Every privilege comes with a responsibility. If you don’t take the responsibility, you will lose the privilege.

—Sadhguru

As an observer of cybersecurity practices (and former corporate IT manager), I can only say “if only.”

Taking away privileges is one of the toughest management decisions, whether one is managing pushback from a child (“all my friends are on TikTok and I need my phone for homework”), an aging parent (“I am not a terrible driver and don’t care if I die”), or a staff member (“I’ve always been able to download any software that might be useful”). And yet following the “least privilege principle” is a low-cost practice that, in essence, promotes a certain economy of information access: use, take, collect, only what you need to fulfill your job. The objective is to make sure everyone has the right tools to get their work done.

A minimalist approach to information—and data—access reduces the cost of protection; there is no need to protect what you don’t collect. It reduces the cost of incident response. Exposure is limited when individuals and systems are “out of play” as attack points. It strengthens controls based on technology, policy, and people. It helps mitigate a huge organizational and personal security risk: misappropriation of permissions.

Such misappropriation can lead to information compromise by both internal and external individuals (or systems) whether trusted or not. The mechanisms underlying least privilege weave through multiple security control families contained in NIST SP 800-171r2[i]. Enabling these mechanisms requires a solid understanding of how proprietary information flows through an organization, as well as the roles/responsibilities of individuals handling that information. Mapping this information flow and identifying legitimate job requirements can reveal organizational assumptions of trust that contradict the actual condition of trust.

How does “least privilege” work in the real world?

Identify People Assets: Roles and Responsibilities

The role an individual plays in a small manufacturing company is often complicated. One exercise is to create a simple matrix that captures roles across the x-axis and all business-related responsibilities across the y-axis (my preferences for axis designation). Among the roles designated, consider both internal and external stakeholders: staff (full-time, contingent, temporary, contract), investors, clients, and suppliers (e.g., financial and HR services, IT and security support). The level of detail varies with the organization, as demonstrated in the following two examples. The second figure shows a more granular analysis to answer the RACI questions: who is responsible, who is accountable, who is consulted, and who is informed.[ii]

Responsibility	CEO	CFO	SALES	PRODUCTION	CONTRACTOR
Business development	X		X
Client management	X		X
Project research			X		X
Strategic relationships	X
Proposal development			X
Project management				X
Contractor management		X
Quality control				X
Case studies for website			X		X

Figure 1. Roles and Responsibilities Matrix.

Responsibility	CEO	CFO	SALES	PRODUCTION	CONTRACTOR
Business development	C, I	C, I	R, A
Client management	I	C	R, A
Project research	I	I	R	C	A
Strategic relationships	R, A	C	I
Proposal development	I	R	A	C
Project management	I	I	C	R	A
Contractor management		R	I	A	C
Quality control	I	I	I	R	A
Case studies for website	I	I	R	C	A

Figure 2. Roles and Responsibilities Matrix with RACI elements.

The result is a snapshot that informs decisions about the kind of rights individual job responsibilities require viz a viz information assets. These rights go beyond the binary consideration of whether access is permitted or not. They address what access really means: Does access include rights to read, write, modify, delete, copy, print, or share? Those rights are determined by the responsibilities and can be enforced through group policies that outline what settings individual user groups should have. For example, my granddaughter may require access to her smartphone, but the specific apps, screen time, or hours of use can be limited with parental controls.

As work responsibilities—or homework assignments—change, so should privileges. This requires close cooperation among managers who approve roles changes, internal IT staff or external service providers who implement privilege changes by configuring settings, and HR personnel. Updating privileges supports separation of duties, which is a NIST SP 800-171 security control (thus of particular interest to those in the DoD supply chain). This practice simplifies auditing and monitoring individual activity for anomalous or precursor behavior. Manufacturing companies often rely on “best efforts” to effect this cooperation but do not have a written policy to guide this chain of expected, shared responsibility. Employee training also helps establish best practices around privileges and protecting credentials from misuse.

Identify Product Assets

A company’s product-related assets are more than what it delivers to a customer. They include the physical components associated with corporate information assets: workstations, servers, communication devices, software, cloud services. They also include production equipment and even the facility where work is performed. Least privilege applies here as well. For example, some individuals will not need access to a locked server room or cabinets in which media containing controlled unclassified information (CUI) are stored.

Product assets also refer to less tangible materials that support the company’s success. Access to things like intellectual property, price lists, supplier/client contracts, personally identifiable information about employees should also be limited to those who have a legitimate, job-related need.

Product asset information can be captured in a spreadsheet or table. Network discovery tools automate the process of building an inventory of network-connected devices. Smaller companies with technical and production environments that change infrequently can also track their inventory in an asset inventory register. Such documentation also serves business accounting needs (e.g., equipment depreciation sfor taxes, licensing renewal schedules, technology refreshment planning) and business continuity/disaster recovery planning. Developing an information asset inventory often requires a more time-intensive discovery process that includes cross-departmental collaboration rather than an automated tool.

One technique for gathering inventory data is to send out a survey to departments or individuals that create or use information. This keeps the information—and responsibility, to a large degree—within the IT group. A technique for sharing responsibility more openly is to work through a kind of data repository exercise as follows:

1. Assemble a cross-departmental team (in person is preferable).
2. Distribute sticky notes to all participants and request that they note types of information needed to perform their jobs.
3. Suggest different possible data repositories on a whiteboard: email, smart phone, local drive, shared drive, external drive, file server, cloud, application, and so forth.
4. Ask participants to place their information requirements sticky note under the appropriate location(s).
5. Name the individuals or user groups that have access to those data repository locations and define what that access privilege allows (e.g., read, write, modify, delete, share, print, copy).
6. Discuss whether current access privileges—and the associated risk of information exposure—are appropriate.
7. Determine how access privileges should be defined to maximize productivity and job performance, meanwhile limit risk.

Outcomes from the repository exercise can be captured in a table like the one below.

Figure 3. Sample Data Repository with Information Sensitivity, Recoverability, and Criticality

Information sensitivity designations in the sample translate as controlled unclassified information (CUI), company-proprietary information (CPI), financial (FIN), ITAR, personally identifiable information (PII). Senior management and business process owners will evaluate the criticality of different business information systems according to the business impact they perceive should that information be unavailable or unreliable. 

Privilege Justification as Shared Responsibility

The recommendation (or hope) here is that, by making the process of privilege justification more transparent, team members from across the organization will more fully understand their role in protecting corporate assets. This approach can be used with other stakeholders like members of the board of directors or suppliers who expect privileged access to information without fully understanding their shared responsibility in protecting it.

The end result should be a closer alignment between trust assumptions and trust conditions.

---

[i] Least Privilege: The principle that a security architecture should be designed so that each entity is granted the minimum system resources and authorizations that the entity needs to perform its function. https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-171r2.pdf

[ii] Responsible: Person who is completing the task

Accountable: Person who is making decisions and taking actions on the task(s)

Consulted: Person who will be communicated with regarding the decision-making process and specific tasks

Informed: Person who will be updated on decisions and actions during the project

Understanding Responsibility Assignment Matrix (RACI Matrix)