Azure policies as security tests
Azure policies are mainly used to streamline organizational standards throughout the deployed Azure resources. This can be as trivial as resource tags and as critical as public access. These policies can also be used to streamline common security practices in your applications. Going from only allowing a certain set of IP addresses in a firewall to limiting access for certain users/resources.
What makes an Azure policy a security test and not a best-practice infrastructure step, is the location where the policy is defined and verified. If the test host is responsible for assigning the policies and verifying the current deployed resources, then it can be considered a security test.
💡 There exists a YAML task to add an Azure policy verification as a deployment gate.
You can also retrieve the definitions in your resource group, and create Pester tests for each of them. When you assert on the policy being ‘Compliant’, you have a dynamic test suite based on the policies.
Azure PSRule as security tests
PSRule brings the best practices from the development and infrastructure worlds together by providing Azure-specific rules that most projects should hold against. Several of these rules are related to security and might indeed overlap with built-in Microsoft Azure policies.
Since this tool is distributed as a PowerShell module, it makes automation fairly easy. It also has built-in output formats that are compatible with Azure DevOps test results, which means that any failures can be reported like any other test failure. That last point cannot be overstated, as besides a good reporting format, the location of the reporting is just as important (and maybe even more). Centralizing information is key here for easy, quick and most of all frequently looked-at reporting.
Code as security tests
One of the often forgotten areas where security testing should happen is right in the code base itself. Common things like ‘check if user has got access to this’ could in some cases be automated by scripting languages, but other times has a big overlap with what the integration tests already defined (same goes for load testing). If the ‘user’ is the subject of the test, then there will be a guaranteed test fixture for a temporary user – in the case that there is a well-defined integration test suite, of course.
These code security tests could be alongside integration tests with specific tags to run them separately, or they could be in a whole separate project, to emphasize their importance.
💡 A tip here would be that it is often good as a defensive strategy to test for things that are not there (like user without the necessary permissions, anonymous access, public resources).
Conclusion
There is only so much you can automate. These security test setups are by no means a replacement for manual, human penetration tests. Creativity can not be automated. But having them in place will provide you with a secure baseline and an awareness to think about security at each stage of the development cycle.
Thanks for reading.
Stijn
Subscribe to our RSS feed