The federal government is in the middle of a once-in-a-generation overhaul of network protection, propelled by presidential executive orders mandating a switch from perimeter-based security to zero trust architecture.

Agencies must include application security (AppSec) and software bills of materials (SBOMs) — an inventory of software’s components, libraries and modules – in their zero trust strategy or deal with the consequences of a gaping security hole.

Agency IT and security teams know all too well the consequences of poor software security. The SolarWinds hack in 2020 compromised the systems and data of NATO, the European Parliament and numerous departments of the U.S. government. And, last year, the ubiquitous Log4j vulnerability affected large chunks of global IT networks and posed “an unacceptable risk to federal network security,” according to Jen Easterly, the Cybersecurity and Infrastructure Security Agency director.

A report by the Cyber Safety Review Board on the Log4j event revealed that the response to the crisis by one cabinet-level federal agency consumed 33,000 hours between December 2021 and this June, at the expense of advancing mission priorities and combating other cyber threats.

Zero trust architecture, based on the principle of verifying everything and trusting nothing, was formulated to keep networks secure in a dynamic digital world. Moreover, access to IT assets is limited to users’ legitimate needs.

Traditional perimeter security, by comparison, takes a binary, castle-and-moat approach, trusting entities with assets (the castle) inside the perimeter (the moat) and distrusting all others (potential enemies). Perimeter security worked well enough in the pre-cloud computing world, but there was always the problem of what to do when an adversary hopped across the moat, slipped through a crack in the wall, and moved about unimpeded, often for months at a time, before being detected.

Now, as networks migrate to software-defined (SD) models, such as SD data centers and SD networks, the need for stronger application security is greater than ever. Although container scanning and infrastructure-as-code scanning bolster the security of software-defined networks/infrastructure, SBOMs focus on libraries and components, providing visibility into the components of software used by agencies. In this way, insight literally enables the security of otherwise opaque applications.

Pillars of cybersecurity

The Zero Trust Maturity Model, developed by CISA, envisions five pillars (or layers) of security that overlap and reinforce one another.

In the journey to implement zero trust, CISA instructs agencies to put in place network-based cyber defenses that continuously verify security across all five pillars: identity, device, network/environment, application workload and data. In January, the administration released guidance (OMB M-22-09) requiring federal agencies to reach specific benchmarks toward attainment of zero trust architecture by the end of fiscal 2024. Half measures won’t cut it.

Making the transition to zero trust architecture requires agencies to think about IT protection in new ways. During the heyday of perimeter security, for example, not enough thought was given to securing the applications that run on agencies’ networks. For years, the prevailing assumption by policymakers was that everything residing behind a firewall, including software, was untouchable and, therefore, safe.

The presumed security of applications positioned behind a security wall has long been debunked, but for many years that widely held misapprehension dampened demand for application security. Colleges and universities neglected to teach secure design or secure coding; software developers lacked the skill to produce secure products; and software security, if it happened at all, was often bolted onto applications after completion of their development.

Nor did security processes improve in the post-development phase of the application lifecycle. As often as not, traditional development methodology was grossly negligent when it came to scanning applications for security vulnerabilities after they were put into service. Moving toward a zero trust architecture in a meaningful way requires agencies to jettison legacy thinking about network security. Shifting from a simple perimeter security model to a paradigm of layered defense means that all layers are important. If, for example, an agency has an application programming interface (API) that lacks strong authentication and secure coding and is open to the internet, that API could be vulnerable to a breach.

Risk also increases when IT teams assume that an authenticated application is safe and doesn’t require security testing.

Steps for implementing zero trust

Given the high stakes of cyberattacks, agencies must reduce their exposure to risk.

To begin, agencies must have greater visibility into their application portfolios because they can’t secure what they can’t see. Next, they should understand what’s in those applications. Contemporary software development is often a process of assembling prefabricated code from open-source products. Not knowing the provenance of those modules is risky. Fortunately, SBOMs are an effective tool enabling developers to see what’s in open-source code before they use it, much the way grocery shoppers read labels before dropping processed food items into their carts.

According to the CSRB report, citing CISA, the Log4j event “called attention to security risks unique to the thinly-resourced, volunteer-based open-source community,” which lacks the resources to develop secure code in accordance with industry practices.

Reducing the risk of security threats like Log4j is especially important at a time when federal government agencies and contractors who develop software for them increasingly rely on open-source software.

Agencies shouldn’t succumb to the temptation of relying on the infrastructure security of cloud-service providers. Security built into cloud providers’ offerings exists to secure the infrastructure of cloud providers, not the applications that run on it. A vulnerable application that lives in the cloud is still a risk because hackers will attack the weakest link. Having confidence in the security of applications requires, at minimum, subjecting applications to static analysis testing, dynamic application security testing, and software composition analysis. If agencies use containers, they should scan them, as well.

In the absence of a security breach, it would be easy to dismiss these security concerns. After all, ignorance is bliss. At minimum, the goal should be to neutralize preventable breaches by addressing known critical vulnerabilities (like Log4j). The work begins with gathering and maintaining SBOMs for all the software in your agency.

Application vulnerabilities tend to be well-hidden, burrowed deep into millions of lines of code. For agencies, the question is who will find them first? Agencies’ security teams or cyber attackers? In the former scenario, remediation and enhanced security ensue. In the latter, a cyberattack could result in a catastrophic breach, an inspector general’s report, and possibly an invitation to appear before a congressional committee.

To avoid such an outcome, agencies should take action and begin implementing all pillars of the Zero Trust Maturity Model, including application security. Start today.

Chris Eng is chief research officer at Veracode.

Copyright © 2024 Federal News Network. All rights reserved. This website is not intended for users located within the European Economic Area.