Zero Trust Strategy and Roadmap(defense.gov)
defense.gov
Zero Trust Strategy and Roadmap
https://www.defense.gov/News/Releases/Release/Article/3225919/department-of-defense-releases-zero-trust-strategy-and-roadmap/
112 comments
> How well do these techniques work in practice, particularly in a huge organisation?
At $dayjob I have access to the Azure Active Directory "unusual user activity" security alerts in an environment with about 15K staff.
In my experience, the reports are accurate, in the sense that they get triggered as advertised by mis-use of IT resources. However, 95% of the time it's just staff being "naughty" instead of actual hackers.
For example, the "impossible travel" one gets triggered regularly. About 80% of the time it's because someone forgot to turn off the VPN they use to watch foreign Netflix. The other 20% of the time is because they were sharing credentials, which is against every IT security policy ever.
Even just the use of a VPN by itself is red flag. VPN providers are notoriously untrustworthy, many of them teetering on the edge of being outright malware. Certainly they all collect far too much metadata and sell it to the highest bidder. No such VPN product has any legitimate use on a corporate device.
Not to mention that corporate traffic is now looping out of the country into another country and back for no good reason...
At $dayjob I have access to the Azure Active Directory "unusual user activity" security alerts in an environment with about 15K staff.
In my experience, the reports are accurate, in the sense that they get triggered as advertised by mis-use of IT resources. However, 95% of the time it's just staff being "naughty" instead of actual hackers.
For example, the "impossible travel" one gets triggered regularly. About 80% of the time it's because someone forgot to turn off the VPN they use to watch foreign Netflix. The other 20% of the time is because they were sharing credentials, which is against every IT security policy ever.
Even just the use of a VPN by itself is red flag. VPN providers are notoriously untrustworthy, many of them teetering on the edge of being outright malware. Certainly they all collect far too much metadata and sell it to the highest bidder. No such VPN product has any legitimate use on a corporate device.
Not to mention that corporate traffic is now looping out of the country into another country and back for no good reason...
[deleted]
>they were sharing credentials, which is against every IT security policy ever
You’d like to think so, but...
You’d like to think so, but...
My experience is that no matter how much training one has taken into that regard, any IT slowness to provide credentials on time for critical project activities, will eventually end up on that behaviour.
This might sound silly (as I have no experience in the field), but if this problem is due to the "largeness" of an organization (say "large" being N = 300, for the sake of argument), then presumably it's because certain false positives become more frequent as they have more employees than N, which causes the security monitors to tune out similar behavior, correct?
So instead of hiring the same constant number of security monitors/auditors independently of the organization size, can't you "solve" this problem by hiring one per every N employees, and having them monitor solely that group?
It sounds to me like either this solution should work (a "large" organization should be able to afford this!), or the problem isn't really related to the size of the organization.
So instead of hiring the same constant number of security monitors/auditors independently of the organization size, can't you "solve" this problem by hiring one per every N employees, and having them monitor solely that group?
It sounds to me like either this solution should work (a "large" organization should be able to afford this!), or the problem isn't really related to the size of the organization.
Org size can cause some amount of fatigue, sure. But reliable security engineers are few and far between. Not necessary scale-able to org size.
Additionally, security is one of those things it's hard to get C-suite execs to pay attention to and spend money on. When it's working, you don't notice it. And if your 5 person security team has worked fine for the past 5 years as the org has grown, why should you suddenly scale it up to 10? Everything is fine! That is...until it isn't. But rarely do people think ahead like this.
Additionally, security is one of those things it's hard to get C-suite execs to pay attention to and spend money on. When it's working, you don't notice it. And if your 5 person security team has worked fine for the past 5 years as the org has grown, why should you suddenly scale it up to 10? Everything is fine! That is...until it isn't. But rarely do people think ahead like this.
My thoughts on complexity are more in relation to large organisations having more areas of business, each with their own set of software in use. For a multinational company which frequently acquires other businesses, perhaps they end up with 10 of everything--10 HR systems, 10 finance systems, etc. And then on top of that a number of other systems for generating reports from the 10 finance systems, polling and searching data from the 10 logistics systems, etc. The DOD would be a nightmare of complexity and most likely the global leader in complexity.
Defense Logistics Agency in 2018 reported 264 applications in use, which was down from 1200 in 2013[1]. DLA only represent about 0.9% of the total DOD workforce[2] and it appears the application reduction could be due to consolidation of applications together, making application counts appear better but not doing much to reduce true complexity.
Given many systems have a single subject matter expert (or sometimes none), what is a cyber security analyst responsible for 100's of applications going to be able to reason about an event raised from a system with a name as vague as "DLA Action Item Tickler Report"? Was Bob OK to send the XY12 report via e-mail to Oscar? Who knows? It's likely no one has asked that type of question before and the only person who knows enough about the system to answer the question is the person who caused the event to be generated.
Some organisations are quite simple (despite having similar finances and employee counts) because they largely consist of simple repeatable processes performed by 1000's of employees using a single software product. Some organisations (particularly the DOD) are very complex because every employee is doing something unique across 100's of different software products.
[1] https://www.dla.mil/About-DLA/News/News-Article-View/Article...
[2] https://en.wikipedia.org/wiki/United_States_Department_of_De...
Defense Logistics Agency in 2018 reported 264 applications in use, which was down from 1200 in 2013[1]. DLA only represent about 0.9% of the total DOD workforce[2] and it appears the application reduction could be due to consolidation of applications together, making application counts appear better but not doing much to reduce true complexity.
Given many systems have a single subject matter expert (or sometimes none), what is a cyber security analyst responsible for 100's of applications going to be able to reason about an event raised from a system with a name as vague as "DLA Action Item Tickler Report"? Was Bob OK to send the XY12 report via e-mail to Oscar? Who knows? It's likely no one has asked that type of question before and the only person who knows enough about the system to answer the question is the person who caused the event to be generated.
Some organisations are quite simple (despite having similar finances and employee counts) because they largely consist of simple repeatable processes performed by 1000's of employees using a single software product. Some organisations (particularly the DOD) are very complex because every employee is doing something unique across 100's of different software products.
[1] https://www.dla.mil/About-DLA/News/News-Article-View/Article...
[2] https://en.wikipedia.org/wiki/United_States_Department_of_De...
One aspect that changes with the scale is the distance (both in org-chart and physically) between the monitor and the monitored - in larger organizations the monitor has less useful context (and less ability to get it) to evaluate the circumstances of some alert.
Ideally in a system like this, you don't just look at a single user and a single point (e.g. 100x data transfer in a day), you build out scoring based on a multitude of factors and across related agents/assets, and hopefully you have enough training data to account for irregular or seasonal occurrences.
For one part of the org, occasionally doing 100x data transfers may not be out of the ordinary, while for others it may be exceptional. But it might be anomalous if its 100x data transfer and hitting services no one on your team has ever hit (indicating perhaps scanning/scraping and exfiltrating data, but you don't need to explicitly specify that as an alert).
For one part of the org, occasionally doing 100x data transfers may not be out of the ordinary, while for others it may be exceptional. But it might be anomalous if its 100x data transfer and hitting services no one on your team has ever hit (indicating perhaps scanning/scraping and exfiltrating data, but you don't need to explicitly specify that as an alert).
Let's remember the level of classification here though - in a usual org an occasional large data transfer might not be worth investigating, but in some contexts within the DoD it's certainly worth investigating.
And although size of transfer may be a valid indicator, not all valuable data is large in size.
I work as an Information Security Officer in a corporation with about 100.000 employees. The outlined reasons in this post are what makes these capabilities effective in our org as well.
A big problem is insiders selling information or ransoming it under the guise of a breach. Employees are the single greatest threat to any organization so behavior analytics is starting to become really big.
As I tell people, "We don't care if you browse Reddit, we only care if you start doing things an employee shouldn't".
But to answer your questions we would just ingest those alerts into Splunk, build a KB on how to handle the alerts when they trigger and then begin the process of filtering out the noise. The SOC Analyst who works these alerts will get numb to them but still pick out the unusual ones to investigate.
As I tell people, "We don't care if you browse Reddit, we only care if you start doing things an employee shouldn't".
But to answer your questions we would just ingest those alerts into Splunk, build a KB on how to handle the alerts when they trigger and then begin the process of filtering out the noise. The SOC Analyst who works these alerts will get numb to them but still pick out the unusual ones to investigate.
I'm curious are there any open source "behavior analytics" projects that are gaining traction?
No, you need too much data and it’s too specific to the environment.
> just ingest those alerts into Splunk
Aah yes, Splunk....
Good tool, but realistically only viable for those working for a corporate-sized employer with corporate-sized pockets filled with $$$$$$$.
Most people can't afford to simply dump it all into Splunk and (if they are using Splunk at all) have to pre-filter first. Which kind of defeats the point of Splunk if they're already doing the hard work outside, and so might was well use some cheaper (F)OSS tool.
Aah yes, Splunk....
Good tool, but realistically only viable for those working for a corporate-sized employer with corporate-sized pockets filled with $$$$$$$.
Most people can't afford to simply dump it all into Splunk and (if they are using Splunk at all) have to pre-filter first. Which kind of defeats the point of Splunk if they're already doing the hard work outside, and so might was well use some cheaper (F)OSS tool.
Working on a startup to basically be 75% of the features of Splunk at 50% the cost: https://log-store.com/
Right now it's 100% free, because I'm just looking for user feedback. I think/hope there is an opening in the market for folks looking for an easy-to-use, but powerful tool like Splunk, but can't afford their hefty price tag. All feedback welcomed!
Also created an open-source ETL tool: https://log-ship.com
Right now it's 100% free, because I'm just looking for user feedback. I think/hope there is an opening in the market for folks looking for an easy-to-use, but powerful tool like Splunk, but can't afford their hefty price tag. All feedback welcomed!
Also created an open-source ETL tool: https://log-ship.com
That sounds interesting, I'll certainly give it a go when I get a chance in the near-future !
you can do the same type of work with spark, which is free
That is something right there. I am intrigued by this.
> How well do these techniques work in practice, particularly in a huge organisation?
Like this:
I log into system foo-bar-baz, which one person accesses once or twice a year. Maybe it's christmas setup, maybe it's for daylight savings time, maybe it's for a new release of Ubuntu, whatever. I have all the relevant credentials, I am responsible for foo-bar-baz, and I have an authorised change request.
Three days later, the security team sends me a slack message, asking if I accessed system foo-bar-baz.
I tell them yes.
Like this:
I log into system foo-bar-baz, which one person accesses once or twice a year. Maybe it's christmas setup, maybe it's for daylight savings time, maybe it's for a new release of Ubuntu, whatever. I have all the relevant credentials, I am responsible for foo-bar-baz, and I have an authorised change request.
Three days later, the security team sends me a slack message, asking if I accessed system foo-bar-baz.
I tell them yes.
Because they want to know if someone stole your creds.
“The Department’s most consequential strategic competitor and the pacing challenge for the Department, the People’s Republic of China,3 as well as other state-sponsored adversaries and individual malicious actors often breach the Department’s defensive perimeter and roam freely within our information systems.”
This statement from the actual PDF really is telling for how far the DoD has dropped the ball on protection- maybe spend less time fleshing out offensive capabilities and more time on defense of your citizens?
This statement from the actual PDF really is telling for how far the DoD has dropped the ball on protection- maybe spend less time fleshing out offensive capabilities and more time on defense of your citizens?
I was reading it and going "Are...are you allowed to publicly admit this?"
It's a wild time, I'm telling you
It's a wild time, I'm telling you
[deleted]
As an insider, I’ll say it’s a selective reading of the facts on the verge of hyperbole.
That is absolutely not the case.
It is absolutely the case.
I worked network defense for Network Warfare Command.
There is literally nobody on earth more qualified than me than me to make the statement I did.
There is literally nobody on earth more qualified than me than me to make the statement I did.
You’re aware that the DoD is more than just the navy, yes? Also, the defender’s having missed a bunch of intrusions is literally exactly what this report is saying. Sorry to be the one to tell you.
[deleted]
[deleted]
If this is true, why now?
Budget.
I could see that being the case, drumming up the situation so they get more funding to fix the problem. At least I hope that is the case, over the alternative.
What’s the downside? It’s not like they have a customer base whose trust they need to keep.
>maybe spend less time fleshing out offensive capabilities and more time on defense of your citizens
With our budget the two are not mutually exclusive
With our budget the two are not mutually exclusive
And they’re often the same. Take cyber “offensive” capabilities for example. Why do those exist? To provide intelligence for defense.
Not really? Cyber threat intelligence is an incredibly overblown industry, remarkably similar to the xkcd about crypto. Offensive capabilities are for Natanz.
Everyone seems to think they need super ninja threat intel to protect them from elite nation state hackers, meanwhile they’re being randomware’d with metasploit modules from 8 months ago.
Run A/V and patch, that’ll be $1.7million, thanks.
Everyone seems to think they need super ninja threat intel to protect them from elite nation state hackers, meanwhile they’re being randomware’d with metasploit modules from 8 months ago.
Run A/V and patch, that’ll be $1.7million, thanks.
Nothing in my comment has anything to do with “cyber threat intelligence”. Did you reply to the wrong comment?
> To provide intelligence for defense.
Did you forget what you wrote?
Did you forget what you wrote?
I didn’t forget what I wrote, I just exist in the real world where missiles are a bigger threat than hackers.
That quote is from this PDF: https://dodcio.defense.gov/Portals/0/Documents/Library/DoD-Z...
They are. The entire purpose of the zero trust push is that it is nearly impossible to completely prevent perimeter breaches, so instead design in such a way that an actor inside your perimeter is not automatically trusted.
You can almost entirely prevent perimeter breaches (from untrusted attacks) by implementing authenticate-before-connect with strong identity incl. closing all inbound ports at source and destination.
> maybe spend less time fleshing out offensive capabilities and more time on defense of your citizens?
What do you mean? The US should invest in cyber defenses instead of fighter jets?
What do you mean? The US should invest in cyber defenses instead of fighter jets?
No it's just that the NSA used to work to make American companies more secure. Now they instead they find zero-days to then secretly exploit for as long as possible.
It's gotten so bad, that their recommendations for crypto are regarded with a significant degree of skepticism because of past history of deliberately undermining crypto systems which is a Terrible state of things.
It's gotten so bad, that their recommendations for crypto are regarded with a significant degree of skepticism because of past history of deliberately undermining crypto systems which is a Terrible state of things.
> their recommendations for crypto are regarded with a significant degree of skepticism
Indeed. Once you start talking about magical constants and extremely convoluted math concepts... that's zero trust in my book.
Integer factorization is a grade school concept in most developed nations. The edge cases are far more obvious than with something like ECC, which has entire classes of no-good constants that would require a PhD in math to fully grok.
Indeed. Once you start talking about magical constants and extremely convoluted math concepts... that's zero trust in my book.
Integer factorization is a grade school concept in most developed nations. The edge cases are far more obvious than with something like ECC, which has entire classes of no-good constants that would require a PhD in math to fully grok.
Prime factorization is one of the great unsolved problems in mathematics and if you can solve it there is a million dollar prize with your name on it. There are all kinds of issues with implementing crypto safely on top of it (google “Fermat factorization”), some related to bad constants. Being well known doesn’t make the math easy.
They do both, but right now the technology makes real defense (when you have real users) pretty much impossible. And not because of the NSA.
They do both, but it has been the case for a while that the NSA prioritizes offense. You can agree with that stance or not, but it is there, criticism on this point goes back at least a decade.
I agree that the security environment is awful, but that doesn't excuse NSA making it worse.
I agree that the security environment is awful, but that doesn't excuse NSA making it worse.
Of course NSA prioritises offense when it provides a vastly greater RoI.
Also, outside of SCIF environments (which do get prioritized), there isn’t a whole lot that is feasible for DOD or other gov’t agencies to do while still using civilian technology or working habits, which they don’t really have an option on right now.
The whole industry and economy needs to be upleveled software wise in a lot of ways for meaningfully better security to be economically possible.
Typically that requires a serious crisis and/or war. Hopefully not the case here.
The whole industry and economy needs to be upleveled software wise in a lot of ways for meaningfully better security to be economically possible.
Typically that requires a serious crisis and/or war. Hopefully not the case here.
> provides a vastly greater RoI
Of course it does. Thinking about it in terms of ROI doesn't consider externalities. When the OPM gets hacked, nobody at the NSA worries about their budget.
Reason #7893 "run government like a business" is a self-describing category error.
Of course it does. Thinking about it in terms of ROI doesn't consider externalities. When the OPM gets hacked, nobody at the NSA worries about their budget.
Reason #7893 "run government like a business" is a self-describing category error.
everyone uses ROI calculations somewhere (just not necessarily using cash as the return metric) or they are flying blind.
The underlying issue is that large organizations have low trust (some worse than others!), and therefore large organizations tend to coarse numeric metrics, and game those metrics to look better, which makes even more low trust (and hence backstabbing, empire building, etc.) between divisions.
As a reaction, leadership also tends to err towards coarse, harder to game metrics (like ‘reduce breaches by xx%’ rather than relying on judgement and trust like ‘ensure we don’t have an unreasonable number of breaches, and work to reduce them in the ecosystem’.
Which of course provides strong incentives for chasing the number by throwing all the babies out with the bathwater, and often making the real problem worse.
It’s a size of the organization problem. Changing metrics/mission will shuffle up the specific babies being thrown out, and what is considered the bath water, but the underlying problem remains.
Solid, consistent leadership makes the problem better. That tends to be expensive and not want to deal with the political BS common in Gov’t, at least in the US.
The underlying issue is that large organizations have low trust (some worse than others!), and therefore large organizations tend to coarse numeric metrics, and game those metrics to look better, which makes even more low trust (and hence backstabbing, empire building, etc.) between divisions.
As a reaction, leadership also tends to err towards coarse, harder to game metrics (like ‘reduce breaches by xx%’ rather than relying on judgement and trust like ‘ensure we don’t have an unreasonable number of breaches, and work to reduce them in the ecosystem’.
Which of course provides strong incentives for chasing the number by throwing all the babies out with the bathwater, and often making the real problem worse.
It’s a size of the organization problem. Changing metrics/mission will shuffle up the specific babies being thrown out, and what is considered the bath water, but the underlying problem remains.
Solid, consistent leadership makes the problem better. That tends to be expensive and not want to deal with the political BS common in Gov’t, at least in the US.
The government does a ton of pure research, including in computer science and security, which is explicitly not about ROI but rather about advancing our understanding of basic science.
Which always has a grant proposal laying out hoped for results in areas being investigated, at least most of the time correct?
Someone looks at it and goes ‘yeah, that might pay off’ or round files it somewhere.
Researchers who never end up finding anything notable also don’t tend to have long careers, correct?
Someone looks at it and goes ‘yeah, that might pay off’ or round files it somewhere.
Researchers who never end up finding anything notable also don’t tend to have long careers, correct?
None of that is what I’m talking about, no. I know many researchers who are quite proud of the fact that their research is never going to make money but is super interesting from a scientific perspective.
The crazy amount of skepticism this always draws is simultaneously very funny and very saddening.
The crazy amount of skepticism this always draws is simultaneously very funny and very saddening.
That a percentage of total funds is put into stuff like that isn't surprising, to avoid too much hyperfocus on what we know.
What percentage of the overall budget do you think it is?
What percentage of the overall budget do you think it is?
[deleted]
Can you please share a source? This isn’t laziness. I know I can search — and I will —- but I cannot know what sources _you_ are intending, which provides context.
I did have some things in mind but, to save me a bit of time, are there any particular claims you're looking to source?
Sure, thanks
> No it's just that the NSA used to work to make American companies more secure
1. I'm interested in that history; e.g. how it came about and how it worked.
2. Evidence that this is no longer (or less of) a goal: policy, internal priorities, spending? Congressional testimony, legislation, or guidance? Leaks?
> No it's just that the NSA used to work to make American companies more secure
1. I'm interested in that history; e.g. how it came about and how it worked.
2. Evidence that this is no longer (or less of) a goal: policy, internal priorities, spending? Congressional testimony, legislation, or guidance? Leaks?
It seems to be that $100B spent by NSA on offensive operations will reap far greater security benefits than spending $100B “to make American companies more (cyber)secure”.
Knowing what your adversaries are up to is invaluable.
Knowing what your adversaries are up to is invaluable.
Here’s one concern highlighting the value of broad defenses. A targeted software-based attack may trigger supply chain disruptions with significant (even if only short-term) impacts. If combined / coordinated, multi-billion dollar disruption is within reach.
The actual roadmap document (PDF) is not linked directly from the press release:
https://dodcio.defense.gov/Portals/0/Documents/Library/DoD-Z...
https://dodcio.defense.gov/Portals/0/Documents/Library/DoD-Z...
Zero trust is fun, it's fine if the computers were all from the last decade and not circa. 2011-2013 HP mini's with HDD rather than SSDs or M.2 in the newest revisions of allowed devices on our networks.
Why would the hardware matter? Zero trust has zero (ha!) to do with hardware.
Don't zero trust architectures often require secure boot as well as a functioning TPM-like secure enclave to do attestation on the client device before allowing the user to logon to some resource?
I would say thats a bonus. Zero trust should be based on strong identity (e.g., x509) and authentication/authorisation-before-connect, ideally that identity would come from HWRoT/TPM. Unfortunately, many vendors say they are zero trust while only implementing some aspects/principles. I wrote a blog on this topic earlier in the year - https://netfoundry.io/demystifying-the-magic-of-zero-trust-w...
It seems to me that distributing this information as a PDF undercuts the message a bit. It's tangential; sure, but also, it doesn't strike me as particularly good security either.
what do you expect it to be distributed as?
I was thinking text/plain would be best way to get the point across.
The type of people that DoD wants to read this are not the type of people that prefer text/plain.
That cuts to the nub of the problems more than any other comment.
We've been spending far too much on the presentation layer of security
for 20 years.
Those are the people that need to understand that a lot of security depends on simpler file formats.
Except that’s completely false.
hnshitpost(1)
Do you not trust the PDF?
Sounds like you're getting the message just fine!
Sounds like you're getting the message just fine!
Didn’t know much about Zero Trust. This article was helpful: https://www.csoonline.com/article/3247848/what-is-zero-trust...
When I think of "zero trust" I think concepts like zksnarks where all the information is already out there (go ahead and let your org leak, in fact you can even deliberately publish it) but protected in such a way that only legitimate uses can decipher / make use of it.
What they're talking about here sounds more like things that ought to be obvious but the industry got lazy about.
What they're talking about here sounds more like things that ought to be obvious but the industry got lazy about.
Firewall and VPN is the obvious part, and that's the industry standard.
Zero-trust means that Access Control is more finely-grained, down to the machine/user level. In this approach we don't trust any machine/user inside the organization as well.
Zero-trust means that Access Control is more finely-grained, down to the machine/user level. In this approach we don't trust any machine/user inside the organization as well.
I think its goes beyond this, its doing authentication-before-connect using strong identity so that we can have 'zero trust' of the network, whether internet/WAN (e.g., closed inbound ports), LAN or even host OS.
Your understanding is an uncommon one.
What they are talking about here is the more common understanding.
What they are talking about here is the more common understanding.
NIST Zero Trust Architecture recommendation:
https://www.nist.gov/publications/zero-trust-architecture
https://www.nist.gov/publications/zero-trust-architecture
What is a real joke is how you can make into the phone system at the DOD and speak to a human and they give you information without even verifying who the hell you are. Still happens all the time.
[deleted]
This is the kind of decentralized systems web3 is supposed to be. Not ethereum tokens
Web3 came and went to no fanfare in places like Estonia, who have cutting edge digital identity and trust systems built on boring, existing crypto primitives and smart cards, while in the US we’re stuck with checks and paper signatures. Everyone raves about distributed identity while Login.gov is now integrated with almost 220+ federal agency systems, is the primary identity provider for Social Security (and soon, IRS after the ID.me debacle), and is a bit of PKI and CAC/smart card infra away from being a huge leap forward.
Hot take: real innovation is finding the right person’s metaphorical arm to twist to get enough leverage to get the tech implemented. The tech is the easy part. Bureaucracy hacking is underrated.
https://e-estonia.com/solutions/e-identity/id-card/
Hot take: real innovation is finding the right person’s metaphorical arm to twist to get enough leverage to get the tech implemented. The tech is the easy part. Bureaucracy hacking is underrated.
https://e-estonia.com/solutions/e-identity/id-card/
Gemalto was hacked, possibly by GCHQ/NSA. How confident are you that the keys in the smartcards aren't compromised by an peer nation-state (e.g. China)? Security is always hard when you adversary is patient, motivated and well-resourced.
More confident than in blockchains.
> Our adversaries are in our networks, exfiltrating our data, and exploiting the Department’s users.
I'm happy to see this admission lead the document; it's bold coming from an org as conservative as the DoD. To see critical mass around the idea that -- like it or not -- adversaries (both malicious insiders and outsiders) are already on trusted networks is really encouraging to see.
First, let's be clear what this document is and isn't.
> Importantly, this document serves only as a strategy, not a solution architecture. Zero Trust Solution Architectures can and should be designed and guided by the details found within this document.
This is a long term strategy doc, not an implementer's guide. Operators looking for zero-trust easy mode won't find it here. It's also very DoD specific.
But there are some good parts. I read the doc so (maybe?) you don't have to.
I made some screenshots of the portions I thought most relevant.
https://imgur.com/a/Dhm7yvi
The comments will make more sense if you are viewing those.
> Zero Trust uses continuous multi-factor authentication, micro-segmentation, advanced encryption, endpoint security, analytics, and robust auditing, among other capabilities, to fortify data, applications, assets, and services to deliver cyber resiliency. The Department is evolving to become a more agile, more mobile, cloud-supported workforce, collaborating with the entirety of DoD enterprise, including federal and non-federal organizations and mission partners working on a variety of missions.
If you somehow managed to read the above without going into a post word salad coma, I'm sorry. I highlighted the section just to bring up there's an awful lot of enterprise security buzzword and DoD acronym bingo going on. But there are some good thoughts too.
> Zero Trust is much more than an IT solution. Zero Trust may include certain products but is not a capability or device that may be bought.
It's nice to hear this being reiterated so often. A good start!
> Zero Trust security eliminates the traditional idea of perimeters, trusted networks, ...
Zero trust is -- to me at least -- mostly about the idea of removing perimeters and trusted networks as the basis for trust and access control. So I'm with you so far.
> ... devices, personas, or processes and shifts to multi-attribute-based levels of confidence that enable authentication and authorization policies founded on the concept of least privileged access concept of least privileged access
But it's interesting here that the authors are also calling out and devices, personas which is what I'd argue are the fundamental contextual attributes that allow you to replace a "trusted perimeter"; if we aren't using perimeters, devices, personas... what is the DoD suggesting we use? I can't find it.
> At its core, ZT assumes no implicit trust is granted to assets or users based solely on their physical or network location (i.e., local area networks versus the Internet) or asset ownership (enterprise or personally owned).12
I strongly agree with the first point, but disagree and am perplexed by the second. Zero trust is all about getting rid of a trusted network location.
However, asset ownership *matters* because it affects not only the identity of the user, but also the _state_ of the device. It's totally reasonable to have different levels of trust for a managed company owned device with a known set of endpoint protection tools, vs a BYOD device whose device state is largely unknown.
The doc does a good job of outlining the "Why" of zero trust. And what's required from an org to make it possible.
Unfortunately, while the document starts out strong, it quickly becomes "actually, zero trust is every security thing you've ever heard of". Paired with a timeline no one will ever meet ever.
I'm happy to see this admission lead the document; it's bold coming from an org as conservative as the DoD. To see critical mass around the idea that -- like it or not -- adversaries (both malicious insiders and outsiders) are already on trusted networks is really encouraging to see.
First, let's be clear what this document is and isn't.
> Importantly, this document serves only as a strategy, not a solution architecture. Zero Trust Solution Architectures can and should be designed and guided by the details found within this document.
This is a long term strategy doc, not an implementer's guide. Operators looking for zero-trust easy mode won't find it here. It's also very DoD specific.
But there are some good parts. I read the doc so (maybe?) you don't have to.
I made some screenshots of the portions I thought most relevant.
https://imgur.com/a/Dhm7yvi
The comments will make more sense if you are viewing those.
> Zero Trust uses continuous multi-factor authentication, micro-segmentation, advanced encryption, endpoint security, analytics, and robust auditing, among other capabilities, to fortify data, applications, assets, and services to deliver cyber resiliency. The Department is evolving to become a more agile, more mobile, cloud-supported workforce, collaborating with the entirety of DoD enterprise, including federal and non-federal organizations and mission partners working on a variety of missions.
If you somehow managed to read the above without going into a post word salad coma, I'm sorry. I highlighted the section just to bring up there's an awful lot of enterprise security buzzword and DoD acronym bingo going on. But there are some good thoughts too.
> Zero Trust is much more than an IT solution. Zero Trust may include certain products but is not a capability or device that may be bought.
It's nice to hear this being reiterated so often. A good start!
> Zero Trust security eliminates the traditional idea of perimeters, trusted networks, ...
Zero trust is -- to me at least -- mostly about the idea of removing perimeters and trusted networks as the basis for trust and access control. So I'm with you so far.
> ... devices, personas, or processes and shifts to multi-attribute-based levels of confidence that enable authentication and authorization policies founded on the concept of least privileged access concept of least privileged access
But it's interesting here that the authors are also calling out and devices, personas which is what I'd argue are the fundamental contextual attributes that allow you to replace a "trusted perimeter"; if we aren't using perimeters, devices, personas... what is the DoD suggesting we use? I can't find it.
> At its core, ZT assumes no implicit trust is granted to assets or users based solely on their physical or network location (i.e., local area networks versus the Internet) or asset ownership (enterprise or personally owned).12
I strongly agree with the first point, but disagree and am perplexed by the second. Zero trust is all about getting rid of a trusted network location.
However, asset ownership *matters* because it affects not only the identity of the user, but also the _state_ of the device. It's totally reasonable to have different levels of trust for a managed company owned device with a known set of endpoint protection tools, vs a BYOD device whose device state is largely unknown.
The doc does a good job of outlining the "Why" of zero trust. And what's required from an org to make it possible.
Unfortunately, while the document starts out strong, it quickly becomes "actually, zero trust is every security thing you've ever heard of". Paired with a timeline no one will ever meet ever.
I agree that it quickly became a radar for every single tech/vendor which slaps a 'zero trust' sticker on their product. Personally, I believe that while zero trust applies to all pillars, the most consequential is the network if we pair it with comcepts/components of the other pillars.
For example, if we state we want to have zero trust in the network, we can achieve this by switching from authenticate/authorise-after-connect (i.e., how TCP/IP/almost every network is built), to authenticate/authorise-before-connect. This is achieved with strong identity (e.g., x509) and an overlay network built on zero trust principles which further provides us microsegmentation, least privilege, etc. It allows us to close all inbound ports and make access decision at the source (rather than destination) edge (e.g., device/user) and close all inbound ports. This makes many MITRE attacks impossible and massively reduces the affect of others. We can have zero trust in the WAN/internet (no inbound ports), LAN and even host OS.
For example, if we state we want to have zero trust in the network, we can achieve this by switching from authenticate/authorise-after-connect (i.e., how TCP/IP/almost every network is built), to authenticate/authorise-before-connect. This is achieved with strong identity (e.g., x509) and an overlay network built on zero trust principles which further provides us microsegmentation, least privilege, etc. It allows us to close all inbound ports and make access decision at the source (rather than destination) edge (e.g., device/user) and close all inbound ports. This makes many MITRE attacks impossible and massively reduces the affect of others. We can have zero trust in the WAN/internet (no inbound ports), LAN and even host OS.
Zero trust is about not trusting anything, not only the network, and instead focusing on controlling the access/damage. It is 100% authz, about limiting what you can access and how long you can access it to what is required. That you there is no trust in those agent (ie. assume authn is already compromised) so you limit the damage possible.
I would extend it to not inherently trusting the agent as well as being able to not have to trust the network (e.g., internet WAN) by closing all inbound ports by implementing authentication-before-connect using strong identity (e.g., x509)
> authentication-before-connect using strong identity
Identity always involves trust and is authn. Zero-trust assumes authn is already compromised (ie. don't trust anything) and therefore identity is out of scope.
Identity always involves trust and is authn. Zero-trust assumes authn is already compromised (ie. don't trust anything) and therefore identity is out of scope.
Quote from NIST, "Zero trust assumes there is no implicit trust granted to assets or user accounts based solely on their physical or network location (i.e., local area networks versus the internet) or based on asset ownership (enterprise or personally owned). Authentication and authorization (both subject and device) are discrete functions performed before a session to an enterprise resource is established."
Zero Trust is not assume everything is compromised and you dont trust anything. Its about reducing implicit trust across the pillars to reduce risk.
Zero Trust is not assume everything is compromised and you dont trust anything. Its about reducing implicit trust across the pillars to reduce risk.
I think you are just misreading it. Read correctly, IMO, it says that no trust is granted to anything... note how they list multiple general examples, enough items to cover everything multiple times, to help make sure this was the reading. That authentication is discrete from authorization and outside of each others purview. And given zero trust is all about access control, I think my framing makes sense.
Any framing which helps one to reduce systematic risk is fine by me and fully agreed that authentication is discrete from authorization. My framing is set by the open source project I work on (https://openziti.github.io/) which allows anyone to embed zero trust networking into anything including an application with an SDK, this allows us to have zero trust in the network, be it internet/WAN, local or even the host OS network. This reduces a lot of the attack surface but you do have the trust the overlay control plane.
> closing all inbound ports by implementing authentication-before-connect using strong identity (e.g., x509)
Bad bot.
Bad bot.
What does bad bot mean?
>advanced encryption
Now I really want to know the DoD's definition of basic vs. advanced encryption. Is there a middle tier, like average encryption?
Now I really want to know the DoD's definition of basic vs. advanced encryption. Is there a middle tier, like average encryption?
I was pushing this stuff in DoD for years. Glad to see it catch on.
Take some solace in the fact that you probably _did_ make a
difference. Just one you couldn't see while being ignored
for years.
It’s exhausting to the soul to yell into the void for so long.
Is zero trust just the same idea as agile 'fixing' waterfall?
I.e. is it just another 'practice' marketed to solve an existing people and process issue that can be readily solved with proper focus , which just introduces its own issues anyway? Like sure, zero trust will work IF you do it really well, but then so will the existing environment.
I.e. is it just another 'practice' marketed to solve an existing people and process issue that can be readily solved with proper focus , which just introduces its own issues anyway? Like sure, zero trust will work IF you do it really well, but then so will the existing environment.
1.6 Behavioral, Contextual ID and Biometrics & 7.4 User and Entity Behavior Analytics - focus monitoring/auditing on accounts that all of a sudden transfer 10GB data when they usually only transfer only 100MB/day, or where the employee has had to be asked for that one time of the year to login on a weekend at an office they don't usually visit.
5.1 Data Flow Mapping - detect unexpected egress of data by defining ahead of time the volumes of data being transferred between systems (e.g. 2AM backup transfers 100GB to systemX and between 9AM-5PM there is a usual data transfer rate of 1MB/s therefore 100MB/s transfer rate at 1PM would raise an alert).
How well do these techniques work in practice, particularly in a huge organisation? I would have thought the number of false positives would be very high and the people monitoring the anomalous behaviour wouldn't have much or any context to know whether something is legitimate or not.
A more feasible approach may be system owners installing a new system would have to specify rate limits (including per time of day, per API call and/or per user) and would have to lodge as part of a change request whether these limits need to be temporarily increased to cater for a one-off or rare event such as a major system upgrade. But given that some of the other techniques listed indicate a lack of awareness of what software is installed and is in use, it seems unlikely that specification of rate limits would happen any time soon.