CISA Zero Trust Maturity Model
cisa.govI like seeing these guidelines but I definitely have been thinking about this essay from a couple months back which I think accurately calls the current situation untenable. These are all good advice, but even most government agencies have nowhere near the budget to fully implement them.
https://doublepulsar.com/the-hard-truth-about-ransomware-we-...
> The truth is, while governments are pushing frameworks such as Zero Trust, the amount of orgs who successfully implement these are… not many. Many companies can barely afford to patch SharePoint, let alone patch the the tens of thousands of application vulnerabilities shown in a vulnerability management program, and really struggle with accurate asset lists. … > My concern, for years, has been that ransomware gangs have not only closed the loop on monetization, they are also acquiring so much income they are becoming a bigger operational threat than some states. > > To give an example, one ransomware group receiving a $40m payment for attacking a cybersecurity insurance company gives the attackers more budget to launch cyberattack than most medium to large organizations have to defend against attacks in total. And that’s just one attack, from one group, that barely made the news radar of most people. > > The payment amounts are increasing, the frequency is increasing, the sophistication is increasing.
Goes hand-in-hand with the recent scathing message from Nicolas Chaillan regarding DoD development modernization efforts
https://www.linkedin.com/pulse/time-say-goodbye-nicolas-m-ch...
I know the HN discussion had some debate over that (https://news.ycombinator.com/item?id=28408399) but I definitely think there's a lot of good discussion about how to make these problems more tractable. Even in the .gov space, which does tend to treat security as something you can't just brush away, there's generally limited money and resources for actually shipping improvements and especially challenging are the issues of legacy apps (which probably require Congress to allocate money for replacements) and adequately staffing for O&M (contractors are usually a bad fit with lower continuity and restrictions on flexibility). Most of the breaches you hear about trace back to something which someone has been complaining about for ages but been unable to get support for actually fixing.
I perused the draft and was surprised by my jaded reaction: Great! More effort put into detailed cybersecurity strategies for the likes of OPM, T-Mobile, and Equifax to ignore.
We have thousands of pages of frameworks and NIST guides and the people in charge, especially in the private sector, are free to neglect or ignore them with impunity because apparently regulators don’t care and the market doesn’t care, so why should they?
It’s like we have these brilliant cryptographers working on technical advancements that I can barely grasp, and the people (management) in charge of putting their work to use can’t be bothered with basic patch management.
The whole landscape of practical cybersecurity feels very hopeless to me.
Come work in healthcare - if you are at one of the larger insurance orgs (UHG, Anthem, Humana) or hospital networks (HCA, Dignity, etc) you are locked into a world of this model making your life the most difficult imaginable. Need vendor support? Hope you like watching them work over webex as they wont have any access to any of your servers. Need a VPN to tunnel data across? Yeah good luck with that it'll take at least 6 months mostly for legal to approve. On top of rotating passwords on a yearly basis for service accounts , regular entitlement reviews, risk reviews, policy reviews, and rotating passwords for users every 90 days still along with multifactor authentication. I feel like I'm working at ft knox every day.
This sort of speaks to what the GP was talking about -- not following guidelines and frameworks.
For example,
>On top of rotating passwords on a yearly basis
> rotating passwords for users every 90 days
NIST 800-63B, as of 2017, explicitly advised against this.
"Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically)." [1]
Agreed, be careful what you wish for. When I was a consultant at Red Hat I worked with a lot of customers in this boat. We had to jump through absolutely absurd hoops that made a two day job take weeks.
I'm a security pro and I rejoice in secure systems, but swinging the pendulum to the other side is bad too.
there are ways to 1. be secure, 2. be productive.
I think that's the ultimate goal of "zero trust," but maybe I'm naive
A lot of these frameworks are to convince bean counters that Their sysadmins are right.
“Why do you wanna make that change? It’s expensive!”
“Because it says so right here, sir”
That “official” guidance can go a long way.
If you want to work in the DoD supply chain after 2024 then you'll have to implement NIST 800-171 and some level of CMMC. Its no longer a self-attestation and requires a 3rd party audit and certification. Its not trivial.
The compliance costs aren't what worry me. The part that worries me is ending up with FIPS but even worse everywhere. Just because of how slowly it evolves and how people are stuck on old things because of that.
I cant argue. I dont love all of the things we are required to do. I'm sure my current VPN is better than what I'll have to implement. The things I'm required to implement are major attack targets with histories of vulnerabilities - but they are certified.
One target audience for this document that can’t ignore it (at least not as easily) is the federal government and the contractors they hire. In 2020, the chief information security officer of a federal agency told me they didn’t buy into this newfangled zero trust stuff and would continue to rely on network perimeter security, largely because that’s what CISA and OMB documents offered as a reference architecture.
And if you look, CISA is mostly for gov agencies and critical infra like oil pipelines.. They have a harder time ignoring stuff like this if they are obligated by law.
Zero Trust is such a terrible name. What they really mean is less trust in network location, static firewalls, and site-to-site VPNs, and much more trust in the cryptography behind TLS, identity systems, and how they interact with applications.
I think defense in depth is also a major related principle. Make each layer as beefy as possible in terms of security even if seemingly redundant since these help when other layers are bypassed through some exploit.
However, in my opinion one major failing of this paradigm is that while some additional layers are useful, it's still good to think about threat models and failure modes since at some point, you can't implement additional security measures due to the computational and human cost.
See also last month's K8s hardening guidance.
https://news.ycombinator.com/item?id=28050750
https://media.defense.gov/2021/Aug/03/2002820425/-1/-1/1/CTR...
Regarding authentication, the "optimal" practice is described as:
> Agency continuously validates identity, not just when access is initially granted.
How does this work practically without having terrible UX? MFA to login, then periodically poll for the presence of a hardware token and less frequently, prompt for password reauthentication?
There are programmatic implications for this as well. For example, don't use/trust really long lived tickets with Kerberos and force renegotiation with the AS. This doesn't require much human interaction if you are using keytabs. However, IMO it is much more important to continuously be checking authorization to ensure no funny business is going on rather than relying upon implied permissions.
Just in time before 2022. Great!