EE579U/3 #1 Spring 2004 © 2000-2004, Richard A. Stanley EE579U Information Systems Security and...

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?