View
213
Download
0
Embed Size (px)
Citation preview
Spring 2004© 2000-2004, Richard A. Stanley
EE579U/3 #1
EE579UInformation Systems Security
and Management3. Policy Examples and Development
Professor Richard A. Stanley
Spring 2004© 2000-2004, Richard A. Stanley
EE579U/3 #2
Overview of Today’s Class
• Review of last class
• Projects
• Policy Examples and Development
Spring 2004© 2000-2004, Richard A. Stanley
EE579U/3 #3
Projects?
• Proposals due today
• Teams?
• Topics?
• Issues?
Spring 2004© 2000-2004, Richard A. Stanley
EE579U/3 #4
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.
Spring 2004© 2000-2004, Richard A. Stanley
EE579U/3 #5
Example Policies
• We covered some examples last week. Let’s refresh our memories
Spring 2004© 2000-2004, Richard A. Stanley
EE579U/3 #6
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/3 #7
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
Spring 2004© 2000-2004, Richard A. Stanley
EE579U/3 #8
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
http://secinf.net/policy_and_standards/What_Do_I_Put_in_a_Security_Policy_.html
Spring 2004© 2000-2004, Richard A. Stanley
EE579U/3 #9
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 Protection5.1.3 Physical Access5.1.4 Backups5.1.5 Retention Policy5.1.6 Auditing5.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/3 #10
Another View from the SANS Institute – 4
• 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
http://secinf.net/policy_and_standards/What_Do_I_Put_in_a_Security_Policy_.html
Spring 2004© 2000-2004, Richard A. Stanley
EE579U/3 #11
Another View from the SANS Institute – 5
• 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
http://secinf.net/policy_and_standards/What_Do_I_Put_in_a_Security_Policy_.html
Spring 2004© 2000-2004, Richard A. Stanley
EE579U/3 #12
Another View from the SANS Institute – 6
• 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
http://secinf.net/policy_and_standards/What_Do_I_Put_in_a_Security_Policy_.html
Spring 2004© 2000-2004, Richard A. Stanley
EE579U/3 #13
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 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
http://secinf.net/policy_and_standards/What_Do_I_Put_in_a_Security_Policy_.html
Spring 2004© 2000-2004, Richard A. Stanley
EE579U/3 #14
Another View from the SANS Institute – 8
• 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
Spring 2004© 2000-2004, Richard A. Stanley
EE579U/3 #15
Yet Another Approach
Source: http://www.cs.rmit.edu.au/rules/computer-security.shtml
Spring 2004© 2000-2004, Richard A. Stanley
EE579U/3 #16
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/3 #17
Another Source: the NSA!
Source: http://www.nsa.gov/snac/index.html
Spring 2004© 2000-2004, Richard A. Stanley
EE579U/3 #18
What’s In the Guides?
Spring 2004© 2000-2004, Richard A. Stanley
EE579U/3 #19
But Wait, There’s More!
Spring 2004© 2000-2004, Richard A. Stanley
EE579U/3 #20
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/3 #21
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
Spring 2004© 2000-2004, Richard A. Stanley
EE579U/3 #22
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/3 #23
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
Spring 2004© 2000-2004, Richard A. Stanley
EE579U/3 #24
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?)
Spring 2004© 2000-2004, Richard A. Stanley
EE579U/3 #25
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
Spring 2004© 2000-2004, Richard A. Stanley
EE579U/3 #26
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
Spring 2004© 2000-2004, Richard A. Stanley
EE579U/3 #27
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
Spring 2004© 2000-2004, Richard A. Stanley
EE579U/3 #28
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
Spring 2004© 2000-2004, Richard A. Stanley
EE579U/3 #29
Dealing With Problems: 1
Workstation problems Physical access controls Environmental controls Object controls Data validation and auditing Data file controls Output controls Performance
Spring 2004© 2000-2004, Richard A. Stanley
EE579U/3 #30
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
Spring 2004© 2000-2004, Richard A. Stanley
EE579U/3 #31
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
Spring 2004© 2000-2004, Richard A. Stanley
EE579U/3 #32
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
Spring 2004© 2000-2004, Richard A. Stanley
EE579U/3 #33
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
Spring 2004© 2000-2004, Richard A. Stanley
EE579U/3 #34
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
Spring 2004© 2000-2004, Richard A. Stanley
EE579U/3 #35
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?