The Cybersecurity Executive Order: the first 120 days
How has cybersecurity changed in the four months since the White House mandate and where are we going?
When the Executive Order on Improving the Nation’s Cybersecurity (Executive Order) was released in May 2021, it came with some very short deadlines for agencies. Most of the Executive Order’s timelines were in the 45-, 60-, and 90-day range. With that in mind, taking a look at the changes that have occurred in the last few months can shed some light on where the Executive Order stands.
Critical Software Definition
On June 2 and 3, 2021, the National Institute of Standard and Technology (NIST) held a workshop where it consulted with federal agencies, the private sector, academics, and other stakeholders to start working on a definition of Critical Software.
The definition of EO-critical software
Since the Executive Order seeks to enhance the security and integrity of “critical software,” defining the term needed to be one of the first agenda items completed. As a result of this workshop, NIST released a whitepaper on June 25, 2021, “Definition of Critical Software under the Executive Order (EO) 14028.”
The final definition applies to all types of software, including standalone software, firmware, and cloud-based software:
EO-critical software is defined as any software that has at least one component or direct software dependency with at least one of these attributes:
- 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; or,
- operates outside of normal trust boundaries with privileged access.
The definition of “direct software dependencies”
This term is defined in the NIST whitepaper’s Frequently Asked Questions (FAQ) as:
other software components (e.g., libraries, packages, modules) that are directly integrated into, and necessary for the operation of, the software instance in question.
NIST notes that this definition isn’t intended to be a systems definition, meaning it doesn’t include the interfaces and services of otherwise independent products.
The definition of “critical trust”
Along with “direct software dependencies,” NIST also uses the FAQ to define the term “critical trust” as:
categories of software used for security functions such as network control, endpoint security, and network protection.
Security Measures for EO-critical software use
Finally, NIST released a set of Security Measures (SM) grouped by objective that will be applied to all EO-critical software, including platforms, users, administrators, data, or networks needed for running the software.
The SMs are grouped according to five objectives:
- Access and usage
- Confidentiality, integrity, and availability
- Protecting software from exploitation
- Incident detection, response, and recovery
- Security training
Recommended Minimum Standard for Vendor or Developer Verification (Testing) of Software Under Executive Order (EO) 14028
The recommended guidelines around vendors’ source code testing is not limited to EO-critical software. It focuses on setting guidelines that software producers can use to tailor their own internal processes as applied to their software products, technologies, toolchains, and development life cycle models.
Recommended Minimum Standards
NIST lists the following eleven software verification techniques that developers should be using to verify their software:
- Threat modeling to look for design-level security issues
- Automated testing for consistency and to minimize human effort
- Static code scanning to look for top bugs
- Heuristic tools to look for possible hardcoded secrets
- Use of built-in checks and protections
- “Black box” test cases
- Code-based structural test cases
- Historical test cases
- Fuzzing
- Web app scanners, if applicable
- Address included code (libraries, packages, services)
Beyond Software Verification
Software verification is only one part of delivering quality software. While the eleven best practices are minimum requirements, NIST clarifies that developers can also use practices and processes to enhance security.
NIST lists three additional practices, processes, and technologies that can help mitigate supply chain attack risks.
Adopting the Secure Software Development Framework (SSDF)
The SSDF consists of four general practices, with an additional four that apply specifically to DevOps. The four general practices are:
- Prepare the Organization (PO): make sure all people, processes, and technology across the organization are prepared
- Protect the Software (PS): prevent tampering with and unauthorized access of software
- Produce Well-Secure Software (PW): make sure that software releases have as few security vulnerabilities as possible
- Respond to Vulnerabilities (RV): identify and remediate vulnerabilities while working to prevent similar ones in the future
For DevOps, the following additional practices apply:
- Include a security specialist on the developer team to train developers on designing and implementing secure software as well as how to use vulnerability tracking tools
- Automate security checking for Security as Code
- Track threats and vulnerabilities
- Share software development task, security threat, and vulnerability information across the security, development, and operations teams
Secure Installation and Operation
Not all vulnerabilities exist in the software itself. The installation, operation, and maintenance of software can also lead to exploitable vulnerabilities.
NIST addresses these risks across four categories:
- Configuration files: Changing configuration settings can lead to critical vulnerabilities so security verification should include all valid settings and possibly assurance that invalid settings will be caught by run-time checks
- File permissions: File ownership and read/write/execute/delete permissions should be limited according to the principle of least privilege
- Network configuration:network configurations limit unauthorized access to software so verification should include all valid network configuration settings and possibly assurance that invalid settings will be caught by runtime checks
- Operational configuration: adding or removing components can invalidate software security so verification needs to be done in an environment similar to the anticipated operational configuration and developers must tell the user about these to maintain supply chain integrity.
Software Assurance Technology
As verification technologies change, DevOps should incorporate them to enhance the security of their software.
Technology advancements that NIST notes include:
- Machine learning for automated security scanning tools to reduce false positive and increase vulnerability detection
- Automated web interface tests for producing application security tests
- Scaling model-based security testing
- Advanced web-application security assessment tools that include:
- Session state management
- Script parsing
- Logical flow
- Custom uniform resource locators (URLs)
- Privilege escalation
- Observability tools for use in cloud environments
- Achieving cloud service security assurance by adapting current security testing technology
What These Changes Mean for DevOps
For the near future, these changes only impact software used within federal networks. However, as Federal Civilian Executive Branch (FCEB) agencies work to secure their supply chains, these guidelines and directives will extend their reach further downstream.
In order to continue developing and releasing software products, DevOps teams need to work more closely with security teams. Meanwhile, they need to maintain SLAs and continue to meet their deadlines. To reduce costs and secure the software development lifecycle, DevOps teams need to consider next-gen solutions that help them detect vulnerabilities early on in the cycle and remediate weaknesses quickly.
Teams that engage in regular code scans are more likely to detect a new vulnerability across their application’s dependencies and, ultimately, reduce security risk. Using next-generation static application security testing (SAST) like that in ShiftLeft CORE, organizations can scan their applications in minutes, meaning that they can scan them weekly or even daily. In order to meet these enhanced software verification requirements, DevOps needs to build application security iteration into its development cycles.
Teams using next-gen SAST scan 46% of applications at least weekly, 14x the rate of legacy tools.*
*source, AppSec Shift Left Progress Report
Teams that account for attacker reachability can reduce open-source security tickets by 92%*
*source, AppSec Shift Left Progress Report
DevOps teams will become increasingly important to supply chain security as agencies and organizations rely on applications for daily business operations. Building security into the software development lifecycle as early as possible reduces financial and operational costs while ensuring better data protection.
The Cybersecurity Executive Order: the first 120 days was originally published in ShiftLeft Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.
*** This is a Security Bloggers Network syndicated blog from ShiftLeft Blog - Medium authored by The ShiftLeft Team. Read the original post at: https://blog.shiftleft.io/the-cybersecurity-executive-order-the-first-120-days-e725e904ab?source=rss----86a4f941c7da---4
