Policy-driven security makes perfect sense. You’re developing a secure system and you have some compliance requirements it must meet. You start by translating those requirements into a series of security policies with which your system must comply. You then cut loose your DevOps team to develop such a system in accordance with those policies. What could be easier than that?
The Challenges of Policy-driven Security
There are three substantial challenges to implementing policy-driven security in a system or application. The first is that all policies are interpretive and therefore subjective. Consequently, strict adherence to a policy by the system or application is also subjective. What’s the best way to deal with the subjective nature of policies?
The second challenge to implementing policy-driven security is that policies provide no context. They are, in essence, stand-alone “rules”. But secure systems boil down to the relationship between things internal and external to the system. How do you evaluate your policies in context?
The third challenge is provided by the ever-changing nature of today’s systems. Once you assure your system is compliant with the policies, how do you assure it continues to remain compliant as things change?
The good news is that the answer to all three questions above is the same: with threat modeling.
How Threat Modeling Overcomes the Challenges
While it’s true that services like Azure and Google Cloud Platform (GCP) do provide blueprints (or patterns) to help DevOps adhere to regulations from an architecture perspective, there is still no way to way to assure these architectures are compliant with all your policies. Threat modeling is a way of converting subjective policies into an architecture that can then be evaluated objectively. In essence, the threat model makes the policies more concrete and therefore less subjective.
If you decide not to use threat modeling to do policy-based enforcement, you’ll probably use a code scanning tool, which will produce a voluminous amount of findings. And because these findings are completely out of context, they become an avalanche of false positives. How would you handle that?
Threat modeling, on the other hand, takes your policies and puts them in a diagram where you can see all the relationships. Policy-based threat modeling becomes the mechanism by which you check to be sure the relationships support the policies.
And once you confirm adherence to policies, threat modeling can help maintain compliance too. Ideally, every change to a system would be immediately followed by an assessment of policy compliance. However, the changing nature of cloud environments makes this impractical to do manually and in real-time But, modern threat modeling platforms have the ability to constantly scan for changes in the environment and alert on policy violations. This functionality is not the same as policy-driven automation, which suffers from the same contextual and subjective nature of policy enforcement.
Summary
Building systems and applications based on policies derived from compliance regulations is a practical strategy, but it has its challenges. Strict adherence to policy-driven security without understanding the subjective nature of the policy, the context of the policy, or the changing environment, can easily lead to non-compliant solutions.
To see how a modern threat modeling tool can help you evaluate the policy-driven security of your system, check out ThreatModeler.
Schedule a demo today with our cybersecurity experts and fortify your operations!
