Facebook Pixel

Infrastructure as Code (IaC) is not as simple as some other security risks because IaC is not automatically right or wrong. Vulnerabilities are easy, if you have a vulnerability, it is bad and you want to remediate it, no questions asked. IaC may not follow a best practice, but it may still be appropriate or required. This makes auto-remediation a challenge because it may break things.

Developers use a standard way of automating their resources: infrastructure (IaC e.g. Terraform), configuration (CaC e.g. chef, puppet), containerization (e.g. Kube) and pipeline (PaC, e.g. drone). This is accomplished by using structured code that defines various parameters. This is independent of the actual underlying resources, making it portable and reusable.

When building IaC there are best practices, defined as coded parameters based on principles such as least privilege. The challenge is that some applications or pods in your Kube cluster may require escalated privilege. This creates a gray area for auto-remediation. A standard remediation tool will recommend lowering the privilege, but that could break the app. If you were to auto-remediate it, it could assume that a lower privilege is better and make that change, resulting in a broken app.

For this reason, IaC auto-remediation is a bit challenging. You can use a tool to scan your IaC and identify security risks or deviations from best practices. That tool might also recommend code to make these misconfigurations conform to best practices. The developer can step through the list of proposed remediations and make decisions one at a time. With over a thousand possible parameters, this process can be tedious and time-consuming. Yes, it's better than committing code with risks, but there has to be a faster and better way..

You can leverage auto-remediation for the obvious misconfigurations, but what about those in the gray area? This is where machine learning can build models based on user response and correlate that to various other configurations and other variables. With this level of intelligence in the form of models, tools can organize configuration remediation based upon confidence level and enable group actions that reduce user input by more than 80%. And of course balancing developer efficiency against security demands is the ultimate goal of any developer-centric security tool.

What is Infrastructure as Code (IaC)?

You can think of IaC as a universal configuration file that tells your infrastructure platform—which can include the cloud, Kubernetes, Function-as-a-Service (FaaS), storage, and other services—how to handle a running piece of code. IaC describes rights, scaling constraints, resources, and more.

Prior to IaC, you had to configure each component of the infrastructure individually using each one’s proprietary user interface or config file. This might require one or more individuals with expertise in certain components, which added to the costs. Infrastructure vendors, with proprietary configuration tools, were able to lock-in customers and charge higher prices.

IaC empowers buyers by abstracting this configuration process, providing far more flexibility to deploy on any supporting infrastructure. This drives down costs. IaC also enables automation and other advantages, as described below.
[/et_pb_text][et_pb_text admin_label="The Benefits of IaC" _builder_version="4.10.7" _module_preset="default" text_font="||||||||" ol_line_height="1.5em" hover_enabled="0" global_colors_info="{}" sticky_enabled="0"]

The Benefits of IaC

  1. Shifting the Balance of Power: By abstracting the deployment infrastructure, you gain portability. You can take your code and your IaC file and deploy it anywhere in an automated fashion. This shifts the power balance between you and your infrastructure vendors, commoditizing them and forcing them to compete purely on performance and price, instead of vendor lock-in.
  2. Democratizes Expertise: Instead of hiring or training infrastructure people with expertise in certain vendor environments, IaC encapsulates best practices in files that can be reused. This reduces the headcount and costs associated with traditional configuration and deployment roles.
  3. Standardization: IaC provides a standard format for defining a couple of hundred individual configuration attributes. It is universally accepted/used by vendors. These standard formats make it easy to share best practices in the form of principles, policy rules and even files that can be copied and reused without any expertise in infrastructure. This also reduces the errors inherent in human activity, since shared files are evaluated, tested and debugged by experts over time.
  4. Automation: Automation not only makes developers more productive, it also makes them happier. Why force your developers to learn to configure infrastructure and then slow them down by making them do it, when you can reuse an existing IaC file? Happier and more productive developers results in faster time-to-market and faster product evolution.
  5. Security: By replacing traditionally manual infrastructure configuration with standardized files, computers can then evaluate those files. IaC files can be automatically evaluated against best practices to identify misconfigurations. This reduces errors and makes your code more secure because it flags potential threat vectors that can be exploited. By automating the evaluation of IaC, you can also compare those results against company policy, giving you compliance. By logging all the IaC information—scan results, policy evaluation results, and who changed what—you now have the information you need for governance.

[/et_pb_text][et_pb_text admin_label="Conclusion" _builder_version="4.10.7" _module_preset="default" text_line_height="1.3em" global_colors_info="{}"]

Conclusion

Infrastructure as Code (IaC) delivers huge advantages as detailed above. It enables you to deliver more secure code faster, more easily, more inexpensively and with fewer errors. It also provides much more flexibility to move your code to any target platform. In short, every software development process should be leveraging the benefits of IaC now.

IaC also enables fully automated deployment of containerized code into a Kubernetes platform, called GitOps. It builds on the self-defining configuration of IaC, by adding rules for when and where the container should be deployed. This enables fully automated continuous deployment, fulfilling the promise of CI/CD tools. The next post will dive deeper into GitOps and Secure GitOps.

Security policies are a critical component of your security solution and selecting the right security policy is critical to secure development. This article looks at the different types and provides insight into what to look for in a security policy to balance security and development efficiency at scale.

Security policies encapsulate a company’s requirements for a piece of code to advance in the software product lifecycle (SPLC). They effectively say: “clear these requirements and you can move to the next phase,” which may be QA, test server, production, whatever. In today’s highly distributed development world, with people working from home and often in different countries, your security policy must be codified and automated inside the development process or it simply will not scale.

The challenge is that many companies use a collection of different tools for various security functions, e.g. vulnerabilities, Software Composition Analysis (SCA), open source licenses, Infrastructure as Code (IaC), secrets, etc. This mix-and-match approach results in a collection of separate security policy tools and different security policies that may conflict when they have overlapping functionality. This results in an operational nightmare. What you really want is a unified security policy strategy.

There are three categories of security policies:

  1. Separate Policies
  2. Bundles of Policies
  3. Unified Policies

Separate Policies

When using different tools to scan for different risks, such as one tool scanning your IaC, another scanning vulnerabilities, etc., you encounter several challenges. Your security team will have to both learn and use multiple tools with different user interfaces. This requires additional time and money upfront and on an ongoing basis. They will also have to deal with conflicts between products. Since products often have overlapping functionality, such as two or more tools addressing vulnerabilities, and since the risk scoring across different products can vary wildly, you might have one tool passing a CVE because it scores it as low, while another rejects the code because it scores that same CVE as high. You can address these conflicts with white/blacklisting, but that merely creates white/blacklist conflicts and maintenance issues. The final issue with separate policies is that you don’t have a single source of truth for compliance or governance. To get a complete picture you need to pull data from all the tools and consolidate it in another tool, adding work and expense.

From a developer’s perspective, separate tools with separate policies means a multi-step remediation process. The developer runs one scanning tool at a time and then resolves those issues before running the next scanning tool, and so on. This is because overlapping tools will generate a ton of duplicate issues that confuse and slow the remediation process, so developers run them serially, which is a slow process.

Bundles of Policies

There are a couple of tools that will scan all the risk types: IaC, vulnerability, licenses, etc. These tools provide a single user interface for building bundles of policies. By providing a one-stop shop for building policies for each of the potential risks, it reduces learning time and implementation time. This approach also eliminates conflicts between scan results, policies, and white/blacklists. By using a comprehensive security scanning tool, the security team gets a single source of truth for compliance and governance. And finally, developers love comprehensive security scanning because they get a single punch list for remediation from a single tool. This is the current state of the art for security scanning. However, this approach merely bundles up separate policies that are each dedicated to a single type of risk, it doesn’t correlate multiple risks into a unified policy.

Unified Policies

Users are starting to appreciate the value of security asset management tools, where they can correlate all the various risks. These tools provide context that enables you to determine the true risk profile of your containers. Naturally the next question is: “How do we get that same level of correlation and context into our security policies?” I haven’t seen any security vendors generate context-rich security policies that correlate various risks yet, but I’m sure that is the next wave of innovation we should anticipate. This sort of highly correlated unified policy would be exceptionally valuable because it provides a more realistic perspective of the aggregate risk.

Conclusions

Using a collection of specialty scanning and policy tools results in conflicts between tools, serialized (slower) processes, and leaves you without a single source of truth for compliance and governance. Comprehensive security solutions can scan for all the potential risks and then evaluate them with a single bundle of policy rules. This approach addresses all the deficiencies of separate policies, but under the covers they are merely a bundle of individual policies for each risk type. We believe that the next generation of policy will be patterned after security asset management tools, where users can add context and correlations to evaluate the true risk profile of each container based on a holistic view of its various risks: security, legal, content and deployment risks. We hope to work with you as we make container security easier and more effective.

Container security is the practice of correlating all inherent security risks in conjunction with the context of how the container is deployed and used. The risks can include vulnerabilities, dependencies, secrets, malware, IaC, licenses, and more. By adding the context about how each container is deployed, exposure to hackers, and how it is used, and more, we get a complete picture of the true risk profile. This true risk profile is invaluable for making technical decisions such as prioritizing remediation, whether to build a container (policy/compliance), whether to promote images, which Infrastructure as Code (IaC) files should be associated with certain images, and more.

There are also business decisions that are driven by information from these risk assessments, such as whether images can be exported, whether they run afoul of HIPPA and other legal constraints, license compliance, whether they are exposing Personally Identifiable Information (PII), and more. The business decisions can have a high impact on business success, including company reputation, outsized costs and even result in civil and criminal penalties.

Analyzing security risks individually, or without context from IaC and deployment insight, is insufficient because these variables combine to amplify the true risk profile. In this case, the truism applies: the whole is greater than the sum of the parts. Additional context such as which cluster an image is deployed in (e.g. internal vs. customer-facing), which labels are associated with the image (e.g. HIPAA, NO EXPORT, etc.), license compliance, open ports in the cluster, and more, must all be considered, along with the inherent security risks, to build a true risk profile.

Container Security Asset Management (CSAM) describes a set of tools that enable users to correlate the inherent security risks with the context of how they are exposed in deployment. Basically, you can think of CSAM as enabling users to correlate any combination variables to answer business questions and achieve specific actionable insights. Here are just a few examples of questions you might want to answer:

Container Security Asset Management (CSAM) enables you to combine all of the risk factors with deployment context to not only determine the true risk profile of certain containers, it also enables you to answer key business questions. This raises the value of container security tools from tactical tools used only by developers and security personnel, to being strategic business tools used by executives.

 chevron-down