Logical access requirements are established and maintained (for example, rules for which types of entities are allowed to access an asset, limits of allowed access, constraints on remote access, authentication parameters)

It is the asset owner’s responsibility to ensure that requirements for protecting and sustaining assets are defined for assets under the owner’s control, including requirements for controlling logical access (for example, rules for which types of entities are allowed to access an asset, the limits of allowed access, constraints on remote access, and authentication parameters). For example, the logical access requirements for a specific asset might allow remote access by a vendor only during specified and preplanned maintenance intervals and might also require multifactor authentication for such access. As another example, it may be appropriate to apply additional logical access controls (such as peer review) to high-priority assets. There are several models for access control, such as discretionary access control (DAC), mandatory access control (MAC), role-based access control (RBAC), policy-based access control (PBAC), and attribute-based access control (ABAC). Selection of an access control model will vary based on several factors, such as the operating environment and feasibility of implementation. For example, an organization may choose to implement an access control model that is supported by current infrastructure, such as RBAC, and plan for future implementation of a more advanced model, such as ABAC, as part of an acquisition of new infrastructure the supports additional access control capabilities. Advanced security models, such as Zero Trust, may also inform the development of access requirements. For example, implementation of Zero Trust principles may include the ability to collect and use additional information (such as behavioral information, geolocation information, threat intelligence, and other contextual information) as part of access policy enforcement.

Related Practices · Input From: Implementing ARCHITECTURE-3a provides input that may be useful for implementing this practice. · Progression: This practice is part of a practice progression. Practice progressions are groups of related practices that represent increasingly complete or more advanced implementations of an activity. The practices in this progression include: ACCESS-2a, ACCESS-2c, ACCESS-2d, ACCESS-2e, ACCESS-2f.