Agile Security & SecDevOps Touch Points

Agile software development has gotten more and more attention in the last couple of years. Not only internet startups or media agencies but also large companies from conservative business lines like automotive, banking, insurance and public sector more and more adjusting to the agile world. Since those companies are often already very much security aware, at least from a governance perspective, the question of how to ensure security of applications that are developed in such a way has been asked more and more frequently in the last time.

First of all, agile is not bad for security. It is, however, in fact challenging. It can in fact be quite positive for security. This however, often requires not less than a mind change. Not only in the development but also in the security as well. The later one often just don’t understand how Agile security and DevOps actually work, which is of course essential when you want to secure it.

So let’s have a look on what agile development is in respect of security very quickly: Agile development means that you have product iterations instead of a linear process. These iterations are often two or four weeks long and end up in some sort of testable artifact. It does, however, not mean that you have a release in production every two or four weeks. In fact you can have an agile development project that works on two weeks sprints but just pushed two releases in production each year. On the other hand we have DevOps that is based on methods like Continuous Delivery and Continuous Deployment that can lead to a numerous changes in the production each day.

This is an important aspect from a security point of view: If a team is working agile but just releases let’s say two in a year, we can of course easily implement a security sign-off (aka final security reviews) in form of a pentest before each release. In a DevOps world, however, this will clearly not be an option.

Secure (Test) Automation

The more Continuous or DevOps you are working (= the more frequently you push releases into production) the more you need to automate security. This does not necessarily mean test automation, although this is of course an important aspect.

Security test automation often means that we run certain code scanning tools (SAST) or web site scanning tools (DAST) within the build chain to ensure security. Nowadays a large number of commercial and OpenSource tools exists that we can automatically executed as part of a build job from within a continuous integration server such as Jenkins. Since at least OpenSource tools are often very much focused on specific languages or problems, we usually have to combine a number of them to test an enterprise application. This is what we call AppSec Pipelines.

Sounds great, is however often quite difficult to implement, especially if you want to apply them to complex applications and/or a couple of agile teams at once. Also, if you have DevOps teams they may not be delighted to have a special pipeline that runs for 30+ minutes only for security scans when the usual requirement for a complete build chain is 5-10 minutes.

At least this point can be improved by setting up a dedicated security pipeline that runs once a day whereas small and smart security tests are defined that are allowed to be executed within the regular build chain. The bellow screenshot shows the implementation of such a pipeline with Jenkins:
agile-sec-pipeline2

IAST solutions can help here, since they are not executed within the build itself but scan the application passively as it is tested by regular integration tests. Such solutions are, however, not cheap and therefore not an option to everyone.

Secure Foundation

When you work a lot with security test automation like I do you realize that this cannot be the solution for security, especially not in Agile teams with or without DevOps. It’s an important pillar, nothing more. Tools need to be configured a lot, they need to be operated by someone, they will through false positives and a lot of false negatives (vulnerabilities that have not been identified).

If you want to solve this problem, you need to think about how you can prevent vulnerabilities from being introduced in the application code in the first place. This can be accomplished with smart technology choices (e.g. secure frameworks), strict coding principles, secure defaults and a security architecture that enforces as much security as possible. This is actually what we need to spend more time thinking about. Agile security will not primarily be solved by testing but by engineering!

You will realize that with a solid secure foundation implemented, you will not have to test for everything anymore. Instead you can now focus on smart tests that covers those spots not covered by your secure foundation, for example insufficiently implemented access controls. Such security tests are usually fast and can normally be executed with very little or now false positive behavior at all with every build.

Team Responsibilities & Agile Security Practices

Lastly, but not least important, agile security is not a problem that we can solve with technology alone. It needs to be understood as a responsibility of the team itself. Agile security is a lot about shifting responsibilities into the development team (e.g. tests, operation, …), security needs to be one of it!

Furthermore, security needs to be “agilized”, that means security activities needs to be planned by the project manager and must be a part of each sprint planning and retrospective. Instead of executing a full-fledged pentest we can specify that a new functionality needs to be pentested and create a sub task for this. Such security-relevant stories can be again collected and handled within one dedicated “security” sprint, so that we do not need to on-board a pentester for each sprint.

What has to be done within a sprint from a security perspective (e.g. executing a SAST scan and assessing the results) can be defined in the Definition of Done (DoD). Security User stories can be created and get story points and many more.
agile-flow_en

Conclusion

As mentioned above, agile and security are not mutually exclusive. In fact its quite the opposite: Agile practices can influence product security very positively. This however often requires a lot of work, technology and often nothing less than a mind change, not only within the development. Agile development needs to be understood by the security function as well. And, most importantly, security needs to be accepted by the agile dev teams as their responsibility.

About Matthias Rohr

Matthias Rohr, CISSP, CCSLP, CISM, CCSK, is Founder and CEO of Secodis GmbH. Matthias began working in this field in 2004 and is since a frequent speaker on international conferences, book author and an active OWASP constributor and recently published his first book. He lives and works in Hamburg / Germany.

This entry was posted in DAST, IAST, Java, SAST, Secure SDLC, Security Test Automation. Bookmark the permalink.

3 Responses to Agile Security & SecDevOps Touch Points

  1. Great post, most informative, didn’t realise devops were into this.

  2. Bruce Bading says:

    Agile was not meant for everything as is commonly the perception. Microsoft was one company forced to re-think its development methods and move to a more linear lifecycle with its OS.

    “Microsoft has embarked on a set of software development process improvements called the Security Development Lifecycle (SDL). The SDL has been shown to reduce the number of vulnerabilities in shipping software by more than 50 percent. However, from an Agile viewpoint, the SDL is heavyweight because it was designed primarily to help secure very large products, such as Windows® and Microsoft Office, both
    of which have long development cycles.”

    This is because agile was originally conceptualized for web and app development and not for large operating systems and applications such as Microsoft’s, much less mainframes. Gartner, Forrester, SANS, ISACA and other have similar articles. People and executives need to quit forcing agile into areas it does not belong and understand that a hybrid development process, not a one size fits all is needed.

    • Hi Bruce,
      I think I’m not qualified to say whether agile development does not work for other development fields as web and mobile to be honest. But enforcing security in agile development (and especially when its not only agile but continous delivery/deployment as well) clearly requires a lot of re-thinking work, both in the security department (in respect of understanding how agile/scrum works) and development itself (in respect of understanding that security is their responsibility as well).

      The lack of internal know-how, suitable security practices for agile development and the management attention for that are surely three of the biggest challenges that we at Secodis see many companies struggling at the moment. I do see a lot of hybrid development processes though – although this may be due to an internal transformation process in many cases. I cannot speak for other fields, but I do agree with you that concidering a non-agile methodology may sometimes be sensible at least from a security point of view – e.g. when a team is implementing a security critical component that requires a lot of (manual) security testing effort.

Leave a Reply

Your email address will not be published. Required fields are marked *