May 3, 2012
During the past three years, you may have noticed that security and risk professionals have added a new term to their lexicon – business resiliency. Is this just an attempt by vendors to rebrand business continuity (BC) and IT disaster recovery (DR) in much the same way that vendors rebranded information security as cybersecurity to make it seem sexier and to sell more of their existing products? Some of it certainly is rebranding. However, like the shift in the threat landscape from lone hackers to well-funded crime syndicates and state sponsored agents that precipitated the use of the term cybersecurity, a real shift has also taken place in BC/DR.
If you look up the term “resiliency” in the dictionary, it’s defined as “an occurrence of rebounding or springing back”. Thus, business resiliency refers to the ability of a business to spring back from a disruption to its operations. Historically, BC/DR focused on the ability of the business to recover from a disruption. Recovery implies that there was in fact a disruption, that for some period of time, business operations were unavailable, there was downtime as the business strove to recover. Resiliency, on the other hand, implies that an event may have affected the business’ operations, perhaps the business operated in a diminished state for some period of time, but operations were never completely unavailable, the business was never down.
BC/DR also historically focused on events such as natural disasters, extreme weather, major IT failures, critical infrastructure failures, pandemics/epidemics etc. – events that have a low probability of occurrence but have a very high impact to the business. However, in today’s world of global, 24X7 operations and intense competition, downtime, regardless of whether it’s a natural disaster, a simple hard drive failure or a security breach, is unacceptable. The business doesn’t care what caused the downtime, they want service restored and they don’t care who does it.
Unfortunately, most enterprises treat BC, DR and security as separate silos. BC often reports outside of IT into the COO, CRO or some other executive. While the VP of IT Operations is in charge of DR and the CISO or equivalent is obviously responsible for denial of service attacks, security breaches, data leaks etc. But who ensures that during a security breach, IT operations doesn’t accidentally destroy forensic evidence when they recover systems? Who ensures that there is an appropriate crisis management plan in place or that the business notifies appropriate government agencies when the Security team discovers a breach? Who ensures that employees adhere to corporate security policies no matter where the business has shifted operations?
The truth is that BC, DR and security, while separate disciplines that require specialized expertise and their own well-documented response plans, also have a lot in common. They use common processes (business impact analysis, risk assessments) that could be combined, they have important points of integration (joint testing, links between response plans etc.) and they all have a requirement to see availability and security embedded into enterprise architecture, not treated as bolt-ons after applications and systems are already in production. I believe that CISOs, because of their growing focus on broader information and IT risks, are best suited to act as the glue between these silos. And the more that these silos come together, the more that an organization can achieve business resiliency – the ability to spring back from ANY kind of disruption in a coordinated fashion.
If you have thoughts on business resiliency and the role of the CISO, I hope you'll reach out for a one-on-one chat at our upcoming Security Forums in Las Vegas and Paris, and/or drop me a note in the comments or on Twitter. You can track and contribute to the Security Forum using the #FSF12 (Las Vegas) and #SFE12 (Paris) hashtags.