My wife has an uncanny ability to hold pens.
Three highlighters - of different colours - and a pen for writing. All in one hand.
It all started 15 years ago when she started her accountancy career.
She spent many hours reconciling and auditing accounts.
A laborious task of printing out vast spreadsheets and correlating the data line by line.
Each highlighter had a specific meaning - and the pen was to do an Auditor's Tick.
Not a common tick
A special - auditor's one.
In those early days, there were weeks when I didn't need to ask - What did you do at work today? ...I already knew.
Audits of all types have a stereotype. Long. Complex. Labour intensive.
This has led many to view audits as a necessary but rarely conducted evil.
At the same time my wife was diving into financial audits, I was getting to grips with cybersecurity compliance. Many of the same viewpoints applied - especially from the "Do it once, so we can get on with business..." viewpoint.
One counterargument came from a SANS cybersecurity instructor in 2006. I was told, "Microsoft's Patch Tuesday leads to Exploit Wednesday".
If a hacker had a new exploit, from a game theory view - they should wait until the day after the monthly patching cycle… Check the exploit hasn't been discovered… and then relish in the 30 days before a fix is implemented.
Amazon AWS Changed the Game
For cybersecurity - the thinking of point-in-time audits and fixes is almost a decade out of date.
To operate at the scale of AWS, everything must be automated. Their infrastructure is so vast (and security certifications so numerous) that it is rumoured that an external auditor is checking their configuration and ways of working every day of the year.
To meet this incredible demand, they turned to automation.
AWS is known for being the largest consumers of their own services - often creating and using services internally before releasing them publicly.
Their ethos of automated security auditing can be seen in the security services AWS now offer. It started with software-driven access controls in 2010. And continued with configuration auditing, automated security assessments, and in 2019 - gap analysis of your access controls.
The concept of Compliance-as-Code has been loitering on the edges of AWS summits since 2019 - and earlier in their labs programme. The idea being that default configurations and rules are defined in source code. And an audit becomes a search task - looking for anomalies.
AWS are not alone.
Microsoft has started talking about automating, searching and adding compliance checks to a dashboard. And they similarly rely on an API-driven foundation of security configuration and monitoring.
But not everyone has followed this approach. While the two largest cloud operators are heading along an automated audit path, Google remains a notable laggard.
I am repeatedly frustrated that some crucial security configuration settings in Google Workspace are only available via the web interface. And remain surprised that Google only enables software configuration of some settings.
The contrast between AWS and Microsoft runs deeper with Google publicly releasing tools that it then does not use internally - for example, Kubernetes. So maybe that's why Google's compliance-as-code is hidden behind a "Contact Us" button.
It seems - in some areas - it will be necessary to run manual audits for some time to come.