"One of the most significant sections of the executive order is the requirement for all federal agencies to adopt multi-factor authentication within six months (180 days) of the order being signed."
I will eat my hat if this happens in that timeframe.
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.
In particular Login.gov can do WebAuthn, so a vaguely recent Yubikey or other Security Key product, a modern iPhone, or the nicer Android phones with fingerprint readers, all work and deliver unphishable¹, zero correlation² authentication.
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.
How is it affiliated with TSA Precheck? I'm quite sure I've never directly used login.gov for anything related to my TSA Precheck, and I don't have a password associated with it either.
This is the oldest compliance trick in the book. To adopt is easy. To implement is difficult. This is why some regulations specify “adopt and _implement_”.
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.
NASA has had 2FA for over a decade for internal users, RSA dongles initially and PIV cards now (there was something about JPL and the fingerprinting requirement, though). They have taken steps recently to get rid of passwords entirely, although legacy systems are a problem (like OpenShift).
The down side is that accessing a server requires a patched Putty from Centrify and about 27 configuration steps that are documented nowhere.
OpenShift isn't a legacy system, it's a commercially supported distribution of Kubernetes. That's about as close to "new hotness" as you're going to find in government.
Unless you mean they're stuck on a version from 5+ years ago, which is believable, but hardly OpenShift's fault.
In 2001 I worked on a project for some of the federal agencies that used remote biometrics for authentication in addition to password use. I'm not sure if it was safe from replay attacks, but still. It wasn't that the feds didn't know how to make things secure, it's just that the workers in the civilian side of the government didn't really understand the threats and didn't prioritize security.
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.
Will this make SMS-based MfA more vulnerable if the government chooses to adopt / implement using SMS? There are other options but if the EO only says MFA ..
I think criminals gaining access to my bank account is far more lucrative for them than gaining access to my social security account so I don't think it makes the problem particularly worse than it already is.
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.
dear god, please no. So tired of the entities I have to deal with who only offer SMS for 2FA and not email. I tried to send some of them a stash of links about how insecure SMS is for this purpose, to no avail.
That does seem far fetch considering how slow they move, but I wonder how many agencies have something like that already. Back when I worked as a government contractor I had to get a CAC card and use that with a card reader to sign into a computer when I had to visit a military base. That was about 2 decades ago (man that makes me feel old).
It's hit and miss. Many civilian side agencies have PIV (the civilian version of CAC) cards for login to laptop/desktops, but not mobile phones/tablets. A few agencies have apps are PIV/CAC enabled or have any MFA, but usually one user/pass login. So you see situations where smartcards are used to login to a device, then a username/password to connect to webapps.
The nightmares that normally come with govt stuff in this space I'm seeing.
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.
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.
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.
>3) Hard lockouts (rather than more nuanced rate limiting etc) requiring password resets.
>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.
The challenge with this EO and all aspirational security pronouncements is their focus on outcomes while avoiding implementation details, trade offs and resources.
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.
The order covers exactly what it should: these are the outcomes we want, make them happen. It's silly to assert that an executive order from the president would lay out how all the different agencies in the government will adopt Zero Trust, MFA, or other things. This is the kick in the pants, now the agencies are on the hook for doing them. I appreciate your point that it will be hard to accomplish, but that doesn't really let them off the hook I don't think.
> The order covers exactly what it should: these are the outcomes we want, make them happen.
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".
Docker does not allow specifying a docker container by the SHA-256 digest of its contents. I hope the US Federal Government will get them to finally add that crucial security feature.
SPDX (https://spdx.dev) is an open standard for describing software bill of material information. A number of open source projects, like the Linux kernel, have already adopted its conventions (e.g. for marking the license in the files), so that information can be automatically be processed.
Within the cloud native and container space, there is work being done on how to implement this (SBoM, Signing etc). It will obviously be tricky to get right, but there are groups looking at it :)
I wonder what governments will be using for zero trust architecture? There are a number of companies competing in this space, one is strongDM [1] who I currently work for. I am curious if they are planning to work with existing companies in this space, or pay billions of dollars to build custom software to do this.
Readit News
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.
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.
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.
>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.
[1] https://strongdm.com
(And sometimes share them with our Israeli friends for hunting down Saudi journalists.)