[HN Gopher] Redefining Threat Modeling: Security team goes on va...
___________________________________________________________________
Redefining Threat Modeling: Security team goes on vacation
Author : mooreds
Score : 36 points
Date : 2021-04-07 15:11 UTC (7 hours ago)
(HTM) web link (segment.com)
(TXT) w3m dump (segment.com)
| motohagiography wrote:
| Some of my favourite threat actors to model are ones who
| developers can empathize with. What I call grad students and
| conference papers, where someone who is doing it for the
| professional prestige is pulling your feature or product apart.
|
| A lot of threat modelling is story telling around your product.
| Who uses it, why, and how could someone else benefit from
| stealing what your company gets out of it? I formalized that
| threat story development it into a product a few years ago, and
| it actually generated security epics and stories, but ran out of
| runway for it and moved back into consulting, but the reason I
| think people get into security is precisely because of the threat
| modelling aspect of it. It's really the fun part of the field
| where you get to inhabit a kind of cyberpunk noir world of spies,
| opposition researchers, organized crime, hackers, and activists.
| I moved on from it because unfortunately 95% of the material
| demand for security is driven by Compliance, which is a set of
| methodologies designed to specifically avoid having to
| acknowledge your real threat model, because to do so and write it
| down creates discoverable liability for potential negligence in
| some enterprise cultures. Taking risks of all kinds is the game
| in business, and narrating the risk game and winning it at the
| same time can be hard to reconcile. However, a company that can
| look at its real risks and threat model and get everyone down to
| developers aligned on what they're doing and why is probably a
| 10x company culture. It might be worth looking at whether threat
| modelling could be used in product orgs as the founding narrative
| or story to get that kind of alignment that would supercharge
| their teams.
| mox1 wrote:
| Worked for a major medical device manufacturer in security for
| a few years. That was (and probably still is) their #1 threat
| model.
|
| Security Researchers at conferences moved the security needle
| far more than any other threat actor.
|
| I wont opine on whether this is good or bad, just interesting
| to note that this is real.
|
| The threat model is hard, because you have all this "meta"
| stuff. We also commonly ended up in "proving a negative"
| arguments with researches and regulators.
|
| Researcher X says "I can do this, so giving this other set of
| circumstances I can probably do this".
|
| We would say, "No, we looked into that, doesn't work that way."
|
| Researcher X "Prove it".
|
| We then enter a standstill where we try to figure out how we
| "prove" our product isn't vulnerable!?!?
|
| It eventually felt like trying to prove bigfoot was or wasn't
| real.
| suifbwish wrote:
| It's probably safe to say that some major hacks have been
| made possible by security researchers publishing POCs for
| vulnerabilities that will inevitably never be completely
| patched by everyone. It's not like a POC is just a tool
| that's being abused, it literally has only one purpose.
| rreichel03 wrote:
| I had the pleasure of meeting these folks while they were
| building out this program - It was incredible to see the work
| they put in to truly scale out threat modeling by enabling dev
| teams to understand security risk.
|
| Kudos to them on helping push us to a more secure future!
| jameshart wrote:
| The biggest obstacle I struggle with in getting good threat
| modeling done is keeping the model up to date as design decisions
| and constraints change.
|
| Building a threat model in to the 'design phase' only makes sense
| if you have a design phase - but an iterative dev cycle is just
| continuous overlapping design and dev phases. It can be really
| hard to recognize that a particular iteration of a design change
| is the one that broke one of the assumptions built into your
| previous threat model.
|
| I'm really interested in ways to turn threat models into
| verifiable constraints and executable tests so iterative
| development can proceed safely in the framework of agreed
| security guardrails... but most threat modeling literature seems
| to end at 'having a threat model', not 'verifying your threat
| model actually applies to your system'...
| ghughes wrote:
| This is interesting in that it positions security engineering as
| an that is to be
___________________________________________________________________
(page generated 2021-04-07 23:02 UTC)