Security as Code is the Future to Governing Risk

This blog was originally published by Secberus here.

Written by Fausto Lendeborg, Secberus.

We read McKinsey’s Security as code: The best (and maybe only) path to securing cloud applications and systems in July and have not stopped discussing it.

The big idea: “Managing security as code enables companies to create value in the cloud securely.”

Bravo focusing on “enabling value”. Value in this case means business acceleration. Too often security gets caught up in all the minute details that fulfill the security is a business roadblock stereotype. It’s time to look past those hurdles and focus on the value (and speed) security can bring to your enterprise.

The challenge: “...cloud requires secure configuration of applications and systems. But traditional cybersecurity mechanisms were not designed to ensure secure configuration or operate at the tempo required to capture the benefits of agility and speed that business leaders expect.”

We agree McKinsey is highlighting the right challenge and the right solution. We agree so much that we want to elaborate on the security as code storyline with three points.

1. Security as code applies to all aspects of your security environment.

In order to manage security as code, you need to have a cloud strategy that works “as code” too. We call this governance as code. (We have another name as well, Security as Business.) The thought is that in order to protect infrastructure as code you need to do as much as possible with an “as code” framework. You can’t protect something built “as code” with something that isn’t built “as code”. At least, you can’t do it well.

In essence, “as code” is the secret formula that brings you scale, agility and speed. And if you are managing a security environment with security as code, your overall security strategy should be just as flexible.

We have found there to be five pillars to consider when building an adaptable cloud governance strategy: development, security, compliance, organization, and cost. Each of these pillars is associated with a cloud governance goal:

• Development. Continuous innovation and development at the speed of business.
• Security. Manage and remediate risk that affects business performance first.
• Compliance. Map, manage, implement and audit compliance as efficiently and effectively as possible.
• Organization. Get real-time risk context to the right person at the right time.
• Cost. Gain visibility into cloud cost posture management gaps.

In order to protect your applications being built on infrastructure as code and in order to enable the value your business is seeking, you need to go beyond security as code and apply an as code framework to everything you build.

2. Security requirements have to scale.

McKinsey explains the value of security as code in this instance,

“At this point, most cloud leaders agree that infrastructure as code (IaC) allows them to automate the building of systems in the cloud without error-prone manual configuration. SaC takes this one step further by defining cybersecurity policies and standards programmatically, so they can be referenced automatically in the configuration scripts used to provision cloud systems and systems running in the cloud can be compared with security policies to prevent drift…”

McKinsey analysts go on to explain:

“Implementing SaC requires a substantial policy, architectural, and cultural departure for almost all companies.”

And that ultimately,

“A Cloud Governance Engine Compliance Service is used to manage the process. It is the centralized service responsible for accepting provisioning requests and verifying IaC meets organization compliance requirements prior to provisioning cloud resources.”

Implementing SaC within your enterprise is, without a doubt, a productive move. It’s even more productive when you add context to the security as code you are distributing and automating.

The most common challenges we see with implementing security as code to govern risk across your cloud environment are twofold:

• Translating requirements into policy as code.
  McKinsey mentions this as well. Organizations have the policies written as requirements yet lose productivity in the interpretation and translation of those requirements into security as code. So, why not write your requirements as code from the beginning?

• Creating adaptable policy as code.
  Once your security as code is in place, organizations get easily frustrated and, again, lose productivity, if they can’t add context to the code in order to build knowledge and efficiencies into the automation. This context should be applied at every level: core business requirements, individual business units and individual application controls. So, why not create security as code that is able to adapt to the context of the requirement and therefore enable the user to manage the requirement efficiently and effectively?

By being able to solve both of these challenges you are putting into practice a security as code strategy that will scale with the needs of your business--as well as increase the accuracy of your policies and the productivity and well-being of your people.

3. Security as code depends on governance as code.

Security as code is a piece of the puzzle. As mentioned previously, security as code acts as the rules engine in your security strategy. And this rules engine is essential in order to achieve scale and speed within your enterprise. But it has to answer to an overarching governance strategy aligned with business goals in order to provide the most value.

There are two big benefits that come with implementing security as code in this way: a security strategy your CISO can sustain and the elimination of silos within the team.

Your strategy is now sustainable because any identified risk is attached to the person who created the risk. This is important because when a new engineer enters the picture she will have the context to mitigate that risk. So now, the organization’s security risk infrastructure (or, as McKinsey refers to it, the Cloud Governance Engine Compliance Service) stays true to the business. If the business requirements change, security adapts.

And secondly, the silos within the team can now be eliminated through the automation capability an as code infrastructure creates. Automation creates a frictionless experience. Automation also creates the avenue to add appropriate context to the security as code at scale. And by tying the security strategy to the business requirements, you are creating an as code infrastructure that spans the entire organization.

This is one of the most rewarding and hopeful articles we’ve read in awhile. And if you haven’t read it yet, we highly recommend you take ten minutes and read it now.

At the end of the day, this conversation supports the race every CISO is a part of--the race to protect data. It’s all about the data -- how it’s stored, processed, and protected. That’s what we are all trying to do. And to do better. The question we continually ask ourselves at Secberus is,

“How can we help to simplify enterprise security strategy so that the most complex organizations can continue to move at the speed of the business?”

The McKinsey article is a fantastic launching point for shifting the risk conversation from security as code being a possibility to security as code being a foundational element to your security strategy.