GRC Overview

In this post I will write about GRC and how it works.

While not overly encompassing, it will describe major GRC components and how they connected.

Governance vs Management

What is Governance. 

Governance (for Information Security in this context) is a tool that is employed by the board, the leadership and organization and used by the Information Security function to enforce a result:
Ensuring Confidentiality, Integrity, and Availability of information! That’s that – Essentially it establishes rules that the organization imposing on itself.

What is Management

Management is a process where the organization executes it day to day responsibilities and delivering on requirements defined by the governance

• Often, it might present a conflict of interest when the same group, who sets the rules are actually responsible for executing them and the primarily the reason for that is governance is about long term goals (very strategic) and management’s goals are short-term goals. This is not uncommon, but as organizations grow larger, they try to separate these two functions. 
• One popular approach, especially highly used by financial institutions is a three lines of defense model – First line executes, second line provides an oversight and the third line audits. 

• Governance
  setting rules and strategic direction for the Information Security Program
  • Why [Policy] 
  • What [Standard]

• Management
  adhering to and executing policies, tactical decisions, day-to-day operations and business as usual
  • Who, When, and How [Procedure]
  • Specifically How [Control]

Governance, Risk & Compliance

I tried put all components that is tightly connected to governance. In essence, of the components should not exist in the vacuum and they need to talk to each other in order for governance to be effective.

I will  go over each component and discuss its role.

The business is in the middle, it generates profit. 

As a result of doing business, companies create Technology and Information

To effectively protect these assets, a GRC function is established

Business drivers

“There is no information security risk; rather, it is a business risk (c)” Many of you seen this quote or variations of it.

Most organizations are concerned with revenue and risk management is something that needs to be done to help business grow and survive. Take an interest in how your company makes money.

To reiterate, business exposes itself to Risk. Therefore it is important to understand, assess, address, document and manage the risk to the business.

Information and Technology

Business exposes itself to risk thought Information and Technology. As a result, we need to assess those assets for risks, implement controls and monitor controls for effective risk management.

Concerned with technical Assets, how assets are used and risks they create

• Data: Raw facts and figures that form the foundation of information.

• Systems: Software and applications that manage and use information

• Infrastructure: Hardware, networks, and cloud environments supporting I&T

Processes: Methods and workflows that govern how information and technology are used

Risk [what if]

• Adverse event that can negatively affect business outcome
• CIA: Confidentiality, Integrity or Availability
• PROBABILITY: Threat x Vulnerability x IMPACT
• Enables the risk appetite and tolerance

As I mentioned previously, risk is an outcome of doing business.

The risk management function is broad and complicated, and risk management in information security is a subset and a partner of overall risk management function that exists in the organization. 

Information Security Concerns itself with 3 primary risk categories: Confidentiality, Integrity or Availability

Confidentiality is concerned with data breaches and most regulatory requirements. 

Availability is having information readily available. Risk of DDoS attack fits here.

Integrity ensures that the information is not modified without the authorization. For example, Risk of Access Control Compromise fits here, although depending on the intent, risk can span all 3 categories.

Like a pyramid, Risk categories get broader and more defined when you drill down as it helps the organization to concentrate their efforts on specific risk and their mitigation.

Risk is evaluated from Probability and Impact perspectives, where probability is a chance that there is a vulnerability in combination of someone exploiting it, intentionally or not, versus the impact, or damage the unauthorized exploitation might create. 

I tried to outline some terminology and fit it into the risk lifecycle.

Risk Exposure: most of decisions we face or actions we do expose ourselves to risk. Sometimes, we do not do anything about it due to low risk impact and probability and the organization can accept the risk. For example, being hit a meteor is low probability event and it is not documented anywhere. Nonetheless, the risk is there and the fact that is is not accepted, does not negate the acceptance let’s call it quiet acceptance.

Risk Threshold: is where we start looking into probability and impact analysis and apply controls. Controls ensure that the residual risk stays within the risk appetite.

Risk Appetite: Exceeding Risk appetite is organizational decision or it might driven by external forces. Risk appetite is set by the board of directors – it is pretty important to meet their expectations and is an indicator of the hard limit the organization is willing absorb to survive in normal circumstances (Like setting 60mph target on 55mph highway for everyday transportation)

Risk Tolerance: is a variation in Risk appetite and helps organization to adjust its actions in order to pursue opportunities (like driving 75miles per hour on the 55mph highway to make the flight)

Risk Capacity: Nonetheless, risk needs to stay below the point of no return which is risk capacity. It could be the result of a security incident, or a result of exceeding the risk appetite due to risky decisions. This is very bad for the organization to reach this stage. Going 120mph to make the flight might get you to jail instead.

The risk is a complex environment and there is an interest, I can come back and talk about it specifically

Authority [must]

Authority – exists to set the tone for your policies and helps you to formulate your governance. 

When you understood your risk and defined your appetite, then you can craft your authority rules. 

Authority rules could be laws, regulations, contractual obligations, industry best practices, governance frameworks and organizational risk appetite.

NIST CSF, OWASP, GLBA, PCI are the few that exist and could be your authority.

Legal Authority , for example, can be owned by legal and it will be their responsibility to communicate proper interpretations of regulatory requirements. 

• Authority predetermines the rules which the organization need to abide by and then be enforced through the Governance
• Legal or regulatory obligations that mandate compliance
• Contractual obligations
• Risk appetite is set by the board and leadership
• Governance Frameworks that the organization decided to align with
• Might be owned/managed by different areas in the organization

Policies [why]

On the previous slides, I outlined some prerequisites for effective policies and when risk is understood and authority has been documented, effective policies can be created.

Policies are strategic documents that provide the rationale and strategic approach to security in the organization.

Most organizations have the Information Security Policy – it provides direction and sets the tone for the whole security program. I look at the ISP as a ground zero for information security governance.

Policies must address your Authority in one coherent approach – if you have tons of regulations and obligations and other things that the organization needs to address, Policies consolidate everything into one stream of requirements. This way operational teams won’t need to chase specific laws or regulations everytime they those regulations change, or new regulations come into fruition.

• Aggregate authority requirements
• Outlines the organization’s intentions, security goals, and overall approach upon which information security program is established and executed
• Providing the rationale and high-level objectives, helps the organization to answer “why”
• Conveys the amount of risk organization is willing to accept to achieve its objectives
• Sets forward high-level roles and responsibilities on the organizational level

Standards [what]

Standards are technical documents that provide the scope of what needs to happen to meet policy requirements. Standards provide control design. 

For example, when operational teams need to build an MFA, they should be able to look into a standard, see the need for MFA and then have enough information on acceptable MFA security mechanisms. Also, this gives an upper hand for Enterprise Architecture to understand the ask and look into comprehensive appropriate patterns and overarching toolsets for the organization to adopt.

• Are tactical documents that provide ‘What’ on achieving directions and intent outlined by policies
• Don’t exist in the vacuum and support/address ‘parent’ policies 
• Requirements are finite and quantifiable that could be implemented and monitored
• Might outline more detailed roles and responsibilities relative to specific requirements
• Provide a blueprint for control design

Controls [how]

Controls established to protect the asset and usually are build based on the Policy and Standard requirements. 

When this happens, you effectively Meeting your Governance.

When control is implemented, it must be  assessed and rated for effectiveness.
In case if control is not effective for any reason, whether because change in threat environment or due to not properly meeting the governance requirements, there should be a path forward, that usually done via the Issue Management, which documents the gap and obtains the security exception and proceeds with remediation by building the action plans.

Controls are broad. For example, for each system that is exposed to to internet, you might have a separate instance of MFA control applied. Each control might be maged by its own owner and have a different implementation ‘Flavour’.

In case if control is effective, it provides the “NOW” security posture for the associated risk. But for more forward looking approach, we implement KRIs, that aggregate control data (one control or multiple), and then track history of baseline, together with the threshold that could potentially break the control and make ineffective. When KRI’s hit the threshold, it indicates potential issues in the future, and that information can be used to review existing governance and strengthen controls before the issue materializes.

• The practical and technical measures put in place to meet the 

standards and the security objectives

• Controls are the actual methods or mechanisms used to safeguard assets,
  manage risks
• Ensure compliance with the established standards and policies
• Must have a clear owner per system/product/area
• List mechanisms used to address requirements defined by standards
• Closely related to KRIs

Everything is connected an example 

I tried to outline the flow of things in the GRC. 

I did not include IT before the control to save the pace
when we have a risk that needs attention and we built the risk appetite, then we communicate the high level needs though the Policy and Set specifics in the standards. Finally, control is build on specific assets and that control’s purpose is to protect the asset from the risk and stay compliant with internal and external requirements.