One of the luxuries of my job is that I get to speak to and work with a range of IT people employed by U.S. federal and state government agencies. That range includes DevOps engineers, developers, sysadmins, database administrators, and security professionals. Everyone I talk to, even security professionals, says that IT security and compliance can be imprecise, subjective, overwhelming, and variable—especially in the federal government.
The plethora of policies, laws, and standards can be intimidating in aggregate. Here is a short list:
- Authorization to Operate (ATO)
- Federal Information Security Management Act (FISMA)
- Federal Risk and Authorization Management Program (FedRAMP)
- Department of Defense Cloud Computing Security Requirements Guide (DoD SRG)
- 508 Compliance
Additionally, what it means to be secure or compliant changes from agency to agency, and even between authorizing officers within a single agency, based on a range of factors.
Many developers ask how newer technologies and behaviors like infrastructure as code (IaC), continuous integration/continuous delivery (CI/CD), containers, and a range of cloud services map to compliance frameworks and federal security laws. As a developer, you're often wondering what your security responsibility is right from the beginning of the software development lifecycle, and you might still be wondering all the way into production. Trust me when I say that you're not the only one who is wondering.
This article is dedicated to helping you, the developer, understand more of the standards so that less is unknown and variable. The ultimate goal is to make security more precise, establish known responsibility (and gaps in responsibility), and incorporate security into your daily workflow—even when the requirements and how they are interpreted change from project to project.
Share responsibility and inherit when you can
Start by establishing that it's not your job to cover it all (or, to say it another way, don't try to boil the ocean). As a developer in the enterprise, it is impossible for you to deliver secure code, configure operating system images, monitor the network, and scan filesystems. If you try to do all of that, you'll spend far less time securing the components that you are responsible for—source code, application dependencies, and testing—and you'll spread yourself too thin.
The number of platforms and vendors that offer reliable, reputable options for services and products has never been higher, and it is still growing. Infrastructure cloud providers supply resources like compute, network, and storage provision, while software vendors typically provide supported container images for their products.
The lesson here is to inherit the responsibility that these platforms and vendors assumed for securing an information system. Doing that allows you to check off a significant number of security controls during the ATO process. In the case of patches or responding to security incidents, these providers (not just you) are on the hook to deliver.
This doesn't mean that you should stop talking to ops and infosec, or that you can place all of the blame on them if an internal, enterprise service they've provided fails. If anything, it means you should work with providers of all types that welcome your collaboration. Intentionally share the responsibility for managing risk. Having an established RACI matrix supports clear communication and assignments of responsibility between developers, operations, and security teams. It enforces the behaviors necessary to generate a successful DevSecOps culture.
Embrace the world of continuous security
If you're still doubting when it's important to focus on security in the areas that you are responsible for, then do it all the time. Rather, do it continuously.
Authors Gene Kim, Nicole Forsgren, and Jez Humble did everyone involved in enterprise software delivery a big favor with their book, Accelerate: Building and Scaling High Performing Technology Organizations, which measures the behaviors that lead to overall organizational performance. Using data collected from enterprises of all types, the book proves that behaviors like continuous delivery and continuous security lead to a more collaborative culture and overall improved organizational performance. As the book states:
"Teams that build security into their work also do better at continuous delivery."
In other words, your organization will reach its goals and deliver better software if you build security into your daily work. Continuously performing security activities and behaviors forces you to learn as you go. It also forces you out of bad behaviors like leaving SSH keys lying around in a repository.
The DevSecOps Reference Design, authored by the U.S. Department of Defense, is an excellent resource for identifying what security steps to apply during specific software development lifecycle phases to support continuous security. Among other things, the guide recommends:
- IDE security plugins that scan source code as the developer writes it.
- Static source code tools that scan code before commits.
- Source code repository security plugins to check for things like authorization tokens, SSH keys, and passwords.
- Container registries with security-scanning frameworks that can identify vulnerabilities in container images.
- Dependency checks for applications using potentially vulnerable open source libraries.
- Dynamic and interactive tools that scan applications after they've been built.
- Manual penetration tests that mimic an attacker and might discover vulnerabilities not uncovered by another tool.
- Continuous monitoring solutions that identify threats at runtime and persist event logging for analysis.
Get involved in choosing your tools
Telling a developer to be picky about tools kind of goes without saying. Nevertheless, I've had conversations with too many developers who think that information security is someone else's job. It's everyone's job.
Because developers are responsible for security, it's important to have a choice about the security products used during the development, building, and testing phases. In Accelerate, authors Kim, Forsgren, and Humble argue that choosing the correct tool is technical work. "When the tools provided actually make life easier for the engineers who use them, they will adopt them of their own free will."
Security will be more precise if it's surrounded by the precision of your existing work, such as the security plugins for your favorite IDEs or the scanning tools that are just another component in your CI/CD pipeline. If a tool gives you faster feedback, if it takes less time to use than remediating a vulnerability later in the delivery cycle, then you are more apt to use it. Choose the right tools to incorporate security into your daily work.
Tech is evolving, but security principles don't
Container orchestration, serverless platforms, intelligent security tooling, and automated deployments might be changing how we scan for vulnerabilities or patch an application in production, but that doesn't change the fact that security is still more about the process than the products, or that defense-in-depth still reigns supreme for securing an information system. There is a good reason that the National Institute of Standards and Technology's special publication on security controls includes 18 different control families or categories on security. Everything from how you encrypt sensitive information to where you put the fire extinguishers matters to information security. New technologies for cryptography and fire management are surfacing all the time.
If anything, the best practice is to have an open mind to new technologies that could help you address security concerns in your organization. Automated configuration management, container orchestration, and immutable infrastructure all make it easier to consistently and repeatably configure information systems. IDE security plug-ins and container registry security scanning help to shift security "left" by enabling developers to identify vulnerabilities early rather than during a security review that occurs downstream.
These tools don't remove the need for standard security principles like security confirmation management and vulnerability scanning; rather, they allow you to focus your attention on where you most need to analyze and manage risk.
Education is the silver bullet
Just like software security and delivery, learning should be continuous. New tools help to manage security prevention and response, but attackers are also continuously innovating and learning. There are plentiful resources for delivering software securely, especially in the context of Agile and DevOps. As a former product manager, I can't state enough the power of threat modeling as an exercise for scrum teams to identify potential risks early on in the software development lifecycle.
I also recommend borrowing what's worked before and replicating outcomes. Read studies about how others have delivered security continuously, like the National Geospatial-Intelligence Agency's success with Red Hat OpenShift. In the case of this program, applications were able to inherit ~90% of their security controls from a hardened CI/CD pipeline and container platform, which not only significantly reduced the developer's responsibility for addressing the controls within their application, but also reduced the time the time to compliance (application ATOs in a single Agile sprint!) Even better, those information security organizations that are pursuing "continuous authorizations" like the US Air Force can really complement and even accelerate their teams that are conducting continuous security in parallel (i.e., all boats rowing in the same direction).
Reversing the formula, I would also look at security incidents from the past, such as the Apache Struts statement on the Equifax security breach from 2017. Use these past incidents to identify where users and enterprises went wrong. Examine them carefully to understand the consequences of not sharing responsibility and adopting continuous security.
The recommendations from the Apache statement apply to all types of software delivery, not only to projects using Struts, and certainly not only to Equifax. Everyone is building software today, including government departments and agencies of all types. For software to be delivered continuously and securely, security needs to be everyone's job. This type of behavior leads to lower costs and faster implementation times, which invariably leads to more rapid approvals for compliance and security authorization audits. Let's make it an integral part of each phase of the software development lifecycle.
Last updated: June 24, 2020