First Take on the Cybersecurity Executive Order

Yesterday, on May 12^th, President Biden issued the “Executive Order (EO) on Improving the Nation’s Cybersecurity.” Given that the Order features 11 sections that include both policy and general provisions among others, its 8,080 words is arguably the equivalent of multiple EOs. Such an effort is, no doubt, purposeful by the President—this is significant, and will certainly impact the security worlds of both the government itself and those companies that provide it with software and services.

This Order will be analyzed, discussed, and debated by many, with the very detailed recommendations surely influencing programs or even becoming new standards in the near future. The early talking points can be found on the White House website, but rather than repeat them, below is some more particular commentary on the sections with important points that I feel could have an impact on Schellman’s software and cloud services client base.

The Order is actually chock full of these important points—as I read this for the first time last night, every few paragraphs, my eyes lit up constantly as I came across more and more new information that has the potential to be game-changing. All I could do was marvel at all these new “nuggets of gold.”

Section 3 – Modernizing Federal Government Cybersecurity

Jumping right to said gold, Section 3 of the EO focuses quite a bit on FedRAMP—it’s mentioned eight times—but in relation, this content also addresses Zero Trust, cloud services, and encryption.

A term oft used in the security world, “Zero Trust” can be used in different contexts but gets a new definition within this Order, which includes these key points:

The Zero Trust security model eliminates implicit trust in any one element, node, or service and instead requires continuous verification of the operational picture via real-time information from multiple sources to determine access and other system responses. (Section 10 (Definitions), Subsection (k))

…

The Zero Trust Architecture security model assumes that a breach is inevitable or has likely already occurred, so it constantly limits access to only what is needed and looks for anomalous or malicious activity. (Section 10 (Definitions), Subsection (k))

This interpretation of Zero Trust assumes failure will occur and thusly requires layers of defenses to minimize the impact.

Back in Section 3, the content expounds upon this, addressing how the Cybersecurity and Infrastructure Security Agency (CISA) will work with FedRAMP on the modernization strategy—according to the Order, Agencies should update their strategies regarding moving IT resources to secure cloud services by July of this year. To me, this seems to shift energy back into the Cloud First and Cloud Smart initiatives and should drive more use of cloud services by Agencies, especially since August will see FedRAMP and CISA both publish their plans for improvement of use and awareness, as well as guidance and reference architectures for cloud services and Zero Trust.

Moreover, Subsection (f)—a section jam-packed with nuggets—speaks specifically to FedRAMP modernization. As a leading 3PAO, Schellman has seen firsthand that many of the addressed components in this subsection are already—and have been—underway at the FedRAMP PMO. Of the items specifically mentioned, training (i) and communication (ii) have been a priority for some time, but one can appreciate how the Order specifies a comms approach similar to those “where is my pizza” apps—i.e., notifications at each stage, only these won’t track food and instead will facilitate real time visibility into a cloud providers’ progress.

 Much of the rest of Subsection (f) speaks to automation and the “digitizing and streamlining documentation that vendors are required to complete, including through online accessibility and pre-populated forms.” Back in 2019, I had the privilege of testifying before the House Oversight Committee on FedRAMP, and one of the points I made regarded the difficulty in assessing 300-400+ controls, conducting scans, and completing penetration testing—all of the data for which had to be communicated in large spreadsheets and Word documents. Back in 2019, an OSCAL initiative by NIST and FedRAMP aimed at supporting a modernized overhaul for this system, and it seems this Executive Order strives to boost that progress.

Subsection (f)(v) also sets the goal of “identifying relevant compliance frameworks, mapping those frameworks onto requirements in the FedRAMP authorization process, and allowing those frameworks to be used as a substitute for the relevant portion of the authorization process, as appropriate.” All of that to say, this EO supports the infamous “R word”—reciprocity.

As a firm that assesses against all the major compliance standards, this is a welcome concept for Schellman. There is absolutely overlap between the requirements of globally adopted standards from NIST 800-53 to ISO 27001, albeit often at different levels of granularity. We believe that where the overlaps exist lies within specific control implementations and mappings and that, with qualifications and assumptions around shared user responsibilities, there can be more leverage for every company that services both commercial and government clients and suffers from audit fatigue.    

The final big topic of Section 3, encryption and its relation to FedRAMP are addressed thusly:

(d) Within 180 days of the date of this order, agencies shall adopt multi-factor authentication and encryption for data at rest and in transit, to the maximum extent consistent with Federal records laws and other applicable laws.

An ambitious ask, the Order gives agencies just under five months to implement multi-factor authentication (MFA) and encryption of data in both rest and transit. Though multi-factor authentication has slowly become the norm in banking, it remains a hard requirement for FedRAMP today. And while the use of MFA absolutely stops a very large percentage of the types of attacks used by hackers, the implementation across applications, networks, and other systems is not easy—especially not for anyone who begins today with a hard deadline of November 8^th.

Despite that, anyone who has been part of FedRAMP reviews over the past 12 to 18 months has already seen an ongoing, increased push for 100% encryption of data, at least in transit—that includes even inside an otherwise inaccessible boundary (i.e., an internal network or segment). So, much of the industry will have already been somewhat following a bit of this encryption guidance, as well as the model of Zero Trust newly noted in the Order, which states that if you assume that boundary protection fails at some point, you must encrypt the data where it stores and where it travels.

Section 4 – Enhancing Software Supply Chain Security

Clearly, Section 3 of the President’s Order provides plenty to dig into, but there is actually much more to explore within the full text, including Section 4, which is actually also summed up in the press release statement that accompanied the entire Order: “It creates a pilot program to create an “energy star” type of label so the government – and the public at large – can quickly determine whether software was developed securely.” Though I suspect many won’t get that Energy Star reference, the program concept outlined here remains familiar.

Deeper in the text of Section 4 are the particulars—while FedRAMP becomes the requirement for cloud services used by the government, we will also now have a program where software and software development processes must be approved, authorized, or certified—how they will define all of that remains to be determined.

So, what does this mean? This discussion is ongoing—by June, NIST will solicit input from the community on this topic, and Schellman welcomes the opportunity to participate! While the deadline to publish initial guidance is November 8^th, the presumption is that all this will go into effect no later than a year from now, with a rollout period to be defined. But perhaps most important in Section 4 right now are the numerous references to the Office of Management and Budget (OMB), as well as the Federal Acquisition Regulation (FAR) and the Defense Federal Acquisition Regulation Supplement (DFARS), which make it clear that if the government spends money on software, the software companies will contractually have to meet these new standards.

This is a pattern we have previously seen in other areas—the Payment Card Industry also recognized the need to secure software, not just companies or services, with its Software Security Framework initiative. Regarding FedRAMP, this new program will not only assess related software but the literal processes by which companies develop it and whether this is done in a secure manner. Either way, expect more emphasis on secure software development, more code review, static, and dynamic testing of applications as part of this program.

Other Sections

Among the rest of the EO, a few other notable topics we aim to delve more into in the future include:

• The multiple references throughout the EO that speak to improving incident response capabilities, including the Cyber Safety Review Board (Section 5) and Standardizing the Federal Government’s Playbook for Responding to Cybersecurity Vulnerabilities and Incidents (Section 6). Notably, the EO blends incident response with vulnerability response—this makes sense, since in today’s environment, a vulnerability can have as much of an impact on an organization’s reputation as an actual incident.
• Sections 7 and 8, which address event and incident detection and investigation capabilities, starting with the requirement that Agencies and the service providers that support them use a more robust and immutable means of collecting the necessary logs needed for investigation.  

“(b) … Such recommendations shall include the types of logs to be maintained, the time periods to retain the logs and other relevant data, the time periods for agencies to enable recommended logging and security requirements, and how to protect logs. Logs shall be protected by cryptographic methods to ensure integrity once collected and periodically verified against the hashes throughout their retention. Data shall be retained in a manner consistent with all applicable privacy laws and regulations.”

We have also seen this before—again with PCI DSS, which itself features an entire section in requirement 10 that is dedicated to log collection, management, and review.

What Wasn’t in There?

Given the breadth and depth of this Executive Order, there was certainly not a lot missing compared to previous attempts at this. However, still absent was the normal mention of the need for security programs, policies, and procedures, but that’s no problem, as FISMA and NIST have no lack of such requirements.

What was curious was the absence of even a single, specific reference to the Cybersecurity Maturity Model Certification (CMMC) program, especially given the extensive presence and clear involvement in developing the Order in terms of FedRAMP. As the CMMC is a new program designed to secure the suppliers of services to the Defense Industrial Base, one would think that the coverage of this Order and its references to DFARS contractual requirements would also affect defense contractors in terms of CMMC as well. But perhaps its absence can be attributed to the fact that CMMC remains new—the development and adoption of its standards is still being worked through by certification bodies and programs. My personal hope is that politics isn’t at play here, and the Department of Defense will soon have an active role alongside CISA, DHS, and FedRAMP—but all that remains to be seen.

The Key Takeaway

All in all, this new Order from the President is a lot to digest, and it will surely keep the experts talking about the details and nuances in the coming days and months.

Still, the key takeaway for Schellman clients is that though the President’s words in any Executive Order usually mostly impact the actions of government agencies, in this particular EO, the phrase “service provider” does come up 15 times, while “vendor” is mentioned five times. Therefore, it can be inferred that if an organization seeks to provide software or cloud services to the government, these new rules will impact your ability to sell to arguably the largest technology markets on the planet, making them worth looking into.

For good measure, Schellman will also continue to provide updates to these respective programs through informative videos, our blog, and other content.