Now Available! Permit Elements. Learn More

  • Best Practices
  • IAM

DARCC - The five layers of Modern App Security

The DRACC framework is a DevSecOps methodology, which allows you to map the security posture of your application in a way that’s communicative, comprehensive, and shouldn’t take more than an hour or so to create.

Or Weis

Jan 03 2023
DARCC - The five layers of Modern App Security
Share:

Death to the Security Questionnaire

The DRACC framework is a DevSecOps methodology that allows you to map the security posture of your application in a way that’s communicative and comprehensive. It shouldn’t take more than an hour or so to create - effectively removing the necessity for filling out ridiculously long security questionnaires while allowing you to find security gaps in the solution you are building. 

How, you ask? Let’s dig in.

unnamed (4).png

The dreaded security questionnaire

The challenge 

As the software stack that we're building is continuously getting bigger, software gets more complex. We keep on adding more parts and layers to our software - all of which mean potential weak links being added to the chain, or in other words, many potential attack surfaces all over the plane.

The issue is it's tough to communicate these new attack surfaces to our customers, vendors, or between DevOps and security - leaving us feeling lost in the dark

Take the example of a startup in the healthcare sector - 

unnamed (3).png

The startup connects to an element deployed on the hospital’s side, which allows them to provide a machine learning-driven service. This service has both a backend part and a frontend customer-facing application, allowing patients and doctors to work on the produced data. 

They have data scientists responsible for training the machine learning model and integrating it into the interface, platform engineers handling the planning and development of the platform, and an R&D team responsible for constructing all the necessary elements.

Looking at this picture, you can see how valuable and sensitive data flows through the system and how proprietary aspects of the system, such as the model, can be translated into attack surfaces and vulnerabilities we need to deal with. Now try and imagine what it would take to give a detailed description of this picture to someone.

unnamed (2).png

Try to describe what's happening in this picture.

Trying to cover all of the areas will take a while, especially if we plan on connecting this system to other partners, vendors, or solutions - which is usually inevitable. 

This issue is extremely clear when you think about security questionnaires. Anyone who's ever built a product or SaaS offering is probably familiar with these documents - long spreadsheets you need to fill out just to communicate the baseline of how you do security and how your product looks. Filling one out can drive someone insane - they are stressful, annoying, and very hard to work with. 

With the plane and potential attack surfaces constantly growing, it's difficult to communicate them and find the gaps and potential weak points that need to be addressed.

This is where DARCC comes in.

The solution? DARCC - Death to the security questionnaire 

DARCC is a new methodology/framework that is focused on providing a quick, broad view of your DevSecOps status. It allows you to easily communicate the status of your system's security both within the organization as well as to your customers, all without having to fill out absurdly long security questionnaires. While DARCC allows you to view the overall picture, it also enables you to ensure every aspect of your system adheres to best practices and easily translates into understanding which tools you need to apply to avoid potential issues.

DARCC consists of 5 basic layers which exist in every application. If all five are covered properly, you should be able to avoid any potential security vulnerabilities. These are -

Dependency | Access Control | Runtime | Configuration | Containers

⁠Let’s dive into each of these layers to understand it better. Handling each layer requires us to answer a different question, so let's dive into those - 

Dependency

Supply chains are a really hot topic right now, and managing the dependencies of the software we're providing is a critical thing. We basically want to ask ourselves, 

How secure is the software supply chain that we're depending on? 

Access Control 

How do we connect other people, services, or identities to what we are building, and are we doing so securely?

Runtime 

How do we know that the software that we've built is going to behave the way that we expect?

Configuration

How do we know that we've set and configured the software that we're deploying to run in the way that we expect and want? 

Containers

How do we set up the containing environment? How do we ensure that our software runs within the intended box/servers/cloud in the way it is intended to work?

The best practices

Now that we have our layers in place, we need to pair those with best practices. These will serve as our light in the dark, as they will provide you with an understanding of any potential gaps in your security. Each of these best practices is relevant to every single layer we listed previously. These best practices are: 

Manage as Code | Zero Trust | Event Driven | Decoupled | Unified View | Approachable 

So what does each of these mean? 

Manage As Code

There is a very mature ecosystem that allows developers to manage complex things as code. Translating complex concepts into code (IaC, Config as code, Policy as code) is huge right now, as managing them with GitOps saves us from reinventing the wheel.

Zero Trust

Also a very common best practice, each component has to stand securely on its own, answering the weakest link principle, with a need-to-know basis baked into all of its layers. 

This will really affect how we compile or build the software itself and how we connect different software components to one another. 

Event Driven

Being event-driven is a necessity of every modern application. If your software is moving too slowly, or if it is unable to respond to changes in customer demands or infrastructure, you will have a bad time. Modern systems mutate in real time; your security needs to match.

Decouple

A classic principle from software development, you need to ensure that only the necessary parts are bundled together and that you have the tools to do so. If you abstain from doing so today because the software seems too complex - you’ll end up with spaghetti code or spaghetti architecture tomorrow. Coupled components are harder to monitor, track, and upgrade, making them harder to defend. 

Unified view

Having this will allow you to monitor the entire layer in a way that is easy and aggregated so that you can connect it to other systems. Modern systems are often distributed - so we need to aggregate and unify views on top of them.

Approachable

Everyone is becoming a developer, and every stakeholder has to be involved in security. This means we can no longer apply security as an afterthought, and we need developers to be able to access it in a way that is comfortable for them to use. Not only that, but we also often need to enable the product, security, compliance, sales, and support teams, to chime in on our security posture or at least be part of the conversation. Modern security can’t be left just to the CISO or developers - everyone needs to be able to contribute.

Now we will see how these best practices can be combined with the layers we mentioned earlier. For each layer in DARCC, we’re going to look at each of the best practices and ask ourselves: How are we implementing the best practice? And more importantly, Which tools do we have in our arsenal that allow us to do so? 

The Breakdown

Here is a detailed breakdown of each DARCC layer, with tools that we think are worthwhile knowing to apply these best practices. 

Dependency

Best Practice

Implementation / Method

Tool 

As Code

SBOM manifests

SPDXSnykCloud

Zero Trust

Minimize; silo; limit

Build tools, Snyk

Event Driven

CI/CD

Decouple

Each service is siloed

Unified View

Dev Portals

BackstageGetPort.io

Approachable

Dev Portals

BackstageGetPort.io


Access Control

Best Practice

Implementation / Method

Tool 

As Code

Policy as Code

OPACedarPermit.io

Zero Trust

Policy Decision Point

OPAOPAL

Event Driven

Policy update stream

OPALSpice DB

Decouple

Policy from Code, Code from Data

OPAOPAL

Unified View

Audit Logs, Decision Logs

Logging, Permit.ioFrontegg

Approachable

Low-code Control Interfaces

Permit.io

Runtime

Best Practice

Implementation / Method

Tool 

As Code

Policy as Code

GateKeeper

Zero Trust

Containers

Docker 

Event Driven

RASP, WAF

Falco

Decouple

Security tests standalone (SAST,  DAST)

Snyk Code

Unified View

SIEM

Approachable

Security Control Panel

Know one? Let us know


Configuration

Best Practice

Implementation / Method

Tool 

As Code

Configuration as Code / Infrastructure as Code

Terraform, Pulumi, Helm

Zero Trust

SDLC policies

ConftestDatreeCheckov

Event Driven

Gitops

Decouple

Config loading hierarchy

E.g. Python’s Decouple

Unified View

Configuration Management

Configu

Approachable

Dev Portals

BackstageGetPort.io


Containers

Best Practice

Implementation / Method

Tool 

As Code

Infrastructure as code

Docker-file, Helm charts, Env0

Zero Trust

Provenance and Integrity

Helm, OCI signatures

Event Driven

CI/CD

Decouple

Compute, Infra, Container

Cloud Services

Unified View

Services inventory

DataDogPrometheus

Approachable

Containerized Envs on demand

Raftt.ioVelocity

This breakdown provides an example of tools we can utilize to manage all of the best practices we need to apply to each layer, giving us a full overview of our company’s security posture, with all its potential gaps. 

unnamed (1).png

An example of a “DARCC Map” mapping each tool used to achieve best practices

Who should be using DARCC? 

DARCC is relevant for anyone building software (Developers, DevOps, SREs, AppSec) and everyone managing the overall picture (Architects, Security Analysts, AppSec, the management team) and it can be a valuable tool to speed up processes on both those sides. 

For management, this can be a guiding principle. Whether you’re building something new, refactoring something, or working on new architecture, you can start with a DARCC map to quickly highlight where you have answers and where you have gaps you need to address.  

For developers, DARCC is foremost a checklist. When you build something, you want it to be secure, and by going through the DARCC map you can make sure that you are addressing every part of the security landscape. 

A DARCC map can also be a great way to communicate your security posture as part of your docs. As much of the documentation for SaaS offerings nowadays tends to include a section on security, having a DARCC map as part of that security section could significantly speed up someone's ramping up into the project and finding the answers they need to make sure your product is up to their standards. 

A DARCC map can be used as a baseline for a SWOT analysis to identify your strengths, your gaps, and where you need to invest your time when dealing with technical debt. 

It can also be a base to decide which tools you need to invest in, knowing what you have in place, knowing which gaps you have, prioritizing them, and understanding which ones are more critical and which ones you need to bring in next. 

Eventually, this DARCC map will look different depending on how you build and run your software and the interaction that you have with your vendors and customers. Regardless, creating this type of map for an average midsize SaaS offering would probably take you not more than a few hours and will provide you with a tool to communicate internally, share it as a part of, or even eventually, instead of a security questionnaire, and most importantly the ability to find security gaps in the solution you are building. 

For a more detailed overview of this methodology, with a specific example of how you can apply this to what you are building, check out Or Wies’s full DevSecCon talk here

Or Weis

Co-Founder / CEO at Permit.io

decorative background