Guest post by Limor Wainstein, Technical Writer & Editor at Agile SEO.
IT security professionals have to deal with preventing and managing a variety of network security risks in their daily work, including cybercrime, the compromise of sensitive data, and service outages. The first line of defense is always prevention, and a slew of tools are used to help with this, including web application firewalls, network firewalls, anti-malware, and automatic failover. However, it is not always possible to prevent security breaches from occurring.
The ability to limit the damage arising from any data breaches, cyber attacks, or other serious network events that actually happen rests on the development of a robust incident response plan. These incident response plans outline, in an organized manner, the steps and processes that should be followed to mitigate, reduce, and contain the damage.
Attackers are constantly diversifying the means with which they attempt to carry out cyber crimes. A pressing threat faced by IT departments is cryptojacking, which has now surpassed ransomware as the most popular a form of cybercrime. Cryptojacking highlights an important distinction between incident response and disaster recovery.
In addition to an evolving range of network security threats, IT infrastructures continue to shift, with organizations becoming more dependent on the cloud. This infrastructural evolution increases the scope of threats and incidents that can potentially occur. Bearing in mind such trends, there is a real need for an incident response plan that constantly evolves too.
Here are five tweaks you should consider for your incident response plan to make sure your company is better prepared to deal with evolving network threats in an efficient and predictable manner.
An important part of an effective incident response plan is the correct categorization of incidents. Categorization is used for effective incident reporting so that the right people are informed and the right processes are used to contain the damage upon identification of a network incident.
Incident categories should be current, precise, and relevant. For example, using “malicious cyber attack” as a category is much too broad because there are many types of cyber attacks and the response to sub-groups of such incidents would differ. On the flip side, you can have too many incident categories to the extent that reporting incidents becomes extremely inefficient.
The best way to tweak your categories is to identify emerging patterns over time. Gather a list of between ten and twenty of the most prevalent incidents that your IT department or IT service desk submits reports on. Use this list alongside feedback from your staff to get a better picture of the range of actual incidents that occur on your network. Improved categorization leads to better reporting and ultimately, better incident response.
Consider setting up a dedicated computer security incident response team (CSIRT) to minimize the impact of network security threats in your organization. A CSIRT has a range of responsibilities solely focused on incident response, including:
In the context of tweaking an incident response plan, the last point is particularly pertinent. The recommendations made by a team of professionals in the area of incident response can lead to a much-improved plan. In fact, establishing a CSIRT can involve delegating responsibility for the creation and/or maintenance of your incident response plan to that team, leading to a more robust and informed plan.
Approaches to incident response often entail learning through real-world experiences of responding to genuine security incidents. This means that incident response plans are assumed to work, and the processes involved aren’t updated or evaluated until an incident brings to light some deficiencies in the plan.
A more prudent approach to improving incident response plans is putting them through their paces by conducting simulated attacks on the network. These test attacks simulate known threats to garner information about whether your plan works and what gaps exist in it that need to be plugged.
According to the 2017 SANS Incident Response Survey, 25 percent of organizations only update their incident response procedures following a major incident. Another revealing statistic from the same survey is that just 33 percent of organizations review and refine their incident response plan at all.
There is a clear opportunity in the form of controlled, simulated attacks that can provide actionable data to help IT departments better respond to incidents. Not enough organizations are taking this opportunity.
Not all incidents require a response beyond merely reporting them. An incident response plan should provide guidance on which incidents IT security teams should immediately act on, which ones they can ignore, and how to respond to specific incidents.
Prioritization depends on a host of factors, such as the current and potential future functional impact of the incident and how practical it is to recover from an incident. Organizations often ineffectively prioritize incidents, for example, by directing too many resources towards recovering from incidents that it is not possible to recover from, such as the compromise of data confidentiality. In the data confidentiality case, it would be better to prioritize steps that ensure future incidents don’t happen again.
You can use the National Institute of Standards and Technology’s Computer Security Incident Handling Guide to get a good basis for incident prioritization and what it entails.
Valuable data emerges from the reporting and response to any network security incident. This data can prove valuable for tweaking and improving incident response plans. For example, by studying the data, patterns and characteristics can come to light that reveal systemic weaknesses with your network security.
The data can also reveal threats that are perhaps more relevant and potent than you initially prioritized them. An additional way to leverage data is by using it to gauge the performance of incident response teams. Data collected can include the number of incidents, time to respond to incidents, time elapsed between occurrence and detection of an incident, and the estimated monetary cost of incidents.
Use these five tips to help tweak your incident response plan. Don’t lose sight of the fact that any robust and effective incident response plan evolves over time. Periodic testing, proper categorization and prioritization, and leveraging data can all help. Setting up a dedicated CSIRT will lead to further improvements in your plan.