Embracing Zero Trust (Part 2 of 7): Least-Privilege Access

Summary

Schneider Electric has seven principles in our Zero Trust model, which focuses on how we routinely verify, authorize, and validate users of our IT and OT infrastructures to prevent potential compromises to critical data and systems. This blog delves into our second zero trust principle which is Least-Privilege Access, a concept that is essentially a fundamental requirement of security and a core building block of any zero-trust model.

Like almost all companies that implement this, least-privilege access helps Schneider Electric ensure that users only have access to exactly what they need—nothing more, nothing less. By identifying and limiting our users’ access rights to what is strictly necessary, we not only reduce our exposure to malware and cyber-attacks, but we also bolster productivity by affording people with exactly what they need to do their jobs.
 
Limiting access rights also has the benefit of reminding people that cybersecurity principles like least privilege are important to everyone in our company, even for those who feel like they are not directly impacted by or susceptible to cybersecurity risks.

Least-privilege access: Simple in concept, complicated in execution

The starting point for least-privilege access is easy. All our new users begin with the bare-minimum amount of access required for the least-sensitive functions; these are referred to as least-privileged users (LPUs). Moving forth, we grant privileges on an individualized basis while keeping track of what privileges have been granted and to whom.
 
Instead of solely granting permanent privileges, we place time limits on access permissions, giving people temporary privileges if they need access for a specific task for a certain amount of time. Temporary privileges can either be granted within a specific timeframe before expiring or until the task is done. In the case of the latter, we often create and track one-time-use credentials while conducting due diligence to ensure that such permissions are revoked afterwards.

The fine balance between required access and privilege creep

As advancements in smart technologies and automated processes require an increasingly larger workforce with more unique access control requirements, implementing the principle of least-privilege access in our organization can get complicated.
 
For instance, we take an active role in managing access privileges to ensure that users have the requisite permissions to fulfill vital tasks. However, we also must actively remove access controls from those who no longer require them to prevent privilege creep, which is the overabundance of permissions to sensitive systems granted to users who no longer need them to perform their functions.
 
Privilege creep significantly opens up organizations like Schneider Electric to cyber vulnerabilities. Limiting the number of users with certain access not only reduces our risk of data loss, corruption, or theft, but it also makes traceability of the source for those problems far more efficient.

Privilege access is multifaceted and multileveled

Another complexity in least-privilege access is the creation of clearly defined parameters for different levels of access. This may sound simple, but on a daily basis, we can have over 600,000 assets or devices around the world that access our networks at any given moment.
 
Therefore, we need go beyond just granting individual access and address privilege when it comes to activities like access to systems and applications as well. One way to do this is through the use of authorization controllers. We already have centralized controllers in place who grant access to our key applications, such as our ERP systems, as well as to our databases and source code repositories. We recently extended this concept to apply to applications in our company that may be used strictly within a department or business unit.
 
This is particularly helpful in smaller environments, like in software development, for instance. There may be five or ten thousand developers that need access to specialized applications that are not centrally managed. The application controller responsible for these applications is familiar with the environment and its users, so they can easily manage what is appropriate access to those applications.
 
We are also putting application security gateways in place which help us enable least-access privileges as applications are onboarded. With these gateways in place, we can identify which users and devices need access to newly onboarded applications, which adds another layer of protection.  

Least-privilege access is not a nicety: It’s a necessity

Practicing the principle of least-privilege access is not only the responsible thing for Schneider Electric to do — it is a necessity we must address to best serve our customers. For instance, access privileges are often part of the requirements of global industrial standards that our customers must adhere to be compliant. Cybersecurity regulations and standards series—such as IEC 62443, ISO 27001, the NIS Directive, LPM, NERC CIP, and NIST SP-800-82—each contain highly complex requirements regarding access privileges.
 
By making least privilege access a matter of well-documented policy, we are not only able to attain cyber standards certifications required by our customers but also prove compliance in case of an audit by regulatory agencies.

Trusting nothing—and verifying everything

When it comes to cybersecurity, hypervigilance is crucial while even the slightest bit of slack can be disastrous. As a core tenet of our zero-trust philosophy, least-privilege access helps us practice a “trust nothing and verify everything” philosophy.
 
We encourage other organizations who seek to protect their critical systems and data actively manage privileges to ensure they are granted, reprovisioned, and removed properly. While such scrupulous oversight comes at a cost, it is more than recouped by mitigating potential cyber-attacks and reducing inefficiencies by ensuring employees always have the exact privileges they need to do their jobs.

_{Read part 1 of this series here.}