If in any doubt as to the necessity of an incident response (IR) plan, consider this statistic from IDC research that reveals that 80% of consumers would take their business elsewhere if directly affected by a data breach.
If a security breach is not properly handled quickly, the company risks losing business, with investor and shareholder confidence dramatically slumping after a publicised data breach.
According to Gartner, the increase in complexity and frequency of cyber attacks, combined with an overreliance on preventative controls, has heightened the need for the development of a clear computer security IR plan.
Gartner’s research provides guidance to security and risk management technology professionals implementing an IR programme. The research house urges companies to first determine why they need an IR plan – I have covered that significantly in my first article on this topic – and goes on to recommend that businesses are encouraged to define the scope of their IR programmes.
So, what is needed here? The response to that is: a guiding set of best practices that can assist to design and implement a quality IR programme. The SANS Institute − the world’s largest provider of security training and certification – provides a set of best practices that commences with preparation.
It recommends you review and codify an organisational security policy, perform a risk assessment, identify sensitive assets, define which are critical security incidents the team should focus on, and build a computer security incident response team.
It is recommended that IT systems be monitored, so deviations from normal operations can be detected and examined to determine if they represent actual security incidents. When an incident is discovered, it is further recommended that you collect additional evidence, establish the type and severity of the incident, and document everything.
In today’s digital business world, no plan can be formulated that does not factor in cloud, and IR is no different.
Short-term containment measures must be deployed; for example, by isolating the network segment that is under attack. This should be followed by long-term containment, which involves temporary fixes to allow systems to be used in production, while rebuilding clean systems.
This is then followed by eradication − removal of the malware from all affected systems, identification of the root cause of the attack, and action taken to prevent similar attacks in the future.
Companies are cautioned to bring affected production systems back online carefully, to prevent additional attacks. Test, verify and monitor affected systems to ensure they are back to normal activity.
Then we get back to the ‘lessons learned’ gathering that I advocated in my first article – this should take place no later than two weeks from the end of the incident and should provide a retrospective view of the event.
Prepare complete documentation of the episode, investigate it further, understand what was done to contain it and whether anything in the IR process could be improved.
What about cloud and IR?
In today’s digital business world, no plan can be formulated that does not factor in cloud, and IR is no different.
Threat actors use cloud environments as entry points to infect, harm and disrupt business operations. They know that critical data may be duplicated to poorly protected or unsupervised cloud environments.
So, what should a company do if it discovers a cyber breach is taking place by way of, or within, its cloud environments? It’s important to recognise that tackling cloud incidents is different to addressing those within traditional IT environments.
The MITRE ATT&CK Cloud Matrix is a great resource for insights on real world adversary tactics and techniques based on real world observations.
Remember that monitoring in a cloud scenario is different to traditional, on-premises environments. Implementing security measures to protect cloud environments and its sensitive data will only get you so far. In the cloud, the organisation will need to focus more on applications, application programming interfaces and user roles.
Furthermore, consider all the actions that incident responders need to implement if they are to do their jobs, successfully, within a cloud environment. It’s important to ensure visibility and appropriate access, or it will be impossible to locate, remediate and ultimately eradicate infections.
Cloud must be an integral part of incident response. Threats to the cloud will persist, and incident responders will need to evolve to keep pace with the rapidly-changing landscape. Keep IR front and centre of strategies when building cloud environments, remembering that reactive IR doesn’t work in the cloud.
DevOps and cloud architecture teams need to consider incident response requirements as they set up cloud environments so that response is automated and coordinated.
Lastly, no IR plan can be regarded as comprehensive without building in a disaster recovery component. Complement the IR plan with a disaster recovery strategy, which prescribes how an organisation manages a catastrophic event such as a natural disaster or accidental loss of data.
One is a natural companion to the other − an IR plan focuses on identifying a security event and bring it to closure, but disaster recovery serves to ensure continuity of business processes after a service disruption and aims to bring systems back online, as quickly as possible.
Share