Chillisoft’s SOC/SIEM service

1. Overview

This SOC incident response procedure establishes an integrated approach between CHILLISOFT and its clients to jointly respond to security incidents. The procedure outlines the information passed to the appropriate personnel, assessment of the incident, the integrated response, documentation, and preservation of evidence.

2. Purpose

• Keep all stakeholders informed of the situation and the response

• Ensure a rapid, documented and controlled response to information security incidents

• Verification that an incident occurred.

• Maintain or restore business continuity

• Minimise the impact of the incident

• Determine how the incident was executed and prevent similar incidents in the future

• Improve security and incident response

3. Scope

This policy applies to all CHILLISOFT employees, consultants and contractors who lead or respond to information security incident.

4. Policy Statements

• Any suspected Information Security Incidents are to be reported to customer nominated contacts provided by the customer and CHILLISOFT’s shift incident commander on an urgent basis. Customer nominated contacts, when applicable, will evaluate, qualify and report the incident to the senior leader, CEO or the board.

• Corrective measures will be prescribed according to the type and severity of the incident.

• Employees, consultants and contractors may be engaged on an urgent basis to support remediation efforts.

• In all cases, the first response to an incident will be to identify and execute such measures as contain or otherwise minimise the incident or threat. This may involve terminating systems processes, terminating network circuits, user accounts, applying IOCs or the rapid isolation of endpoints or network segments.

5. Roles and Responsibilities

Roles and responsibilities for the various parties involved in all the steps of the incident response process are outlined below.

5.1 Incident Detection and Recording

Incidents may be discovered and reported by SOC Analysts or Threat Hunters. The individual discovering an incident should immediately contact the customer.

All CHILLISOFT employees being alerted to a suspected or confirmed incident, (whether part of the SOC or not) should endeavour to capture the following incident details as clearly as possible:

1. The name of the individual who discovered the incident, and their contact details.
2. Date and time of the reported incident.
3. The nature of the incident, how and when it was detected.
4. The customer stakeholders involved, and locations. Name of system being targeted, along with user, operating system, IP address, and location.
5. Any information about the origin of the attack, including IP addresses, if applicable.
6. Preliminary evaluation of the severity or impact of the incident.

The CHILLISOFT’s shift incident commander, working with customer stakeholders and their IT teams will be principally responsible for the Incident Ownership, Monitoring and Tracking on CHILLISOFT end.

CHILLISOFT’s shift incident commander will consider the following:

- Is the incident still in progress?
  - What data or property is threatened and how critical is it?

- - What is the impact on the business should the attack succeed?

- - What system or systems are targeted, where are they located physically, and on the customer’s network?

- - Is the incident inside the trusted network?

- - Is an urgent response necessary?

- - Can the incident be contained?

- - What type of incident is this? Ex: virus, worm, intrusion, abuse, damage.

- What is the degree of confidence that the nature and impact of the Incident is fully understood?

A security incident report will be created. The incident will be categorised into the highest applicable severity as listed below.

5.3 Containment

- SOC will follow an established procedure to contain or otherwise minimise the impact of the incident, such as procedures provided within Anti-Virus Software.
  - If there is no applicable procedure, the SOC will engage subject matter experts as may be required, including external experts, to contain the impact of the Incident, and will fully document the procedure followed.

- Following the conclusion of the incident, this procedure will be appropriately communicated to enable use in future incidents.

5.4 Resolution and Recovery

- SOC will use forensic techniques including reviewing system logs, searching for gaps in logs, reviewing intrusion detection logs, and interviewing witnesses, to determine the root cause of the incident.

- SOC will recommend changes to prevent a recurrence of the incident and/or to prevent infection of other systems. Such changes should be implemented per the Change Management procedure, or may be executed on an urgent basis. Customer will restore the affected system(s) to the uninfected state. Restoration tasks may include, but are not limited to the following:

1. Re-installation of the affected system(s) from scratch, with a restoration of data from backups if necessary. SOC may be required to preserve evidence before doing this.
2. Reset User passwords if passwords may have been compromised.
3. Ensure that the system has been hardened by turning off or uninstalling unused services.
4. Ensure that the system is fully patched.
5. Ensure that real time virus protection and intrusion detection is running.
6. Ensure that the system is logging the correct events, at the appropriate level of detail.

5.5 Documentation

The following information will be documented within an incident ticket recorded in CHILLISOFT’s incident management system. The incident ticket will cover the following information:

- All artefacts and communication collected during the analysis and investigation
  - The severity of the incident.
  - How the incident occurred, whether via email, firewall, etc.
  - Origin of the attack, such as an IP address or computer/username.
  - Other information related to a potential attacker
  - The response plan, including all preventative actions that were developed.
  - What was done to respond to the Incident?

- The overall assessed effectiveness of the response

5.6 Evidence Preservation

If evidence preservation is deemed appropriate, it may be appropriate to engage the services of 3^rd party forensics partner. The following items should be maintained by the SOC.

- Retain copies of logs, email, and other communication
  - Make a list of witnesses, statements and contact details

- Retain all evidence until instructed otherwise by the customer.

5.7 Incident Closure

An incident will be closed once confirmed by the customer. Review of closed incidents is used to discuss lessons learnt and improved the quality of the service. Where appropriate the following items are also recorded pre incident closure.

- Assessment of damages and/or costs. A review of the response policy and an update to any relevant policies. A plan for the prevention of a recurrence of the incident.
  - Requirements for additional policies, procedures or training that may have prevented or lessened the impact of the incident.
  - An analysis of the appropriateness and timeliness of the response, and opportunities for improvement.
  - Availability of subject matter experts during the Incident.

- Any other lessons arising from the incident.

6. Framework

CHILLISOFT follows NIST Incident Response framework when handling incidents.

7. Procedure

8. Communication

CHILLISOFT uses Traffic Light Protocol (TLP) as explained at this Cert NZ link https://www.cert.govt.nz/it- specialists/guides/traffic-light-protocol/ for incident communication with the nominated contacts on the customer end on the agreed communication channels. Initial communication will be done via email using the following notification template.