november 1, 2004introduction to computer security ©2004 matt bishop 1 data flow diagrams (dfds)...
TRANSCRIPT
November 1, 2004 Introduction to Computer Security©2004 Matt Bishop
1
Data Flow Diagrams (DFDs)
• Model the flow of data through the system• Shows data flow between components• May use different view levels
– e.g. Level 1 (rough) ... level 3 (detailed)– Often one top-level (sometimes called context)
• Components of a DFD (below)
Process InterfaceDataStore
Data Flow
Bou
ndar
y
November 1, 2004 Introduction to Computer Security©2004 Matt Bishop
2
Levels in a DFD
Level 1
P1
I1 DF1
I2 DF2
Level 2
P1.1
I1.1
DF1.1
D1.2
P1.2
DS1
DF1.3
Process P1 on more detail
November 1, 2004 Introduction to Computer Security©2004 Matt Bishop
3
Simple Example DFD
WebInterface
Shop
Create Order
ShopDatabase
Order DataOrder Feedback
NewOrder
OrderConfirm-
ationAudit Log
Log Entries
November 1, 2004 Introduction to Computer Security©2004 Matt Bishop
4
Requirements for DFD
• A process always has input data and output data
• A data flow starts or ends at a process
• A data store only be connected to a process via data flows (in and/or out)– Not with another data store or interface
November 1, 2004 Introduction to Computer Security©2004 Matt Bishop
5
Naming of the Components
• Process– With verbs saying what the process does– e.g. create order
• Data flow– Name of the data which flows– e.g. log entries
• Interface– Name of the interface or actor (who)– e.g. web interface
• Data store– A name telling what type of data is stored there– e.g. Audit Log
November 1, 2004 Introduction to Computer Security©2004 Matt Bishop
6
Threat Matrix - DFDThreat Type
Process Interface Data Store
Data Flow
Spoof X X
Tamper X X X
Repudiate X X X
I. disclosure X X X
Denial X X X
Elevation X
November 1, 2004 Introduction to Computer Security©2004 Matt Bishop
7
Threat Targets
• All components in a DFD can be targets of threats
• Consider all possible categories of threats for each target
• For each threat, we can sketch the requirements to enable an attack
• Try to see with the eye of an attacker
November 1, 2004 Introduction to Computer Security©2004 Matt Bishop
8
Threat Tree
• Each threat forms the root of a separate tree – a threat tree
• Each path to a leaf shows a way to mount an attack (also known as attack vector)
• Each node in a path shows an action– Its children show the requirements for enabling the
action or show options to perform the action– Children can have a logical AND relation
• Some paths are more likely than others– The most likely forms the basis for risk assessment
November 1, 2004 Introduction to Computer Security©2004 Matt Bishop
9
Example: Threat TreeThreat #1 (I)View order data on wire
1.1HTTP is unprotected
1.2Attacker views traffic
Adapted from book Writing Secure Code
Microsoft Press
1.2.2Listen to router traffic
1.2.1Sniff networktraffic
1.2.3Compromiseswitch
1.2.2.1Router isunpatched
1.2.2.2Compromiserouter
1.2.2.3Guess routerpassword
1.2.3.1Variousswitch attacks
and
and
November 1, 2004 Introduction to Computer Security©2004 Matt Bishop
10
Compact Text Format
1 View order data on wire 1.1 HTTP is unprotected (AND) 1.2 Attacker views traffic 1.2.1 Sniff network traffic 1.2.2 Listen to router traffic 1.2.2.1 Router is unpatched (AND) 1.2.2.2 Compromise router 1.2.2.3 Guess router password 1.2.3 Compromise switch 1.2.3.1 Various switch attacks
November 1, 2004 Introduction to Computer Security©2004 Matt Bishop
11
Things to Note for a Threat
• Title (ID)• Threat target – e.g. component of DFD• Threat type(s) – e.g. a letter from STRIDE• Risk – e.g. with a value between 1 and 100• Threat tree• Mitigation techniques
– What can be done? Add this after analysis of threat
• Mitigation status– What needs to be, what has been done? With what effect?
• Bug number (optional)– If the threat is related to (or caused by) a bug
November 1, 2004 Introduction to Computer Security©2004 Matt Bishop
12
Chapter 12: Design Principles
• Overview• Principles
– Least Privilege– Fail-Safe Defaults– Economy of Mechanism– Complete Mediation– Open Design – Separation of Privilege– Least Common Mechanism– Psychological Acceptability
November 1, 2004 Introduction to Computer Security©2004 Matt Bishop
13
Overview
• Simplicity– Less to go wrong– Fewer possible inconsistencies– Easy to understand
• Restriction– Minimize access– Inhibit communication
November 1, 2004 Introduction to Computer Security©2004 Matt Bishop
14
Least Privilege
• A subject should be given only those privileges necessary to complete its task– Function, not identity, controls– Rights added as needed, discarded after use– Minimal protection domain
November 1, 2004 Introduction to Computer Security©2004 Matt Bishop
15
Fail-Safe Defaults
• Default action is to deny access
• If action fails, system as secure as when action began
November 1, 2004 Introduction to Computer Security©2004 Matt Bishop
16
Economy of Mechanism
• Keep it as simple as possible– KISS Principle
• Simpler means less can go wrong– And when errors occur, they are easier to
understand and fix
• Interfaces and interactions
November 1, 2004 Introduction to Computer Security©2004 Matt Bishop
17
Complete Mediation
• Check every access
• Usually done once, on first action– UNIX: access checked on open, not checked
thereafter
• If permissions change after, may get unauthorized access
November 1, 2004 Introduction to Computer Security©2004 Matt Bishop
18
Open Design
• Security should not depend on secrecy of design or implementation– Popularly misunderstood to mean that source
code should be public– “Security through obscurity” – Does not apply to information such as
passwords or cryptographic keys
November 1, 2004 Introduction to Computer Security©2004 Matt Bishop
19
Separation of Privilege
• Require multiple conditions to grant privilege– Separation of duty– Defense in depth
November 1, 2004 Introduction to Computer Security©2004 Matt Bishop
20
Least Common Mechanism
• Mechanisms should not be shared– Information can flow along shared channels– Covert channels
• Isolation– Virtual machines– Sandboxes
November 1, 2004 Introduction to Computer Security©2004 Matt Bishop
21
Psychological Acceptability
• Security mechanisms should not add to difficulty of accessing resource– Hide complexity introduced by security
mechanisms– Ease of installation, configuration, use– Human factors critical here
November 1, 2004 Introduction to Computer Security©2004 Matt Bishop
22
Key Points
• Principles of secure design underlie all security-related mechanisms
• Require:– Good understanding of goal of mechanism and
environment in which it is to be used– Careful analysis and design– Careful implementation
November 1, 2004 Introduction to Computer Security©2004 Matt Bishop
23
Session 4 – Access Control Lists
• ACLs can be long … so combine users– UNIX: 3 classes of users: owner, group, rest
– rwx rwx rwx
rest
group
owner
– Ownership assigned based on creating process• Some systems: if directory has setgid permission, file group owned by
group of directory (SunOS, Solaris)
November 1, 2004 Introduction to Computer Security©2004 Matt Bishop
24
Permissions in IBM AIX
attributes:base permissionsowner(bishop): rw-group(sys): r--others: ---
extended permissions enabledspecify rw- u:hollypermit -w- u:heidi, g=syspermit rw- u:mattdeny -w- u:holly, g=faculty
November 1, 2004 Introduction to Computer Security©2004 Matt Bishop
25
Privileged Users
• Do ACLs apply to privileged users (root)?– Solaris: abbreviated lists do not, but full-blown
ACL entries do– Other vendors: varies
November 1, 2004 Introduction to Computer Security©2004 Matt Bishop
26
Conflicts
• Deny access if any entry would deny access– AIX: if any entry denies access, regardless or rights
given so far, access is denied
• Apply first entry matching subject– Cisco routers: run packet through access control rules
(ACL entries) in order; on a match, stop, and forward the packet; if no matches, deny
• Note default is deny so honors principle of fail-safe defaults
November 1, 2004 Introduction to Computer Security©2004 Matt Bishop
27
Handling Default Permissions
• Apply ACL entry, and if none use defaults– Cisco router: apply matching access control
rule, if any; otherwise, use default rule (deny)
• Augment defaults with those in the appropriate ACL entry– AIX: extended permissions augment base
permissions
November 1, 2004 Introduction to Computer Security©2004 Matt Bishop
28
Windows NT ACLs
• Different sets of rights– Basic: read, write, execute, delete, change permission, take
ownership
– Generic: no access, read (read/execute), change (read/write/execute/delete), full control (all), special access (assign any of the basics)
– Directory: no access, read (read/execute files in directory), list, add, add and read, change (create, add, read, execute, write files; delete subdirectories), full control, special access
November 1, 2004 Introduction to Computer Security©2004 Matt Bishop
29
Accessing Files
• User not in file’s ACL nor in any group named in file’s ACL: deny access
• ACL entry denies user access: deny access
• Take union of rights of all ACL entries giving user access: user has this set of rights over file
November 1, 2004 Introduction to Computer Security©2004 Matt Bishop
30
Example: Cisco Router
• Dynamic access control listsaccess-list 100 permit tcp any host 10.1.1.1 eq telnetaccess-list 100 dynamic test timeout 180 permit ip any host \
10.1.2.3 time-range my-timetime-range my-time
periodic weekdays 9:00 to 17:00line vty 0 2
login localautocommand access-enable host timeout 10
• Limits external access to 10.1.2.3 to 9AM–5PM– Adds temporary entry for connecting host once user
supplies name, password to router– Connections good for 180 minutes
• Drops access control entry after that
November 1, 2004 Introduction to Computer Security©2004 Matt Bishop
31
Chapter 16: Confinement Problem
• What is the problem?
• Isolation: virtual machines, sandboxes
• Detecting covert channels
• Analyzing covert channels
• Mitigating covert channels
November 1, 2004 Introduction to Computer Security©2004 Matt Bishop
32
Overview
• The confinement problem• Isolating entities
– Virtual machines– Sandboxes
• Covert channels– Detecting them– Analyzing them– Mitigating them
November 1, 2004 Introduction to Computer Security©2004 Matt Bishop
33
Example Problem
• Server balances bank accounts for clients
• Server security issues:– Record correctly who used it– Send only balancing info to client
• Client security issues:– Log use correctly– Do not save or retransmit data client sends
November 1, 2004 Introduction to Computer Security©2004 Matt Bishop
34
Generalization
• Client sends request, data to server• Server performs some function on data• Server returns result to client• Access controls:
– Server must ensure the resources it accesses on behalf of client include only resources client is authorized to access
– Server must ensure it does not reveal client’s data to any entity not authorized to see the client’s data
November 1, 2004 Introduction to Computer Security©2004 Matt Bishop
35
Confinement Problem
• Problem of preventing a server from leaking information that the user of the service considers confidential
November 1, 2004 Introduction to Computer Security©2004 Matt Bishop
36
Total Isolation
• Process cannot communicate with any other process
• Process cannot be observed
Impossible for this process to leak information– Not practical as process uses observable
resources such as CPU, secondary storage, networks, etc.
November 1, 2004 Introduction to Computer Security©2004 Matt Bishop
37
Covert Channel
• A path of communication not designed to be used for communication
• In example, file system is a (storage) covert channel
November 1, 2004 Introduction to Computer Security©2004 Matt Bishop
38
Rule of Transitive Confinement
• If p is confined to prevent leaking, and it invokes q, then q must be similarly confined to prevent leaking
• Rule: if a confined process invokes a second process, the second process must be as confined as the first
November 1, 2004 Introduction to Computer Security©2004 Matt Bishop
39
Isolation
• Virtual machines– Emulate computer– Process cannot access underlying computer
system, anything not part of that computer system
• Sandboxing– Does not emulate computer– Alters interface between computer, process
November 1, 2004 Introduction to Computer Security©2004 Matt Bishop
40
Virtual Machine (VM)
• A program that simulates hardware of computer system
• Virtual machine monitor (VMM) provides VM on which conventional OS can run– Each VM is one subject; VMM knows nothing about
processes running on each VM
– VMM mediates all interactions of VM with resources, other VMS
– Satisfies rule of transitive closure
November 1, 2004 Introduction to Computer Security©2004 Matt Bishop
41
Example: KVM/370
• Security-enhanced version of IBM VM/370 VMM• Goals
– Provide virtual machines for users
– Prevent VMs of different security classes from communicating
• Provides minidisks; some VMs could share some areas of disk– Security policy controlled access to shared areas to
limit communications to those allowed by policy
November 1, 2004 Introduction to Computer Security©2004 Matt Bishop
42
Sandbox
• Environment in which actions of process are restricted according to security policy– Can add extra security-checking mechanisms to
libraries, kernel• Program to be executed is not altered
– Can modify program or process to be executed• Similar to debuggers, profilers that add breakpoints• Add code to do extra checks (memory access, etc.)
as program runs (software fault isolation)
November 1, 2004 Introduction to Computer Security©2004 Matt Bishop
43
Covert Channels
• Channel using shared resources as a communication path
• Covert storage channel uses attribute of shared resource
• Covert timing channel uses temporal or ordering relationship among accesses to shared resource
November 1, 2004 Introduction to Computer Security©2004 Matt Bishop
44
Example: File Manipulation
• Communications protocol:– p sends a bit by creating a file called 0 or 1, then a
second file called send• p waits until send is deleted before repeating to send another
bit
– q waits until file send exists, then looks for file 0 or 1; whichever exists is the bit
• q then deletes 0, 1, and send and waits until send is recreated before repeating to read another bit
• Covert storage channel: resource is directory, names of files in directory
November 1, 2004 Introduction to Computer Security©2004 Matt Bishop
45
Noise
• Noiseless covert channel uses shared resource available to sender, receiver only
• Noisy covert channel uses shared resource available to sender, receive, and others– Need to minimize interference enough so that
message can be read in spite of others’ use of channel
November 1, 2004 Introduction to Computer Security©2004 Matt Bishop
46
Detection
• Covert channels require sharing• Manner of sharing controls which subjects
can send, which subjects can receive information using that shared resource
• Porras, Kemmerer: model flow of information through shared resources with a tree– Called covert flow trees
November 1, 2004 Introduction to Computer Security©2004 Matt Bishop
47
Finding Covert Channels
• Find sequences of operations that modify attribute– ( Lockfile ), ( Unlockfile )
• Find sequences of operations that recognize modifications to attribute– ( Filelocked ), ( Openfile, Fileopened ) )
November 1, 2004 Introduction to Computer Security©2004 Matt Bishop
48
Covert Channel Commands
• Sequences with first element from first list, second element from second list– Lockfile, then Filelocked– Unlockfile, then Filelocked– Lockfile, then Openfile, then Fileopened– Unlockfile, then Openfile, then Fileopened
November 1, 2004 Introduction to Computer Security©2004 Matt Bishop
49
Mitigation
• Goal: obscure amount of resources a process uses– Receiver cannot determine what part sender is
using and what part is obfuscated
• How to do this?– Devote uniform, fixed amount of resources to
each process– Inject randomness into allocation, use of
resources
November 1, 2004 Introduction to Computer Security©2004 Matt Bishop
50
Disaster Prevention and Recovery Controls
• Backup• Environmental controls• Redundant hardware to prevent system
outage• Disaster recovery plan• Insurance
November 1, 2004 Introduction to Computer Security©2004 Matt Bishop
51
Backup
• Applies to programs and data.
• Should backup programs daily or as changed, but at least weekly.
• Keep a copy of backup offsite.
November 1, 2004 Introduction to Computer Security©2004 Matt Bishop
52
Data Retention and Backup – Batch Systems
• Grandparent-parent-child approach for retaining master files, i.e., at least last 3 generations of master files are kept for recreation of the current master file.
• Transaction files are kept to meet statutory requirements.
• A copy of each version of master file and transaction file should be made and stored offsite for contingency.
November 1, 2004 Introduction to Computer Security©2004 Matt Bishop
53
Data Retention and Backup – Online Systems
• Master file is updated continuously and should be backed up frequently like every 15 minutes.
• Transactions are written to redundant (duplicate) disks for contingency.
• Transaction files are kept for statutory requirements.
November 1, 2004 Introduction to Computer Security©2004 Matt Bishop
54
Data Retention and Backup- Online Systems
• A copy of the master file backup and each transaction file is stored offsite.
• Although transactions update the master files continuously, organizations typically keep transaction files by day, one file per day.
November 1, 2004 Introduction to Computer Security©2004 Matt Bishop
55
Environmental Controls
• Preventive – fire and water resistant material used for media and premises; also temperature control.
• Detective – alarms such as smoke detectors
• Corrective – fire retardant measures such as extinguishers.
November 1, 2004 Introduction to Computer Security©2004 Matt Bishop
56
Redundant Hardware
• Critical servers
• Redundant array of independent disks to prevent system outage or data loss from disk failures
• Redundant transmission methods
• Redundant transmission lines and routers
November 1, 2004 Introduction to Computer Security©2004 Matt Bishop
57
Disaster Recovery Plan
• Based on business impact analysis; purpose is to recover critical application in the event of system incapacitation.
• Hot, warm and cold sites.
• Plan should be tested.
• Plan should be kept offsite.
November 1, 2004 Introduction to Computer Security©2004 Matt Bishop
58
Disaster Recovery Plan
• Should address office space and human requirements for information systems continuity.
• Should designate a team and who is in charge.
• Should have procedures and criteria for invoking the plan.
• Must be rigorously tested annually.
November 1, 2004 Introduction to Computer Security©2004 Matt Bishop
59
Disaster Recovery Site
• Hot site – Available within a day, has hardware, software and data.
• Warm site – Available in a few days, has hardware, but no software or data.
• Cold site – Available in about a week, has no hardware, software or data.
November 1, 2004 Introduction to Computer Security©2004 Matt Bishop
60
Disaster Recovery Site
• May be provided within the organization, through a vendor or through a competitor or trading partner
• When provided by a competitor or trading partner, this is also called a mutual aid pact or a reciprocal site.
• Should be distant from the production site.
• Security should be equivalent to production site.