Bridging the gap between security and engineering can bring significant value in compliance and operational protection, and its impact will place broad strokes in knowledge transfer and relationship building. In functional shops, security might oversee rules, time-based audits, and create tickets for teams. As teams cross over the DevSecOps divide, security becomes less of a task and more verification in the release. Specifically focused on cloud workloads, several automated steps can be adopted that plug right in and give that instant feedback engineers desire. Call the movement: continuous security.

Infrastructure Pipelines

There are several moving parts with cloud infrastructure, regardless of which provider, albeit a data store, server, security group, or any other resource configuration. Several compliance institutions have come out with benchmarks to compare against, and these are what security uses in auditing. With shift left, the question is, how can we integrate with the workflows that already exist versus devising new solutions or performing out of band scanning? Several open-source tools can provide this protection.

Disclaimer: This piece is not designed to focus on tools, but rather how tools can simplify the process. No means suggested is a catch-all and should be seen as examples rather than implementation specifications.

Static Analysis of IAC

Depending on your stack, several solutions can provide coverage. Static analysis of infrastructure should be seen as different than static analysis of application code, as IAC is finite and declarative, where applications are variable. The tools in this market vary by the framework in which you are utilizing. TFSec, for example, is focused solely on terraform, whereas Checkov covers multiple frameworks. In determining what works best, the most critical factors to look for are extensibility and coverage.

Take this sample Terraform code, which creates an s3 bucket:

Utilizing a framework like checkov, we can run a series of checks against the resource definition and determine that some work can be done to harden the overall configuration.

With that said, checkov is not the only static code analysis. For a more comprehensive breakdown of static analysis tools, I recommend you read this blog post by Christophe Tafani-Dereeper.

Config Test

If we take a quote from Jim Brikman from Hashiconf 2018, "Infrastructure code without automated tests is broken." Inspec is widely adopted to ensure that the config is appropriately set, but what about using it for security? Several resource checks can validate encryption settings, access policies, etc. Take that same s3 bucket from before, and after deployment, we can validate to ensure the deployment meets our expectations.

~ inspec exec -t aws:// .

Profile: Bucket Testing profile (bucket-test)
Version: 0.1.0
Target:  aws://

  S3 Bucket tf-test-bucket
     ✔  is expected to exist
     ✔  is expected not to be public
     ×  is expected to have default encryption enabled
     expected #has_default_encryption_enabled? to return true, got false
     ✔  

As you get writing more tests, there can become an issue when you have trickling dependencies. An example would be if you create an access policy, having the means to exercise that policy to validate that it is doing what it should, and not doing what it should not. Integration tests are where Terratest or self-curated scripts (ex. pytest + kubetest) are the means to the solution. An integration test will ensure that the written access policy will continue to work regardless of the underlying changes.

What if we had a role that we wanted to ensure could list objects from our s3 bucket? Can we deploy the role, then assume it and test its permissions against the bucket

~ go test
Running command terraform with args [init -upgrade=false]
...
Running command terraform with args [apply -input=false -auto-approve -lock=false]
...
Apply complete! Resources: 4 added, 0 changed, 0 destroyed.
...
PASS

Runtime protection

In this domain, we typically start to see tight integrations. In the k8s world, an example involves OPA Gatekeeper utilizing the admission controller; in the server space, the remediation might be a service such as AWS Config, which will scan existing assets against known configuration checks.

Recently a CVE was released within k8s, CVE-2020-8554. Using OPA Gatekeepr, you can create a constraint template, that restricts the ability from publishing through an admission controller

After trying to exercise the vulnerability, gatekeeper will block it.

Error from server ([denied by k8sexternalip] service has forbidden external IPs: {"23.185.0.3"}): error when creating "STDIN": admission webhook "validation.gatekeeper.sh" denied the request: [denied by k8sexternalip] service has forbidden external IPs: {"23.185.0.3"}

Application Pipelines

Many applications depend on system resources or external dependencies, of which the OWASP Top 10 calls out “Using Components with Known Vulnerabilities.” The nice thing about being in the OWASP Top 10, is engineers tend to be more aware of the risks. When talking about shifting left, there are several measures to keep you protected.

Utilize SCA to discover in code

Application dependencies are defined in a static config file, and most languages have a typical pattern for analysis. GitHub and GitLab, two leading Source Code Management solutions, have SCA built into their platform. However, security tools such as Synk or Contrast can integrate directly into your already existing application security stack. In the end, it’s not about which software, but rather ensuring your dependencies are up to date, and having an automated means to do so that runs against your existing CI pipeline makes it easy for developers to adopt.

A web app I manage utilizes AWS Amplify. Having an SCA tool at the disposal can keep the application up to date whenever a patch, minor, or major release comes out. Github's Dependabot compared Amplify's current package and saw a new one was released in this example. Auto opening a PR, the CI checks were able to execute and assure that it won't break the build.

Image Scanning

New CVEs are discovered daily. Having build-time and proactive scans against your images can help you find out OS-based patches that need to be applied. Scanning can take part both on the host side or the container side. Clair is a popular application integrated by many vendors for containers, but Nessus lead the way on the host side.

The claire scanner makes it easy to scan your containers on the fly. Once everything is all set up, you can scan any container image to get a list of its vulnerabilities.

Summary

Engineers feed into automation and want to utilize existing pipelines and frameworks to bridge the technical and social gap between security and engineering. Using tickets as a means of patching leads to slow turnarounds, and time-based audits lead to large openings of vulnerabilities. Through integrating changes on the infrastructure and application pipelines, the shift-left approach leads to an overall better security posture.