When it comes to security, all software is ‘critical’ software

All the sessions from Transform 2021 are available on-demand now. Watch now.

Defining critical software has become a more complex task in recent years, as both tech professionals and government officials aim to contain or diminish the impact of cybersecurity breaches that are more difficult to label. The lines of definition have blurred beyond recognition, as all software platforms are hackable and threat actors are motivated by a slew of financial, geopolitical, or ideological agendas. Cyberattacks are undoubtedly part of the national security conversation, as more potent threats emanate from nations unfriendly to the United States.

As a partial response to this growing number of attacks, the White House released an executive order on May 12, 2021 to help improve the United States’ posture on cybersecurity. The order mandated that the National Institute of Standards and Technology (NIST) provide a definition for what should be considered “critical software.” On June 24, NIST released its definition, which will help both government and industry better understand where to focus and how to ramp up their efforts in securing software.

According to NIST, “EO-critical software is defined 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.”

The NIST announcement goes on to provide examples of software that fits the definition: identity, credential and access management (ICAM); 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; backup/recovery and remote storage.

This rather wide definition confirms what many cybersecurity experts know but perhaps fail to execute on: All software, regardless of its ingenuity or seeming insignificance, is absolutely critical. The NIST definition should not be considered too broad; rather, software today is sprawling and touches almost all aspects of our lives. Hybrid work, social media, and a greater dependence on mobile devices have made software an irreplaceable piece of modern society.

An example of software’s boundless reach can be found in web applications that are designed to control access to data. Many mobile applications require access to operational technologies of the mobile device in order to carry out their most basic functionalities. Software can give access to the underlying operating system or other software, which can then lead to a privilege escalation that enables takeover of a system. All software can enable access. Even if software was not intended to be used in a “critical” way, it could potentially be used that way or repurposed into a “direct software dependency.” Threat actors fully understand this, coming up with unconventional workarounds to manipulate software that otherwise wouldn’t be considered critical. Analyzing these incidents and taking stock of their frequency should be part of the software security process.

One specific, well known example highlighting unexpected software criticality comes from a fish tank thermometer in a Las Vegas casino. Attackers were able to get into the casino’s network via the fish tank thermometer which was connected to the Internet. The attackers then accessed data on the network and sent it to a server in Finland. Most people would not think of a fish tank thermometer as critical software, but it may very well meet the definition of EO-critical software, as it did enable access to a PC over a network — and ultimately, sensitive data. This example highlights that the criticality of software is not based solely on a particular application, but the application’s context in a larger cyber ecosystem. If one component of that ecosystem is exploited, the entire operation is at risk, exposing private information, access to financial resources, or granting the ability to control the ecosystem itself.

When dealing with limited resources, the security focus should begin with what is “most critical,” but that security focus should not end once the items initially marked as “most critical” are secured. A long-term, comprehensive security outlook is necessary when working with a limited budget, allowing for later security coverage for software that may not be used as frequently but could still be considered an access point. Prioritization of what is critical is very dependent on the system, the purpose, the data it is connected to, and context. Coming up with a taxonomy for prioritization is difficult and should be done on a case-by-case basis with trusted security partners. Companies both small and large are targets for threat actors. Dismissing the critical nature of an organization’s software due to the operation’s size would be unwise; the recent Kaseya supply chain attack clearly demonstrates this.

Threat actors are demonstrating a lot of creativity, and the NIST definition of critical software underscores this point. Finding a long-term security strategy that adequately addresses all software components of an ecosystem is non-negotiable, as all software should be considered critical.

Jared Ablon is CEO of HackEDU.


  • up-to-date information on the subjects of interest to you
  • our newsletters
  • gated thought-leader content and discounted access to our prized events, such as Transform 2021: Learn More
  • networking features, and more

Source: Read Full Article