"Software security" often evokes negative feelings among software developers since this term is associated with additional programming effort and uncertainty. To secure software, developers must follow a lot of guidelines that, while intended to satisfy some regulation or other, can be very restricting and hard to understand. As a result a lot of fear, uncertainty, and doubt can surround software security. This blog posting describes how the Rugged Software movement attempts to combat the toxic environment surrounding software security by shifting the paradigm from following rules and guidelines to creatively determining solutions for tough security problems.

Rugged software moves from prescriptive restrictions to a set of DevOps principles. Emphasizing a set of DevOps principles enables developers to learn more about what they are developing and how it can be exploited. Rather than just blindly following the required security measures, developers can understand how to think about making their applications rugged. As a result, they can derive their own creative ways to solve security problems.

As part of understanding the challenges associated with secure software development, rugged software developers look more at how their software responds in all kinds of situations. Rather than reacting to new attacks, rugged software should be proactively focused on surviving by providing reliable software with a reduced attack surface that is quick both to deploy and restore. In other words, developers worry less about being hacked and more about preventing predictable attacks and quickly recovering from being hacked.

In the past, software security focused on anticipating where and how the attacks would come and putting up barriers to prevent those attacks. However, most attacks--especially sophisticated attacks--can't be anticipated, which means that fixes are bolted on as new attacks are discovered. The inability to anticipate attacks is why we often see patches coming out in response to new 0-day vulnerabilities. Rugged software developers would rather their software absorb the attacks and continue to function. In other words, it should bend but not break.

This shift in thinking from a prevent to a bend-don't-break mindset allows for a lot more flexibility when it comes to dealing with attacks. In a rugged world, things can be dropped because they will survive the fall and bounce right back up. Becoming rugged requires the development team to focus on continuous integration, infrastructure as code, eliminating denial of service (DOS), and limiting the attack surface.

Continuous Integration

Building software should be automated and repeatable. These attributes can best be achieved through continuous integration, or continually merging source code updates from all developers on the development team. When a software development team is able to reliably, quickly, and easily integrate their code, they will be able to focus on creating robust, rugged code rather than having to worry about integration. In addition, they will be able to rule out integration issues when debugging, decreasing the time and effort required to find and fix bugs. Quickly deploying a fix means quickly patching holes and quickly improving security.

Infrastructure as Code

Software tests and infrastructure should be easy to validate and not left to the whim of whoever is setting up the infrastructure or performing testing. The whole team should be able to review exactly what is going on when the infrastructure is being set up and the code is being tested. Infrastructure (and testing) as code is an example of a means to make infrastructure easy to validate.

Eliminating Denial of Service (DOS)

The fact that DOS attacks are often easy to launch and can be expensive to defend against makes their elimination a tricky thing. Quite a few people have talked about eliminating DOS. Symantec has an article, and Rugged Software has a Rugged Implementation Guide. Even though DOS attacks been around for quite a while, they are not abating. Moreover, they still manage to do considerable damage, which means it is important to have a solution to this problem.

Limiting the Attack Surface

Finally, it is very important to limit the attack surface (i.e., the amount of your application that is exposed to nefarious individuals attempting to exploit weaknesses) of your application. Limiting the amount of your application that is accessible to possible attackers limits the number of attacks that your application will encounter. For more information on how to go about limiting your application's exposure, see SANS and the InfoSec Institute. Concentration on exposing as little of the application to the outside world as possible allows the developer to focus security testing on a smaller piece of the application. Doing this at an early stage in an application's development means that the exposed part has a greater chance to undergo more testing and become more resilient.

Continuous integration, infrastructure as code, eliminating DOS, and limiting attack surfaces while developing a software product will all help to make your product rugged. While this doesn't mean that this product is immune from security problems, it does give it a leg up on other products that aren't rugged due to the added resiliency that these techniques provide. Your product will be more likely to survive and thrive in a dangerous world.

Every two weeks, the SEI will publish a new blog post offering guidelines and practical advice for organizations seeking to adopt DevOps in practice. We welcome your feedback on this series, as well as suggestions for future content. Please leave feedback in the comments section below.

Additional Resources

On April 9 at 1:30 p.m. ET, Aaron Volkmann and Todd Waits will present the webinar Culture Shock: Unlocking DevOps with Collaboration and Communication. To register for the webinar, please click here.

To listen to the podcast, DevOps--Transform Development and Operations for Fast, Secure Deployments featuring Gene Kim and Julia Allen, please visit https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=58525.