IT Security Incident Management Policies and Practices

Transcription

1 IT Security Incident Management Policies and Practices Information Technology Services Center (ITSC) of The Hong Kong University of Science and Technology Date: Feb 6, 2015 i

2 Document Control Document Owner Classification Publication Date Issue to ITSC INTERNAL 6 Feb 2015 Public Version History Ver. No. Ver. Date Revised By Description Feb 2015 ITSC Initial Release ii

3 Table of Contents 1 Introduction Definitions and Abbreviations Information Security Incident Personal Data Incident Abbreviations Information Security Incident Response Team Team Structure Roles and Responsibilities All staff members, contractors and students ISIRT Manager ISIRT Members Cyber Security Coordinators (CSC) Reporting Incident Handling Process Overview of the Incident Handling Process Preparation Incident Impact Analysis Incident Detection and Reporting Escalation and Notification Containment Eradication and Recovery Aftermath References iii

4 1 Introduction Recently, malware attack, hacking and other IT security incidents were found to be targeting universities IT facilities. In order to ensure The Hong Kong University of Science and Technology (HKUST) can promptly response to IT security incidents detected within HKUST, IT Security Incident Management Policies and Practices have to be documented. This document outlines the management and handling procedures of information security related incidents within HKUST. 4

5 2 Definitions and Abbreviations 2.1 Information Security Incident According to NIST Computer Security Incident Handling Guide (SP800-61), A computer security incident is a violation or imminent threat of violation of computer security policies, acceptable use policies, or standard security practices. The term 'security incident' used in this guideline refers to any incident related to information security. In the case of Security Incident, such incident indicates that the security of an information system, service or network within the University may have been breached or compromised which is very likely to weaken or impair service operation. It poses a threat to the service in respect of availability, integrity and confidentiality. However, adverse events such as natural disaster, hardware/software breakdown, data line failure, power disruption etc. are outside the scope of this guideline. Example of security incidents includes: Unauthorized access and use of systems Hacking, or attempted hacking of the University IT facilities Computer viruses and hoaxes, and malicious codes or scripts affecting networked systems Leaks or breach of sensitive University data 2.2 Personal Data Incident Among the category of sensitive University data, some of them may be related to personal data. Therefore, any IT security incident that affects personal data within the University would be categorized as Personal Data Incident. When personal data incidents or suspected incidents are expected to be involving the breach of personal data privacy, the incident management procedure should follow the procedure stated in the Personal Data Privacy Policy of The Hong Kong University of Science and Technology. Besides, all personal data privacy breaches must be reported to Data Privacy Officer of the University. 2.3 Abbreviations The following abbreviations are commonly used in this document: 5

6 IH IRT ISIRT ITSC HKUST Service desk CSC IT Support team Incident Handling Incident Response Team which is the same as Information Security Incident Response Team Information Security Incident Response Team Information Technology Services Center The Hong Kong University of Science and Technology Service desk support team in ITSC Cyber Security Coordinator representing the departments to coordinate and handle IT Security IT team responsible for supporting the IT system of concern in HKUST 6

7 3 Information Security Incident Response Team 3.1 Team Structure An Information Security Incident Response Team (ISIRT) shall include an ISIRT Manager, Deputy Manager and ISIRT members from User service team, Network team and Infrastructure team for supporting incident handling process. The ISIRT may also include CSC from other departments of the University for handling security incidents related to the relevant department. ISIRT roles ISIRT Manager ISIRT Deputy Manager ISIRT Members (User service team) ISIRT Members (Network team) ISIRT Members (Infrastructure team) ISIRT Members (for public relationship) ITSC roles IT Security Officer IT Security Officer (Backup) User service team representatives Network team representatives Infrastructure team representatives User service team representatives 3.2 Roles and Responsibilities All staff members, contractors and students Report security weakness and suspicious security incidents to the Service desk of ITSC or ISIRT Keep appropriate records of systems so that exceptional events are noticed and can be presented to ISIRT for investigation and handling Assist the ISIRT members in investigating and resolving the incidents ISIRT Manager IT security officer takes the role as manager of ISIRT Have delegated authority to make immediate decisions on how to deal with an incident Ensure consistent application of incident classification and impact assessment Ensure that all ISIRT members have the required knowledge and skills levels, and that these continue to be maintained 7

8 Classify incidents and determine corresponding severities Assign investigation of each incident to the most appropriate member of his / her team and monitor the progress Document incidents ISIRT Members Assist the ISIRT manager in investigating, containing and resolving IT security incidents within their areas of specialty Classify incidents and determine corresponding severities in their own responsible areas Ensure timely communication with the ISIRT manager during investigating, containing and resolving IT security incidents Document detected incidents Cyber Security Coordinators (CSC) Coordinate with ITSC in handling security incidents Liaise with ITSC on training and awareness Implement security practices in the department 3.3 Reporting security@ust.hk will be published by ITSC for HKUST users to report security incidents. 8

9 4 Incident Handling Process 4.1 Overview of the Incident Handling Process When Security Incident occurs, Security Incident Handling, or in short Incident Handling (IH) is crucial for returning the IT Service to Users as quickly as possible, at the same time identifying the cause of the incident and minimize the chance of occurrence in the future. IH is a set of continuous process governing the activities before, during and after a security incident occurs. The Incident Handling Procedure is derived based on the SANS 6-Steps Incident Handling Methodology with the addition step of Forensics Investigation, the following is the overview of the Security Incident Handling Cycle. Preparation Follow Up and AfterMath Incident Detection Recovery Containment Eradication 4.2 Preparation Planning and preparing for the resource can serve as the basis of the later steps. Proper incident impact analysis, urgency and prioritization definition has to be established. Systems/Applications normal status and behaviour should be recorded. Incident detection mechanisms should be defined. IT support team should develop its own set of incident handling procedure. Security vulnerabilities and latest patch version should be recorded and maintained by relevant IT support team for prompt detection and incident response. 9

10 4.3 Incident Impact Analysis When an incident is detected, the corresponding Service desk and IT staff has to categorize the incident to relevant incident impact level. The 4 types of Incident Impact Levels are listed below. Incident Impact Level Extensive/ Widespread Significant/ Large Moderate/ Limited Minor/ Localized Descriptions of Impact Level If not resolved immediately, the incident will result in unscheduled service interruption of critical service, or severe security breach together with financial loss, data breaches or reputation damage. If not resolved timely, the incident may affect the normal operation of core services and lead to security breach. Financial loss or reputation damage is also probable. If not resolved within a reasonable period of them, may introduce additional vulnerabilities and expose the information systems or resource to higher risk of service interruption. Financial loss or reputation damage is possible if such vulnerabilities are exploited accidentally or by malicious parties. The incident is related to non-critical information systems or non-sensitive data, and the possibilities or causing service interruption, financial loss or reputation is remote. However, it may require additional controls or alternative operational procedures to retain service level and could lead to downgrade of efficiency Example of incidents e.g. compromise of computer handling student records; media reported compromise of system, etc e.g. disruption of teaching related IT systems; compromise of computing facilities but without student or staff records, etc e.g. IT systems found to be vulnerable or compromised; some non-teaching related servers suspected to be compromised e.g. virus infection of few desktop computers which are not used for student records After deciding the impact of the incident, priority in handling an incident also depends on the urgency of the incident. 4.4 Incident Detection and Reporting Incident detection is in dormant state and abnormalities from different detection channels will monitor the system until abnormalities has been detected. The main aim of this phase is to determine and scope of the suspected incident, classify and notify responsible parties. 10

11 IT support team should perform preliminary analysis of suspected incident. If incident is declared open, IT support team should maintain logs and system snapshot for further analysis and forensics investigation. 4.5 Escalation and Notification The escalation procedure defines the way to escalate the security incident to relevant parties and management to ensure that important decision can be promptly taken. Within the escalation path, IT support team should alert all the related parties (for attention, seek for support and approval on recommended actions). IT support team should define and implement its applicable reporting, notification and escalation path and priority. 4.6 Containment IT support team shall deploy a handling team to contain the incident to limit the scope, impact & magnitude, protect critical resources and determine operation status before the spread of it overwhelms resources or the damage increases. 4.7 Eradication and Recovery After containment of the incident, IT support team should perform the necessary activities to determine the root cause of the detected security incident. During the Eradication stage, IT support team should get rid of the incident by applying patches/fix, correcting system misconfiguration, password or software update. In some situation, IT support team may have to completely reinstall the entire system. During the Recovery stage, IT support team could further recover damaged or lost data to the restored system. IT support team may have to perform pre-production security assessment then restore system to normal operation. 4.8 Aftermath IT support team shall prepare a draft follow-up report, and submit the draft report to all parties for review and comments. The finalized report will provide a reference that can be used to assist in handling similar incidents. The finalized report should be kept for at least 3 years. 11

12 5 References 1. Information Security Incident Handling Guidelines [G54], version 5.0, The Office of the Government Chief Information Officer, Sep Information Security Incident Management Standard v1.0, City University of Hong Kong, 24 th Dec