Category Archives: Incident Response

What is incident response management and why do you need it?

The threat of cyber attacks and other security incidents looms over all organisations. There are simply too many things that can go wrong – whether it’s a cyber attack, a technical malfunction or another delay – to assume that operations will always be functional.

But that doesn’t mean you need to accept that delays are inevitable. You should be constantly assessing what might go wrong and how you would deal with it, because the way you respond to an incident may well be the difference between a minor disruption and a major disaster.

Every second counts

The longer it takes an organisation to detect a vulnerability, the more likely it is that it will lead to a serious security incident. For example, perhaps you have an unpatched system that’s waiting to be exploited by a cyber criminal, or your anti-malware software isn’t up to scratch and is letting infected attachments pass into employees’ inboxes.

Criminals sometimes exploit vulnerabilities as soon as they discover them, causing problems that organisations must react to immediately.

However, they’re just as likely to exploit them surreptitiously, with the organisation only discovering the breach weeks or months later – often after being made aware by a third party.

It takes 175 days on average to identify a breach, giving criminals plenty of time to access sensitive information and launch further attacks.

As Ponemon Institute’s 2019 Cost of a Data Breach Study found, the damages associated with undetected security incidents can quickly add up, with the average cost of recovery being £3.17 million.

If your organisation is to reduce financial losses and stay in control of the situation, you must have an incident response plan. This allows you to mitigate the damage and reduce the delays and costs that come with disruptions.

But incident management isn’t only good business sense, as we discuss next.

The GDPR and the NIS Regulations

Incident response management is a key requirement of the GDPR (General Data Protection Regulation) and the NIS Regulations (Network and Information Systems Regulations).

Failure to implement adequate response protocols could therefore not only endanger your organisation’s long-term productivity but also lead to substantial penalties. Breaches of the NIS Regulations can attract fines of up to £17 million, and the stakes are even higher when it comes to the GDPR, with penalties reaching €20 million (about £17.8 million) or 4% of the organisation’s global annual turnover – whichever is greater.

So, what do you need to do to stay compliant? Article 32 of the GDPR states that organisations must take necessary technical and organisational measures to ensure a high level of information security.

This includes implementing an incident response plan to contain any damage in the event of a data breach and to prevent future incidents from occurring.

Doing so also helps you comply with Article 33 of the Regulation, which requires organisations to contact their supervisory authority if they suffer a breach that poses a risk to the rights and freedoms of individuals.

The notification must be made within 72 hours of becoming aware of the breach, and should include as much detail about the breach as possible.

It should also describe the measures taken, or proposed to be taken, to address the breach, including steps to mitigate possible adverse effects.

Meanwhile, the NIS Regulations require organisations to produce:

  • Detection processes and procedures, which should be regularly monitored to ensure that they are up to date and effective;
  • Processes and policies for reporting vulnerabilities and security incidents;
  • Procedures for documenting the response to cyber security incidents; and
  • Incident analyses to assess an incident’s severity and collect information for the organisation’s continual improvement process.

The incident response lifecycle

We recommend that your incident response plan draws on ISO 27001, the international standard for information security, and ISO 27035, which contains principles and guidelines for incident management.

You might also be interested in our approach to incident response, which combines those elements with processes to help you prepare for incidents and aspects of business continuity.

You can adopt this approach by following these eight steps:

1. Identify risks, vulnerabilities and threat exposure

You can’t plan for disaster if you don’t know what might be coming, so the first step is to identify risks by conducting a risk assessment.

This process will also give you an idea of how much of a threat each risk poses and whether it’s worth addressing. For example, if you decide that a risk is highly unlikely to occur or will only cause minimal damage, planning for it might be more trouble than it’s worth.

2. Review cyber security controls

Your organisation more than likely already has certain controls in place; these could be as basic as antivirus software or firewalls.

Such measures could also stretch to existing policies or procedures, e.g. maintaining a schedule for regularly updating devices and software, or even physical security, such as CCTV.

These controls and measures should be reviewed to make sure they are still up to date, and ultimately capable of saving you any unnecessary work – if an existing measure suffices, ensure it is documented and cross it off the to-do list.

3. Conduct a business impact analysis

A BIA (business impact analysis) is a process that uses critical activities to determine priorities for recovery following an incident.

A BIA will also help you work out how quickly each activity needs to be resumed following an incident. Importantly, the analysis will give you an RTO (recovery time objective) for each activity, which is the ‘acceptable’ length of time it takes to get your systems up and running again.

4. Form the incident response team

A dedicated incident response team analyses information about incidents, discusses observations, coordinates activities, and shares important findings internally.

The team could include a director or senior manager, information security manager, facilities manager and IT manager.

Whatever the exact roles are, the team needs to have enough authority to act quickly in response to incidents, and sufficient access to information and expertise to make sure decisions are made on the basis of the best information available.

5. Develop incident response plans

Your plan should focus on the identified critical assets – including the risks to those assets, asset owners and asset locations – as well as the summarised results of the BIA.

You also need to put a reporting process or communication plan in place to ensure that both the incident response team and relevant stakeholders will be informed of any incidents.

For that process to work, you need to include contact details – both of team members and relevant authorities – and call trees, as well as checklists or steps to be taken in the case of specific scenarios.

6. Test incident scenarios

To be sure that the checklists or steps for specific scenarios actually work, you must test them.

Testing these steps at least biannually ensures that they are and remain effective, but also enables the documented plan to be as detailed as possible. And no matter how familiar staff are with the plan, theory is no substitute for practical experience.

Testing does not simply confirm that the plan works, but also trains staff to respond as efficiently as possible. All lessons learned should be documented, and resulting improvements incorporated into the scenarios as necessary.

7. Conduct incident response training

Human error and process failures are the underlying reasons for the majority of security incidents.

To reduce this risk, you must teach your staff about the importance of effective security and how they can avoid making mistakes.

Employees with incident response duties should receive additional training in relation to their role, whether this concerns incident notification, reporting or classification, or scenario testing.

Those with business continuity duties should also receive appropriate training.

8. Establish a continual improvement framework

Like any framework, incident response processes must be regularly reviewed to take into account emerging threats and areas where the current framework isn’t working as intended.

As such, the steps outlined here should be repeated annually or whenever there are major changes to your organisation.

Experiencing a cyber security incident?

If you’re facing a disaster or worried about what will happen when an incident occurs, you should turn to IT Governance.

Our experts help you take immediate action no matter what the situation. We can mitigate the damage if you’re in a crisis or optimise your existing resources and provide support where needed.

Following the incident, we aim to get you back to business, armed with the knowledge to manage your risks and improve your security posture.


A version of this blog was originally published on 14 May 2018.

The post What is incident response management and why do you need it? appeared first on IT Governance Blog.

The Five Incident Response Steps

It is important to remember that implementing incident response steps is a process and not an isolated event. For a truly successful incident response, the team should have a coordinated approach. There are five key steps in responding to incidents to ensure efficiency.

<iframe width=”560″ height=”315″ src=”https://www.youtube.com/embed/Euhl7hNquTQ” frameborder=”0″ allow=”accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture” allowfullscreen></iframe>

The five important incident response steps are the following.

Preparation

The key to an effective incident response is preparation. Sometimes even with the best team, they cannot effectively address a situation without the proper guidelines or plan. This should be in place in order to support the team and is one of the most important incident response steps.

Features that should be included in the plan are:

  • Develop and document policies and procedures for proper incident response management.
  • Create a communication standard so teams can coordinate properly during an incident.
  • Incorporate threat intelligence feeds, and perform ongoing analysis and synchronization of feeds.
  • Do cyber hunting exercises for a more proactive approach to incident response.
  • Assess the current threat detection capability of the organization, and update if needed.

Detection and Reporting

The second in the series of incident response steps is detecting and reporting potential security threats.

Monitor

Firewalls, IP systems, and data loss prevention solutions can all help you monitor security events in the environment.

Detect

Security threats can be detected by correlating the alerts in a SIEM solution.

Alert

An incident ticket should then be created and the initial findings documented. An incident classification would then be assigned.

Reporting

All report processes should include ways to accommodate regulatory reporting escalations.

Analysis

Most of the understanding of a security threat happens during the analysis part of the incident response steps. Evidence is collected from the data coming in from tools and systems for proper analysis and identification of the incident.

Analysts should focus on three main areas:

Endpoint Analysis

  • Find any tracks that could have been left behind by the threat actor.
  • Collect all the artifacts required to recreate the timeline of events.
  • Analyze the systems from a forensic perspective.

Binary Analysis

Analyze any malicious binaries or tools used by the attacker, and document these programs along with their functionalities. This can be done either through behavioral analysis or static analysis.

Enterprise Hunting

  • Check systems and the event log to determine what was compromised.
  • Document all the accounts, machines, tools, programs, etc. that were compromised for proper containment.

Containment

The fourth in the incident response steps is one of the most critical: containing and neutralizing the threat based from all indicators gathered through the analysis. Normal operations can resume after system restoration.

Coordinated Shutdown

Once all the affected systems are identified, a coordinated shutdown should be done for these devices.

Wiping and Rebuild

All infected devices need to be wiped, then the operating systems are rebuilt from the ground up. Passwords need to be changed for accounts compromised by the threat event.

Threat Mitigation Requests

If domains or IP addresses are identified and known to be used by threat actors, you should issue a threat mitigation request in order to block all future communication with these domains.

Post-Incident

There is more work to be done even after containment is successful with the final of the incident response steps.

  • Create a complete incident report.
  • Closely monitor the activities of affected devices and programs.
  • Update your threat intelligence to avoid similar attacks.
  • Last but not least of the incident response steps, implement new preventive measures.

Also Read,

Building Your Incident Response Team

Many Organizations Lack Plan to Respond to Incidents: Study Report

The post The Five Incident Response Steps appeared first on .