Incident Response: How Planning for the Worst Can Protect Your Site Today

Cyber criminals are constantly finding new ways of stealing information, infiltrating systems, and otherwise causing damage. They are applying these methods to businesses of all sizes. If you haven’t yet had to deal with an incident, you’ve lucked out but it is likely only a matter of time until that luck changes.

Rather than taking a chance, you should develop a robust incident response strategy that increases your protective measures and lays the groundwork for an efficient and effective response when an incident does occur.

What Is Incident Response and Why Is It Necessary?

Incident response refers to the actions taken when a system is attacked, data is lost, or services are down. Typically, an Incident Response Plan (IRP), is a set of instructions and guidelines for responding to incidents. It helps in facilitating response to incidents and ensure that issues are detected and checked as quickly as possible.

Not having a well-developed incident response strategy in place allows criminals more time to compromise your system. They get an advantage in stealing or modifying your assets. Without an organized plan, any response you might have to incidents is likely to be slow and ineffective at best. At worst, it can cause more harm than good.

NIST Incident Response Plan

To develop your incident response plan requires taking into consideration your available resources, the security and value of your assets. For instance, the tools and solutions you’re currently implementing, and what specific requirements and limitations you face.

A good place to start is with the framework developed by the National Institute of Standards and Technology (NIST). It is a useful resource for plan creation that includes extensive recommendations and is adaptable to almost any organization. This framework consists of a cycle of the following four phases:

1. Preparation

Form a Incident Response Team

This phase begins with the creation of a Cybersecurity Incident Response Team (CIRT).

This team will be responsible for defining response policies and procedures, coordinating resources and team members during an incident. It also means establishing communications and escalating procedures as necessary. CIRT also evaluates processes after an incident has been contained.

In addition to the above, they might also be responsible for training staff on potential threats, periodically auditing security policies, and developing or implementing tools for use in incident response situations.

Assess Your Current Security

During preparations, you should assess your current security measures. This is the step that will help analyze how appropriate these measures are in protecting systems and data. If you find that they’re lacking, now is the time to make corrections. Also, address current policies and protocols to make sure that they match your security goals and are being properly enforced.

Define New Criteria

Next, your team should clearly define the incident detection criteria. This should be defined taking into consideration the probable attack vectors and known vulnerabilities. Likewise, establish criteria for determining incident priority. This must be according to functional, informational and recoverability impacts of potential incidents.

Try automating the response procedures as much as possible. For example, updating status pages or ticketing systems, revocation of user rights, etc can be configured in a way that they get activated immediately when necessary.

2. Detection and Analysis

Get Your Tools

The next step is to build a proper mechanism for detection and analysis. Using tools and technologies to detect threats, collect contextual information and analyze data can help a lot. They must include continuous monitoring and alerting functionality at a minimum. The Astra Firewall is a tool that simplifies monitoring and alerting. It is a tool with centralized management, log aggregation, behavior analysis and automated response capabilities. It ensures faster detection and analysis of potential events.

Tools which detects the widest possibility of attacks, including those from external or removable media, brute force attacks, web-based attacks, email attacks, redirection and Man-in-the-Middle (MitM) attacks, stolen credentials, misuse of data and stolen equipment are even better.

In case of an alert, it is your team’s responsibility to determine if the alert corresponds to an event. Then, analyze the currently known information, and determine the next steps based on your previously defined detection and priority criteria. If you are obligated to report the incident, whether to stakeholders or regulatory boards, now is the time to do so.

3. Containment, Eradication, and Recovery

Take Desired Steps

Once an incident has been detected and evaluated, action must be taken. The specific steps you take will depend on what your CIRT team has determined. Implement the best course of action like sandboxing an intruder or simply disconnecting a service & restarting it with a clean version.

Store Evidence of Incidents For Future

Regardless of the action taken, always protect evidence of the incident for later use in analysis, legal proceedings, and for regulatory compliance. So, document all steps taken. And, enforce a strict chain of data custody to ensure that evidence is not tampered with or lost. This documentation will also help ensure that no response steps are skipped or left incomplete.

Patch Vulnerabilities

After you have checked the incident, you must patch all the vulnerabilities. Since only eliminating a threat will do you no good, if you do not prevent them from reinfiltrating your system.

You should indulge in a thorough security audit on your website to reveal all other hidden vulnerabilities before a hacker does. Other than this, before putting your systems, services or data are put back into production reset security features such as passwords and user credentials.

4. Post-incident activity

In the final incident response phase, your CIRT team is responsible for analyzing the incident in its entirety. You should evaluate the following:

• What happened—including who or what was behind the incident, the methods and exploits used, when the incident occurred, when it was detected, and what damage was done
• How effective was the response—including the mean time-to-detection and response, the speed of containment, eradication and recovery, and the impacts on productivity or financials
• What went wrong—which protocols failed, were skipped or were otherwise inefficient, and whether there were team role or responsibility failures
• What resources were used—which tools were used and how, whether tools were beneficial or obstructive, and what tools would have been helpful to have but were missing or unavailable
• What improvements can be made—what steps would have improved time-to-response or effectiveness, if roles or responsibilities need to be changed, and whether security tools should be implemented or configured differently

Teams should prepare reports or statements to be provided to stakeholders, employees, customers or authorities as appropriate. The information they gain should be turned into actionable steps to be taken in improving future response plans and strategies.

Conclusion

Assuming that you are hack-proof is an idealistic thought. However, this is not always the case in reality. So, it might be tempting to avoid the idea of incident response, you must resist the urge to give in to this. Neglecting response can be a huge mistake and one that can cost you dearly. Rather than take this risk, set aside time and resources for the creation of an incident response plan now. The NIST framework introduced here can ease this process and help you ensure that all your bases are covered.

Share this...

Facebook

Pinterest

Twitter

Linkedin