Presentation is loading. Please wait.

Presentation is loading. Please wait.

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

Similar presentations


Presentation on theme: "EE579U/3 #1 Spring 2004 © 2000-2004, Richard A. Stanley EE579U Information Systems Security and Management 3. Policy Examples and Development Professor."— Presentation transcript:

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

2 EE579U/3 #2 Spring 2004 © 2000-2004, Richard A. Stanley Overview of Today’s Class Review of last class Projects Policy Examples and Development

3 EE579U/3 #3 Spring 2004 © 2000-2004, Richard A. Stanley Projects? Proposals due today Teams? Topics? Issues?

4 EE579U/3 #4 Spring 2004 © 2000-2004, Richard A. Stanley Review of Last Class 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, enforceable, 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.

5 EE579U/3 #5 Spring 2004 © 2000-2004, Richard A. Stanley Example Policies We covered some examples last week. Let’s refresh our memories

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

7 EE579U/3 #7 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

8 EE579U/3 #8 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

9 EE579U/3 #9 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

10 EE579U/3 #10 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

11 EE579U/3 #11 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

12 EE579U/3 #12 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

13 EE579U/3 #13 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

14 EE579U/3 #14 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

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

16 EE579U/3 #16 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!

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

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

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

20 EE579U/3 #20 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

21 EE579U/3 #21 Spring 2004 © 2000-2004, Richard A. Stanley Some Real Policies Univ. of Toronto Network Security Policy SDSC Security Policy HP Policy Solution Guide UC Berkley CISC Policy Univ. of Colorado Security Policy House of Representatives Security Policy

22 EE579U/3 #22 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

23 EE579U/3 #23 Spring 2004 © 2000-2004, Richard A. Stanley Audit Types and Purposes  Types of audits  Global security audits  Verification audits  Compliance audits  Intrusive audits, or “Tiger Teams”  Who should perform?  Internal audit staff  Audit performed by a trusted outside party  Accredited external audit team

24 EE579U/3 #24 Spring 2004 © 2000-2004, Richard A. Stanley Planning an Audit: 1  Policy review and analysis Choosing the methodology and time frame to use for the audit Obtaining senior management approval and consent for the level of the audit and the auditors Contract Legal liabilities Rules of conduct, including forbidden areas Data collection planning Scope of work to be undertaken (e.g., how extensive an audit is to be performed?) Managing expectations Dealing with problems (e.g., what if no issues are found in the allotted time?)

25 EE579U/3 #25 Spring 2004 © 2000-2004, Richard A. Stanley Planning an Audit: 2  Comparing the system described in the policy to the system that actually exists  How to find the differences  What to do about them?  How will they affect the audit?  The final audit plan  Approval

26 EE579U/3 #26 Spring 2004 © 2000-2004, Richard A. Stanley Conducting an Audit: 1  Obtain information about the system to be audited  Policy analysis  Actual system scans and evaluations  Collect and protect audit data  Work methodically and professionally at all times  Tools available to help in the audit  Develop and adhere to the data collection plan (e.g., take screen shots)  Keep the customer informed  Reports as agreed in the plan  Immediate reporting if something big is found  The customer’s ability to fix the problem exceeds the auditor’s need to crow about finding it  Keep findings confidential  Don’t leap to conclusions

27 EE579U/3 #27 Spring 2004 © 2000-2004, Richard A. Stanley Conducting an Audit: 2  Follow-up / retesting  Prepare the audit report  Executive summary  Vulnerabilities and/or problems found  Several small things can add up to a large problem  Business impact  Recommendations

28 EE579U/3 #28 Spring 2004 © 2000-2004, Richard A. Stanley Evaluating Audit Results  Assess the severity of the findings  Depends on the organizational security policy and business model  Deciding if external help is needed to deal with the findings (e.g., are we able to understand and deal with the findings?)  Do the findings corroborate the perceived threats?  Is a change to the security policy needed?  Does this warrant another audit before proceeding further?  Rank problems: what to fix first; where to stop?  Match vulnerabilities and problems to legal liability issues  Determine if further, perhaps more extensive auditing is warranted  Evaluate what, if any changes to security policy are warranted based on findings

29 EE579U/3 #29 Spring 2004 © 2000-2004, Richard A. Stanley Dealing With Problems: 1  Workstation problems  Physical access controls  Environmental controls  Object controls  Data validation and auditing  Data file controls  Output controls  Performance

30 EE579U/3 #30 Spring 2004 © 2000-2004, Richard A. Stanley Dealing With Problems: 2  Software problems  Licensing issues  Version and configuration control  Update control  Business continuity problems  Disaster events and probabilities  Alternative sites  Testing business continuity plan

31 EE579U/3 #31 Spring 2004 © 2000-2004, Richard A. Stanley Audit Standards & Tools  ISO 17799  Good starting point for policies and audits  Compliance not trivial  Agreed-upon international standard  COBRA tool automates compliance checking  COBIT (Control Objectives for Information and related Technology)  Generally accepted IT control objectives  Developed and recognized by the ISACA (Information Systems Audit and Control Association), the international IT auditors’ professional organization  Includes audit guidelines  Developing your own standards

32 EE579U/3 #32 Spring 2004 © 2000-2004, Richard A. Stanley ISO 17799 Overview Business Continuity Planning System Access Control System Development and Maintenance Physical and Environmental Security Compliance Personnel Security Security Organization Computer & Network Management Asset Classification and Control Security Policy

33 EE579U/3 #33 Spring 2004 © 2000-2004, Richard A. Stanley Audit Review Necessary element to ensure compliance with security policies Many approaches to performing Standards-based approach has merit, but requires rigorous compliance Recent financial escapades illustrate the need for frequent, thorough system audits

34 EE579U/3 #34 Spring 2004 © 2000-2004, Richard A. Stanley Summary Policy development is hard work, requiring detailed knowledge of both the system and the risks and threats Audits are essential to ensuring that policy is achieved The “just say no” approach is not a viable policy

35 EE579U/3 #35 Spring 2004 © 2000-2004, Richard A. Stanley Homework Reading: –Bishop, Chapters 18 & 19 Problem: –Identify a security policy problem in literature or from your own experience. Describe the problem, the consequences resulting from it and what was done to mitigate or repair it. What would you have done if you had the power to prevent or mitigate this event?


Download ppt "EE579U/3 #1 Spring 2004 © 2000-2004, Richard A. Stanley EE579U Information Systems Security and Management 3. Policy Examples and Development Professor."

Similar presentations


Ads by Google