[HN Gopher] Implementing a Zero Trust Architecture
___________________________________________________________________
Implementing a Zero Trust Architecture
Author : justinludwig
Score : 90 points
Date : 2022-08-09 19:13 UTC (3 hours ago)
(HTM) web link (www.nccoe.nist.gov)
(TXT) w3m dump (www.nccoe.nist.gov)
| tjstebbing wrote:
| [deleted]
| er4hn wrote:
| I can understand not trusting NIST's approach to crypto
| standards, given their history with the NSA. However what in
| this set of documents do you find untrustworthy?
| pvg wrote:
| _Avoid unrelated controversies, generic tangents, and internet
| tropes._
|
| https://news.ycombinator.com/newsguidelines.html
| denton-scratch wrote:
| Well, parent has actually expressed my reaction. The article
| seems to be a puff site, with no details about what they mean
| by "Zero Trust". I didn't follow any of the links (I don't
| think I should have to).
|
| If NIST has something to tell me, then they need to tell it
| me straight, not cloaked in partner sites and snazzy
| graphics.
| tptacek wrote:
| You're a Google search away from the entire industry
| explaining to you what they think "Zero Trust" is --- the
| term predates the OMB memo.
|
| Your best first read is the Google BeyondCorp paper.
| pvg wrote:
| You can write a comment about things you don't like in the
| thing posted but not a reflexive trope response that can
| appear unchanged in anything with 'NIST' in it, which is
| what the guideline is about.
| tomrod wrote:
| https://csrc.nist.gov/publications/detail/sp/800-207/final
|
| https://csrc.nist.gov/publications/detail/white-
| paper/2022/0...
|
| https://csrc.nist.gov/publications/detail/sp/1800-35/draft
| [deleted]
| tptacek wrote:
| Shameless plug: we had Eric Mill on to talk about what OMB was
| going for with this.
|
| https://securitycryptographywhatever.buzzsprout.com/1822302/...
| er4hn wrote:
| This was a really great episode. I'm glad you took the time to
| get someone from the gov to talk about this on the podcast.
| gz5 wrote:
| I have previously read most of these docs, and NIST has done some
| excellent work in what can be tough territory, even if 'zero
| trust' is now* a misleading term (the question is more like
| who/what do you trust under which circumstances and how do you
| implement that in a simple, scalable, extensible way...so I
| prefer something closer to 'authorize everything').
|
| * The term was more applicable when originally coined - the
| context back then was don't trust an endpoint just because it is
| on your network.
| philjohn wrote:
| Although "authorize everything" can also be confusing - so,
| what, you just let anything query your system?
| jeffbee wrote:
| That seems appropriate in many contexts. The originator of
| the "beyond corp" meme has all their critical systems just
| hanging out there on port 443. You could just download all
| their source code, if you were authorized. The point is if
| you want the extra layer of security, the belt of physical or
| VPN access to go along with the "authorize everything"
| suspenders, you can just put it on top. But you _don 't_
| assume that the network security actually works, you don't
| allow its existence to degrade the rest of your security
| story.
| gz5 wrote:
| Agree, not a perfect term. You certainly make a good point
| and in fact the strongest zero trust approaches don't even
| let you on the network (even at layer 3) until after you are
| authorized.
| happyopossum wrote:
| Err, no - the strongest zero trust approaches _never_ let
| you "on the network" - authorized or not.
|
| They are designed to connect you to an application, you
| should never see the network.
| alexott wrote:
| I met customers who put anything under that umbrella. And they
| want to use PaaS/SaaS products - like, you need to encrypt
| table names, or some unrelated data... Some companies just use
| that to protect their ...
| eikenberry wrote:
| I'm not sure I see the difference between zero trust networking
| and authorize everything. Seems like they are saying pretty
| much the same thing, differing in positive vs negative
| assertions.
| tenebrisalietum wrote:
| Zero trust means "don't authn/authz based on IP address,
| authn/authz at the application level where you should have
| been doing that in the first place."
| gz5 wrote:
| If you are to provide access to an app or network, you need
| to trust (something) under some circumstances.
| nightpool wrote:
| > provide access to a network
|
| That's your first mistake. You should be providing access
| to _software_ , not networks. The idea of a "trusted"
| network that applications or users can communicate on is
| the fundamental idea that zero-trust architecture aims to
| get rid of.
| gz5 wrote:
| absolutely. can even completely 'eliminate' the network
| by closing all inbound firewall ports (not even allowing
| dynamic hole punching), and then opening ephemeral,
| session-specific L3 outbound connects (from both sides*
| of the session) only for authorized sessions.
|
| * requires intermediate 'gateways' which can bridge both
| sides to enable bidirectional data flow, initiated from
| either side
| mberning wrote:
| The idea that many vendors have is an agent on the client and
| server that scrutinizes every connection, at both ends, based
| on policy and/or entitlement to specific resources. For an
| enterprise this means not having to worry as much about
| locking down your internal network as it is no longer the
| only boundary. In reality this is a very tall order. All your
| internal systems, legacy systems, cloud vendors, etc. have to
| be on board. The reality is a hybrid solution with all the
| attendant complexity.
| historynops wrote:
| The problem with "implementing a zero trust architecture" is that
| it's framing an ongoing process as an end state. You'll see the
| same disappointment that people saw when they decided "we're
| going to _do_ DevOps ".
|
| I thought that "Shift Left" was going to be the new DevOps
| buzzword for security groups, but I liked that because it implied
| an ongoing process, not a "we're going to become perfect and fix
| this once and for all".
|
| Google's BeyondCorp - the precursor to zero trust architecture -
| said you need to secure three things: users, devices, and
| application policies. Your security teams are probably already
| aware of many of good tools available to secure the users and
| apps, but the device security piece has very weak tooling even
| today. You may have heard of MDM software. No one wants to use
| it.
| 0xbadcafebee wrote:
| I just like that there will _eventually_ be a big shiny
| C-level-friendly website that I can show my bosses, that they
| can show their bosses, so we might actually get funding to
| _start_ working on Zero Trust. Nobody cared about BeyondCorp
| but they might care about NIST.
| tptacek wrote:
| People get into all sorts of trouble trying to reason
| axiomatically about "Zero Trust". It's definitely a problem
| with the term, and a strength of "BeyondCorp"; BeyondCorp can
| only mean the one set of things, because it's meaningless
| outside of Google's branding. But everyone feels like they can
| work out what "Zero Trust" should mean. So the first thing you
| have to do is, you have to rewire your brain to read "Zero
| Trust" as the marketing term of art that it is.
|
| The OMB ZT stuff is a reaction to USG breaches, and I think in
| particular the OMB hack. There's a "before" state and a desired
| "after" state.
|
| In the "before" state, you're one of the 2.1 million federal
| employees, and you start your day by inserting a PIV card into
| a reader, and with that, you're given access to an intranet
| that in turn gives you access to a bananas number of different
| things that nobody can keep track of or secure.
|
| In the "after" state, each service is responsible for
| establishing its own tight trust boundaries, and instead of
| providing a network dial tone that people mistakenly assume is
| a proxy for trust, the USG infrastructure provides you with
| end-to-end authentication for requests regardless of the
| network you're using.
|
| As far as OMB and NIST talking about ZT goes, the major problem
| you're trying to solve is that there are a zillion federal
| agencies --- way more than you think there are, like you know
| that there's a Department of the Interior, but also under
| Interior there's a Susquehannah River Basin Commission with 100
| employees, and there are other agencies that have like 4-5
| employees. And what you're trying to do is provide a security
| strategy and a toolbox and a set of best/worst practices that
| you can apply across all of these organizations, to replace
| what I understand to be the _status quo ante_ strategy of
| "stick it on the VPN, pretend we've kept it off the Internet,
| and call it a day".
|
| The other important subtext to all of this is that there's a
| huge give and take between USG and industry, where USG tends to
| take its lead from what's happening in industry, but it also
| participates in the industry in that it is one of the largest
| customers for technology products, so the industry is intensely
| interested in what it does. So when USG decides to demand "Zero
| Trust" for its agencies, and sets out a standard set of
| requirements for ZT, industry goes nuts making sure their
| products are responsive to that standard.
|
| The good thing here is that the OMB memo is smart, and ZT as
| construed by the current administration's IT people is a pretty
| good baseline security strategy, so in this one instance the
| USG is being a force for good, in that it's aligning a lot of
| industry work around a strategy that people should be seriously
| considering adopting anyways. And I think there's pretty broad
| recognition/agreement about that in the "security community"
| (hate that term), so when USG (here: NIST) does some big new
| thing about ZT, it gets a lot of positive attention.
|
| ... is how I understand all of this.
| [deleted]
___________________________________________________________________
(page generated 2022-08-09 23:00 UTC)