Capturing security policies — such as data access — as code, which can then be tested and automated across the software delivery lifecycle.
The purpose of treating these policies as code is not just to capture policies in as software and data, but to automate security for consistent application across the enterprise and apply software engineering practices to them — for instance, keeping the code under version control, and observing and monitoring policy operation.
This enables enterprises to automate their security policies, increasing their protection against disruption and threats.
Capturing your security policies as code in order to automate it and write tests for it — then demonstrating security by passing those tests and producing an audit trail of having done so.
It enables you to automate security policies, ensuring better adherence to good practices and prove that you did so
It can require cross-disciplinary cooperation that some teams struggle to adapt to.
It is being adopted as a part of agile software delivery lifecycles.
What is it?
As the technology landscape becomes more complex, automation and engineering practices can help keep the enterprise secure. Security policy as code codifies the security policies in place, for instance access control, so that the policies can be treated as tests.
That means as your software teams write code, they can uses these policy as code tests to verify their code is secure — and can take steps to rectify this if not. Following this approach, your teams can be confident that any code put into production follows your security policies.
And because your security policies are treated as code, you should apply engineering practices to them — for instance version control, and observing and monitoring their performance.
What’s in for you?
Security policy as code improves your ability to remain secure in an increasingly complex and fast moving environment. You can ensure that policy requirements, for things like access controls for all production systems, are robust and up to date.
Additionally, as you are able to automate more security testing, your highly trained security experts are able to concentrate on identifying and remediating hard to find edge cases.
What are the trade offs?
Making security part of the development process is a sea-change for many teams and organizations — it brings with it cultural changes that can be hard for those enterprises accustomed to working in silos. Use of red, blue, purple security teams and structure can help alleviate these tradeoffs.
How is it being used?
Security policy as code is being adopted more and more as a part of an enterprise’s security practices. Tools that support it are maturing and we have seen many teams use it with great success. In the Agile lifecycle, it is combined with DevOps, to create a combined pipeline called SecDevOps.
Would you like to suggest a topic to be decoded?
Just leave your email address and we'll be in touch the moment it's ready.