From ransomware attacks on operational technology (OT) systems to data theft targeting enterprise email systems, critical software vulnerabilities are constantly being exploited by sophisticated cyber threats. The federal government has rushed to counter the risks with President Joe Biden’s Executive Order 14028, security guidance for “EO-critical software,” and the Office of Management and Budget (OMB) Memorandum 21-30.
With instructions come deadlines — and few have been as top-of-mind for federal IT leaders as the Oct. 9 requirement for identifying critical software. The good news is the Cybersecurity and Infrastructure Security Agency has resources to help organizations meet the deadline.
What’s more, agencies can take several actions right now to both meet this immediate milestone and lay a strong foundation for future requirements like developing and submitting an implementation plan in the next 12 months, meeting National Institute of Standards and Technology guidance, and strengthening overall cyber protection. Five of these actions follow.
1. Prioritize network, system administration and security tools
Focus on what’s most important. Agencies don’t need to identify every piece of critical software by Oct. 9. According to the June 25, 2021 NIST definition of “critical software,” most of the key priorities include network, system administration and security tools. Other types of critical software can be identified in future phases. There are three primary ways to assess the criticality of the software:
Look at what software is used by the agency’s High Value Asset (HVA) list that is shared with CISA — the agency has already designated which assets and data stored on them are critical to the agency’s mission, so it is likely that critical software needed to support that mission are listed.
Look at what software is used on assets/endpoints that are part of an agency FISMA system whose FIPS 199 categorization is rated as: Confidentiality=High, Integrity=High, Availability=High.
Cross reference the list of software gathered from these two approaches to form a meta-list of what software is consistently important across multiple high priority agency missions and objectives.
2. Use available dashboards and diagnostics
Agencies already have the tools they need to identify critical infrastructure in their operating environments. In 2012, CISA launched the continuous diagnostics and mitigation (CDM) program to help agencies improve visibility and cyber response capabilities, reduce their threat surface and improve the Federal Information Security Management Act (FISMA) reporting. The tools, integration services and dashboards include technologies for software asset management (SWAM).
Most immediately, these SWAM technologies, plus the new CDM dashboard ecosystem, give agencies capabilities to meet both the Oct. 9 deadline and subsequent reporting requirements for the NIST security measures. The CDM program also provides identity and access management capabilities to achieve other objectives, including privileged account management and trusted user behavior management.
SWAM will help because it provides a highly-automated data-driven method of performing the analysis at scale, leveraging CDM program investments to the greatest extent. Leveraging SWAM removes much of the manual labor from this effort and applies a consistent and repeatable methodology for building and maintaining the list of critical software.
3. Mind the visibility gaps
The NIST definition of critical software includes “direct software dependencies” such as software libraries and modules. Your agency, like many, may lack visibility into such dependencies, especially across cloud and OT environments. As you identify and secure critical software, it’s important to concurrently identify visibility gaps and establish plans for closing them.
Why is such visibility critical, and how does it fit into the overall risk management and security picture? While the Software Bill of Materials (SBOM) mandates for proprietary software are still a work in progress, EO 14028 and OMB 21-30 both emphasize risk management across the software supply chain. This increased transparency may incentivize agencies to use open-source and government-off-the-shelf components for critical software.
One primary way to identify and determine visibility gaps is to leverage CISA’s Data Quality rubric and certification process. Additionally, agencies can seek out guidance from private industry to identify gaps in visibility and data above and beyond the standard defined by CISA.
4. Establish governance
If your agency has not yet created policies and practices for managing critical software, now is the time to start. Not only is such governance part of both EO 14028 and OMB 21-30, it’s also essential to a successful overall cyber response. Ask yourself a few questions: How are you procuring critical software? How are you continually evaluating this software against threats within your operating environment? How are you decommissioning this software when it’s no longer needed to reduce your attack surface?
5. Request assistance from CISA
Before and following the Oct 9 deadline, CISA’s CDM team can provide assistance to meet these milestones and guidance deadlines. CISA is already working with some agencies to implement endpoint detection and response capabilities to fulfill requirements for endpoint security protection. It also plans to use American Rescue Plan Act funding to identify and close gaps at multiple agencies. In the months ahead, agencies can use the government’s CDM request for service process to obtain security event monitoring services, as well as data discovery protection, and loss prevention support. The trouble is, not all agencies fully understand how and when to reach out to CISA for assistance when in fact they don’t have to go it alone in this process
These steps and milestones lay the groundwork for modern tools like the dynamic application security testing (DAST) and interactive application security testing (IAST) platforms NIST recommends. DAST and IAST employ auto-discovery for more comprehensive scanning and protection, use proof-of-exploit and automation technologies to validate vulnerabilities, and integrate into software development lifecycles. In cyber defense operations where speed, precision and accuracy matter, high-quality data, advanced analytics and automation are key enablers.
But security is about the entire extended digital ecosystem, across software, the cloud and the expanding perimeters of our everything-as-a-service world. Organizations must have visibility into every element of this digital ecosystem and every aspect of their supply chains. While such risk management goes beyond checklists and questionnaires, OMB 21-30 and EO 14028 milestones and mandates provide tangible steps for near-term improvements.
Todd Skinner is chief engineer at Booz Allen Hamilton and Matt Van Mater is chief technologist at Booz Allen Hamilton.
5 ways to meet OMB’s cybersecurity deadline for critical software
Todd Skinner and Matt Van Mater of Booz Allen Hamilton explain the steps agencies can take today and in the future to secure their critical software.
From ransomware attacks on operational technology (OT) systems to data theft targeting enterprise email systems, critical software vulnerabilities are constantly being exploited by sophisticated cyber threats. The federal government has rushed to counter the risks with President Joe Biden’s Executive Order 14028, security guidance for “EO-critical software,” and the Office of Management and Budget (OMB) Memorandum 21-30.
With instructions come deadlines — and few have been as top-of-mind for federal IT leaders as the Oct. 9 requirement for identifying critical software. The good news is the Cybersecurity and Infrastructure Security Agency has resources to help organizations meet the deadline.
What’s more, agencies can take several actions right now to both meet this immediate milestone and lay a strong foundation for future requirements like developing and submitting an implementation plan in the next 12 months, meeting National Institute of Standards and Technology guidance, and strengthening overall cyber protection. Five of these actions follow.
1. Prioritize network, system administration and security tools
Focus on what’s most important. Agencies don’t need to identify every piece of critical software by Oct. 9. According to the June 25, 2021 NIST definition of “critical software,” most of the key priorities include network, system administration and security tools. Other types of critical software can be identified in future phases. There are three primary ways to assess the criticality of the software:
Get tips and tactics to make informed IT and professional services buys across government in our Small Business Guide.
2. Use available dashboards and diagnostics
Agencies already have the tools they need to identify critical infrastructure in their operating environments. In 2012, CISA launched the continuous diagnostics and mitigation (CDM) program to help agencies improve visibility and cyber response capabilities, reduce their threat surface and improve the Federal Information Security Management Act (FISMA) reporting. The tools, integration services and dashboards include technologies for software asset management (SWAM).
Most immediately, these SWAM technologies, plus the new CDM dashboard ecosystem, give agencies capabilities to meet both the Oct. 9 deadline and subsequent reporting requirements for the NIST security measures. The CDM program also provides identity and access management capabilities to achieve other objectives, including privileged account management and trusted user behavior management.
SWAM will help because it provides a highly-automated data-driven method of performing the analysis at scale, leveraging CDM program investments to the greatest extent. Leveraging SWAM removes much of the manual labor from this effort and applies a consistent and repeatable methodology for building and maintaining the list of critical software.
3. Mind the visibility gaps
The NIST definition of critical software includes “direct software dependencies” such as software libraries and modules. Your agency, like many, may lack visibility into such dependencies, especially across cloud and OT environments. As you identify and secure critical software, it’s important to concurrently identify visibility gaps and establish plans for closing them.
Why is such visibility critical, and how does it fit into the overall risk management and security picture? While the Software Bill of Materials (SBOM) mandates for proprietary software are still a work in progress, EO 14028 and OMB 21-30 both emphasize risk management across the software supply chain. This increased transparency may incentivize agencies to use open-source and government-off-the-shelf components for critical software.
One primary way to identify and determine visibility gaps is to leverage CISA’s Data Quality rubric and certification process. Additionally, agencies can seek out guidance from private industry to identify gaps in visibility and data above and beyond the standard defined by CISA.
4. Establish governance
If your agency has not yet created policies and practices for managing critical software, now is the time to start. Not only is such governance part of both EO 14028 and OMB 21-30, it’s also essential to a successful overall cyber response. Ask yourself a few questions: How are you procuring critical software? How are you continually evaluating this software against threats within your operating environment? How are you decommissioning this software when it’s no longer needed to reduce your attack surface?
5. Request assistance from CISA
Before and following the Oct 9 deadline, CISA’s CDM team can provide assistance to meet these milestones and guidance deadlines. CISA is already working with some agencies to implement endpoint detection and response capabilities to fulfill requirements for endpoint security protection. It also plans to use American Rescue Plan Act funding to identify and close gaps at multiple agencies. In the months ahead, agencies can use the government’s CDM request for service process to obtain security event monitoring services, as well as data discovery protection, and loss prevention support. The trouble is, not all agencies fully understand how and when to reach out to CISA for assistance when in fact they don’t have to go it alone in this process
Read more: Commentary
In conclusion
These steps and milestones lay the groundwork for modern tools like the dynamic application security testing (DAST) and interactive application security testing (IAST) platforms NIST recommends. DAST and IAST employ auto-discovery for more comprehensive scanning and protection, use proof-of-exploit and automation technologies to validate vulnerabilities, and integrate into software development lifecycles. In cyber defense operations where speed, precision and accuracy matter, high-quality data, advanced analytics and automation are key enablers.
But security is about the entire extended digital ecosystem, across software, the cloud and the expanding perimeters of our everything-as-a-service world. Organizations must have visibility into every element of this digital ecosystem and every aspect of their supply chains. While such risk management goes beyond checklists and questionnaires, OMB 21-30 and EO 14028 milestones and mandates provide tangible steps for near-term improvements.
Todd Skinner is chief engineer at Booz Allen Hamilton and Matt Van Mater is chief technologist at Booz Allen Hamilton.
Copyright © 2024 Federal News Network. All rights reserved. This website is not intended for users located within the European Economic Area.
Related Stories
How 21st-century data management can help leaders provide more effective correctional healthcare services
Breaking down barriers: The challenges of federal micro-purchases for small businesses
The push to upskill the technology workforce in federal agencies