4 Reasons Why Companies should Codify their Security

Overview

In today’s fast paced world of development, many, if not all companies, have embraced the DevOps culture with the increased agility and flexibility as the primary driving forces. Coupled with the agile methodology, the DevOps practices have brought a harmonious way of developing code and integrating systems and software.

As enterprises started adopting these DevOps principles like cloud-native, Kubernetes, etc, taking compliance and security into account has been a pressing issue. For example, FinTechs and MedTechs companies have a series of industry-specific standards that they must adhere to avoid the hefty fines. Failing to adequately secure the infrastructure has costly and devastating consequences for companies. According to a research by Ponemon Instituter, security breaches are costing companies nearly $5 trillion in monetary losses.

For a more agile, friction-free and secure environment, shifting-left has become essential. By shifting-left, organizations are instilling security measures into the DevOps workflows, not just at the tail-end of the process, giving rise to the SecDevOps.

Policy-as-Code (PaC) in the Cloud and Agile World

Most of the major cloud providers offer dozens of services and products. To date, AWS alone has more than 200 products and services. As a matter of fact, a company uses on average 20 to 30 cloud services and products. With all the possible ways things can go wrong with these services, the operational and security complexity is exponentially increasing.

Enforcing policies and standards is not a new concept. It has been there for decades. However, many existing policy or ACL systems do not practice policy-as-code. Many policies are set in an Agile manner, which is not easily repeatable nor versionable. They usually don't provide any system for testing policies other than testing an action that would violate the policy. This makes it actually difficult for automated testing and the policy language itself varies by product.

And now, the relatively new concept of codifying policies is a natural evolution of Infrastructure as Code; solving many problems for engineering teams.

Benefits to Codifying Security

Codifying security and compliance has a wide range of benefits for organizations, specifically engineering teams, which include:

• Real-time compliance and security monitoring
• A defined uniformity across all cloud systems
• Security embedded into CI/CD Workflows
• Reinforcing Security Practices across Teams

1- Real-Time Compliance and Security Monitoring

When you apply policy-as-code to a running environment, you have an idea in real-time what is in compliance and what is not. And by compliance here, we mean organization-specific standards, be they industry-specific standards or company-specific rules.

 For example, in an organization with tens and hundreds of developers, it's going to be extremely difficult to check every single pod to make sure every single configuration is aligned. It doesn't make sense, it doesn't scale, it's probably impossible to catch up and maintain that if you have a very, very large cloud native deployment.

2- A Defined Uniformity Across all Cloud Systems

With policy-as-code, you can run a tab of what's compliance from a holistic level. Instead of just looking at one deployment, you could look at your fleet of clusters across your multi-cloud environment. So having the same policy scale across a multi-cloud even on-prem, allows you to have this uniformity regardless of what's under the hood.

One of the advantages of Kubernetes is this kind of lift and shift idea - that if you deploy Kubernetes anywhere, you can deploy the same artifacts and the same architecture. And so policy helps define uniformity across all cloud systems.

3- Security Embedded into CI/CD Workflows

As more organizations adopt DevSecOps approach, you want to start incorporating security early on in the development process. Just as developers are using CI/CD today for unit testing to ensure they are not introducing any bugs into the system, teams can do the same thing with policies.

Developers now have much more autonomy over their micro-services. For example, regarding specific Kubernetes, a developer can create a deployment YAML file, or service file, maybe an Ingress YAML, and within those they configure everything.

 And unbeknownst to them, they have the ability to deploy these things, but they might be deploying configurations that are very lax in security, maybe the containers are running as root or some configuration that's not adhering to the org standards. But instead, what DevOps can do is codify the policies, incorporate that into the CI/CD jobs, and "shift left".

So, when the developer is building, they're deploying YAML or their Helm chart or whatnot, and if they're doing something there that doesn't adhere to the organization, the codified guardrails can flag it as a violation and the developer can then remedy that even before the Ops do.

For DevOps to Automate Security

If DevOps should own the codification of policies, we should expect a lot of automation and innovative ways of using it. There are three main characteristics of policy codification programming language.

• First, they need to be non-programmer friendly. Non-programmers need the ability to enforce certain rules within a system without complex structures.

• Second, they also need to be programmer friendly. At the same time, the language needs to support programmer friendly constructs such as conditionals, loops, and functions for complex policies that the programmer might be writing.
• And finally, they need to be safe. Most policy languages are used in security sensitive environments. They must not be able to crash the whole system or access the system resources without explicit approval.

4- Reinforcing Security Practices Across Teams

 Policy codification can bring Ops, security, and developers together to secure their infrastructure and move fast. Security teams want to protect the current value of company products and data. Developers want to increase the value of these products, however, which requires changes and disruptions of the status quo. Operations teams, on the other hand, want to keep the system stable and available all the time for their customers.

Codifying security policies can help these teams work together and reduce the possible (and probable) friction given their conflicting roles and goals. What PaC does is commit time, build time, and runtime checks and reinforce the message of security across the organization.

Let’s imagine a developer is building a new micro-service; they build the job, they run a build job for the first time and one of their proposed configurations is in violation. Maybe security isn’t necessarily on top of their mind. But what this automated security policy actually does, is it forces in a way, the developer to start thinking, “Hey, I have to build a secure configuration in order for my build jobs to pass in order for me to bundle this package, in this case, build my container image and be able to deploy it.”

In terms of the big picture, policy-as-code reinforces the message that security is really everyone's - in terms of the development, DevOps, infrastructure, and the tech side of things - everyone's responsibility. But when you think about it piece by piece, it plays a huge role in the SDLC in pretty much every phase of the software development life cycle. Because you can check your policies at the commit time using Git pre-commit hooks.

 If you have a CI/CD system, you can check it there. So, every time you open a pull request, you can have a trigger there if you wish. It can also be done at deployment time in Kubernetes. You can use a mission controller so if someone wants to bypass all of that or you don't have it, and someone wants to deploy a policy-violating configuration, it gets blocked there, and then for those entities that are already deployed, you can catch it at runtime. It plays a huge role in the SDLC but it also reinforces the message that security is something that everyone needs to pay attention to.

How Magalix Can Help?

Magalix policy enforcement engine is a fast, scalable, and reliable way to implement “security-as-code” across your entire infrastructure. Get access to hundreds of built-in templates and policies so you can quickly apply all the security and compliance standards you need in a snap.

Start protecting your cloud storage assets with codified security policies that effectively cover all your security, compliance, and operational needs.