Information SecurityIncident Management GuidelinesA.Guidelines1.Audience1.1The intended audiences of this guide are:(a)Individuals / ISIRT (Information Security Incident Response Team) taskedwith Information security incident response and management activities.(b)Individuals that interface with ISIRT (Information Security Incident ResponseTeam)2.Executive Summary2.1This guideline document governs the actions required for reporting, responding andmanaging information security incidents involving University’s ICT services and systemresources.2.2To ensure effective and consistent reporting and handling of such events, an incidentresponse capability is necessary for rapid detection, to minimize loss and destruction,mitigate the weaknesses that were exploited and restore University ICT services andsystems.2.3Safe use of the University's ICT services and systems is essential to keep it workingeffectively. All users of the University’s ICT services and systems have a responsibilityto(a)Minimise the risk of vital or confidential information being lost or falling into thehands of people who do not have the right to see it(b)Protect the security and integrity of IT systems on which vital or confidentialinformation is held and processed(c)Report suspected information security incidents promptly so that appropriateaction can be taken to minimise harm.3.Purpose3.1The intent of this guideline document is to provide a framework and procedures formanaging and responding to information security incidents. Fostering a culture ofproactive incident reporting and logging will help reduce the number of securityincidents which go unreported and unnoticed, often without resolution.
3.2This document provides guidance to the Information Security Incident Response Team(ISIRT) and associated stakeholders to better respond to information security eventsand incidents and provides a structured approach to:3.3Detect, report, and assess information security incidents.3.4Respond to and manage information security incidents.3.5Continuously improve incident response as a result of managing information securityincidents.B.Information Security Incident Management Process4.Introduction4.1Information Security Incident Management is a structured approach, and is composedof four major phases:(a)Preparation: Policies, ISIRT member nomination, stakeholder notification andISIRT technology acquisition.(b)Detection \ Incident Analysis: Detecting and confirming an Incident hasoccurred; categorising the Nature of the Incident and then prioritising theincident.(c)Containment, Eradication and Recovery: Minimising loss, theft of information,or service disruption; eliminating the threat and restoring services quickly andsecurely.(d)Post-Incident Activity: Submitting a formal closure report including lessonslearned. This report must also contain recommendations for improvement,mitigation of exploited weaknesses and additional security controls to preventsimilar incidents from occurring in the future.5.Phase 1: Preparation5.1The first phase deals with preparing a team to be ready to handle an incident at shortnotice. Regardless of the cause of the incident, preparation is the most crucial phase,as it will determine how well the team will be able to respond to the event5.2Preparing to handle an IncidentThere are several key actions that must be taken care of while responding to anincident:(a)Policies – The University’s Critical Incident Management Policy and theUniversity Information Security Management, Security and Conditions of UsePolicy must readily be available for use as reference.(b)ISIRT member nomination - Appropriately skilled ISIRT members must beselected from employees deemed capable of adequately responding to a
security incident, either from the IT services department or any externalsource.(c)The ISIRT members must be apprised of their responsibilities as a team, andmust prepare to undertake the relevant activities to ensure that the ISIRT isoperational.(d)The ISIRT will be managed by the Chief Information Officer (CIO), who willoversee and coordinate operations.(e)Stakeholder Notification – In cases of Severe and Major Category incidents,ISIRT must immediately send an Incident Notification communication inaccordance with applicable policy, legal, regulatory, or contractualrequirements. Refer Critical Incident Management Communication Procedurefor notification to parties outside the University.(f)Technology – Required technology must be acquired to support theinformation security incident management process. This may include a cleanlaptop (i.e. not vulnerable to any network or virus attack that may be involvedin the incident), a mobile internet connection (if network access is impacted)and access to copies of necessary documents such as policies and guidelines6.Phase 2: Detection \ Incident Analysis6.1When an incident is reported or assigned to the IT Security team/ISIRT, the team mustperform a detailed incident analysis and risk assessment.6.2The risk analysis considers the range of potential consequences. The risk ratingdetermines the level of risk management required by the University. Consequence andlikelihood are combined to produce a risk rating. This is achieved by applying criteriain the Risk Management Matrix to determine the level of risk to the University. Thesecriteria include the following:(a)Likelihood of the risk, which reflects how often a risk may occur(b)Consequence defines the actual/potential impact that would/might occur6.3Refer to the University Risk Management Framework for detailed Risk Analysisguidelines to be followed6.4Process Steps:(a)IT Security shares the Incident notification with ISIRT team for analysis.(b)The IT Security/ISIRT teams will perform the incident analysis to determinewhether or not a security incident has occurred.(c)The ISIRT team will perform a detailed risk analysis of the incident as perUniversity Risk Management Framework.(d)ISIRT team determines the priority of the incident as per IncidentCategorisation, Prioritisation and responds as per Incident SLAs.
6.5(e)Thereafter, it assigns the case to Department Representative / IncidentHandler for action.(f)Once sufficient details are available, the Department Representative / IncidentHandler will take necessary action required for the incident.(g)Where an incident receives a priority of Severe or Major, the UniversityManagement must be notified as soon as possible.Incident CategoriesCategoryDescriptionUnauthorised Access Unauthorised and successful / unsuccessful logical access to theUniversity’s ICT services and systems.Denial of Service(DoS)Malicious CodeData LeakageAn attack that successfully prevents or impairs the normalauthorised functionality of networks, systems or applications byexhausting resources. This activity includes being the victim of, orparticipating in, a DoS.Successful installation of malicious software (e.g., virus, worm,Trojan horse, or other code-based malicious entity) that infects theICT services and systems.Security incident involving loss of the University’s criticalinformation that can have a negative impact on theUniversity.Actions involving ICT services and systems that violate the UniversityComputing & Communications Use Policy, e.g.:Improper UsageI.Downloading and/or using unauthorised security tools,II.Use of Peer to Peer applications to acquire or distributecopyrighted material.III.IV.Investigation6.6Refer : Information Technology Conditions of Use PolicyMis-use of UoN ICT services and systems.Unconfirmed incidents that have been contained, that arepotentially malicious or anomalous activity deemed by the ISIRTteam that warrant further review.Incident Prioritisation(a)The ISIRT shall perform an assessment of the incident priority using thefactors in the table below.(b)Given the established priority, the incident will be allocated a Service Levelwhich determines the timelines attached to next steps.
PriorityFactorExamples of Incidents SevereMajorModerateInsignificant6.7 An incidentaffecting the entire organizationAn incidentaffecting multiplefacilities, UserGroups ornetworksAn incidentaffecting a facilityor networkMinor Incident Business disruptions resulting from malicious activity thatresults in 50% degradationAny incident that impacts the availability of perimetersecurity infrastructureExposure of unencrypted, unmasked, or insufficientlymasked University confidential or sensitive information(Health Data/PII) into the public domain. This includes anydata that could have a negative impact on the University’sreputation.Compromised privileged account credentialsIncident involving Highly Critical assets 10% of University users unable to use IT resourcesPotential for involvement of law enforcementActive attack incidents by unknown attackers that impact theUniversity’s serversExposure of unencrypted, unmasked, or insufficientlymasked University confidential or sensitive information(Health Data/PII) into the public domain or to anunauthorised third party Malware incidents that don’t fall in a higher severityData loss incidents not involving sensitive informationConfirmed phishing campaign that impacts more than ahundred users Some localised inconvenience, but no impact to theUniversity.Incident Service Level Agreements (SLA)(a)The ISIRT team shall ensure that the incidents are managed and respondedto as per the below SLA. This SLA applies to the Incident responsecommitments for all type of information security incidents. Incident responsetimes vary according to the priority level assigned to the incident.(i)Notification – Initial notification of a suspected incident to ISIRT / ITSecurity Teams(ii)Contain/Remediate – Maximum timethreat/exposure or permanently tain / RemediateEscalation MatrixSevereImmediate8 Hours8 Hours24 HoursModerate24 Hours5 Business DaysRisk Committee, Privacy Office,University Executive & CIORisk committee, Privacy Office &CIOIT Security Team or ISIRTInsignificantN/AN/AN/AMajor
6.8Incident(a)Based on the analysis of the incident category and classification, theinformation security incident can be addressed in the following ways:StatusConfirmedReasonAn incident has been confirmed and response is underway.DispositionReasonUnidentifiedA confirmed incident involving an ICT service or system whichcannot be located may be resolved as Unidentified.TransferredA confirmed incident may be investigated and transferred toanother department for further investigation or action.A confirmed incident may be Deferred due to resourceconstraints, or information type.DeferredNote: Critical/High Priority cases cannot be deferred withoutCIO approval.False Indicator Investigation reveals that the source indicator used as the basisfor incident detection was a faulty Indicator.An event that appeared to be a malicious activity wasMisconfiguration subsequently proven to be a false alert and determined to be amisconfiguration (malfunction) of a system.Duplicate6.9An incident may be a duplicate of another record in the ServiceDesk, and must be merged with the existing workflow.Escalation(a)Severe and Major category incidents will require escalation so that seniormanagement within the University are made aware of, and may respondaccordingly to, serious and potentially serious information security incidents.The Crisis/Escalation Team consists of senior members of the relevantdepartments of the University. Not all members of the Crisis/Escalation Teamwill need to be alerted to all information security incidents immediately.(b)Refer to the Critical Incident Management Communication Procedure forescalation procedures to be followed for Severe and Major Categoryincidents.7.Phase 3: Containment, Eradication and Recovery7.1This phase begins once the suspected event has been classified as a ConfirmedIncident. This phase involves identifying the immediate response actions to deal withthe information security incident and informing the appropriate team about the requiredactions. The primary objective is to confine any adverse impact to the University’soperations, followed by eradication of the threat and the return of the ICT services andsystems to its normal productive state.
7.2The department representative/ incident handler shall manage this phase. Incidentcontainment, eradication and recovery steps may vary based on the incident type, andthe Incident Response Responsibility may be split over multiple teams which shall bemanaged and coordinated by the Incident Handlers.7.3Incident Handlers may require investigation expertise during the course of a responseor must have access to or agreements with third parties with appropriate skill sets toperform investigations.7.4An appropriate combination of the following actions must be used to complete thisphase:(a)(b)(c)8.Initial containment of the incident(i)Acquire, preserve, secure and document evidence(ii)Confirm containment of the Incident(iii)Further analyse the incident and determine if containment wassuccessful(iv)Implement additional containment measures, if necessaryEradicate the incident(i)Identify and mitigate all vulnerabilities that were exploited(ii)The ISIRT team will undertake the necessary activities to resolve theproblem, and restore the affected services to their normal state. Ifexternal support has been requested, the external bodies will also beinvolved in resolving the problem.(iii)Remove components of the systems causing the incident.Recover from the incident(i)Return affected systems and services to a state that is ready foroperation.(ii)Confirm that the affected systems and services are functioningnormally.Phase4: Post-Incident ActivityThis phase takes place once the information security incident has been resolved orclosed.8.1Compile Summary of Actions and Findings(a)The Incident Handler(s) must document the actions taken during the process.If the incident involved support from external Investigators or ForensicIn