The new White House memo on zero trust is a strong signal
pomerium.com
pomerium.com
No, my problem is that every goddam security product company in the world is treating it like the white paper for their product, and so, if you pay attention to security stuff, you're besieged with takes about how this memo is going to change everything, hmmm, just coincidentally, in such a way that makes our product vital to the continued working of every company connected to the Internet.
God help us if the federal government ever publishes a memo about geographically distributing app workloads. You thought I was a nightmare now.
"[M]any overlook device identity but it’s one of the most important context sources". Yeesh.
90% of it is box ticking.
In my view, SOC2 is equivalent to apple forcing PKI on app developers for ad-hoc testing. Ultimately a bunch of complex bullshit boilerplate that some adversarial actor could trivially usurp if they were inclined to do so. Lying to an auditor or due diligence process is not hard.
Real security comes from practical experience and procedures, not bullshit busywork proposed by someone who has no clue how your business operates.
I guess the context here is zero trust, so s/laptop/HR vacation request site/.
Well... Sort of?
The Industrial Internet of Things (IIoT) refers to the application of
instrumentation and connected sensors and other devices to machinery and
vehicles in the transport, energy, and other critical infrastructure sectors.
In the energy sector, distributed energy resources (DERs) such as solar
photovoltaics including sensors, data transfer and communications systems,
instruments, and other commercially available devices that are networked
together. DERs introduce information exchanges between a utility’s
distribution control system and the DERs to manage the flow of energy in the
distribution grid.
This practice guide explores how information exchanges among commercial- and
utility-scale DERs and electric distribution grid operations can be monitored
and protected from certain cybersecurity threats and vulnerabilities.
The NCCoE built a reference architecture using commercially available products
to show organizations how several cybersecurity capabilities, including
communications and data integrity, malware detection, network monitoring,
authentication and access control, and cloud-based analysis and visualization
can be applied to protect distributed end points and reduce the IIoT attack
surface for DERs. [1]
At least #2 is in draft and not finalized.
[1] https://csrc.nist.gov/publications/detail/sp/1800-32/final
[2] https://csrc.nist.gov/publications/detail/sp/800-204c/draft
It's about time. That's how airliners are designed. The guiding principle is "no single failure will bring the airplane down."
What it is not is "guarantee critical components will not fail".
The airline design principle is applicable to all kinds of things, like electrical grid design, security design, nuclear plant design, oil drilling platform design, ship design, and on and on. But I see it rarely applied, which is frustrating.
EDIT: In case it's not clear: I'm talking about employee facing software inside an organization where you might have some kind of single sign on system or a distributed account system (like IPA or LDAP.)
For example, don't use the same password on your Etrade account that you use on your bank account.
The SP never sees the credentials. The SP only sees a token which includes the username (NameID) and other attributes passed from the IdP through the client.
https://en.wikipedia.org/wiki/Security_Assertion_Markup_Lang...
(Scroll down to the "Single sign-on using SAML in a Web browser" image for a good data flow depiction)
Basically this seems to be a "SAML-IZE EVERYTHING".
With ZT, you basically have to bootstrap trust from the factory. I don't think of ZT as "don't trust anything" - it's more like "trust our supply lines".
Think about the failure modes of ZT: if the NIC, the CPU, the OS, and the bootloader are deemed secure at boot time, there has to be something that starts the bootloader and loads its keys. If you compromise _that_ piece, then you can compromise anything further up the stack and not worry too much about security alerts. The only way to make sure that all machines are secure/uncompromised is to XRay all of the bootloader chips and verify them down to the ~100um level (got this figure by talking to a guy doing grad work @UofM when he was in SV around 2017-2018, I want to say).
There is a Wikipedia article on 'Key ceremony'[0] that seems to indicate an in-real-life shared secret creation and or sharing event.
*Can* this fail?
but instead ask:
*When* this fails, can it be survived?
I don't think I'm communicating myself clearly here, but I would like to thank the parent commenter for his insight into this area and more. Just to cover my bases.
EDIT: I want to make clear that there is no sarcasm here. I respect WalterBright probably only behind Knuth in terms of effective programmers/engineers in the field today, and I doubt I could add anything to his opinions.
In order to survive shutting down that access, the system must be compartmentalized, so the shutdown is limited in scope.
For example, the hydraulic system on an airplane has a redundant equivalent hydraulic system. But within a hydraulic system, it is designed to isolate failed sections of it from the rest, so the rest can still function. I.e. developing a leak in the elevator actuators won't disable the aileron actuators on the wings.
The Fukushima plant and Deepwater Horizon rig both had a vulnerability to a single point of failure that produced cascading failures that unzipped the whole system. Both were easily and inexpensively preventable.
But that may not fit the risk profile, and you may need additional considerations - and perhaps even different levels of authentication.
Yet another example of the concepts of airliner design being completely unknown outside of the aviation industry.
The "grid" doesn't appear to be a grid at all, but a tree. An actual grid would be able to route around failures, much like the internet protocol can do.
The trouble is that the power grid just operates on the electrical principle of electricity following the path of least resistance. So if there's low resistance but low capacity line between generation and usage, the electricity will flow through it, and there is no QoS on the line that can limit how much power goes through it, besides on/off.
The on/off nature of the interconnections is what makes the power grid fragile. If a interconnection has a rating of 100MW or whatever, and the grid attempts to pump 110MW through it, you either leave it on and hope it doesn't break or shut it off and pump 0MW. The grid will then automatically route that 110MW through other interconnects. If there is a nearby 500MW interconnect that is currently pumping 350MW, you're fine, but if it's pumping 475MW, you're probably not. This can lead to cascading failures.
The grid does have the ability to shut down usage if there's a danger of a cascading failure. For instance, if your 100MW rated interconnect has 101MW coursing through it, you can shut down a neighborhood that's using 10MW or whatever, and keep the 100MW interconnect online with just 91MW running through it. This is what brownouts and rolling blackouts are.
The grid can have major failures, but these major failures don't happen unless there are multiple overlapping minor failures. Similarly, if your 737 MAX has 2 MCAS sensors and 1 manual MCAS override button, and both your sensors and your manual override all fail, you're going to have a bad time. Look at the sequence of events of the 2003 Northeast blackout: https://en.wikipedia.org/wiki/Northeast_blackout_of_2003#Seq... There are at least half a dozen failures between the initial problem at 12:15pm and until the point of no return failure at 4:05pm that if handled properly would have averted the crisis and turned it into a minor inconvenience. At least half a dozen instances of human error plus multiple instances of equipment failures. If an aircraft had that many things go wrong all at once, the plane's going down.
Note that the Texas power outage last year wasn't like this at all. The grid actually kept working fine, the problem is that there were lots of generators that failed as a result of the cold, mostly due to impure natural gas freezing. The generation capacity of the grid was cut to a fraction of its capacity, and as a result, they shut down a bunch of cities to reduce load. For whatever reason, they just left power off in several cities for days instead of doing rolling blackouts. I don't know enough about the circumstances to speculate on what the reason for that is.
But you should know that there was a backup. 3 crews experience MCAS failure. 2 crashed. The 3rd crew simply turned off the stab trim system and completed the flight safely. You almost never hear about crew #3.
I can't really offer any suggestions for the power grid, as I don't know enough about it, except that I'm sure there's a way :-)
And in cases like zero trust it may mean things like “make sure it works so well you don’t have people resetting access over the phone” or requiring an in-person replacement of a security token, etc.
But the only reason there are pilots at all on an airliner is to deal with the unexpected.
I was told about one case where the elevator actuators froze in the slightly nose up position. The pilot called the cabin, and asked everyone to pack themselves into the front. With that he managed to bring enough pitch control to land it safely, but it surely was a terrifying ordeal for everyone on board.
(The actuators froze because of water buildup turning to ice at altitude. Actuators are now heavily designed and tested with freezing water. The stab trim test for this was quite thorough - the motors were very powerful and the ice scrapers on the nut would just peel the ice off. I also enlarged the drain holes in my car doors to Boeing spec so water wouldn't build up in them and rust.)
Unfortunately for the Ethiopian Airlines crew, they were too late. By the time they set the stabilizer trim to CUT OUT, MCAS already pushed the plane nose down too much and they couldn't manage them manual controls, which were pretty hard to use under extreme conditions[2].
I'm not an expert or even an amateur, but the engineering issue I see here is that Boeing really left no contingency plan for a catastrophically failing AoA sensor on take-off. You can't turn off MCAS directly, and the recommended indirect method for turning it off require skills that many (most?) commercial airline pilots are not trained for.
The worst thing, of course, is that the Lion Air crew that crashed wasn't even aware of MCAS. The 737 MAX manuals made no mention of it.
[1]: https://en.wikipedia.org/wiki/Ethiopian_Airlines_Flight_302 [2]: https://www.cliffordlaw.com/boeing-faa-knew-manual-stab-trim...
They had successfully brought it back to normal trim with the electric trim switches, which had overridden MCAS. Then, the trim gets turned off.
The 3rd crew that survived had no idea MCAS existed. All they knew was misbehaving trim => turn it off. They also had repeatedly used the electric trim switches to return trim to normal. Then they turned it off.
This procedure was documented in an Emergency Airworthiness Directive sent to all MAX pilots, including the EA crew.
The only skill required was to use the electric trim switches to restore normal trim, which all three crews did, and then turn it off.
The point is, it is not necessary to know why the trim is misbehaving, it was only necessary to know how to turn it off. Emergency procedures are like this - they're not debugging procedures, they're about regaining control. Save the debugging for the mechanics on the ground.
P.S. the LA crew restored normal trim 25 times, and never did turn it off.
All it takes for a 737 MAX to crash is one piece of equipment failure and 2/3 an instance of human error. I submit that if three crews were presenting with the same situation and two of them crashed with everyone onboard killed, it's not really the sort of thing that you can blame on human error.
All it takes for a catastrophic failure of the grid is literally over a dozen cascading equipment and human error instances.
I guess I don't understand -- you're saying that the grid, where over a dozen overlapping failures is required for catastrophic results, should learn from the airline industry where it takes 2-5 failures to bring down an airliner.
I think it's possible you're maybe getting confused about what the point of the interview was-- were they talking about a targeted attack on the power grid? An adversarial opponent, knowledgeable, determined, well funded, conducting a dedicated attack on the power grid? I think that yes, if a nation state or terrorist organization conducted a targeted attack on the power grid, it would likely do an outsized amount of damage on a regional portion of the nation compared to the resources expended. But in that case the comparison to airliners does not apply -- all the redundant safety systems in the world aren't going to save you from a Buk or SM-2MR surface to air missile.
Load is simply distributed among the working parts of the grid.
However the issue is that the grid doesn’t cut off a part of itself for the sake of survival.
I think the issue is: at some point you have to shed off some of your customers and choose the ones that still get power.
Who makes that call? Where do you even draw the lines? And how do you do this quickly in a few minutes?
And yeah, you let a section fail if that prevents the entire system from failing.
The power in my neighborhood fails all the time, even though it is well within the city. Fed up, I finally installed a generator last year. Several failures since, including going out for the night 2 days ago, continues to justify it. I was probably the last holdout, one by one each of the neighbors had acquired a generator.
I live in California and I have had maybe 2 blackouts in 15 years? For maybe 3 hours?
Granted, my electricity bill is kind of high.
What ZTN is mostly about is changing the SPOF we had before --- the network perimeter --- to something fuzzier and more flexible. It's a good plan; we've been talking for over 20 years, going back to the Jericho Forum, about "deperimeterization" and "segmentation", and segmentation hasn't really worked out.
But it'd be a mistake to look at all of this stuff and think that it's a shift away from single points of failure, or to fundamentally greater resilience. We're opting for better SPOFs, not the elimination of SPOFs.
I have had people tell me in meetings at work that they have pictures of people swapping out parts on an assembly line for unknown parts. If that's happening, unless the machines are verified by XRay, from my point of view, the ZT concept isn't worth a whole lot.
We don't so much have to get lost in abstractions here. There's a blueprint: all this ZTN stuff was inspired by Google's BeyondCorp paper (ZTN is the marketing-neutral name for BeyondCorp; the Kubernetes to BC's Borg). So: just go read the BeyondTrust paper; it's great:
https://storage.googleapis.com/pub-tools-public-publication-...
a) This is implementation heavy
b) The implementation is tied to a specific company migrating to this approach incrementally
I would say it's a great case study for moving to a ZTN, but if I were to explain ZTN I'd probably just propose a definition. I'm technically a vendor but the definition serves me in no way.
1. Requests are mutually authenticated and always encrypted (ex: mtls)
2. Requests are authorized; policy oriented, granular, and contextual authorization
3. Requests are monitored and audited
The paper lists a bunch of ways to accomplish those goals. SSO, device inventories, an authorizing proxy, a monitor, etc.
Of course, you're right. Vendors are horribly self serving and have already significantly degraded the term and confused people.
If someone is interested in ZTN they would be best presented with both imo
The idea is assume the board is compromised. Now what?
Answering that question is the key to robustness.
When I got a job at Boeing, I thought it was impossible to design an airplane with full redundancy. They showed me how it was done.
If a node is compromised, that shouldn't turn into full access to everything. Specifics would vary depending on your application, but while most user facing servers might need to be able to validate a login token, few would need to be able to issue a login token or access billing details.
If you compromise the node that has billing details or access to them, then you'll have them, but if you compromise a different node, you won't. That's better than compromise any host and get access to the 'private' network where there's no auth or encryption, which is kind of traditional.
aren't all internal amazon services doing this every-api-called-authenticated thing?
A company wants to design a service with three operations. Signup(username, password), SetData(username, password, new_data) and GetData(username).
The client app is assumed to be trusted, but any server (no more than one though) could be compromised. Design a protocol so that the compromise does neither allow an attacker to update someone elses data, return wrong data, nor cause a denial of service.
1. when on a ladder, always 3 of my 4 limbs are firmly on the ladder at all times.
2. when jacking up my car, I always put 2 sets of jack stands under it.
3. I never put a body part underneath a chain hoist.
4. I rehearse in my mind what to do if the brakes fail.
I’m convinced that the “defense in depth” and “security permitter” models were pretty much entirely driven by laziness (define a perimeter and call it a day) and pork (defense in depth= we can pay for tons of different disjoint security software/vendors/contracting because it adds depth). Zero trust actually requires you to do the right thing and do it everywhere, and hopefully reduces the amount of waste thrown at vendors. It will create a lot of integration work but will hopefully consolidate the actual security software used.
It can be the justification for things like database controls, OS level controls, or seemingly trivial things like log forging. I heard a million different versions of “it’s not a big deal because an attacker would have to breach our network already”
Consider an older citizen losing their hardware token, and unable to login to their Social Security or IRS account. The current model is to be expected until the government builds out its identity functions. Security is about trade offs and compromise.
(no affiliation with login.gov or related federal agencies, just a fan of their work)
The other question I'd ask is how bad SMS really is: it's definitely not great from a security perspective but for the average person it seems unlikely that they're worse off from having it. Maybe we can start phasing that out now that common clients have integrated WebAuthn support (e.g. Apple's FaceID/TouchID for the web) but if you have to support the general public you probably have a different threat model than a more targeted audience.
My login.gov has my two Security Keys plus my phone (a Pixel 2, via WebAuthn) as possible second factors. You can indeed choose TOTP, or use a Government ID (a few million people have Federal jobs with IDs) and if you must yes you can use SMS
So if you need better security, just don't choose the weaker options.
Suddenly that goes from "automated attack launched by a school kid on the far side of an ocean" to "Government black bag job", and it's enough that most people should sleep soundly.
Also, the other benefit of Security Keys as an option is that we can teach users that their Security Key is safe, because it can't be phished. That exercise where you try to train users to check they're on the right domain and realistically you know adversaries will confuse or terrify them into skipping that step? No need with Security Keys, that's the Web Browser's job and the browser isn't confused or terrified, it's just calling memcmp() as it does many times every page load.
I'm still waiting for feds to implement the guidance from https://pages.nist.gov/800-63-3/sp800-63-3.html from 2017 and 2020 about NOT rotating passwords arbitrarily, and NOT requiring undue amount of special symbols.
Even when I've asked IT, I get crickets and more bullshit password rotation.
Where I work (MS infra & service) 90 password changes show no sign of going away.
A pretty convincing argument that the folks involved are more into theatre than practice.
Luckily that is starting to back off, but it has NOT trickled down everywhere by a long shot.
They still haven't fixed this after decades of effort:
https://www.washingtonpost.com/sf/national/2014/03/22/sinkho...
It would be great if they could do something to prevent things like the OPM data breach, but check out this questioning of the principles involved in that debacle:
https://www.youtube.com/watch?v=AK-zEGjxuAA
Does this give anyone any hope that there is competence to deal with this?
I know someone is going to say, "but we have to start somewhere". Sure. But, keep in mind there doesn't appear to be any pilot program where they've proven they can do this in even a single place. And now they're creating a blanket executive order to do something across the whole federal government?
I read the federal government’s Zero-Trust Memo so you don’t have to - https://news.ycombinator.com/item?id=30101411 - Jan 2022 (352 comments)
That's the one!
> MFA should be integrated at the application layer, such as through an enterprise identity service as described above, rather than through network authentication (e.g., a virtual private network).
They comment with:
> While it’s no surprise seeing multi-factor authentication being a requirement, what stands out is that doing so at the network level is explicitly disallowed. Meaning all VPNs and tunnels – nextGen or not – do not meet the standard.
Which of course is completely untrue. You still want VPNs to connect sites or even client/network and any security expert worth their salt will surely recommend you to have layered security. Opening up your internal network to the internet and rely on every app to do security correctly is a ridiculously bad strategy.
I don't know or care who pomerium is or what they sell, but this sort of anti-advice severely diminishes their trustworthiness.
Having done FedRAMP and also running Tor servers, I'm also at the conclusion that using IP in any sort of rules is a bad practice. You should be identifying/verifying/authorizing/logging the connection regardless how it came to you. Consistently doing that means you now can control user access at a chokepoint (usually an IdP or similar token passing credentialled login).
If you have a malicious entry, you do not want lateral transfer to end up hitting less secure stuff on the network because of implicit network trust. Zero-Trust is about removing those implicit things. And if everything has service-level IdP token checks, not even replay attacks will work. As a malicious hacker, you're stuck there. Less scope of damage.
Same with Tor. For anyone running a Tor client or operating a Onionserver, all connections are actually an IPv6 overlay with routers that only support TCP (not UDP/ICMP). And since those absolutely will be randomized every 10m on average, you absolutely must verify the connection AND NOT the source/destination.
> Users should log into applications, rather than networks, and enterprise applications should eventually be able to be used over the public internet.
Second with regards to this statement:
> Opening up your internal network to the internet and rely on every app to do security correctly is a ridiculously bad strategy.
That's precisely what zero trust networking is. Ala Google's BeyondCorp:
> Virtually every company today uses firewalls to enforce perimeter security. However, this security model is problematic because, when that perimeter is breached, an attacker has relatively easy access to a company’s privileged intranet. As companies adopt mobile and cloud technologies, the perimeter is becoming increasingly difficult to enforce. Google is taking a different approach to network security. We are removing the requirement for a privileged intranet and moving our corporate applications to the Internet.
(https://storage.googleapis.com/pub-tools-public-publication-...)
Maybe they're wrong about all this, but it's not anti-advice. It's a legitimate security model being pursued by many different companies.
Google doesn't do what you suggest and I'll throw in another large security-aware company as well, known for their privacy-conscious phones. They protect the perimeter as well as the inside. As does any military organization. Stop spreading misinformation.
So as I said previously, for most organizations, it would be crazy to the point of lunacy of their infosec team to allow the internet access to internal corporate systems and just rely on those to have been individually secured.
I would dare to say that nobody does this or I'll ask you to please give me the IP address of Google's internal DVCS server.
The problem with VPNs is that enterprises have used them for decades as a crutch, extending their perimeter model out so that instead of a small SPOF, they have a gigantic, ever-changing SPOF. "ZTN-think" pushes this basic idea way past usefulness, to the point where all network controls are somehow suspicious. Which is crazy; BeyondCorp fundamentally relies on network access controls as well as application access controls, like every other modern network design. They're just different controls.
People claim they are deprecated. I don’t think VPNs, proxies and bastions will be deprecated. I don’t think we will access so many random applications directly over internet without segmentation.