Improve Your Security Posture and Sleep Better at Night with Compliance as Code
Compliance is getting serious! Fines from violating industry compliance standards such as PCI-DSS (for processing credit cards) or SOx (Sarbanes-Oxley) range from $4,000 to $100,000 per month with the average total fine being approximately $4 million [1].
The cost of data breaches is also rising, with the average cost approximately $3.62 million, according to the Ponemon Institute [2].
Given the high cost of breaches and non-compliance, one would think that most organizations would place a heavier premium on the relationship between security and technology.
Unfortunately, my experience has shown me that, generally, the opposite is true. The result is release delays, higher costs and greater vulnerability.
In this blog, I’ll explain why the lack of communication between security, engineering and the business creates either delays or leads to vulnerabilities, and how compliance-as-code can help!
Gun-Slingin' IT: The Security and Engineering Standoff
One critical reason for vulnerabilities and security issues in the enterprise is that the relationship between the security and engineering organization is often quite tenuous.
Allow me to demonstrate exactly what I mean with the example of a multinational Fortune 10 financial services firm.
Once upon a time, a Consumer Banking business unit wanted to add a feature to the website whereby customers can get a graphical breakdown of their spending habits along with their statements and other online banking needs. The dotcom Technical Lead knew that her team could easily do this: transactions and transactional metadata are relatively easy to find in ‘the database’, creating a graph on a website is practically a prerequisite for graduating a Computer Science program so...let's do this!
A few meetings and rounds of gossip later, the epic, stories and tasks are created in JIRA or Rally, and the requisite dotcom development team is off to the races.
Fast-forward two weeks. The feature is unit- and integration-tested, acceptance tests have been signed off by QA and Consumer Banking, and our shiny new feature is ready to go out to Production. That is, it was...until the Information Security ("InfoSec") team catches wind of this. They want to ensure that it passes automated vulnerability scans and run a round of penetration testing on the feature before they bless the release.
*Cue collective loud groans here*
Engineering says: "This process takes weeks. They (InfoSec) always find something wrong that isn't really a big deal. This release is going to get held up – again – and we're going to get the heat for it. How can we avoid them?"
InfoSec says: "I don't understand why those devs can't do security right. It's not hard! They always try and avoid us, and they're the reason why we had that big data leak a few years back that we had to fire people over. How can we force them to be more secure?"
The Consumer Banking product teams say: "It's only a graph! Why does it take so long to get anything done on the website around here? How much are we giving them to keep the lights on? Surely there's a cheaper way of getting what we need without the insane delays!"
The negative feedback cycle continues. Many proofs-of-concept get drafted up, but nothing lands in production. The circle of blame continues, increasing in intensity and velocity until a massive data breach makes everyone rethink the relationship.
Why is this the case?
Communication Is The Problem: Use a Common Language
The problem is that, currently, most technology organizations communicate their security posture through mountains of Word documents and Confluence wikis. While this makes their authors feel good and responsible in the moment, it is easy for important details to get "lost in the sauce."
“How do we separate our cardholder environments from less-sensitive ones? How do we patch our systems to ensure that they have important security updates installed? Where do we keep our secrets, and are they all in one place?”
If you've asked these questions sometime this week, you have probably spent a bit of time spelunking those mountains.
Instead, InfoSec and engineering teams need a common language so that everyone understands each other.
This already occurs in other areas. Configuration management tools such as Puppet, Chef and Ansible gave systems administration and development teams a bridge for communicating what bits of infrastructure should look and behave like at scale.
Infrastructure-as-code frameworks such as Terraform and CloudFormation gave platform engineering teams a bridge to application feature teams for communicating how their applications ran together in a live environment.
Compliance-as-code finally gives Information Security teams a bridge to both Engineering and the less-technical sides of the business for communicating how their application is secured and made compliant.
It does this by turning the mountains of diverse documents into clean, human- and machine-readable code.
Compliance-as-code eliminates this clerical burden in three ways:
- It runs against your systems: there is nothing better for enforcing standards against a platform than code that runs on your systems and gives you a result. Similarly, there is nothing better for exposing stale documentation than code that runs against your systems and produces outdated results.
- It lives alongside your application code: in my experience, finding information within Confluence or SharePoint was time-consuming, quite difficult if you don't know exactly what you are looking for, and often produced outdated or incomplete results. The real truth always lay hidden in the mind of an architect somewhere. Compliance-as-code puts accuracy first by living in the same place as the source code for application features. When automated compliance tests run immediately after unit tests or code analysis, the only way for that documentation to go out-of-date is through negligence.
- It creates a common language: a good compliance-as-code framework uses a syntax that's easy enough for everyone to understand, but powerful enough to meet most teams' needs. This way, everyone involved in the life of an application feature can contribute to keeping it secure.
Hug-Bringin' IT: Using Compliance-as-Code
Let's revisit our situation in our big financial services firm and imagine that compliance-as-code had been in the mix.
Consumer Banking wants pretty graphs for people to see how much money they've burned spent on Amazon this month. Dotcom knows how to make pretty graphs. Everyone agrees that this can be done in a reasonable amount of time. Agile ceremonies commence and work begins thereafter.
But what does InfoSec think?
InfoSec wants to know that adding this new feature won't make their organization vulnerable to an Alice and Bob situation. How can we ensure that we get our feature deployed quickly while protecting our organization's security posture?
The first story added onto the requisite Dotcom's scrum board isn't to begin writing code, or, hopefully, begin writing unit tests. The first story is to write compliance tests. How will this feature guarantee that PCI compliance or internal PII requirements are upheld? What needs to be done to ensure that GPDR is not violated?
Those tests are written in conjunction with a member of the InfoSec team. They know security as well as the Dotcom development team knows how to write software. By bringing them into the fold earlier into the process, trust is built, slowly, but surely, between both teams. This also potentially makes this release happen faster, as this reduces the chance of InfoSec becoming a blocker come release-time.
Assuming all else is well and that your release pipeline is mature, Consumer Banking not only gets their coveted feature into the hands of their consumers more quickly, but they more immediately see the value that their technology teams bring to them.
Consistent Software Deployment Pipelines from Laptop to Production
Compliance-as-code isn’t limited to testing code and applications. It’s extremely useful for ensuring consistent software deployment pipelines.
Consider that software projects differ in size and purpose, but all have one thing in common: their artifacts need to be deployed somewhere. My experience has shown me that, in most cases, the pipeline through which those artifacts are deployed onto infrastructure is created and managed manually. Furthermore, my experience has also shown me that the process for building, testing and verifying an application's readiness locally is wholly different from what happens in CI/CD or upper environments!
These inconsistent, manual environments open you up to vulnerabilities!
For example, we were once tasked with helping a Fortune 100 Financial Services institution with implementing a container-native platform for their legacy applications. In doing so, we needed to learn more about how applications were tested and built locally to determine whether it could survive as-is within Docker. Given that it was a traditional Java Web Application, we thought that it would be as simple as cloning its source code and running Maven to test and build it. We also assumed that the project's Maven configuration would contain all of the steps required to ensure that the application was viable for production.
Unfortunately, our assumptions were incorrect.
From this exercise, we learned that:
- While the project did have a build configuration with build steps within it, much of the actual steps required to build the application were performed manually and by select key people,
- Some automated build steps for this project were tightly-coupled with their IDE, and
- Scanning for security vulnerabilities and software best practices (code linting and syntax checking) were manual steps within hard-to-find Jenkins pipelines.
“How does this relate to security and compliance?”, you might ask. Consider the following scenario:
A new developer from a team that you manage adds a new feature that involves user input. No unit tests were written, and the deployment pipeline does not check for code coverage or vulnerability scans. The feature sails through QA, as it doesn't affect functionality of its parent product very much. The text form makes it into the monthly release and gets released onto the production website.
Two weeks later, you get a concerning email from Operations: a business-critical database was deleted unexpectedly. After hours of root-causing, it turns out that part of the input captured from that user input form added last release is used in a database query to fetch information about that user. The automatically-generated SQL query doesn't do any parameterization or validation. A malicious actor decided to "see what happens" when they add a ; DROP TABLE inside of the form.
Oops.
Making the process of testing and verifying code locally the same as in higher environments removes surprises during the release process and makes software development at scale safer and more predictable. It also establishes a lightweight minimum threshold that development teams need to pass before their code enters the deployment process to production. This combined with Pipelines as Code also gives your organization the ability to survive losing your entire build system without losing critical business knowledge in the process.
Sounds Awesome? How Can I Get It?
The good news is that there are several ways to get to compliance-as-code, and most of them are free!
InSpec: The Industry Standard
The most immediate solution that comes to mind is InSpec by Chef Software. A derivative of the RSpec testing framework, InSpec provides a framework for ensuring compliance that is easy to read, easy to use and easy to extend upon. It is designed to be as operationally flexible as possible. it can be installed as an agent onto your entire fleet or run as an ephemeral Docker container. InSpec tests can also be executed in a routine schedule in a centralized or decentralized way, or they can run ad-hoc as part of your golden image creation pipeline. Lastly, InSpec helps you fight reinventing the wheel by providing a repository of pre-existing tests one can download.
To see what I mean by "easy to read and use," consider the snippet of code below that checks against CIS benchmark 2.1:
control 'sshd-21' do title 'Set SSH Protocol to 2' desc 'A detailed description' impact 1.0 # This is critical ref 'compliance guide, section 2.1' describe sshd_config do its('Protocol') { should cmp 2 } end end
Running this test is as simple as saving this code as ssh_test.rb on your Desktop and running docker run --remove --volume $PWD:/share chef/inspec exec.
The biggest disadvantage with InSpec is that it is specific to Ruby. While it works quite well for doing deep tests within Ruby applications in an easy-to-read way, much less flexibility exists for Java or .NET applications. However, given that InSpec tests are really meant for a wider audience, such as auditors and security professionals, application-specific tests such as these are likely a better fit in your application's test suite.
Wrapping Up
Being non-compliant and risking breaches and leaks is expensive, embarrassing and emotional. Incidents such as these fuel the fire that divides the security organization from engineering and the business as a whole. Organizations of all sizes are fighting this fire, which slows releases, damages trust and, simply, makes life difficult.
Compliance-as-code helps quench this by providing a common language through which InfoSec, engineering and less-technical business units can contribute to the security posture of their applications and infrastructure. An approachable, extensive and easy-to-read framework makes this activity inviting while putting security first in the development process instead of last.
Of course, compliance-as-code is not the only tool in a modern software delivery pipeline that ensures security. Validating code correctness, preventing common vulnerability vectors within the code and approval gates also play big roles in keeping applications secure.
References
