5 Ways RiskLens Supports DevSecOps and Agile Development with Cyber Risk Quantification

June 29, 2020  Tyler Britton & Taylor Maze

The most common use cases for RiskLens, the only cyber risk management platform purpose-built on Factor Analysis of Information Risk (FAIR™), tend to be centered on risk prioritization and cost-benefit analyses. But for our clients running Agile and/or DevOps for software development, RiskLens can also play a central role in DevSecOps.

The prioritization and decision-support abilities make the RiskLens platform an ideal solution for integrating cyber risk management into Agile based production pipelines, enhancing DevOps quality as well as strategic efficiency. With economic, risk-based prioritization of feature development, bug remediation, and control implementation, the RiskLens platform provides a better alternative to the ad-hoc way in which Agile development is currently managed. It’s also a necessary reality check on risk, as companies move rapidly ahead on their “digital transformation” projects.

Here are five different use cases in which RiskLens enhances the development process.

1. Effectively Prioritize Bug Remediation Backlog

One of the most tedious and exhausting aspects of software development is the seemingly never-ending bug backlog. The backlog may be dozens or even hundreds of items deep, making it impractical to address all of them in one sprint. At the same time, pressure is always on from management to push new features vs. going back and fixing issues.

While it is likely equally impractical to do an in-depth quantitative analysis on each and every bug in order to prioritize, there is still a way RiskLens can help alleviate this burden: Triage through the Rapid Risk Assessment solution on the RiskLens platform.

A Triage is a high-level analysis that typically takes 30 minutes or less to complete. It is an effective means of prioritization and also helps to weed out which items require a deeper analysis (as referenced above).  By doing a Triage of your bug backlog, you can quickly identify which bugs represent the highest potential risk to the organization and prioritize those accordingly in the sprint planning process. 

This rapid quantification and prioritization optimize the efficiency of the Software Development and Quality Assurance Teams by enabling them to focus on what matters most. It also creates an opportunity to revisit the strategic objectives of the platform/organization and make sure that the decisions made within each sprint align with the strategic business objectives: cost/benefit, value, and the bottom line.

2. Align Sprints with Strategic Business Objectives

Adopting FAIR with RiskLens is a high-level strategic decision to integrate cyber risk programs into the general business unit. By taking an objective, quantifiable approach to planning your sprints, you can ensure that projects align with the goals and vision of executive management for the direction of the company.

When RiskLens is used at the Operational level (e.g., sprints), it creates a feedback loop to answer all-important strategic cyber risk management questions related to return on investment:

  • Do we spend less on cybersecurity than the amount of exposure we reduce?
  • Are there architectural, engineering, or operational changes that are more cost effective than currently?
  • Are we over-engineering cyber controls (i.e., spending too much)?
  • Are we best prioritizing resources (person hours, investments)?

This is contrasted against how we typically see sprints conducted: on an ad-hoc basis or simply within the bubble of IT with only loose ties back to the business and the vision of executive management. Using RiskLens to plan sprint and sprint production pipelines necessitates planning from a standpoint of strategic business objectives, namely, ensuring that each sprint provide measurable business value.

3. Integrate Cyber Risk Reduction into Sprints to Maximize ROI

Using the RiskLens platform, you can create a parent or baseline analysis that serves as the “current state” of a given system, etc. From there, you can make iterative changes to the baseline analysis in order to model upcoming changes in the pipeline. These iterative updates typically take less than 5 minutes and allow you to show how risk exposure trends over time in relation to your sprint planning.

For example, imagine you are working on a sprint to implement 2FA into the remote collaboration platform you are building. In order to understand how the additional control will impact your overall risk (see What Is Cyber Risk? The FAIR Definition), you consider how it will impact the frequency and/or magnitude of the loss events you are concerned with.

You may expect, for example, that implementing 2FA will reduce the platform’s susceptibility to external actors gaining access via social engineering and credential theft to breach the confidentiality of the information contained within the platform. You compare your baseline risk (prior to 2FA implementation) to your future state risk (post 2FA implementation) to determine the amount of risk reduction you have achieved.

While that example involves a security product, this process applies equally to any increment in the Scrum process. If you expect a direct increase in revenue of $X from some added functionality, you can run a RiskLens/FAIR analysis to compare that increase to the change in loss exposure (positive or negative) for a full picture of your ROI, and taking into account your risk appetite.

4. Effectively Prioritize Sprint Functionality Production Pipeline

Now that we understand how to use quantitative risk analysis powered by RiskLens to evaluate the risk vs. reward value provided by sprints, the next logical step is to use this information to prioritize the sprint functionality production pipeline. By doing so, you can evaluate each potential sprint under the following criteria:

  • Does the functionality reduce the platform’s overall risk exposure? If so, to what degree?
  • What value does the sprint provide? How does that relate to the effort required to facilitate the development (i.e. ROI?)
  • Does the additional risk posed by the functionality outweigh the expected value? If so, are we willing to accept the additional exposure?

Following the evaluation, you can prioritize your sprint initiatives based on their overall ROI, rather than addressing them on an ad-hoc basis or based on a schedule built purely from a project management standpoint with no true reliance on the objective value provided.

Taking a rigorous analytical approach will also help to weed out ineffective sprints that either

  • Do not align with strategic business vision, leading to outputs with little long-term value or
  • Pose increased risk that negatively affects long term value of output

5. Quantify, Monitor, and Mitigate Incremental System Risk

The final core benefit we identified is ultimately an amalgamation of them all: FAIR provides the ability to understand how each sprint affects overall risk. Each and every change, functionality upgrade, system scope upgrade, bug remediation, etc. provide some degree of value while also having some impact on risk exposure. This means that, practically speaking, risk exposure should be a critical point of consideration when evaluating the value of a given change.

In addition to having the ability to understand the hidden costs associated with each sprint (increase in exposure) this also allows for the ability to take a risk-based approach to platform usability planning and policy. For example, if you determine that allowing for the storage of personally identifiable information (PII) in the platform will result in $2.5M in increased risk, you can use that as evidence when determining what type of data storage is appropriate. Similarly, this allows for more open dialog with business stakeholders as you can clearly articulate how the features they are requesting will impact the bottom line, thus bridging the gap between business and IT.


Adopting FAIR Risk Analysis in Agile and DevOps Environments with RiskLens

If you are ready to take a more rigorous and objective approach to Agile development, the important thing to keep in mind when adopting is to take a proactive risk approach, not reactive. On that note, FAIR should be paramount to each and every sprint planning phase, including:

  • Platform planning/ideation
  • Sprint production pipeline planning
  • Individual sprint planning
  • Bug remediation planning

In terms of how to actually apply the quantitative approach, Triage through Rapid Risk Assessment on the RiskLens platform provides an excellent alignment of the benefits of FAIR and the fundamental concepts of Agile development: efficiency, collaboration, and iterative improvement. This flexibility and quick turnaround make it ideal for the prioritization decisions required in sprint and bug remediation planning.

While the majority of sprint decisions may be solved by a quick Triage, others may require a deeper understanding. This is where full detailed analysis will come into play. We see in-depth FAIR analysis on the RiskLens platform being used on important decisions, such as whether to take on new service or make major functionality change. This will ensure that important decisions do not cause undue risk, thus aligning sprint production with strategic business objectives.