It has been more than a year since the U.S. White House released Executive Order 14028, “Improving the Nation’s Cybersecurity.” Published after a series of significant cybersecurity attacks including SolarWinds, the EO kicked off an aggressive timeline for the definition of requirements to strengthen security of the apps built and used by federal government agencies.
The timeline ends with the removal of noncompliant software and cancellation of contracts with vendors who could not meet the defined requirements. One requirement specified in the EO is Security Testing Automation. Section 4(e)(iii) and 4(e)(iv) requires “employing automated tools, or comparable processes, to maintain trusted source code supply chains” and “employing automated tools, or comparable processes, that check for known and potential vulnerabilities and remediate them at a minimum prior to product, version, or update release.” This ties directly to Section 4(r) which defines automated tools such as SAST, DAST, IAST, SCA and API security testing and calls for penetration testing guidelines.
Another EO requirement quickly garnered attention, Section 4(e)(vii). This requires all software sellers “provide a purchaser a Software Bill of Materials (SBOM) for each product directly or by publishing it on a public website.”
What Is a Software Bill of Materials (SBOM)?
Software Bill of Materials (SBOM) requirements were the first to be well defined, and are often described as a list of ingredients for an application. Simply put, an SBOM is an inventory of all the dependencies and third-party code included in an application. This includes dependencies of dependencies, known as transitive dependencies, open-source libraries and third-party components.
In order to make the data usable, most SBOMs are generated in a machine readable format like XML or JSON and the OWASP CycloneDX has quickly become the leading standard format. This data is meant to help reduce the risk of another pervasive supply-chain attack like SolarWinds. By inventorying the third-party dependencies an application has, agencies can react quickly to remove, update, or isolate an app if a dependency is compromised.
“The U.S. government is focused on improving the cybersecurity of all applications, including mobile applications, produced by and utilized by its agencies.”rnrn
Government Expands Cybersecurity Guidelines
Many developments and memos followed Executive Order 14028 including several key to organizations that create mobile apps or mobile application security programs.
NIST Security Measures
The NIST Security Measures for EO-Critical Software Use defines critical software subject to the EO requirements, elaborates on the objectives presented in the EO and outlines security measures vendors can begin to take to meet the pending requirements.
NIST defines critical software as “any software that has, or has direct software dependencies upon, one or more components 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.”
While the EO first focuses on critical software, observers expect the requirements to eventually extend to all software used by the federal government and the definition of critical software to potentially expand in the future.
NIST also outlines Security Measures that will be expected of all EO-compliant applications. Security Measure 2.3 requires software sellers to protect sensitive data at rest by encrypting it using current cryptographic standards. This is followed by SM 2.4, which requires the protection of data in transit “by using mutual authentication whenever feasible and by encrypting sensitive data communications.”
Mobile app security and mobile app development teams will also be interested in SM 3.2, which requires the use of patch management practices that include the “rapidly identify, document, and mitigate known vulnerabilities (e.g., patching, updating, upgrading software to supported version) to continuously reduce the exposure time.” NIST also mandates continuous monitoring of the security of software platforms and all software running on those platforms in SM 4.2.
Finally, NIST stipulates guidelines for developer verification of software which should inform these aspects of mobile application security testing:
- 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
- “Black box” test cases
- Fuzzing
- Address included code (libraries, packages, services)
Executive Order 14034
Tangentially related to the original Cybersecurity EO, the White House also published Executive Order 14034 on “Protecting Americans’ Sensitive Data From Foreign Adversaries.” This EO details the security threat of applications which run on “personal electronic devices such as smartphones, tablets, and computers” and their ability to capture “vast swaths of information from users, including United States persons’ personal information and proprietary organization information.” It even goes as far as describing mobile application cybersecurity attacks as “an unusual and extraordinary threat to the national security, foreign policy, and economy of the United States.”
The EO on Protecting Sensitive Data defines the indicators of risk and the sensitive data at risk to foreign adversaries and introduced a second set of deadlines that are available on the NowSecure Cybersecurity Executive Orders page.
OMB M-21-30
In August of 2021, the Office of Management and Budget published OMB M-21-30, “Protecting Critical Software Through Enhanced Security Measures.” This doubles down on the importance of securing the critical software as defined by NIST and defines the early phases of the approach being taken by the government to secure the apps they are building and help fix the “software is commercially developed through an often opaque process that may lack sufficient controls to prevent the creation and exploitation of significant application security vulnerabilities.”
Phase 1 of the EO rollout criteria applies to identity, credential, and access management (ICAM) software, operating systems, hypervisors, container environments, web browsers, endpoint security, network control, network protection, network monitoring and configuration, operational monitoring and analysis, remote scanning, remote access and configuration management, and backup/recovery and remote storage software. Phase 2 expands to software that controls access to data, cloud-based and hybrid software, software development tools, such as code repository systems, testing software, integration software, packaging software, and deployment software, software components in boot-level firmware, and software components in operational technology (OT).
OMB M-21-31 & M-22-01
OMB M-21-31 on “Improving the Federal Government’s Investigative and Remediation Capabilities Related to Cybersecurity Incidents” and OMB M-22-01 on “Improving Detection of Cybersecurity Vulnerabilities and Incidents on Federal Government Systems through Endpoint Detection and Response” both expanded the scope of the EO-impacted software to include software in the Enterprise Mobility Management, Unified Endpoint Management, Mobile Threat Defense, Mobile Device Management, International Mobile Equipment Identity and International Mobile Subscriber Identity categories, and by stressing mobile phones as a critical endpoint for EDR solutions to have insight into.
FISMA Reform Act
The proposed FISMA Reform Act also has massive implications for mobile app security practitioners and mobile app developers. After its enactment, the Director is required to “evaluate mobile application security guidance and issue guidance to secure mobile devices, including for mobile applications, for every agency” in less than one year. For government agencies, this will also require continuous inventory of all “mobile devices operated by or on behalf of the agency; and vulnerability identified by the agency associated with a mobile device” and require every agency to perform continuous “evaluation of vulnerabilities and other risks associated with the use of applications on mobile devices.”
OMB M-22-09
OMB M-22-09 on “Moving the U.S. Government Toward Zero Trust Cybersecurity Principles” may be the most impactful development since the EO on Cybersecurity. The government’s efforts to a Zero Trust Architecture has major implications for mobile apps. One proposed strategy entails consistently tracking and monitoring the security posture of the mobile devices used by federal staff, and using the security posture to make decisions when granting access to internal resources. That means an individual with a mobile application with subpar security may be blocked from accessing critical information. It also requires that “enterprise applications are tested internally and externally.”
As with all Zero Trust Architecture and as previously stated in other requirements, this OMB stresses the importance of encryption for data both in transit and at rest, a problem commonly found in mobile apps. It encourages adopting an attacker’s perspective and working with everyone to improve security postures, “agencies should scrutinize their applications as our nation’s adversaries do. This requires welcoming external partners and independent perspectives to evaluate the real-world security of agency applications, and a process for coordinated disclosure of vulnerabilities by the general public.”
The strategic goals included in this memo align with CISA’s five pillars, one of which is “Applications and Workloads,” which encourages “Agencies treat all applications as internet-connected, routinely subject their applications to rigorous empirical testing, and welcome external vulnerability reports.” It later specifically points out mobile applications, and provides steps to make progress on the Applications and Workloads vision. “Agencies must operate dedicated application security testing programs,” “Agencies must utilize high-quality firms specializing in application security for independent third-party evaluation” and “Agencies must maintain an effective and welcoming public vulnerability disclosure program for their internet-accessible systems.”
OMB M-22-09 also provides more specifics around application security testing. It states “agencies must analyze their software and its deployed functionality with a comprehensive and rigorous approach, whether their software is built internally or by a contracted vendor,” requires the use of both automated and manual techniques, “should incorporate not just information gathered by automated tools for vulnerability scanning and code analysis of custom-developed software, but also analysis prepared by more time-intensive, specialized, and application-specific methods.”
It also encourages the adoption of a more modern DevSecOps approach stipulating, “Agencies are expected to continue moving toward continuous monitoring and ongoing authorizations while employing periodic manual security assessments as applications, dependencies, components, and infrastructure evolve.”
The memo goes on not only to promise a “procurement structure for agencies that allows for rapid acquisition of rigorous application-security testing capabilities. As a result of this work, agencies should be able to schedule most work within less than a month (or in high urgency situations, a few days).” It also encourages the acceptance of application vulnerability reports. It establishes a public vulnerability disclosure program that government agencies can use to work directly with security researchers.
What Does This All Mean
All the Executive Orders, OMB Memos, NIST Measures and Reform Acts make it a bit confusing to nail down what is expected. Put most simply, the U.S. government is focusing on improving the cybersecurity of all applications, including mobile applications, produced by and utilized by its agencies. Regulations will continue to be defined, evolve, and expand. And because so many software vendors sell to the government, these requirements will become the norm.
How NowSecure Can Help
NowSecure has been closely tracking the development of federal cybersecurity regulations. We have submitted feedback to the agencies that are open to comment on what mobile appsec requirements should look like and what they should include, advocating for standards-based testing and automatable tests.
For mobile application development and security teams, more requirements are coming for automated testing. NowSecure has the expertise and the solutions to make mobile app security testing easy and speed delivery, and can provide both the continuous automated mobile appsec testing and the periodic manual testing required. NowSecure can help you get started today and stay ahead of the impending requirements.
