DEVOPSdigest

Q: What is "policy as code" and how does that fit within the overall compliance and security landscape?

A: Policy as code is an evolution of the infrastructure as code movement, which has actually been discussed and adopted in DevOps circles for the past decade. Today, we're at an interesting point where Policy as Code is starting to break out of its DevOps bubble to be embraced more widely across the tech sphere — yet there is still a lot of confusion around what it is and how it can be used most effectively.

At its core, Policy as Code builds off the principles of Test Driven Development in which users first define the business case and intended outcome, also known as desired state, in code. By applying these principles to infrastructure, the desired state becomes defined "as code" and can be used to test infrastructure changes. You might say, okay so why does this matter? Testing has become essential for organizations given the rapid acceleration of app production, putting more pressure on the software development life cycle than ever before. In a push to churn out more products quickly, scaling compliance and security is often left on the backburner, with policies enforced manually and human oversight quickly creating a bottleneck in workflows. In turn, this creates exactly what the organization was working to avoid all along — major developmental delays across teams. But now, with Policy as Code, compliance is baked into the development process much earlier on, removing the hidden risk of these issues cropping up in post-production releases.

Modern system development demands Policy as Code and the higher degree of business confidence that it brings. It goes beyond compliance to overall organizational success, minimizing disruptions by ensuring every change is validated before being pushed to production.

Q: Where does automation fall into this conversation, if at all?

A: DevOps teams live and die by automated pipelines — it's the function by which they can reliably build and deploy code to a production environment. Yet, a practitioner is only as successful as their least efficient pipeline — no one wants to deal with that manual toil. Defining Policy as Code within teams helps declare guardrails within these pipelines and provides a tighter feedback loop which helps train teams over time to recognize when they are close to falling over the proverbial (and cloud) edge.

Q: Are there any external factors or trends that make ‘policy as code' imperative today?

A: Amid an ever-evolving regulatory landscape, organizations simply don't have the right technology or resources to scale their security and compliance efforts. Policy as Code provides the needed agility to address regulations or standards as they evolve. New compliance checks can easily be programmed and shared with the community, allowing both organizational and industry collaboration.

Q: What industries will benefit the most from adopting policy as code?

A: If recent ransomware attacks have proven anything, it's that Policy as Code is important to every industry. For example, in June JBS paid an $11 million ransom to cybercriminals who shut down roughly one-fifth of the nation's meat supply, not to mention the Colonial Pipeline hack that created gas shortages across the East Coast. These are just a few painful examples of how any time you have a change happen to a system outside of a pipeline you introduce risk and systems must then be constantly validated to make sure "rogue" activity has not happened and systems remain in the desired state. This is especially critical for organizations with complex hybrid architectures and hundreds of different devices under management including governmental bodies, banking, insurance, healthcare and energy organizations.

Q: Who within an organization should be at the table when deciding on whether to adopt this practice?

A: IT, security and developers should all be at the table helping to guide their CIO or CTO to a mutually beneficial decision for all parties. Yet, this might be easier said than done. Believe it or not, there is still tension between IT, security and developers despite all of the talk about breaking down cultural silos in recent years. This tension is tied directly to the different, yet interconnected, goals of each of their roles.

Developers are focused on time to market and meeting their release timeline goals while IT/Ops are responsible for keeping systems working as designed and combatting unwanted outages. Meanwhile, security is tasked with only thinking of vulnerabilities and risks. Because of this, both developers and IT/Ops see security as a resource drain requiring additional work without jumping into the trenches to help fix the issues. This is an antiquated mindset though — security and compliance can't just point to the problem and walk away. Instead, they need to be arm in arm with engineers and IT to fix the problem.

Policy as Code melds security into the development lifecycle and opens up the communication lines between these all too often disparate parties to collaborate and help each other where they can.

Q: Can you share a few best practices for organizations who are considering implementing policy as code?

A: Like I mentioned before, the most important step is to unify teams for a more accurate view of compliance on an on-going basis. Building compliance into everything an organization delivers ensures that developers, IT/Ops as well as security and compliance teams have the ability to run the same tests across all stages of the application deployment cycle.

Q: Do you envision policy as code evolving in the future? What does this look like in 5 years?

A: Environments and regulations will only get more complex and distributed in the future, with systems being spun up faster and at a larger scale than we can fathom now. While the pace of innovation will be high, it doesn't have to be painful. With Policy as Code playbooks, systems can be built natively with security baked in — without having to reinvent the wheel with every new app and environment. Policy as Code will allow for greater flexibility and enforcement of different policies across teams, effectively decreasing the cost to comply.