Factorial Separation of Duties for Modern AppSec Compliance

What's on the other side of the mountain?

The place where the customers and users of our software applications are; it's what's driving our organizations to climb over to the other side.

Traditionally, climbing was the only way to cross a mountain pass. We form a plan because it's a risky endeavor. We pull together our supplies, wear our packs, familiarize ourselves with our guide, set up a meeting location, and then start our journey. The first target is base camp, the first of many waypoints and stoppages. If you enjoy mountain climbing or have read or watched content about it, this may sound familiar.

With today's technology we can ride in a car instead of a risky climbing endeavor. So how do we, as technologists, help get the software to the other side of the mountain faster? I would say, build a road. Or better yet, use the roads that other technologists have built so that we do not have to build our own.

What about the guides, support staff, and staging camps that we absolutely depended upon to keep us safe and transport supplies? The majority of organizations are stuck driving around roads built between the staging camps. This is our current state of manual gates for QA (quality assurance) checks for software pipelines – we have automated very well up to each transition point in our development pipelines.

How do we build a better metaphorical road for our software factories and pipelines to avoid costly stoppages? We build the guardrails and safety checks to keep us safe on the road if we have to veer for any reason. When it comes to technology guardrails we can accomplish this via Factorial Separation of Duties (SoD).

“Factorial separation is applied when several factors contribute to the completion of the activity. (For example, two-factor access authentication.)” - Baykara

How do we do that?

We perform risk reduction to help mitigate errors, deficiencies, inaccuracies, irregularities or corruption. We divide up our tasks to be completed, our undertakings and activities, as well as decisions and transactions. This division is one of the primary principles of SoD.

Factorial SoD enables product managers, development teams, security teams, operations teams and business leaders, to ensure that their responsibilities and concerns are met. How do I know (regardless of where I sit in the organization) that the new code being merged into our trunk is functioning and safe to run? Let's factor our risk out.

Risk Modeling Framework

A code merge can combine newly developed code and additional third-party code, typically Free/Libre and Open Source Software (FLOSS). Let's model our roles, concerns, and risk reduction activities:

We are missing one critical component of our model, which is risk management thresholds. Not everything is binary and it's how the role holder knows the activity satisfies the concern put forth. Thresholds will allow us to perform an activity without an absolute 100% reduction of the risk.

Let's pick on our FLOSS code for a bit. We put in vulnerability and licensing checks to be executed, with thresholds to meet, to satisfy our concerns. I am a cybersecurity professional (my role), and I'm concerned about high and critically-defined FLOSS vulnerabilities residing in my code that is executed in production. Once the FLOSS scanners check for our concerns and if they meet our threshold (no critical or high issues), we are satisfied.

Real-World Implementation

An example within The DevOps Audit Defense Toolkit pertains to committing fraud within code functions. Protections, such as dual-developer or peer code reviews, and handling new code are put into place followed by FLOSS and static code analysis, with each rule set for analysis approved by the Change Approval Board (CAB).

Allowing developers to code and release to production is analogous to allowing the driver of the car to be in charge all alone up the mountain, bypassing those stopping points. How can we trust the driver with our important product, get it to the customer, and get it back again with payment?

These safeguards are our responsibility because we live and work in the age of the Shared Responsibility Model from cloud providers. We gather our resources from others that have done it before and done a decent job at it, just as we bring in FLOSS to handle some of the extremely common components.

Factorial SoD allows us to have visibility into the safety checks that go into the automated workflow of developing applications in our dynamic, modern era.