Carl LandwehrSenior FellowMitretek Systems, Inc.MS Z2857525 Colshire Dr.McLean VA 22102(703)610-1576Carl.Landwehr@mitretek.org

Threat/Attack Model and Policy Specifications Discussion

DARPA IA&S Joint PI Meeting

19 July 2000

Goals of discussion

• Better understanding of threat/attack models different projects are working with

• Better understanding of what protection the current ITS projects will provide– individually– collectively

• What is your attack model?• What policies can you enforce?

How can we understand how our systems will behave under attack?• Build it and try it out

– penetrate and patch– red teams

• Abstract the properties we desire of the system and the kinds of attacks we think likely

• Build models to represent system designs and see whether they have the desired properties

• Build systems to match the abstractions

S

’

S’f

Want: P(S) =>P(f(S))

Show: =>’

Unfortunately …• The process isn’t so tidy• We have to use pre-existing components to build

the system• Those components may have properties we don’t

want• Or properties we don’t know about (e.g. buffer

overflows, etc.)

Standard approach for attacker

Attack the assumptions of the system at some level of abstraction: – Thompson compiler attack: assumption that

reviewing source code is sufficient– Race condition/TOCTTOU: attacks assumption

that execution is linear– Find hidden software interfaces/hardware

instructions: attacks assumption that full transition function is known

– Replace some hardware: attacks assumption that configuration, initialization are fixed

Anatomy of an attack

1. Preparation:– Identify systems of

interest– Identify specific targets– Collect information on

targets:• Obtain & study specs• Identify/befriend

operators/users• Subvert insider

– Develop attack plan– Design/build attack

2. Limited Probing– LPI to minimize alerting

the targeted system

3. Mounting the attack• Exploit identified weakness to gain unauthorized access• Turn off intrusion detection• Execute bad deed• Restore state to look benign• Exit quietly

4. Possibly iterate step (3) e.g.: • install password sniffer, • time bomb, • DDOS zombie,• Download host list to identify trust relationships.

Models of computer system threat/attack

• Trojan Horse program(1972)• Byzantine failures (1982)• Security Flaw taxonomy (NRL, 1994):

– purpose to characterize flaws, not attacks– characterize genesis (when), where, what kind

• J. Howard Diss. (1997)– Process orientation– Characterize:

• attacker, tool, access method, results, objectives

K. Kendall MS thesis - 1998 • LL IDS evaluation

– privilege levels: Remote, Local, User, Superuser, Physical – actions:

• abusive act at authorized level of privilege• unauthorized level transition• cause (unauth) action at higher level

– means• masquerade• bug• misconfiguration• social engineering

– actions (results)• probe - machines, services, users• deny - temporary, admin, permanent• intercept - keystrokes, files, net traffic• alter - data, traces of intrusion• use - recreation, further intrusion

• Lincoln Lab shorthand: R2L, U2R, DoS, Probe

Vulnerability database(s):

• ISS X-force, http://xforce.iss.net/• NIST ICAT, http://csrc.nist.gov/icat/• MITRE CVE http://www.cve.mitre.org/

Relation to Intrusion Tolerant Systems

• What is the model of an attack (intrusion) for your system?

• What is the policy your system, component, technique, aims to enforce?

• Characterize the response of your system to an attack

• Success for ITS– composition of the systems can withstand

the union of the attacks?

What is a policy?

• A high-level overall plan embracing the general goals and acceptable procedures of a body (Merriam Webster)

• Roots similar to politics• Notion of overall guiding rule• It’s what police enforce?

• Distinction with long history in computer security

• Reference Monitor: reference validation mechanism tests access against specified policy (Anderson Report, 1972)

• Security kernels (e.g., Popek UCLA Data Secure Unix)

• Note bureaucratic analog: – DoD Directives set policy, – military departments and

agencies write implementing instructions

Policy vs Mechanism

ReferenceValidation Mechanism

Subject

Policy(accessmatrix)

Object

The old stuff• Confidentiality: Mandatory Access Control

– policy: protect sensitive data from being disclosed to those uncleared for it

– Bell LaPadula model: model of policy (plus computer system, sort of)

– non-interference, restrictiveness, ...• Integrity:

– Biba model(s)• Availability?

– Yu/Gligor, Millen efforts for modeling DoS– Dependability world

• Application level policies: Secure MMS

Theory

• Harrison-Ruzzo-Ullman– for a typical access matrix implementation,

you can’t tell where a given right may end up (i.e., safety problem undecidable)

• Sandhu, etc.– identify some constraints (e.g. typed access

matrices) under which problem becomes decidable

• Schneider– Security automata - what policies can be

enforced by Execution Monitors?

Role Based Access Control

• Attempt to provide finer grained access control policies, with better accountability, simpler management

• Role organizes a set of permissions; • Users, Subjects, operations, objects, roles, • Example: Adage

Firewall policies• Rules specify policy:

– action: permit/deny– basis: from/to (IP addresses), protocol,

possibly additional state• Example: Firmato

– attempt to specify firewall policy at level above specific firewall rules

– concepts: • Role (set of peer capabilities)

– Capability: Service (protocol, src/dest port range), peers, direction

• Topology (Gateways, Zones (Hostgroups, hosts)

Firmato example goal policy

1. Internal corporate hosts can access all resources on Internet

2. External hosts can access only servers in DMZ3. External servers can only be updated by web

administrator host4. Firewall gateway interfaces are accessible only

from fw_admin host

Practical policies for COTS use?

• Viewing/printing a Postscript file should never: cause any file in a directory other than /tmp to be altered

• Opening a Word document should never: cause any file to be written without explicit user concurrence?

• Applet can read local files as long as it doesn’t send any data over network

• Attachment, when invoked, can’t modify/delete any file except in /tmp

• Editor controlled by user can access any file, otherwise only files in /tmp

• Agent can read only specific row in this spreadsheet and send only to battalion HQ

Discussion

• What threats/attacks is your project considering?• What assumptions does your project make?• What policies can your project enforce?• What policies can the collection of projects

enforce?