CIPA: A Recipe for Secure Infrastructure
Introduction
Does the Infrastructure provide the necessary security safeguards? Did we increase our attack surface by standing up new ingress? Are we confidant our cloud infrastructure is protecting our data, identities, secrets, and network? How are we incorporating cloud-native functionality, like IAM, audit logging, and networking, in conjunction with the available underlying and non-native services to secure our Infrastructure?
If you’re in charge of infrastructure security, these questions may keep you up at night unless you have a robust shift-left secure infrastructure program in place. This article provides the CIPA model of keeping the Infrastructure secure, incorporating infrastructure-as-code, policy-as-code, and automation.
Why CIPA?
C = Controls
I = Infratsructure-as-Code
P = Policy-as-Code
A = Automation (or Action!)
STAGE I : Controls
Security Controls and Guidelines
In some organizations, security controls are often not clearly defined and provided to infrastructure teams. Infrastructure teams should design and implement secure cloud resources such as AWS EC2, EKS, etc., based on the controls. Security controls should be as prescriptive as possible to take any ambiguity out of the equation.
Without predefined security controls, an infrastructure engineer may wonder “How can I build a secure Kubernetes cluster? I might as well just use my own judgment”
Why is this important?
Lack of prescriptive security guidelines would result in self-policing and noncompliance in the cloud infrastructure.
Recommendation
Author Security controls for all Cloud Services used at the organization and maintains a list of Approved and Unapproved Cloud Services. CIS benchmark is a great place to start adopting initial security controls and guidelines.
STAGE II : Infrastructure-as-Code
Infrastructure-as-Code <> Codify Infrastructure based on the controls
Terraform is the primary Infrastructure-as-Code tool used across many small and large organizations. However, often there is no set of pre-defined Hardened and Compliant Terraform Modules. As a result, system and infrastructure engineers create ad-hoc and non-compliant Terraform modules to build cloud resources.
I’ve heard this many times:
“Each team has its edition of Terraform modules for building a Kubernetes cluster.”
God knows some may not have disabled ‘basic authentication’. This is a disaster!
Why is this important?
Readily available Terraform modules on the internet (e.g., https://registry.terraform.io) come with defaults and often have security misconfiguration.
According to a study conducted by Bridgecrew, nearly 1 in 2 modules within the Terraform Registry are misconfigured. And the most common misconfigurations are in the Backup and Recovery, Logging, and Encryption categories.
Recommendation
Develop or Adopt Hardened and Compliant Terraform Modules
for cloud services and publish in code-repository company-wide access. There are some readily available hardened modules on Github, which could be a good start. My go-to is Cloudposse modules.
STAGE III : Policy-as-Code
Policy-as-Code <> Codify Security Controls
Many organizations haven’t leveraged the shift-left paradigm in their application or infrastructure development cycles. There are no Infrastructure-as-Code verification stages to ensure non-compliant cloud resources are not deployed in production. This gap obviously won’t be fully addressed without automated Infrastructure-as-Code practices in place.
Why is this important?
Without proper security checks prior to deployment, non-compliant cloud infrastructure would be built in production. Security teams must rely on reactive (vs. preventive) measures to detect the non-compliant resources and chase down the relevant teams for remediation. Additionally, reactive approaches are much more expensive to carry out than preventative measures.
Recommendation
Incorporate Policy-as-a-Code tools (e.g., OPA, Hashicorp Sentinel, Terrascan, Checkov) in the Infrastructure CICD pipeline, with a rule-set that’s a codified version of the security controls to ensure the Infrastructure-as-Code scripts (e.g., Terraform/CloudFormation/Ansible codes) are in compliance. And with the help of the CICD pipeline tool (e.g., Jenkins), fail the deploy process in the pipeline upon detecting noncompliance build with set thresholds (For instance, alert on the low severity and fail on the critical severity deviations).
STAGE IV : Automation
Tying it all together <> Pipeline it!
A robust Infrastructure automation pipeline is a requirement to uplift the maturity of the Infrastructure. Infra-as-Code & Policy-as-Code would be as effective as the underlying CICD pipeline bringing them all together. This allows the infrastructure teams to follow the GitOps flow for any modifications on the existing Infrastructure, with trackability and visibility in place, and eliminate any manual work that would go unnoticed otherwise; Decisions are made based on prescriptive controls (PaC), and human error is eliminated from decision making.
Let’s see it all in action.
Now let’s see all 4 stages discussed above in a simple example below.
**The code, for example below, is available on my GitHub account https://github.com/microsudo
*Security Control prohibits using *:* admin privileges on IAM policies
