Risk Management in the Agile Environment
Agile risk management – is it even possible? This is our second of two posts ruminating on agility versus security. Today, you’ll see that an agile risk management framework like the one in the figure below is feasible, and that there need be no dilemma between agility and security.
I originally wrote what I call the “oxymoron post” about agile/security and put it up for discussion on the Linked In Security Architecture group. Soon, a frustrated colleague wrote: “For me, the VAST majority of organizations that state they are going to use Agile for development aren’t using Agile, they are finding an excuse to not do things properly and bypass checks-and-balances. It’s a way of implementing a project WITHOUT including things like security.”
In my experience, however, many developers are open to easy-to-use security solutions properly factored to their environments. I think they have a right to ask for that!
Two Very Different Companies
Over the last few months, Security Architects Partners had the opportunity to contrast the agile risk management (RM) approach with traditional RM on two projects running in parallel. The first was with a large global company and the second is with a mid-sized, high-revenue, heavily-regulated financial services company. Contrast their current states:
- Large global company (BigCorp): BigCorp has taken an executive decision to adopt agile development and agile project delivery methodologies for almost all projects. The company is transforming traditional IT, IT security, and RM models to fit the agile paradigm. As part of this model, cross-functional teams (aka “squads or crews“) of less than 10 persons forming the basic units of agile work will be given end-to-end accountability for as much of their work process as possible. To empower these small teams with the necessary flexibility, BigCorp is in the process of modifying prescriptive security policies and procedures to principles-based ones.
- Mid-sized Financial Company (MidCorp): To maintain and expand its position in the face of rapidly evolving financial, business, IT, risk, and regulatory landscapes MidCorp must continuously improve its capabilities, partnerships, and international presence. Security-related events, incidents, findings, and demands will remain challenging for the foreseeable future. The company must address multiple threats, stringent auditors or regulators, and a continuous stream of difficult findings. MidCorp has formally adopted COBIT 5.0 audit and governance processes along with the NIST 800-53 control framework.
It seems as if the two companies couldn’t be more different. And yet, after performing considerable discovery and research for each, we came up with three points of commonality in their RM requirements.
- Which standards an organization chooses for IT risk management are less important than ensuring that the standard(s) are well-implemented to be a good fit to its culture. Any solution must provide a streamlined approach to formal regulatory reporting and be well-integrated with other IT processes (e.g., agile for BigCorp, COBIT for MidCorp) to allow for efficient operation by a mix of fractional resources at the work group level and a small specialist Risk Team.
- ISO 31000 is the international standard for RM frameworks, and most other risk standards tend to align with it. It serves as a useful framework for a comprehensive, well-governed risk management program that supports audit/regulatory reports requiring a documented risk management function. It is designed to be customizable.
- Whether a company seeks to radically decentralize some risk functions (like BigCorp to the agile team level) or merely distribute them (to the assurance, operations, and security engineering groups for MidCorp) it still requires a consistent risk analysis taxonomy. The purpose of this taxonomy is to provide a consistent and methodical way to consolidate individual security issues into operational risks, and to map operational risks to strategic risks tracked by the security organization’s Risk Team. We’ve developed a risk assessment taxonomy many clients can use derived from Open FAIR. It can strengthen, rather than replace, existing risk analysis processes.
An Agile RM Framework for BigCorp
The figure at the top of this post is in fact a generic rendition of the framework we developed for BigCorp based on ISO 31000, our adaptation of Open FAIR’s quantitative risk assessment approach, and our addition of a methodology for control assessment and residual risk assessment. The agile elements for BigCorp are highlighted in red.
Each box depicts agile elements of the agile risk management processes. BigCorp’s goal is to empower crews to remediate most security issues locally while also making issues lists available for review. We’ve recommended they use a remediation time window in combination with an agile asset risk profiling process to determine when an issue creates enough risk to warrant further reviews. Security issues from multiple risk intake channels (e.g. vulnerabilities, software defects, third party deficiencies, etc.) can be triaged through this same general process.
When a security issue cannot be remediated within the allowed time for the affected asset’s risk profile, it should be escalated as a risk and subjected to a agile risk assessment (RA). The agile RA should be performed by a person in a “risk adviser” role in the crew itself. BigCorp will provide easy-to-use, automated asset risk profiling, issue identification, agile RA questionnaires, and other tools to agile teams and their risk advisers. We have provided them detailed prototypes of the required instrumentation.
After the agile RA, the risk adviser can determine risk treatment for “low”, “medium-low”, and “medium” level risks. However, risks rated at the “medium-high” or “high” level will require a business unit level security officer to formally acknowledge and approve the risk treatment approach. Medium-high and high risks will generally also require a focused risk assessment by a centralized Risk Team. Ultimately, the level of risk that warrants escalation to focused risk assessments is an expression of the organization (or business unit) risk tolerance, and should be codified as part of the overall risk management policy.
A “Traditional” RM Framework for MidCorp
As a financial services company, MidCorp is regulated more heavily than BigCorp and needs more formality in its security and risk management approach. Therefore, the generic version of the framework recommended for MidCorp looked a bit different once we added the COBIT 5.0 processes that MidCorp will map to.
Similarities and Differences
What is the same? In both cases, we’ve used the overall ISO 31000 framework and customized a risk taxonomy derived from Open FAIR for the client using their definitions of data sensitivity, application business criticality, and other terms. Note that we’ve recommended iterative issues triage, agile or lightweight RAs, focused RAs, and residual risk and control assessment processes for both clients.
What is different? Although similar processes exist in both frameworks, BigCorp plans to focus on pushing as much capability as possible down to the agile crews. MidCorp, on the other hand, may formalize the processes to align with the indicated COBIT 5.0 processes and the NIST Cybersecurity Framework (CSF). If, as we expect, BigCorp tries to make it’s processes “good enough” and MidCorp tries to keep its processes relatively lightweight they may end up not so far apart.
The most significant differences are the use of agile risk profiling and agile RAs at the agile crew level for BigCorp. BigCorp’s agile RA’s will be performed, in most cases, by non-security professionals assuming a part time risk adviser role. We made some adjustments to the BigCorp risk analysis taxonomy to automate RA processes and reduce the required skill level. BigCorp will need to incentivize, train, and manage its risk advisers to do this work. It must also integrate agile issues backlogs and operational risk registers with centralized Risk Team functions.
The Secret Sauce
For both clients, we have developed a sophisticated taxonomy underlying the risk assessment, control assessment, and risk treatment processes. This taxonomy describes how to:
- Define risk appetite and risk tolerance thresholds.
- Triage issues based on their severity and the risk profile of an asset.
- Measure risk based on the likelihood of a threat class exploiting a vulnerability to create an adverse impact (based on quantitative metrics).
- Prioritize and select compensating controls by balancing control strength with the cost of deployment and other factors.
- Map operational risks to strategic risk statements.
- Aggregate risks, compare risks, and identify systemic risks.
- Policy statements, process diagrams, risk advisory or risk exception memo templates
We tweaked the taxonomy for small teams in the agile environment by using simplified questionnaires that reduce, as much as possible, the need for a technical asset owner or a risk adviser to subjectively estimate risk based on technical security knowledge he/she isn’t expected to have. For the purposes of an agile or lightweight RA, we can get a rough estimate of likelihood by asking questions that team members know the answer to, such as whether an asset is Internet-accessible and to what kinds of users and devices. BigCorp can then run those answers through an automated or semi-automated tool to translate them into likelihood and impact should the risk materialize. Risks that exceed tolerance levels based on the agile or lightweight RA require focused risk assessment by a security/risk professional.
In conclusion, we’ve shown through the lens of agile risk management that agile security is NOT an oxymoron. Perhaps it’s just that agile development and delivery have forced us to do what we should have done all along. That is, to build role-appropriate security responsibilities into the work process so that security can become everyone’s responsibility.
Call to Action
The modern company MUST be agile enough, and it MUST manage risk well enough, to thrive in today’s challenging business, technology, threat, and regulatory landscapes. Don’t become a victim of inaction through thinking there is some dichotomy between agility and security. Solving agile security starts with developing an agile risk management process. We’re here to help and we’re interested in any questions you may have. Please feel free to contact us on agile security, risk management program reviews, identity management, and other topics we cover.
One Response to Risk Management in the Agile Environment