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

Overview Policy Examples Case Study IT Security Policy Case Study

Overview Selected IT Security Policy Examples University of California - Berkeley SANS Institute

IT Security Policy Case Study UC – 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.”

IT Security Policy Case Study UC – 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.

IT Security Policy Case Study UC – 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

IT Security Policy Case Study SANS Institute – Policy Template

IT Security Policy Case Study SANS Institute – Policy Template

IT Security Policy Case Study SANS Institute – Policy Template

IT Security Policy Case Study SANS Institute – Policy Template

IT Security Policy Case Study SANS Institute – Policy Template

IT Security Policy Case Study Case 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.

IT Security Policy Case Study Case 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.

IT Security Policy Case Study Case 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.”

IT Security Policy Case Study Case 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.

IT Security Policy Case Study Case 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 . 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.

IT Security Policy Case Study Case 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.