What Does the Biden Administration’s Cybersecurity Executive Order Mean for API Security?
The latest executive order (EO) zones in on a few areas of cybersecurity, but a primary focus is software supply chain security after incidents such as the SolarWinds attack. Some of these mandates were already in play as part of the Federal Risk and Authorization Management Program (FedRAMP) program initiated in 2011, but the Authorization to Operate (ATO) process was notoriously slow. The EO aims to promote higher levels of automation and continuous validation rather than manual, compliance-heavy, and point in time activity. Though the scope of the EO is limited to federal entities and suppliers to those entities, the EO contains useful guidance for the private sector and security industry.
The EO calls for increased scrutiny of the software supply chain and validation against guidance provided by the National Institute of Technology (NIST). NIST guidance includes a range of systems engineering best practices, secure SDLC activities and DevSecOps practices. Any supplier that contracts with federal entities must secure their development environments, regularly check code for weaknesses and known vulnerabilities, and ensure code integrity throughout the application lifecycle.
Learn why apps are built on APIs, the security risk APIs present, and best practices for securing APIs.
Download NowThe EO calls out the need for software bill of materials (SBOM), which is a way of detailing the contents of an application package including third-party libraries or open-source software dependencies. SBOMs are useful for quickly identifying known vulnerabilities that may be contained within an application package and should be remediated. Unfortunately, SBOMs haven’t been expanded to include APIs, which are foundational to modern system design and integration. APIs often exhibit their own unique security weaknesses and vulnerabilities. Application security isn’t just a factor of vulnerable libraries within an application codebase, an organization’s security focus must also include APIs that enable business functionality, data exchange, and service integration.
The EO also calls out some newer security principles such as use of multi-factor authentication (MFA) and zero trust architecture (ZTA) to improve infrastructure security in the software supply chain. Zero trust architecture requires continuous behavior analysis within authenticated and authorized sessions to ensure least privilege and quickly contain any malicious activity. This must be done for users and machines across environments, and it must also be done for all types of computing activities such as connecting to data sources, modifying configurations, or transferring information. MFA implementations also get complicated quickly when considering the larger ecosystem of machine identities, direct API communications, and external service integrations.
Organizations often overlook or misconfigure the technologies that support newer security principles such as MFA and ZTA because of concerns over negative impact to production users or inherent complexity in a complete architecture. Keeping tabs on this complex spiderweb of internal and externally developed systems, applications and APIs is also simply too much to keep track of using traditional tooling and manual approaches. As a result, many Salt Security customers use our API Protection Platform to bring order to the chaos of modern system design and bolster their cybersecurity initiatives.
If you’re interested in seeing the Salt Security API Protection Platform in action, contact us for a customized demo today!
