<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=160269078105920&amp;ev=PageView&amp;noscript=1">
This service has been removed!
Service successfully added!
Sign up for our blog, talk to a specialist, or just send us an email

DevSecOps: Continuous Security for your Delivery Pipeline

Tuesday 11 of September, 2018./ Reading Time: 5 minutes./ By Paolo Quintero

Our Business Software Dependency.

Nowadays, most businesses are software-driven. Some people even say that every company is a software company, due to the strong dependency we have on software systems that allow our business to meet customer expectations.

This software dependency brings many benefits, but it may also expose our business to potential internal and external security threats.

In this post, we’ll see how Devops and security testing practices can be merged, by adopting principles and best practices within our Continuous Delivery flow. This lets us work proactively to prevent possible threads, instead of waiting until our organization suffers a security breach to act on the matter.

100:10:1 Ratio.

According to research by James Wickett in 2012, the software industry usually shows a “100:10:1” ratio:

● For every 100 developers, there are 10 operation engineers and 1 security engineer in an organization

● It also means that there’s only 1 operation person for every 10 developers. This ratio is still valid even in big companies.

Based on these numbers, there’s a potential bottleneck in our software delivery cycle when security concerns are involved. Not only is there probably just 1 security engineer, but also because software development architecture is more complex than before and security testing practices are not that common when we talk about Agile.

Mix all the ingredients of this little recipe and you will have a delicious bottleneck with security vulnerabilities as toppings. If you want to further read about this, the book Agile Application Security written by Laura Bell, Michael Brunton-Spall, Rich Smith and Jim Bird is a great place to start.

3 Principles of DevOps Culture.

For us to counter the situation, we need to extend our DevOps culture and aim for a security-driven development, and make sure we follow these three principles:

● Design for the Worst Case.

● Test for Security across the Pipeline.

● Abandon the AppSec Training Fallacy.

These principles were discussed in the latest XebiaLabs conference about DevSecOps presented by Gene Kim, Rob Stroud and James Wickett.

Let’s dig into them to have a better understanding of what they mean, and the good practices involved in each one:

Design for the worst case.

You shouldn’t only think about the happy path when coding and/or testing because the end user probably won’t use our software in the same way we thought. We need to find creative ways to break our code, see how it reacts, and find the best way to mitigate the problems before they become issues. Here are some practices you can apply to work on this:

  •  Bulkhead pattern

Isolate parts of your application into pools, so that, if one fails, the others will continue to function.

Use a tool like Hystrix, so you can limit the number of concurrent calls to a component.

▪ If you have instances A, B, C of a component on your system and C starts to hang or becomes too slow to answer, eventually our app will hang.

▪ Hystrixcan limit the number of concurrent calls to C, so that it can be isolated, and have A and B handling the workload.

  • Evil User Stories

Think of test scenarios with the goal of finding vulnerabilities. Here we can implement Penetration Testing using BDD or the BDD-Security framework to help you create these kinds of tests easily.

  • Threat Modelling

Identify, communicate, and understand threats and mitigation within the context of protecting something of value. This includes:

▪ Design/model what you’re worried about.

▪ Define a list of assumptions that can be challenged in the future.

▪Define a list of potential threats to the system with their corresponding action items to be taken for each threat.

▪Define a way of validating the model and threats with the verification of success of action items.

The goal is to build a secure design, have an efficient investment of resources, and bring security and development together to collaborate on a shared understanding.

Tools like IriusRisk can help achieving this practice.

  • Mozilla Rapid Risk Assessments.

A fast and agile way to do some of the actions required on Thread Modelling. You can find additional details here .

Test for security across your Delivery Pipeline.

Even if you adopt the first principle, you would still need to integrate the specific actions into your Delivery Pipeline to ensure constant execution and get timely feedback. Some good practices we can adopt are:

  • Adversity Testing
Put in place your automated security tests and security attack tooling inside your delivery pipeline.
  • Security as Code

Map out how changes to code and infrastructure are made and find places to add automated security checks without introducing unnecessary costs or delays.

This will definitely involve developers following an “Infra as Code" approach to automate the provisioning of the infrastructure and ensure security checks.

  • Static Application Security Testing (SAST)
Tools for SAST like Fortify and Veracode can be easily integrated into our Delivery Pipeline.
  • Dynamic Application Security Testing (DAST)
OWASP ZAP can be used as a checkpoint in the pipeline,
  • Interactive Application Security Testing (IAST)

The mix of DAST and RASP (Runtime Application Self Protection) can help you identify the behavior of your application and any possible bugs.

Abandon the AppSec Training Fallacy.

Training our developers in good practices related to security matters is still an important thing to do, but at the end of the day, they are human beings and that implies that they are going to introduce a certain number of errors and security vulnerabilities.

We need to get support in the same way DevOps did for operation problems. The solution was not to teach developers to write operational code, but to add automation to the frontend and backend and use instrumentation tools while we work on the culture.

We need to take the same approach for security. We need to reinforce Code Hygiene. We don’t want to force it by people, but by our deployment system.

Gene Kim presented a study made in a software company where they analyzed the source code for the last 116 days and found that 282 commits broke the API. In other words, they had changed the interface and found that for any given dependency there was a 6.1% chance of a breaking change.

We can infer there’s a huge economic cost of changing dependencies, but we still need to upgrade our system every now and then. So, introducing practices like OWASP Dependency Check in our Delivery Pipeline will give us awareness of the impact of changing dependencies.

Conclusion.

DevSecOps is a great way to work on getting the performance, quality, and security levels that our development team needs to be successful in a world where software is driving business. There’s a lot to do, but it’s really important to clearly understand the issues we are facing to define our first steps towards a complete and effective DevSecOps Delivery Pipeline.

About Avantica.

If you are looking for a software partner who will work towards your own business goals and success, then Avantica is your solution. We offer dedicated teams, team augmentation, and individual projects to our clients, and are constantly looking for the best methodologies in order to give you the best results.

Let's start a project together

Join our newsletter

PREVIOUS
7 Things To Remember When Designing UX For Mobile
NEXT
Defining an Effective Regression Plan.

YOU MAY ALSO LIKE