EE579U/2 #1 Spring 2004 © 2000-2004, Richard A. Stanley EE579U Information Systems Security and Management 2. Policy Structure, Implementation, and Development.

Spring 2004© 2000-2004, Richard A. Stanley

EE579U/2 #1

EE579UInformation Systems Security

and Management2. Policy Structure, Implementation,

and Development

Professor Richard A. Stanley


EE579U/2 #2

Overview of Today’s Class

• Administration

• Review of last class

• Projects

• Policies


EE579U/2 #3

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


EE579U/2 #4

Projects?

• Proposals?

• Teams?

• Topics?

• Issues?


EE579U/2 #5

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


EE579U/2 #6

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?


EE579U/2 #7

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


EE579U/2 #8

Access Control Model

Subject RequestReferenceMonitor Object

Any of these points is a vulnerability. How to protect?


EE579U/2 #9

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


EE579U/2 #10

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


EE579U/2 #11

Bell-LaPadula Access Rights

• e: execute• r: read• a: append• w: write

• BLP developed a methodology to implement an access control policy!


EE579U/2 #12

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


EE579U/2 #13

Access Control Matrix

• A = set of access operations permitted• S = set of subjects• O = set of objects

M M so s S o O M Aso

, ,


EE579U/2 #14

Access Control Matrix Example

Bill.doc Edit.exe Fun.comBill r,w e e,r,wAlice e e,r

How easy is this to implement?


EE579U/2 #15

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?


EE579U/2 #16

Security Levels• Linear

– Top secret– Secret– Confidential– Unclassified

• Lattice– Security level– Compartment


EE579U/2 #17

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


EE579U/2 #18

Who Can Read What?

• In a linear system?

• In a lattice system?

• What is dominance?


EE579U/2 #19

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?


EE579U/2 #20

Security Model Types

• Formal (high-assurance computing)– Bell-LaPadula– Biba– Chinese Wall

• Informal (policy description)– Clark-Wilson


EE579U/2 #21

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?


EE579U/2 #22

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


EE579U/2 #23

Access Control Model

Subject RequestReferenceMonitor Object

The Reference Monitor validates all requestsagainst permitted state functions

We have seen this before, and we will see it again


EE579U/2 #24

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


EE579U/2 #25

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)


EE579U/2 #26

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)


EE579U/2 #27

BLP Disadvantages

• Deals only with confidentiality, not integrity

• Does not address management of access control

• Contains covert channels


EE579U/2 #28

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


EE579U/2 #29

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


EE579U/2 #30

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


EE579U/2 #31

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


EE579U/2 #32

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


EE579U/2 #33

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?


EE579U/2 #34

Policy Starts with Objectives and Risk Assessment

Security objectives and how risks and vulnerabilities affect achieving them

Threats to information systems Risk analysis Vulnerability assessment

How to measure?


EE579U/2 #35

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


EE579U/2 #36

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


EE579U/2 #37

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


EE579U/2 #38

Some Examples


EE579U/2 #39

What Might Be In a Policy?

Source: http://www.tekcentral.com/teknetwork/Policies_and_Procedures/Security_Policy/


EE579U/2 #40

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 Services1.2.1.1.3 International Organizations1.2.1.1.4 Tenants

• 1.2.2 Security Standards– 1.2.2.1.1 Confidentiality

1.2.2.1.2 Integrity1.2.2.1.3 Authorization1.2.2.1.4 Access1.2.2.1.5 Appropriate Use1.2.2.1.6 Employee Privacy

http://secinf.net/policy_and_standards/What_Do_I_Put_in_a_Security_Policy_.html


EE579U/2 #41

Another View from the SANS Institute – 2

• 2. Domain Services– 2.1.1 Authentication

2.1.2 Password Standards2.1.3 Resident Personnel Departure

• 2.1.3.1.1 Friendly Terms2.1.3.1.2 Unfriendly Terms

• 3. Email Systems• 3.1.1 Authentication

3.1.2 Intrusion Protection3.1.3 Physical Access3.1.4 Backups3.1.5 Retention Policy3.1.6 Auditing



EE579U/2 #42


• 4. Web Servers– 4.1.1 Internal

4.1.2 External

• 5. Data Center– 5.1.1 Authentication

5.1.2 Intrusion Protection5.1.3 Physical Access5.1.4 Backups5.1.5 Retention Policy5.1.6 Auditing5.1.7 Disaster Recovery



EE579U/2 #43


• 6. LAN/WAN– 6.1.1 Authentication

6.1.2 Intrusion Protection6.1.3 Physical Access

• 6.1.3.1.1 Modems6.1.3.1.2 Dial-in Access6.1.3.1.3 Dial-out

– 6.1.4 Backups6.1.5 Retention Policy6.1.6 Content Filtering6.1.7 Auditing6.1.8 Disaster Recovery

• 6.1.8.1.1 Network Operations Center6.1.8.1.2 Physical Network Layer



EE579U/2 #44


• 7. Desktop Systems– 7.1.1 Authentication

7.1.2 Intrusion Protection7.1.3 Physical Access7.1.4 Backups7.1.5 Auditing7.1.6 Disaster Recovery

• 8. Telecommunication Systems– 8.1.1 Authentication

8.1.2 Intrusion Protection8.1.3 Physical Access8.1.4 Auditing8.1.5 Backups8.1.6 Retention Policy8.1.7 Disaster Recovery



EE579U/2 #45


• 9. Strategic Servers– 9.1.1 Authentication

9.1.2 Intrusion Protection9.1.3 Physical Access9.1.4 Backups9.1.5 Retention Policy9.1.6 Auditing9.1.7 Disaster Recovery

• 10. Legacy Systems– 10.1.1 Authentication

• 10.1.1.1.1 Password Standards

– 10.1.2 Intrusion Protection10.1.3 Physical Access10.1.4 Backups10.1.5 Retention Policy10.1.6 Auditing10.1.7 Disaster Recovery



EE579U/2 #46


• 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 Contact12.3 Identifying an Incident12.4 Handling an Incident12.5 Aftermath of an Incident12.6 Forensics and Legal Implications12.7 Public Relations Contacts12.8 Key Steps

• 12.8.1.1.1 Containment12.8.1.1.2 Eradication12.8.1.1.3 Recovery12.8.1.1.4 Follow-Up12.8.1.1.5 Aftermath / Lessons Learned

– 12.9 Responsibilities



EE579U/2 #47


• 13. Ongoing Activities– 13.1.1 Incident Warnings

– 13.1.1.1.1 Virus warnings13.1.1.1.2 Intrusion Vulnerabilities13.1.1.1.3 Security Patches

• 14. Contacts, Mailing Lists and Other Resources

• 15. Referenceshttp://secinf.net/policy_and_standards/What_Do_I_Put_in_a_Security_Policy_.html


EE579U/2 #48

Yet Another Approach

Source: http://www.cs.rmit.edu.au/rules/computer-security.shtml


EE579U/2 #49

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!


EE579U/2 #50

Another Source: the NSA!

Source: http://www.nsa.gov/snac/index.html


EE579U/2 #51

What’s In the Guides?


EE579U/2 #52

But Wait, There’s More!


EE579U/2 #53

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


EE579U/2 #54

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


EE579U/2 #55

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.


EE579U/2 #56

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.

EE579U/2 #1 Spring 2004 © 2000-2004, Richard A. Stanley EE579U Information Systems Security and Management 2. Policy Structure, Implementation, and Development.

Documents

stanley slide

policy slide

access control policy

stanley unix access

stanley review

stanley projects

stanley policy whats

stanley policy models