Improving the Nation’s Cybersecurity
Summary and opinions on President Biden’s Executive Order (EO) 14028
Table of contents
- Introduction
- Summary
- Section 1. Policy
- Section 2. Removing Barriers to Sharing Threat Information – Summary
- Section 3. Modernizing Federal Government Cybersecurity – Summary
- Zero Trust Architecture (ZTA)
- Movement to secure cloud services
- Section 4. Enhancing Software Supply Chain Security – Summary
- Section 5. Establishing a Cyber Safety Review Board – Summary
- Section 6. Standardizing the Federal Government’s Playbook for Responding to Cybersecurity Vulnerabilities and Incidents – Summary
- Section 7. Improving Detection of Cybersecurity Vulnerabilities and Incidents on Federal Government Networks – Summary
- Section 8. Improving the Federal Government’s Investigative and Remediation Capabilities – Summary
- Section 9. National Security Systems – Summary
- Section 10. Definitions – Summary
- Section 11. General Provisions – Summary
- Conclusion
Introduction
On May 12, 2021, President Biden issued Executive Order (EO) 14028. The EO was published into the Federal Register on May 17, 2021 and can be referenced online here:
https://www.federalregister.gov/documents/2021/05/17/2021-10460/improving-the-nationscybersecurity
This document is a summary interpretation of the EO and our unbiased opinion, section by section.
Summary
There are eleven sections in the EO, each with a subset of topics, deadlines, and responsible parties:
- Section 1. Policy
- Section 2. Removing Barriers to Sharing Threat Information
- Section 3. Modernizing Federal Government Cybersecurity
- Section 4. Enhancing Software Supply Chain Security
- Section 5. Establishing a Cyber Safety Review Board
- Section 6. Standardizing the Federal Government’s Playbook for Responding to Cybersecurity
- Vulnerabilities and Incidents
- Section 7. Improving Detection of Cybersecurity Vulnerabilities and Incidents on Federal
- Government Networks
- Section 8. Improving the Federal Government’s Investigative and Remediation Capabilities
- Section 9. National Security Systems
- Section 10. Definitions
- Section 11. General Provisions
The titles are good indicators of each section’s contents; however, there are some interesting, and maybe concerning “hidden gems” found in the details. Zero Trust Architecture, Endpoint Detection and Response are specifically called out, and these could turn out disastrous if they’re not done right or if they’re done for the wrong reasons. Few would argue that the Federal Government doesn’t need to do a better job protecting its assets. This EO could be exactly what the country needs.
On the other hand, an EO with poorly written requirements and/or ulterior motives could be worse than no EO at all.
If you only read the titles of each section, you might be very supportive of this EO. If you read the details within each section, which we did, you might find some things you don’t feel completely comfortable with. We encourage everyone to read the President’s EO in detail and form your own opinions, then share them with us.
We promise to respect your opinions, and we hope you will reciprocate.
Section 1. Policy – Summary
A standard opening and the Biden Administration’s justification for the EO.
The policy statement is:
It is the policy of my Administration that the prevention, detection, assessment, and remediation of
cyber incidents is a top priority and essential to national and economic security.
The scope of the EO is:
All Federal Information Systems should meet or exceed the standards and requirements for
cybersecurity set forth in and issued pursuant to this order.
Section 1 also contains admissions that the Federal Government must improve “cybersecurity”, must partner with the private sector, must make “bold changes and significant investments”, and must “bring to bear the full scope of its authorities and resources”.
Section 1. Policy – Opinion
Section one sounds good. The right words are used in the right places, and the right justifications are used to support the EO.
There should be little doubt our country needs to do “cybersecurity” better, but we can’t help feeling some level of distrust based on track record and political motivations.
Information security is logical and should never be political.
Maybe our feelings are just run of the mill paranoia, or maybe our feelings are justified by witnessing our Federal Government operate with a less than stellar track record:
- There’s no objection to partnering with the private sector; however, the government has a reputation of only working with the powerful people in the private sector.
- There’s no objection to making “bold changes and significant investments”; however, the government has a reputation of making bold changes with ulterior motives and making HUGE investments on bad things.
- Anytime our Federal Government says it “must bring to bear the full scope of its authorities and resources” (or something similar), the hairs rise on the back of our collective necks and we cringe a little.
If the goal is to secure the government (and the country better), then let’s look at the rest of this EO with this lens. Let’s NOT look at this EO with a political or emotional lens.
Section 2. Removing Barriers to Sharing Threat Information – Summary
This section is mostly related to establishing better “cyber incident” reporting between contracted IT and OT service providers and the Federal Government.
Topics covered in this section include:
- Review existing reporting requirements and procedures.
- Recommend updates to the Federal Acquisition Regulation (FAR).
- Update the FAR.
- Enforce IT/OT provider compliance.
- Centralize reporting.
- Provide budget for this section.
The timelines are aggressive, and several deadlines are mentioned, the latest being October 9, 2021.
Section 2. Removing Barriers to Sharing Threat Information – Opinion
One of the best sections in the EO, setting proper expectations for incident information sharing. We’re very interested to see the specific requirements once they’ve been vetted and communicated. The requirements in this section should go a long way toward ensuring incident information is shared properly and promptly between concerned parties. A quick and coordinated response should significantly limit the impact of future incidents.
Section 3. Modernizing Federal Government Cybersecurity – Summary
The main purpose for this section is to force wider adoption of cloud technologies, a Zero Trust Architecture (ZTA), and multi-factor authentication (MFA).
According to this section, the Federal Government must:
- Adopt security best practices.
- Advance toward Zero Trust Architecture
- Accelerate movement to secure cloud services.
- Adopt multi-factor authentication.
- Encrypt data at rest and in transit.
- Centralize and streamline access to cybersecurity data.
- Invest in both technology and personnel to match the modernization goals.
The timelines for the requirements in this section are also aggressive, for instance, the plan to implement a Zero Trust Architecture is due within 60 days (7/11/21).
Section 3. Modernizing Federal Government Cybersecurity – Opinion
This is a weighty section with many requirements, and the timelines are VERY ambitious. On the surface, everything in this section seems good, until we consider reality.
Security best practices are good, adopting multi-factor authentication is good, encrypting data at rest and in transit seems good (although it could disrupt some things), and centralizing and streamlining access should be good depending upon the implementation.
To be blunt, pushing the Zero Trust Architecture (ZTA) on this scale seems premature. There are many steps that could be made towards ZTA without going all the way this quickly. Taking steps is doable and effective but pushing ZTA the way this EO does seems unrealistic and more marketing than substance. Many people in our industry see “ZTA” as marketing on what have always been seen as best practice.
Accelerating movement/migration to the cloud also gives us an uneasy feeling. Is the cloud more secure than on premise? Maybe, but that’s almost like saying Apple is more secure than Linux. It sort of depends, doesn’t it? One could make the argument that the cloud is not inherently more secure, so why are we accelerating the migration to the cloud on this scale? Feels more about money than security, but the EO doesn’t give all the justification either.
Zero Trust Architecture (ZTA)
ZTA is generally good and conceptually sound. Despite all the marketing BS by vendors trying to make a buck (at our expense), ZTA draws upon information security concepts we’ve been preaching for many years; things like default deny, network isolation, least privilege, inventory management, etc. Despite the good things about ZTA, its inclusion in the EO is premature and almost impractical.
ZTA is VERY difficult to implement in large, complex environments. We swear it’s easier and more effective to start over in some/most cases. Here are just some of the challenges with mandating ZTA wholesale like this EO appears to:
- Most people don’t know what a Zero Trust Architecture is.
- We already have a talent shortage problem (allegedly), this is going to take many knowledgeable people to implement.
- ZTA adds complexity, adding a Policy Engine (PE), a Policy Administrator (PA), Policy Enforcement Points (PEP), a Continuous Diagnostics and Mitigation (CDM) system, an industry compliance system, and (a lot) more.
- Deciding which variation of ZTA is the right one is no trivial task. There’s ZTA using enhanced identity governance, ZTA using micro-segmentation, ZTA using network infrastructure and software defined perimeters, device agent/gateway-based deployments, enclave deployments, resource portal-based deployments, device application sandboxing, and various combinations in between. If that’s not enough, there’s variations in trust algorithms too.
- From NIST SP 800-207, “Gaps that Prevent Immediate Move to ZTA”:
- Lack of Common Terms for ZTA Design, Planning, and Procurement
- Perception that ZTA Conflicts with Existing Federal Cybersecurity Policies
- From NIST SP 800-207, “Systemic Gaps that Impact ZTA”:
- Standardization of Interfaces Between Components
- Emerging Standards that Address Overreliance on Proprietary APIs
- From NIST SP 800-207, “Knowledge Gaps in ZTA and Future Areas of Research”:
- Attacker Response to ZTA
- User Experience in a ZTA Environment
- Resilience of ZTA to Enterprise and Network Disruption
- And many, many, many other challenges.
We can’t help but wonder if FCEB agencies and the Federal Government are ready for ZTA? Judging from last year’s FITARA scorecard (See: Figure 1 above), there’s still plenty of work to do on the fundamentals.
Let’s give the benefit of the doubt and just go for it, right? Here’s what we must do to get ZTA going in the Federal Government…
After preparing for the long arduous ZTA journey, step one in the migration “requires an organization to have detailed knowledge of its assets (physical and virtual), subjects (including user privileges), and business processes”. ZTA or not, every organization should have detailed knowledge of their assets.
NIST Special Publication 800-207, “Zero Trust Architecture”
How can you possibly protect the things you don’t know you have?
Start with an inventory of every single piece of hardware (firewalls, routers, switches, server chassis, workstations, laptops, mobile devices, and all other), then an inventory of every single piece of software (operating systems, client/server applications, cloud systems/applications, host applications, databases, and all other), then figure out your where your data is and where it goes (data flows).
Got it? OK, now map your business processes. If you’ve got all that figured out, you might want to consider throwing half of it away. You probably don’t “need” some of it, or you aren’t using it correctly anyway.
Step two, risk assessment and policy development. Step three is deployment, four is operations, then cycle back through continuously.
Vendors LOVE ZTA because it sells things, lots of things. The market is flooded with vendors who claim to sell ZTA solutions, but most of them are not ZTA solutions and most buyers won’t know the difference. Other vendors love ZTA because you’ll probably need software to do some/all of this. At a minimum, you’ll need a public key infrastructure (PKI), ID management system, and a security information and event management (SIEM) system.
All this adds more complexity to the environment, and complexity is the worst enemy of security. We sincerely hope ZTA isn’t in the EO for marketing to increase vendor sales (for companies with close ties).
Movement to secure cloud services
Certainly, cloud service providers like Microsoft, Amazon and others love seeing this in the EO. Sure, there are security benefits in using cloud services, but there are also drawbacks. It all comes down to “how” you use as much (or more than) “what” you use. In our opinion about ZTA (above), we mentioned that you cannot secure the things you don’t know you have. The follow-up is you can’t secure things you can’t control. When you move to the cloud, it’s not that you lose control, it’s that you have less control.
There’s also a concern that you’re giving attackers one (or a few) big juicy target(s) versus distributed ones. So, why accelerate movement to the cloud for better security? We’ll keep the rest of our thoughts to ourselves right now. This doesn’t sit 100% well with us.
Section 4. Enhancing Software Supply Chain Security – Summary
This section of the EO covers topics and requirements to:
- Develop standards, tools, and best practices for secure software development.
- Enforce secure software development practices.
- Define and enforce a “Software Bill of Materials (SBOM)”.
- Define “critical software” and its protection requirements.
- Consumer labeling programs for IoT and software.
This section contains two new topics and concepts that we haven’t seen before; the Software Bill of Materials (SBOM) and the consumer labeling programs.
Section 4. Enhancing Software Supply Chain Security – Opinion
If the requirements in this section are developed and implemented well, they could be great for information security. One of our concerns is (and has been) the insecure methods software developers follow and how we allow this to persist. Secure software development requirements and the transparency mentioned in this section of the EO is very intriguing.
We think the SBOM is a double-edged sword. On one side, it allows consumers (the government, organizations, people, etc.) to know where software comes from, how it’s made, and how to secure it better. On the flip side, this could be great intel for an adversary to build a better attack. We’ll have to see how this fleshes out.
Consumer labeling for IoT devices and software (and hardware) is too long in coming. Granted, many people won’t read the labeling, but for those who do, this is a great move.
All-in-all, there’s a lot of good stuff in this section of the EO. Let’s hope it all gets implemented well.
Section 5. Establishing a Cyber Safety Review Board – Summary
This section outlines requirements for a new “Cyber Safety Review Board”. All the requirements in this section are for the Secretary of Homeland Security and the (yet to be established) Cyber Safety Review Board (“board”).
This section contains high-level information about the board, when the board is convened, how the board is convened, who’s on the board, and what the board needs to do. Most of the responsibilities for the board are related to “cyber incidents”. The board reports directly to the Director of Homeland Security and by proxy, the President.
Section 5. Establishing a Cyber Safety Review Board – Opinion
There’s not enough detail to know what the board will do exactly. There is no charter or other detail provided; however, one of the board’s responsibilities is to create a charter. There is mention of membership, which we thought was interesting:
- Federal officials.
- Representatives of the Department of Defense
- Representatives of the Department of Justice
- Representatives of CISA
- Representatives of the NSA
- Representatives of the FBI
- Representatives from private-sector entities and/or “appropriate” private-sector cybersecurity or software suppliers as determined by the Secretary of Homeland Security.
Seems like the right government agencies are represented. We’ll have to see what the “appropriate” private-sector members will be. Let’s hope there’s no pay to play here!
Section 6. Standardizing the Federal Government’s Playbook for Responding to Cybersecurity
Vulnerabilities and Incidents – Summary
This section is about the creation of a standard set of cybersecurity and incident response procedures (or “playbook”).
The playbook:
- Will Incorporate all appropriate NIST standards.
- Be used by all Federal Civilian Executive Branch (FCEB) Agencies.
- Will articulate progress and completion through all phases of an incident response.
- Will allow flexibility so it may be used in support of various response activities.
- Establishes a requirement that the Director of CISA reviews and validates FCEB Agencies’ incident response and remediation results upon an agency’s completion of its incident response.
- Defines key terms and use such terms consistently with any statutory definitions.
Essentially, one “cyber incident” response plan to rule them all.
Section 6. Standardizing the Federal Government’s Playbook for Responding to Cybersecurity
Vulnerabilities and Incidents – Opinion
Getting all the FCEB Agencies to work from the same (or similar) playbook seems like a step in the right direction. The government will need to be careful that the playbook is kept confidential if/when it outlines details (which it likely will).
We’re sort of disappointed such a thing didn’t already exist. By the way, are we still sure we’re ready for ZTA?
Section 7. Improving Detection of Cybersecurity Vulnerabilities and Incidents on Federal
Government Networks – Summary
This section puts a lot of power in the hands of the Department of Homeland Security and the Cybersecurity and Infrastructure Security Agency (CISA).
Major topics covered in this section of the EO include:
- The adoption of a Federal Government-wide Endpoint Detection and Response (EDR) initiative.
- CISA threat hunting on FCEB networks and systems without agency authorization.
- Information sharing between the Department of Defense and the Department of Homeland Security
The timeline is aggressive, with EDR requirements mandated to be issued no later than September 9th, 2021.
Section 7. Improving Detection of Cybersecurity Vulnerabilities and Incidents on Federal
Government Networks – Opinion
We’re not against EDR as much as we are against adding more complexity to technology environments, especially when the environment is likely to contain tools that are not used well as it is. Adding more tools to an environment that already uses tools poorly just adds to the insanity.
Maybe the agencies are ready for EDR, but it’s hard to ignore that there’s going to be a HUGE payday for one or more vendors here. Which vendor or vendors? We’ll have to wait and see. Obviously, EDR only does what EDR does and there are some clear differentiators amongst the players in the market.
CISA doing threat hunting on FCEB networks without prior agency authorization should be interesting to watch. There need to be strict rules of engagement and strong oversight for such things. CISA will obviously need to hire many, many new employees, between this and all the other EO requirements. These will be employees that won’t be available to the private sector.
Section 8. Improving the Federal Government’s Investigative and Remediation Capabilities – Summary
The section of the EO is all about network logging, system logging and information sharing requirements.
FCEB Agencies and IT service providers will need to comply with (details TBD) requirements for logging events and retaining other relevant data within an agency’s systems and networks, including:
- Types of logs to be maintained.
- Time periods to retain the logs and other relevant data.
- Time periods for agencies to enable recommended logging and security requirements.
- 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.
- Ensure that, upon request, agencies provide logs to the Secretary of Homeland Security through the Director of CISA and to the FBI, consistent with applicable law.
- Permit agencies to share log information, as needed and appropriate, with other Federal agencies for cyber risks or incidents.
Once the requirements are set, enforcement will follow.
Section 8. Improving the Federal Government’s Investigative and Remediation Capabilities – Opinion
Standardized logging is a good thing, and it too has been a best practice for years. There are numerous sources for good logging configuration guidance, most notably being CIS and the STIGs. It’s important to point out that logs can (and often do) contain sensitive information. Sharing log files and other data can certainly help expedite and improve the quality of an incident response, but they can also be used by attackers to enhance the effectiveness of their attacks.
Share, but don’t.
Section 9. National Security Systems – Summary
Within 60 days, the Secretary of Defense must adopt National Security Systems requirements that are equivalent or exceed the requirements in the EO.
Section 9. National Security Systems – Opinion
This is a very short section and there isn’t much to comment on.
Section 10. Definitions – Summary
Eleven definitions are provided for words and/or terms used in the EO. There are useful definitions for “cyber incident”, “Federal Civilian Executive Branch Information Systems”, “Software Bill of Materials”, and “Zero Trust Architecture”.
Section 10. Definitions – Opinion
They are definitions and definitions are good for clarity. Interesting how the definition of “Zero Trust Architecture” is 227 words long. I like simple, so our simple definition is only two words long, “default deny”.
Section 11. General Provisions – Summary
Looks like some legal stuff. No information security requirements cited in this section.
Section 11. General Provisions – Opinion
No opinion on this section.
Conclusion
There’s plenty to unpack in this Executive Order. Most of the requirements in the EO were reasonable and should result in a net positive in terms of better cybersecurity protection. Requirements that are a little concerning are the Zero Trust Architecture (ZTA) requirements (which we think are premature), prioritized movement to cloud services (which we think could be unjustified from a security standpoint), quick adoption of an endpoint detection and response (EDR) initiative (adding more to manage to environments that are already complex), and unauthorized (by the FCEB Agency) threat hunting.
Other points to consider:
- Would this prevent or mitigate some of our current attacks? This is a longer discussion.
- The timeline is extremely aggressive.
- The requirements are very expensive.
- Those who benefit the most include the Federal Government itself, (big) cloud service providers, ZTA solution providers, and EDR software makers.
- Those who benefit less are private sector organizations, state and local governments, education (K12 and higher ed), small to mid-sized businesses, and people at home.
This EO is essentially law; therefore, like it or not, (our) compliance is mandatory.
