@sachafaust One of the things that I find helpful is to use product management frameworks to look at effort and impact over time. Lots of things you 'should have' can take a lot of time to roll out and then don't give you the agility you want (e.g. in detection over custom data sets)...
@sachafaust ... which means the team needs to think about what will move the needle quickly in the short term while also laying the foundation to go from 1.0 to 2.0 of capability (vs waiting for 5.0 and never getting there).
@sachafaust Another product management tool is 'time boxing' for testing new ideas (either on red or blue) and that can be effective in limiting scope (which itself is another important part of testing assumptions under uncertainty).
@sachafaust We've found that linking timeboxed goals via Objectives and Key Results that should only take one 2-week Sprint to complete is a great way of limiting scope and focusing attention on low effort / high impact activities in terms of 'outcome for the business'.
@sachafaust The challenge is how to apply this to multiple threat surfaces when you have more than one (e.g. internet web app, AWS, traditional network etc) that you would call 'a priority' - all be it for (potentially) different attack scenarios.
@sachafaust Another area is how you show a security ticket priority against a business ticket priority. Being able to articulate impact from a threat surface (e.g. the availability of a control gap to credible threat actors, its ease of exploit, the impact from exploit) is super important.
@sachafaust Sometimes the impact of an exploit is that it opens up a whole new part of the attack graph to a threat actors (so no direct biz, impact but wider potential badness by enabling compromise of more stuff). It's helpful to show this to people who have to pull things out of sprints.
@sachafaust That's because it can help with the risk decision of '
"Can this wait? And under what specific circumstances, either relating to a threat or tech change, would it suddenly become much more urgent?"
"Can this wait? And under what specific circumstances, either relating to a threat or tech change, would it suddenly become much more urgent?"
@sachafaust For e.g. if something is v obviously bad (biz asset exposure at low level of sophistication to anyone on internal network) the risk decision may be to close down the biggest avenue for discovery of the asset & implement some detections that IR need to jump on asap if they fire.
@sachafaust That means there's a Sprint action you can take immediately for both 'prevent' and 'detect' - with agreement to look at mitigations for a later Sprint.
@sachafaust I guess the final thing I'd say is you have to k ow how to hack the meta-structure for how things get done in your specific org. Sometimes that is getting a ticket in a Sprint planning session. Sometimes it's knowing the right person at the right level to show the finding to...
@sachafaust ...as you may have some findings that at one level are 'this is way too hard for engineering to fix' (e.g. scrum master) and at another (e.g. cto) are 'Do we turn this feature off right now?'
