November 1, 2004Introduction to Computer Security ©2004 Matt Bishop 1 Data Flow Diagrams (DFDs)...

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


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


3

Simple Example DFD

WebInterface

Shop

Create Order

ShopDatabase

Order DataOrder Feedback

NewOrder

OrderConfirm-

ationAudit Log

Log Entries


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


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


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


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


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


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


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


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


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


13

Overview

• Simplicity– Less to go wrong– Fewer possible inconsistencies– Easy to understand

• Restriction– Minimize access– Inhibit communication


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


15

Fail-Safe Defaults

• Default action is to deny access

• If action fails, system as secure as when action began


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


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


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


19

Separation of Privilege

• Require multiple conditions to grant privilege– Separation of duty– Defense in depth


20

Least Common Mechanism

• Mechanisms should not be shared– Information can flow along shared channels– Covert channels

• Isolation– Virtual machines– Sandboxes


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


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


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)


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


25

Privileged Users

• Do ACLs apply to privileged users (root)?– Solaris: abbreviated lists do not, but full-blown

ACL entries do– Other vendors: varies


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


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


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


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


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


31

Chapter 16: Confinement Problem

• What is the problem?

• Isolation: virtual machines, sandboxes

• Detecting covert channels

• Analyzing covert channels

• Mitigating covert channels


32

Overview

• The confinement problem• Isolating entities

– Virtual machines– Sandboxes

• Covert channels– Detecting them– Analyzing them– Mitigating them


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


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


35

Confinement Problem

• Problem of preventing a server from leaking information that the user of the service considers confidential


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.


37

Covert Channel

• A path of communication not designed to be used for communication

• In example, file system is a (storage) covert channel


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


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


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


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


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)


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


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


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


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


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 ) )


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


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


50

Disaster Prevention and Recovery Controls

• Backup• Environmental controls• Redundant hardware to prevent system

outage• Disaster recovery plan• Insurance


51

Backup

• Applies to programs and data.

• Should backup programs daily or as changed, but at least weekly.

• Keep a copy of backup offsite.


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.


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.


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.


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.


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


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.


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.


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.


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.

Date post:	17-Jan-2016
Category:	Documents
Upload:	coral-preston
View:	215 times
Download:	0 times

November 1, 2004Introduction to Computer Security ©2004 Matt Bishop 1 Data Flow Diagrams (DFDs)...

Documents