Information Security Incident Management Policy
1. Background and Purpose
This policy covers all incidents that may affect the security of information system including information assets of Melbourne Racing Club, its subsidiaries and related entities (“MRC”), and outlines steps to take in the event of such an incident.
Furthermore, this policy aims at a detailed analysis of security incidents in order to determine their root causes and to develop measures that help to mitigate the risk of similar security incidents in the future.
This policy aligns with relevant clauses of ISO 27001 – Annex A.16: Information Security Incident Management.
2. Scope
This policy applies to all Users of MRC’s Information Assets, including business partners and all other Third Parties authorised to use such resources through their association with MRC. This policy also applies to all methods of accessing these resources including, but not limited to, MRC’s network (all locations) and remote network connections via VPN etc.
3. Roles and Responsibilities
All employees, contractors and third-party vendors are required to report an IT security incident in accordance with this policy and in a timely manner.
3.1. General Manager Technology
- Is responsible for IT security incident management within the organisation;
- Informs the Executives of the security incident;
- Decides to isolate the incident and whether to shut down a critical IT service;
- Validates the reported incident in consultation with the appropriate technical experts;
- Validates the priority assigned to the security incident;
- Communicates to key stakeholders;
- Reports incident to appropriate regulatory agencies as required (in dialogue with Executive: Legal, Risk & Compliance);
- Monitor compliance of this policy by staff and contractors;
- Monitors and reviews the policy.
3.2. MRC Legal representative
- Responsible for data/privacy advice
3.3. Corporate Communications Representative
- Responsible for development of media response
3.4. Business and system owners
- Ensure reported security incidents are addressed promptly and appropriately in consideration of the risks;
- Ensure employees and contractors are aware of this policy;
- Ensure employees are trained in the secure handling of the MRC’s business-sensitive and personally identifiable information;
4. Security Incident
This policy specifically relates to the following types of IT and information security incidents (but is not limited to):
- Malicious software installed on MRC computers, devices or IT systems that can’t be detected, removed or quarantined by anti-virus or anti-spyware products;
- An attempt to disrupt the availability of MRC IT resources (Denial of Services attack etc);
- Criminal activity launched from internal or external networks that is directed at MRC’s IT resources or users;
- An attack from the internet such as, but not limited to, phishing attacks, spyware, ransomware etc on MRC’s IT systems;
- Defacement of MRC’s websites;
- A serious breach of MRC’s IT Security Policy;
- Theft, loss or unauthorised transfer of business-sensitive or personally identifiable information from MRC IT resources;
- Loss or theft of a laptop, mobile device, portable storage devices that may contain company information;
- Databases containing information being ‘hacked’ into or otherwise illegally accessed by employees (who are not authorised) within MRC including individuals outside of MRC; and
- Employees accessing or disclosing client information outside the requirements or authorisation of their employment.
5. Reporting
MRC must create a possible event to initiate the detection, response and reporting of a possible incident. The process is as follows:
- Upon detecting or being notified of a suspected event, all relevant information must be recorded;
- Whilst it is important that all available information is captured and recorded, this must not delay reporting of the event;
- Below information should be collected in a secure manner:
o Details of any processes running;
o Applicable screen shots of incidents or evidence;
o Copies of logs and important files;
o Logs from systems, services and networks (e.g. firewalls).
- Create and capture the event via MRC’s Service Desk and/or via phone. Events captured via phone must be logged by the service desk;
- The General Manager of Technology may allow an event to continue under controlled conditions after seeking legal advice for the purpose of seeking information that may be useful for the analysis of the incident.
6. Assessment and Decisions
The assessment activity at MRC (to identify a cyber security and/or an information security event), is initiated by MRC General Manager of Technology. The process in this section is as follows:
- Information must be gathered from the Service Desk, seeking clarification (if required) and collecting further information from the reporter if necessary;
- Conduct initial assessment to determine if it is a possible security related event or a false positive:
- If it is a false positive, the Service Desk must be updated and the ticket must be closed;
- If it is a possible security event, it must be investigated by the MRC IT team and the response process must be initiated.
- The assessment should also assess the potential or actual adverse effects of the incident.
Consider:
- Unauthorised disclosure of information;
- Unauthorised modification of information;
- Repudiation of information;
- Unavailability of information and/or service; and
- Destruction of information and/or service.
- If the MRC IT team assess it as a false positive, the service desk must be updated, and the ticket must be closed;
- If it is assessed as a security event, the Senior Infrastructure & Security Engineer must initiate the Response process.
7. Response
The response activities focus on the containment, eradication and recovery lifecycle of an incident. Below process must be followed post confirmation of a Cyber security incident:
- Responding to the incident, which could include the activation of IT recovery procedures, MRC Business Continuity and Disaster Recovery Plan, Data Breach Response Plan and /or issuing communications to relevant involved personnel;
- Contain the incident depending on the severity;
- The MRC General Manager of Technology must ensure that any production systems are not affected and if the incident requires isolation, all affected parties (internal and external) must be notified.
- Deciding whether cyber security incidents are under control.
- If the incident is not under control and containment is difficult or not possible, the MRC General Manager of Technology will decide whether the incident requires escalation (and thus triggering the MRC Data Breach Response Plan);
- Communicating the existence of the cyber security incident (and the relevant details thereof) to other internal and external people or organisations;
- In accordance with the processes set out in the Data Breach Response Plan, if a data breach has occurred, the extent of the breach or loss of data must be determined and should be also identified whether it has caused reputational or economic harm that requires MRC to actively inform the MRC Committee and impacted customers in a timely manner;
- If the incident is under control and contained, eradication and recovery of the system and/or components must be initiated;
- Information may be corrupted by an incident. Therefore, backup records must be checked for modifications, deletions, or insertions of information;
- The integrity of the logs must be checked, as a deliberate attacker may have manipulated these to cover their tracks; and
- Recovery options must be restored from a known good backup.
- Evidentiary data must be retained (particularly if the incident may lead to disciplinary or legal proceedings). Below information should be documented:
- What was seen and done (including tools used) and why;
- The location of ‘evidence’;
- How evidence is archived (if applicable);
- How evidence verification was performed (if applicable); and
- Details of storage/safe custody of material and subsequent access to.
- All activities must be properly logged, for later analysis;
- Incident report must be developed; and
- Once recovery has been completed and confirmed a Post Incident Review (PIR) must be initiated.
8. Learning from Information Security Incident
Any lessons to be learned from the handling of an incident must be quickly identified and acted upon. When conducting a review of an incident, consider:
- The information about the incident in the service desk ticket;
- New or changed requirements for information security safeguards. These could be technical and/or non-technical (including physical) safeguards;
- Note: It may not be feasible to financially or operationally implement these immediately, in which case they must be factored into longer-term plans;
- Potential incident applicability beyond the affected system / service / network;
- The need to:
- Incorporate findings into a security awareness briefing; and o Issue a Security Bulletin.
- Changes to the way incidents are managed, considering elements such as:
- Did procedures work as intended?
- Are there any procedures or methods that would have aided in the detection of the incident?
- Were any procedures or tools identified that would have been of assistance in the response process?
- Were there any procedures that would have aided in recovering information systems following an incident identified?
- Was the communication of the incident to all relevant parties’ effective throughout the detection, reporting and response process?
- Changes to any MRC IT Policies, as applicable.
9. Applicability of Other Policies
- MRC Privacy Policy;
- MRC Data Breach Response Plan;
- Risk Management Policy;
- Information Security Policy;
- Physical and Environmental Security Policy;
- Bring Your Own Device Policy
- MRC Crisis Management Policy
10. Key Legislation, Acts & Standards
- ISO/IEC 27035:2011 Standards – Information Technology – Security techniques – Information Security Incident Management - https://www.iso.org/obp/ui/#iso:std:isoiec:27035:ed-1:v1:en;
- ISO/IEC 27035-1:2016 Standards – Information Technology – Security techniques – Information Security Incident Management – Part 1: Principles of Incident Management - https://www.iso.org/obp/ui/#iso:std:iso-iec:27035:-1:ed-1:v1:en;
- ISO/IEC 27035-2:2016 Standards – Information Technology – Security techniques – Information Security Incident Management – Part 2: Guidelines to Plan and Prepare for Incident Response - https://www.iso.org/obp/ui/#iso:std:iso-iec:27035:-2:ed-1:v1:en.
- Australia Cyber Security Centre (ACSC) – Guidelines for Cyber Security Incidents – March 2023 – https://www.cyber.gov.au/acsc/view-all-content/advice/guidelines-cyber-securityincidents.
11. Review[1]
This Policy is recommended to be reviewed biennially.
12. Further assistance
For advice and assistance on policy matters please direct your enquiries to MRC’s IT Department via itsupport@mrc.net.au.
13. Glossary of terms/definition
Term
Definition
Assets
Any hardware, software, or information element of MRC’s information processing environment. Examples include but not limited to:
- Hardware (servers, laptops, routers, mobile devices, USBs etc)
- Software (developed applications, purchased software, tool and
utilities)
- Information (see ‘Information’ definition below).
Data
The representation of facts, concepts, or instructions in a formalised (consistent and agreed) manner suitable for communication, interpretation, or processing by human or automatic means. Typically comprised of numbers, words or images, the format and presentation of data may vary with the context in which it is used. Data is not information until it is utilised in a specific context for a particular purpose.
Employees
Directors, employees, contractors, and third-party service providers
Incident
Any event that causes, or may cause, an interruption or reduction in the quality of that service (i.e. it worked before but is broken and no longer works).
An unplanned interruption to an IT Service or a reduction in the quality of an IT Service. A failure of a configuration item that has not yet impacted a service is also an Incident.
Information
System
An automated system that creates or manages information about an organisation’s activities. Includes applications whose primary purpose is to facilitate transactions between an organisational unit and its customers, e.g. an e-commerce system, client relationship management system, purpose-built or customised database, finance, or human resources systems.
Information
Data that is interpreted, organised and structured in such a way as to be meaningful to the person who receives it.
Information Asset
An information asset is described as a body of information, defined and practically managed so it can be understood, shared, protected and used to its full potential.
Mobile Device
A portable device that can be used for certain applications and data storage. Examples are PDAs or Smartphones.
Password
A sequence of characters that is used to authenticate a user to a file, computer, or network. Also known as a passphrase or passcode.
PDA
Stands for Personal Digital Assistant. A portable device that stores and organizes personal information, such as contact information, calendar, and notes.
Personal
Information
Information or opinion – whether true or not – about an individual whose identity is apparent, or can reasonably be ascertained from the information.
Phishing
Phishing is the fraudulent attempt to obtain sensitive information or data, such as usernames, passwords and credit card details, by disguising oneself as a trustworthy entity in an electronic communication.
Smartphone
A mobile telephone that offers additional applications, such as PDA functions and email.
Sensitive
Information
Sensitive Information is a subset of personal information. Because of its nature, it has higher restrictions on when it can and cannot be collected. There are nine different types of sensitive information under the Privacy and Data Protection Act 2014 i.e. Racial or ethnic origin, political opinions, membership of a political association, religious beliefs or affiliations, philosophical beliefs.
[
1] Review date is recommended only. Should this Policy have not been reviewed or updated by its review date, this Policy shall still remain in force and does not expire.