Yo Delmar
By Yo Delmar, December 2, 2009
GRC stands for Governance, Risk, and Compliance. It is a way of managing the overlaps in the way we govern our business and IT processes, manage exposures that are outside of our risk appetite, and demonstrate compliant controls — all so that we can maximize value and minimize cost. We GRCers often say we like to test controls once, analyze across multiple requirements, and report to many stakeholders. Why? It’s more accurate, efficient, and streamlined that way — everybody gets the same picture.
When we talk about the cloud, whether it is an internal cloud, an external cloud (i.e., public cloud), or a private cloud (i.e., hybrid cloud), we are inevitably led to consider GRC. To date the cloud GRC discussion has been limited to issues of privacy, trust, reliability, and availability, narrowly focused at times on security. This is typical when profound changes are underway driving any paradigm shift, and this evolution to the cloud is truly profound for IT. It changes not everything, but nearly everything. It is as transformational for IT, and perhaps more so, than the movement from centralized to distributed client server computing in the 90’s.
Going forward, we need to broaden the cloud discussion to imagine the scenarios where the cloud is GRC-enabled, at the appropriate level, matching the precise needs of its diverse and distinct user communities. Let’s rise above the clouds for a moment and “blue sky” GRC concepts one by one.
First, to level the set:
Governance is about boundaries and decision rights between entities, whether those entities are humans or machines. It’s all about aligning policy with business intent, and driving that accountability into the day to day fabric of the organization and infrastructure, whether the organization is virtual in the technology sense, extending through webs of cloud relationships, or in the people sense, extending through webs of human relationships.
Risk is all about managing exposure within appetites, if you are blessed enough to know what that is. This can be a challenge because there are mini-universes of processes, assets, and requirements and of course, this becomes even more complex in the clouds.
Compliance is largely about demonstration of control design and effectiveness, whether controls are in place to satisfy business or regulatory requirements, in the cloud, on the ground, or in the fog.
Governance in the cloud
What would a governance-enabled cloud look like? Governance translates directly through policy to authority, behavior, and access in the cloud.
Policy would need to be based not only on business and regulatory requirements, but also on best practices that can be translated from written edicts through instantiations of configurations for all in-scope technologies. For example, applications would specify their operational policies; hosts would specify their control capabilities; and hosting would occur when policies match control capabilities.
Classification schema would need to underpin the policies that govern behavior of entities, in particular, applications, information, or virtualized environs. Entities would need to know their GRC profile, that is, how they are classified and what their attendant configuration and protection requirements are, and by extension, what the characteristics of their target cloud environs must be.
Chain-of-trust-custody: we know about chain-of-trust-custody in the legal and even information security sense. When clouds negotiate handoffs in this dynamic, fluid eco-system, the chain of trust would need to be carried with it, logged, analyzed, and be auditable. If the chain should break, it must either stop the movement or self-heal. Policy shapes the rules of interaction and policy enforcement would be able to break bindings dynamically.
Risk management in the cloud
What would a risk management-enabled cloud look like? Risk translates directly to the probability or likelihood that a threat will have a negative impact on an entity.
Business Impact Analysis (BIA) would need to be continuous and based on known and accepted levels of risk tolerance, at many levels of granularity, running from business process through the stack to applications, information, and the cloud environ. BIA would be based not just on availability, “A”, as we see today in business continuity, but also on confidentiality, “C”, to ensure privacy, and integrity, “I”, to ensure data quality, as well. This BIA-CIA profile would map into the governance classification schema and be a foundation stone to facilitate trust.
Threat and vulnerability analysis would need to be dynamic, absorb new threat-vulnerability pairs, and determine probabilities by sensing their context through the type of e-discovery, instrumentation, and configuration controls monitoring that is possible at granular levels through the hypervisor. We have this type of technology today at the network level within the internal cloud; we need to extend it across cloud ecosystems.
Risk analysis and remediation would need to be dynamic; near-real time. Blocking and quarantining technologies would be part of the solution but most importantly, human-machine and machine-machine visibility into configuration postures, coupling, and service levels would enable just-in-time remediation.
Compliance in the cloud
What would a compliance-enabled cloud look like? Compliance translates into understanding how policy enforces regulatory and business requirements in the cloud, through the use of controls.
Control rationalization and normalization would need to be more automated. Conflicting controls would be rooted out and overlapping controls allowed to persist only in those environs where deeper levels of defense are required, based on classifications and policy.
Control implementation would need to be dynamic when possible. Human intervention will bottleneck processes, and where communication is machine-machine, collaborative decisions will need to be negotiated through rules or inference. Compliance would involve knowing such things as where information resides or has resided; where it has been transmitted to, from, or through regulatory boundaries; and how it is protected at rest or in flight, notified, consented, or “safe harbored”.
It’s time to reframe the cloud discussion in a way that frees us to think strategically and practically about how the journey to the cloud may actually evolve. By doing this we can be proactive and creative, and avoid the inevitable backtracking and reworking that occurs when we react piecemeal to profound change. Let’s continue the dialogue…it’s time.
