Skip to content

Latest commit

 

History

History
214 lines (169 loc) · 8.97 KB

ac_low_impact_pri1.md

File metadata and controls

214 lines (169 loc) · 8.97 KB

NIST 800-53 AC Low Impact Priority 1

This file is generated by a script. To modify, update source file ./ac_low_impact_pri1.yaml.

As the CIO, I want to document and communicate our organization's approach to managing access control mechanisms in our IT systems.

Why:

Access control is central to security compliance, and maintaining sensible rules for what classes of users have access to what types of systems will ensure lasting security for organizational systems.

How:

  • Define roles in addition to ISSO or ISSM that the access control policy is to be disseminated to. (State if there are no additional roles)
  • Define roles in addition to ISSO or ISSM that the access control procedures are to be disseminated to. (State if there are no additional roles)
  • Ensure that the access control policy and procedures are disseminated
  • Define frequency at which to review and update the access control policy and procedures (Annually).
  • Maintain audit trail of reviews and updates.

Acceptance Criteria / Evidence:

  • List of personnel to whom access control policy and procedures are to be disseminated
  • Access control policy
  • Access control policy version update page
  • Access control policy audit trail of reviews and updates

Links:

Labels:

  • AC
  • AC-1
  • security
  • compliance

As the CIO, I want to ensure system accounts are identified, approved, assigned, monitored, and reviewed in accordance with organizational policy.

Why: Having a robust process for the creation and review of IT system accounts ensures that users, and their privileges, are appropriately segmented in the organization.

How:

  • Define types of accounts that exist within an organizational structure (eg. individual, shared, group, system, guest/anonymous, emergency, developer/manufacturer/vendor, temporary, and service).
  • Nominate account managers for existing/future IT system accounts.
  • Define conditions for group and role membership.
  • Assign appropriate access and roles to existing accounts..
  • Define roles to approve new IT system accounts.
  • Manage existing and new accounts with defined policy (create, enable, modify, disable, and remove).
  • Monitor account access across IT systems.
  • Notify account managers when accounts are outdated, when users are no longer in the organization, or when system requirements change.
  • Authorize access in accordance with authorization, intended use, and associated organizational goals.
  • Review accounts at a defined frequency and evaluate compliance with account requirements.
  • Define process for issuing group based credentials when individual accounts

Acceptance Criteria / Evidence:

  • List of types of accounts within an organization
  • List of account managers for each IT system
  • List of conditions for membership in each group and role
  • Logs of the process in which existing accounts have been assigned roles
  • List of personnel who approve new accounts for each system
  • Logs of IT system account access
  • Logs of communication with account managers when account roles and requirements change
  • Logs of process to allow access or a new account to IT systems
  • Logs of existing account review
  • Documented process for re-issuance of group-based credentials upon member change

Links:

Labels:

  • AC
  • AC-2
  • security
  • compliance

As the CIO, I want to not only enforce access control policies for IT systems, but also apply them to applications and services that exist on those systems.

Why: Applications and services that run on IT systems present an equal, if not greater, danger to organizational security if left unexamined.

How:

  • Apply access control policies to applications and services that run on IT systems.

Acceptance Criteria / Evidence:

  • Retain equivalent documentation of access control methods for individual applications that you do for IT systems themselves.

Links: https://web.nvd.nist.gov/view/800-53/Rev4/control?controlName=AC-3

Labels:

  • AC
  • AC-3
  • security
  • compliance

As the CIO, I want to ensure that users are notified of privacy and security concerns when they are logging into or using U.S. Government systems.

Why: Users interacting with U.S. Government systems should be aware of potential privacy and security concerns.

How:

  • Display in notice or banner that users are accessing a U.S. Government system
  • Display in notice or banner that usage may be monitored, recorded, and subject to audit
  • Display in notice or banner that unauthorized usage may incur civil and criminal charges
  • Display in notice or banner that system usage implies consent to these policies
  • If the system is publicly accessible, inform user of the acceptable uses and potential for monitoring, audits, etc.
  • Display the notice or banner until the user acknowledges it

Acceptance Criteria / Evidence:

  • List of systems and their user privacy and security concerns
  • Notice or banner alerts user of relevant information
  • Notice or banner continues to display until user acknowledges it

Links:

Labels:

  • AC
  • AC-8
  • security
  • compliance

As the CIO, I want to create guidelines for different types of remote connections to IT systems and authorize the granting of those connections.

Why: Different types of remote access present unique security concerns. Documenting the individual requirements for each type, and ensuring that authorization is granted accordingly, is key in maintaining organizational security.

How:

  • Define acceptable types of remote access
  • Define restriction, configuration and implementation details for each type of access
  • Authorize the granting of remote connection access

Acceptance Criteria / Evidence:

  • List of organization approved remote access types
  • Remote access policy
  • Remote access authorization policy

Links:

Labels:

  • AC
  • AC-17
  • security
  • compliance

As the CIO, I want to create guidelines for wireless access to IT systems and authorize the granting of those connections.

Why: Wireless access to IT systems by definition can be intercepted, and as a result, present security concerns. Documenting the requirements for wireless access, and ensuring that authorization is granted accordingly, is key in maintaining organizational security.

How:

  • Define restriction, configuration and implementation details of wireless access
  • Authorize the granting of wireless access to IT systems

Acceptance Criteria / Evidence:

  • Wireless access policy
  • Wireless access authorization policy

Links:

Labels:

  • AC
  • AC-18
  • security
  • compliance

As the CIO, I want to create guidelines for organizational mobile devices and authorize the connection of said mobile devices to IT systems.

Why: The distribution of mobile devices within an organization is increasingly common, and as such, having an organizational policy controlling how those devices are used, updated, authenticated and tracked is now a critical task.

How:

  • Define restriction, configuration, connection and implementation details for organization mobile devices
  • Policy points that may be considered:
    • Acceptable types of mobile devices (embedded systems, smartphones, tablets)
    • Acceptable software on mobile devices (Apple iOS, Android, Blackberry, Windows)
    • Required security applications
    • Integrity / version checks
  • Authorize the connection of mobile devices to IT systems

Acceptance Criteria / Evidence:

  • Mobile device policy
  • Mobile device connection authorization policy

Links:

Labels:

  • AC
  • AC-19
  • security
  • compliance

As the CIO, I want to document terms and conditions regarding external access to IT systems and the use of external systems by our organization.

Why: External access to IT systems by contractors, other agencies, etc will inevitably be required in some situations and, similarly, organizational information will need to be dealt with on IT systems external to the organization. Drafting policies governing these cases is a critical step in maintaining strong security.

How:

  • Document terms and conditions regarding access from external systems/devices. May include:
    • Personally owned systems/devices
    • Contractor owned systems/devices
    • Federal agency owned systems/devices
  • Document terms and conditions regarding the use of external systems/devices. May include:
    • Software/Platform as a service
    • Cloud-based hosting
  • Document agencies/entities that may be trusted without additional terms and conditions

Acceptance Criteria / Evidence:

  • External access policy
  • External systems policy
  • List of exempt agencies/entities (if any)

Links:

Labels:

  • AC
  • AC-20
  • security
  • compliance