GRC in the Cloud - Control + Visibility = Trust – Some examples from VmWare and RSA

Here’s the basic problem:  Information in the cloud is constantly on the move – that’s the side effect of cloud’s basic benefits of resource utilization and service availability.  This mobility, of course, is what drives security and GRC people crazy because it implies we don’t have visibility into where our information is, or control over where it goes, how it is used or who accesses it.

At EMC we’ve netted out the cloud trust challenge in a simple equation: Control+ Visibility = Trust.  (See Chuck Hollis’s blog for more on this and the EMC Cloud Trust Vision Paper that describes it.)
We believe it can be that simple and here’s a few examples that show you why.
Assertion:  Hybrid cloud GRC platforms can gain unprecedented levels of visibility and control by harvesting from monitoring systems to ensure that the hybrid cloud infrastructure conforms to security specifications, and that information is controlled in compliance with policies and regulations.
Proof:  Let’s look at how virtualization facilitates dynamic GRC at the infrastructure level.  Take Vmware’s vSphere™ platform - VMware vShield security suite includes virtual firewalls, logical zoning and edge network security and new capabilities are being integrated to enhance information security.

Example # 1 Information-centric visibility and control:
RSA and VMware are integrating policy libraries from RSA DLP into the VMware vShield solution to discover sensitive or regulated data and create information-centric zones of secure IT resources designed to comply with the most exacting security and compliance standards.  This is key: now we have embedded intelligence to manage and monitor the most heavily regulated data types, including personally identifiable information, payment card information and patient health information. This approach uses secure zones to automate the control and monitoring of sensitive, valuable information – which means that organizations can now safely move mission-critical business processes to a more efficient cloud model.

Example #2 Secure multi-tenancy:
Now let’s look at the oft-discussed multi-tenant risk – how can we ensure secure partitions so that one tenant’s information in keep private and protected from another tenant’s?  The hypervisor-level firewall in the VMware vShield platform is engineered to enforce proper segmentation and trust zones for applications. In private clouds, this means organizations can set up virtual firewalls so that applications with different security requirements – for example, production and testing, finance and sales – can be hosted in the same virtual datacenter. In a cloud service provider environment, VMware vShield solutions enable different tenants to share IT resources safely by creating logical security boundaries that provide complete port group isolation.  This means that organizations can safely process mission-critical information in multi-tenant environments.

The Future: Adaptive Analytics
So, virtualization is giving us a new level of continuous controls monitoring.  Many of us believe that we will see adaptive analytics employed in these systems will manage information risk in a highly adaptive way.  With these examples we are already seeing the focus in cloud trust a shift more and more to information and identities – as we manage some of the highest profile risks – ensuring that information is protected in accordance with its sensitivity, and that only authorized identities, machines and people, can gain access to it.

So, the Call to Action: learn more about hybrid cloud architectures and how virtualization can provide the level of trust your organization needs to make the move to cloud computing.   Talk to your IT architects and CSPs - and keep asking the fundamental questions around the basic equation:  how can you show me that Control+ Visibility = Trust?

Five Simple Questions Core to GRC Program Success

  As I work with customers on their journey to a unified GRC program, it often seems an insurmountable task.  But, as they say, every journey begins with the first step. And, often the first step is about sitting back and taking the time to really ask yourself, what is it that we need to accomplish? What’s the desired end state? From that introspection comes a set of questions, that when answered, form the basic building blocks of a GRC program:

• What is our end-to-end GRC program and what do we need to invest in to achieve our goals?
• How can we align business requirements with our policies and day-to-day operating processes?
• What is our real exposure and what controls need to be implemented to contain risks?
• How can we leverage technology to manage GRC holistically across the enterprise?
• How can we govern our GRC processes across silos and stakeholders?

Let’s take them one by one.
What is our end-to-end program and what do we need to invest in to achieve our goals?
This question begs us to build a strategy, a plan, a roadmap. Here maturity assessments are essential – they help us focus the lens on high priority initiatives that will get us to the target state.  It forces us to define the scope of the program – across what business units – IT, Operations, Finance or Legal? It’s about adopting the right principles to drive GRC – process efficiency, visibility, transparency, accountability. This question leads us to consider how we will measure success, what metrics are important. And to examine and be realistic about constraints – such as how the program can be funded. It raises issues of prioritization and what is and is not on the roadmap.


How can we align business requirements with our policies and day-to-day operating processes?
This question is really about how we align business processes and procedures with policies and controls. It forces us to look at our policy framework and how it is enforced.  Do we take an information-centric approach to risk and a risk –centric approach to security?  Do we take a pragmatic approach to do the right things well, such as enforce policies at the point of use? Do we have a strong training and awareness program in place to keep a culture of risk awareness growing in our organization? This question makes us to look beyond our boundaries, to other stakeholders, including regulators and third parties that are critical to our business to ask how we ensure our policies are embraced by our partners and customers.

What is our real exposure and what controls need to be implemented to contain risks?
This question has us reflect on the value of our assessments and audits – in what way do they help us understand our most critical business processes and most sensitive information? How do we put boundaries around real exposures that matter the most to our organization? This is the heart of risk management, compliance and controls testing. This question makes us think about risk monitoring and reporting – do we know what they are and are they prioritized in a hierarchy and risk register? This question makes us consider how we leverage common methods in evaluating risks, what rating schemes we use and how we can harvest risk information from performance management and quality systems that provide us insight into KPIs and KRIs.

How can we leverage technology to manage GRC holistically across the enterprise?
This question forces us to look thoughtfully at the entire GRC technology eco-system in play with the organization, and extending to through virtual environments to our customers and partners. We contemplate its architecture and how it will need to evolve over time to meet ever-changing business requirements.  Do we have a single version of the truth, a central platform for managing GRC? How can we leverage technology to ‘test once, analyze across, report many’?

How can we govern our GRC processes across silos and stakeholders?
Finally, we consider governance – what is the accountability framework for making decisions on risk, and who in the organizations truly has decision rights? Who owns risk and what is the organization’s appetite for risk? What nomenclature is used, and how to we strive to inculcate a common language to talk about, understand and act on and remediate risk? Finally, how do we monitor our environment, what metrics do we use and how do we respond to incidents? This question compels us to improve operations and incidence response – so that we are prepared in the event of a crisis, disaster or breach.

Whether it is trying to understand the end-to-end program and what investments need to be made, or diving into the detail of aligning business requirements with policies and day-to-day operating processes, or responding to incidents - implementing a unified GRC program forces us to move up the maturity curve.

Call to action for you: Take some time to think about these questions. Share your thoughts with your colleagues. You may find yourself starting to work on these building blocks together, and building a solid vision for comprehensive end-to end- GRC program – and find it is not such an insurmountable task!

Privacy and GRC – What the New Ponemon Study and the GAPP is Telling Us

Many organizations get their first taste of the promise and power of a GRC program when they begin to implement a Privacy Program. Why? Because privacy is an enterprise issue that spans legal, IT, compliance and business operations. Privacy regulations vary by jurisdiction, and at times may be in conflict.  In fact, privacy regulations are expected to get tougher, with additional breach notification requirements. With the increase in cloud computing, mobile devices and social networking, we are seeing growing demands from individuals and governments that organizations proactively build in ‘Privacy by Design’.  Privacy is a core GRC use case that is broad in its application, constantly evolving, delivered through many channels, and as a result needs to be managed as a program.

Ponemon Survey on eGRC and Privacy
Surveying one of the largest eGRC practitioner communities at the RSA Archer eGRC Summit recently, a new Ponemon study reveals that “as eGRC continues to emerge as a top C-Suite priority, only 20% of large organizations have a clearly defined eGRC strategy that pertains to the entire enterprise and 33% admit they have no clearly defined eGRC strategy at all. Regardless of their industry, all organizations report that managing privacy regulations by geography and in accordance with country or state laws are a driving factor in their organization’s move to an integrated program that supports IT, Legal, Operations and Finance.  Respondents identified their top two privacy challenges as 1) ensuring data shared with third parties will remain safe and secure and 2) complying with all appropriate regulations.”
 If you want to see more about this, read RSA’s press release on the topic here.

Managing Privacy as a part of a GRC Program
Privacy programs have multiple facets, all of which fall into fundamental processes in GRC. Building common processes such as policy management, incident management and risk assessments to support not only privacy, but your other GRC challenges, make sense, creates efficiencies and provides an integrated foundation for managing risk across the enterprise. Here are some of the basic elements of a Privacy Program – all of these can be shared with similar programs such as security, regulatory compliance or controls testing.

• Policy Management from life cycle management, through communication to personnel and third parties
• Personal Information identification and classification
• Risk Assessments, to identify real exposures
• Privacy incident and breach management
• Training and Awareness of privacy policy and controls
• Choice and Consent in the collection of privacy information
• Use of private information for an identified purpose
• Retention and disposal of privacy information
• Access to, physical and virtual, and protection of privacy information
• Monitoring and Enforcement of privacy policies and controls

What can you do now?
If you are finding this a bit overwhelming, know that there is quite a bit you can do now to get started on building a strong, integrated Privacy Program. If you want to get some insight into the maturity state of your privacy processes, check out the Generally Accepted Privacy Principles (GAPP) from the IACPA here.

What you are likely to discover is that beyond the program itself, you will need technology to help you manage such a broad spectrum of requirements. Yes, you’ll probably need an open GRC platform that can manage the collaboration privacy policy development, dissemination and attestation requires, and the automation of controls testing – through continuous controls monitoring or questionnaires.  Privacy management is supported by most GRC platforms (see RSA Archer here as an example) that do a great deal to help monitor risk and compliance related to the use of personal information.
What is for sure is that privacy challenges are NOT going away. They are only getting more intense. Time to get moving! If you are one of the two-thirds that are in need an enterprise GRC strategy - use privacy as your first use case. It’s bound to move you up the curve quickly and provide real value to your organization.

GRC Fundamental Component: Risk Ontology

At the heart of GRC is adopting a coordinated, coherent approach to risk management across the organization, and core to that objective is developing and adopting a risk ontology.

What is Risk Ontology?
In the information sciences, ontology “formally represents knowledge as a set of concepts within a domain, and the relationships between those concepts. It can be used to reason about the entities within that domain, and may be used to describe the domain”.
Some people think of ontologies as simply a nomenclature – but an ontology is much more than a shared index, vocabulary or taxonomy.  A Risk Ontology, for example, would include a model with the definition of objects and concepts, and how they relate to one another.  It would include rules about how concepts interact, and provide a basis for calculations and analytics.  It would provide a basis for establishing consensus on the meaning of risk terms, and a model that explains their use.
Organizations manage risk by identifying it, analyzing it and then evaluating whether the risk should be modified by risk treatment in order to satisfy their risk criteria – those concepts, and definitions of risk criteria – most importantly appetites, thresholds, rating schemes – can be part of a risk ontology shared by everyone.

Why do we need Risk Ontology?
We need Risk Ontologies to provide a basis for coordinating risk across the many activities in an organization:

• Since all activities across an organization involve risk, a Risk Ontology can be consistently applied to an entire organization, at its many functions, projects and activities
• While no single definition of risk exists, adoption of consistent concepts within a comprehensive framework can help organizations can improve visibility into the true risk profile
• Risk Onotologies can help organizations establish governance and manage risk more effectively, efficiently and coherently across an organization and externally with 3rd parties
• Risk Ontologies can support variations of approaches, definition of threats and risk criteria across internal organization functions, partners and customers
• Risk Ontologies are essential for driving value out of GRC technology platforms and enabling tools; they are only as good as the underlying frameworks, processes, and ontologies that define their use.

What does Risk Ontology contain?

A complete Risk Ontology would contain:

• Objects: These are the basic ‘objects’ – a person or thing found across your organization – for example, an object may be a person – a risk or control owner, or technical steward. Or on object may be an specific risk determined by applying risk criteria to potential events and consequences: a MEDIUM risk exists that intellectual property associated with the Aurora Project will leak from the Sharepoint site due to absence of data loss prevention policy and controls.
• Classes: These are concepts or types of objects – for example, reputation risk, strategic risk, financial risk, security risk, technology risk, health and safety risk, and so on. A very important class is the Risk Register – a list of all risks of importance to the organization. Classes might also include role, process, information, policy, control, asset, threat, vulnerability, and impact or treatment types.
• Attributes:  These are aspects, properties, features, characteristics, or parameters that objects (and classes) can have – for example, risk criteria such as a risk source, or criteria such as appetite, or a consequences such as a likelihood or impact rating.
• Relations: These are ways in which classes and individuals can be related to one another - for example, a threat source has a relationship to specific vulnerabilities.
• Function terms: These are complex structures formed from certain relations that can be used in place of an individual term in a statement – such as a risk equation, R = Likelihood x Impact, or R = Severity x Frequency.
• Rules:  These are statements in the form of an if-then (antecedent-consequent) sentence that describe the logical inferences that can be drawn from an assertion in a particular form – for example, if a regulation xyz applies to our operations in country, we must abide by it.  Or, as a specific output of a risk equation, rules may look like earthquake strikes our California operations there is a high likelihood that our mission critical processes for order to cash will be impacted for 3-5 days at a cost of $1m revenue per day. 
• Events: These are the changing of attributes or relation – for example, geo-political events effecting the threat landscape, economic indicators, exchange or interest rates.

How Do I start to create one?
Use your governance structures and processes to help you with developing a strong Risk Ontology, which may take many months to fully complete. Start with the very basics and work outwards from there. It takes real collaborative work, but you really can’t get to value-based GRC without it.  Set up working sub­committees of your Risk Councils to get the right people involved with this important work. Some of the core questions that have to be addressed are below. Over upcoming posts we’ll go into more detail about practice models and best practices to leverage in doing this.

• How is risk defined and calculated in each business unit and for each discipline?
• How do you aggregate risk across activities?
• What best practice frameworks are being used now for enterprise or operational risk, compliance, legal, audit, privacy, IT, security or business resilience?
• What are the key entities, attributes, relationships & constraints for risk and compliance?
• What are the key risk sources, criteria and consequences for risk?
• What metrics are required by each stakeholder group?
• How will these metrics be shared/leveraged by other programs such as Operational Risk Management, Audit, Legal, Privacy and Enterprise Risk Management?

Risk Framework: Five Easy Steps (yes, you can try this at work)

Last post, we went into what a Risk Ontology is, why we need one and what it contains. In this post, we look at Five Easy (some may say not so easy…) steps to get started. Remember that core to GRC is adopting a coordinated, coherent approach to risk management across the organization, built on a common risk ontology. And, at the core of a risk ontology, is a risk framework.  

Quick review: Risk Frameworks provide risk management programs with better:

• Coordination - Provide a basis for coordinating risk across  many activities in the organization

• Consistency - Since all activities across the organization involve risk, a Risk Framework can be consistently applied to an entire organization, at its many functions, projects and activities

• Visibility – While no single definition of risk exists, adoption of consistent concepts within a comprehensive framework can help the organization improve visibility into the true risk profile

• Governance – Risk Frameworks can help the organization establish governance and manage risk more effectively, efficiently and coherently both internally and externally with 3rd parties

• Flexibility – A Risk Framework, probably designed, can support variations of approaches, definition of threats and risk criteria across internal organization functions, partners and customers

• GRC Technology Platform Value – Risk Frameworks are essential for driving value out of GRC technology platforms and enabling tools; they are only as good as the underlying frameworks, processes and procedures that define their use.

What’s in a Risk Framework?
Here is main things you want to get defined in a risk framework - this is a subset of the GRC Ontology; the core or ‘engine’ of risk management.
1)       Risk hierarchy; which includes Class and Type
2)       Mitigating Controls (and procedures)
3)       Risk Scores, and
4)       Metrics.
Risks Scores (inherent and residual) will come as a by-product of assessments and can change.  

What are the key steps to follow in building a Risk Framework?
The diagram below shows five easy :-) steps to follow in building a risk framework. Step 1 is pre-work – you need to get a skeleton defined of risk classes and types, and gather as much as you can from stakeholders. The holes in the hierarchy should become apparent during step 1.  In steps 2-4, work with key stakeholders to further develop the hierarchy, and associate risks with policies and mitigating controls, risk scores and metrics if you can. At the end of the process you should have a reasonably good ‘tree’ and eliminated overlapping or redundant risk and controls. Top tier risks, those with High ratings, will surface to the top of the hierarchy. You can use those to recalibrate metrics to ensure you are focusing on the right things. Active risks in the framework become part of your organization’s risk register.  Most all GRC technology platforms automate this process, and the mappings between essential elements (shameless plug: RSA Archer’s Risk Management solution does this well)

Next post, we’ll show a best practice governance process flow for updating content in a Risk Framework.

Risk Framework: Managing Content – What’s the best practice governance process?

The last two posts have dealt with Risk Ontology, why we need one and what it contains; and Risk Framework – what it contains, and five key steps to get started. This post is about how to manage that information once it is defined.

What’s the best practice process and governance for managing a Risk Framework?
Managing updates to the Risk Framework can be a bear if you don’t have good governance around that information once it is defined.

Basically, we have three phases to the process, outlined below. Many GRC Technology platforms (shameless plug, yes, RSA Archer does this) support this type of process, but word of caution: you still need to define the Risk Framework that makes sense for your organization, and work through the step by process for each stakeholder community, and of course, train people on it, and implement the governance process to support it.

1. Risk Framework – That’s what we talked about last post – With the Stakeholder Community, define the risk hierarchy of classes and types, identify risks through residual rating, and associate metrics to risks.
2. Risk Remediation – For all risks with an inherent risk that is above the threshold, go through a remediation cycle. Some of these activities will be part of a regular risk assessment – but need not be.
3.  Content Review - Use the Stakeholder Community as a Review Board for Risk Content. New risks will emerge through audits and assessments, so make sure you have a regular review and governance process in place to accept new risks into the framework, and prune risks that are no longer relevant for your organization.

If you follow this type of best-practice process, you will go a long way to implementing a GRC ontology that gives your organization the visibility and control of risks that really matter. 

GRC and Risk Appetite formulation – A critical skill that executive management must develop to thrive in today’s climate.

If there is one element of a GRC framework upon which all else depends, it is the correct formulation of risk appetite, and the translation of appetite into tolerances, thresholds and limits that the organization must operate within. Without this, it’s simply impossible to manage risks effectively.
Risk appetite can be defined as the quantity and types of risk that an organization is willing to assume in pursuit of its strategic objectives.  Boards are typically responsible for setting risk appetites, and executive teams then implement them into the business by translate those appetites into more granular risk-taking limits within the most fundamental operating processes.

This is a huge challenge, and most organizations struggle to do it effectively. Those who do it well know it is a bit of art, a bit of science, and a mix of qualitative and quantitative approaches.

Everything depends on the right formulation of risk thresholds –policy, controls and ultimately, what is expressed as a risk, or not.

However - with the right collaboration, and properly managed process, risk appetite and thresholds can be defined.
GRC teams can work with executive and management to establish meaningful thresholds, or tolerances of acceptable loss, compromise, disruption, disablement of key material business processes, people, or information.  Tolerances describe, in tangible terms, the limits around which risk and compliance teams can manage their efforts.

Risk Appetite sets the bar – and the buck stops at the bar. You’ve got to work with the business to understand how much risk is the organization willing to take in a particular area.  How high is the bar? Once set, policy, controls and reporting can be calibrated to feedback the right indicators that allow management to make decisions to avoid, treat or transfer risk – efficiently and effectively.

Risk Appetite Definition 
 The quantity and types of risk that an organization is willing to assume in pursuit of its strategic objectives. 

What you can leverage

• Organizations tend to be fairly good at understanding thresholds in a few critical categories, such as financial liquidity requirements or business resilience and availability thresholds, which are typically defined in terms of business impact of disasters or service interruptions.
• Regulatory compliance thresholds have been formalized through control standards by Regulatory bodies and Professional Standards Organizations.
• Leverage expertise gained in these processes to build competencies at the next level.

What you need to do

• Clearly state the amount and types of risks that the organization is comfortable taking.
• Define maximum tolerable limits, both qualitative and quantitative, based on stakeholder expectations, constraints and strategic objectives.
• Identify actions that need to be taken when the organization’s’ actual risk profile is outside of tolerances.

What to watch out for

• Risk appetite and thresholds being set by security and risk analysts, rather than the board and business executives.

Risk tolerance calculations ensure that the organization is able to adhere to adopted risk appetites and implement the right escalation procedures. Utilization of Key Performance Indicators (KPI’s) and Key Risk Indicators (SRI’s) help risk and security teams understand how the organization currently assesses risks to the business.

Call to action: Find out how your organization formulates risk appetite and thresholds, and build that process into your GRC framework.