In my first blog on Continuous Security, an outline for three thematic areas, each containing two key capabilities was provided.  This blog will focus on the Construct theme and the capabilities of Design and Automate.

Construct is the place where most organizations start with when they are trying to add security into their existing software development processes.  Teams will use APIs or leverage CLIs to provide some kind of scanning capability that is done when code is committed and/or built. And then they will look for ways to make the results and feedback from those scans actionable.

It’s a great start.

But if we really want to Construct well, there is more to consider. Consider this:  you take a trip into the mountains and you find a perfect piece of land to build that dream cabin you have always wanted.  Do you just start by chopping down trees and building?  Of course not.  You start by planning.  There are permits to obtain, ground leveling that needs to happen and a foundation that needs to be built and set first.  There is a method and order to successfully building that cabin.

The same is true for software.

Many organizations have spent years collecting technical debt and are now fighting a daily battle between paying down that debt or creating new functionality.  Too often it seems, the time technical debt gets dealt with is when we are forced to. The pain and breakage of not dealing with it gets too great and things must change.  In contrast, successful businesses are the ones that can balance appropriately between these ideas.  What allows them to do this?  Paying attention to Design.

Design

In the architectural world, it is often said that “form follows function”.  This means that the way in which you make a building or structure is largely determined by what it will be used for.  The intention determines the invention.

In software we intuitively know we want the same thing, but we often operate with a narrow and limited scope.  We build a new feature or capability and we know what we want to accomplish with it, but we often lack the means or visibility to really see how it interacts with other parts of our systems.  And for security, that can present a real problem.

That is why, when it comes to Continuous Security, we need to include it right from the beginning of a project and all throughout the SDLC.  This means that our use cases, our hill statements, our user stories, our Kanban boards, etc. are all including specific aspects of security within them.  Gone are the days where we can have an epic that contains dozens of steps which outline how a given feature should work and then add a final step that reads “and it shall be secure”.

Doing great design is a team sport, and it requires multiple players.  If you are a developer – when was the last time you participated in a threat modeling exercise?  Have you ever paused to consider different ways your code might be compromised?   If you are a security professional – when was the last time you invited development teams to join you in your assessments?  Are you examining threats and risk in relation to the impact to the business?

Here are a few “Robservations” on Design that should help:

• Use Gamification in your threat modeling. This will help ease communication and avoid the blame game.  One great game you can use:  Elevation of Privilege (also available on github)
• Have Security requirements that act as constraints. Software deployments that do not meet security requirements should cause processes to stop until they are resolved.
  • This also means that you should allow ANYONE who finds a security flaw to stop a delivery or even shipping. This is the same idea as the famous Toyota plant andon cords, which permit automotive workers to pause production until an issue is corrected.
  • It’s much better to delay a release to fix a security flaw than to pay for it later through a data breach.
• Add Adversarial Use Cases to your projects and ensure they fail. For instance, consider the various steps and events that could lead to a breach and define those in one or more use cases.
  • As an example: In a given use case you might have a simple step like this:  “As a remote hacker, I can insert a malformed URL and thereby gain unauthorized access into this website”.
  • This will help teams to “think like hackers” and to routinely build more robust security into what they building.

Spending more time thinking through the security aspects of projects in the design phases will almost certainly shorten overall cycle-times, due to less time spent finding, prioritizing and remediating vulnerabilities later on.

Automate

When it comes to DevOps and DevSecOps, more often than not the Automate capability is where most begin.  It makes sense.  DevOps and DevSecOps are ultimately about realizing value sooner by getting trusted, reliable capabilities out quicker.  But Automate should not just be about speed.

At the core, WHY we automate is every bit as important as WHAT we automate.  Likely even more so.

For instance, suppose you want to include security testing as part of the initial validation of an integration build, before it is deployed to a quality assurance (QA) testing environment.  To do this, you decide to automate static analysis testing of the code stream before you allow the integration build to proceed.

You know that performing static analysis prior to the build is a great practice, but the key question becomes when and where to conduct it?  Do you run it in the build environment prior to kicking off the build?  If so, what does that do to your build time?  If your build normally takes 30 minutes, running a static scan at that point could potentially double your perceived build time.  And what do you do if you find critical vulnerabilities?  Do you prevent the build from running, or do you let it proceed, knowing full well that there are serious issues?  Or do you instead mandate that individual developers run scans and resolve critical issues before allowing them to commit?  If so, how do you enable developers to get issues resolved when they do not know how to?  Do you pair them with your security team?

All valid questions that should be thought through prior to implementation.

The point with Automation is that it is far more than simply running tests in a prescribed manner and reporting results.  Of course, tests should be run, and results should be reported.  But, adding automation in the wrong ways ends up hurting more than helping.  It can cause information overload or alert fatigue – or both.  Good automation looks at behaviors and decisions and seeks to eliminate friction and waste in our process.

Here are a few “Robservations” on Design that should help:

• Identify the bottleneck first. Those familiar with Eliyahu M. Goldratt’s Theory of Constraints (or those who have read The Phoenix Project),  will know that any improvements made to a process anywhere besides the bottleneck are an illusion.
  • Improvements after the bottleneck are useless because they’re left waiting.
  • Improvements before the bottleneck result in more pileup at the bottleneck.
• Start small. Don’t try to automate everything at once.  Doing so simply makes it much harder to measure the impact of automation at a single place in the process.  This makes later optimization more difficult to assess.
  • Identify where there are mundane manual processes occurring or a handoff between stages and add automation there.
  • Quantify the gain automation adds at that point.
• Measure Twice, Add Once: Just like skilled carpenters and artists, it is important to validate measurements to ensure that we are doing the right things.
  • Before adding additional automation to another point in the process, be able to confidently know the current process throughput and what the determining factors are. This will provide a great understanding of the system.

To Learn More

In this blog we focused on the Construct theme and the capabilities of Design and Automate.  In Part 3 we will examine the Intensify theme and the capabilities of Educate and Govern. For even more information about this topic, please watch the replay of our recent Webinar titled, “Go Beyond Application Testing to Continuous Security.”