Golden rules of Cloud drift management

For my third year of IT security drift management in Azure, I would like to share considerations from what I've gleaned over time. In a nutshell, the operating model I'm going to put forward is an early bird version of Carl Nygard's point-in-time compliance, the main difference is that our controls are not always blocking devOps pipelines.

Some of the ideas expressed here are opinionated and very organization-dependent, so use your best judgment and don't take them all for granted...

Rule #1: the more immutability by design, the merrier. Your landing zone must be architected in such a way as to limit the number of hotspots where deployments are permitted to drift. Because managing drift is way more costly than preventing it. And because drift reconciliation is often a manual operation that simply doesn't scale.

Rule #2: don't get in the way of your devOps. Be consistent with your own decisions: as soon as you have accepted to mitigate a risk with a detective control (and what best example of a detective control than drift management?), there is absolutely no need to implement a checkpoint in the IaC pipeline [*]. Which is a very good thing for your business, because devOps are magicians that turn business requirements into business value.

Rule #3: commit to a devSecOps operating model. Injecting no checkpoints doesn't mean being deprived of first-class security! A model has to be shared where roles and responsibilities are delineated, where people know one another, what they do and why they do it. An "ivory control tower" clad with knobs, whistles, colorful indicators and endless multidimensional spreadsheets is likely to yield an epic fail here.

Rule #4: decouple the devOps "ground truth" from the security/compliance "ground truth". Each team has its own source of truth with its own rationale, freshness, versioning semantics, grain and accuracy. When in doubt, be driven by agility: centralization brings complexity, stiffness, and discontent.

Rule #5: security/compliance must adjust to devOps continuously, never the opposite. In the Cloud, cybersecurity is not a static business resting on heavyweight sets of "validated practices", "derogations", ... It is a lively bottom-up activity, with security constantly trying to catch up devOps activity and rethinking its role as a rail guard along the way. "This developer is doing something suspicious! Or... Maybe I'm retarded, this guy is an expert and I should try to understand his behavior?"

Rule #6: monitoring drift is meaningless without an accurate, real-time inventory of drifting objects. So far, I believe no single tool has proven to perform great drift management AND great inventory at the same time. What's more, inventory is not magic: it will not auto-discover the assets you need to supervise without being fed with some structured, business dependent clues. (A lot of progress has been recently achieved here... still, auto-discovery remains an hazardous undertaking).

[*] Unless you wish to implement a second-level control, but this is out of scope.