In the part I of the blog, we focussed on how development and operations can use ‘Infrastructure-As-Code’ practices for better governance, traceability, reproducibility and repeatability of infrastructure. In this part II of the blog, we will discuss the best practices for using ‘Security-As-Code’ and ‘Compliance-As-Code’ in cloud native DevOps pipelines to maintain security without sacrificing agility.
Traditional security is an afterthought. Once a release is just about ready to be deployed, security vulnerability testing, pen testing, threat modeling and assessments are done using tools, security checklists and documents. If critical or high vulnerabilities or security issues are found, the release is stopped from being deployed until these are fixed causing weeks to months of delays.
The ‘Security-As-Code’ principle codifies security practices as code and automates its delivery as a part of DevOps pipelines. It ensures that security and compliance is measured and mitigated very early during DevOps pipeline – at use cases, design, development and testing stages of application delivery. This shift-left approach allows us to manage security just like code by storing security policies, tests and results as a part of repository and DevOps pipelines.
Let us break this down with key best practices in achieving this. As shown in the diagram below, there are 5 points in a pipeline where we can apply security and compliance as code practices. We will use a cloud native application running on AWS cloud to illustrate these.
a) Define and codify security policies: Security is defined and codified for any cloud application at the beginning of a project and are kept in a source code repository. As an example, a few AWS cloud security policies v1.0 are defined below:
- Security groups/firewalls secured, eg. No 0.0.0.0 ingress rules
- VPC, ELB, NACL enforced and secured
- All EC2 and other resources must be in VPC and each resource individually firewalled
- All AWS resources –EC2, EBS, RDS, DDB, S3 are encrypted as well as logs, use KMS.
Having security policies such as above in a document is old world. All such security policies need to be automated – by pressing a button, one should be able to evaluate security policies for any application at any stage and environment. This is a major shift that happens with the principle of security as code – everything about security is codified, versioned, and automated instead of having a “Word” or “Pdf” document about security. As shown in the diagram above, security as code is checked in as “code” in repository and versioned.
Enterprises should build standardized security patterns to allow easy reuse of security across multiple organizations and applications. Using standardized security templates (also as “code”) will result in out-of-box security instead of each organization or application owner defining such policies and automation per team. For example, if you are building a 3 tier application, a standard cloud security pattern must be defined. Similarly, for a dev/test cloud, another cloud security pattern must be defined and standardized. Both hardened servers and hardened clouds are patterns that can yield security out of the box.
For example, with AWS cloud, the 5 NIST AWS cloud formation templates can be used to harden your networks, VPCs, IAM roles with these templates. The cloud application can then be deployed on this secure cloud infrastructure where these templates form the “hardened cloud” (Blue) layer of the stack as shown below. For cloud or on-premise servers, server hardening can be done by products such as BMC Bladelogic.
b) Define security user stories and do security assessment of application and infrastructure architecture: Security related user stories must be defined in the agile process just like any other feature stories. This will ensure that security is not ignored.
Security controls are identified as a result of application security risk and threat models on the application and infrastructure architecture. These controls are implemented in the application code or policies.
c) Test and remediate security and compliance at application code check-in: As frequent application changes are continuously deployed to production, the security testing and assessment is automated early in the DevOps pipeline. The security testing is automatically triggered as soon as code check-in happens for both application or infrastructure changes. Security vulnerability tools are plentiful in the marketplace such as Nessus, opensource recipes from Chef for security automation, web pen testing tools, static and dynamic code analysis, infrastructure scanners and others.
If critical or high vulnerabilities are found, automation will create “defects/tickets” in JIRA for resolution assigned to the owner of microservice for any new security issues.
d) Security and Compliance test infrastructure-as-code artifacts: In the new cloud native world, infrastructure is represented as code such as Chef recipes, AWS CFN templates and Azure templates. Security policies are embedded in these artifacts as well as code together with infrastructure. For example, IAM AWS resources can be created as a part of AWS CFN templates.
Security policies need to be tested for violations of security policies such as “no s3 buckets should be publicly readable or writable” or “do not use open security groups with 0.0.0.0/all traffic allowed”. This needs to be automated as a part of the application delivery pipeline using security and compliance tools. Many tools such as CloudCheckr, AWS Config and others can be used. For regulatory compliance policy checks such as CIS and DISA on servers, databases and networks, BMC Bladelogic suite of products can be effectively used to not just detect but also remediate compliance.
e) Test and remediate security and compliance in production: As application moves from dev to qa to test, automated security and compliance testing continues to happen although risk of finding issues here is much less as most of the security automation is done much earlier in the DevOps pipeline. Tools such as BMC Bladelogic can be used for production security patching after scanning of production servers for mutable infrastructure. For immutable infrastructure, of course, new servers are created and replaced instead of patching.
Shift-left approach for security and compliance is a key mind shift change with DevOps pipeline. Instead of security being a gating add-on process at the end of the release, or a periodic security scanning of production environments, start with security at the beginning of an application release by representing it as “code” and baking it in. We showed 5 best practices to embed security and compliance best practices for application delivery. These practices include defining security policies as a part of infrastructure-as-code, standardized hardened cloud just like hardened servers; defining compliance policies as code; automating testing at early lower environments and stages in a pipeline as well as production environments. We strongly believe that with these 5 best practices, successful product companies can ensure security while maintaining agility and speed of innovation.