EE579U
Information Systems Security
and Management
2. Policy Structure, Implementation,
and Development
Professor Richard A. Stanley
Spring 2004
© 2000-2004, Richard A. Stanley
EE579U/2 #1
Overview of Today’s Class
•
•
•
•
Administration
Review of last class
Projects
Policies
Spring 2004
© 2000-2004, Richard A. Stanley
EE579U/2 #2
Review of Last Class
• Information security is a real need in real
systems
• There are multitudes of examples of
systems that failed due to poor security, and
which cost their owners dearly
– In some cases, security failures have led to
business failures
• Absolute security does not exist
Spring 2004
© 2000-2004, Richard A. Stanley
EE579U/2 #3
Projects?
•
•
•
•
Proposals?
Teams?
Topics?
Issues?
Spring 2004
© 2000-2004, Richard A. Stanley
EE579U/2 #4
Policy
• What’s the big deal?
– Need to define acceptable usage and the parameters of
that usage
– If it is to work, must be within the boundaries of a
model
• If users are to follow the policy, they need to know
what it is
– Reasonable
– Available
– Understandable
Spring 2004
© 2000-2004, Richard A. Stanley
EE579U/2 #5
Policy Models
• We covered these in Computer Security
• Let’s review a few of them and see how
well they might be suited to developing a
policy for our users
• Policy infers an access control mechanism
in place and operating
– Technological solutions?
Spring 2004
© 2000-2004, Richard A. Stanley
EE579U/2 #6
Access Control
• Determines and monitors who can do what
with what in the computer
• Is much more than establishing a physical
perimeter around the computer
• Can’t happen without identification and
authentication (about which, more later)
• Needs to be instantiated in a policy
Spring 2004
© 2000-2004, Richard A. Stanley
EE579U/2 #7
Access Control Model
Subject
Request
Reference
Monitor
Object
Any of these points is a vulnerability. How to protect?
Spring 2004
© 2000-2004, Richard A. Stanley
EE579U/2 #8
Reference Monitor
• Makes access control work
• You can tell it
– What a subject is allowed to do (privilege)
– What may be done with an object (permission)
• In order to specify these things, you need to
know all the possibilities, or you need to
define things narrowly so that what you
don't know doesn’t become allowed
Spring 2004
© 2000-2004, Richard A. Stanley
EE579U/2 #9
Unix Access Control
•
•
•
•
Read: read a file
Write: write to a file
Execute: execute a file
Interpreted according to where the access
rights are to be granted
Spring 2004
© 2000-2004, Richard A. Stanley
EE579U/2 #10
Bell-LaPadula Access Rights
•
•
•
•
e: execute
r: read
a: append
w: write
• BLP developed a methodology to
implement an access control policy!
Spring 2004
© 2000-2004, Richard A. Stanley
EE579U/2 #11
Access Control Types
• Discretionary: the file owner is in charge
• Mandatory: the system policy is in charge
• One can exist within the other, especially
discretionary within a class of mandatory
Spring 2004
© 2000-2004, Richard A. Stanley
EE579U/2 #12
Access Control Matrix
• A = set of access operations permitted
• S = set of subjects
• O = set of objects
M  M so
Spring 2004
© 2000-2004, Richard A. Stanley
sS ,o O , M so  A
EE579U/2 #13
Access Control Matrix Example
Bill
Alice
Bill.doc
r,w
Edit.exe
e
e
Fun.com
e,r,w
e,r
How easy is this to implement?
Spring 2004
© 2000-2004, Richard A. Stanley
EE579U/2 #14
Access Control Lists
• Stores the access rights within the object
– Columnar decomposition of the matrix
• Convenient, quick
– This is the Unix approach
• Difficult to modify globally w.r.t. subjects,
easy w.r.t. the object
• How to find out what a subject is able to
do?
Spring 2004
© 2000-2004, Richard A. Stanley
EE579U/2 #15
Security Levels
• Linear
–
–
–
–
Top secret
Secret
Confidential
Unclassified
• Lattice
– Security level
– Compartment
Spring 2004
© 2000-2004, Richard A. Stanley
EE579U/2 #16
Security Level Examples
• Linear
– Marking contains the name of the level
– Each higher level dominates those below it
• Lattice
– Marking contains name of level + name of
compartment (e.g. TOP SECRET PETUNIA)
– Only those “read into” the compartment can
read the information in that compartment, and
then only at the level of their overall access
Spring 2004
© 2000-2004, Richard A. Stanley
EE579U/2 #17
Who Can Read What?
• In a linear system?
• In a lattice system?
• What is dominance?
Spring 2004
© 2000-2004, Richard A. Stanley
EE579U/2 #18
System High/Low
• System High is the highest security level in the
system. It can be thought of the apex of all lattice
levels
• System Low is the lowest security level in the
system. It can be thought of as that level which all
system users can “see”
• Question?
– In a Unix system, what level should be assigned to the
root directory?
Spring 2004
© 2000-2004, Richard A. Stanley
EE579U/2 #19
Security Model Types
• Formal (high-assurance computing)
– Bell-LaPadula
– Biba
– Chinese Wall
• Informal (policy description)
– Clark-Wilson
Spring 2004
© 2000-2004, Richard A. Stanley
EE579U/2 #20
State Machines
• BLP: security = property of states
• State is an instantaneous representation of the
system at an instant in time
• State transition occurs when the state changes
• State transitions may be constrained
• With a 1000 MHz processor, what is the likely rate
of state change?
• What are the chances that you can capture all the
states of even a desktop computer? Why?
Spring 2004
© 2000-2004, Richard A. Stanley
EE579U/2 #21
Bell-LaPadula
• Is a state machine model
• Utilizes the machine state to check security
– All permissions must be captured
– All subjects accessing objects must be captured
– These are machine states
• Complicated state set results
• Defining state set is the major BLP problem
Spring 2004
© 2000-2004, Richard A. Stanley
EE579U/2 #22
Access Control Model
We have seen this before, and we will see it again
Subject
Request
Reference
Monitor
Object
The Reference Monitor validates all requests
against permitted state functions
Spring 2004
© 2000-2004, Richard A. Stanley
EE579U/2 #23
BLP Security Policies
• Mandatory security policies
• Simple security (ss) policy (no read up)
• Star (*) policy (no write down)
– How to send messages from high to low?
– Trusted subjects can violate policy
• Discretionary (ds) policy
• If all three properties are satisfied, a state is
secure
Spring 2004
© 2000-2004, Richard A. Stanley
EE579U/2 #24
Basic Security Theorem
• A state transition is secure if both the initial
and the final states are secure, so
• If all state transitions are secure and the
initial system state is secure, then every
subsequent state will also be secure,
regardless of which inputs occur. (Proof)
Spring 2004
© 2000-2004, Richard A. Stanley
EE579U/2 #25
BLP Advantages
• Descriptive capabilities of the model
• Policies based on security levels -- easy to
introduce other structures in their place
• Actual security policies
• Specific solution (e.g. Multics)
Spring 2004
© 2000-2004, Richard A. Stanley
EE579U/2 #26
BLP Disadvantages
• Deals only with confidentiality, not integrity
• Does not address management of access
control
• Contains covert channels
Spring 2004
© 2000-2004, Richard A. Stanley
EE579U/2 #27
Covert Channel
• An information flow that is not controlled
by a security mechanism
• Can occur by allowing low-level subjects to
see names, results of comparisons, etc. of
high-level objects
• Difficult to find, difficult to control, critical
to success
Spring 2004
© 2000-2004, Richard A. Stanley
EE579U/2 #28
Harrison-Ruzzo-Ullman Model
• Deals with BLP lack of procedures to change
access rights
• Uses a structured programming approach to
modify the access control matrix
• Provides a view of complex systems modeled by
complex models
• The more complex a security model is, the more
difficult it usually is to verify security properties
Spring 2004
© 2000-2004, Richard A. Stanley
EE579U/2 #29
Other Models
• Chinese Wall
– Prevent conflicts of interest
• Biba
– Address integrity with static/dynamic levels
• Clark-Wilson
– Commercial focus on data integrity
• Information flow
– Close covert channels
Spring 2004
© 2000-2004, Richard A. Stanley
EE579U/2 #30
So What?
• These models all seek to provide a
framework within which to implement a
policy
• Without such a framework, it will be
difficult to impossible to establish a policy
that works, or to measure the performance
of the policy
– This is called a security audit
Spring 2004
© 2000-2004, Richard A. Stanley
EE579U/2 #31
How to Deal With These Issues?
• Policy
– Guides the organization in security posture
– Provides the benchmark against which
activities can be measured
• Auditing
– Attempts to measure success in complying with
policy
– Provides evidence of security success, failure
Spring 2004
© 2000-2004, Richard A. Stanley
EE579U/2 #32
Why Policy?
• Why laws?
• Without policy, everything is permitted, as
nothing is forbidden
– You may think this will work for you, to
“enforce” on an ad hoc basis, but exactly what
will you enforce?
Spring 2004
© 2000-2004, Richard A. Stanley
EE579U/2 #33
Policy Starts with Objectives
and Risk Assessment
 Security objectives and how risks and
vulnerabilities affect achieving them
 Threats to information systems
How to
 Risk analysis
measure?
 Vulnerability assessment
Spring 2004
© 2000-2004, Richard A. Stanley
EE579U/2 #34
Layering
• Just as with protocols, policy should be
layered from top to bottom
– Start with broad high-level objectives at the
corporate level
– Work down to department or section policies,
which should be much more detailed -- almost a
checklist approach
Spring 2004
© 2000-2004, Richard A. Stanley
EE579U/2 #35
Effective Policy Considerations
 Identify the key components of a policy that’s right for your
system
 Threat reduction techniques and their application to policy
 Identify responsibilities for security actions
 Determine appropriate and consistent countermeasures
 Incident detection and management
 Damage control and recovery
 some examples, good and bad, taken from the 9/11 attacks
 Choose appropriate tools to assist in policy development and
management
 Policy management and maintaining currency
 Get and keep staff support for the policy
Spring 2004
© 2000-2004, Richard A. Stanley
EE579U/2 #36
How to Get Started?
• Creating a policy is hard, continuous work
• There is no shortage of vendors who sell
policy templates and tools
– These may be useful
– As with any tool, using these requires a
knowledge of the goals and objectives to be
achieved by using the tool
– Simply buying a policy does not make it work
Spring 2004
© 2000-2004, Richard A. Stanley
EE579U/2 #37
Some Examples
Spring 2004
© 2000-2004, Richard A. Stanley
EE579U/2 #38
What Might Be In a Policy?
Source: http://www.tekcentral.com/teknetwork/Policies_and_Procedures/Security_Policy/
Spring 2004
© 2000-2004, Richard A. Stanley
EE579U/2 #39
Another View from the
SANS Institute –1
• 1. Introduction
• 1.1.1General Information
1.1.2 Objectives
– 1.2 Responsible Organizational Structure
• 1.2.1.1.1 Corporate Information Services
1.2.1.1.2 Business Unit Information Services
1.2.1.1.3 International Organizations
1.2.1.1.4 Tenants
• 1.2.2 Security Standards
– 1.2.2.1.1 Confidentiality
1.2.2.1.2 Integrity
1.2.2.1.3 Authorization
1.2.2.1.4 Access
1.2.2.1.5 Appropriate Use
1.2.2.1.6 Employee Privacy
http://secinf.net/policy_and_standards/What_Do_I_Put_in_a_Security_Policy_.html
Spring 2004
© 2000-2004, Richard A. Stanley
EE579U/2 #40
Another View from the
SANS Institute – 2
• 2. Domain Services
– 2.1.1 Authentication
2.1.2 Password Standards
2.1.3 Resident Personnel Departure
• 2.1.3.1.1 Friendly Terms
2.1.3.1.2 Unfriendly Terms
• 3. Email Systems
• 3.1.1 Authentication
3.1.2 Intrusion Protection
3.1.3 Physical Access
3.1.4 Backups
3.1.5 Retention Policy
3.1.6 Auditing
http://secinf.net/policy_and_standards/What_Do_I_Put_in_a_Security_Policy_.html
Spring 2004
© 2000-2004, Richard A. Stanley
EE579U/2 #41
Another View from the
SANS Institute – 3
• 4. Web Servers
– 4.1.1 Internal
4.1.2 External
• 5. Data Center
– 5.1.1 Authentication
5.1.2 Intrusion Protection
5.1.3 Physical Access
5.1.4 Backups
5.1.5 Retention Policy
5.1.6 Auditing
5.1.7 Disaster Recovery
http://secinf.net/policy_and_standards/What_Do_I_Put_in_a_Security_Policy_.html
Spring 2004
© 2000-2004, Richard A. Stanley
EE579U/2 #42
Another View from the
SANS Institute – 4
• 6. LAN/WAN
– 6.1.1 Authentication
6.1.2 Intrusion Protection
6.1.3 Physical Access
• 6.1.3.1.1 Modems
6.1.3.1.2 Dial-in Access
6.1.3.1.3 Dial-out
– 6.1.4 Backups
6.1.5 Retention Policy
6.1.6 Content Filtering
6.1.7 Auditing
6.1.8 Disaster Recovery
• 6.1.8.1.1 Network Operations Center
6.1.8.1.2 Physical Network Layer
http://secinf.net/policy_and_standards/What_Do_I_Put_in_a_Security_Policy_.html
Spring 2004
© 2000-2004, Richard A. Stanley
EE579U/2 #43
Another View from the
SANS Institute – 5
• 7. Desktop Systems
– 7.1.1 Authentication
7.1.2 Intrusion Protection
7.1.3 Physical Access
7.1.4 Backups
7.1.5 Auditing
7.1.6 Disaster Recovery
• 8. Telecommunication Systems
– 8.1.1 Authentication
8.1.2 Intrusion Protection
8.1.3 Physical Access
8.1.4 Auditing
8.1.5 Backups
8.1.6 Retention Policy
8.1.7 Disaster Recovery
http://secinf.net/policy_and_standards/What_Do_I_Put_in_a_Security_Policy_.html
Spring 2004
© 2000-2004, Richard A. Stanley
EE579U/2 #44
Another View from the
SANS Institute – 6
• 9. Strategic Servers
– 9.1.1 Authentication
9.1.2 Intrusion Protection
9.1.3 Physical Access
9.1.4 Backups
9.1.5 Retention Policy
9.1.6 Auditing
9.1.7 Disaster Recovery
• 10. Legacy Systems
– 10.1.1 Authentication
• 10.1.1.1.1 Password Standards
– 10.1.2 Intrusion Protection
10.1.3 Physical Access
10.1.4 Backups
10.1.5 Retention Policy
10.1.6 Auditing
10.1.7 Disaster Recovery
http://secinf.net/policy_and_standards/What_Do_I_Put_in_a_Security_Policy_.html
Spring 2004
© 2000-2004, Richard A. Stanley
EE579U/2 #45
Another View from the
SANS Institute – 7
• 11. Security Services and Procedures
• 11.1 Auditing
11.2 Monitoring
• 12. Security Incident Handling
– 12.1 Preparing and Planning for Incident Handling
12.2 Notification and Points of Contact
12.3 Identifying an Incident
12.4 Handling an Incident
12.5 Aftermath of an Incident
12.6 Forensics and Legal Implications
12.7 Public Relations Contacts
12.8 Key Steps
• 12.8.1.1.1 Containment
12.8.1.1.2 Eradication
12.8.1.1.3 Recovery
12.8.1.1.4 Follow-Up
12.8.1.1.5 Aftermath / Lessons Learned
– 12.9 Responsibilities
http://secinf.net/policy_and_standards/What_Do_I_Put_in_a_Security_Policy_.html
Spring 2004
© 2000-2004, Richard A. Stanley
EE579U/2 #46
Another View from the
SANS Institute – 8
• 13. Ongoing Activities
– 13.1.1 Incident Warnings
– 13.1.1.1.1 Virus warnings
13.1.1.1.2 Intrusion Vulnerabilities
13.1.1.1.3 Security Patches
• 14. Contacts, Mailing Lists and Other
Resources
• 15. References
http://secinf.net/policy_and_standards/What_Do_I_Put_in_a_Security_Policy_.html
Spring 2004
© 2000-2004, Richard A. Stanley
EE579U/2 #47
Yet Another Approach
Source: http://www.cs.rmit.edu.au/rules/computer-security.shtml
Spring 2004
© 2000-2004, Richard A. Stanley
EE579U/2 #48
Is That All?
• Probably not
• Should one person produce the policy?
• Where is the policy about configuring the
system elements?
– Operating system settings
– Audit and logging procedures
– …etc.
• Help is available, and often for free!
Spring 2004
© 2000-2004, Richard A. Stanley
EE579U/2 #49
Another Source: the NSA!
Source: http://www.nsa.gov/snac/index.html
Spring 2004
© 2000-2004, Richard A. Stanley
EE579U/2 #50
What’s In the Guides?
Spring 2004
© 2000-2004, Richard A. Stanley
EE579U/2 #51
But Wait, There’s More!
Spring 2004
© 2000-2004, Richard A. Stanley
EE579U/2 #52
More to Think About
• Other resources for policy help
– Search the Web, look at other’s approach to the
policy issue
– Look at the Web sites of your vendors for
suggestions and updates
– Free guides, e.g. http://www.stuhenderson.com/howpolcy.html
• Start small, and build incrementally
– A manageable policy that is understood is better
than a comprehensive one that is ignored
Spring 2004
© 2000-2004, Richard A. Stanley
EE579U/2 #53
Now What?
• Policy is essential, but how do you know if
it is working, and how well?
• You need to do an audit
–
–
–
–
Not a once in a lifetime event
Need to be regular, but aperiodic
Follow the financial industry guidelines
May want to follow standards
Spring 2004
© 2000-2004, Richard A. Stanley
EE579U/2 #54
Summary
• A security policy is essential to a security
posture in any information system
• Policies cannot be ad hoc if they are to be
effective; they must be written, sensible,
enforcable, and evaluated
• Enforcement must be part of the policy
• Regular audits must be undertaken to ensure
the effectiveness of the policy and to
identify needs for change and updates.
Spring 2004
© 2000-2004, Richard A. Stanley
EE579U/2 #55
Homework
• Using either your own company network or
a network with which you are familiar, and
without disclosing confidential information,
provide an outline of a policy that either
exists or that you would implement based
on the discussions in class. Describe the
measures in your policy that you believe to
be most critical, and how you would
implement them and obtain staff support.
Spring 2004
© 2000-2004, Richard A. Stanley
EE579U/2 #56