Tanawts

More Network Security Thoughts:
#AssumeBreach

Don't just threat model based upon ingress network traffic to surface area

Design from the standpoint that infrastructure is assumed to get breached and limit exposure to other resources.

We used to do this with 'DMZs' but that concept is largely obsolete in the modern era --

If you can, leverage host-based firewalls to prohibit inbound remote-admin connections except from trusted source-subnets

I shouldn't be able to play ssh/rdp/powershell hop-scotch across your backend network from a webapp server to another.

Nov 8, 2022 at 10:34pmWeb
Show threadTanawtsNov 8, 2022

Relevant case in point: Nate and I have a special place in our hearts for Vulnerable Load Balancers and the internal networks they have direct unfettered access to

https://infosec.exchange/@n0x08/109309471734398495

🇺🇦 Nate Warfield :verified:🌻 (@[email protected])

https://www.bleepingcomputer.com/news/security/citrix-urges-admins-to-patch-critical-adc-gateway-auth-bypass/ I'll be publishing a blog soon detailing how to take over Citrix & F5 devices and install C2 that won't stop running and can infect device backups. Easy enough to detect once you know what to look for. I presented it in person at Ekoparty last week and the slides are here: https://github.com/n0x08/ConferenceTalks/blob/master/BecomeLoadbalancer_Ekoparty.pdf

Infosec Exchange
Show thread🇺🇦 Nate Warfield🌻Nov 8, 2022

@Enigma bruh you are gonna *love* this blog.

Vendors are gonna hate me for it but that’s kinda the point ¯\_(ツ)_/¯

Show threadJeffrey GoldbergNov 9, 2022

@Enigma, I've argued that the whole Green/Red zones was an artifact of network topology. Perimeter gateways allowed for putting defenses there. And so the world built a threat model on the silly notion that traffic from inside is trustworthy. We construct threat models around what we can defend against; not around the actual threats.

Back to your 1st point: I like to say, as part of my job, we don't plan ON being breached, but we have to plan FOR being breached.

Show threadTanawtsNov 9, 2022

@jpgoldberg similar to Mike Tyson's sage advice about planning for vs being punched in the mouth... I've found it help to actually be breached; for a great number of reasons. Synthetically and very much literally.

You learn what works, you learn what doesnt work (technically and/or logistically), you get confirmation of the accepted risks/debt that get paid to the piper, you get a whole lot of servings of humble pie, and when the dust settles, you also get a renewed sense of gravity and urgency about the work the security needs done.

And in a lot if cases, the #AssumeBreach mindset isn't a future tense condition - it is a present state undetected reality waiting for the right bidder to buy the access that has been quietly sitting unused in the environment waiting to be monetized.

I do miss the prod environment war games though

https://m.youtube.com/watch?v=IYcGA-AqcWo

Show threadTanawtsNov 9, 2022

@jpgoldberg - ps, thanks for the work you do at 1Password ;)

Been a loyal user since late 2006

Show threadJeffrey GoldbergNov 9, 2022

@Enigma Thanks. And so you know that E2EE and data minimization are core parts of what we do. If someone held a gun to my kid's head, I would comply with whatever they want. But the damage to customers should still be limited.

The whole Secret Key stuff is part of an #AssumeBreach approach. (This term is growing on me.)

Show threadJeffrey GoldbergNov 9, 2022

@Enigma What is the old saying, "there are two kinds of services: those who have been breached, and those who don't know that they have been breached."

So yes. The #AssumeBreach mindset is right. Don't waste time on yet more anti-phishing training. Instead build your systems to protect what you need to protect under the assumption that parts are compromised.

Show threadTanawtsNov 9, 2022
@jpgoldberg (let's try that again) seems I also forgot to previously link the relevant callback post that the OP was in building on
https://infosec.exchange/@Enigma/109299136236757338#