I’ve coached a number of organizations, mostly Federal Government, where securing the application and its infrastructure is a primary concern. Most information security offices seem to struggle with how to improve the organization’s security posture when working with Agile teams. The traditional phase-gate approach allowed them to perform their security testing at the end and identify corrections for the application teams to make. Delays in production deployment and lengthy test-fix cycles were just expected. Security requirements were spelled out in policy documents and referenced in team notes or some other documentation and passed to the application team. In such an environment, the business—often represented by a Product Owner on Agile teams—has little say in what is actually needed when.
The challenges grow as product development efforts scale up to meet increasing demands. With a series of Agile teams, the traditional approach breaks down. Information security personnel can’t keep up with demand, particularly if they try to embed testing into iteration cycles or frequent releases. Many organizations are embracing DevSecOps as means to scale. What are some immediate steps that your information security offices can take to enable success? In this post, I’ll discuss three ideas: security policies becoming user stories and/or acceptance criteria, dark stories (and automating them), and continuous delivery of hardened servers.
Creating User Stories for Security Policies and/or Acceptance Criteria
I’ve written on the details of this before (with regards to NIST 800-53 based controls), but it is worth mentioning the idea again. Essentially take your organization’s security controls and rewrite them as user stories with acceptance criteria, or, if they are broad-based controls that apply to other functionality, make them acceptance criteria for the user stories to which they apply. The policy may be based on the NIST guidance or some other information security policy that your corporate information security shop may have created.
There are several benefits of this approach; with it, the security controls:
- Become attached to business value, not just a security standard. This in turn gives the business an attachment to security.
- Become easier to understand. Many security policies can be cryptic and this helps them be expressed in plain language.
- Can be put into specification by example scenarios using the Given-When-Then format; this allows automated acceptance tests to be written around them, a form of behavior-driven development (BDD).
- Can be negotiated more easily when they are difficult to implement. Embedding security controls in stories creates a trade space. Challenging security stories/acceptance criteria can be put off to future iterations or when more funding becomes available. This is particularly useful if the originating security policies can be correlated to specific threats (e.g. insider threat of attempting to gain access to unauthorized data). The user stories will have the same correlations and that makes the trade space more understandable.
Using Dark Stories (and Automating Them)
User stories can also be written from the point of view of a bad actor; these are often called dark stories. Don’t confuse them with “dark work,” which is a name for hidden requests that teams fail to visualize. Dark stories harden the system against bad actors like hackers or inside threats; they can be represented by personas or specific roles if necessary. These stories have business value based on what they prevent: the team protects business value by thwarting bad actors from achieving their end goals.
Dark Stories can be written as user stories and automated using various penetration tools or other mechanisms. Creating automated routines around dark stories allows these tests to be driven by automated acceptance tests and BDD. This complements the use of security policies as user stories because these are two very different perspectives that aim to achieve a similar level of protection. Security stories tend to focus on the application, while dark stories are more often geared towards the supporting infrastructure.
Here are some benefits to using Dark Stories:
- The dark stories can be linked to business-focused stories and prioritized together. This helps couple the functionality with the appropriate protections. Dark stories can also be prioritized independently, based on the protections they enable.
- Different penetration methods can be automated to test dark story scenarios. Some may be extremely expensive to simulate. When that occurs, we can use alternatives to generate the necessary tests.
- Dark stories, just like security stories, are written in plain language. This will promote shared understanding and can make it easier to get the business to support working on them.
- We can automate the testing of dark stories with a BDD tool and tie it into our continuous delivery pipeline.
Continuously Delivering Hardened Servers
Security professionals frequently find themselves strapped for time and having to make prioritization decisions about what vulnerabilities and potential threats to address. Patching operating systems, finding unnecessarily open ports, and removing unneeded libraries are just some of the things they have to do to address potential vulnerabilities. Often, the work of security is reactive because security professionals are out of the loop when development is occurring. They are only pulled in after the application has been built. This can lead to delays and rework as mistaken assumptions about the use of ports, libraries, and the like are addressed.
An alternative approach is to have your information security office build out secure images and make them available to your application teams. This can be challenging because there may be many different operating systems and infrastructure components required for your solutions; a database server, for example, may have very different requirements than an application server and systems exposed to the internet may have different needs than those behind a DMZ. Creating up-to-date, hardened images for all these systems is difficult.
Automation to the rescue! Build and configure your servers through automated scripts (including compiled source code if using an OS like Linux) and run penetration tests and other security checks that validate their configuration. When the servers pass these automated tests and meet the desired security threshold, the associated image can be made available to teams for their environments: development, test, staging, and production. By creating a pipeline of hardened images for your different servers, teams don’t have to worry about ensuring they have the right configuration with the proper patches. This accelerates testing and validation, and with enough automation, you should be able to effectively test the security of your solution within an iteration.
There are many advantages to creating a hardened image pipeline:
- Reduced dependence on application teams implementing changes (e.g. patches) correctly.
- Effective integration of security with teams delivering business value, increasing collaboration and cooperation.
- Increased capacity to support different types of images for different purposes, allowing greater flexibility with the solution design and architecture.
How Does This Relate to Scaling?
If your organization has a large portfolio of applications, security policies and appropriate protections have to be implemented across them all. This creates a significant burden for your teams. For application teams, the problem is additive. Each team has to enable these protections and apply them consistently. For your information security office, however, the problem can grow geometrically. As you scale, they have to support more and more teams, and they are unlikely to get the time and money necessary to continue to use their established procedures. Instead, they will require new means to promulgate and maintain your security controls. By approaching it in ways that the business and application teams can understand, and by automating much of the testing and infrastructure, they can keep up with demand while you scale and simultaneously enhance your organization’s security posture. If you’d like to learn more about how we’ve applied these patterns successfully for our clients, please contact us. We’d be happy to help.