PROCEDURE

/ Information Security Incident
Operational Responsibility: / Information Technology Services
Related Policy: / Information Security Policy
PROCEDURE STATEMENT
OBJECTIVE / The objective of this procedure is to:
  • Provide a systematic process for the investigation, recording and reporting of information security incidentsand to enable proactive prevention in the future
  • Encourage all staffmembers and students to be proactive and raise potential breaches that are of concern as soon as possible to prevent escalation
  • Ensure effective management of information security incidents and communications to relevant stakeholders.

EXCLUSIONS / None.

PROCEDURE STEPS AND ACTIONS:

The RMIT procedure for management of information security incidents was developed based on internationally recognised standards (National Institute of Standards and Technology 800-61)
Diagram – RMIT Information Security Incident procedure
This diagram represents a pictorial overview of the Information Security Incident procedure and should be read in conjunction with the procedure steps outlined below:

  1. Identification: Confirming, categorising, scoping, and prioritising suspected incidents
  2. Analysis: Identify compromised assets, threat indicators and implement incident specific monitoring
  3. Notification: Notify ITS management, Business Owner and other stakeholder/s
  4. Containment: Minimising loss, theft of information or service disruption
  5. Eradication: Eliminating the threat
  6. Recovery: Restoring computing services quickly and securely
  7. Post-incident: Assessing response to better handle future incidents through utilisation of reports and after-action activities, or mitigation of exploited weakness to prevent similar incidents from occurring in the future.

Procedure / Responsibility / Timeline
  1. Incident Identification
Once the potential breach has been identified, notify the Service and Support Centre (S&SC). The request must specify detailsof the breach.
Forward the notification of potential breachto the ITS Security Team for initial analysis and confirmation of threat indicators.
Determine whether or not a securityincident has occurred and, if it has, determine the appropriate security incident type/category (Appendix 1);and prioritise the incident i.e. from Priority 1 to Priority 5 (refer Table 1).
Setup and maintain an incident handling register across the lifecycle of the incident to track both timeline(s) and action(s) undertaken. / Incident Detector (staff or student)
Service and Support Centre
ITS Security Team
ITS Security Team / Immediate
Immediate
Immediately or as soon as practical
Ongoing
  1. Incident analysis
Analysethe incident to identify threat indicators and compromised systems and/or information. The analysis may result in commencing additional monitoring of threat indicators.
Identifythe appropriate ITS Support team who will provide assistance with further analysis of the incident. / ITS Security Team / Immediately or as soon as practical
  1. Incident Notification
For all Priority 1 and 2 security incidents notify the following:
  • ITS Leadership Team
  • Business and System Owner
  • Internal Audit and Risk Management
  • Privacy Officer
Report all incidents that may receive adverse media attention to the following:
  • Vice-Chancellor and President
  • Chief Operating Officer and Vice-President Resources
  • Chief Marketing Officer
  • RMIT Legal Services
For all Priority 3, 4 and 5security incidentsnotify relevant ITS Management and the System Owner. / Senior Security Manager
Chief Information Security Officer
ITS Security Team / Notification must be provided immediately or as soon as practical
  1. Incident Containment
Develop a containment action plan with assistance of the relevant ITS Support team,that may limit the damage that an incident may cause, taking into account least possible impact to services.
Seek approval from the appropriate system owner should containment action(s) impact the service.
Review and, in consultation with the ITS Security team approve the containment action request.
Raise the appropriate change request(s) as per the ITS technology change management process to implement the containment actions.
Notify the ITS Security team of the success or failure of the change.
Notes:
  • During implementation do not compromise the ability to investigate the incident and/ordestroy evidence that may be valuable in determining the cause or allow corrective action to be taken.
  • For approval of the containment action(s), ifthe System Owner is not reachable or identified, the actionscan be taken following approval of the Chief Information Security Officer (CISO).
/ ITS Security Team
ITS Security Team
System Owner
ITS Support Team
ITS Support Team / Immediately or as soon as practical.
  1. Incident Eradication
Develop appropriate protection techniqueswith the assistance of the relevant ITS Support team, to remove malicious artifacts on the compromised systems and implement additional security controlsto mitigate the threats.
Notify the system owner of the proposed protection technique.
Review and, in consultation with the ITS Security Team approve protection techniques.
Raise the appropriate change or problem request as per the ITS technology change management or problem management process to implement the protection techniques.
Note:
For approval of the eradication action(s), if the System Owner is not reachable or identified, the actionscan be taken following approval of the Chief Information Security Officer (CISO). / ITS Security Team
ITS Security Team
System Owner
ITS Support team / As recommended or agreed
  1. Incident Recovery
Restore compromised system(s)to normal operational status with the assistance of the ITS Security team and System Owner.
Monitor compromised systems, to detect potential recurrence of the threat indicators. / ITS Support Team
ITS Security Team / Restore communications must be sent within 90 minutes after restoration of the system(s)
  1. Post-Incident activities
For all Priority 1 and 2 incidents, document action(s) taken and lesson(s) learnedinto post-incident report.
For all Priority 3,4, and 5 incidents notify the incident detector and close the incident. / ITS Security Team / Immediately or as soon as practical.
Information Security Incident General Rules:
The following rules are non-negotiable during the management of an Incident:
  • All incidents must be recorded
  • Multiple reports of the same incident must be recorded as separate incidents and, where possible, linked to a master incident record
  • Changes made to ITS infrastructure to restore service must be managed via the ITS Technology Change Management (including Emergency Change Management) process
  • All communication with a customer during the life of an incident shall be in professional, non-technical language
  • All communication with an incident detector (inbound and outbound) shall be recorded within the Incident Record
Tables

Table 1 - Information Security Incident Priority Factors:

Impact
Affected Users
University Wide / Department/LOB / Small Group or
VIP User / Individual User
Service Impact / Gold / Major / Major / Major / Moderate
Silver / Major / Moderate / Moderate / Minor
Bronze / Moderate / Moderate / Minor / Minor
Urgency
Urgency / High /
  • Senior Management Visibility or
  • Organisation is no longer able to provide some critical services to any users or
  • Negative effect on funding, reputation, relationship with partners or
  • Loss of critical informational assets or
  • Sensitive data exfiltrated and posted publicly or
  • Sensitive or proprietary information changed or deleted.

Moderate /
  • Management Visibility or
  • Organisation has lost the ability to provide a critical service to a sub-set of system users or
  • Non-Sensitive information was accessed or exfiltrated.

Low /
  • Minimal effect: the organisation can still provide all critical services to all users but has lot efficiency or
  • Time to recovery is predictable with existing resources or
  • No information was exfiltrated, changed, deleted or otherwise compromised.

Priority Matrix
Impact
Major / Moderate / Minor
Urgency / High / P1 / P2 / P3
Moderate / P2 / P3 / P4
Low / P3 / P4 / P5
Supporting Instructions or Documents /
  • Information Security Policy
  • Password Standard Policy

Related Documents /
  • NIST 800-61 Revision 2 Computer Security Incident Handling Guide
  • ISO/IEC 27002-2013 InfoSec techniques
  • COBIT 5 for Information Security.

PROCEDURE FURTHER INFORMATION

Commencement date / Review date / Secretariat Posting Approval

REVISION HISTORY – section maintained by the University Policy Officer

Revision Ref. No. / Status / Type Amendment / Date Approved / Approval Authority / Resolution Number / TRIM Reference
Approval/Other
V1.0

ACCOUNTABILITIES

Policy Sponsor: / Chief Operating Officer and Vice-President Resources
Implementation & Communication: / Chief Information Officer, Information Technology Services
Monitoring and Compliance: / Chief Information Security Officer
Approval Authority: / Vice-Chancellor and President

PROCEDURE SUPPORTING INFORMATION

Definitions and acronyms / Information Security Incident:An Information Security Incident is a single or series of unwanted or unexpected events that poses a threat to the integrity, availability and confidentiality of an information system and have significant probability of compromising business operations.
Incident detector: The person who logs an Incident or reports it to the Service and Support Centre.
ITS Management: An individual accountable for implementing and maintaining an RMIT’s ITS Services.
ITS Support Team: The ITS team who are assigned to resolve an Information Security Incidents that is out-of-scope for the Service and Support Center.
Priority: An attribute of an Incident that represents its relative importance. Priority is based on Impact and Service Category and determines the response time targets for the Incident.
Service category: Each service provided by ITS to its customers is categorised in the Service Catalogue as either a Bronze, Silver or Gold service based on how dependent customers are on the normal operation of the service – a Gold service is deemed most critical and a Bronze, the least. Service Category is used together with Impact to determine the Priority of an Incident.
System Owner: An individual with managerial, operational, technical and often budgetary responsibility for all aspects of an information technology system.
Key words for search engine / Information Security Incidents,Security Incidents, Cyber Security Incidents

Appendices

Appendix 1 - Information Security Incident Categories

Incident Categories / Description
Unauthorised changes to information, applications, systems or hardware /
  • Any unauthorised changes to RMIT’s information systems, through insertion, modification or deletion. For example, modifications to critical files.
  • Any unauthorised installation of additional processing, communications or storage equipment into the ITS environment.
  • This includes but is not limited to:
  1. modems
  2. portable media
  3. wireless access points.

Theft/Loss of any Information Assets /
  • The theft or loss of any information assets or devices including portable and fixed media that might have been or have been used to either process or store RMIT University’s information.

Unauthorised access to information/systems /
  • Unauthorised access from internal and external sources to RMIT’s information and systems.

Unauthorised release or disclosure of information /
  • Unauthorised release or disclosure of RMIT’s information to an unknown environment.

Violation of Information Security Policy /
  • Any violation of RMIT Information Security Policy or the information security related aspects of the code of conduct.

Malware Infections /
  • Program designed to cause damage to RMIT’s information systems.
  • This includes but is not limited to:
  1. A virus that spreads through email infects a host
  2. A worm that spreads through a vulnerable service infects hosts
  3. A Trojan horse is installed and running on a host
  4. Malicious mobile code on website is used to infect a host with a virus, worm, or Trojan horse
  5. Malicious code on a website exploits vulnerabilities on a host

Intrusion against networks /
  • Intrusions specifically targeting RMIT University’s internal infrastructure.
  • This includes but is not limited to:
  1. Network-based Denial of Service against a particular host
  2. Network-based DoS against a particular network
  3. DoS against the operating system of a particular host
  4. Dos against an application on a particular host;
  5. Website defacements
  6. Brute-force attempts
  7. Intrusion attempts that consistently target internal network infrastructure, users or services provided for external use such as web applications.

Abuse of Privileges /
  • Changes to privilege use settings on stand-alone or networked equipment including network profiles, local user or device configuration files that have not been approved through the RMIT’s change management process.

Password Confidentiality /
  • Sharing/stealing/loss of passwords or other authentication token.

Suspicious system behaviour or failure /
  • Unknown network activities, increased suspicious network requests or increased Intrusion Detection System (IDS) / Intrusion Prevention System (IPS) alerts leading to application crashes.

Other Events /
  • Other events which result in damage to information and systems

Page 1 of 8