What to Do in a Cyber Incident, Part 2: Non-Technical Response

As discussed in the first part of this series, the initial technical response in the aftermath of a cyber incident is critical to containing the incident and mitigating against further data theft. As the extent of the cyber incident comes into view, it is important to note even minor details that may prove useful in forming the non-technical response. A cyber incident response plan must be firmly in place. Gartner defines this as:

Also known as a “computer incident response plan,” this is formulated by an enterprise to respond to potentially catastrophic, computer-related incidents, such as viruses or hacker attacks. The CIRP should include steps to determine whether the incident originated from a malicious source — and, if so, to contain the threat and isolate the enterprise from the attacker.

The plan informs the constitution of the relevant teams who will handle any incidents that may arise. An example may be:

• First Responders
• Tactical (Security)
• Team Coordinator (C-Level)
• Legal
• Public Relations

The first responders are usually the IT help desk who tend to be involved with IT-related and break/fix issues in the organisation. If a reported issue is of a security nature, it is quickly escalated to the tactical (security) team who may involve a more specialised external incident response team depending on the severity of the incident. This team will then be responsible for the more detailed forensic investigation and root cause analysis. Usually, a C-level executive, such as a CIO or CISO, would receive regular updates that can be fed to top-level management, especially in the severe case of a data breach. Should any legal or public relations communication need arise, then the respective teams should be engaged. All these steps should form part of the Standard Operating Procedure (SOP) as part of the overall plan.

All employees within the organisation should also be clear on the reporting lines should an incident occur. If staff members are not aware of the importance of such a policy, it will be exceedingly difficult to have an effective cyber response plan.

For example, an employee who receives a suspicious email should immediately report such an incident so that the right technical staff can ascertain whether it is malicious. It could also be that an alert in one of the organisation's cyber monitoring systems is triggered. In most cases, threat actors target the weakest link, the end user, and failure to report seemingly trivial incidents could be the difference between detecting the beginnings of a larger malicious campaign or not.

Thus, the non-technical response part deals with policy, procedures, and processes involving:

• Incident Assessment
• Incident Reporting
• Regulatory Reporting
• Public Disclosure

Incident Assessment

It is important to make an initial classification of a cyber incident based on the information presently known. The possible impact level should be the worst-case scenario, even in the absence of all the details. As in the reference example discussed in the initial technical response, if the cyber incident involves an internal user account compromise, then each resource that the compromised account has access to may also be impacted.

This could be resources like VPN or remote access, email access, and intranet resource access, especially in cases where multi-factor authentication or machine authentication controls were not being used at the time of the incident.

The potential impact level should be the guiding light for the technical response phase. Once the full scale of the incident has been investigated and determined with some certainty, the known impact level assessment can be confirmed. In that case, it may be entirely possible that the incident’s impact and implications may not be as severe as originally thought.

Assessing the initial impact of an incident is a crucial step. It provides a way to make informed decisions on other steps, such as the nature of a formal report to regulators, whether a public communications disclosure may be required, or if background protocols should be activated. In any case, it is best to go ahead by assuming the worst-case scenario until proven otherwise.

Incident Report

Although a cybersecurity incident does not automatically equate to a major breach, it is still essential to make an incident report. In the initial instance, this will be a formal internal report that details some important aspects of the incident. The report should clearly identify the incident ID and incident owner.

The formal report should also capture some useful information, such as the type of incident, a summary of the incident, timeline, impact, and root cause analysis, any remediation or recovery actions, and finally, any lessons learned from the specific incident. An example is as follows:

• Incident Date
• Incident ID
• Incident Owner
• Incident Summary
• Incident Timeline
• Incident Detail
• Impact Analysis
• Root Cause
• Remediation & Recovery
• Lessons Learned
• Appendix

The report should contain details about affected users and their accounts and a timeline of occurrences leading up to, during, and after the incident. The organisation’s affected assets, such as computer systems, data, or websites, should also be detailed. This will help inform the final impact analysis and root cause analysis. All reports should be properly filed and then catalogued upon closure for each reported incident.

Regulatory & Public Disclosure

When dealing with regulators, depending on an organisation’s vertical (healthcare, finance, transportation, or retail), specific frameworks and regulations will need to be followed. There will also be general compliance regulations that cut across different verticals, such as GDPR, especially in incidents involving customers’ or employees’ personal data. Here, it may also be necessary to inform law enforcement. This may be the dedicated law enforcement agency responsible for receiving such reports. In the case of organisations that also provide defense or are part of what is deemed critical national infrastructure, there may already be a clear line of reporting to such an agency due to regulatory requirements.

Significant consideration should also be given to the legal side of the incident. Again, if the incident involves a data breach of personal information, adequate preparation should be in place for a potential legal challenge as well. Organisations should seek competent legal advice. The legal counsel should also inform the content of any disclosures and who within the organisation formally makes such a disclosure. Such a sub-team may include:

• C-level (CIO / CISO or equivalent)
• Incident Response Team Lead (Technical)
• Legal
• Public Relations

If a significant data breach is confirmed – meaning personal or customer data has been inappropriately accessed – it may be necessary to make a public announcement. This is one of the most delicate parts of the non-technical response, as it can have direct or indirect negative consequences for the organisation legally and financially. Therefore, it is of the utmost importance that a competent PR team is consulted on the best way to approach any such disclosure. In most cases, the regulatory framework will determine when and how to make a public disclosure. It will also determine when and how to involve regulators.

It should now be clear that every organisation’s cybersecurity policy document should include a cyber incident response plan. You need a standing response team and a clear and actionable standard operating procedure (SOP). All staff members, contractors, and affiliated personnel should be fully aware of the cyber policy and reporting lines. Local and international organisations, such as NIST, provide public frameworks to guide incident response planning. When it comes to cyber incident response, planning and preparation is the ultimate key to success, irrespective of the size or stature of any organisation, especially in this era of ‘assume breach.’