After a long think this weekend (while not on pain meds) - I still believe that standards & policy bodies for infosec - are still way out of touch with the day-to-day challenges and operations of a security apparatus. It's great to generate data, but have it support decisions. 🧵
3
4
15
If I were to ever think of developing a standard, especially one that relied on collecting data. I'd work backward from what I want as an outcome - versus throwing the kitchen sink in to collect "all the things" & then try tying stuff together with tools. However...
1
2
Nothing against tools that merge and help visualize data... but from prior experience... so much more is done on that part to help transform and visualize the data post collection to help personalize decision-making actions. Laudable, but the tail end work is the issue.
1
2
It still follows not moving consideration on risk- and security-based decisions being considered more on the left side (start) of the equation. We move to get security left with earlier engagement & DevSecOps, but that is even more work, trying to move Napoleon's Army to Russia
1
2
we keep losing resources, time, and other goodies in that push, and find ourselves quite depleted, and easily defeated once we get to the left, and we turn tail to regroup and muster where there's equilibrium. How can you get secure coding standards, when you're...
1
3
blowing a lot of your budget and resources trying to keep DAST/SAST after stuff's already been built? Or trying to integrate digital exhaust (logs, telemetry) from different apps and systems, because nobody thought to align common capabilities or inventory what's out there.
1
3
And this point is fundamentally why I switched from doing operational infosec work to incident response. Trying to effect change left of boom was burnout inducing. So I’ll see you all when you get to the right.
Jul 5, 2022 · 2:35 PM UTC
1
1

