Template:Cybersecurity/Access control

From LIMSWiki
Jump to navigationJump to search

AC-1 Access control policy and procedure

This control recommends the organization develop, document, disseminate, review, and update an access control policy. Taking into account regulations, standards, policy, guidance, and law, this policy essentially details the security controls and enhancements "that specify how access is managed and who may access information under what circumstances."[1]

Additional resources:

AC-2 Account management

This control recommends the organization develop a series of account management steps for its information systems. Among its many recommendations, it asks the organization to clearly define account types (e.g., individual, group, vendor, temporary, etc.), their associated membership requirements, and policy dictating how accounts should be managed; appoint one or more individuals to be in charge of account creation, approval, modification, compliance review, and removal; and provide proper communication to those account managers when an account needs to be modified, disabled, or removed.

Additional resources:

AC-2 (3) Account management: Disable inactive accounts

This control enhancement recommends the system have the ability to automatically disable an inactive account after a designated period of time.

Additional resources:

AC-2 (4) Account management: Automated audit actions

This control enhancement recommends the system have the ability to automatically audit creation, modification, enabling, disabling, and removal actions performed on accounts, as well as notify designated individuals or roles of those actions.

Additional resources:

AC-2 (7) Account management: Role-based schemes

This control enhancement recommends the organization take additional action in regards to accounts with privileged roles. NIST defines privileged roles as "organization-defined roles assigned to individuals that allow those individuals to perform certain security-relevant functions that ordinary users are not authorized to perform." The organization should not only use a role-based mechanism for assigning privileges to an account, but also the organization should monitor the activities of privileged accounts and manage those accounts when the role is no longer appropriate.

Additional resources:

AC-2 (11) Account management: Usage conditions

This control enhancement recommends the system allow for the configuration of specific usage conditions or circumstances under which an account type can be used. Conditions or circumstances for account activity may include role, physical location, logical location, network address, or chronometric criterion (time of day, day of week/month).

Additional resources:

AC-3 Access enforcement

This control recommends the system be capable of enforcing system access based upon the configured access controls (policies and mechanisms) put into place by the organization. This enforcement could occur at the overall information system level, or be more granular at the application and service levels.

Additional resources:

AC-6 Least privilege

This control recommends the organization use the principle of "least privilege" when implementing and managing accounts in the system. The concept of least privilege essentially "requires giving each user, service, and application only the permissions needed to perform their work and no more."[2]

Additional resources:

AC-6 (1) Least privilege: Authorize access to security functions

This control enhancement recommends the organization provide access to specific security-related functions and information in the system to explicitly authorized personnel. In other words, one or more specific system administrators, network administrators, security officers, etc. should be given access to configure security permissions, monitoring, cryptographic keys, services, etc. required to ensure the system is correctly protected.

Additional resources:

AC-6 (4) Least privilege: Separate processing domains

This control enhancement recommends the system provide separate processing domains in order to make user privilege allocation more granular. This essentially means that through using virtualization, domain separation mechanisms, or separate physical domains, the overall information system can create additional fine layers of access control for a particular domain.

Additional resources:

AC-6 (9) Least privilege: Auditing use of privileged functions

This control enhancement recommends the system perform auditing functions on any privileged functions that get executed in the system. This allows organizations to review audit records to ensure the effects of intentional or unintentional misuse of privileged functions is caught early and mitigated effectively.

Additional resources:

AC-7 Unsuccessful logon attempts

This control recommends the system be capable of not only enforcing a specific number of failed logon attempts in a given period of time, but also automatically locking or disabling an account until released by the system after a designated period of time, or manually by an administrator.

Additional resources:

AC-8 System use notification

This control recommends the system be configurable to allow the creation of a system-wide notification message or banner before logon that provides vital privacy, security, and authorized use information related to the system. The message or banner should remain on the screen until acknowledged by the user and the user logs on. Note that the wording of such message or banner may require legal review and approval before implementation.

Additional resources:

AC-10 Concurrent session control

This control recommends the system be able to limit the number of concurrent (running at the same time) sessions (log ins) globally, for a given account type, for a given a user, or by using a combination of such limiters. NIST gives the example of wanting to tighten security by limiting the number of concurrent sessions for system administrators or users working in domains containing sensitive data.

Additional resources:

AC-11 Session lock

This control recommends the system be able to prevent further access to a system using a session lock, which activates after a defined period of inactivity or upon a user request. The session lock must be able to remain in place until the user associated with the session again goes through the system's identification and authentication process.

Additional resources:

AC-14 Permitted actions without identification or authentication

This control recommends the organization develop a list of user actions, if any, that can be performed on the system without going through the system's identification and authentication process. Any such list should be documented and provide supporting rationale as to why the authentication can be bypassed. This may largely pertain to public websites or other publicly accessible systems.

Additional resources:

  • No LIMSpec comp (organizational policy rather than system specification)

AC-17 Remote access

This control recommends the organization develop and document a remote access policy that addresses each type of remote access allowed into the system. Remote access involves communicating with the system through an external network, usually the internet. The policy should address the usage restrictions, configuration requirements, connection requirements, and implementation rules for the approved methods (e.g., wireless, broadband, Bluetooth, etc.). Some sort of access enforcement process should take place prior to allowing remote access (see AC-3 for said access enforcement).

Additional resources:

AC-17 (1) Remote access: Automated monitoring and control

This control enhancement recommends the system have the ability to monitor and control remote access methods. By enabling authorized individuals to audit the connection activity of remote users, compliance with remote access policies (see AC-17) can be ensured and cyber attacks caught early.

Additional resources:

AC-17 (2) Remote access: Protection of confidentiality and integrity using encryption

This control enhancement recommends the system have the ability to implement encryption mechanisms for remote access. This involves using "encryption to protect communications between the access device and the institution," using encryption "to protect sensitive data residing on the access device," or both.[3]

Additional resources:

AC-18 Wireless access

This control recommends the organization develop and document a wireless access policy, probably best done in conjunction with AC-17. NIST gives examples of wireless technologies such as microwave, packet radio, 802.11x, and Bluetooth. The policy should address the usage restrictions, configuration requirements, connection requirements, and implementation rules for the approved wireless technologies. Some sort of access enforcement process should take place prior to allowing a wireless connection to the system (see AC-3 for said access enforcement). In most cases this will be a built-in authentication protocol for the wireless network.

Additional resources:

AC-19 Access control for mobile devices

This control recommends the organization develop and document a mobile device (e.g., smart phone, tablet, e-reader) use and access policy. The policy should address the usage restrictions, configuration requirements, connection requirements, and implementation rules for the approved wireless technologies. Some sort of access enforcement process should take place prior to allowing a wireless connection to the system (see AC-3 for said access enforcement).

Additional resources:

AC-20 Use of external information systems

This control recommends the organization develop and document a policy concerning the use of external information systems to access, process, store, and transmit data from the organization's system. External information systems include (but are not limited to) personal devices, private or public computing devices in commercial or public facilities, non-federal government systems, and federal systems not operated or owned by the organization. This includes the use of cloud-based service providers. The organization should consider the trust relationships already established with contractors and other third parties when developing this policy.

  • No LIMSpec comp (organizational policy rather than system specification)

AC-22 Publicly accessible content

This control recommend the organization develop and document policy on the use and management of public-facing components of the system, typically the public website. This control ensures that sensitive, protected, or classified information is not accessible by the general public. The organizational policy should address who's responsible for posting information to the public-facing system; how to verify the information being posted does not contain sensitive, protected, or classified information; and how to monitor the public-facing system to ensure any non-public information is removed upon discovery.

  • No LIMSpec comp (organizational policy rather than system specification)