R096. Set users' required privileges

Requirement

The privileges required by the users who will access the system must be defined.

Description

Systems should have a set of roles with different levels of privilege to access resources. The privileges of each role must be clearly defined and the role of each user should also be clearly stated.

References

  1. CAPEC-1: Accessing Functionality Not Properly Constrained by ACLs. In the case that the administrator failed to specify an Access Control List (ACL) for a particular element, an attacker may be able to access it with impunity. An attacker with the ability to access functionality not properly constrained by ACLs can obtain sensitive information and possibly compromise the entire application.

  2. CAPEC-122: Privilege Abuse. An adversary is able to exploit features of the target that should be reserved for privileged users or administrators but are exposed to use by lower or non-privileged accounts. Access to sensitive information and functionality must be controlled to ensure that only authorized users are able to access these resources.

  3. CIS Controls. 14.6 Protect Information Through Access Control Lists. Protect all information stored on systems with file system, network share, claims, application, or database specific access control lists.

  4. CWE-250: Execution with Unnecessary Privileges The software performs an operation at a privilege level that is higher than the minimum level required, which creates new weaknesses or amplifies the consequences of other weaknesses.

  5. CWE-276: Incorrect Default Permissions. The product, upon installation, sets incorrect permissions for an object that exposes it to an unintended actor.

  6. CWE-287: Improper Authentication. When an actor claims to have a given identity, the software does not prove or insufficiently proves that the claim is correct.

  7. CWE-306: Missing Authentication for Critical Function. The software does not perform any authentication for functionality that requires a provable user identity or consumes a significant amount of resources.

  8. HIPAA Security Rules 164.312(a)(1): Access Control: Implement technical policies and procedures for electronic information systems that maintain electronic protected health information to allow access only to those persons or software programs that have been granted access rights as specified in 164.308(a)(4)

  9. HIPAA Security Rules 164.312(d): Person or Entity Authentication: Implement procedures to verify that a person or entity seeking access to electronic protected health information is the one claimed.

  10. NERC CIP-005-5. B. Requirements and measures. R1.3 Require inbound and outbound access permissions, including the reason for granting access, and deny all other access by default.

  11. NIST 800-53 AC-2 (6) The information system implements the following dynamic privilege management capabilities: [Assignment: organization-defined list of dynamic privilege management capabilities].

  12. NIST 800-53 AC-2 (7) a The organization establishes and administers privileged user accounts in accordance with a role-based access scheme that organizes allowed information system access and privileges into roles.

  13. NIST 800-53 AC-2 (7) b The organization monitors privileged role assignments.

  14. NIST 800-53 AC-2 (7) c The organization Takes [Assignment: organization-defined actions] when privileged role assignments are no longer appropriate.

  15. OWASP Top 10 A5:2017-Broken Access Control. Restrictions on what authenticated users are allowed to do are often not properly enforced. Attackers can exploit these flaws to access unauthorized functionality and/or data, such as access other users' accounts, view sensitive files, modify other users' data, change access rights, etc.

  16. OWASP-ASVS v4.0.1 V1.2 Authentication Architectural Requirements.(1.2.1) Verify the use of unique or special low-privilege operating system accounts for all application components, services, and servers.

  17. OWASP-ASVS v4.0.1 V4.1 General Access Control Design.(4.1.4) Verify that the principle of deny by default exists whereby new users/roles start with minimal or no permissions and users/roles do not receive access to new features until access is explicitly assigned.

  18. OWASP-ASVS v4.0.1 V13.2 RESTful Web Service Verification Requirements.(13.2.1) Verify that enabled RESTful HTTP methods are a valid choice for the user or action, such as preventing normal users using DELETE or PUT on protected API or resources.

  19. PCI DSS v3.2.1 - Requirement 6.5.8 Address common coding vulnerabilities in software-development processes including improper access control (such as insecure direct object references, failure to restrict URL access, directory traversal, and failure to restrict user access to functions).

  20. PCI DSS v3.2.1 - Requirement 7.1.1 Define access needs for each role, including level of privilege required (for example, user, administrator, etc.) for accessing resources.

  21. PCI DSS v3.2.1 - Requirement 7.1.3 Assign access based on individual personnel’s job classification and function.

  22. PCI DSS v3.2.1 - Requirement 7.2.2 This access control system(s) must include assignment of privileges to individuals based on job classification and function.

  23. PCI DSS v3.2.1 - Requirement 10.5.1 Limit viewing of audit trails to those with a job-related need.

  24. PCI DSS v3.2.1 - Appendix A1 A1.1 Ensure that each entity only runs processes that have access to that entity’s cardholder data environment.

Copyright © 2020 Fluid Attacks, We hack your software. All rights reserved.

Service status - Terms of Use - Privacy Policy - Cookie Policy