IS 3957 Doctoral Seminar in Systems and Technology Information Assurance

1
IS 3957 Doctoral Seminar in Systems and
TechnologyInformation Assurance

• Introduction
• James Joshi
• September 8, 2005

2
Access Control

• Access control
• Restrict access to system entities to authorized
  personnel
• Security Domain
• A bounded group of subjects and objects under a
  single security policy
• Multidomain Secure Environment
• Ensuring a secure interaction among participating
  domains

3
Current Systems

• Single domain systems
• Multidomain systems
• Open Interconnected Heterogeneous Systems
• Web applications, E-Government, Global
  enterprises

4
DoD Business Operations Environment (Ref JECPO)
Operational View
OV-1
Warfighter Operations

• Introduction

Movement
Training
Requirements Analysis
Maintenance
Adjudication
TE
Business Protection Environment
Auditing
Transportation
Budget Planning
Training Development
Construction Mgmt
Receiving
Program Sch, Dir, Cont
Contract Admin
Disposal Mgmt
Procurement
Personnel Admin
Engineering Analysis Approval
Payment/ Disbursement
Facilities Mgmt
Technology Projection
Funds Mgmt
Inventory Flow Mgmt
Oversight
Maintenance Planning
Health, Safety, Environment
Accounting
Log Planning
DoD Business Operations
Business Protection Environment
Example
5
Discretionary Access Control (DAC)

• Subjects have ownership over objects
• A subject can pass access rights to other
  subjects at his discretion
• Highly flexible and most widely used
• Not appropriate for
• high assurance systems, e.g., a military system
• Many complex commercial security requirements
• Trojan horse problem

6
Mandatory Access Control (MAC)

• Subjects/objects have security levels forming a
  lattice
• Flow of information is restricted.
• Example (no-readup), (no-writedown)
• Well-know MAC model is the Bell-LaPadula model

7
Some Existing Models

• Abstract models
• HRUs Access Control Matrix
• Schematic Protection Model and variation
• Mandatory
• Confidentiality model - Bell-LaPadula
• Integrity model
• Biba, Lipners, Clark-Wilson
• Hybrid
• Chinese wall

8
Confidentiality Policy

• Also known as information flow policy
• Integrity is secondary objective
• Eg. Military mission date
• Bell-LaPadula Model
• Formally models military requirements
• Information has sensitivity levels or
  classification
• Subjects have clearance
• Subjects with clearance are allowed access
• Multi-level access control or mandatory access
  control

9
Bell-LaPadula Basics

• Mandatory access control
• Entities are assigned security levels
• Subject has security clearance L(s) ls
• Object has security classification L(o) lo
• Simplest case Security levels are arranged in a
  linear order li lt li1
• Example
• Top secret gt Secret gt Confidential gtUnclassified

10
No Read Up

• Information is allowed to flow up, not down
• Simple security property
• s can read o if and only if
• lo ls and
• s has read access to o
• Combines mandatory (security levels) and
  discretionary (permission required)
• Prevents subjects from reading objects at higher
  levels (No Read Up rule)

11
No Write Down

• Information is allowed to flow up, not down
• property
• s can write o if and only if
• ls lo and
• s has write access to o
• Combines mandatory (security levels) and
  discretionary (permission required)
• Prevents subjects from writing to objects at
  lower levels (No Write Down rule)

12
Categories

• Total order of classifications not flexible
  enough
• Alice cleared for missiles Bob cleared for
  warheads Both cleared for targets
• Solution Categories
• Use set of compartments (from power set of
  compartments)
• Enforce need to know principle
• Security levels (security level, category set)
• (Top Secret, Nuc, Eur, Asi)
• (Top Secret, Nuc, Asi)
• Combining with clearance
• (L,C) dominates (L,C) ? L L and C ? C
• Induces lattice of security levels

13
Lattice of categories
Nuc, Eur, Us

• Examples of levels
• (Top Secret, Nuc,Asi) dom (Secret, Nuc)
• (Secret, Nuc, Eur) dom (Confidential,
  Nuc,Eur)
• (Top Secret, Nuc) ?dom (Confidential, Eur)
• Bounds
• Greatest lower,
• Lowest upper
• glb of X, Nuc, Us X, Eur, Us?
• lub of X, Nuc, Us X, Eur, Us?

Nuc, Eur
Nuc, Us
Eur, Us
Us
Nuc
Eur

14
Integrity policy

• Requirements different than confidentiality
  policies
• Bibas models
• Low-Water-Mark policy
• Ring policy
• Strict Integrity policy
• Lipners model
• Combines Bell-LaPadula, Biba for a more practical
  software development and deployment process
• Clark-Wilson model
• Transaction integrity
• Separation of duty

15
Bibas Integrity Policy Model

• Based on Bell-LaPadula
• Subject, Objects
• Integrity Levels with dominance relation
• Higher levels
• more reliable/trustworthy
• More accurate
• Information transfer pathSequence of subjects,
  objects where
• si r oi
• si w oi1

16
Policies

• Low-Water-Mark Policy
• s w o ? i(o) i(s) prevents writing to higher
  level
• s r o ? i(s) min(i(s), i(o)) drops subjects
  level
• s1 x s2 ? i(s2) i(s1) prevents executing higher
  level objects
• Ring Policy
• s r o allows any subject to read any object
• s w o ? i(o) i(s) (same as above)
• s1 x s2 ? i(s2) i(s1)
• Bibas Model Strict Integrity Policy (dual of
  Bell-LaPadula)
• s r o ? i(s) i(o) (no read-down)
• s w o ? i(o) i(s) (no write-up)
• s1 x s2 ? i(s2) i(s1)
• Theorem for each
• If there is an information transfer path from
  object o1 to object on1, then the enforcement of
  the policy requires that i(on1) i(o1) for all
  ngt1

17
Requirements of Commercial Integrity Policies
(Lipner)

1. Users will not write their own programs, but will
   use existing production programs and databases.
2. Programmers will develop and test programs on a
   nonproduction system if they need access to
   actual data, they will be given production data
   via a special process, but will use it on their
   development system.
3. A special process must be followed to install a
   program from the development system onto the
   production system.
4. The special process in requirement 3 must be
   controlled and audited.
5. The managers and auditors must have access to
   both the system state and the system logs that
   are generated.

18
Integrity Policy Principles of operation

• Requirements induce principles of operation
• Separation of Duty Single person should not be
  allowed to carry out all steps of a critical
  function
• Moving a program from Dev. to Prod. system
• Developer and Certifier (installer) of a program
• Authorizing checks and cashing it
• Separation of function
• Do not process production data on development
  system
• Auditing
• Emphasis on recovery and accountability
• Controlled/audited process for updating code on
  production system

19
RBAC (NIST Standard)
Permissions
PA
UA
Users
Roles
Operations
Objects
user_sessions (one-to-many)
role_sessions (many-to-many)
Sessions
An important difference from classical models is
that Subject in other models corresponds to a
Session in RBAC
20
Advantages of RBAC

• Allows Efficient Security Management
• Administrative roles to manage other roles
• Role hierarchy allows inheritance of permissions
• Principle of least privilege
• Minimizes damage
• Separation of Duties constraints
• Prevents fraud
• Grouping Objects
• Permissions can be grouped according to a class
  of objects
• Policy-neutrality
• Provides generality

21
Core RBAC (relations)

• Permissions 2Operations x Objects
• UA ? Users x Roles
• PA ? Permissions x Roles
• assigned_users Roles ? 2Users
• assigned_permissions Roles ? 2Permissions
• Op(p) set of operations associated with
  permission p
• Ob(p) set of objects associated with permission
  p
• user_sessions Users ? 2Sessions
• session_user Sessions ? Users
• session_roles Sessions ? 2Roles
• session_roles(s) r (session_user(s), r) ?
  UA)
• avail_session_perms Sessions ? 2Permissions

22
RBAC with General Role Hierarchy
RH (role hierarchy)
Permissions
PA
UA
Users
Roles
Operations
Objects
user_sessions (one-to-many)
role_sessions (many-to-many)
Sessions
23
RBAC with General Role Hierarchy

• authorized_users Roles? 2Users
• authorized_users(r) u r r (r, u) ?
  UA)
• authorized_permissions Roles? 2Permissions
• authorized_users(r) p r r (p, r) ?
  PA)
• RH ? Roles x Roles is a partial order
• called the inheritance relation
• written as .
• (r1 r2) ? authorized_users(r1) ?
  authorized_users(r2)
• authorized_permisssions(r2) ? authorized_permisssi
  ons(r1)

24
Example
authorized_users(Employee)? authorized_users(Admin
istrator)? authorized_permissions(Employee)?
authorized_permissions(Administrator)?
25
Constrained RBAC
RH (role hierarchy)
Static Separation of Duty
Permissions
PA
UA
Users
Roles
Operations
Objects
user_sessions (one-to-many)
Dynamic Separation of Duty
Sessions
26
Static Separation of Duty

• SSD ?2Roles x N
• In absence of hierarchy
• Collection of pairs (RS, n) where RS is a role
  set, n 2 for all (RS, n) ? SSD, for all t
  ?RS
• t n ? nr?t assigned_users(r) ?
• In presence of hierarchy
• Collection of pairs (RS, n) where RS is a role
  set, n 2
• for all (RS, n) ? SSD, for all t ?RS
• t n ? nr?t authorized_uers(r) ?

27
Dynamic Separation of Duty

• DSD ?2Roles x N
• Collection of pairs (RS, n) where RS is a role
  set, n 2
• A user cannot activate n or more roles from RS
• What if both SSD and DSD contains (RS, n)?
• Consider (RS, n) (r1, r2, r3, 2)?
• If SSD can r1, r2 and r3 be assigned to u?
• If DSD can r1, r2 and r3 be assigned to u?

28
MAC using RBAC
HR
LW
H
Read Roles (same lattice)
Write Roles (inverse lattice)
M1R
M2R
M1W
M2W
M1
M2
BLP
LR
H
L

• Transformation rules
• R L1R, L2R,, LnR, L1W, L2W,, LnW
• Two separate hierarchies for L1R, L2R,, LnR
  and L1W, L2W,, LnW
• Each user is assigned to exactly two roles xR
  and LW
• Each session has exactly two roles yR and yW
• Permission (o, r) is assigned to xR iff (o, w) is
  assigned to xW)

29
Security for Grid-based Computing SystemsIssues
and Challenges
30
What is a Grid?

• Enabling the coordinated use of geographically
  distributed resources in the absence of central
  control, omniscience, strong trust relationships
  connect distributed heterogeneous high
  performance computer, computer cluster,
  large-scale database server and large-scale file
  server with high-speed interconnection network
  and integrate them into a transparent virtual
  high-performance computing environment.
• 
  Ian Foster

31
What is a Grid?

• Systems applications that integrate and manage
  resources and services distributed across
  multiple security domains
• Large and dynamic pool of users and resources
• Sharing is highly controlled coordinated
• Dynamic creation of services
• Form virtual organizations (VO)
• Collaboration is dynamic, ad-hoc
• Resource providers belong to different real
  organizations employing different policies and
  mechanisms

32
What is a Grid?
Domain 1
Domain 3
Virtual Organization Policy
Domain 4
Domain 2
Essentially a Dynamic Multidomain Environment
33
Grid Security

• Globus Toolkit (GT) includes Grid Security
  Infrastructure (GSI)
• PKI to support identity mapping, single sign-on,
  delegation
• GT2
• X.509 certificate, TLS, SSL protocol
• Proxy certificate for delegation
• Community Authorization Service
• GT3 Open Grid Services Architecture (OGSA)
• Align Grid with web services technologies

34
Limitation of Classic Globus Authorization

• Scalability
• Each personnel or policy change requires changing
  policy at each participating site
• Authorization is done at VO as well as in each
  site
• Authorization information needs to be managed by
  individual local site
• Expressivity
• Native OS methods may not be expressive enough to
  support VO policies
• Consistency
• Native OS methods at different sites may not
  support the same kinds of policies

35
Grid Challenges

• Individual hosts (resource providers)
• Each domain must specify highly dynamic set of
  access control policies
• Challenges
• Highly flexible access control framework
  (attribute-based AC)
• Multi-domain problem
• Multiple policies need to be integrated
• Challenges
• Multidomain challenges!
• Trust issues and Risk management

36
Secure interoperation

• Challenges
• Expressive multi-domain policy specification
  framework
• Automation of the integration of policies
• Algorithms to detect violations and compute
  maximal secure interoperation
• scalability?

Policy negotiation Issues (trust)
Delegation
Identity/Credential mapping
37
Security Management

• Tools and techniques needed to support efficient
  administration of Grid security
• Grid can scale to Internet size
• Dynamically changing resource pool
• Protection objects may include
• Compute cycle storage elements
• Sophisticate instruments
• Data (files and database elements)
• Services
• High level information knowledge/concepts
• Dynamic pool of users with diverse credentials
• Identity/credential management
• Policies and mechanisms evolve

38
Trust and Risk Management

• Trust management is essential for dynamic
  collaboration environment
• Trust-based authorization
• Absolute security is not possible
• Single point of failure situation
• Security assurance may vary
• Grid resources may be very sensitive
• Trust and risk issues become very crucial
• Impact severity of information leaks?
• How to control propagation of risks?

39
Grid Challenges

• Individual hosts (resource providers)
• flexible access control framework
• Multi-domain problem
• Semantic heterogeneity secure interoperability
• Security management
• Trust issues and Risk management

40
Multidomain Security
Application (e.g., workflow)
Application (e.g., workflow)
Lightly-coupled
Access Control Module
Access Control Module
Trust-based
Application (e.g. workflow)
Users access requests
Users authorization
Access Control Module
Global Policy Base
Application (e.g., workflow)
Application (e.g., workflow)
Tightly-coupled (Federated system)
Access Control Module
Local Policy Base
41
Semantic heterogeneity

• Different systems may use different security
  policies
• e.g., DAC, MAC, Chinese wall, Integrity policies
  etc.
• Variations of the same policies
• e.g., BLP model and its several variations
• Naming conflict on security attributes
• Similar roles with different names
• Similar permission sets with different role names
• Structural conflict
• different multilevel lattices / role hierarchies

42
Secure Interoperability

• Principles of secure interoperation
• Principle of autonomy
• If an access is permitted within an individual
  system, it must also be permitted under secure
  interoperation in a multi-domain environment.
• Principle of security
• If an access is not permitted within an
  individual system, it must not be permitted under
  secure interoperation.
• Interoperation of secure systems can create new
  security breaches

43
Unsecure Interoperability
X
A
X
A
d
c
a
a
Y
Y
B
C
B
C
b
b
Z
D
Z
D
1
1
2
2
F12 a, b, c, d
F12 a, b
(1) F12 a, b, d Direct access
(2) F12 c
F12 - permitted access between systems 1 and 2
44
Challenges in Secure Interoperability

• How to ensure autonomy and security principles?
• Determining inconsistencies/incompleteness in
  security rules.
• Identifying security holes
• Selecting optimality criteria for secure
  interoperability maximizing number of domains,
  direct accesses

45
Assurance and Risk Propagation Security
Management

• Assurance and Risk propagation
• Breach in one domain can render the whole
  environment insecure
• Cascading problem
• Security Management
• Centralized/Decentralized
• Managing global metapolicy
• Managing policy evolution

46
Approaches to Multidomain Problem

• Policy-Metapolicy specification framework
• Ad-hoc, Formal models lattice merging, RBAC
• Agent based approach (Policy agents)
• Architectural approaches (CORBA, DCE)

47
A Multi-Domain Access Control Framework

• A Multi-Phase Framework
• Based on RBAC model

Pre-integration
Policy Comparison
Policy Conformance
Merging/ Restructuring
Need external mediation policy to handle
conflicts/incompleteness
Consistent, complete and optimal specification
48
Pre-integration Phase

• Requires RBAC representation of arbitrary
  policies. A policy mapping technique is needed
  for non-RBAC systems.
• Uses an information base
• Semantic information about domains including
  policies, roles and attributes
• Integration/merging strategies to generate the
  overall configuration of the multi-domain
  environment.

49
Policy Comparison and Conformance

• Tools techniques for detecting
• Semantic conflicts
• Naming conflicts
• Structural conflicts
• Rule conflicts
• Mediation policies are needed for resolution
• Predefined meta-policies
• Domain cooperation by administrators
• Tradeoffs
• Determine optimal/heuristic solutions secure
  interoperability

50
De Merging/Restructuring

• Merging/integrating policies
• Restructure domain policies according to the
  selected optimal criteria
• Generate integrated global policy
• Repeat policy conformance step
• Re-evaluation and restructuring of meta-policy

51
Multidomain Security

• Loosely coupled environment
• More appropriate for open environments
• Mobile environments
• Trust-based framework
• Trust management
• Trust negotiation
• Trust models
• Service oriented architectures
• OO -gt Component based -gt Web Services

52
Trust
53
Trust Establishment

• Trust establishment between strangers in open
  system.
• The client and server are not in the same
  security domain.
• Access control decision is attribute based
  instead of identity based.
• Examples citizenship, clearance, job
  classification, group memberships, licenses, etc.
• The clients role within his home organization.
• Trust Management coined by Matt Blaze

54
Trust negotiation
55
Trust Negotiation

• Goals
• Establish trust
• Maintain privacy of attributes
• Process
• Iteratively exchange digital credentials between
  two negotiating participants.
• Begin by exchanging less sensitive credentials
• Build trust gradually in order to exchange more
  sensitive credentials

56
Digital Credentials

• Digital Credentials
• Are the vehicle for carrying attribute
  information reliably
• Contain attributes of the credential owner
  asserted by the issuer
• Issuer is a certification authority
• Must be unforgeable
• Must be verifiable
• Digitally signed using PKI
• X.509 V3 standard for public-key certificate

57
Credential disclosure

• Credential disclosure policy (CDP)
• Conditions under which a party release resources
• Credentials it contains may be sensitive
  information and should be treated as protected
  resources
• The CDP itself could be a protected object

58
Requirements

• Language requirements
• Well-defined semantics
• Monotonicity
• Credential combination (and, or)
• Authentication
• E.g., a subject may have multiple
  identities/credentials
• Constraints on property values
• Intercredential constraints
• e.g., compare values of different credentials of
  a subject
• Sensitive policy protection no inference should
  be allowed
• Unified formalism and use of interoperable
  language (XML)

59
Requirements

• System requirement
• Credential ownership (challenge response)
• Credential validity
• Credential chain discovery
• Privacy protection mechanisms
• Support for alternative negotiation strategies
• E.g., maximizing protection or considering first
  the computation efforts
• Fast negotiation strategies

60
Some existing systems

• Keynote trust management system
• Trust Establishment at Haifa Research lab
• Trust Policy Language
• TrustBuilder
• Unipro
• Role-based trust management framework
• Trust-X

61
Comparison
62
Intrusion/SurvivabilityManagement
63
Survivability

• Absolute security is not possible
• Hence everything bad cannot be prevented
• Infrastructure for survivability needed
• Detection
• Response
• Recovery
• Survivability
• Represent capability to gracefully manage system
  functionality in presence of attacks and faults

64
Intrusion Detection/Response

• Characteristics of systems not under attack
• Denning Systems under attack fail to meet one
  or more of the following characteristics
• Actions of users/processes conform to
  statistically predictable patterns
• Actions of users/processes do not include
  sequences of commands to subvert security policy
• Actions of processes conform to specifications
  describing allowable actions
• Denning Systems under attack fail to meet one
  or more of these characteristics

65
Intrusion Detection

• Idea Attack can be discovered by one of the
  above being violated
• Automated attack tools
• Designed to violate security policy
• Example rootkits sniff passwords and stay
  hidden
• Practical goals of intrusion detection systems
• Detect a wide variety of intrusions (known
  unknown)
• Detect in a timely fashion
• Present analysis in a useful manner
• Need to monitor many components proper
  interfaces needed
• Be (sufficiently) accurate
• Minimize false positives and false negatives

66
IDS TypesAnomaly Detection

• Compare characteristics of system with expected
  values
• report when statistics do not match
• Threshold metric when statistics deviate from
  normal by threshold, sound alarm
• E.g., Number of failed logins
• Statistical moments based on mean/standard
  deviation of observations
• Number of user events in a system
• Time periods of user activity
• Resource usages profiles
• Markov model based on state, expected
  likelihood of transition to new states
• If a low probability event occurs then it is
  considered suspicious

67
Anomaly DetectionHow do we determine normal?

• Capture average over time
• But system behavior isnt always average
• Correlated events
• Events may have dependencies
• Machine learning approaches
• Training data obtained experimentally
• Data should relate to as accurate normal
  operation as possible

68
IDS TypesMisuse Modeling

• Does sequence of instructions violate security
  policy?
• Problem How do we know all violating sequences?
• Solution capture known violating sequences
• Generate a rule set for an intrusion signature
• But wont the attacker just do something
  different?
• Often, no kiddie scripts, Rootkit,
• Alternate solution State-transition approach
• Known bad state transition from attack (e.g.
  use petri-nets)
• Capture when transition has occurred (user ? root)

69
Specification Modeling

• Does sequence of instructions violate system
  specification?
• What is the system specification?
• Need to formally specify operations of
  potentially critical code
• trusted code
• Verify post-conditions met

70
IDS Systems

• Anomaly Detection
• Intrusion Detection Expert System (IDES)
  successor is NIDES
• Network Security MonitorNSM
• Misuse Detection
• Intrusion Detection In Our Time- IDIOT (colored
  Petri-nets)
• USTAT?
• ASAX (Rule-based)
• Hybrid
• NADIR (Los Alamos)
• Haystack (Air force, adaptive)
• Hyperview (uses neural network)
• Distributed IDS (Haystack NSM)

71
IDS Architecture

• Similar to Audit system
• Log events
• Analyze log
• Difference
• happens real-time - timely fashion
• (Distributed) IDS idea
• Agent generates log
• Director analyzes logs
• May be adaptive
• Notifier decides how to handle result
• GrIDS displays attacks in progress

Director
Notifier
72
Where is the Agent?

• Host based IDS
• watches events on the host
• Often uses existing audit logs
• Network-based IDS
• Packet sniffing
• Firewall logs

73
IDS Problem

• IDS useless unless accurate
• Significant fraction of intrusions detected
• Significant number of alarms correspond to
  intrusions
• Goal is
• Reduce false positives
• Reports an attack, but no attack underway
• Reduce false negatives
• An attack occurs but IDS fails to report

74
Intrusion Response

• Incident Prevention
• Stop attack before it succeeds
• Measures to detect attacker
• Example Jailing (also Honepots)
• Make attacker think they are succeeding and
  confine to an area
• Intrusion handling
• Preparation for detecting attacks
• Identification of an attack
• Contain attack
• Eradicate attack
• Recover to secure state
• Follow-up to the attack - Punish attacker

75
Containment

• Passive monitoring
• Track intruder actions
• Eases recovery and punishment
• Constraining access
• Downgrade attacker privileges
• Protect sensitive information
• Why not just pull the plug?
• Example Honepots

76
Eradication

• Terminate network connection
• Terminate processes
• Block future attacks
• Close ports
• Disallow specific IP addresses
• Wrappers around attacked applications

77
Follow-Up

• Legal action
• Trace through network
• Cut off resources
• Notify ISP of action
• Counterattack
• Is this a good idea?

78
(No Transcript)
79
Survivability Challenge

• Piecemeal solutions exists for different
  components
• Intrusion detection including real-time
  detection at different architectural layer
• Anomaly detection
• Misuse detection
• Response and recovery
• Vulnerability analysis
• Challenge is to synthesize an integrated,
  cost-based adoptive framework

80
Application Layer

Offline Analysis
system info/ alerts
Business Rule Base Workflow policy
Disruption Detection Response Recovery
(DDRR) (across layers)
Transaction Log
AccessControl
Authentication
Information System Layer

Offline Analysis
DBMS Systems
Response data
Operating Systems/ System Utilities
Audit Log
Access control Policy Base
Authentication
Access Control
Network Layer
Real-time stream mining (Intrusion
Detection) (across layers)
System Support/Backend
Offline Analysis
Network Services
Service Log
Network access Policy Base
Traffic Log
Firewalls
Hubs, Switches Routers
Hubs, Switches Routers
Internet
81
Survivability Framework
82
(No Transcript)
83
Disruption (FaultAttack) Tree

• Root is the ultimate goal
• Each node is associated with the following
  information
• Vulnerability exploits needed to achieve the goal
• Attacker profile indicating different attacker
  expertise levels
• Impact profile indicating directly affected
  objects
• Environmental pre-conditions and post- conditions
• Response strategies
• Vulnerability/fault databases provide some
  information
• Vulnerability exploits
• objects that are affected

84
Disruption Tree
85
Disruption Tree

• Two key quantitative parameters
• Ps(gG) probability of the attacker achieving
  goal g given that the of sub-goals G have been
  achieved
• Tm(gG) propagation time associated with success
  of goal g given that set of sub-goals G have
  been achieved
• Key factors that determine Ps and Tm.
• Attacker expertise level,
• State of the system
• Modeling attacker expertise based on following
  factors
• Resources available (funds, tools, personnel,
  skills, etc.)
• Types of system access (internet access,
  insider/outsider)
• Attacker objective (financial gain, cyber-war,
  etc.)
• Risks that attacker is willing to take
• Time that attacker is willing to spend

86
(No Transcript)