Thread by @MalwareJake

This story is getting a lot of attention. Let me quickly break down for followers not in offensive security what it means.

This is not great, but *the sky isn't falling*. Anyone who says this will immediately result in {thing} is uninformed (or worse) 1/
reuters.com/article/us-glo…

First, we need to take the MSFT information at face value. MSFT says attackers could *view* some code (not sure how much/what) but specifically notes that the attackers could not modify anything.

Claiming "well there's risk they had write access" is unproductive in every way. 2/

As MSFT notes in their blog post, they have embraced an open source threat modeling approach - assume the code will become open and don't tie security to secrecy.

With some companies, you might hear that and call BS. Don't do that here. 3/
msrc-blog.microsoft.com/2020/12/31/mic…

MSFT practically invented the Secure Software Development Lifecycle (SSDLC) - though can we PLEASE drop the first S?

I mean who implements an SDLC and then says "no, we need to make it insecure" - who does that?! But I digress - I'll step down off my soapbox... 4/

MSFT revolutionized secure development practices - and this isn't new. The real push was in the development of the dumpster fire known as Vista.

Did Vista suck? Yep. Was it leaps and bounds more secure than its predecessors? Darn skippy. Ask ANY exploit developer. 5/

So we're talking about a company with almost two decades of commitment to secure coding practices. The attackers are unlikely to find some secret engineering backdoor in the code.

So is this still a big deal? Perhaps. Source code access makes a lot of things WAY easier. 6/

If you need to write rootkits, you know, like this sort of attacker does, then source code access really helps there.

In particular, I'm thinking about two things:
1) The networking subsystem
2) PatchGuard (aka KPP)

However, there are certainly others. 7/

But before I even finish this thread, people at MSFT that are much smarter than me will have been threat modeling with their security teams about how the *specific* source code accessed (which remember, we don't know) might potentially help an attacker. 8/

And then they'll take countermeasures in the OS. And that's important. KPP itself is a countermeasure to what MSFT saw attackers *doing* NOT what they saw them exploiting.

And when was KPP introduced? I'm glad you asked. Vista. See a correlation (hint: it's SSDLC)? 9/

If you take only one thing from this thread, it's DON'T STOP APPLYING PATCHES!

Many "patches" are really security feature updates that aren't remediating a vulnerability, but instead making it harder for attackers to use known techniques to accomplish their goals. 10/

"But Jake, what if they really COULD compromise the build process like they did with SolarWinds?!"

Okay, I'll play that out - keep right on patching. This compromise isn't brand new so in your world you're probably already pwned (unless you haven't patched for a LONG TIME). 11/

So that's it. This is certainly a big deal, we just don't know how big or even specifically why. Unfortunately then it's not actionable.

What do you do then? All the infosec basics: check your logging posture, review trust relationships, and filter traffic at the egress. /12

Oh, and Cyher says to pet your dog. /FIN