Welcome to the SecAware blog

I spy with my beady eye ...

16 Jul 2012

Storms on the horizon

A new NIST standard SP800-146 cloud computing synopsis and recommendations set me thinking yet again about the business continuity (BC) aspects of cloudiness.

I should start by explaining that I believe effective BC involves engineering an appropriate combination of resilience, recovery and contingency arrangements, wrapped up in a nice package of incident management for good measure.  These four complementary approaches (five if you include the implied risk analysis) help ensure the continuity of critical business processes, along with the associated IT and comms services normally supporting them.  

Of these aspects, the standard mostly considers disaster recovery, and then only at a superficial level (it is a 'synopsis' after all).  For example, paragraph 8.3.5 says:
"Disaster recovery involves both physical and electronic mishaps with consumer assets. For natural disasters, replication of data at geographically distributed sites is advisable. For other physical disasters such as hardware theft, law enforcement involvement may offer the only remedy. For electronic mishaps, fault tolerance approaches such as redundancy, replication, and diversity are all applicable, depending on what type of electronic mishap is being protected against. Disaster recovery plans are applicable to all hosted IT services and should be documented and quickly executable.  All of these traditional issues are complicated as consumers may not know where their workloads are hosted."
'Resilience' merits just two brief mentions, while 'contingency' gets four.  Statements such as "What are the resiliency alternatives a consumer has for contingency situations involving a prolonged outage [of a cloud service]?" do not acknowledge the BC benefits of using cloud services as a part of resilience engineering and contingency planning.

Unfortunately, this rather negative perspective on BC is all too common.  I'm quite sure many IT security and IT professionals unconsciously equate BC with IT disaster recovery, specifically, except perhaps for niches such as fault tolerance and safety-critical systems where the broader perspective reins.  Avoiding disasters, or at least reducing the probability and/or severity of reasonably foreseeable incidents, is a fantastic way to achieve BC, while developing the organization's capability to muddle through even totally unanticipated incidents is conspicuously absent from most written advice.


No comments:

Post a Comment