Managing privileged access for ‘critical’ software
- By Josh Brodbent
- Oct 06, 2021
On May 12, President Joe Biden issued the Executive Order on Improving the Nation’s Cybersecurity. This EO is arguably one of the most significant statements on cybersecurity and software used in the federal government.
A central component of the EO was instructing the National Institutes of Standards and Technology to collaborate with the private sector and educational institutions to define “critical software.” On June 25, NIST posted a white paper that described software as “EO-critical” if it has, or has dependencies on, 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 (OT).
- Performs a function critical to trust.
- Operates outside of normal trust boundaries with privileged access.
NIST worked with the Cybersecurity and Infrastructure Security Agency and the Office of Management and Budget to ensure these attributes matched their vision for the future. Eventually CISA will use these attributes to develop a list of categories and products that it will define as critical software. The White House is starting with an agreed upon definition to build out what is essentially a baseline for cybersecurity standards, specifically around software.
Three out of the five attributes recognized by NIST explicitly deal with privilege, while the other two concern aspects of privileged access security. The first attribute, deeming any software designed to run with privilege or manage privilege as critical software, should be taken at face value, considering the opportunity for attack these products pose if not correctly implemented. The second attribute concerns any software that has direct or privileged access to networking resources. Here NIST moves past what manages privilege to look at where that privilege grants access.
In the third and fourth attributes, NIST ostensibly takes a break from privilege. However, the third attribute, controlling access to data and OT, is also clearly within the domain of privilege management as it involves privileged accounts. As seen in recent attacks on infrastructure, threat actors leveraging privileged accounts on OT devices can prove devastating. This category is an often-overlooked problem, and one that both CISA and the National Security Agency reacted to in June 2020 by issuing statements warning the security and posture of OT technology inside the federal government were not sufficient to protect agencies from threat actors.
Attributes four and five both essentially state that software performing any action critical to trust in the network or performing actions outside that trust that require privilege access should be defined as critical.
This first step in defining critical software validates the concept that privileged access management is arguably the most foundational security needed to help achieve the EO’s objectives of protecting critical software and supply chains. In addition, PAM is one of the core sets of technology that is necessary to enable zero trust, which is another broader objective called out in the Biden EO.
To protect critical software as well as to prevent misuse of critical software, agencies should focus on the following three privileged access security controls:
- Privileged password management: This entails discovering and bringing all privileged accounts (human, application, machine, employee, vendor) and credentials (passwords, secrets, keys) under management. Password security best practices -- such as uniqueness, complexity, rotation, etc. -- should be enforced across all credentials. In addition, all embedded credentials, such as may be found in applications, scripts, internet-of-things devices and various tools, should be removed, vaulted and replaced with API calls or dynamic secrets.
- Endpoint privilege management: This encompasses applying the principle of least privilege across all devices and endpoints, applications, systems, etc. Ideally, this is also combined with application control to more effectively and granularly control applications.
- Secure remote access: This involves managing and protecting all remote privileged sessions, whether by employees or vendors. Privileged access security best practices must be extended beyond the perimeter. This capability can also be applied to proxy access to sensitive assets and control planes, such as those found in cloud/virtualization consoles and web applications.
By implementing these three key areas of PAM, agencies can substantively boost protection of critical software and harden supply chain security while also enhancing protection for other assets and identities across the agency.
Josh Brodbent is senior public sector security director at BeyondTrust.