Post originally published on AWS startup blog
Infrastructure-as-Code (IaC) has emerged as an essential strategy associated with organizations’ DevOps practices. Tools such as AWS CloudFormation and Terraform allow software-defined infrastructure to be deployed quickly and repeatedly to the public cloud infrastructure. Dome9’s CTO, Roy Feintuch, has written an article in The New Stack explaining the rise of the Infra-as-code trend, agility of CI/CD pipelines, and how to tackle the security challenges faced by DevOps teams. As Roy writes, one methodology that has started to gain traction is static (infrastructure) code analysis prior to deployment. In this process, CFT templates are treated just like any other SW code and DevSecOps teams perform security and compliance unit-tests after code commits as part of the standard CI process. Although this is a very promising new approach that can bring security and compliance as close as possible to the source, there are some challenges that are present.
Challenges faced in this approach
Complex Regex Rules: Security rules tend to be complicated and often require complex regex queries.
Typical regex for SSH open to the world (allow inbound 0.0.0.0/0 on port 22) below:
'ruledata' : {'S': " ^ .*Ingress. *(([fF]rom[pP]ort|[tT]o[pP]ort). \s*:\s*u?.(22).*[cC]idr[iI]p. \s*:\s*u?.((0\.){3}0\/0)|[ cC]idr[iI]p .\s*:\s*u?.((0\.){3}0\/0).*([fF]rom [pP]ort| [tT]o[pP]ort ).\s*:\s*u?.(22))"},
The scary snippet above is a strong indicator of why you shouldn’t use regex rules to enforce security policies. One alternative is to use general purpose languages (Python, JS) to reason about JSON structures. Yet, using a programming language to reason about your CFT has additional challenges:
1. CFTs are dynamic templates and have properties such as:
– Parameters that hide the value that is being searched for
– Intrinsic functions that obfuscate the security intent and clutter the logic
– Conditional statements that could lead to false positives (regex will fail)
2. Intended outcome can be modeled in multiple ways in a CFT
Let’s imagine an SG that exposes 0.0.0.0/0. The same outcome can be modeled in two ways below:
[wp_colorbox_media url=”https://dome9.com/wp-content/uploads/2018/05/sca3.png” type=”image” hyperlink=”https://dome9.com/wp-content/uploads/2018/05/sca3.png” alt=””]
Security teams need to be aware of and reason about both representations to ensure proper security assessment.
3. Deep domain knowledge (networking concepts, AWS infra) is needed to reason about your domain and can result in misconfigurations
[wp_colorbox_media url=”https://dome9.com/wp-content/uploads/2018/05/sca1.png” type=”image” hyperlink=”https://dome9.com/wp-content/uploads/2018/05/sca1.png” alt=””]
[wp_colorbox_media url=”https://dome9.com/wp-content/uploads/2018/05/sca2.png” type=”image” hyperlink=”https://dome9.com/wp-content/uploads/2018/05/sca2.png” alt=””]
Dome9 Solution: Software-defined security and compliance for your Infra-as-code
Dome9 provides the ability to scan and ensure the infrastructure code passes the necessary compliance and security checks before deploying to production. Dome9 enhances infra-security by the powerful Dome9’s Compliance Engine API and the GSL language to write custom policies to govern your DevOps posture.
GSL code
SecurityGroup should not have inboundRules with [ port=22 and scope isPublic()]
Instead of complex regex queries, above is a simple GSL code that checks to see if there are any inbound rules that allow public access over SSH in your app.
Dome9 is a DevOps enabler by maximizing operational efficiency of Infrastructure-as-code. Using Dome9, compliance/security teams can seamlessly update policy changes into the pipeline and ensure the DevOps stakeholders can build code without barriers!
[wp_colorbox_media url=”https://dome9.com/wp-content/uploads/2018/05/pipeline.png” type=”image” hyperlink=”https://dome9.com/wp-content/uploads/2018/05/pipeline.png” alt=””]
For a more in depth walkthrough, check out the AWS Re-invent session by our CTO Roy here!