it security policy: case study march 2008 copyright 2000-2008, all rights reserved

17
IT Security Policy: Case Study March 2008 Copyright 2000-2008, All Rights Reserved

Upload: kelley-griffith

Post on 18-Jan-2016

215 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: IT Security Policy: Case Study March 2008 Copyright 2000-2008, All Rights Reserved

IT Security Policy: Case Study

March 2008

Copyright 2000-2008, All Rights Reserved

Page 2: IT Security Policy: Case Study March 2008 Copyright 2000-2008, All Rights Reserved

Overview

Policy Examples

Case Study

IT Security Policy Case Study

Page 3: IT Security Policy: Case Study March 2008 Copyright 2000-2008, All Rights Reserved

IT Security Policy Case Study

OverviewOverview

Selected IT Security Policy Examples

•University of California - Berkeley

•SANS Institute

Page 4: IT Security Policy: Case Study March 2008 Copyright 2000-2008, All Rights Reserved

IT Security Policy Case Study

UC – Berkeley IT Security PolicyUC – Berkeley IT Security Policy

“Each member of the campus community is responsible for the security and protection of electronic information

resources over which he or she has control. Resources to be protected include networks, computers, software,

and data. The physical and logical integrity of these resources must be protected against threats such as

unauthorized intrusions, malicious misuse, or inadvertent compromise. Activities outsourced to off-campus entities must comply with the same security

requirements as in-house activities.”

Page 5: IT Security Policy: Case Study March 2008 Copyright 2000-2008, All Rights Reserved

IT Security Policy Case Study

UC – Berkeley IT Security PolicyUC – Berkeley IT Security Policy

“Logical Security: Computers must have the most recently available and appropriate software security patches,

commensurate with the identified level of acceptable risk. For example, installations that allow unrestricted access to

resources must be configured with extra care to minimize security risks.”

Physical Security: Appropriate controls must be employed to protect physical access to resources, commensurate with the

identified level of acceptable risk. These may range in scope and complexity from extensive security installations to

protect a room or facility where server machines are located, to simple measures taken to protect a User's display screen.

Page 6: IT Security Policy: Case Study March 2008 Copyright 2000-2008, All Rights Reserved

IT Security Policy Case Study

UC – Berkeley IT Security PolicyUC – Berkeley IT Security Policy

“Roles and Responsibilities: Responsibilities range in scope from security controls administration for a large system to the

protection of one's own access password. A particular individual often has more than one role.”

•Administrative Officials

•Providers

•Users

Page 7: IT Security Policy: Case Study March 2008 Copyright 2000-2008, All Rights Reserved

IT Security Policy Case Study

SANS Institute – Policy TemplateSANS Institute – Policy Template

Page 8: IT Security Policy: Case Study March 2008 Copyright 2000-2008, All Rights Reserved

IT Security Policy Case Study

SANS Institute – Policy TemplateSANS Institute – Policy Template

Page 9: IT Security Policy: Case Study March 2008 Copyright 2000-2008, All Rights Reserved

IT Security Policy Case Study

SANS Institute – Policy TemplateSANS Institute – Policy Template

Page 10: IT Security Policy: Case Study March 2008 Copyright 2000-2008, All Rights Reserved

IT Security Policy Case Study

SANS Institute – Policy TemplateSANS Institute – Policy Template

Page 11: IT Security Policy: Case Study March 2008 Copyright 2000-2008, All Rights Reserved

IT Security Policy Case Study

SANS Institute – Policy TemplateSANS Institute – Policy Template

Page 12: IT Security Policy: Case Study March 2008 Copyright 2000-2008, All Rights Reserved

IT Security Policy Case Study

Case Study – Financial InstitutionCase Study – Financial Institution

A financial services company maintains several physical offices, including a facility in Europe that houses servers and data entry terminals for

processing of electronic funds transfers and issuance of credit cards.

Initial contact is due to a desire to improve security for the facility, with a focus on securing servers and workstations. No known exploitation of

security vulnerabilities at this time.

Security audit indicates numerous problems with administration of systems, including no security policy, poor handling of paper records,

inadequate physical security, obsolete and unsupported systems.

No detection of abnormal activity within the company’s IT systems at this time.

Page 13: IT Security Policy: Case Study March 2008 Copyright 2000-2008, All Rights Reserved

IT Security Policy Case Study

Case Study – Financial InstitutionCase Study – Financial Institution

The company receives the results of the audit along with recommendations for upgrading systems, improving architecture,

improving records handling, and upgrading physical security.

The company hires an independent contractor to design and implement a solution based around the recommendations.

An intermediate audit is conducted, approximately half way through completion of the project. Some previous problems still exist, new

problems are transient effects from the upgrade process, all known issues are addressed or in the process of being addressed.

One new recommendation: have the contractor performing the upgrades provide systems management and security management training courses

for company IT admins.

Page 14: IT Security Policy: Case Study March 2008 Copyright 2000-2008, All Rights Reserved

IT Security Policy Case Study

Case Study – Financial InstitutionCase Study – Financial Institution

System upgrade and security system upgrade completed. A second auditing firm is brought in to conduct an audit of the systems and certify compliance with industry best practices, independent of the initial audit

company and the contractor that designed and installed the new systems.

•No significant problems are detected

•Security policies are well defined and implemented

•All systems are fully patched, with appropriate access controls

•All activity on the networks is monitored and logged

•Firewalls are hardened and correctly configured

•Intrusion detection systems are installed and configured

•Physical security is improved

•Administrators are trained to manage and monitor the servers

•Final Audit Review states “Excellent design and implementation, no significant issues detected.”

Page 15: IT Security Policy: Case Study March 2008 Copyright 2000-2008, All Rights Reserved

IT Security Policy Case Study

Case Study – Financial InstitutionCase Study – Financial Institution

Later:Administrators at the company decide to improve security by

installing new security software on their workstations and servers.

Installation of the product chosen breaks connectivity between mission critical systems. Transactions fail to clear, company loses

millions in customer fees in a single day.

Unable to implement their desired change, the company turns to the original auditing firm to re-examine their systems and perform

the desired installation of security software.

Page 16: IT Security Policy: Case Study March 2008 Copyright 2000-2008, All Rights Reserved

IT Security Policy Case Study

Case Study – Financial InstitutionCase Study – Financial Institution

Audit reveals penetration of the company’s network, and complete compromise of all servers and workstations, including intrusion detection systems and firewalls.

Probable point of entry was an employee’s workstation, due to unsafe web surfing or opening spam email.

Compromise of the network and security appliances spread due to weak passwords among general employees and some administrators, and storage of administrative passwords for security appliances on the desktop of admin workstations in unencrypted files.

Page 17: IT Security Policy: Case Study March 2008 Copyright 2000-2008, All Rights Reserved

IT Security Policy Case Study

Case Study – Financial InstitutionCase Study – Financial Institution

Detection of the intrusion and compromise of systems went unnoticed despite the intrusion detection system and logging.

Administrators were convinced that the network was a hard target and failed to monitor the intrusion detection system or examine activity logs.

This lax approach due to an exaggerated sense of their security precautions also created the conditions in which weak passwords were allowed, and critical passwords were not protected in the event of a single compromised system.