Intro
If you only read the first two sentences of this blog, this should be your takeaway: Policy as Code provides a roadmap to verify the processes in security and governance that should be automated, while supplying teams a blueprint to build and meet those requirements.
This blog post is the first in a multi-part series on understanding policy as code. Moving forward we cover topics such as how you should tackle your current gaps, and how to utilize automation overseeing your policy goals.
Policy
Policy is an aspect of security and governance that sets guardrails for organizations. These guardrails are not only meant to provide guidance on the procedures that must be followed but also to create a framework to build from when designing secure systems. The enforcement of these policies is where security and governance teams spend their time daily. That is to say, every policy an organization follows should have a measurable way to validate and enforce it's compliance. In addition, these policies are subject to the same changes that security and governance teams have to anticipate every year.
Modern Policy Challenges
When we tie this into the broader organizational landscape, the challenge of scaling across every facet of its users, business logic and intellectual property is unwieldy. Not only are user's interpretations and acknowledgement of policies a challenge, but enforcing them is a tedious task.
For many organizations, part of this challenge is magnified by policies being spread out across the organization. Separate sets of policies existing in different physical and logical locations only create more barriers to enforce the procedures that matter.
Policy gaps are often introduced due to a change in business logic or technology changes. If your development team updates authentication schemes, or operational teams make changes to the architecture of the organization's environment, you are likely going to end up with a policy gap.
For many organizations, policies are not documented, or are all created ad hoc. Your Security/Governance team is likely up against a 1:100-1000 user ratio. You can't possibly talk to every developer/operator/user every day.
What is PaC and how does it solve these challenges
Rather than thinking of PaC as a way to write your policies, think of it as a way to enforce/validate your policies, thus achieving the goals of your organization's security and risk programs. You are likely already enforcing certain policies following some procedures or control, and some of them may even be automated.
PaC is expanding that to a larger scale across every practice in the organization. Connecting the Policies with the security/IT/risk mitigation tools you are using today is how PaC works. These tools act as the engine that allow your policies to be validated. In turn, your policies provide the priority ranking necessary to determine what should be remediated with urgency.
Many organizations face a challenge. They want to build security and governance into as many processes as possible, but they can't do it without actionable automation in those processes. It simply will not scale if done incorrectly, however. Manual processes are what give governance and security teams a bad reputation.
On the flip side, automated tools that provide too much information but can't be tied back to a single actionable reason to prioritize a finding eventually turn automated processes into manual processes with an extra step. If you aren't able to tie the result of a finding back to policy, does it matter? From a developer, operator or user perspective, the answer will always be "NO". PaC provides the law to automated assertions and evidence.
PaC provides actionability, foresight, and the ability to accommodate automation for stakeholders. Automating security is just a way of enforcing policies in a scalable way. In order to automate security you need to have actionable priorities defined. The ultimate source of those priorities will be defined by policy.
Next Steps
Begin by consolidating your current policies into a single source of truth. The policies you currently have need to all exist in one single repository. Having everything located in one spot provides you with a place where you can corral your users, as well as providing you with control over the future changes to your policies.
Next, identify the tools and controls you are currently using to enforce policy controls. You likely are using a plethora of tools that can provide information about the worrying behaviors that result in events, and ways to manage and respond to those events. Without a way to tie those back to your policies controls, you'll likely be tied up second guessing false positives.
Finally, acknowledge that there are likely going to be gaps that need to be addressed. It is likely that in addition to finding gaps in your policies, you will also find there are gaps in your ability to respond and detect certain types of events. Before you can address those gaps, figuring out what can be simplified within your current policies and tooling frees you to focus on remediating those gaps.
