- Fire TV just got three new accessibility features for people with disabilities
- 6 ways to deal with mental fatigue at work
- Interpol Calls for an End to “Pig Butchering” Terminology
- Capital Energy se alza con el premio Energía y Utilities en los ‘CIO 100 Awards’
- “인도가 발전하려면 주 70시간 근무 시행해야…” 인포시스 설립자 발언
Critical Software Security and the Cyber Executive Order
For the average American, the term critical infrastructure probably conjures up images of hospitals, power plants, and highways. But how about critical software? The range of responses will be off the charts. We could probably say the same about the software that powers your agency too. What’s critical and what isn’t?
Disruption would be debilitating
Critical infrastructure sectors are so important that disruption would have a “debilitating effect” on our country, so national policy prioritizes them. The Critical Infrastructure Security Agency (CISA) defines both the term and its 16 specific sectors. Each one has a unique, sector-specific plan to mitigate risks. That’s the goal, anyway.
Contrast that with critical software, a term that lacks a clear definition. Your agency typically decides for itself what software is mission critical, and how best to protect it. For instance, you’re following the NIST Risk Management Framework within your agency to determine its importance in the security categorization step.
Yet recent software supply chain attacks showed us that we need clarity and consistent security measures. It begins with the definition.
Defining EO-critical software
The President’s Executive Order on Improving the Nation’s Cybersecurity (EO 14028) addresses this in Section 4, “Enhancing Software Supply Chain Security.” There it directed NIST to define critical software and provide security guidelines, which they’ve done in two separate whitepapers (Definition of Critical Software and Security Measures for “EO-Critical Software”).
First, let’s talk about the term itself. It’s not “critical software,” it’s “EO-critical software” in NIST’s Executive Order response publications. They acknowledged that “critical” is too loosely defined in general, so they wanted to be crystal clear about critical software in the context of the Executive Order.
Paraphrasing their definition, EO-critical software is any software that:
- Is designed to run with elevated privilege or manage privileges
- Has direct or privileged access to networking or computing resources
- Is designed to control access to data or operational technology
- Performs a function critical to trust
- Operates outside of normal trust boundaries with privileged access.
NIST acknowledges that this is a broad definition, so it covers a lot of software types. That’s why they’ve recommended a phased approach starting with on-premises software. Later phases will address other types like cloud-based software, OT software components, and boot-level firmware.
Their paper also covers preliminary EO-critical software categories like operating systems, hypervisors, container environments, web browsers, endpoint security, identity management, network protection and control, configuration management, and more.
Security measures for EO-critical software usage
With the definition complete, the second NIST whitepaper covers the Security Measures (SM) for EO-critical software. An important word here is usage: It’s about how agencies use EO-critical software, not about how vendors develop it or how agencies acquire it. After all, it’s already running in production, so these Security Measures are intended to boost the software’s security.
With that in mind, NIST defined five objectives for EO-critical software that I’ll paraphrase:
- Protecting from unauthorized access and usage
- Protecting data
- Identifying and maintaining
- Detecting, responding, and recovering from threats
- Strengthening humans’ actions around it.
Under each objective, there are up to five Security Measures (SM) prescribing specific controls. And NIST mapped all SMs to existing references like the Cybersecurity Framework and NIST SP 800-53 so they aren’t entirely new.
For example, multi-factor authentication (SM 1.1) supports the first objective around unauthorized access protection, and maps to controls AC-2, IA-2, IA-4, and IA-5 in NIST SP 800-53.
Cisco can help
At Cisco, we’ve been protecting government systems and data for decades, and we’re no stranger to cyber best practices. The table below shows how Cisco Secure solutions can help you secure EO-critical software. It’s not meant to be exhaustive; rather, a starting point to illustrate the many ways that we can help.
What questions do you have? Please comment below or, better yet, talk with us. We’re always here to help.
Additional Resources
Share: