Defining & Protecting Critical Software to Improve U.S. National Cybersecurity & Supply Chain Resilience

Critical software used across the federal government should have rigorous security measures applied to ensure safe and secure use. Compromise, misuse, or disruption of critical software can jeopardize agency and enterprise missions, while also causing financial damage, loss of trust, loss of life and widespread societal consequences. Not only must the critical software itself be protected, but the agency IT environment, its customers, partners, and the public must be protected from any potential misuse or rogue activity posed by the software (SolarWinds Orion, etc.).

With a wave of industry-shaking cyberattacks kicking off the first half of 2021, the U.S. government has mobilized efforts and marshalled minds and resources to improve supply chain cyber resilience and protect critical infrastructure. Recently, President Biden issued the Executive Order (EO) on Improving the Nation’s Cybersecurity. This blog will put forth definitions and best practices to address Section 4 of Biden’s EO: Enhancing Software Supply Chain Security. I will start by defining what critical software is, and then breakdown three fundamental cybersecurity categories that all agencies and enterprises should implement to ensure a strong foundation for securing critical software and bolstering the software supply chain.

Critical Software Defined

To help ensure agencies and enterprises align the appropriate security rigor for protection of critical software and help ensure the continuity and integrity of their missions, we must start by defining what constitutes “critical software.” The factors by which we designate software packages “critical” can vary, but include understanding the types of data it accesses, the level of systems it controls, and/or the open attack surface that it carries. While some software may always be classified as critical, classification can fluctuate based on the data being accessed at any given time.

In today’s enterprise-level environments, “critical software” should be defined by a variety of factors. “critical” software can be:

• Application software, which relates to the software’s access to, maintenance of, or transmission of sensitive data
• System software, categorized as software that controls and manages networked devices, including directory services, client, server, or network hardware
• Public-facing software, which presents unmitigated risk exposure

Application Software

The first category of critical software, application software, is installed in a client/server configuration or on individual systems as productivity software, such as word processors or spreadsheet manipulators. Software within this category receives its critical designation because it is considered sensitive and/or classified under privacy laws or government designations.

For example, applications that maintain, transmit, or access data governed under the Health Insurance Portability and Privacy Act (HIPAA) should be designated “critical”, considering the type of data and the potential for massive damage resulting from a breach. Similarly, Personally Identifiable Information (PII) is defined by OMB Memorandum M 071616 as “information that can be used to distinguish or trace an individual's identity, either alone or when combined with other personal or identifying information that is linked or linkable to a specific individual.” This data, as dictated by OMB, would create a true potential for harm. In this case, not only is the harm substantive in cost, but it also creates a potential life-threatening risk. Therefore, the same software that is deemed critical in one system may not receive that designation in another simply based on the sensitivity of the data it can access, and may transition from normal operations to a critical designation based on the current state of data being accessed.

In April of 2015, operators at the Office of Personnel Management discovered a breach in personnel management software, including “SF-86” Forms, which contained the extensive background information for cleared civilian personnel working in the federal government. Fingerprints, financial information, known friends and relatives, and job assignments are just a sample of information included in the breach. Multiple sources cited the trove of information as a significant value to the international intelligence community, and a potential significant risk to those employees who might be serving abroad or undercover. This is a clear example of combining sensitive and/or classified data with PII to form a potential for harm.

System Software

The second category, system software, provides management for networks, databases, individual systems, and other utilities as necessary for the efficient running of the network. The critical status of system software is determined by the impact to an organization or mission if that software and data were no longer functioning or secure.

A particularly sensitive subset of system software includes authoritative directories, which provide the base of authentication for most modern networks. A breach of this software allows threat actors to access almost everything of value on a network and may allow them to regain access in the future. These directories may be the most significant critical piece of software on a network.

Database servers are the backbone of the modern Enterprise Resource Planning (ERP) and productivity software. Often containing tens of thousands of data entries, and supporting every known fiscal management software in existence, databases provide the essential platform for conducting business. Operating systems for clients or servers could provide base function access to a system and any activity that occurs on it.

System software that governs network hardware provides a host of security and utility functions to devices once considered the perimeter of the network. Access to this software will grant lateral movement or allow unmitigated access to sensitive data areas. Even as NIST (National Institute of Standards and Technology) and CISA (Cybersecurity and Infrastructure Security Agency) begin to recognize identity as the perimeter, network hardware and the underlying management software still cannot be understated in their importance. These services provide dependent functions for other critical software. Any unauthorized use or breach of this software could render multiple functions inoperable or allow continued access to a set of data otherwise intended to be governed by policy and reputation.

In addition, system software such as authoritative directories, can provide privileged access to a multitude of other critical software, allowing for unwanted lateral movement and data exfiltration en masse, potentially resulting in substantive loss of trust and data. Any software that uses a set of privileged credentials to launch or elevate should be considered “critical.” Such software packages are vulnerable to an array of attacks attempting to retrieve the credentials or use the elevated access of the application to launch secondary or tertiary malware applications to continue to infiltrate a network or probe for additional attack vectors. Zero Trust architectures for privileges and remote access help resolve some of these security concerns, however, require additional controls to be effective end-to-end.

Public-Facing Software

Software that is considered “public facing”, defined by section 508 as “[software] made available by the agency to members of the general public”, provides an extraordinarily vulnerable attack vector into an agency, specifically if the underlying data services also serve internal software or components of the network. These software packages should take precedence as “critical” because a breach of them could open multiple attack vectors into an agency’s network, exposing broader damage as threat actors probe for opportunities.

Best Practices for Securing Critical Software

A robust strategy to secure critical software should include:

1. Systems hardening and vulnerability and configuration management
2. Privileged access management (PAM) and application control
3. Zero trust architecture, with an emphasis on least privilege, executed on an agency’s network.

Each of the three above areas overlap, and in each of these, the principle of least privilege (PoLP) is a strong underlying theme. Why is that? Almost every attack (malware, external hacker, insider, etc.) today requires privilege—either to execute and initially compromise an environment, and/or to move laterally within an organization’s systems.

The more privileges a piece of software or application, user, account, or process has, the greater the potential for abuse, exploit, or error. Today, many planes of privileges are being created at tremendous scale due to digital transformation, cloud expansion, virtualized environments, and IoT. Remote workers pose many compounding risks as well.

Applying the principle of least privileges (PoLP) is one of the most powerful and well-recognized ways of securing software from attack and preventing misconfigurations, while also protecting organizations from rogue, compromised, or misused applications. A least privilege security posture can not only outright eliminate many types of malware and other attacks from executing and gaining a foothold, it can also essentially maroon attackers who do gain a foothold by sharply reducing potential for privilege escalation and lateral movement, which are also key parts of the cyberattack chain. Lateral movement, after all, means all the difference between compromising a single asset and potentially navigating throughout an organization to establish a persistent presence. 70% of attacks today are reported to involve some form of lateral movement. And today, it’s the scale and disruption wrought by society-shaking breaches (SolarWinds Orion, Colonial Pipeline, Verkada, etc.) that should concern us all.

1. Systems Hardening & Vulnerability & Configuration Management

The first strategy, systems hardening and vulnerability and configuration management, provide a baseline for secure software. In rushing to support a large remote workforce during the early days of the COVID-19 pandemic, agencies and enterprises relaxed their hardening policies. In March 2020, internet-facing RDP ports increased by 50% in an ill-advised attempt to support these WFH initiatives. Over the following 12 months, 52% of ransomware attacks leveraged publicly accessible RDP servers to gain initial access. These breaches are a direct result of ignoring basic system and network hardening tenets.

Systems should be regularly scanned and have automated ways to remove unnecessary, or block-listed, software and applications. Agencies must automate the process of privilege discovery, auditing, and onboarding across their environment to encompass the activities of humans, applications, and machines to ensure these are not leveraged to gain access to the installed critical software. These controls should be applied prior to the device/endpoint receiving access to an agency’s network.

Hardening activities should be rigorously enforced across the device lifecycle. The proliferation of BYOD and work-from-home amongst federal and civilian workforces increases the necessity for the continual scan and hardening of such devices, especially if they periodically leave and enter the agency physically and connect to its network.

Attackers leveraging known vulnerabilities is not new. However, this practice continues to give attackers a high rate of success in compromising their targets and is a common component of attack chains. In late 2020, the FBI and CISA warned that APT hackers are targeting government networks, critical infrastructure, and election organizations with chained vulnerability cyberattacks. These attacks were stringing together legacy vulnerabilities to achieve a foothold and continue to progress an attack and could easily be thwarted at multiple stages by patching alone.

A vulnerability management strategy where software, application, and other vulnerabilities are continuously and systematically discovered, assessed, prioritized, and addressed, is critical to hardening the attack surface and preventing attackers from gaining a foothold or escalating an attack. Addressing vulnerabilities can entail patching and/or another mitigation (i.e. a configuration change or use of cybersecurity tools), while accepting a vulnerability could include actions that range from doing nothing to purchasing cyber insurance.

Prioritization is a key component of vulnerability management and essential to effectively address the sheer multitude of vulnerabilities that will exist across any moderately complex IT environment. And patching itself is not always a riskless activity—for instance, it could cause incompatibilities, software disruption, or even bring an application or tool out of compliance. That’s why IT teams need automated tools that can help them make smart vulnerability management decisions fast that minimize the attack surface while preserving uptime.

2. Privileged Access Management (PAM)

Privileged access management (PAM) and application control must be applied across all operating systems and Operational Technology (OT). Agencies must automate the process of privilege discovery, auditing, and onboarding across their environment and beyond the perimeter, to encompass the activities of humans (employees, vendors, on-premise or remote), applications, and machines.

In implementing PAM, agencies should strive to manage privileged credentials. Management of these credentials/accounts also encompasses reducing the number of identities with privileged access, the quantity of privileged access, and the duration of privileged access. This approach not only drastically condenses the attack surface, but also vastly minimizes threat windows.

Credential security best practices should be consistently applied—such as enforcing unique, complex passwords. This helps prevent password re-use and many other attack vectors. For instance, leaving default passwords unchanged, presents one of the easiest attack vectors for threat actors. As much as possible, agencies should also eliminate shared accounts, so there is clear oversight over what a specific identity did with a privileged account. Any hardcoded credentials should be eliminated and replaced with API calls or dynamic secrets, such as with DevOps and CI/CD toolsets.

In 2020, 87% of Critical vulnerabilities in Internet Explorer and Edge would have been mitigated by removing admin rights. A similarly influential risk-reducing power of least-privilege has also been demonstrated across important third-party applications, with a quick search of the National Vulnerability Database, published by NIST, revealing a significant number of registered vulnerabilities mitigated by appropriate Elevated Privilege Management. Eliminating admin rights translates into a significant risk reduction across many platforms, even absent an appropriate patching process in place.

Agencies should remove local admin rights on endpoints and remove all root and admin access rights to servers. Moreover, by defaulting all users to standard privileges, while enabling elevated privileges for applications to perform specific tasks, malware such as samples deployed by Darkside, the group who perpetrated the devastating attack on Colonial Pipeline, could be minimized or fully mitigated.

Privileged access, except in few exceptional and unavoidable cases such as in certain automated workflows, should only be provisioned just-in-time (JIT) when certain contextual parameters are sufficiently met, and subsequently removed or expired immediately upon completion of the activity or change in behavior. Context should also dynamically consider real-time vulnerability and threat data about an application, asset, or user so privileged access may be further restricted or denied, or launch workflows requiring additional approvals or monitoring.

The SolarWinds Orion supply chain attack was particularly devastating because the Orion application needed unrestricted access to work. Since the Orion application itself was compromised, threat actors leveraged this unrestricted privileged access throughout victims' environments using the application. This attack demonstrates why it’s essential for organization to identify and address over-privileged applications, and wherever possible, implement least privilege application management. However, since many legacy applications (i.e., SolarWinds) may not work without these high levels of privilege, agencies should implement more layers of mitigation or discontinue the software’s use in the environment.

Agencies should ensure only authorized applications execute approved functions or communications. This type of control would also prevent unsigned binaries from executing on the system, as used in Darkside malware attacks. This entails exercising granular control over access and privilege elevation for all applications, commands, files, and scripts to prevent or mitigate errors, eliminate privilege sprawl, and reduce the attack surface. Allow lists, block lists, and grey lists should also be applied in tandem with endpoint privilege management to efficiently control application execution. Restricting software and system privileges to the minimal range of processes to perform an authorized activity also reduces the chance of incompatibility issues cropping up between other applications or systems, and helps reduce the risk of downtime, improving overall operational performance.

Trusted applications (Powershell, Wscript, Csript, etc.) are often leveraged as part of the attack chain (i.e. in Darkside ransomware attacks) as advanced persistent threats (APTs) that allow attackers to wield and abuse an organization’s legitimate tools under the radar to conduct their activities. In fact, fileless attacks surged 888% in 2020, and were often part of ransomware campaigns. By applying context-rich privileged access security controls, such as content and application control rules and control over launch of child processes, agencies can protect trusted applications from misuse.

Agencies should strive to provide secure application access independent of VPN access, only enabling contractors and vendors the applications and systems they need. This will increase protection against malicious insiders, external actors, and human errors. Increasingly, attackers are exploiting inadequately protected cloud applications using control planes inadvertently or recklessly exposed to the Internet. Agencies should proxy access to control planes and other critical software to segment and isolate remote access traffic in the cloud. In addition, admin access should be locked down and discoverable to authorized admins only through secure encrypted connections. Providing a locked-down, isolated browser that supports automatic web credential injection is recommended to prevent end users from ever interacting with any credentials.

In addition, non-Windows IT administrators should be assigned commands they can execute and run elevated without needing sudo or root. Agencies should use a policy language that can elevate commands via least privilege and inspect all the options and switches. This allows it to identify malformed or inappropriate commands, which could cause downtime of critical software and expose attack vectors that can be exploited.

Adhering to the security principle of “Individual Accountability” where privileged accounts are not shared, rather a privileged account is restricted to one user at a time, gives organizations clear oversight into what actions specific users/identities are performing with the elevated access. Also, organizations should apply, privilege separation, which involves defining and delineating employee, application, and system roles and tasks so that access is only granted to specific, discrete parts of systems or data, as necessary, and each account can only perform a specific, narrow range of actions. Separation of privileges helps contain intruders close to the point of compromise and restricts lateral movement. Thus, if one account is compromised, the range of privileges it affords the attacker is limited.

The Verkada breach provides a striking illustration of how a breach scope can get to mind-boggling size when separation of privilege and separation of duties are not implemented. In 2020, Verkada network exposed the live feeds of 150,000 security cameras used in jails, hospitals, and even companies like Tesla. The exposure revealed live feeds from some incredibly sensitive environments including women’s health clinics, psychiatric facilities, and even police departments. Many controls (removing admin rights, etc.) detailed in this section would have helped prevent or mitigate this breach, as would separation of privilege. No one account should have control over so many different customer accounts and have such high-level privileges across so many systems. It is a glaring example of unchecked privileged access controls and segregation. Rather than having one superuser account perform all of an IT admin’s duties, implement separation of privileges and duties across different accounts, with each account requiring unique login credentials and used only for a specific set of functions/tasks. Some practical ways agencies and enterprises can implement separation of privilege include:

• Separating various administrative account functions from each other
• Separating administrative and standard account capabilities
• Separating auditing and logging capabilities within administrative accounts
• Separating software functions like read, edit, write, execute, etc.

Zero Trust Architecture

Multiple strategies for segmenting access can be applied to help enforce least privilege and enable zero trust principles. Segmentation efficaciously helps organizations, in broad strokes, protect the new attack surfaces created by digital transformation and cloud deployments. It is also an essential strategy for protecting sensitive software, applications, and environments, from encroaching on network-based technologies.

Verifying every attempted access through proper identity controls with location awareness, identity authentication, MFA, and assuming every attempt at access is a threat actor until verified, allow for an identity-centric approach to network segmentation. In this model, the network is not segmented necessarily by network or data link layer devices, it elevates the segmentation and authentication authority to the application layer. Application-level micro-segmentation should be implemented to prevent users from discovering applications they are not authorized to access.

One of the central tenants of zero trust architecture is the continuous and dynamic monitoring of identities that access the network. Agencies should monitor this architecture and manage any session involving privileged activity, whether by human, application, or machine. Monitoring should include performing screen recording command logging, scripts executed, and screen outputs. Anomalous activity should be flagged, with the ability to pinpoint, pause, and terminate suspicious sessions in real-time. Privilege analytics should also be performed to spot potential issues and to optimize a least privilege posture, such as removing unused privileges.

Next Steps toward Protecting Critical Applications & Software

Success in cybersecurity is about identifying and assessing risks, understanding the implications of remediating, or accepting those risks, prioritizing any planned remediation, and effectively executing on that risk management plan. A key part of this process hinges on understanding which assets and risks are most critical, and how they can effectively be protected.

Securing critical software packages in a federal network must include a multi-tiered application of security practices to support continuity and integrity of the agency’s mission. Applying appropriate configuration, vulnerability management, and hardening guidelines ensures the agency’s network and software have a solid baseline that can withstand attacks using known vulnerabilities. Privileged access management and application control vastly reduce the risk of unauthorized access, and if a breach occurs, lateral movement is restricted. Zero trust architectures build on the previous two practices, ensuring identities are verified every time a resource is accessed, thus mitigating the risk of an external actor breaching the network plane.

BeyondTrust is recognized by the top analysts as a Leader in Privileged Access Management. We have a unique, multi-pillar Universal Privilege Management approach for securing every privileged identity, asset, and session. Our complete and integrated platform enables organizations to achieve leaps in risk reduction, fast, whether deploying our solutions as on-prem, cloud, hybrid, or SaaS.

For more information on how BeyondTrust can help you harden your attack surface, improve your privileged access security controls, and enable a zero trust environment, contact us today.