If you're worried about 0day exploitation of VPNs:
1. Use IPsec VPNs where possible.
2. use separate identity authorities at network and app layers
3. Make sure that at least app-level traffic (RDP, SSH, https) to admin boxes & Tier 0 is using cert pinning or other server auth 4. Actually take advantage of the ability to turn your double layer perimeter setup into a nightmare for any state actor unwise to exploit their way into it by baselining both typical network traffic patterns to and from the VPN and host telemetry from it.

So with all the negative talk about Microsoft security recently it occurred to me it's interesting to remember that MS also achieved one of the most consequential security successes of the last decade. A success that no one--including MS--ever talks about.

Hardening Office. By Office, I mean of course the Office apps. Principally the Windows desktop apps, and especially the core three: Word, Excel, and PowerPoint.
Three of the most important pieces of software on the planet.

And also, until recently, among the most widely abused for initial entry.

It's honestly pretty funny to me how criticizing Microsoft has gone from almost verboten to The Hot New Thing among prominent infosec folks and journalists.
So let's talk about what is--and isn't--really wrong with Microsoft.
🧵 First of all, let's call out the elephant in the room:

From the standpoint of an MS shareholder who only looks at short-term returns there's nothing wrong with Microsoft's approach to security.

Indeed, things have never been better.

So...
I'm starting to think the most practical software liability regime might use a tiered system of liability standards + safe harbors that--with some limits--would allow software makers themselves to select warranty/attestation levels for their own products.
Let me explain: The idea behind this regime would be that software makers could largely--but not entirely (see following tweets)--select the degree of security quality they would warrant to customers their products would meet in a way both comprehensible to customers and binding on the makers.

The specific, urgent problem where gov agency cyber policy & messaging could probably achieve important gains relatively quickly:
Drastically reducing the number of easy-to-exploit, pre-authentication vulnerabilities in Net-facing software in use by critical infrastructure orgs. (By "relatively quickly" I mean a few years vs decades.)

What if in addition to medium and long-term efforts and things that required extensive discussion, careful consideration, and/or Congressional approval CISA or somebody applied focused, aggressive attention toward that?

Microsoft has released a fascinating, actually pretty transparent post on the recent cloud breach.
Notable:
1. MS unsure how (inactive) consumer/MSA key obtained.
2. A validation flaw allowed that to be used vs Exchange Online.
3. An important API flaw made the situation worse.

https://twitter.com/MsftSecIntel/status/1679899809648455680

The most surprising news concerns point #3. There was a flaw in the GetAccessTokenForResource API that allowed the attacker here to renew access tokens by just providing the previous one, instead of requiring a new token signed by a proper AAD or MSA key.

Lol. This says a lot more about the foolishness of many Washington policymakers when it comes to tech than it does about the substantive merits of his/Microsoft's arguments.

At least the Post pointed out the actual self-interest factor at play here.
washingtonpost.com/technology/202… Smith had to have been absolutely laughing his ass off when he read this quote from a Congressman:

From one standpoint, arguably the central problem with adversary simulation/emulation red teaming in infosec today is that so often there's a mismatch between the types of threat actors organizations most need to better prepare for and the types that red teamers usually pose as. Simply put the number of organizations who need to be focused intently and presently on being able to defeat intrusions conducted by skilled operators using stealthy techniques appears to be much lower than the number who are undergoing red teaming using that threat profile.

It's important to really understand the implications of the fact that threat actors of many types are now regularly using legitimate remote access capabilities--both those built-in to OSes and from third party apps--to maintain persistent remote access into targets. Often, attackers will create these persistence footholds in addition to ones involving the malware they use, for the purpose of trying to establish multiple redundant access channels.
But sometimes there will be no malware C2 footholds at all.

I would very seriously argue that the single biggest factor holding back advances in both the practical art of conducting organizational cybersecurity well and in cybersecurity policymaking is that the details of how breaches of note occurred are almost always kept under wraps. There is immense, underappreciated value in being able to point to specific instances of events and say "The approach you're talking about is the same one that [organizations X, Y, and Z] took. It didn't work. And it would be dangerous here for similar reasons."

A cheap, pre-hardened remote access box (for use as a Privileged Access Workstation & connecting to high-security environments) from MS and based on the Xbox platform is one of the best, enduring, and entirely doable dreams of Windows security people.
One can always dream.

https://twitter.com/SwiftOnSecurity/status/1661063594329489412

Give me a standards-based, interoperable VPN client, SSH client + terminal, and RDP that can connect to Azure Virtual Desktop or on-prem.

On Xbox hardware for like $400-$500. With optional subscription to enable fancy enterprise remote management of the box.

Yup.

Okay, so a non-IT/sec interlude for a moment:

As someone who both handled some child custody cases where couples got married young and takes pragmatic views on many things, you might expect me to agree with "Don't get married or have kids in your 20s."

You would be wrong. I remember a talk with a woman I was representing in a child custody case. At some point, she made a self-critical comment: "I can't believe I made the mistake of marrying him."

My reply:
"You were really in love. And you two wanted to be married. What else could you have done?"

The approach of trying to secure corporate IT infrastructure well by applying bare minimum maintenance & hardening efforts to it and then slathering it in security products & services and dedicated security personnel does not reliably work.

And it will never reliably work. To know and control what equipment, software, and people are allowed in your networks and to access non-public resources, and with what privileges; to understand how things are patched and/or configured, and how they *should* be; and etc: That is the vital foundation of security.

To explain what is going on here for my tech/sec readership, in the American legal system there is a difference between whether a federal Constitutional right exists and whether a cause of action that can allow you to sue officials for money damages for violation of it exists.

https://twitter.com/OrinKerr/status/1608976866974781442

In 1871, Congress passed the Ku Klux Klan Act, one provision of which--later famously codified in Title 42, Section 1983 of the United States Code--allows suits against state officials for money damages* for violating federal Constitutional rights.
*Subject to qualified immunity.

This reminds me, if you have Netflix and haven't seen Challenger: The Final Flight I recommend it.
Challenger is the story of how NASA officials faced a choice between admitting the Space Shuttle couldn't meet the launch pace promised and plowing forward hoping for the best.

https://twitter.com/HumanityCritic/status/1608599422883225600

The people who directly made the decision to launch on that cold Florida morning knew there was probably some greater risk going forward with the rocket booster O-rings at that temperature. But the schedule pressure alongside overconfidence led them to underappreciate that risk.

There's something I wish people understood about cybersecurity policy reform (well many things, but here one in particular):
On most issues where more gov intervention is necessary the best answer is not (IMO, anyway) actually specific proscriptive regulation. *But* that... ...outcome actually becomes more & more likely over time on various issues as interests try--and temporarily succeed--in thwarting more flexible, less intrusive measures being put in place.
Why?
Because that opposition means problems won't get addressed until awful things happen.

I mentioned earlier that it's good that the CSRB will be investigating the $Lapsus intrusions. One particular reason for that (among others) is that, frankly, this will provide a good test case to see whether or not the current board membership is... well, a sham. Here are the key & obvious lessons to learn from the $Lapsus intrusions: (At least based on what is publicly known about them. Which is a lot.)

1. Remote access for ALL privileged accounts--inc. support-- must use cryptographic authentication at important and high-profile orgs.

Look, I'm gonna share a little wisdom with those of you who haven't learned this yet:

Most organizational efforts to do things that are in any way remotely ambitious will fail. At least by some plausible definition of "failure" you could use.

That's how it is. Are there exceptions? Obviously. Do you try to get the projects that you work on to be so of those exceptions? Obviously

But projects/efforts fail for a vast variety of different reasons,any of which have little or nothing with to do with whether you're involved personally.

The failure of Apple, Google, and Microsoft to implement practical cross-interoperability between supposedly "standards compatible" WebAuthn/FIDO2 platform authenticators and their respective services is one of the most important and underappreciated tech debacles of our time. Platform authenticators (using the trusted computing elements of your PC, phone, or whatever to store cryptographic keys) had such potential to enable greater adoption of device-bound WebAuthn/FIDO2 credentials because they could eliminate the need to buy separate hardware.

The major ways (or at least most of them) for cyber actors to attempt to initially compromise your networks, operations, or data, ranked from generally most desirable to least preferable for them:
🧵 1. The most preferred options:
-Exploit Net-facing misconfiguration
-Abuse weak or reused credentials
-Exploit server-side OS/application vulnerabilities
-Credential theft attempts (like cred phishing)

Big week for CISA, and an even bigger one for @CISAJen's tenure.

Version 2.0 of the Cross-Sector Performance Goals set out a genuinely good vision for a voluntary baseline for critical infrastructure cybersecurity.
Will CISA wilt under industry pressure?
politico.com/newsletters/we… To be clear, the measures and goals included in the 2.0 draft are hardly outlandish. Indeed, responsible, decently-resourced CI orgs should already be doing most or all of them. But if you want to pay lip service to cybersecurity they are objectionable.
cisa.gov/sites/default/…