Information Technology Services Information Security Incident Response Plan Authors: Peter Hamilton Security Manager Craig Collis Head of Risk, Quality and Continuity Date:1/04/2014 Version:1.3 Status:Final Information Security Incident Response Plan Page 1 of 10
Contents Version History:... 2 Introduction:... 2 Scope... 3 Risk Exposure... 3 Security Incident Classification... 3 Security Incident Recording:... 5 Security Incident Response Process:... 6 Other Related Documents:... 10 Definitions:... 10 Version History: V1.3 (Draft) Incorporate feedback from ISSOC 30/01/2014 v1.2.1 (Draft) 30/04/2013 v1.2 (Draft) 03/04/2013 v1.1 (Draft) 28/03/2013 v1.0 (Draft) 14/03/2013 v0.1-v0.9.1 (Draft) 12/02/2013-07/03/2013 Introduction: The purpose of Massey University s Information Security Incident Response Plan is to document the standard response to information security incidents for all staff, students and third parties who interact with the University. The plan outlines the differing types of incidents, and the processes for handling them. Note that this plan serves as a guide to the minimum response process in the event of an information security incident. It does not supplant rational judgement. If a situation warrants escalating an incident above and beyond the processes outlined below, then that escalation should be considered by those involved in managing the incident. This plan is concerned with responding to incidents which impact the security of University data, including the following: Research Data: This data may contain information of a confidential, sensitive or commercial nature. In addition, Research data may carry with it unique obligations in terms of external organisations with which the University holds contractual arrangements, and therefore additional requirements for communication, consultation and levels of response. Teaching Data: This data is critical to the teaching activities of the University, and may contain sensitive student information or intellectual property belonging to the University. Information Security Incident Response Plan Page 2 of 10
Administrative Data: This data contains sensitive information regarding University staff and students, and is also critical to ensuring that downstream information systems function correctly. Commercial Data: A number of University commercial activities utilise information systems and data which are hosted by the University. This data is financial and commercially sensitive to both the University and external third parties. Scope: This document outlines the appropriate procedure to be followed in the event of an Information Technology Security Incident. This includes incidents which relate to Research, Teaching, Administrative, Commercial, and all other sensitive data associated with Massey University information systems and activities. The procedure within this document deals with the aspects of a security incident which relate to information technology systems and services, and the response of ITS to such incidents. The broader aspects of security incident response such as staff or student conduct investigations and disciplinary procedures, is documented elsewhere. Also, this document does not seek to regulate the management and use of University data, which is addressed by separate Data Management Policy. Risk Exposure: The consequences of a security incident affecting University information systems can range from trivial to severe. The loss, corruption or inappropriate release of data can lead to critical University systems and services being unable to function, which could in turn lead to the University being unable to carry out its core business activities. In addition, security incidents have the potential to expose the University to significant cost, both in terms of financial cost and damage to the University s reputation. Security Incident Classification Information security is the practice of risk analysis and response to ensure the credibility, integrity and availability of information services. Information services are critical to Massey University s daily operations, reputation and fiscal status and are key in reaching the University s goals as outlined in The Road to 2020, by underpinning the Research, Teaching, Administrative and Commercial activities of the University. Because of this, appropriate response in the event of an information security incident is critical. A security incident may involve any or all of the following: A violation of University information security policies, including breaking New Zealand laws Unauthorised access or use of an information system or data, including deliberate hacking Inappropriate use of an information system Loss of information confidentiality Compromise of information integrity Loss of information or service availability Physical or logical damage to systems Malware outbreaks such as viruses and worms Information Security Incident Response Plan Page 3 of 10
Accidental disclosure of data to unauthorised or inappropriate individuals The following matrix serves as a guide to common types of information security incidents. It is not a complete list delimiting the bounds of possible incidents. If a situation is encountered which is believed to constitute or may lead to an information security incident, then the mattershould be escalated. Impact of incident Nature of incident Low Medium High Police engagement Legal engagement Media engagement Impact to health and safety Malware outbreak Compromised user credentials Denial of service against core University services Denial of service against medium- risk University service Denial of service against lower- risk University services Unauthorised access to University core business service Copyright infringement notice Breach of University policy Targeted (AKA Spear ) phishing attack Spam/Untargeted Phishing email Accidental disclosure of sensitive University information Single user or small group Single user Department or College Multiple users, or single medium risk individuals to service and nature of access. Assess details of infringement. to breach to target. Single user or small group to the nature of the data to service and nature of access. Assess details of infringement. to breach to target. Department or College to the nature of the data Campus / university wide Large scale, or high risk individuals to service and nature of access. Assess details of infringement. to breach to target. Campus / university wide to the nature of the data Information Security Incident Response Plan Page 4 of 10
Core University Business Systems are defined as follows, based on a 2005 Business Impact Analysis conducted by Standby Consulting Ltd. This impact analysis is currently being refreshed. Foundation Infrastructure Services HR and Payroll Data Storage Shared Database Services Server Virtualisation Services SharePoint Online Learning Management System FCMIS FileServices Print Services Email Application Licensing Service Building Management System Knowledge Base Service Student Management and Enrolment Research Master Finance Marval However, it should be noted that while these are identified as the core services required to carry out University business, sensitive University information is also held in a wide variety of other systems which are not identified as core. SecurityIncident Recording: Massey University s IT Incident Management System is known as Marval. All information within Marval is visible to all Marval users. Because of this, Marval should only be used as a place-holder for information security incident management for the purpose of high level tracking, monitoring, auditing and reporting. Sensitive or confidential information relating to information security incidents should not be recorded in Marval. This information will be recorded within the body of the Incident Report associated with the security incident. Information Security Incident Response Plan Page 5 of 10
Security Incident Response Process: Incident response workflow:the path(s) an incident is escalated along depends on the incident s priority. The higher the priority, the higher the incident will need to be escalated, as per the following escalation workflow. Information Security Incident Response Plan Page 6 of 10
All of these steps should be carried out with minimal delay. The higher the impact or associated risk of the incident, the greater the focus must be and ensuring all participants and decision makers are informed. For incidents with higher impacts, escalations via telephone or in person are recommended to ensure a timely response to an incident. Discovery and Response Phase 1)Incidents will usually be discovered in one of the following manners: Someone in an affected area may notice an incident Automated systems may report an incident The Police or lawyers may contact the University in regard to an incident The media may enquire about an incident Other 3 rd parties may report an incident A person responsible for accidental disclosure may report the incident In the event that the Police serve a warrant, the person receiving the warrant must escalate the matter to the applicable Level 3 Manager (Head of Department/Institute/School) and the Risk Manager. The Risk Manager may escalate the incident to the University Registrar. In the event that contact is made by lawyers or the Police, and where no warrant is provided, then any request for information or investigative support must be formallsed in writing (email is acceptable) to the University Registrar. In the event that a member of the media is making an enquiry about an incident, they are to be directed toward External Relations. All other forms of incident discovery must be directed to the ITS Service Desk for entry into the University s IT incident management system. 2) When an incident is logged, ITS Service Desk staff will conduct an initial assessment of the incident relating to its impact, urgency and the group responsible for the service(s) affected. When this is found to be the type of incident covered under the Information Security Incident Response Plan, it will be assigned to the Information Security Team for action. 3) When an information security incident is received by the Information Security Team, an initial risk assessment will be performed to understand the risk relating to this incident. The group focused on responding to an information security incident is known as the Information Security Incident Response Team (ISIRT). This team may be expanded by drawing on subject matter experts from outside of the Information Security Team if and when required. Low risk incidents are processed on a daily basis and do not require escalation to senior ITS Management, the Risk Management Office, Level 3 Managers or the University Registrar. 4) If the incident is reviewed and found to benon-security related, it will be assigned back to the ITS Service Desk for processing. 5) Once the risk has been assessed, steps will be taken to contain the risk and preventing the incident from becoming worse. Information Security Incident Response Plan Page 7 of 10
6) At this stage, the process splits in to two streams. In one stream, members of the ISIRT work to address the vulnerabilities at the root cause of the incident. Simultaneously, the Security Manager will escalate medium and high level risks to the Associate Director (AD) responsible for information security, and to the Chief Information Officer (CIO). 7) In the event that the CIO deems it warranted, as outlined by the University s standard risk assessment methodology, the CIO will escalate the risk to the Risk Manager. This is required in cases involving the Police and lawyers. 8)The University s Risk Manager, or authorised delegate, will review the identified risk. Should it be deemed necessary, the risk will then be escalated to the applicable Level 3 Manager 1 *of the relevant area affected, and to the University Registrar if required. During these escalations it is common for questions to be asked across all levels of those responding to these incidents. These questions will be directed toward the most appropriate parties participating in the incident response. Analysis and Review Phase Once the incident has been contained and escalated appropriately as outlined above, the incident moves in to the analysis and review phase. The purpose of this phase is to understand the causes and effects of the incident and to identity and conduct any formal investigations and disciplinary proceedings in the event of policy breaches or illegal activities. 9)The Information Security Incident Response Team will generate an Incident Report. The Information Security Manager is responsible for managing low risk incidents. Low risk incidents involving policy breaches by staff or students will result in the Incident Report being passed to the applicable ITS Service Manager, or delegate for possible formalemployment investigations. Medium and high risk incidents will have an incident report passed to the Associate Director responsible for Information Security and to the Chief Information Officer. 10) If warranted, the high risk Incident Report will be passed from the Chief Information Officer to the applicable Level 3 Manager. 11) If warranted, based on information within the Incident Report, the applicable Level 3 Manager may choose to initiate a formal investigation. Employment investigations and disciplinary proceedings have their own regulations, processes and procedures which must be followed. 12) Investigations in to student behaviour are conducted within the offices of the Campus Registrar. Investigations in to staff behaviour are conducted within the offices of People and Organisatio nal Development. 13) When an investigation is conducted which requires access and disclosure of information from services such as an individual s email, network or local computer drives and security and Internet 1 * Head of Department/Institute/School if the incident relates to staff, Campus Registrar if the incident relates to students, or Research Services if research information is involved. Information Security Incident Response Plan Page 8 of 10
access logs, authorisation for this access must first be given by the Chief Information Officer to the Information Security Incident Response Team 14) Once approval has been given by the Chief Information Officer for participation in an investigation, the Information Security Incident Response Team will work with the individuals* 2 conducting the investigationto provide evidence in aid of the investigation. 15) Once the investigation is concluded, if required in relation to external enquiries, information will be passed to External Relations or the University Registrar. 16) External Relations or the University Registrar will then liaise, as appropriate, with members of the media, the Police or lawyers. Risk Mitigation Phase After the Incident Review Phase is completed the Risk MitigationPhase will be executedto identify appropriate risk mitigation controls to limit the risk of similar incidents in the future. 17)The Information Security Incident Response Team will generate a list of recommended security controls in the form of policy, process and procedure changes to mitigate future risk. 18) Major systems changes will be processed via the University s Enterprise Architecture Working Group (EAWG). Minor policy changes may be approved by the Chief Information Officer. Major policy changes and major system changes processed via the Enterprise Architecture Working Group will be submitted to the Information Services Steering and Oversight Committee (ISSOC). 19)As appropriate, the University s Risk Register will have newly identified risks added or existing risks modified. 20)All approved changes will be implemented through the University s Information Technology Services Change Management Process. 21) With all prior steps having been completed, the incident will formally be resolved and passed to the ITS Service Desk for closure. 22) For medium and high level risks, an Incident Resolution Summary will be sent to the Associate Director responsible for Information Security and the Chief Information Officer. 23) For risks which have previously been escalated to the Risk Manager, or delegate, a copy of the Incident Resolution Summary will be forwarded to them. 24) For risks which have previously been escalated to an applicable Level 3 Manager, University Registrar, and/or Research Services, a copy of the Incident Resolution Summary will be forwarded to them. 25) For risks which have involved 3 rd parties, those parties will be notified by the Level 3 Manager, University Registrar, or Research Services, as appropriate. 2 Investigations into conduct are carried out by People and Organisational Development (POD) for staff and applicable Campus Registrar for students and are not conducted directly by ITS. Information Security Incident Response Plan Page 9 of 10
Other Related Documents: Massey University Emergency Response Plan Massey University Data Management Policy (in preparation) Massey University Procedures for Non-IT Security Incidents (in preparation) SLT 14/03/45 Definitions: Denial of Service (DoS) A denial-of-service attack or distributed denial-of-service(ddos) attack is an attempt to make a machine or network resource unavailable to its intended users. Malware Malicious software. Software that is intended to damage or disable computers and computer systems. Phishing The fraudulent practice of sending e-mails purporting to be from legitimate companies in order to induce individuals to reveal personal information. Spam Unsolicited email which is often sent in bulk and is generally sent with the purpose of commercial solicitation or the spread of malicious software. Information Security Incident Response Plan Page 10 of 10