How Policy-as-code can make your developers infallible

Matt Luckett   ·   Tuesday, December 13th, 2022

Policies are at the heart of every security strategy. Whether it’s your data loss prevention (DLP), cloud access security broker (CASB), encryption, or access control strategy, policy drives how these are enacted.

Unfortunately, people are at the core of building all these policies, and people are known for errors.

But what if you can take the errors out of human error?

What if the strategies you were looking to achieve were executed flawlessly?

Would this give you the peace of mind that only the right people inside and outside your organization had access to the right information at the right time?

Policy-as-code can help.

Empowering your policy building workflow with the right testing framework

When building policies, policy-as-code gives your application owners the flexibility to quickly and easily create the policies your organization needs to protect your data.

But this is only half of the challenge. The other half is ensuring the policies being built have the desired effect without impacting other policies.

That’s why we created our policy testing framework. This testing framework gives your team the tools and steps needed to trust that your users always have the right level of access to data. Our testing framework starts with the end in mind.

Put another way, it looks at what it is the policy is trying to achieve.

An example might be to make sure users only have access to information from within their department. In this case, a test would be written to validate that users can only access department-specific information.

Once the test is written, your developers can move onto building the new policy using policy-as-code.

In this instance, they would simply need to create a scenario where the user trying to access certain data has the same department as the data they are trying to access. From there, they can use the testing framework to run unit tests, nightly tests or full regression tests to make sure the new policy works long before it makes it into production.

Bugs not resolved quickly can get expensive…quickly

This becomes important when we look at the possibility the new policy doesn’t work as expected. The longer it takes for a bug to be identified, the more expensive it becomes.

In fact, according to IBM, if a bug costs $100 to fix in the “gathering requirements” phase, it would cost $1,500 in the QA testing phase and $10,000 once in production.

The quicker you identify a bug in the policy, the quicker and cheaper it is to fix.

But the real cost of a bad policy isn’t that it needs to go back to development, it’s that it means people will either have too little access to do their job, or they will have too much access. Too little access slows down the business and prevents revenue generating activities.

Users with too much access can lead to compliance issues and fines, impact confidentiality agreements or even lead to outsider threats. Both scenarios are dangerous for an organization and can cost literally millions of dollars to mitigate or remedy.

At first, this problem may not be noticeable when creating policies. When there are only a handful of policies, it’s easy to know that they are all working as expected.

However, this doesn’t last long as the number of policies grows into the hundreds, with multiple applications being supported by teams of people building policies. It quickly becomes a challenge to keep track of all of the different policies and feel comfortable knowing they are all working in conjunction with each other and not in conflict or having a similar negative impact.

Considerations through the policy development process

When it comes to policy testing and authorization, here are the three things you should remember:

• Humans make mistakes. It’s not in our nature to be perfect, but building security policies with a proper testing framework removes the element of human error.
• Policy mistakes are expensive. Fixing an issue in policies early reduces the downstream cost of having to fix a policy, but security and compliance violations cost organizations millions of dollars per violation.
• Testing avoids complexity. As the number of policies and applications grows, the level of complexity can grow with it. By building tests into the policies from day one, your developers can ensure all policies continue to work regardless of the number of policies.

Building policies that go through a rigorous testing framework helps make your developers infallible when creating the policies that protect the sensitive information people work with on a daily basis.

This means users always have access to the information they need to do their job, without being over privileged and risk a security or compliance issue.