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

2. EE579U/2 #2 Spring 2004 © 2000-2004, Richard A. Stanley Overview of Today’s Class Administration Review of last class Projects Policies

3. EE579U/2 #3 Spring 2004 © 2000-2004, Richard A. Stanley 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

4. EE579U/2 #4 Spring 2004 © 2000-2004, Richard A. Stanley Projects? Proposals? Teams? Topics? Issues?

5. EE579U/2 #5 Spring 2004 © 2000-2004, Richard A. Stanley 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

6. EE579U/2 #6 Spring 2004 © 2000-2004, Richard A. Stanley 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?

7. EE579U/2 #7 Spring 2004 © 2000-2004, Richard A. Stanley 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

8. EE579U/2 #8 Spring 2004 © 2000-2004, Richard A. Stanley Access Control Model SubjectRequest Reference Monitor Object Any of these points is a vulnerability. How to protect?

9. EE579U/2 #9 Spring 2004 © 2000-2004, Richard A. Stanley 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

10. EE579U/2 #10 Spring 2004 © 2000-2004, Richard A. Stanley 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

11. EE579U/2 #11 Spring 2004 © 2000-2004, Richard A. Stanley Bell-LaPadula Access Rights e: execute r: read a: append w: write BLP developed a methodology to implement an access control policy!

12. EE579U/2 #12 Spring 2004 © 2000-2004, Richard A. Stanley 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

13. EE579U/2 #13 Spring 2004 © 2000-2004, Richard A. Stanley Access Control Matrix A = set of access operations permitted S = set of subjects O = set of objects

14. EE579U/2 #14 Spring 2004 © 2000-2004, Richard A. Stanley Access Control Matrix Example How easy is this to implement?

15. EE579U/2 #15 Spring 2004 © 2000-2004, Richard A. Stanley 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?

16. EE579U/2 #16 Spring 2004 © 2000-2004, Richard A. Stanley Security Levels Linear –Top secret –Secret –Confidential –Unclassified Lattice –Security level –Compartment

17. EE579U/2 #17 Spring 2004 © 2000-2004, Richard A. Stanley 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

18. EE579U/2 #18 Spring 2004 © 2000-2004, Richard A. Stanley Who Can Read What? In a linear system? In a lattice system? What is dominance?

19. EE579U/2 #19 Spring 2004 © 2000-2004, Richard A. Stanley 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?

20. EE579U/2 #20 Spring 2004 © 2000-2004, Richard A. Stanley Security Model Types Formal (high-assurance computing) –Bell-LaPadula –Biba –Chinese Wall Informal (policy description) –Clark-Wilson

21. EE579U/2 #21 Spring 2004 © 2000-2004, Richard A. Stanley 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?

22. EE579U/2 #22 Spring 2004 © 2000-2004, Richard A. Stanley 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

23. EE579U/2 #23 Spring 2004 © 2000-2004, Richard A. Stanley Access Control Model SubjectRequest Reference Monitor Object The Reference Monitor validates all requests against permitted state functions We have seen this before, and we will see it again

24. EE579U/2 #24 Spring 2004 © 2000-2004, Richard A. Stanley 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

25. EE579U/2 #25 Spring 2004 © 2000-2004, Richard A. Stanley 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)

26. EE579U/2 #26 Spring 2004 © 2000-2004, Richard A. Stanley 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)

27. EE579U/2 #27 Spring 2004 © 2000-2004, Richard A. Stanley BLP Disadvantages Deals only with confidentiality, not integrity Does not address management of access control Contains covert channels

28. EE579U/2 #28 Spring 2004 © 2000-2004, Richard A. Stanley 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

29. EE579U/2 #29 Spring 2004 © 2000-2004, Richard A. Stanley 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

30. EE579U/2 #30 Spring 2004 © 2000-2004, Richard A. Stanley 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

31. EE579U/2 #31 Spring 2004 © 2000-2004, Richard A. Stanley 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

32. EE579U/2 #32 Spring 2004 © 2000-2004, Richard A. Stanley 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

33. EE579U/2 #33 Spring 2004 © 2000-2004, Richard A. Stanley 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?

34. EE579U/2 #34 Spring 2004 © 2000-2004, Richard A. Stanley 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?

35. EE579U/2 #35 Spring 2004 © 2000-2004, Richard A. Stanley 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

36. EE579U/2 #36 Spring 2004 © 2000-2004, Richard A. Stanley 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

37. EE579U/2 #37 Spring 2004 © 2000-2004, Richard A. Stanley 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

38. EE579U/2 #38 Spring 2004 © 2000-2004, Richard A. Stanley Some Examples

39. EE579U/2 #39 Spring 2004 © 2000-2004, Richard A. Stanley What Might Be In a Policy? Source: http://www.tekcentral.com/teknetwork/Policies_and_Procedures/Security_Policy/

40. EE579U/2 #40 Spring 2004 © 2000-2004, Richard A. Stanley 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

41. EE579U/2 #41 Spring 2004 © 2000-2004, Richard A. Stanley 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

42. EE579U/2 #42 Spring 2004 © 2000-2004, Richard A. Stanley 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

43. EE579U/2 #43 Spring 2004 © 2000-2004, Richard A. Stanley 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

44. EE579U/2 #44 Spring 2004 © 2000-2004, Richard A. Stanley 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

45. EE579U/2 #45 Spring 2004 © 2000-2004, Richard A. Stanley 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

46. EE579U/2 #46 Spring 2004 © 2000-2004, Richard A. Stanley 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

47. EE579U/2 #47 Spring 2004 © 2000-2004, Richard A. Stanley 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

48. EE579U/2 #48 Spring 2004 © 2000-2004, Richard A. Stanley Yet Another Approach Source: http://www.cs.rmit.edu.au/rules/computer-security.shtml

49. EE579U/2 #49 Spring 2004 © 2000-2004, Richard A. Stanley 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!

50. EE579U/2 #50 Spring 2004 © 2000-2004, Richard A. Stanley Another Source: the NSA! Source: http://www.nsa.gov/snac/index.html

51. EE579U/2 #51 Spring 2004 © 2000-2004, Richard A. Stanley What’s In the Guides?

52. EE579U/2 #52 Spring 2004 © 2000-2004, Richard A. Stanley But Wait, There’s More!

53. EE579U/2 #53 Spring 2004 © 2000-2004, Richard A. Stanley 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

54. EE579U/2 #54 Spring 2004 © 2000-2004, Richard A. Stanley 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

55. EE579U/2 #55 Spring 2004 © 2000-2004, Richard A. Stanley 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.

56. EE579U/2 #56 Spring 2004 © 2000-2004, Richard A. Stanley 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.