Recently, there was a brief flurry around the ability to ‘audit’ in agile environments or not.
Some notes:
- Agile development methods (which would include organisational changes …!) can be audited of course. Either from the Soll or As Is, probably with a wide margin between the two, vis-à-vis the just-delivered To Be which in itself is rather some vague proxy for the actually originally wanted To Be. From this, flow your findings. Gaps abound.
- Side stepping the issue of DevOps/DevSecOps or is that in:
- Security in a narrow sense, by the way, can be done; easily implemented and maintained (if properly tested against possibly lost controls). But one fails when security controls — mind you, a vast majority of controls are about security-in-the-widest-sense of safeguarding (hah! as if your posture is effective beyond mere luck and happenstance!) against loss of value — just don’t fit a sprint or any dev cycle you’d use. Still, when considering the Wagile/Agifall bandwidth, security controls can be of the higher level and still get implemented in parts (sprints ..? or ‘supersprints’ or what?). If, big if, only your sprint deliverables aren’t pushed into production as soon as available. They are not MVPs ..!! First, even for the minimalistic of minimal deliverable, some security controls larger than a sprint, may (will, for sure) have to be in place; how ..? Security in epics doesn’t necessarily help here. Building the sec infra first, maybe — but that goes against about-all of the agile idea, right? (Wrong, by the way: the agile manifesto wasn’t cast in stone as late, late laggards want to do their sprint’lets.) There’s more to life than picking up only the easiest, nicest post-its on Monday morning.
- Also, it remains superbly important to remember this, on re-use of code…
- Supposing you’ve ‘fixed’ security in your sprint teams e.g., by including a sec officer where appropriate+ (details to be had here), one (given the above: ‘hence’) can indeed audit e.g., at epic level, if the focus retreats to control objectives not controls — a dire need for sanity already in the audit world — and flexibility in the detailed implementation is maintained. Given such continuous development, there would be need for more Prove Me than before even if this runs against my personal grain. By way of showing the completeness and consistency of the controls you had put / maintained in place vis-à-vis [that one again] control objectives. But that’s just the Law of Conservation of Trouble; you want to be flexible and do the Agily-scrummy-kindergartenfreedom’y thing, then you also do the chores, only the sun rises for free (i.e., you don’t get owt for nowt).
- If you don’t want to see that, you have no place in the organisational world. Controls are about non-flexibilising business, in their essence; their very (need for!) existence is based on not allowing ad hoc deviations. So, if you want no controls, you want no work.
- Now, as a homework assignment: outline how this translates back up when the control objectives are just the How of a higher-level control objective’s What.
- Oh and there’s another strand which is about the transformation of the IT function in (larger) organisations. No longer the controller over all things IT but having to turn into a flex intermediairy between business demand (in broad terms! and including security requirements) and delivery-from-anywhere. I see trouble when this has to be squared with agile team work; who does what when parts are elsewhere?
Never mind. ..?
For the trouble, I’ll give you:
[Not all plain sailing; St. Cat’s Docks London]