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

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

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

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

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

EE579U/3 #6 Spring 2004 © , Richard A. Stanley What Might Be In a Policy? Source:

EE579U/3 #7 Spring 2004 © , Richard A. Stanley Another View from the SANS Institute –1 1. Introduction 1.1.1General Information Objectives –1.2 Responsible Organizational Structure Corporate Information Services Business Unit Information Services International Organizations Tenants Security Standards – Confidentiality Integrity Authorization Access Appropriate Use Employee Privacy

EE579U/3 #8 Spring 2004 © , Richard A. Stanley Another View from the SANS Institute – 2 2. Domain Services –2.1.1 Authentication Password Standards Resident Personnel Departure Friendly Terms Unfriendly Terms 3. Systems Authentication Intrusion Protection Physical Access Backups Retention Policy Auditing

EE579U/3 #9 Spring 2004 © , Richard A. Stanley Another View from the SANS Institute – 3 4. Web Servers –4.1.1 Internal External 5. Data Center –5.1.1 Authentication Intrusion Protection Physical Access Backups Retention Policy Auditing Disaster Recovery

EE579U/3 #10 Spring 2004 © , Richard A. Stanley Another View from the SANS Institute – 4 6. LAN/WAN –6.1.1 Authentication Intrusion Protection Physical Access Modems Dial-in Access Dial-out –6.1.4 Backups Retention Policy Content Filtering Auditing Disaster Recovery Network Operations Center Physical Network Layer

EE579U/3 #11 Spring 2004 © , Richard A. Stanley Another View from the SANS Institute – 5 7. Desktop Systems –7.1.1 Authentication Intrusion Protection Physical Access Backups Auditing Disaster Recovery 8. Telecommunication Systems –8.1.1 Authentication Intrusion Protection Physical Access Auditing Backups Retention Policy Disaster Recovery

EE579U/3 #12 Spring 2004 © , Richard A. Stanley Another View from the SANS Institute – 6 9. Strategic Servers –9.1.1 Authentication Intrusion Protection Physical Access Backups Retention Policy Auditing Disaster Recovery 10. Legacy Systems – Authentication Password Standards – Intrusion Protection Physical Access Backups Retention Policy Auditing Disaster Recovery

EE579U/3 #13 Spring 2004 © , Richard A. Stanley Another View from the SANS Institute – 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 Containment Eradication Recovery Follow-Up Aftermath / Lessons Learned –12.9 Responsibilities

EE579U/3 #14 Spring 2004 © , Richard A. Stanley Another View from the SANS Institute – Ongoing Activities – Incident Warnings – Virus warnings Intrusion Vulnerabilities Security Patches 14. Contacts, Mailing Lists and Other Resources 15. References

EE579U/3 #15 Spring 2004 © , Richard A. Stanley Yet Another Approach Source:

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

EE579U/3 #17 Spring 2004 © , Richard A. Stanley Another Source: the NSA! Source:

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

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

EE579U/3 #20 Spring 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. Start small, and build incrementally –A manageable policy that is understood is better than a comprehensive one that is ignored

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

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

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

EE579U/3 #24 Spring 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?)

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

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

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

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

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

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

EE579U/3 #31 Spring 2004 © , Richard A. Stanley Audit Standards & Tools  ISO  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

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

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

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

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