This week’s bulletin has been written by guest author Chandrasekar S, who suggests that bringing cyber security, incident response and business continuity teams together will enable organisations to better manage cyber resiliency.
Cyber risks are nowadays considered as a business risk and not limited to being simply an IT risk. The after-effects of a cyber incident are not only restricted to loss of IT systems but also include other business impacts, such as loss of reputation, loss of transparency and honesty, financial instability and operational losses. In many organisations, the security incident response function, which is the foremost team to manage these kind of events, is aligned within the security department while the business continuity function is owned by business and IT DR is owned by the infrastructure managers. It is high time to integrate these disciplines under a common function called cyber resiliency.
In general, any form of a cyber risk is considered as one of the sub scenarios, or a small part, of the larger business continuity plan of the organisation; while the main scenarios for the business continuity plan are more focused on non-availability of a facility or data center due to natural disasters or unavailability of critical systems. Many organisations have their policies and procedures written in such a way that they need to trigger the business continuity plans immediately following a cyber attack. Though both these functions are interdependent, cyber risk being a prequel to business continuity is not always true. Often the occurrence of a cyber attack is not realised immediately, but after a considerable period of time, such as days or even months. It is during this window that an attacker starts gaining access to multiple layers of the organisation. With this being the case, the foremost need is for the organisation to have proper mechanisms to first detect these form of attacks; and then prevent them from happening.
When an attack breaches the existing detection and prevention capabilities of the organisation and gets control of the organisation’s IT systems, it is time to redefine the complete security architecture. In today’s world of professional and highly adept cyber attackers the intelligence behind cyber attacks is always a step ahead of an organisation’s cyber resiliency capabilities.
In a situation where there has been unauthorised access to an organisation’s data / confidential information or a data breach, there is no advantage in an organisation initiating a fail-over of its systems or data to an alternate processing site by invoking the disaster recovery plans. Shutting down the primary operating facility is also not a solution. Rather an effort has to be made to isolate the incident, restrict further damage and ensure that this does not seep into other layers of the organisation. However, in situations where the assets and data of the organisation are compromised (e.g. cases like ransomware), the organisation has to trigger its business continuity plans after running through the security incident response plans. Also, it is also a matter of fact that a business continuity plan takes off the moment that the incident response plans fail. So, if the incident response plans are strong enough to contain the attack and restrict the impact, then there probably is no need to trigger the business continuity plans.
Figure one: a graphical representation of cyber incident response and business continuity functions.
There are few approaches in which an organisation can integrate both these disciplines to move towards the common goal:
Firstly, the executive function governing these bodies must be integrated together under the same leadership.
Secondly, the scope of the incident response and business continuity functions have to be drafted by keeping in mind that any event would require both these functions to work in tandem to restore the services quickly. Both these functions are interdependent on each other because the cyber security aspect has to be kept in mind while designing a business continuity framework or methodology.
Thirdly, an incident response plan has to be clearly documented by including all categories of incidents and should be reviewed and maintained on a periodic basis. The cyber security team can take guidance from the business continuity planners to design the templates and structure of the incident response plans because the business continuity team always maintain their plans and procedures.
Fourth, similar to simulated testing of business continuity or disaster recovery plans, the incident response plans must also be regularly tested. While the team coordination and planning skill set is available with the disaster recovery coordinators, the technical knowledge is available with the security engineers. Both these teams together can test the complete aspects of the unified resiliency program. Table top and walk through drills can be scheduled by considering each scenario / type of attack and validating the preparedness of the organisation. This will also help to review what kind of communication plan the organisation must follow to avoid degrading the trust of its customers. A good example is in the recent cyber attack on Norwegian aluminium producer Norsk Hydro. Though the organisation took a couple of weeks to recover, the way it handled the crisis and communication with outsiders and interested parties was top notch. This was only possible due to a high degree of maturity in the company’s incident response plans and its integration with their business continuity function. The manner in which Norsk Hydro provided continuous updates on current recovery progress, what was done between the previous update and providing the timeline on the next communication, has left cyber resiliency experts impressed. This not only upholds the reputation of the firm but also shows its transparency in handling crises.
Finally, this overall integration helps an organisation to build better governance on its cyber-security function as the end goal of both these disciplines are the same.
This article was first published on Continuity Central and has been written by Chandrasekar S, Senior Technical Lead at HCL Technologies. Contact him at: firstname.lastname@example.org