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.

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 - 

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.

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

Access Control

Runtime

Configuration

Containers

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. 

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.