id: "SA-17(07)" title: "Structure for Least Privilege" family: "SA" family_name: "System and Services Acquisition" sort_id: "sa-17.07" priority: "P1" implementation_level: "organization" parent: "SA-17" enhancement: True
Statement
Require the developer of the system, system component, or system service to structure security-relevant hardware, software, and firmware to facilitate controlling access with least privilege.
Guidance
The principle of least privilege states that each component is allocated sufficient privileges to accomplish its specified functions but no more (see SA-8(14) ). Applying the principle of least privilege limits the scope of the component’s actions, which has two desirable effects. First, the security impact of a failure, corruption, or misuse of the system component results in a minimized security impact. Second, the security analysis of the component is simplified. Least privilege is a pervasive principle that is reflected in all aspects of the secure system design. Interfaces used to invoke component capability are available to only certain subsets of the user population, and component design supports a sufficiently fine granularity of privilege decomposition. For example, in the case of an audit mechanism, there may be an interface for the audit manager, who configures the audit settings; an interface for the audit operator, who ensures that audit data is safely collected and stored; and, finally, yet another interface for the audit reviewer, who only has a need to view the audit data that has been collected but no need to perform operations on that data.
In addition to its manifestations at the system interface, least privilege can be used as a guiding principle for the internal structure of the system itself. One aspect of internal least privilege is to construct modules so that only the elements encapsulated by the module are directly operated upon by the functions within the module. Elements external to a module that may be affected by the module’s operation are indirectly accessed through interaction (e.g., via a function call) with the module that contains those elements. Another aspect of internal least privilege is that the scope of a given module or component includes only those system elements that are necessary for its functionality, and the access modes to the elements (e.g., read, write) are minimal.
Assessment Objective
the developer of the system, system component, or system service is required to structure security-relevant hardware, software, and firmware to facilitate controlling access with least privilege.
System and services acquisition policy
enterprise architecture policy
procedures addressing developer security architecture and design specifications for the system
solicitation documentation
acquisition documentation
service level agreements
acquisition contracts for the system, system component, or system service
system design documentation
system security architecture documentation
system configuration settings and associated documentation
developer documentation describing the design and structure of security-relevant hardware, software, and firmware components to facilitate controlling access with least privilege
system security plan
other relevant documents or records
Organizational personnel with system and service acquisition responsibilities
organizational personnel with information security responsibilities
system developer
organizational personnel with information security architecture and design responsibilities