EE579S Computer Security
Download
Report
Transcript EE579S Computer Security
EE579U
Information Systems Security
and Management
3. Policy Examples and Development
Professor Richard A. Stanley
Spring 2004
© 2000-2004, Richard A. Stanley
EE579U/3 #1
Overview of Today’s Class
• Review of last class
• Projects
• Policy Examples and Development
Spring 2004
© 2000-2004, Richard A. Stanley
EE579U/3 #2
Projects?
•
•
•
•
Proposals due today
Teams?
Topics?
Issues?
Spring 2004
© 2000-2004, Richard A. Stanley
EE579U/3 #3
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 #4
Example Policies
• We covered some examples last week.
Let’s refresh our memories
Spring 2004
© 2000-2004, Richard A. Stanley
EE579U/3 #5
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 #6
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
Spring 2004
© 2000-2004, Richard A. Stanley
EE579U/3 #7
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
Spring 2004
© 2000-2004, Richard A. Stanley
EE579U/3 #8
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
Spring 2004
© 2000-2004, Richard A. Stanley
EE579U/3 #9
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
Spring 2004
© 2000-2004, Richard A. Stanley
EE579U/3 #10
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
Spring 2004
© 2000-2004, Richard A. Stanley
EE579U/3 #11
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
Spring 2004
© 2000-2004, Richard A. Stanley
EE579U/3 #12
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
Spring 2004
© 2000-2004, Richard A. Stanley
EE579U/3 #13
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
Spring 2004
© 2000-2004, Richard A. Stanley
EE579U/3 #14
Yet Another Approach
Source: http://www.cs.rmit.edu.au/rules/computer-security.shtml
Spring 2004
© 2000-2004, Richard A. Stanley
EE579U/3 #15
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 #16
Another Source: the NSA!
Source: http://www.nsa.gov/snac/index.html
Spring 2004
© 2000-2004, Richard A. Stanley
EE579U/3 #17
What’s In the Guides?
Spring 2004
© 2000-2004, Richard A. Stanley
EE579U/3 #18
But Wait, There’s More!
Spring 2004
© 2000-2004, Richard A. Stanley
EE579U/3 #19
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 #20
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 #21
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 #22
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 #23
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 #24
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 #25
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 #26
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 #27
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 #28
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 #29
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 #30
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 #31
ISO 17799 Overview
• Business Continuity
Planning
• System Access
Control
• System Development
and Maintenance
• Physical and
Environmental
Security
Spring 2004
© 2000-2004, Richard A. Stanley
•
•
•
•
Compliance
Personnel Security
Security Organization
Computer & Network
Management
• Asset Classification
and Control
• Security Policy
EE579U/3 #32
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 #33
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 #34
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?
Spring 2004
© 2000-2004, Richard A. Stanley
EE579U/3 #35