This seems very feasible in the context of a government agency, because each employee can receive her token as part of her onboarding when she is hired. However, this sort of thing is harder to do if you are a SaaS service

It's not. Allow SMS to be disabled in favor of a more secure option (WebAuthn). Strongly suggest that users purchase a token.

I find tokens to be incredibly hard to manage and if you lose them you’re completely screwed forever. And then there’s the problem where every employee gives you a security key do you don’t know which one has which credentials (yes you can add keys but managing all of that physical stuff has a cost).

Although they’re not popular in security circled because technically they’re still vulnerable to phishing websites, I prefer TOTP apps like Google authenticator because it’s backed up to the cloud so even if I lose my phone I know I can get back the keys; it’s the best trade off for security vs usability.

I was confused on my first read through: this guidance seems to refer to federal enterprise applications, not necessarily customer-facing services.

It seems reasonable to me to require employees to use a physical authenticator. Heck, how many of the people here use them and require employees to use them? Often to secure access to applications and resources less consequential than Official Acts Of The Federal Government.

It would feel less reasonable (and a throwback to the ‘00s) to mail out hardware authenticators to customers/members of the public just to, say, buy stamps from the USPS or something.

But the employee needs to be responsible enough not to lose it, they definitely need to not be able to back it up to god-knows-what consumer-grade provider (or to duplicate it at all). And when they lose it, IT needs to know to invalidate the lost one and issue them a new one.

My impression is that physical authenticators (often in the form of smart cards that double as employee ID) are pretty much table stakes in serious federal environments anyway, is that mistaken?

The main issue with TOTP is that it's still vulnerable to phishing, though it certainly is significantly better than SMS.

Yes but as I said, I’m personally less concerned about a successful phishing attack. I can see why you might be concerned as an employee to a multi billion dollar business but attacks on my personal safe are unlikely to be sophisticated enough to fool me / I’m not a target for sophisticated ones. UX vs threat model tradeoff.

Passkeys might provide a decent middle ground here, assuming current UX issues can be improved upon.

A lot of good stuff in the recommendations, but I find this one questionable:

“Enterprise applications should be able to be used over the public internet.”

This is straight up arguing against defense-in-depth, and getting rid of connection auditing and interception capability. Seems extremely dubious, unless by "be able to" they mean "it should be OK security-wise if you get rid of the VPN" and not "you should actually get rid of the VPN".

This is a fairly common recommendation for "zero trust." A VPN is theoretically superfluous in a zero trust environment, where you have no concept of a trusted network and your applications should be sufficiently hardened to prevent unauthorized access. Google operates this way, if I recall correctly. It's how their "Beyond Corp" white-paper recommends setting up the environment.

It's not exactly a "one size fits all" solution; I believe PCI requires VPN usage, for example, so a bank trying to implement zero trust practices would need to keep their VPN intact, but that's a regulatory concern, not so much a technical one.

A VPN is theoretically superfluous in a zero trust environment, where you have no concept of a trusted network and your applications should be sufficiently hardened to prevent unauthorized access.

Defense in depth is theoretically superfluous in a secure system, but it's still a good idea for... what I thought were obvious reasons. I don't see how this is any different.

And, again, as I mentioned above this isn't even just about network trust, it's also about the ability to monitor, audit, and intercept potentially malicious connections when something does get compromised. "We assume our one layer of security will work perfectly" cannot be the starting assumption...

Google operates this way, if I recall correctly.

Google also has 24/7 world-class security teams monitoring everything across the planet. They have a ton of power to monitor and mitigate damage across the entire internet. Just because something works for Google that doesn't mean it'll work for arbitrary organizations.

Defense in depth is an idea that has probably done about as much harm as it's done good. The notion that your apps should be exposed on the public Internet is about clarifying the need for sound authentication on apps. In the OMBZT cinematic universe, there is no meaningful security benefit from being masked on a VPN, because so many different people get access to those VPNs.

Your mileage will vary. I wouldn't expose internal apps on the public Internet even as I acknowledge the ideas OMBZT is pursuing make sense in OMB's setting.

Defense in depth is an idea that has probably done about as much harm as it's done good

Citation needed?

I'm not going to give you a citation. Historically, "defense in depth" has been a way to inoculate security tooling from critique or even assessment; things don't need to work at all in a "defense in depth" regime, because you can always say there's some marginal "fail2ban"-level utility to any countermeasure and retain it on that basis. It has in cases prevented meaningful defenses from being deployed, and has crudded up lots of people's attack surfaces. You see this most clearly in endpoint security, where "defense in depth" loaded everyone up with security and AV agents that were all riddled with memory corruption vulnerabilities.

Both of the following can be true simultaneously:

1. The term "defense in depth" can be popularly abused by irresponsible people looking to pass the buck on security.

2. An application that is intended to withstand being exposed to the public internet becomes strictly more secure when it isn't exposed to the public internet.

I can buy that the government contractors who fall into the former category are sufficiently numerous and sufficiently gormless that this memo is intended to be used as a weapon to drag them kicking and screaming towards default-secure applications. But for people who are already responsible enough that they're doing the right thing, keep using a VPN. Redundancy is resiliency.

You see this most clearly in endpoint security, where "defense in depth" loaded everyone up with security and AV agents that were all riddled with memory corruption vulnerabilities

There's no way you can seriously argue AVs have caused remotely as much damage as they've mitigated or prevented. Especially not without any kind of citation to back it up.

It has in cases prevented [...]

A lot of things go wrong "in cases". In cases, governments give poor recommendations. In cases, HN users give nonsensical opinions. In cases, police end up killing civilians instead of criminals. In cases, criminals go free because they refuse to testify against themselves. I could go on, but you could use this kind of argument to dismantle just about anything you don't like. Especially when you absolve yourself of the need to provide any kind of evidence of the relative harms.

Not only do I argue that, but it's a banal argument among security practitioners.

Not only do I argue that, but it's a banal argument among security practitioners.

Well that's great to know. Do all security practitioners also believe whatever they hear from each other without question? Or do they only expect us mortals to treat them that way?

Have you heard a similar argument to “we don’t need authentication to this application because it’s only accessible on the VPN”?

It allows some pretty sloppy thoughts about security. Treating apps as if they were public is correct because the damage is more likely to be done with someone who already has access.

None of this is new to me, unfortunately. Going through getting FedRAMP High for my company and there are a lot of hoops to jump through. 80% of it is very reasonable e.g. DNSSEC, Hardware MFA. 20% of it is theater: You cannot, for example, allow AWS Govcloud to handle SSL termination for ECS. You have to manually verify S3 replication and cannot rely on their logging.

Still, echoing other commenters' sentiments, it's nice to see the government being forward-thinking on this. Jury is still out for NIST to weigh in on post-quantum encryption.

DNSSEC isn't reasonable, and the OMB memo doesn't require it. CLOUD.GOV doesn't even support it.

NIST has standardized a set of PQC constructions; I think the jury is in there.

NIST has standardized a set of PQC constructions; I think the jury is in there.

Published 4 days ago, thanks for the heads up. I was curious if they would delay announcing the CRYSTALS-Kyber algorithm as their choice after a paper claimed that they were able to decrypt it without quantum. I just looked the paper up and they had a bug in their code, so their claim was dropped. https://eprint.iacr.org/2024/555

DNSSEC isn't reasonable

Memo doesn't mention it, but please enlighten me as to why you feel this way. I think it's a low-effort way to prevent a (admittedly esoteric) attack.

You cannot, for example, allow AWS Govcloud to handle SSL termination for ECS.

Are you saying you can't terminate TLS at the ALB in FedRAMP high and instead have to terminate TLS at the node/pod level? That's the exact opposite interpretation that we have taken.

Yes, TLS all the way at every layer, but we explicitly terminate at the ALB first.