Implementing a Zero Trust Architecture
nccoe.nist.gov
nccoe.nist.gov
* 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.
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.
* requires intermediate 'gateways' which can bridge both sides to enable bidirectional data flow, initiated from either side
You should be providing access to an identity, not software. If someone is running the same software but with the wrong identity, it should be denied access.
One non-malicious example that comes to mind is the right application from the wrong environment, e.g. dev frontend calling prod backend, or even worse prod backend calling test DB, etc.
You can also call it 'perimeter-less security'.
As for zero trust - that seems to be a bit of a misnomer to me - doesn't it tend to aggregate trust into one big bucket - certs?
Won't anybody who can do man-in-the-middle or has access to root certs have total free reign?
Security services wet dream.
They are designed to connect you to an application, you should never see the network.
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 (strong auth - not IP-address based auth).
* requires intermediate 'gateways' which can bridge both sides to enable bidirectional data flow, initiated from either side
If you implement security at the network layer, what’s to stop app developers from kicking the can down the road rather than implement app security?
"Authenticate everyone, authorize everything"
The majority of the world is still in this context...
I remember working for a major tech company that had contracts for big critical industries (think oil, aviation, trains, etc.). All the R&D department pretty much rested on one Brent, because they made no efforts to upgrade their systems for 15 years+.
tl;dr: I asked him: hey maybe we shouldn't trust devs computers just because they are "on the network", he just shrugged and said: "if we're compromised we'll have other things to worry about anyway".
While zero trust as a goal is impossible, it still is the guiding principle that everyone should follow; especially if you have a Brent.
https://securitycryptographywhatever.buzzsprout.com/1822302/...
People have commented on the naming but I don't know if it's clear that it's not just a nitpick. It's breeding a situation where devices we moved away from years ago are becoming a topic people are suddenly asking us about for largely no reason.
A company that employs both IT Security experts and Actuaries would be in a perfect position to balance up-front investments in security against risk of payments in case of incidents, and would have this as their primary business purpose, instead of seeing security as a cost center with no revenue.
This is a benefit of having actual security be core business for such a company. While for many companies, security is a small part of their business, and not critical for their long term performance, a dedicated insurance/security company would HAVE to be good at both to stay competitive.
Now, if society feels that too many ransoms are being paid (due to externalities, such as loss of confidential information, service quality, etc) , this might also make it easier to implement additional countermeasures. In particular, I think it would make sense to demand a fine or tax any time a company pays such a ransom.
Lets say, if the government would demand a tax equal to the size of each ransom paid, the insurance/security company would either have an increased incentive to protect against ransomware, or alternatively, the attackers would understand that the break-even size of the ransom, where it would be preferable for the target to not pay, would be not much higher than half as high.
I have worked on and partnered with some of the largest public sector digital identity schemes in the world, and almost none of the players who actually have traction in those organizations are represented. Microsoft has their B2B service, which is the inferior product you choose when you don't have expertise, and even though I think Okta is an excellent product and Duo (via Cisco) are fantastic, most of the parties represented aren't what developers, architects, and the people who actually build and use these techs would select. I realize these are IAA/IAM products, but ZTA has a bootstrapping problem without a foundation in identity. (Though I was glad to see Oracle wasn't on the list, even though they are the identity elephant in the room.)
I like Zero Trust as a concept, but it's going to take more organic growth and integration with IAM and with the traction of companies like those missing vendors to make it viable. The players on the list right now are all enterprise vendors, but it's startups who are the ones growing and adopting standards - and using those missing organic-demand vendors whose customers actually want their tech instead of having it imposed. The growth companies hold the real influence on standards implementation because they are the adopters. Enterprise customers aren't going to change anytime soon, and having enterprise (slow linear to flat growth) vendors as your partner channel seems risky. I agree ZTA will be a thing, but without exposure to non-linear growth, they may just be inventing another SAML.
The reasoning goes that in govt, you have licenses and birth certificates, SINs and ID cards, and depending on the legal regime, there are limitations for the legal uses of each of those. Banks could theoretically offer ID because they have more information about you, but then they take on risk and liability in its usages. Second, each transaction that requires identity only needs a certain level of assurance, and what these orgs have agreed to is they will contribute their user identity attributes to a blockchain to support an identifying consensus without holding any risk or having any responsibility for the usage, while providing a high degree of institutional assurance that their contribution is verified and supported by KYC, pattern of life, anti-fraud etc. In this case, identity is an epiphenomenal artifact of the consensus.
Where I might agree is that I don't think strong identity itself is valuable, it in fact destroys value, and the consensus just implements the impunity and social anti-pattern of a one-way committee decision - and I think it's an imposition that doesn't help anyone except make them more exposed to remote enforcement of fines and petty policies. e.g. Yay, now you can get parking tickets in foreign countries, and all the use cases are variations of that.
However, if you want recourse and sanctions of individuals that are portable without integrating with central national identity schemes, a blockchain is the way to do that. That's the most succinct version I think there is. The irony may be that civil liberties may be the strongest argument against blockchains because they are the cryptological implementation of a committee or star chamber when their consensus represents a monopoly or "radical monopoly."
An interesting study on identity is the (book/play/film) Les Misérables. At various points in the story, the protagonist is a prisoner (#24601), a Frenchman (Jean Valjean), a factory owner (Monsieur Madeleine), and a community leader (Monsieur le Maire). The main antagonist in the story, Javert, is so strongly biased in his rigid system of classifying people, that he is unable to accept Valjean's identity as anything other than a criminal - prisoner 24601. The internal dissonance this creates when Valjean continues to defy this categorization eventually results in Javert's demise.
At the beginning of the story, the protagonist's identity _is_ prisoner 24601. At the end of the story, it is not. Identity changes with time, context and circumstances, and how that identity is asserted will also vary from group to group.
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.
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.
If a company asked me to use MDM software and set themselves up as a device owner on a phone I purchased and used every day my answer is: hell no
If they want that, they can buy me a phone, and pay for the mobile/data plan. I've worked places that have done this, having 2 phones is a pain, but you only use the corp one at work or if you're oncall.
Nowadays, Android can have a Work profile that your company can control (and wipe, for example) that doesn't affect your personal stuff. It's actually convenient because you have a separate instance of Chrome, which is a good workaround for mobile Chrome not supporting multiple profiles inside the app like the desktop version does.
For Chrome, it will perform a very intrusive popup whenever you log into an extra Google account to get you to use a different profile. If you say yes, that new profile will be governed by the administrators without them gaining access to the entire Chrome browser.
For Android, there are 'Work Profiles'[0], however I haven't tried this and I wouldn't be surprised if it breaks fundamental parts of Android and/or it's disabled on certain OEM Android makers.
For iOS, User Enrollment[1] is a thing.
The main problems I see with these solutions is that they add a lot of complexity to MDM configurations, so chances are the organization will either go without MDM, or ask you to set up your device under full MDM. Under the second scenario I would suggest purchasing an extra phone just for work - this also helps with the possibility of an internal investigation, or even subpoena, asking for access to any phone with work data on it, as chances are they won't limit searches and data exports to data stored in your work profile.
0: https://support.google.com/work/android/answer/6191949
1: https://support.apple.com/guide/deployment/user-enrollment-a...
a while ago when prepping for my APs, I came across the paper "Reflections on Trusting 'Trustlessness' in the Era of Crypto/Blockchains" (Georgiadis,E.) available here: https://www.cs.umd.edu/~gasarch/BLOGPAPERS/cbit-4-2.pdf and found some parts very illuminating.
It makes reference to a paper by Kuhn called Backdoor Engineering and advances that point to a concept the author calls conceptual corruption. Under this light, zero trust architectures are impossible.
My fellow classmate a CS nerd made an additional point about the paper reflections on trust. it was beyond me.