I Read the Entire Cybersecurity Executive Order; Here's What You Need to Know
lastweekasavciso.substack.com
lastweekasavciso.substack.com
I will eat my hat if this happens in that timeframe.
Login.gov (a product of USDS and 18F @ GSA) is positioned to meet these identity provider needs.
https://www.login.gov/help/get-started/authentication-option... (2FA support for all users + PIV/CAC support for Fed Gov workers)
https://developers.login.gov/ (developer resources)
Skepticism is warranted as 6 USC 1523: Federal cybersecurity requirements [1] has required a lot of what the EO is calling for for almost half a decade, but the tooling exists and 82 agency applications/systems (as of October 2020) are already leveraging this identity provider. Appropriations ($$$) for this identity integration work seems the challenge, as implementation is straightforward.
Sidenote: You can now login to your Social Security Administration account with Login.gov [2] (under "Other Sign In Options"). If you've applied for TSA Precheck or Global Entry, you've been using Login.gov for some time.
[1] https://uscode.house.gov/view.xhtml?req=granuleid:USC-prelim...
[2] https://secure.ssa.gov/RIL/SiView.action
(disclosure: no affiliation with any federal government agency or office, not a fed gov employee or contractor currently)
1) The Domain Name "login.gov" is inherently associated with these credentials, your Security Key hasn't the faintest idea how to use them on another site even if you yourself are completely fooled and believe you're on Login.gov
2) Even if the US government, your key manufacturer and Facebook conspire together to try to figure it out, there's no way to take their authentication data and correlate that Facebook user mikey-the-shoe is US Login.gov user Michael Shoemaker of New York based on the Security Key used on both sites. It seems like a good guess of course, but WebAuthn deliberately doesn't confirm this.
> The Cybersecurity and Infrastructure Security Agency will get $650 million for cybersecurity risk mitigation. The agency has been leading the federal government’s investigation into the SolarWinds hack that breached several federal agencies.
> Also included in the relief funding is $200 million for the U.S. Digital Service, a technology team based within the Executive Office of the President. The General Services Administration will receive two appropriations through the COVID Relief Act: $1 billion for the Technology Modernization Fund and $150 million for its Federal Citizen Services Fund. The citizen services fund enables public access and engagement with government programs through a variety of operational programs and public-facing products, and supports the implementation of emerging technologies in agency-facing programs.
[1] https://www.nextgov.com/cio-briefing/2021/03/covid-relief-bi...
Interestingly enough, the TSA Jobs portal does use Login.gov. [3]
[1] https://login.gov/help/specific-agencies/trusted-traveler-pr...
The process for establishing identity for login.gov was frighteningly easy. It required something like my Global Entry ID and my full name only, and then it automatically connected with other details about me.
The takeaway for me is to go claim my login.gov ID (if possible) before someone else does.
We adopted multi factor and now we’re in the process of rolling it out. At the moment Ted is our only user. But we aren’t not compliant.
The down side is that accessing a server requires a patched Putty from Centrify and about 27 configuration steps that are documented nowhere.
Unless you mean they're stuck on a version from 5+ years ago, which is believable, but hardly OpenShift's fault.
Edit: Not to say everywhere in the non-civilian side of the government is secure. It isn't. Just that there are pockets of it that are better hardened that we could just wholesale copy.
But besides that, the federal government already has an SSO provider that supports smart cards, U2F, and TOTP. I suspect many agencies will choose to adopt that rather than trying to roll their own SMS auth.
The important part of the EO is the section 3.d.i, which says that every 60 days, until MFA is fully adopted, the agencies will report to DHS their plan and progress for implementing MFA. So basically, they can take longer then 180 days, but they need to be transparent about their plan and the roadblocks they are hitting in doing so.
1) Long passwords - govt loves these - think 12 characters or longer. Think "EhKx~9RDmPMCW7"
2) Failures to specify allowable characters or blocked characters - very annoying.
3) Hard lockouts (rather than more nuanced rate limiting etc) requiring password resets.
4) Password reset options are weak and not protected.
The backdoor is usually the password reset option.
Ie, agency will do crazy long password + SMS code to login, but you can then reset your password with just SMS. So the long passwords are often just for show.
They often also don't time delay anything. So they'll do things like immediate reset. For high value apps you should have a 4 - 24 hour delay on reset to allow legit user to react.
They'll also often not have good ways to report bad password reset attempts other than via phone which goes no where.
They also often actively block password managers and cutting and pasting passwords. So annoying.
The IRS is currently requiring 90 day password rotations as well which are a nightmare. Coupled with hard account lockouts you have another nightmare.
The list goes on. For the millions to billions they spend you really wonder who is giving them advice.
https://pages.nist.gov/800-63-FAQ/#q-b05
It says: SP 800-63B Section 5.1.1.2 paragraph 9 states: “Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically). However, verifiers SHALL force a change if there is evidence of compromise of the authenticator.” Users tend to choose weaker memorized secrets when they know that they will have to change them in the near future. When those changes do occur, they often select a secret that is similar to their old memorized secret by applying a set of common transformations such as increasing a number in the password. This practice provides a false sense of security if any of the previous secrets has been compromised since attackers can apply these same common transformations. But if there is evidence that the memorized secret has been compromised, such as by a breach of the verifier’s hashed password database or observed fraudulent activity, subscribers should be required to change their memorized secrets. However, this event-based change should occur rarely, so that they are less motivated to choose a weak secret with the knowledge that it will only be used for a limited period of time.
What a total lie.
Do people actually work in / with govt who makes these statements? I just looked up a the current IRS checklist we've been forced to comply with which has driven lots of downline changes to all systems touching this system.
"Control access to sensitive information by requiring employees to use “strong” passwords that *must be changed on a regular basis.". This is not an option, and regular has been defined as 90 days. A previous job (yes, I'm totally aware of NIST guidance) they forced a move to 30 days. 30 days with 12 character passwords is a joke and they blocked copy and paste. EVERY password was on sticky notes by computers after that. They are $100M system implementations.
My point remains, the implementations of these things in the govt space is often the stuff of nightmares, and I have no idea who they are listening to for the money they spend.
Just doing it annually would be a big relief in some cases. 30 day rotations with no copy / paste is a nightmare.
We are way down the stack of course but just a basic approach like
1) Allow for cut and paste passwords
2) Reduce rotation requirements (even annually would be better).
3) 2FA if logging in from a new device (with no SMS)
Would I'm sure get tons of protection without the insanity we have now. Some folks are asking for 16 character passwords but allow reset with a text message or email? Or a phone call to an overwhelmed help desk who barely verifies anything.
That said, I've seen worse. I once tried to go as high as I could on the chain to get something even worse fixed (we were required to hand out a form for a program that had been out of existence for 5 years so form did nothing). They would not budge, I even got legal in on it.
Because someone somewhere had ordered the form be distributed, the order had not been revoked, we still had to hand it out even though everyone agreed the form and program were no longer in existence. After I kept on escalating they threatened to prosecute or violate contract if form was not distributed an I kept pursuing the issue. So thousands of people filled out a form that just went no where.
>4) Password reset options are weak and not protected.
These are pretty much impossible to both satisfy. At the end of the day you need to think of computer accounts as ephemeral or have some out of band access to the administrative staff.
County Password Inspector!
It’s as if nobody asked WHY zero trust and MFA are not already pervasive in the Federal Government. Legacy systems are going to be incredibly difficult and expensive to rearchitect for ZTA. Despite HSPD-12 (CAC and PIV authentication and access) being over a decade old, some parts of government refuse to use a smart card plus password for MFA. I wonder why? It is not simply because “government doesn’t understand computers.” The core issue is leadership. There is no benefit for executives to point out the constraints, like usability, cost or talent, that ensure that good ideas in principle will be adopted incorrectly and incompletely.
That said, there is some stuff worth cheering. The CSRB is much overdue and the elevation in status of cybersecurity as a critical function is directionally correct.
Much of whether these aspirations will be possible hinges on legislative budget decisions and ultimately sweeping reform of the government hiring system.
No, it doesn't. "Zero-trust architecture" is not an outcome - it's an means to the actual outcome, which is "lack of breached systems/successful cyberattacks".
https://www.whitehouse.gov/briefing-room/presidential-action...
On Page 8 look at the Corpus tag.
https://github.com/cncf/tag-security/ is a good place to go for more info.
(And sometimes share them with our Israeli friends for hunting down Saudi journalists.)
We need more discussion of its costs, what it specifically provides, and its limitations. Can anyone with some expertise and experience comment?
If "zero trust" was truer to its name, everyone would be applying the type of engineering techniques[2][3] used to design "critical systems"[4]. However this probably wouldn't be desirable for the IT security sector as it'd show that many IT security products and measures are in fact detrimental to the security of the systems involved. Detriments including:
1. Increasing complexity of the system design and the impact this has on the ability to configure and maintain everything securely (think 5 years later with a new team of people looking after it who don't fully understand how it all works changing configuration).
2. Introduction of new centralised points of failure in the form of security systems having elevated access to an entire network. The recent example of this detriment is SolarWinds Orion.
3. Increasing prevalence of shadow IT as a result of end users fed up with difficulty obtaining access to information or resources they need to do their job.
4. Chilling effect on IT system development within the organisation as the security bureaucracy becomes too difficult to overcome when delivering IT system upgrades. Legacy systems in an insecure state remain connected to the network forever because it costs too much to make even small incremental improvements as the security bureaucracy will demand a complete overhaul or slow down upgrade projects.
[1] https://www.youtube.com/watch?v=NWQgh42O8WU
[2] https://en.wikipedia.org/wiki/Failure_mode_and_effects_analy...
https://en.wikipedia.org/wiki/Executive_order_(disambiguatio...
This seems like it will translate into "significant productivity losses due to security taking away access that workers use to accomplish their jobs more effectively", and possibly taking capabilities away that workers really do need to get their jobs done and requiring a gate-keeper to do them instead.
You used to get root on your development box? Tough luck - now you're developing in a thin client connecting to a VM on a remote machine that you don't get administrative privileges on, and if you want to install a new package, you have to submit a JIRA ticket. But it's ok, because you have the "bare minimum you need to perform your job".
Source: have seen this happen at least once before.
I think gross negligence should be treated similarly to insider trading, HIPAA violations, etc. There should be fines and jail time.
(link from https://news.ycombinator.com/item?id=27530920)
Do you remember back when there were no weapons of mass destruction and the "Intelligence Community", the media, and other agents of reputable institutions all went along with the lie so that unrelated geopolitical objectives could be satisfied and defense contractors would make insane amounts of money? It's like that.
so what happens to Executives who do not support this?
Nothing, in my experience.