Data Security Checklist_AED Mgmt and Maint.xlsx

Open to Public

Moderate Baseline Requirements

Sensitive PII

EPHI HIPAA

1. System and application file access.

2. System change attempts.

3. User and Service account changes, including:

a. Account creation.

b. Account role changes/modification.

c. Deletion.

4. Use of privileged user account.

5. The application logs activities of privileged users.

6. Changes to the security configuration (e.g. change of user(s) privileges, deletion of audit log, etc.) of the solution logged.

* Identify and respond to suspected or known security incidents

* Mitigate, to the extent practicable, harmful effects of security incidents that are known to the covered entity

* Documents security incidents and their outcomes

FTI

a. Define and document the types of accounts allowed and specifically prohibited for use within the system;

b. Assign account managers;

c. Require conditions for group and role membership;

d. Specify:

1. Authorized users of the system;

2. Group and role membership; and

3. Access authorizations (i.e., privileges) and other attributes (as required) for each account.

e. Require approvals by the system owner or designated representative for requests to create accounts;

f. Create, enable, modify, disable and remove accounts in accordance with agency account management procedures prerequisites;

g. Monitor the use of accounts;

h. Notify account managers and designated agency official within:

1. 24 hours when accounts are no longer required;

2. 24 hours when users are terminated or transferred; and

3. 24 hours when system usage or need-to-know changes for an individual;

i. Authorize access to the system based on:

1. A valid access authorization;

2. Intended system usage; and

3. Under the authority to re-disclosed FTI under the provisions of IRC § 6103;

j. Review accounts for compliance with account management requirements annually for user account and semi-annually for privileged accounts;

k. Establish and implement a process for changing shared or group account authenticators (if deployed) when individuals are removed from the group; and

l. Align account management processes with personnel termination and transfer processes.

4.1 AC - Access Control AC-3 Access Enforcement

Enforce approved authorizations for logical access to information and system resources in accordance with applicable access control policies.

(IRS-Defined): Users having accounts with administrator access privileges may access those accounts only from agency-owned or authorized contractor systems.

Supplemental Guidance: A key intent is to prohibit personally-owned or public kiosk (e.g., library) systems from being used for remote administrator access. If individuals with administrator rights require email or Internet access beyond local boundaries, one alternative would be to issue separate, non-privileged accounts (one per affected individual) for that purpose. For the considerations of this section, administrator accounts/rights are those that allow for the installation or configuration of software on agency assets receiving, processing, storing, accessing, protecting and/or transmitting FTI.

4.1 AC - Access Control AC-4 Information Flow Enforcement

Enforce approved authorization for controlling the flow of information within the system and between interconnected systems based on the technical safeguards in place to protect FTI

4.1 AC - Access Control AC-5 Separation of Duties

a. Identify and document separate duties of individuals to prevent harmful activity without collusion; and

b. Define system access authorizations to support separation of duties.

4.1 AC - Access Control AC-6 Least Privilege

Employ the principle of least privilege, allowing only authorized accesses for users (or processes acting on behalf of users) that are necessary to accomplish assigned organizational tasks.

4.1 AC - Access Control AC-7: Unsuccessful Logon Attempts

a. Enforce a limit of three (3) consecutive invalid logon attempts by a user during a 120-minute period; and

b. Automatically lock the account for 15 minutes or until released by an administrator when the maximum number of unsuccessful attempts is exceeded.

4.1 AC - Access Control AC-8: System Use Notification

a. Display a warning banner to users before granting access to the system that provides privacy and security notices consistent with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines and state that:

1. Users are accessing a U.S. Government System;

2. System usage may be monitored, recorded, and subject to audit;

3. Unauthorized use of the system is prohibited and subject to criminal and civil penalties; and

4. Use of the system indicates consent to monitoring and recording;

b. Retain the notification message or banner on the screen until users acknowledge the usage conditions and take explicit actions to log on to or further access the system; and

c. For publicly accessible systems:

1. Display system use information warning banner before granting further access to the publicly accessible system;

2. Display references, if any, to monitoring, recording, or auditing that are consistent with privacy accommodations for such systems that generally prohibit those activities and

3. Include a description of the authorized uses of the system.

Supplemental Guidance: The warning banner must be applied at the application, database, operating system, and network device levels for all systems that receive, process, store, or transmit FTI.

4.1 AC - Access Control AC-11: Device Lock

a. Prevent further access to the system by initiating a device lock after 15 minutes of inactivity; requiring the user to initiate a device lock before leaving the system unattended; and

b. Retain the device lock until the user reestablishes access using established identification and authentication procedures.

Supplemental Guidance: Device locks are temporary actions taken to prevent logical access to organizational systems when users stop work and move away from the immediate vicinity of those systems but do not want to log out because of the temporary nature of their absences. Device locks are implemented where session activities can be determined. This is typically at the operating system level but can also be at the application level. Device locks are not an acceptable substitute for logging out of systems, for example, if organizations require users to log out at the end of workdays.

4.1 AC - Access Control AC-12: Session Termination

Automatically terminate a user session after 30 minutes of inactivity.

Supplemental Guidance: This control addresses the termination of user-initiated logical sessions in contrast to SC-10 which addresses the termination of network connections that are associated with communications sessions (i.e., network disconnect). A logical session (for local, network and remote access) is initiated whenever a user (or process acting on behalf of a user) accesses an agency system. Such user sessions can be terminated without terminating network sessions. Session termination terminates all processes associated with a user’s logical session except those processes that are specifically created by the user (i.e., session owner) to continue after the session is terminated. Conditions or trigger events requiring automatic session termination can include, for example, organization-defined periods of user inactivity, targeted responses to certain types of incidents, time-ofday restrictions on system use.

4.1 AC - Access Control AC-14: Permitted Actions Without Identification or Authentication

a. Identify specific user actions that can be performed on the system without identification or authentication consistent with organizational mission and business functions and

b. Document and provide supporting rationale in the security plan for the system, user actions not requiring identification or authentication.

Supplemental Guidance: This control addresses situations in which agencies determine that no identification or authentication is required in agency systems. Agencies may allow a limited number of user actions without identification or authentication including, for example, when individuals access public websites. Access to FTI without identification and authentication is strictly prohibited.

4.1 AC - Access Control AC-17: Remote Access

a. Establish and document usage restrictions, configuration/connection requirements and implementation guidance for each type of remote access allowed; and

b. Authorize each type of remote access to the system prior to allowing such connections.

Supplemental Guidance: Remote access is access to agency systems (or processes acting on behalf of users) communicating through external networks such as the Internet. Remote access methods include, for example, dial-up, broadband, and wireless. Remote access controls apply to systems other than public web servers or systems designed for public access. Any remote access where (i) FTI is accessed or (ii) an FTI environment is administered over the remote connection must be performed using multifactor authentication. Requirements of multifactor authentication are provided in NIST Control IA-2: Identification and Authentication (Organizational Users).

4.1 AC - Access Control AC-18: Wireless Access

1. Establish configuration requirements, connection requirements, and implementation guidance for each type of wireless access; and

2. Authorize each type of wireless access to the system prior to allowing such connections

4.1 AC - Access Control AC-19: Access Control for Mobile Devices

a. Establish configuration requirements, connection requirements and implementation guidance for organization-controlled mobile devices to include when such devices are outside of controlled areas; and

b. Authorize the connection of mobile devices to organizational systems.

Supplemental Guidance: A mobile device is considered a computing device that has a small form factor such that it can easily be carried by a single individual; is designed to operate without a physical connection; possesses local, non-removable or removable data storage; and includes a self-contained power source. Mobile device requirements are not applicable to laptop computers.

4.1 AC - Access Control AC-20: Use of External Systems

a. Establish terms and conditions, consistent with the trust relationships established with other organizations owning, operating and/or maintaining external systems, allowing authorized individuals to:

1. Access the system from external systems; and

2. Process, store, or transmit organization-controlled information using external systems; or

b. Prohibit the use of non-agency managed external systems.

Supplemental Guidance: External information systems, or non-agency-owned equipment, include any technology used to receive, process, store, access, protect and/or transmit FTI that is not owned and managed by 1) the agency or the agency-run mobile device management system, 2) a state's consolidated IT office, 3) one of the agency's approved contractors or sub-contractors (e.g., print vendors, collections agencies, application development contractors, network engineers at a state consolidated IT office, etc.) or 4) one of the agency's constituent counties. To ensure a third-party contractor system is not considered an external information system, the agency must include Exhibit 7 language in its contract with the service provider. Examples of external information systems include but are not limited to: 1) personally-owned devices, which includes any device owned by an individual employee, rather than the agency itself; and 2) devices owned and managed by agency stakeholders that do not have proper approvals to receive, process, store, access, protect and/or transmit FTI.

4.1 AC - Access Control AC-21: Information Sharing

a. Enable authorized users to determine whether access authorizations assigned to a sharing partner match the information’s access and use restrictions for information sharing circumstances where user discretion is required and permitted by IRC § 6103; and

b. Employ automated mechanisms or manual processes compliant with IRC § 6103 to assist users in making information sharing and collaboration decisions.

Supplemental Guidance: The agency must restrict the sharing/re-disclosure of FTI to only those authorized in IRC § 6103 and as approved by the Office of Safeguards.

4.1 AC - Access Control AC-22: Publicly Accessible Content

a. Designate individuals authorized to make information publicly accessible;

b. Train authorized individuals to ensure that publicly accessible information does not contain nonpublic information;

c. Review the proposed content of information prior to posting onto the publicly accessible system to ensure that nonpublic information is not included; and

d. Review the content on the publicly accessible system for nonpublic information at a minimum quarterly and remove such information, if discovered.

Supplemental Guidance: FTI is considered nonpublic information and may never be posted or shared on a publicly accessible system.

4.1 AC - Access Control AC-23: Data Mining Protection

Employ agency-defined data mining prevention and detection techniques for agency-defined data storage objects to detect and protect against unauthorized data mining.

4.2 AT - Awareness and Training AT-2: Awareness Training

a. Provide security and privacy literacy training to system users (including managers, senior executives, and contractors):

1. As part of initial training for new users and annually thereafter; and

2. When required by system changes or following assessment or audit findings, security or privacy incidents, or changes in applicable laws, executive orders, directives, regulations, policies, standards, and guidelines;

b. Employ the following techniques to increase the security and privacy awareness of system users by providing one or more short ad hoc sessions and include topical information on recent attack schemes, changes to organizational security and privacy policies, revised security and privacy expectations, or a subset of topics from the initial training.

c. Update literacy training and awareness content annually and following system changes and

d. Incorporate lessons learned from internal or external security or privacy incidents into literacy training and awareness techniques.

4.2 AT - Awareness and Training AT-3: Role-Based Training

a. Provide role-based security and privacy training to personnel with the following roles and responsibilities: information system security manager (ISSM); information system security officer (ISSO); security specialist; system and software developers; system, network and database administrators; programmer/systems analyst; and personnel having access to FTI

1. Before authorizing access to the system, information, or performing assigned duties, and annually thereafter; and

2. When required by system changes;

b. Update role-based training content annually and following system changes and Update literacy training and awareness content annually and following system changes; and

c. Incorporate lessons learned from internal or external security or privacy incidents into role-based training.

Supplemental Guidance: Agencies may determine the appropriate content of security and privacy training based on the assigned roles and responsibilities of individuals and the specific security and privacy requirements of organizations and the systems to which personnel have authorized access, including security-related technical training specifically tailored for assigned duties. Additional roles that may require role-based security and privacy training include, for example, system owners; authorizing officials; system security officers; privacy officers; enterprise architects; acquisition and procurement officials; systems engineers; personnel conducting configuration management activities; personnel performing verification and validation activities; auditors; personnel having access to system-level software; security and privacy control assessors; personnel with contingency planning and incident response duties; and personnel with privacy management responsibilities.

4.2 AT - Awareness and Training AT-4: Training Records

a. Document and monitor information security and privacy training activities, including security and privacy awareness training and specific role-based security and privacy training; and

b. Retain individual training records for a period of five (5) years

4.2 AT - Awareness and Training AT-6: Training Feedback

Provide feedback on organizational training results to the following personnel: Agency Senior Management and Agency Disclosure Personnel on an annual basis.

4.3 AU - Audit and Accountability AU-2: Audit Events

a. Identify the types of events that the system is capable of logging in support of the audit function:

1. All accesses or attempts to access an FTI system, including the identity of each user and device;

2. Logoff activities;

3. Activities that might modify, bypass, or negate IT security safeguards;

4. Security-relevant actions associated with processing FTI;

5. User generation of reports and extracts containing FTI;

6. Any interaction with FTI through an application;

7. Password changes;

8. Creation or modification of groups;

9. Privileged user actions;

10. Access to the system;

11. Creating and deleting files;

12. Change of permissions or privileges;

13. Command line changes and queries;

14. Changes made to an application or database;

15. System and data interactions;

16. Opening and/or closing of files; and

17. Program execution activities.

b. Coordinate the event logging function with other organizational entities requiring audit related information to guide and inform the selection criteria for events to be logged;

c. Specify the following event types for logging within the system: agency-defined subset of AU-2a requirements (e.g. Systems capable of required event types relevant to the use or administration of FTI);

d. Provide a rationale for why the event types selected for logging are deemed to be adequate to support after-the-fact investigations of incidents; and

e. Review and update the event types selected for logging annually or when there is a system change. Document changes in the SSR.

4.3 AU - Audit and Accountability AU-3: Content of Audit Records Ensure that audit records contain information that establishes the following:

a. What type of event occurred;

b. When the event occurred;

c. Where the event occurred;

d. Source of the event;

e. Outcome of the event; and

f. Identity of any individuals, subjects, or objects/entities associated with the event

4.3 AU - Audit and Accountability AU-4: Audit Storage Capacity Allocate audit log storage capacity to accommodate the retention of audit records for the retention period.

4.3 AU - Audit and Accountability AU-5: Response to Audit Processing Failures

a. Alert designated organizational officials (e.g., SA, ISSO) in the event of an audit processing failure; and

b. Take the following additional actions:

1. Monitor system operational status using operating system or system audit logs and verify functions and performance of the system. operating system or system audit logs and verify functions and performance of the system. Logs shall be able to identify where system process failures have taken place and provide information relative to corrective actions to be taken by the system administrator

2. If logs are not available, shut down the system.

4.3 AU - Audit and Accountability AU-6: Audit Review, Analysis and Reporting

a. Review and analyze system audit records weekly for indications of inappropriate or unusual activity and the potential impact of the inappropriate or unusual activity;

b. Report findings to the individual(s) specified within the agency’s incident response procedures; and

c. Adjust the level of audit record review, analysis, and reporting within the system when there is a change in risk based on law enforcement information, intelligence information, or other credible sources of information.

4.3 AU - Audit and Accountability AU-7: Audit Reduction and Report Generation Provide and implement an audit record reduction and report generation capability that:

a. Supports on-demand audit record review, analysis, and reporting requirements and after-the-fact investigations of incidents; and

b. Does not alter the original content or time ordering of audit records.

4.3 AU - Audit and Accountability AU-8: Time Stamps

a. Use internal system clocks to generate time stamps for audit records; and

b. Record time stamps for audit records that meet agency-defined granularity and that use Coordinated Universal Time, have a fixed local time offset from Coordinated Universal Time, or that include the local time offset as part of the time stamp.

4.3 AU - Audit and Accountability AU-9: Protection of Audit Information

a. Protect audit information and audit logging tools from unauthorized access, modification, and deletion; and

b. Alert ISSO upon detection of unauthorized access, modification, or deletion of audit information.

4.3 AU - Audit and Accountability AU-11: Audit Record Retention Retain audit records seven (7) years to provide support for after-the-fact investigations of incidents and to meet regulatory and organizational information retention requirements.

4.3 AU - Audit and Accountability AU-12: Audit Generation

a. Provide audit record generation capability for the event types the system is capable of auditing as defined in AU-2a on all systems that receive, process, store, access, protect and/or transmit FTI;

b. Allow SA and ISSO to select the event types that are to be logged by specific components of the system; and

c. Generate audit records for the event types defined in AU-2c that include the audit record content defined in AU-3.

4.3 AU - Audit and Accountability AU-16: Cross-Organizational Auditing Logging Employ agency-defined methods for coordinating agency-defined audit information among external organizations when audit information is transmitted across organizational boundaries.

Supplemental Guidance: This requirement applies to consolidated and outsourced data centers, thirdparty vendors, and/or cloud providers handling FTI. When agencies use systems and/or services of external organizations, the auditing capability necessitates a coordinated approach across organizations. For example, maintaining the identity of individuals that requested specific services across organizational boundaries may often be very difficult, and doing so may prove to have significant performance and privacy ramifications. Therefore, it is often the case that cross-organizational auditing simply captures the identity of individuals issuing requests at the initial system, and subsequent systems record that the requests emanated from authorized individuals.

4.4 CA - Assessment, Authorization and Monitoring CA-2: Control Assessments

a. Select the appropriate assessor or assessment team for the type of assessment to be conducted;

b. Develop a control assessment plan that describes the scope of the assessment including:

1. Controls and control enhancements under assessment;

2. Assessment procedures to be used to determine control effectiveness; and

3. Assessment environment, assessment team, and assessment roles and responsibilities;

c. Ensure the control assessment plan is reviewed and approved by the authorizing official or designated representative prior to conducting the assessment;

d. Assess the controls in the system and its environment of operation annually to determine the extent to which the controls are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting established security and privacy requirements;

e. Produce a control assessment report that document the results of the assessment; and

f. Provide the results of the control assessment to agency’s Authorizing Official (AO) or the Authorizing Official Designated Representative.

4.4 CA - Assessment, Authorization and Monitoring CA-3: Information Exchange

a. Approve and manage the exchange of information between the system and other systems using Interconnection Security Agreements (ISAs).

b. Document, as part of each exchange agreement, the interface characteristics, security and privacy requirements, controls, and responsibilities for each system, and the impact level of the information communicated; and

c. Review and update the system interconnection on an annual basis.

Supplemental Guidance: This control applies to dedicated connections between two or more separate systems and does not apply to transitory, user-controlled connections such as email and website browsing. Interconnected systems falling under the same FTI environment, or authorization boundary, do not require a formal Interconnection Security Agreement.

4.4 CA - Assessment, Authorization and Monitoring CA-5: Plan of Action and Milestones

a. Develop a plan of action and milestones for the system to document the planned remediation actions of the agency to correct weaknesses or deficiencies noted during the assessment of the controls and to reduce or eliminate known vulnerabilities in the system; and

b. Update existing plan of action and milestones on a quarterly basis, at a minimum, based on the findings from control assessments, independent audits or reviews, and continuous monitoring activities.

Supplemental Guidance: The POA&M must be comprised of an all-inclusive tool or document for the agency to track vulnerabilities identified by the self-assessments, internal inspections, external audits and any other vulnerabilities identified for information systems that receive, process, store, access, protect and/or transmit FTI.

4.4 CA - Assessment, Authorization and Monitoring CA-6: Authorization

a. Assign a senior official as the authorizing official for the system;

b. Assign a senior official as the authorizing official for common controls available for inheritance by organizational systems;

c. Ensure that the authorizing official for the system, before commencing operations:

1. Accepts the use of common controls inherited by the system; and

2. Authorizes the system to operate;

d. Ensure that the authorizing official for common controls authorizes the use of those controls for inheritance by organizational systems;

e. Update the authorizations whenever there is a significant change to the system, or every three (3) years, whichever occurs first.

Supplemental Guidance: Authorizations are official management decisions by senior officials to authorize operation of systems and to explicitly accept the risk to agency operations and assets, individuals and other agencies based on the implementation of agreed-upon security and privacy controls. Authorizing officials provide budgetary oversight for agency systems or assume responsibility for the mission and business operations supported by those systems. Authorizing officials are responsible and accountable for security and privacy risks associated with the operation and use of agency systems. The authorization comes in the form of a memorandum signed by an agency official with fiduciary control over the security control implementation within the system. Agencies may choose to perform authorizations at the agency level (i.e., authorize all systems that receive, process, store, access, protect and/or transmit FTI at once) or at the system level (i.e., create a memo for each application and supporting infrastructure that receives, processes, stores, accesses, protects and/or transmits FTI). Authorization memos should come after processes where security controls are selected and assessed and should incorporate robust risk management processes to identify, mitigate and reduce risk to an acceptable level. Agencies may conduct ongoing authorizations of systems by implementing continuous monitoring programs. Robust continuous monitoring programs reduce the need for separate reauthorization processes.

4.4 CA - Assessment, Authorization and Monitoring CA-7: Continuous Monitoring Develop a system-level continuous monitoring strategy and implement continuous monitoring in accordance with the organization-level continuous monitoring strategy that includes:

a. Establish agency-defined metrics to be monitored;

b. Establish agency-defined frequencies (no less than annually) for monitoring and agency-defined frequencies (no less than annually) for ongoing assessment of security and privacy control effectiveness;

c. Ongoing control assessments in accordance with the continuous monitoring strategy;

d. Ongoing monitoring of system and organization-defined metrics in accordance with the continuous monitoring strategy;

e. Correlation and analysis of information generated by control assessments and monitoring;

f. Response actions to address results of the analysis of control assessment and monitoring information; and

g. Reporting the security and privacy status of the system to agency-defined personnel annually, at a minimum.

4.4 CA - Assessment, Authorization and Monitoring CA-7: Continuous Monitoring Control Enhancements (CE-1) Independent Assessors: Employ independent assessors or assessment teams to monitor the controls in the system on an ongoing basis.

Supplemental Guidance: Agencies can maximize the value of control assessments during the continuous monitoring process by requiring that assessments be conducted by assessors with…