26 ms·

I read the federal government’s Zero-Trust Memo so you don’t have to

656 points by EthanHeilman 5y ago

staticassertion 5y ago
This is pretty incredible. These aren't just good practices, they're the fairly bleeding edge best practices. 1. No more SMS and TOTP. FIDO2 tokens only. 2. No more unencrypted network traffic - including DNS, which is such a recent development and they're mandating it. Incredible. 3. Context aware authorization. So not just "can this user access this?" but attestation about device state! That's extremely cutting edge - almost no one does that today. My hope is that this makes things more accessible. We do all of this today at my company, except where we can't - for example, a lot of our vendors don't offer FIDO2 2FA or webauthn, so we're stuck with TOTP.
- suns 5y ago
  Yea, imagine the implications of federal agencies all implementing this successfully. Can't wait to see what the trickle down(?) effect is.
  - dev-3892 5y ago
    "downstream" might be the word you're looking for
  - chasd00 5y ago
    lots of billable hours for the various consulting firms. "we'er so happy we can hardly count" - Pink Floyd
- EthanHeilman 5y ago
  We've been building to these goals at bastionzero so I've been living it everyday, but I feels validating and also really strange to see the federal government actually get it.
- meepmorp 5y ago
  Also, “Password policies must not require use of special characters or regular rotation.” They even call out the fact that it's a proven bad practice that leads to weaker passwords - and such policies must be gone from government systems in 1 year from publication of the memo. It's delightful.
  - CGamesPlay 5y ago
    I am a bit concerned that this will be read as "Password policies must require the use of no special characters", possibly as a misguided attempt to push people away from adding using "Password123!" as the password. I wish the memo had spelled out a little more clearly that there's nothing wrong with special characters, but they shouldn't be required. Also, is a whitespace a special character?
    - pm90 5y ago
      If we were to stop using special characters and only use human friendly phrases (eg “jupiterIsTheSmallestPlanet”) it wouldn’t be the end of the world.
      - godelski 5y ago
        But if a whitespace is not a special character (or punctuation) we can add entropy with "Jupiter is the smallest planet!" while still being human readable and using the passphrase paradigm.
  - atuladhar 5y ago
    Somewhat unrelated, but hopefully this also means TreasuryDirect will get rid of its archaic graphical keyboard that disables the usage of password managers. (Graphical keyboards are an old technique to try to defeat key loggers. A frequent side effect of a site using a graphical keyboard is that the developer has to make the password input field un-editable directly, which prevents password managers from working, unless you use a user script to make the field editable again.)
    - 5y ago
- pitaj 5y ago
  What's wrong with TOTP?
  - Sesse__ 5y ago
    It authenticates the user to the service, but not the service to the user, so it's vulnerable to phishing (or MITM, of course, if you don't have TLS).
  - jaycroft 5y ago
    I was wondering the same thing - here's an article I found that describes both approaches. Not being in the cryptography space myself I can't comment on how accurate it is, but passes my engineering smell test. https://blog.trezor.io/why-you-should-never-use-google-authenticator-again-e166d09d4324 https://blog.trezor.io/why-you-should-never-use-google-authe... Edit - sorry that this is really an ad for the writer's products. On the other hand, there's a hell of a bounty for proving them insecure / untrustworthy, whatever your feelings on "the other crypto".
    - deleted 5y ago
      [deleted]
    - tptacek 5y ago
      Yeah these are very dumb arguments against TOTP.
    - deleted 5y ago
      [deleted]
  - tptacek 5y ago
    It's very phishable. Attackers will send text messages to your users saying "Hi, this is Steve with the FooCorp Security Team; we're sorry for the inconvenience, but we're verifying everyone's authentication. Can you please reply with the code on your phone?" It's even worse with texted codes because it's inherently credible in the moment because the message knows something you feel it shouldn't --- that you just got a 2FA code. You have to deeply understand how authentication systems work to catch why the message is suspicious. You can't fix the problem with user education, because interacting with your application is almost always less than 1% of the mental energy your users spend doing their job, and they're simply not going to pay attention.
- c0l0 5y ago
  I think 3. is very harmful for actual, real-world use of Free Software. If only specific builds of software that are on a vendor-sanctioned allowlist, governed by the signature of a "trusted" party to grant them entry to said list, can meaningfully access networked services, all those who compile their own artifacts (even from completely identical source code) will be excluded from accessing that remote side/service. Banks and media corporations are doing it today by requiring a vendor-sanctioned Android build/firmware image, attested and allowlisted by Google's SafetyNet (https://developers.google.com/android/reference/com/google/android/gms/safetynet/SafetyNet https://developers.google.com/android/reference/com/google/a...), and it will only get worse from here. Remote attestation really is killing practical software freedom.
  - seibelj 5y ago
    Reproducible builds are a thing, I don't know how widespread they are. I know the monero project has that built in so everyone compiles the exact same executable regardless of environment, and can verify the hash against the official version https://github.com/monero-project/monero https://github.com/monero-project/monero
    - nybble41 5y ago
      Reproducible builds allow the user of the software to verify the version that they are using or installing. They do not, by themselves, allow the sort of remote attestation which would permit a service to verify the context for authentication—the user, or a malicious actor, could simply modify the device to lie about the software being run. Secure attestation about device state requires something akin to Secure Boot (with a TPM), and in the context of a BYOD environment precludes the device owner having full control of their own hardware. Obviously this is not an issue if the organization only permits access to its services from devices it owns, but no organization should have that level of control over devices owned by employees, vendors, customers, or anyone else who requires access to the organization's services.
      - InitialLastName 5y ago
- dc-programmer 5y ago
  For anyone interested in 3, Google’s BeyondCorp whitepapers are an excellent starting point
- vmception 5y ago
  Force banks to do this, immediately. They can levy it on any organization with a banking license or wants access to FEDWire or the ACH system. Force it for SWIFT access too, if the bank has an online banking system for users.
  - criddell 5y ago
    I asked my bank about their 16 character limit on password length because it suggests they are saving the password rather than some kind of hash. Their response - don't worry about it, you aren't responsible for fraud. Banks aren't going to want to implement any changes that cost more (in system changes and customer support) than the fraud they prevent.
- nextos 5y ago
  > 1. No more SMS and TOTP. FIDO2 tokens only. SMS are bad due to MITM and SIM cloning. In EU many banks still use smsTAN, and it leads to lots of security breaches. It's frustrating some don't offer any alternatives. However, is FIDO2 better than chipTAN or similar? I like simple airgapped 2FAs, but I'm not an expert.
  - tptacek 5y ago
    The major advantage of FIDO2 is that it's difficult to phish. SIM cloning is not the primary reason organizations are now advocating against SMS 2FA.
    - tialaramex 5y ago
      In particular [Thomas knows this, for anybody else reading], WebAuthn (the way you use FIDO for the web, U2F is a legacy system for doing the same thing that you should not use in greenfield deployments) recruits your web browser to defeat phishing. When you use WebAuthn to sign into an site the browser takes responsibility for determining which site you're on, cutting out the whole phishing problem of "Humans don't know which site it is". The browser isn't reading that GIF that says "Real Bank Secure Login" at the top of the page or the title "Real Bank - Authenticate" or the part of the URL bar that says "/cgi-bin/login/secure/realbank/" it is looking only at the hostname it just verified for TLS which says fakebank.example So the browser tells your FIDO authenticator OK, we're signing in to fakebank.example - and that's never going to successfully steal your Real Bank credentials because the correct name is cryptographically necessary for the credentials to work. This is so effective crooks aren't likely to even bother attacking it.
- codemac 5y ago
  Google does 1, 2, and 3 internally. If you join https://landing.google.com/advancedprotection/ https://landing.google.com/advancedprotection/ you can get something similar for personal public accounts.
  - withinboredom 5y ago
    I prefer to keep my email as dumbly secured as possible. I’ll never forget this one time I was on my sailboat with no cell service and only an open WiFi connection from shore. I couldn’t login to anything via sms auth. Same thing with FIDO keys when traveling. Lost luggage? No logging in for you until you get home to get your backup? Cut your finger while cooking? No logging in for you! Have to wear a face mask? No logging in for you! To be clear, I don’t have a better solution. But all the second factor stuff is fundamentally broke when you are likely to need access to the service most.
    - tialaramex 5y ago
      So, I'm somebody who thinks about contingencies a lot and to my mind, there's just not a lot of gap between situations where you don't need credentials (e.g. satellite beacons don't care who you are) and where you don't have credentials (oh no, I lost all the gear) so it doesn't represent a big worry for me. I don't want the consular officials to be unable to authenticate me in a foreign country because I lost my phone, or for my bank to be unable to release funds because I don't have their card or my Security Key, but I feel 100% OK with losing access to Gmail or Hacker News, or whatever for say a few days until I can secure replacement credentials.
    - philjohn 5y ago
      The SMS point is part of why moving to FIDO keys is a good idea - the NFC enabled ones work with modern smartphones and allow you to login. As for lost luggage, I carry mine on my keychain, another one in the laptop itself (USB-C Yubikey) and one in my safe at home - if all three are ever destroyed or lost I also have backup codes available as password protected notes on several devices.
  - staticassertion 5y ago
- mnd999 5y ago
  Bleeding edge or complete fantasy? This is going to be very very expensive and guess who’s going to be paying for it?
  - tssva 5y ago
    As with most OMB memos it is complete fantasy and agencies won't comply by the date, any date close to it or really ever. The answer to the question "who's going to be paying for it?" is nobody which is why it will never actually get done.
    - mnd999 5y ago
      Government contractors are expert at getting paid to deliver nothing.
- melony 5y ago
  Isn't 3 responsible for all those HN horror stories about being locked out of their Google accounts while traveling?
- warner25 5y ago
  "...fairly bleeding edge best practices..." By the time we implement any of these things, if ever, they certainly won't be. I work on military networks and applications, and it's hard for me to believe that I'll see any of this within my career at the pace we move. This is the land of web applications that only work with Internet Explorer, ActiveX, Siverlight, Flash, and Java Applets, plus servers running Linux 2.6 or Windows Server 2012. The idea of "Just-in-Time" access control where "a user is granted access to a resource only while she needs it, and that access is revoked when she is done" is terrifying when it takes weeks or months to get action on support tickets that I submit (where the action is simple, and I tee it up with a detailed description of whatever I need done).
  - staticassertion 5y ago
    Maybe, but my hope is that this pushes external vendors that have government contracts to support these workflows.
  - post_from_work 5y ago
    It took us NINE MONTHS to get a server installed in a data center a few years back. This was Marine-Corps fielded hardware running an ATO'd[1] software stack for real-world situational awareness, going into a Marine Corps data center. The people that run the data center have a glacial Change Management process, exacerbated by everyone in their organization not talking to each other, even though they are separated by cubical walls. I too have no faith of seeing this stuff implemented anytime soon... [1] (Authority to Operate, basically approval from the highest IT authorities to utilize something on a DoD network)
    - warner25 5y ago
      Haha, yes, my day-to-day work for the past two years has been fighting exactly this same fight on the Army side.
- Alex3917 5y ago
  Given that every cybersecurity czar seems to publicly resign a few months after being appointed, what are the chances of these actually being implemented?
- raxxorrax 5y ago
  These are strong requirements, but I fear the government just wants more transparency of citizens. Remote-attestation of trusted platforms could lead to the worst surveillance attempts we have ever seen. And it would require you to trust your government. That is a bad idea from a security point of view. edit: The source of my claim that governments tend to extend surveillance is pretty well documented I believe. So much so that I believe it is worthy to insert the problem into debates about anything relating to security. Because security often serves as the raison d'être for such ambitions.
  - cabbagehead 5y ago
- cabbagehead 5y ago
uncomputation 5y ago
> “Enterprise applications should be able to be used over the public internet.” Isn’t exposing your internal domains and systems outside VPN-gated access a risk? My understanding is this means internaltool.faang.com should now be publicly accessible.
- 3np 5y ago
  There are different ways to look at it. From a defense-in-depth perspective, you are right. That is, however, one of the main points of a zero-trust environment (or you could say Zero Trust), which is a kind-of-new trend that much has been written about. Think about it this way: In the context of ransomware attacks, a lot of times it's game over once an internal agent is compromised. The premise of zero trust is that once an attacker is "inside the wall", they gain basically nothing. Compromising one service or host would mean having no venue for escalation from there. I wouldn't say it's objectively better (maybe by the time I retire I can make a call on that), but it's a valid strategy. Certainly better than relying on perimeter-based security like VPN alone, as opposed to it being just one layer of DiD, though.
- enriquto 5y ago
  As I understand it, this sentence says that the application should be safe even if it was exposed to the public internet, not that it needs to be exposed. It is a good practice to securize everything even if visible only internally. The "perimeter defense" given by a VPN can be a plus, but never the only line of defense.
  - jaywalk 5y ago
    No, the memo pretty clearly says that VPNs need to go away.
    - deleted 5y ago
      [deleted]
    - MattPalmer1086 5y ago
      It says that VPNs and other network tunnels should not be relied on. Where does it say they should go away?
adreamingsoul 5y ago
Here in Norway we have BankID which uses MFA. To access any government, banking, or official system you have to authenticate with your BankID. Its simple amazing.
- brimble 5y ago
  There's significant bi-partisan resistance, in the US, to anything like a national ID, unfortunately, with the result that we have one anyway (because of course we do, the modern world doesn't work without it) it's just an ad-hoc combination of other forms of ID, terrible to work with, heavily reliant on commercial 3rd parties, unreliable, and laughably insecure. But the end result is still a whole bunch of public and private databases that personally identify us and contain tons of information—kind of by necessity, actually, since our ID is a combination of tons of things. It's a very frustrating situation. Worst of both worlds.
  - seniorThrowaway 5y ago
    I've done some thinking about this, and a possible solution is a bunch of cross signed CA's like the Federal common policy / FPKI for cross trust amongst federal agencies, but done at a state DMV / DPS level. Driver's licenses / state IDs could have certs embedded into the cards and then be used for things like accessing government websites, banks, etc. Yes there are some access concerns, and some privacy concerns that this is in essence a national ID, but what we have now is horribly broken, and we're already being tracked. We get all the downside of pervasive tracking, but none of the upside.
    - currency 5y ago
      Would that look anything like the REAL ID system?[0] [0]https://www.tsa.gov/real-id https://www.tsa.gov/real-id
- thomascgalvin 5y ago
  I'm America, about 30% of the population would start screaming about the Mark of the Beast if we tried to roll out something like this.
tims33 5y ago
Really pleasantly surprised at how progressive this memo is. It will be interesting to see the timelines put in place to make the transition. Btw - I'd love to see the people who put this memo together re-evaluate the ID.me system they're implementing for citizens given how poor the identity verification is.
- YeBanKo 5y ago
  I have an issue with using ID.me for government websites, because it is a privately owned company. Online authentication at this point seems as important as USPS service and warrants being owned and developed by the government itself.
  - dmd 5y ago
    They even HAVE this already, at https://login.gov/ https://login.gov/ !
    - tialaramex 5y ago
      I have a login.gov account. Needless to say I'm not a US citizen, and the IRS should not cut me a refund check. ID.me supports WebAuthn (or maybe U2F? In this context it doesn't matter) but importantly it does identity verification so it can determine whether I am a US citizen, whether I'm a tax payer, and if so which one. Now, perhaps the US Federal Government should own the capability to do that instead of a private company. But, so far as I can tell, they do not and login.gov is not such a thing.
      - parkerhiggins 5y ago
        A private company shouldn’t own this capability. Especially as ID.me CEO lied about maintaining a database of every face “1-to-many” that uses their verification system. They’re right up there with Clearview AI. https://www.theverge.com/2022/1/26/22903437/id-me-facial-recognition-databases-irs-match https://www.theverge.com/2022/1/26/22903437/id-me-facial-rec...
      - 5y ago
KarlKemp 5y ago
I’m somewhat unhappy the “zero trust” terminology ha caught on. The technology is fine, but trust is an essential concept in many parts of life[0], and positioning it as something to be avoided or abolished will just further erode the relationships that define a peaceful and civil society. 0: trade only works if the sum of your trust in the legal system, intermediates, and counterparts reaches some threshold. The same is true of any interaction where the payoff is not immediate and assured, from taxes to marriage and friendship, and, no, it is not possible to eliminate it, nor would that be a society you’d want to live in. The only systems that do not rely on some trust that the other person isn’t going to kill them are maximum-security prisons and the US president’s security bubble. Both are asymmetric and still require trust in some people, just not all.
- kstrauser 5y ago
  The "trust" here largely refers to identity. Do you trust that everyone in your house is your relative, by virtue of the fact that they're in your house? That falls down when you have a burglar. Similarly, is it good to trust that everyone on your corporate network is an employee, and therefore should have employee-level access to all the resources on that network? I wouldn't recommend it.
  - KarlKemp 5y ago
    No, but I trust the people I regularly interact with and therefore allow them to be in my home. Nobody trusts people just because they happen to be in their home. To the extend that trust can go to “zero”, my fear is it will harm the (existing) first form of trust, which is vital, and have little impact on the stupid latter definition of trust. I know tech operates on different definitions/circumstances here. That’s why the word ”zero” is so wrong here, because it seems to go out of its way to make the claim that less trust ks always better. Call it “zero misplaced trust” or “my database doesn’t want your lolly”, whatever.
    - agar 5y ago
      I see this as the exact point of the Zero Trust terminology. People extend your exact trust assertions to their networks, and bad actors exploit it to effect a compromise. A corporate network cannot be like your home. Zero Trust says that you should assume anything, and anyone, can be exploited - so secure appropriately. Per your analogy, what would you do if your invited houseguests, unbeknownst even to themselves, wore a camera for reconnaissance by a 3rd party? What would you do if these cameras were so easy to hide that anyone, at any time, might be wearing one and you couldn't know? You would have to assume that anyone that entered your home had a camera on them. You would give them no more access than the bare minimum needed to do whatever they were there to do (whether eat dinner or fix your sink). You'd identify them, track their movement, and keep records. Your term, "Zero misplaced trust," assumes that you can identify where to place trust. Did you trust that system you had validated and scanned for 5 years...until Log4shell was discovered? Did you trust the 20-year veteran researcher before they plugged in a USB without knowing their kid borrowed it and infected it? Zero Trust is a response to the failure of "trust but verify."
paganel 5y ago
> Do not give long-lived credentials to your users. This screams "we'll use more post-it notes for our passwords compared to before", or maybe the real world to which this memo is addressed is different compared to the real (work-related) world I know.
- the_jeremy 5y ago
  It specifically calls out not requiring regular password rotation. Short-lived credentials is for tokens with expiration, not the password you use to login to the service that gives you the token.
  - paganel 5y ago
    Got it, thanks.
- tptacek 5y ago
  The general attitude among practitioners now is that "post-it notes with passwords on them" is superior to the more common practice of "shitty passwords shared across multiple services".
  - cpach 5y ago
    Back in 2009 or so I stored my most-frequently used psswords on a piece of paper in my wallet. (These days I simply use 1Password.)
- Godel_unicode 5y ago
  This was a very unfortunate choice of words by the author, as they don't mean credentials as in the credential a user uses to initially authenticate to the system. Rather they mean authentication tokens, be they Kerberos tickets, bearer tokens, etc. This memo in particular emphasizes the existing guidance the US government has issued around not expiring passwords. If you are a federal agency, you can have (and are in fact encouraged to have!) users with passwords that are unchanged for years. Edit: it's worth pointing out that the memo does a great job of laying this out. I work in security, so possibly there's some curse of knowledge at play, but I found the blog post explainer to be less clear than the memo it is explaining...
ctime 5y ago
The real crux of the issue is the long-tail of applications which were never conceived with anything but network-based trust. I'm certain the DoD is absolutely packed with these, probably for nearly every workflow. The reason this was so "easy" for Google (and some other companies, like GitLab[1]) to realize most of these goals is that they are a web-based technology company - fundamentally the tooling and scalable systems needed to get started were web so the transition were "free". Meaning, most of the internal apps were HTTP apps, built on internal systems, and the initial investment was just to make an existing proxied internal service, external and behind a context aware proxy [1]. The hard part for most other companies (and the DoD) is figuring out what to do with protocols and workflows that aren't http or otherwise proxyable. [1] https://cloud.google.com/iap/docs/cloud-iap-context-aware-access-howto https://cloud.google.com/iap/docs/cloud-iap-context-aware-ac... [2] https://about.gitlab.com/blog/2019/10/02/zero-trust-at-gitlab-implementation-challenges/ https://about.gitlab.com/blog/2019/10/02/zero-trust-at-gitla...
- wordsarelies 5y ago
  As if Gov't does their own IT infrastrucutre... This is a windfall for Gov't contractors.
  - golem14 5y ago
    Hey, at least they're 'our kind' of Gov't contractors. No $640 toilet seats here ;)
    - dopamean 5y ago
      "This line of code will be $500 please"
- amluto 5y ago
  Many workflows are proxyable using fine grained IP-level or TCP-level security. (I believe that Tailscale does more or less this.). This can’t support RBAC or per-user dynamic authentication particularly well, but it can at least avoid trusting an entire network.
jollybean 5y ago
They should have given out free identify FOBs with vaccines. I'm only half joking. It's really just a matter of changing gears - you carry a physical key to your house, car, and your online life. You lose the key, you have to go through a bit of pain to get a new one. But establishing that norm is beyond the purview of anyone it seems. Perhaps one of those advanced Nordic countries will have the wherewithal, it seems Estonia is ahead of all of us but we don't pay attention. But this doc looks good.
- PufPufPuf 5y ago
  The .cz domain managing company, CZ.NIC, actually gave away free GoTrust keys to people who promised to use them for e-government services.
fire 5y ago
I wonder if the recommendation for context-aware auth also includes broader adoption of Impossible Travel style checks? For context, Impossible Travel is typically defined as an absolute minimum travel time between two points based on the geographical distance between them, with the points themselves being derived from event-associated IPs via geolocation The idea is that if a pair of events breaches that minimum travel time by some threshold, it's a sign of credential compromise; It's effective for mitigating active session theft, for example, as any out of region access would violate the aforementioned minimum travel time between locations and produce a detectable anomaly
- judge2020 5y ago
  Is this practical? I would imagine with how peering can get better/worse in an instant (and continuously change as different routers pick up new routes) you can't use ping to measure this, and geoip databases don't seem like a source you could trust, especially with CGNAT throwing you onto some generic IP with a geoIP that everyone else in a 200 mile radius also gets.
  - wmf 5y ago
    Most likely GeoIP information is used as one of many inputs to a neural net that decides whether you can log on or not (see tons of "Google locked me out" examples).
  - nybble41 5y ago
    Any kind of tunnel or VPN would also mess with the minimum travel time. This seems like a good way to cause more problems for regular people just trying to log in from slightly unusual network configurations than for any hypothetical man-in-the-middle.
  - fire 5y ago
    From my experience it isn't a be-all-end-all so much as another point of data for anomaly detection. In practice, geoip "regions" like used for this _are_ on the larger scale, yes; However that still lets you ask valuable questions like "why is this user who logs in from Vermont, USA suddenly in Hungary?" and potentially do something proactive like limiting that session's resource access until a new MFA challenge has been passed, or ( more aggressively ) destroy the session or otherwise force a full reauth. The downside is that this almost always relies on some actively maintained geoip database ( ala maxmind ), which... well it isn't exactly cheap, and it isn't exactly perfect, either ( see: maxmind historically putting IPs in a central location when lacking specific data ) Ultimately it's one part of ( what should be ) a suite of checks for anomalous behavior, not something to blindly implement. The latter can cause a great deal of grief if your tolerances are too tight or your proactive actions aren't in line with the activity/abuse they're intended to mitigate. A pretty direct example of proactive action would be restricting access to using saved payment methods on a platform until the user has completed a new 2fa challenge. You could require this challenge every time the user wants to buy something, yes, but as that will probably impact checkout rates, you could get many ( if not most ) of the same fraud prevention benefits by only challenging when the session has moved some threshold distance - It won't stop them from buying something at home or a coffee shop in town, but would stop a session hijacker on an opposing coast or another country from doing so.
Terretta 5y ago
I'm not sure that ... > “discontinue support for protocols that register phone numbers for SMS or voice calls, supply one-time codes, or receive push notifications." ... necessarily means TOTP. Could be argued "supply" means code-over-the-wire, so all 3 being things with a threat of MITM or interception: SMS, calls, "supply" of codes, or push. Taken that way, all three fail the "something I have" check. So arguably one could take "supply one-time codes" to rule out both what HSBC does, but also what Apple does pushing a one-time code displayed together with a map to a different device (but sometimes the same device). I'd argue TOTP is more akin to an open soft hardware token, as after initial delivery it works entirely offline, and passes the "something I have" check.
- kelnos 5y ago
  No, I'd expect it does include TOTP. Read it as "discontinue support for protocols that supply one-time codes". A TOTP app would fall under that description. TOTP apps are certainly better than getting codes via SMS, but they're still susceptible to phishing. The normal attack there is that the attacker (who has already figured out your password) signs into your bank account, gets the MFA prompt, and then sends an SMS to the victim, saying something like "Hello, this is a security check from Your Super Secure Bank. Please respond with the current code from your Authenticator app." Then they get the code and enter it on their side, and are logged into your bank account. Sure, many people will not fall for this, but some people will, and that minority still makes this attack worthwhile. A hardware security token isn't vulnerable to this sort of attack.
  - Godel_unicode 5y ago
    All of this is really government we-don't-pick-winners speak for yubikeys.
    - Terretta 5y ago
      This makes sense. :-)
    - sodality2 5y ago
deleted 5y ago
[deleted]
scarmig 5y ago
This sounds really beautiful, and I am saving the link for future reference. I'm curious about the DNS encryption recommendation. My impression was that DNSSEC was kind of frowned upon as doing nothing that provides real security, at least according to the folks I try to pay attention to. Are these due to differing perspectives in conflict, or am I missing something?
- dsr_ 5y ago
  DNS over TLS and DNS over HTTP/TLS.
  - nybble41 5y ago
    DoT and DoH only encrypt the connection to the recursive resolver, more for privacy than security. You still need DNSSEC to authenticate the results.
- zie 5y ago
  DNSSEC is security in the other direction( DNS server -> client ). All DNSSEC does is securely sign all the responses to DNS queries. so DNSSEC is the answer to, can I trust this IP is valid for the name news.ycombinator.com. DNS over TLS/HTTPS just says, nobody but the DNS server I use can see I'm wanting news.ycombinator.com's IP. It's mostly useless at the moment, since other gaps exist leaking essentially the same information(SNI, etc), but it should get more useful over time, as people are working on fixing those gaps.
  - zaarn 5y ago
    QUIC and ECH cover the leakage of host information already, so DNS over TLS/HTTPS is plenty useful already IMO. Just needs the hosts to upgrade to support ECH or QUIC. Plus it's never bad to cover your bases, DNS queries are for more than just the browser (ie, for example the SRV record which an application may use for connection data or TXT records for configuration or ACME).
- 0xdeadb00f 5y ago
  Whatever happened to Dnscrypt?
mikewarot 5y ago
Does any of this protect against a zero day exploit running in the client device?
- wmf 5y ago
  No, but once the exploit is discovered they could use client posture information to prevent unpatched clients from logging on.
  - EthanHeilman 5y ago
    It reduces your window of exposure. For instance the zero-trust system we are building at bastion-zero uses ephemeral ECDSA key pairs attested by tokens that expire. + When the user logs out these key pairs and tokens are deleted. Ideally tokens should be revoked as well. If an attacker installs an implant on the user's endhost and the user is not logged in the attacker doesn't get any access because there is no keys/tokens to steal. If the implant/attack is discovered prior to the user logging the device can be reset and the attacker doesn't get any access. + If the attacker installs an implant on the user's endhost and the user is logged in. The attacker gets the key pair and tokens. If the attacker attempts to exfil the key pair/tokens and use them from another host this may set off alarms. The attacker if they wish to be stealthy and maintain access must conduct the attack through that endhost (at least include they compromise additional systems). Once the tokens expire the attacker is locked out again. + If the attacker manages to watch the user login and generate the attestation to the key pair and good MFA is employed, e.g. U2F/FIDO. The attacker can not eternally get new key pairs since they can not read the secret from the MFA device. + As wmf suggests, monitoring helps a lot. Monitoring is extra powerful when can easily revoke the user's key pair without revoking the user. Say a user triggers an alarm, automatically revoke the key pair and see if they can reauth. If it is a stolen key pair the attacker might not be able get a new key pair issues if the actually user is offline. If you decide the device might be compromised you can disable access from that device and have user pick up a new laptop.
- agar 5y ago
  In a true Zero Trust model, every client device would have the minimum number of network permissions necessary to do its job - as would every other device. Every device could only connect to known good/known necessary endpoints over specific ports and protocols. All else would be blocked.[1] If the client device were compromised with a zero day exploit, the blast radius would be substantially smaller, the difficulty of an attacker mapping a network for later exploit would be exponentially larger, and time to response would dramatically shrink. [1] (This is particularly relevant for fixed-function IoT and Operational Technology devices. General computing devices need broader controls, but again - the minimum necessary for that user, in that business context, to do their job.)
unethical_ban 5y ago
TOTP is not going anywhere for much of the Internet. Hold on while I get a Yuibikey to my dad who thinks "folders can't be in other folders" because that's not how they work in real life. TOTP is a great security enhancement, and while phishable, considerably raises the bar for an attacker. The fact that TOTP is mentioned as a bad practice in this document is an indicator that this should not be considered a general best practices guide. It is a valid best practice guide for a particular use case and particular user base.
- adgjlsfhk1 5y ago
  the advantage of fido2/webauthn is actually biggest for non techies. tech people are the ones who won't fall for take bad phishing attempts. stopping malicious logins from fake sites is a massive win.
- tptacek 5y ago
  Yubikeys aren't the serious long-term alternative to TOTP; software keys embedded in phones are what we're going to end up with.
  - zie 5y ago
    I want to disagree, but I can't, because you are right. Though perhaps as wearable tech grows(watches and what not), perhaps the keys will exist there also.
  - takumif 5y ago
    I have a newbie question: Can't we embed a hardware key into a phone, and that'd be just as good as a Yubikey? Do we already do this, or is there a reason why we don't?
    - totony 5y ago
      Laptops can have smart cards so there's no reason a phone couldn't
- konklone 5y ago
solatic 5y ago
Meh. OMB also mandated moving to IPv6 more than a decade ago: https://www.cio.gov/assets/resources/internet-protocol-version6-draft.pdf https://www.cio.gov/assets/resources/internet-protocol-versi... Nobody cares. It just gets postponed forever.
- AaronFriel 5y ago
  The memo you're linking to was recently updated and did have force. The DOD, one of the largest federal agencies, issued its own memo with similar deadlines, and this & others have had the result of jumpstarting IPv6 / dual stack support for all of the major clouds & Kubernetes. If FedRAMP qualification is tied to IPv6 support, you'll see every major contractor and cloud provider support it promptly. If you look at the recent updates for cloud providers - AWS and GCP support for IPv6, Kubernetes going dual stack by default - you can see that this memo had a substantial impact. Sometimes these things take time, but in this case, the recent memo you link to lit a fire under everyone.
  - Hikikomori 5y ago
    Yeah AWS has added a lot of ipv6 support recently, like ipv6 only subnets so you can actually benefit from using ipv6. Waiting for rds support though. Azure is so far behind on this it's silly.
    - AaronFriel 5y ago
      What doesn't work with IPv6 on Azure? I understood they were first to support it of the major clouds, though maybe it was just in preview support for a long time. I think in 2019 I was able to use IPv6 VNETs.
imrejonk 5y ago
> Today’s email protocols use the STARTTLS protocol for encryption; it is laughably easy to do a protocol downgrade attack that turns off the encryption. This can be solved with DANE, which is based on DNSSEC. When properly configured, the sending mailserver will force the use of STARTTLS with a trusted certificate. The STARTTLS+DANE combination has been a mandatory standard for governmental organizations in the Netherlands since 2016.
- philosopher1234 5y ago
  Is DANE @tptacek approved of? You say DNSSEC and it triggers my internal alarm bells.
  - tptacek 5y ago
    No, DANE is very bad. But it's a dead-letter standard, so I don't worry about much.
    - AndyMcConachie 5y ago
      You think no one is deploying DANE for SMTP? https://stats.dnssec-tools.org/images/domains.svg https://stats.dnssec-tools.org/images/domains.svg It's deployed on many more domains than MTA-STS.
      - tptacek 5y ago
        Of course it is. There are only a couple of email providers that actually matter, but out in the long tail of domains that might never receive a single non-spam email, there are plenty that are auto-signed by registrars. It's telling that's the best evidence you have, and not, like, "Google Mail uses DANE".
    - teddyh 5y ago
MrYellowP 5y ago
Inching closer to the complete digital lockdown, I see.
ineedasername 5y ago
>It tells us to stop rotating passwords Finally! Maybe the places I've worked will finally listen. But I stopped reading TFA to praise this, so back to TFA.
- 0xffff2 5y ago
  NIST has made this recommendation for years. Sadly, I work for another branch of the Federal government and despite the NIST guidance I still have to rotate my password every 60 days. (Actually, the starts sending me daily emails warning me 15 days out, and the date is based on last change, so practically it's more like 45 days.)
  - ineedasername 5y ago
    I know, it's been a while since rotation was considered a best practice. Yet the security team where I work will pick a random shiny new security practice and impose it on users. (I don't mind the imposition of good security, the hassle is worth it). Just one example where I work is a prohibition against emailing certain types of documents or data to others in the company (which is mostly Word & Excel docs) Which seems reasonable, but the accepted solution is to use the built in encryption of MS Office to secure the file with a password and then email the file. And then send the password in another email. Honestly, that's supposed to be the protocol. The policy also hasn't been amended in any way to account for implementing Google docs & sheets, which can be accessed with the same credentials used for email or opened on any unattended employee's machine if they left a Gmail tab open (along with anything else in their Google drive). And regardless of any of these rules, almost no one follows them. I do-- I have to, I'm a data custodian so I can't violate the rules, but it annoys people.
    - LilBytes 5y ago
      This is why security teams get a bad wrap :(
rikeanimer 5y ago
if only we had an operating system with flexible granularity permissions models baked in. wouldn't it be nice?
cryptica 5y ago
I thought we had reached peak bureaucracy but I was wrong. On the plus side, it's good that they finally figured out that forcing frequent password changes and forcing the usage of special characters are anti-patterns. I've been repeating this for over a decade. Deprecating passwords is the wrong conclusion. A better solution would be to educate people about good password creation and handling practices. A 1-page document and/or short video would do.
- AdamH12113 5y ago
  Organizations have been educating people about good password creation and handling practices for over a quarter century. It hasn't worked and there is no sign that it will ever work. (Perhaps I misunderstood and you were being sarcastic?)
  - cryptica 5y ago
    They haven't even come up with such practices, let alone taught them to anyone. The practices which they did come up with have been terrible, even harmful (e.g. changing passwords often and using special symbols). Of course if you teach the wrong thing, you will get the wrong results.
pledess 5y ago
Our corporate IT folks have a Zero Trust Manifesto in which there are enrolled devices (laptops that remote SREs can carry around), there are enterprise applications, and there's connectivity between these (e.g., tunnel pairs). SREs often need to write scripts that operate on sensitive production data from the enterprise applications, but must do this work directly on an enrolled device. Pre-Zero-Trust days seemed safer. Copying production data to a laptop wasn't allowed. Instead, each SRE had their own Linux VM in the data center, accessible from home and able to run the scripts (with connectivity to the enterprise application). This prevented a whole class of realistic attacks in which a laptop (while unlocked/decrypted) is taken by an adversary. Admittedly, in return, we're protected from a possible, but less likely, attack in which a Linux VM is compromised and used for lateral movement within one segment of the enterprise network. (An enrolled device has to be in the user's possession; it can't be any machine, Linux or Windows, in the data center or office.) The only people who love this are our enterprise application vendors. Our bosses are paying them a TON more money to implement new requirements where, in theory, all possible types of data analysis can be done directly within the enterprise application. No more scripts, no more copying of data. No more use of Open Source. And, of course, people from these same enterprise application vendors advise the government that Zero Trust must be a top priority mandate.
- YokoZar 5y ago
  Why not combine the two and require using the secure VMs only from enrolled devices?
  - pledess 5y ago
    There isn't a great reason. It's just that the people who set the policy wanted to prevent lateral attacker movement at all costs. The VMs and the enterprise applications are in the same building, but no longer have network connectivity because they don't routinely communicate (in the past, a VM would make an outbound TCP connection only after an SRE decided that a problem existed).
CosmicShadow 5y ago
I wish the country would be listed in the title, even though we all know who this is going to be about.
tardismechanic 5y ago
Hmm so BeyondCorp for gov - BeyondGov? Or am I totally off
eyelidlessness 5y ago
Tangential remark to author if they’re reading: favoring “she” isn’t more inclusive for an unknown pronoun. You probably already use a non-gendered singular “they” in normal speech and you could use that where the gender/preference isn’t known. Just a suggestion from an NB who passes as male and thinks binary gender substitution doesn’t help, even though I appreciate the effort.
McTossOut 5y ago
chiefalchemist 5y ago
- matt_kantor 5y ago
  Looks like you commented on the wrong post.
  - chiefalchemist 5y ago
    Oops. You're right. Weird.
upofadown 5y ago
>Meanwhile encryption with PGP has been a complete failure, due to problems with key distribution and user experience. Encrypted messaging has been a complete failure; there is no need to single out email. I suspect the reason is more or less the same in all cases. Users have not been provided with a conceptual framework that would allow them to use the tools in a reasonable way. If the US federal government can come up with, and promote such a framework the world would become a different place. BTW, the linked article is mostly based on misconceptions: * https://articles.59.ca/doku.php?id=pgpfan:tpp https://articles.59.ca/doku.php?id=pgpfan:tpp
- lolinder 5y ago
  > Encrypted messaging has been a complete failure; there is no need to single out email. Can you elaborate on why you see it this way? WhatsApp has been wildly successful, my very non-technical in-laws use Signal for their family's conversations, and other messaging platforms are jumping on the bandwagon. As far as I can tell, if we lose encrypted messaging at this point, it will be due to government action or corporate rug-pulling, not because it failed to catch on. Whereas encrypted email really hasn't caught on anywhere.
  - upofadown 5y ago
    >WhatsApp has been wildly successful, my very non-technical in-laws use Signal for their family's conversations, and other messaging platforms are jumping on the bandwagon. You only get effective end to end encryption if you can verify that you are talking to who you think you are talking to. Otherwise the people that are running the system can cause your messages to take an unencrypted detour and thus be able to read them. This is often called a man in the middle attack. Verifying identities normally means checking some sort of long identity number. Very few people know how to do that in an effective way. For example: in a usability study involving Signal[1], 21 out of 28 computer science students failed to establish and maintain a secure end to end encrypted connection. The usability of end to end encrypted messaging is a serious issue. We should not kid ourselves into thinking it is a solved issue. PGP in a sense is actually better here in that it forces the user to comprehend the existence of a key in a way where it is intuitively obvious that it is important to know where that key came from. [1] https://www.ndss-symposium.org/wp-content/uploads/2018/03/09-when-signal-hits-the-fan-on-the-usability-and-security-of-state-of-the-art-secure-mobile-messaging.pdf https://www.ndss-symposium.org/wp-content/uploads/2018/03/09...
totony 5y ago
How do you do MFA without a password? I thought it was "what you know" "what you have" "what you are" etc?
- kevlened 5y ago
  You only need two of the three factors to make it multifactor. A computer with a fingerprint scanner could be enough if it’s implemented properly. It’s something you have (a specific computer with a specific fingerprint scanner) with something you are (the fingerprint). In practice, you also need to know an identifier like an email or username, but those are often considered public.

656 points by EthanHeilman 5y ago

This is pretty incredible. These aren't just good practices, they're the fairly bleeding edge best practices. 1. No more SMS and TOTP. FIDO2 tokens only. 2. No more unencrypted network traffic - including DNS, which is such a recent development and they're mandating it. Incredible. 3. Context aware authorization. So not just "can this user access this?" but attestation about device state! That's extremely cutting edge - almost no one does that today. My hope is that this makes things more accessible. We do all of this today at my company, except where we can't - for example, a lot of our vendors don't offer FIDO2 2FA or webauthn, so we're stuck with TOTP.

suns 5y ago
Yea, imagine the implications of federal agencies all implementing this successfully. Can't wait to see what the trickle down(?) effect is.
- dev-3892 5y ago
  "downstream" might be the word you're looking for
- chasd00 5y ago
  lots of billable hours for the various consulting firms. "we'er so happy we can hardly count" - Pink Floyd
EthanHeilman 5y ago
We've been building to these goals at bastionzero so I've been living it everyday, but I feels validating and also really strange to see the federal government actually get it.
meepmorp 5y ago
Also, “Password policies must not require use of special characters or regular rotation.” They even call out the fact that it's a proven bad practice that leads to weaker passwords - and such policies must be gone from government systems in 1 year from publication of the memo. It's delightful.
- CGamesPlay 5y ago
  I am a bit concerned that this will be read as "Password policies must require the use of no special characters", possibly as a misguided attempt to push people away from adding using "Password123!" as the password. I wish the memo had spelled out a little more clearly that there's nothing wrong with special characters, but they shouldn't be required. Also, is a whitespace a special character?
  - pm90 5y ago
    If we were to stop using special characters and only use human friendly phrases (eg “jupiterIsTheSmallestPlanet”) it wouldn’t be the end of the world.
    - godelski 5y ago
      But if a whitespace is not a special character (or punctuation) we can add entropy with "Jupiter is the smallest planet!" while still being human readable and using the passphrase paradigm.
- atuladhar 5y ago
  Somewhat unrelated, but hopefully this also means TreasuryDirect will get rid of its archaic graphical keyboard that disables the usage of password managers. (Graphical keyboards are an old technique to try to defeat key loggers. A frequent side effect of a site using a graphical keyboard is that the developer has to make the password input field un-editable directly, which prevents password managers from working, unless you use a user script to make the field editable again.)
  - 5y ago
pitaj 5y ago
What's wrong with TOTP?
- Sesse__ 5y ago
  It authenticates the user to the service, but not the service to the user, so it's vulnerable to phishing (or MITM, of course, if you don't have TLS).
- jaycroft 5y ago
  I was wondering the same thing - here's an article I found that describes both approaches. Not being in the cryptography space myself I can't comment on how accurate it is, but passes my engineering smell test. https://blog.trezor.io/why-you-should-never-use-google-authenticator-again-e166d09d4324 https://blog.trezor.io/why-you-should-never-use-google-authe... Edit - sorry that this is really an ad for the writer's products. On the other hand, there's a hell of a bounty for proving them insecure / untrustworthy, whatever your feelings on "the other crypto".
  - deleted 5y ago
    [deleted]
  - tptacek 5y ago
    Yeah these are very dumb arguments against TOTP.
  - deleted 5y ago
    [deleted]
- tptacek 5y ago
  It's very phishable. Attackers will send text messages to your users saying "Hi, this is Steve with the FooCorp Security Team; we're sorry for the inconvenience, but we're verifying everyone's authentication. Can you please reply with the code on your phone?" It's even worse with texted codes because it's inherently credible in the moment because the message knows something you feel it shouldn't --- that you just got a 2FA code. You have to deeply understand how authentication systems work to catch why the message is suspicious. You can't fix the problem with user education, because interacting with your application is almost always less than 1% of the mental energy your users spend doing their job, and they're simply not going to pay attention.
c0l0 5y ago
I think 3. is very harmful for actual, real-world use of Free Software. If only specific builds of software that are on a vendor-sanctioned allowlist, governed by the signature of a "trusted" party to grant them entry to said list, can meaningfully access networked services, all those who compile their own artifacts (even from completely identical source code) will be excluded from accessing that remote side/service. Banks and media corporations are doing it today by requiring a vendor-sanctioned Android build/firmware image, attested and allowlisted by Google's SafetyNet (https://developers.google.com/android/reference/com/google/android/gms/safetynet/SafetyNet https://developers.google.com/android/reference/com/google/a...), and it will only get worse from here. Remote attestation really is killing practical software freedom.
- seibelj 5y ago
  Reproducible builds are a thing, I don't know how widespread they are. I know the monero project has that built in so everyone compiles the exact same executable regardless of environment, and can verify the hash against the official version https://github.com/monero-project/monero https://github.com/monero-project/monero
  - nybble41 5y ago
    Reproducible builds allow the user of the software to verify the version that they are using or installing. They do not, by themselves, allow the sort of remote attestation which would permit a service to verify the context for authentication—the user, or a malicious actor, could simply modify the device to lie about the software being run. Secure attestation about device state requires something akin to Secure Boot (with a TPM), and in the context of a BYOD environment precludes the device owner having full control of their own hardware. Obviously this is not an issue if the organization only permits access to its services from devices it owns, but no organization should have that level of control over devices owned by employees, vendors, customers, or anyone else who requires access to the organization's services.
    - InitialLastName 5y ago
dc-programmer 5y ago
For anyone interested in 3, Google’s BeyondCorp whitepapers are an excellent starting point
vmception 5y ago
Force banks to do this, immediately. They can levy it on any organization with a banking license or wants access to FEDWire or the ACH system. Force it for SWIFT access too, if the bank has an online banking system for users.
- criddell 5y ago
  I asked my bank about their 16 character limit on password length because it suggests they are saving the password rather than some kind of hash. Their response - don't worry about it, you aren't responsible for fraud. Banks aren't going to want to implement any changes that cost more (in system changes and customer support) than the fraud they prevent.
nextos 5y ago
> 1. No more SMS and TOTP. FIDO2 tokens only. SMS are bad due to MITM and SIM cloning. In EU many banks still use smsTAN, and it leads to lots of security breaches. It's frustrating some don't offer any alternatives. However, is FIDO2 better than chipTAN or similar? I like simple airgapped 2FAs, but I'm not an expert.
- tptacek 5y ago
  The major advantage of FIDO2 is that it's difficult to phish. SIM cloning is not the primary reason organizations are now advocating against SMS 2FA.
  - tialaramex 5y ago
    In particular [Thomas knows this, for anybody else reading], WebAuthn (the way you use FIDO for the web, U2F is a legacy system for doing the same thing that you should not use in greenfield deployments) recruits your web browser to defeat phishing. When you use WebAuthn to sign into an site the browser takes responsibility for determining which site you're on, cutting out the whole phishing problem of "Humans don't know which site it is". The browser isn't reading that GIF that says "Real Bank Secure Login" at the top of the page or the title "Real Bank - Authenticate" or the part of the URL bar that says "/cgi-bin/login/secure/realbank/" it is looking only at the hostname it just verified for TLS which says fakebank.example So the browser tells your FIDO authenticator OK, we're signing in to fakebank.example - and that's never going to successfully steal your Real Bank credentials because the correct name is cryptographically necessary for the credentials to work. This is so effective crooks aren't likely to even bother attacking it.
codemac 5y ago
Google does 1, 2, and 3 internally. If you join https://landing.google.com/advancedprotection/ https://landing.google.com/advancedprotection/ you can get something similar for personal public accounts.
- withinboredom 5y ago
  I prefer to keep my email as dumbly secured as possible. I’ll never forget this one time I was on my sailboat with no cell service and only an open WiFi connection from shore. I couldn’t login to anything via sms auth. Same thing with FIDO keys when traveling. Lost luggage? No logging in for you until you get home to get your backup? Cut your finger while cooking? No logging in for you! Have to wear a face mask? No logging in for you! To be clear, I don’t have a better solution. But all the second factor stuff is fundamentally broke when you are likely to need access to the service most.
  - tialaramex 5y ago
    So, I'm somebody who thinks about contingencies a lot and to my mind, there's just not a lot of gap between situations where you don't need credentials (e.g. satellite beacons don't care who you are) and where you don't have credentials (oh no, I lost all the gear) so it doesn't represent a big worry for me. I don't want the consular officials to be unable to authenticate me in a foreign country because I lost my phone, or for my bank to be unable to release funds because I don't have their card or my Security Key, but I feel 100% OK with losing access to Gmail or Hacker News, or whatever for say a few days until I can secure replacement credentials.
  - philjohn 5y ago
    The SMS point is part of why moving to FIDO keys is a good idea - the NFC enabled ones work with modern smartphones and allow you to login. As for lost luggage, I carry mine on my keychain, another one in the laptop itself (USB-C Yubikey) and one in my safe at home - if all three are ever destroyed or lost I also have backup codes available as password protected notes on several devices.
- staticassertion 5y ago
mnd999 5y ago
Bleeding edge or complete fantasy? This is going to be very very expensive and guess who’s going to be paying for it?
- tssva 5y ago
  As with most OMB memos it is complete fantasy and agencies won't comply by the date, any date close to it or really ever. The answer to the question "who's going to be paying for it?" is nobody which is why it will never actually get done.
  - mnd999 5y ago
    Government contractors are expert at getting paid to deliver nothing.
melony 5y ago
Isn't 3 responsible for all those HN horror stories about being locked out of their Google accounts while traveling?
warner25 5y ago
"...fairly bleeding edge best practices..." By the time we implement any of these things, if ever, they certainly won't be. I work on military networks and applications, and it's hard for me to believe that I'll see any of this within my career at the pace we move. This is the land of web applications that only work with Internet Explorer, ActiveX, Siverlight, Flash, and Java Applets, plus servers running Linux 2.6 or Windows Server 2012. The idea of "Just-in-Time" access control where "a user is granted access to a resource only while she needs it, and that access is revoked when she is done" is terrifying when it takes weeks or months to get action on support tickets that I submit (where the action is simple, and I tee it up with a detailed description of whatever I need done).
- staticassertion 5y ago
  Maybe, but my hope is that this pushes external vendors that have government contracts to support these workflows.
- post_from_work 5y ago
  It took us NINE MONTHS to get a server installed in a data center a few years back. This was Marine-Corps fielded hardware running an ATO'd[1] software stack for real-world situational awareness, going into a Marine Corps data center. The people that run the data center have a glacial Change Management process, exacerbated by everyone in their organization not talking to each other, even though they are separated by cubical walls. I too have no faith of seeing this stuff implemented anytime soon... [1] (Authority to Operate, basically approval from the highest IT authorities to utilize something on a DoD network)
  - warner25 5y ago
    Haha, yes, my day-to-day work for the past two years has been fighting exactly this same fight on the Army side.
Alex3917 5y ago
Given that every cybersecurity czar seems to publicly resign a few months after being appointed, what are the chances of these actually being implemented?
raxxorrax 5y ago
These are strong requirements, but I fear the government just wants more transparency of citizens. Remote-attestation of trusted platforms could lead to the worst surveillance attempts we have ever seen. And it would require you to trust your government. That is a bad idea from a security point of view. edit: The source of my claim that governments tend to extend surveillance is pretty well documented I believe. So much so that I believe it is worthy to insert the problem into debates about anything relating to security. Because security often serves as the raison d'être for such ambitions.
- cabbagehead 5y ago
cabbagehead 5y ago

uncomputation 5y ago

> “Enterprise applications should be able to be used over the public internet.” Isn’t exposing your internal domains and systems outside VPN-gated access a risk? My understanding is this means internaltool.faang.com should now be publicly accessible.

3np 5y ago
There are different ways to look at it. From a defense-in-depth perspective, you are right. That is, however, one of the main points of a zero-trust environment (or you could say Zero Trust), which is a kind-of-new trend that much has been written about. Think about it this way: In the context of ransomware attacks, a lot of times it's game over once an internal agent is compromised. The premise of zero trust is that once an attacker is "inside the wall", they gain basically nothing. Compromising one service or host would mean having no venue for escalation from there. I wouldn't say it's objectively better (maybe by the time I retire I can make a call on that), but it's a valid strategy. Certainly better than relying on perimeter-based security like VPN alone, as opposed to it being just one layer of DiD, though.
enriquto 5y ago
As I understand it, this sentence says that the application should be safe even if it was exposed to the public internet, not that it needs to be exposed. It is a good practice to securize everything even if visible only internally. The "perimeter defense" given by a VPN can be a plus, but never the only line of defense.
- jaywalk 5y ago
  No, the memo pretty clearly says that VPNs need to go away.
  - deleted 5y ago
    [deleted]
  - MattPalmer1086 5y ago
    It says that VPNs and other network tunnels should not be relied on. Where does it say they should go away?

adreamingsoul 5y ago

Here in Norway we have BankID which uses MFA. To access any government, banking, or official system you have to authenticate with your BankID. Its simple amazing.

brimble 5y ago
There's significant bi-partisan resistance, in the US, to anything like a national ID, unfortunately, with the result that we have one anyway (because of course we do, the modern world doesn't work without it) it's just an ad-hoc combination of other forms of ID, terrible to work with, heavily reliant on commercial 3rd parties, unreliable, and laughably insecure. But the end result is still a whole bunch of public and private databases that personally identify us and contain tons of information—kind of by necessity, actually, since our ID is a combination of tons of things. It's a very frustrating situation. Worst of both worlds.
- seniorThrowaway 5y ago
  I've done some thinking about this, and a possible solution is a bunch of cross signed CA's like the Federal common policy / FPKI for cross trust amongst federal agencies, but done at a state DMV / DPS level. Driver's licenses / state IDs could have certs embedded into the cards and then be used for things like accessing government websites, banks, etc. Yes there are some access concerns, and some privacy concerns that this is in essence a national ID, but what we have now is horribly broken, and we're already being tracked. We get all the downside of pervasive tracking, but none of the upside.
  - currency 5y ago
    Would that look anything like the REAL ID system?[0] [0]https://www.tsa.gov/real-id https://www.tsa.gov/real-id
thomascgalvin 5y ago
I'm America, about 30% of the population would start screaming about the Mark of the Beast if we tried to roll out something like this.

tims33 5y ago

Really pleasantly surprised at how progressive this memo is. It will be interesting to see the timelines put in place to make the transition. Btw - I'd love to see the people who put this memo together re-evaluate the ID.me system they're implementing for citizens given how poor the identity verification is.

YeBanKo 5y ago
I have an issue with using ID.me for government websites, because it is a privately owned company. Online authentication at this point seems as important as USPS service and warrants being owned and developed by the government itself.
- dmd 5y ago
  They even HAVE this already, at https://login.gov/ https://login.gov/ !
  - tialaramex 5y ago
    I have a login.gov account. Needless to say I'm not a US citizen, and the IRS should not cut me a refund check. ID.me supports WebAuthn (or maybe U2F? In this context it doesn't matter) but importantly it does identity verification so it can determine whether I am a US citizen, whether I'm a tax payer, and if so which one. Now, perhaps the US Federal Government should own the capability to do that instead of a private company. But, so far as I can tell, they do not and login.gov is not such a thing.
    - parkerhiggins 5y ago
      A private company shouldn’t own this capability. Especially as ID.me CEO lied about maintaining a database of every face “1-to-many” that uses their verification system. They’re right up there with Clearview AI. https://www.theverge.com/2022/1/26/22903437/id-me-facial-recognition-databases-irs-match https://www.theverge.com/2022/1/26/22903437/id-me-facial-rec...
    - 5y ago

KarlKemp 5y ago

I’m somewhat unhappy the “zero trust” terminology ha caught on. The technology is fine, but trust is an essential concept in many parts of life[0], and positioning it as something to be avoided or abolished will just further erode the relationships that define a peaceful and civil society. 0: trade only works if the sum of your trust in the legal system, intermediates, and counterparts reaches some threshold. The same is true of any interaction where the payoff is not immediate and assured, from taxes to marriage and friendship, and, no, it is not possible to eliminate it, nor would that be a society you’d want to live in. The only systems that do not rely on some trust that the other person isn’t going to kill them are maximum-security prisons and the US president’s security bubble. Both are asymmetric and still require trust in some people, just not all.

kstrauser 5y ago
The "trust" here largely refers to identity. Do you trust that everyone in your house is your relative, by virtue of the fact that they're in your house? That falls down when you have a burglar. Similarly, is it good to trust that everyone on your corporate network is an employee, and therefore should have employee-level access to all the resources on that network? I wouldn't recommend it.
- KarlKemp 5y ago
  No, but I trust the people I regularly interact with and therefore allow them to be in my home. Nobody trusts people just because they happen to be in their home. To the extend that trust can go to “zero”, my fear is it will harm the (existing) first form of trust, which is vital, and have little impact on the stupid latter definition of trust. I know tech operates on different definitions/circumstances here. That’s why the word ”zero” is so wrong here, because it seems to go out of its way to make the claim that less trust ks always better. Call it “zero misplaced trust” or “my database doesn’t want your lolly”, whatever.
  - agar 5y ago
    I see this as the exact point of the Zero Trust terminology. People extend your exact trust assertions to their networks, and bad actors exploit it to effect a compromise. A corporate network cannot be like your home. Zero Trust says that you should assume anything, and anyone, can be exploited - so secure appropriately. Per your analogy, what would you do if your invited houseguests, unbeknownst even to themselves, wore a camera for reconnaissance by a 3rd party? What would you do if these cameras were so easy to hide that anyone, at any time, might be wearing one and you couldn't know? You would have to assume that anyone that entered your home had a camera on them. You would give them no more access than the bare minimum needed to do whatever they were there to do (whether eat dinner or fix your sink). You'd identify them, track their movement, and keep records. Your term, "Zero misplaced trust," assumes that you can identify where to place trust. Did you trust that system you had validated and scanned for 5 years...until Log4shell was discovered? Did you trust the 20-year veteran researcher before they plugged in a USB without knowing their kid borrowed it and infected it? Zero Trust is a response to the failure of "trust but verify."

paganel 5y ago

> Do not give long-lived credentials to your users. This screams "we'll use more post-it notes for our passwords compared to before", or maybe the real world to which this memo is addressed is different compared to the real (work-related) world I know.

the_jeremy 5y ago
It specifically calls out not requiring regular password rotation. Short-lived credentials is for tokens with expiration, not the password you use to login to the service that gives you the token.
- paganel 5y ago
  Got it, thanks.
tptacek 5y ago
The general attitude among practitioners now is that "post-it notes with passwords on them" is superior to the more common practice of "shitty passwords shared across multiple services".
- cpach 5y ago
  Back in 2009 or so I stored my most-frequently used psswords on a piece of paper in my wallet. (These days I simply use 1Password.)
Godel_unicode 5y ago
This was a very unfortunate choice of words by the author, as they don't mean credentials as in the credential a user uses to initially authenticate to the system. Rather they mean authentication tokens, be they Kerberos tickets, bearer tokens, etc. This memo in particular emphasizes the existing guidance the US government has issued around not expiring passwords. If you are a federal agency, you can have (and are in fact encouraged to have!) users with passwords that are unchanged for years. Edit: it's worth pointing out that the memo does a great job of laying this out. I work in security, so possibly there's some curse of knowledge at play, but I found the blog post explainer to be less clear than the memo it is explaining...

ctime 5y ago

The real crux of the issue is the long-tail of applications which were never conceived with anything but network-based trust. I'm certain the DoD is absolutely packed with these, probably for nearly every workflow. The reason this was so "easy" for Google (and some other companies, like GitLab[1]) to realize most of these goals is that they are a web-based technology company - fundamentally the tooling and scalable systems needed to get started were web so the transition were "free". Meaning, most of the internal apps were HTTP apps, built on internal systems, and the initial investment was just to make an existing proxied internal service, external and behind a context aware proxy [1]. The hard part for most other companies (and the DoD) is figuring out what to do with protocols and workflows that aren't http or otherwise proxyable. [1] https://cloud.google.com/iap/docs/cloud-iap-context-aware-access-howto https://cloud.google.com/iap/docs/cloud-iap-context-aware-ac... [2] https://about.gitlab.com/blog/2019/10/02/zero-trust-at-gitlab-implementation-challenges/ https://about.gitlab.com/blog/2019/10/02/zero-trust-at-gitla...

wordsarelies 5y ago
As if Gov't does their own IT infrastrucutre... This is a windfall for Gov't contractors.
- golem14 5y ago
  Hey, at least they're 'our kind' of Gov't contractors. No $640 toilet seats here ;)
  - dopamean 5y ago
    "This line of code will be $500 please"
amluto 5y ago
Many workflows are proxyable using fine grained IP-level or TCP-level security. (I believe that Tailscale does more or less this.). This can’t support RBAC or per-user dynamic authentication particularly well, but it can at least avoid trusting an entire network.

jollybean 5y ago

They should have given out free identify FOBs with vaccines. I'm only half joking. It's really just a matter of changing gears - you carry a physical key to your house, car, and your online life. You lose the key, you have to go through a bit of pain to get a new one. But establishing that norm is beyond the purview of anyone it seems. Perhaps one of those advanced Nordic countries will have the wherewithal, it seems Estonia is ahead of all of us but we don't pay attention. But this doc looks good.

PufPufPuf 5y ago
The .cz domain managing company, CZ.NIC, actually gave away free GoTrust keys to people who promised to use them for e-government services.

fire 5y ago

I wonder if the recommendation for context-aware auth also includes broader adoption of Impossible Travel style checks? For context, Impossible Travel is typically defined as an absolute minimum travel time between two points based on the geographical distance between them, with the points themselves being derived from event-associated IPs via geolocation The idea is that if a pair of events breaches that minimum travel time by some threshold, it's a sign of credential compromise; It's effective for mitigating active session theft, for example, as any out of region access would violate the aforementioned minimum travel time between locations and produce a detectable anomaly

judge2020 5y ago
Is this practical? I would imagine with how peering can get better/worse in an instant (and continuously change as different routers pick up new routes) you can't use ping to measure this, and geoip databases don't seem like a source you could trust, especially with CGNAT throwing you onto some generic IP with a geoIP that everyone else in a 200 mile radius also gets.
- wmf 5y ago
  Most likely GeoIP information is used as one of many inputs to a neural net that decides whether you can log on or not (see tons of "Google locked me out" examples).
- nybble41 5y ago
  Any kind of tunnel or VPN would also mess with the minimum travel time. This seems like a good way to cause more problems for regular people just trying to log in from slightly unusual network configurations than for any hypothetical man-in-the-middle.
- fire 5y ago
  From my experience it isn't a be-all-end-all so much as another point of data for anomaly detection. In practice, geoip "regions" like used for this _are_ on the larger scale, yes; However that still lets you ask valuable questions like "why is this user who logs in from Vermont, USA suddenly in Hungary?" and potentially do something proactive like limiting that session's resource access until a new MFA challenge has been passed, or ( more aggressively ) destroy the session or otherwise force a full reauth. The downside is that this almost always relies on some actively maintained geoip database ( ala maxmind ), which... well it isn't exactly cheap, and it isn't exactly perfect, either ( see: maxmind historically putting IPs in a central location when lacking specific data ) Ultimately it's one part of ( what should be ) a suite of checks for anomalous behavior, not something to blindly implement. The latter can cause a great deal of grief if your tolerances are too tight or your proactive actions aren't in line with the activity/abuse they're intended to mitigate. A pretty direct example of proactive action would be restricting access to using saved payment methods on a platform until the user has completed a new 2fa challenge. You could require this challenge every time the user wants to buy something, yes, but as that will probably impact checkout rates, you could get many ( if not most ) of the same fraud prevention benefits by only challenging when the session has moved some threshold distance - It won't stop them from buying something at home or a coffee shop in town, but would stop a session hijacker on an opposing coast or another country from doing so.

Terretta 5y ago

I'm not sure that ... > “discontinue support for protocols that register phone numbers for SMS or voice calls, supply one-time codes, or receive push notifications." ... necessarily means TOTP. Could be argued "supply" means code-over-the-wire, so all 3 being things with a threat of MITM or interception: SMS, calls, "supply" of codes, or push. Taken that way, all three fail the "something I have" check. So arguably one could take "supply one-time codes" to rule out both what HSBC does, but also what Apple does pushing a one-time code displayed together with a map to a different device (but sometimes the same device). I'd argue TOTP is more akin to an open soft hardware token, as after initial delivery it works entirely offline, and passes the "something I have" check.

kelnos 5y ago
No, I'd expect it does include TOTP. Read it as "discontinue support for protocols that supply one-time codes". A TOTP app would fall under that description. TOTP apps are certainly better than getting codes via SMS, but they're still susceptible to phishing. The normal attack there is that the attacker (who has already figured out your password) signs into your bank account, gets the MFA prompt, and then sends an SMS to the victim, saying something like "Hello, this is a security check from Your Super Secure Bank. Please respond with the current code from your Authenticator app." Then they get the code and enter it on their side, and are logged into your bank account. Sure, many people will not fall for this, but some people will, and that minority still makes this attack worthwhile. A hardware security token isn't vulnerable to this sort of attack.
- Godel_unicode 5y ago
  All of this is really government we-don't-pick-winners speak for yubikeys.
  - Terretta 5y ago
    This makes sense. :-)
  - sodality2 5y ago

deleted 5y ago

[deleted]

scarmig 5y ago

This sounds really beautiful, and I am saving the link for future reference. I'm curious about the DNS encryption recommendation. My impression was that DNSSEC was kind of frowned upon as doing nothing that provides real security, at least according to the folks I try to pay attention to. Are these due to differing perspectives in conflict, or am I missing something?

dsr_ 5y ago
DNS over TLS and DNS over HTTP/TLS.
- nybble41 5y ago
  DoT and DoH only encrypt the connection to the recursive resolver, more for privacy than security. You still need DNSSEC to authenticate the results.
zie 5y ago
DNSSEC is security in the other direction( DNS server -> client ). All DNSSEC does is securely sign all the responses to DNS queries. so DNSSEC is the answer to, can I trust this IP is valid for the name news.ycombinator.com. DNS over TLS/HTTPS just says, nobody but the DNS server I use can see I'm wanting news.ycombinator.com's IP. It's mostly useless at the moment, since other gaps exist leaking essentially the same information(SNI, etc), but it should get more useful over time, as people are working on fixing those gaps.
- zaarn 5y ago
  QUIC and ECH cover the leakage of host information already, so DNS over TLS/HTTPS is plenty useful already IMO. Just needs the hosts to upgrade to support ECH or QUIC. Plus it's never bad to cover your bases, DNS queries are for more than just the browser (ie, for example the SRV record which an application may use for connection data or TXT records for configuration or ACME).
0xdeadb00f 5y ago
Whatever happened to Dnscrypt?

mikewarot 5y ago

Does any of this protect against a zero day exploit running in the client device?

wmf 5y ago
No, but once the exploit is discovered they could use client posture information to prevent unpatched clients from logging on.
- EthanHeilman 5y ago
  It reduces your window of exposure. For instance the zero-trust system we are building at bastion-zero uses ephemeral ECDSA key pairs attested by tokens that expire. + When the user logs out these key pairs and tokens are deleted. Ideally tokens should be revoked as well. If an attacker installs an implant on the user's endhost and the user is not logged in the attacker doesn't get any access because there is no keys/tokens to steal. If the implant/attack is discovered prior to the user logging the device can be reset and the attacker doesn't get any access. + If the attacker installs an implant on the user's endhost and the user is logged in. The attacker gets the key pair and tokens. If the attacker attempts to exfil the key pair/tokens and use them from another host this may set off alarms. The attacker if they wish to be stealthy and maintain access must conduct the attack through that endhost (at least include they compromise additional systems). Once the tokens expire the attacker is locked out again. + If the attacker manages to watch the user login and generate the attestation to the key pair and good MFA is employed, e.g. U2F/FIDO. The attacker can not eternally get new key pairs since they can not read the secret from the MFA device. + As wmf suggests, monitoring helps a lot. Monitoring is extra powerful when can easily revoke the user's key pair without revoking the user. Say a user triggers an alarm, automatically revoke the key pair and see if they can reauth. If it is a stolen key pair the attacker might not be able get a new key pair issues if the actually user is offline. If you decide the device might be compromised you can disable access from that device and have user pick up a new laptop.
agar 5y ago
In a true Zero Trust model, every client device would have the minimum number of network permissions necessary to do its job - as would every other device. Every device could only connect to known good/known necessary endpoints over specific ports and protocols. All else would be blocked.[1] If the client device were compromised with a zero day exploit, the blast radius would be substantially smaller, the difficulty of an attacker mapping a network for later exploit would be exponentially larger, and time to response would dramatically shrink. [1] (This is particularly relevant for fixed-function IoT and Operational Technology devices. General computing devices need broader controls, but again - the minimum necessary for that user, in that business context, to do their job.)

unethical_ban 5y ago

TOTP is not going anywhere for much of the Internet. Hold on while I get a Yuibikey to my dad who thinks "folders can't be in other folders" because that's not how they work in real life. TOTP is a great security enhancement, and while phishable, considerably raises the bar for an attacker. The fact that TOTP is mentioned as a bad practice in this document is an indicator that this should not be considered a general best practices guide. It is a valid best practice guide for a particular use case and particular user base.

adgjlsfhk1 5y ago
the advantage of fido2/webauthn is actually biggest for non techies. tech people are the ones who won't fall for take bad phishing attempts. stopping malicious logins from fake sites is a massive win.
tptacek 5y ago
Yubikeys aren't the serious long-term alternative to TOTP; software keys embedded in phones are what we're going to end up with.
- zie 5y ago
  I want to disagree, but I can't, because you are right. Though perhaps as wearable tech grows(watches and what not), perhaps the keys will exist there also.
- takumif 5y ago
  I have a newbie question: Can't we embed a hardware key into a phone, and that'd be just as good as a Yubikey? Do we already do this, or is there a reason why we don't?
  - totony 5y ago
    Laptops can have smart cards so there's no reason a phone couldn't
konklone 5y ago

solatic 5y ago

Meh. OMB also mandated moving to IPv6 more than a decade ago: https://www.cio.gov/assets/resources/internet-protocol-version6-draft.pdf https://www.cio.gov/assets/resources/internet-protocol-versi... Nobody cares. It just gets postponed forever.

AaronFriel 5y ago
The memo you're linking to was recently updated and did have force. The DOD, one of the largest federal agencies, issued its own memo with similar deadlines, and this & others have had the result of jumpstarting IPv6 / dual stack support for all of the major clouds & Kubernetes. If FedRAMP qualification is tied to IPv6 support, you'll see every major contractor and cloud provider support it promptly. If you look at the recent updates for cloud providers - AWS and GCP support for IPv6, Kubernetes going dual stack by default - you can see that this memo had a substantial impact. Sometimes these things take time, but in this case, the recent memo you link to lit a fire under everyone.
- Hikikomori 5y ago
  Yeah AWS has added a lot of ipv6 support recently, like ipv6 only subnets so you can actually benefit from using ipv6. Waiting for rds support though. Azure is so far behind on this it's silly.
  - AaronFriel 5y ago
    What doesn't work with IPv6 on Azure? I understood they were first to support it of the major clouds, though maybe it was just in preview support for a long time. I think in 2019 I was able to use IPv6 VNETs.

imrejonk 5y ago

> Today’s email protocols use the STARTTLS protocol for encryption; it is laughably easy to do a protocol downgrade attack that turns off the encryption. This can be solved with DANE, which is based on DNSSEC. When properly configured, the sending mailserver will force the use of STARTTLS with a trusted certificate. The STARTTLS+DANE combination has been a mandatory standard for governmental organizations in the Netherlands since 2016.

philosopher1234 5y ago
Is DANE @tptacek approved of? You say DNSSEC and it triggers my internal alarm bells.
- tptacek 5y ago
  No, DANE is very bad. But it's a dead-letter standard, so I don't worry about much.
  - AndyMcConachie 5y ago
    You think no one is deploying DANE for SMTP? https://stats.dnssec-tools.org/images/domains.svg https://stats.dnssec-tools.org/images/domains.svg It's deployed on many more domains than MTA-STS.
    - tptacek 5y ago
      Of course it is. There are only a couple of email providers that actually matter, but out in the long tail of domains that might never receive a single non-spam email, there are plenty that are auto-signed by registrars. It's telling that's the best evidence you have, and not, like, "Google Mail uses DANE".
  - teddyh 5y ago

MrYellowP 5y ago

Inching closer to the complete digital lockdown, I see.

ineedasername 5y ago

>It tells us to stop rotating passwords Finally! Maybe the places I've worked will finally listen. But I stopped reading TFA to praise this, so back to TFA.

0xffff2 5y ago
NIST has made this recommendation for years. Sadly, I work for another branch of the Federal government and despite the NIST guidance I still have to rotate my password every 60 days. (Actually, the starts sending me daily emails warning me 15 days out, and the date is based on last change, so practically it's more like 45 days.)
- ineedasername 5y ago
  I know, it's been a while since rotation was considered a best practice. Yet the security team where I work will pick a random shiny new security practice and impose it on users. (I don't mind the imposition of good security, the hassle is worth it). Just one example where I work is a prohibition against emailing certain types of documents or data to others in the company (which is mostly Word & Excel docs) Which seems reasonable, but the accepted solution is to use the built in encryption of MS Office to secure the file with a password and then email the file. And then send the password in another email. Honestly, that's supposed to be the protocol. The policy also hasn't been amended in any way to account for implementing Google docs & sheets, which can be accessed with the same credentials used for email or opened on any unattended employee's machine if they left a Gmail tab open (along with anything else in their Google drive). And regardless of any of these rules, almost no one follows them. I do-- I have to, I'm a data custodian so I can't violate the rules, but it annoys people.
  - LilBytes 5y ago
    This is why security teams get a bad wrap :(

rikeanimer 5y ago

if only we had an operating system with flexible granularity permissions models baked in. wouldn't it be nice?

cryptica 5y ago

I thought we had reached peak bureaucracy but I was wrong. On the plus side, it's good that they finally figured out that forcing frequent password changes and forcing the usage of special characters are anti-patterns. I've been repeating this for over a decade. Deprecating passwords is the wrong conclusion. A better solution would be to educate people about good password creation and handling practices. A 1-page document and/or short video would do.

AdamH12113 5y ago
Organizations have been educating people about good password creation and handling practices for over a quarter century. It hasn't worked and there is no sign that it will ever work. (Perhaps I misunderstood and you were being sarcastic?)
- cryptica 5y ago
  They haven't even come up with such practices, let alone taught them to anyone. The practices which they did come up with have been terrible, even harmful (e.g. changing passwords often and using special symbols). Of course if you teach the wrong thing, you will get the wrong results.

pledess 5y ago

Our corporate IT folks have a Zero Trust Manifesto in which there are enrolled devices (laptops that remote SREs can carry around), there are enterprise applications, and there's connectivity between these (e.g., tunnel pairs). SREs often need to write scripts that operate on sensitive production data from the enterprise applications, but must do this work directly on an enrolled device. Pre-Zero-Trust days seemed safer. Copying production data to a laptop wasn't allowed. Instead, each SRE had their own Linux VM in the data center, accessible from home and able to run the scripts (with connectivity to the enterprise application). This prevented a whole class of realistic attacks in which a laptop (while unlocked/decrypted) is taken by an adversary. Admittedly, in return, we're protected from a possible, but less likely, attack in which a Linux VM is compromised and used for lateral movement within one segment of the enterprise network. (An enrolled device has to be in the user's possession; it can't be any machine, Linux or Windows, in the data center or office.) The only people who love this are our enterprise application vendors. Our bosses are paying them a TON more money to implement new requirements where, in theory, all possible types of data analysis can be done directly within the enterprise application. No more scripts, no more copying of data. No more use of Open Source. And, of course, people from these same enterprise application vendors advise the government that Zero Trust must be a top priority mandate.

YokoZar 5y ago
Why not combine the two and require using the secure VMs only from enrolled devices?
- pledess 5y ago
  There isn't a great reason. It's just that the people who set the policy wanted to prevent lateral attacker movement at all costs. The VMs and the enterprise applications are in the same building, but no longer have network connectivity because they don't routinely communicate (in the past, a VM would make an outbound TCP connection only after an SRE decided that a problem existed).

CosmicShadow 5y ago

I wish the country would be listed in the title, even though we all know who this is going to be about.

tardismechanic 5y ago

Hmm so BeyondCorp for gov - BeyondGov? Or am I totally off

eyelidlessness 5y ago

Tangential remark to author if they’re reading: favoring “she” isn’t more inclusive for an unknown pronoun. You probably already use a non-gendered singular “they” in normal speech and you could use that where the gender/preference isn’t known. Just a suggestion from an NB who passes as male and thinks binary gender substitution doesn’t help, even though I appreciate the effort.

McTossOut 5y ago

chiefalchemist 5y ago

matt_kantor 5y ago
Looks like you commented on the wrong post.
- chiefalchemist 5y ago
  Oops. You're right. Weird.

upofadown 5y ago

>Meanwhile encryption with PGP has been a complete failure, due to problems with key distribution and user experience. Encrypted messaging has been a complete failure; there is no need to single out email. I suspect the reason is more or less the same in all cases. Users have not been provided with a conceptual framework that would allow them to use the tools in a reasonable way. If the US federal government can come up with, and promote such a framework the world would become a different place. BTW, the linked article is mostly based on misconceptions: * https://articles.59.ca/doku.php?id=pgpfan:tpp https://articles.59.ca/doku.php?id=pgpfan:tpp

lolinder 5y ago
> Encrypted messaging has been a complete failure; there is no need to single out email. Can you elaborate on why you see it this way? WhatsApp has been wildly successful, my very non-technical in-laws use Signal for their family's conversations, and other messaging platforms are jumping on the bandwagon. As far as I can tell, if we lose encrypted messaging at this point, it will be due to government action or corporate rug-pulling, not because it failed to catch on. Whereas encrypted email really hasn't caught on anywhere.
- upofadown 5y ago
  >WhatsApp has been wildly successful, my very non-technical in-laws use Signal for their family's conversations, and other messaging platforms are jumping on the bandwagon. You only get effective end to end encryption if you can verify that you are talking to who you think you are talking to. Otherwise the people that are running the system can cause your messages to take an unencrypted detour and thus be able to read them. This is often called a man in the middle attack. Verifying identities normally means checking some sort of long identity number. Very few people know how to do that in an effective way. For example: in a usability study involving Signal[1], 21 out of 28 computer science students failed to establish and maintain a secure end to end encrypted connection. The usability of end to end encrypted messaging is a serious issue. We should not kid ourselves into thinking it is a solved issue. PGP in a sense is actually better here in that it forces the user to comprehend the existence of a key in a way where it is intuitively obvious that it is important to know where that key came from. [1] https://www.ndss-symposium.org/wp-content/uploads/2018/03/09-when-signal-hits-the-fan-on-the-usability-and-security-of-state-of-the-art-secure-mobile-messaging.pdf https://www.ndss-symposium.org/wp-content/uploads/2018/03/09...

totony 5y ago

How do you do MFA without a password? I thought it was "what you know" "what you have" "what you are" etc?

kevlened 5y ago
You only need two of the three factors to make it multifactor. A computer with a fingerprint scanner could be enough if it’s implemented properly. It’s something you have (a specific computer with a specific fingerprint scanner) with something you are (the fingerprint). In practice, you also need to know an identifier like an email or username, but those are often considered public.