As President Biden’s personal belongings were being packed by his staff, marking the end of his term, the White House released a long-anticipated and long overdue Executive Order (E.O.) on Strengthening and Promoting Innovation in the Nation’s Cybersecurity.
Today, virtually all sectors of the United States economy are under continuous attack from nation states, for-profit criminal organizations and independent hackers, with the biggest bullseye on the United States government. Last summer, I reviewed a draft of the E.O. for one of our federal clients. The White House never released the draft, which was narrowly focused on combatting fraud in public benefits programs, a topic President Biden covered during his 2022 State of the Union Address. While a worthy endeavor, the federal government needs to approach combatting fraud and identity theft holistically.
While this E.O. is refreshingly comprehensive, I have two questions: Why did it take so long, and how long will it last?
Since cybercriminals could care less whether one votes blue or red, cybersecurity is not viewed as a partisan issue. It remains to be seen whether Trump will repeal it and what future replacements will be if he does.
Section 2: Transparency & Security in Third-Party Software Supply Chains
Software development flaws and unpatched systems are a common root of security incidents. To address this within the federal government, E.O. 14028, “Improving the Nation’s Cybersecurity,” released in May 2021, required software developers to self-attest that they conform with secure software development practices. Per that, E.O. and subsequent Office of Management and Budget (OMB) memoranda, the Cybersecurity and Infrastructure Security Agency (CISA) developed a Secure Software Development Attestation Form for contractors providing software to the federal government to complete. The intent is “to provide the Federal Government assurances that software used by agencies is securely developed.”
Having worked for an auditor in a prior life, I find self-attestation to be nice, but it provides no evidence that you are doing what you are supposed to. The new E.O. ups the ante in contracts requiring software developers to submit machine-readable secure software development attestations to CISA along with high-level artifacts to validate their attestations along with a list of their federal agency software customers. High-level artifacts are policy and procedure documents, not source code or intellectual property.
A key point is requiring machine-readable attestations, something we’ll be seeing in more and more federal requirements and possibly in state-level programs. This follows July 2024’s OMB M-24-15 – Modernizing the Federal Risk and Authorization Management Program (FedRAMP), which tasks the FedRAMP PMO, OMB, National Institute of Standards and Technology (NIST), and CISA, and private-sector governance, risk, and compliance (GRC) tool providers to collaborate to provide for the submission of security assessment artifacts and continuous monitoring information to the FedRAMP PMO using NIST’s Open Secure Control Assessment Language (OSCAL).
While the E.O. does not specify OSCAL, I will be surprised if the government doesn’t eat its own dog food, making OSCAL the de facto machine-readable standard. OSCAL enables compliance automation, eliminating redundancy and manual processes while reducing costs, which should be attractive to the Trump administration’s new Department of Government Efficiency (DOGE). With thousands of companies providing software to the federal government, OSCAL will save significant costs and labor hours in the collection and analysis of each submission. Additional information about OSCAL can be found at OSCAL.io, including a version of the NIST Secure Software Development Framework (SSDF), which is available in machine-readable format.
Section 3: Improving the Cybersecurity of Federal Systems
Will this E.O. spur the adoption and usage of FIDO2 authentication? Resembling language in OMB Memos 19-17 and 22-09, the Biden White House mandates phishing-resistant authentication and gives the green light for agencies to use WebAuthn-based authenticators, which include FIDO2 as alternatives to PIV cards and derived PIV credentials. For agencies that have historically taken a PIV-only or PIV-first approach to authentication, the word shall mean “must,” making WebAuthn and FIDO2 on an equal plane with PIV, all capable of meeting NIST’s Authenticator Assurance Level 3 (AAL3) requirements.
Section 5: Solutions to Combat Cybercrime and Fraud
As a proponent of expanding attribute validation services for some time, I was pleased to see this in the E.O. Validating identity evidence and identity attributes from issuing sources and authoritative sources are key requirements in the identity verification process. While credential service providers do an excellent job of determining whether the person is who they claim they are, the root source of the data is the government, as government agencies issue one’s birth certificate, driver’s license, social security number, etc.
The Social Security Administration’s (SSA) electronic Consent Based Verification Service (eCBVS) is one such service, but under law it is only available to the financial sector. While this service is not perfect and is more expensive to the private sector than initially planned, it does aid banks in the Know Your Customer (KYC) process.
Limiting eCBVS to the financial sector has been detrimental to the integrity of the U.S.’s digital identity infrastructure. Opening attribute validation services beyond SSA at the federal level and expanding them to state and local governments is critical to combat cybercrime and identity theft. The Department of Defense (DoD), Veterans Affairs (VA), Internal Revenue Service (IRS), and Health and Human Services (HHS) all serve millions of Americans and should also open their data to combat identity theft.
In addition, attribute verification services need to be made available to not only Login.gov but all credential service providers that have been awarded trust marks by the Kantara Initiative in conformance with NIST 800-63-3 and are also on the General Services Administration’s (GSA) Multiple Award Schedule SIN 541519CSP, Credential Service Providers (CSP).
With AI technologies readily available to fraudsters, overreliance on accepting physical identity documents such as passports, passport cards, and driver’s licenses to present as part of an online identity verification process can be ripe with fraud if credential service providers don’t deploy the latest technologies to combat it.
What is not included in the E.O. is requiring information sharing between credential service providers contracted by federal agencies to perform identity verification services. This should apply to government-owned, Login.gov, and commercial CSPs. This is a gaping hole in overall security. Per NIST, “Each CSP should maintain data that is or could be used to detect multiple fraudulent enrollment attempts by a single applicant.” While should is not shall, agencies today can make fraud data a requirement in their contract. Should a fraudster attempt to onboard via Login.gov and then attempt to onboard via a commercial CSP such as 1Kosmos, Jakobsen ID, or ID.me, there is no information sharing today. Instead of facing threats in isolation, CSPs should leverage each other’s knowledge and experiences to become more resilient.
On the positive side, the E.O. “strongly encourages” the acceptance of digital identity documents, namely mobile driver licenses (mDLs), to access public benefits programs that require identity verification while supporting the principles of privacy, data minimization, and interoperability.
To increase the adoption and issuance of mDLs by states, the E.O. alludes to possible grants to be made available to assist states tasking OMB, National Safety Council (NSC), and other agencies with grant-making authority to put their heads together to determine potential funding. Most importantly, privacy protection is highlighted as it relates to digital identity documents that prohibit surveillance and tracking when and where they are presented. Furthermore, when given, data minimization shall be used.
Section 7: Aligning Policy to Practice
Within three years, OMB is to update Circular A-130 to address critical risks and adapt modern practices and architectures across federal information systems and networks. One call-out is to make the Circular less technically prescriptive as to promote the adoption of evolving cybersecurity best practices across federal systems and to include migration to zero trust architectures and implementation of critical elements such as endpoint detection and response (EDR) capabilities, encryption, network segmentation, and phishing-resistant multi-factor authentication (MFA).
This point is refreshing! In my experience, agencies err on the side of caution to comply with an Executive Branch policy that may be a decade old. Regarding authentication, agencies refer to 2004’s HSPD-12 to champion a PIV-only or PIV-first approach, while modern technologies like FIDO2 security keys authentication solutions may also meet NIST’s requirements to achieve AAL3.
Conclusion
The E.O. is comprehensive and will hopefully be embraced by the new Administration. If it is rescinded, I expect a similar version to be published later this year.
