3-Attachment 17 - Control Sheet.xlsx
XLSX spreadsheet 62 KB Posted
- Attached to
- Master Agreement AZ|CTR077094
- Contract number
- CTR077094
- Issued by
- Arizona
About this file
The document is a comprehensive security control assessment spreadsheet, specifically an AZRamp Guidance document for vendor compliance with state-level information security requirements. It appears to be issued by Arizona's Department of Homeland Security (AZDOHS) and is designed to guide vendors through a detailed security control assessment process, focusing on infrastructure, data handling, and cybersecurity protocols. The document references multiple regulatory frameworks including NIST 800-53, HIPAA, COBIT, and various federal and state cybersecurity standards.
The spreadsheet provides a structured template for vendors to document their security control implementations across multiple domains such as access control, identification and authentication, system and communication protection, and risk assessment. Each control is meticulously detailed with specific requirements, expected vendor responses, implementation status tracking, and documentation references. While no specific goods or services are explicitly outlined, the document is clearly intended to establish rigorous security standards for vendors providing services or systems to Arizona state agencies, with a particular emphasis on protecting state data infrastructure, ensuring proper access controls, and maintaining comprehensive security protocols.
View the file
Other files
Show all 27
On GovTribe
Work with this file
- Download the original file
- Contacts named in this file
- Similar government files
- Ask GovTribe AI about this file
Text version
AZRamp Guidance Company Name: To begin the AZRamp process please complete the following steps below:
1. The required Level 1 Impact controls are identified in the below Controls Tab.
2. Column (D) describes the security controls and enhancements as related to the "Infrastructure" State data will be received/processed/transmitted or stored such as; cloud platforms, computers, routers, servers, network, printers, WiFi, anti-virus/malware, system users/employees with access, etc. (NOT about any software solution you provide or your Internet Service Provider).
3. Column (E) is where you will enter the answer/response to Column (D) questions. Please Note: Your answer/response should come directly from your SSP/WISP, you may use cut/paste from your SSP into Column (E). Yes or No responses in Column (E) will not be accepted and returned for correction.
4. Columns (F) & (G) are self-explanatory. Use the drop down bar to select the most accurate response.
5. Column (H) is where you will list the referenced policy/standard document name, page #, paragraph, sub-paragraph, etc. which the specific security control in Column (E) can be quickly located in your SSP/WISP for our cross-reference and validation purposes.
6. Column (I) is where you will list any Compensating Controls you have implemented in the event your organization does not meet all the requirements listed in Column (E).
7. Columns (K) & (L) is an overview of how we assess each security control response your company entered into Column (E) and cross-reference against your SSP/WISP policies listed in Column (H).
| Vendor Contact Name: | |||
| Vendor Contact Email: | |||
| See sample control AC-2 as a reference of what is expected for each control. For all communications include AZDOHS GRC (grc@azdohs.gov) | |||
| Security Control Family | Control Name | NIST | |
| 800-53 Control # | NIST 800-53 Rev. 5 Control/Enhancement | ||
| Detailed breakdown of required controls/enhancements | Vendor's Response | ||
| (Please Address all the controls and control enhancements in DETAIL Controls and Enhancements identified in Column D) | Overall Control(s) |
Implementation Status
| Please select from Drop down | Where does the Control(s) originate from? |
| Please select from Drop down | Supporting Documentation |
| (Policies and procedures must be explicitly referenced (title and date or version) so that it is clear which document is being referred to. Section numbers or similar mechanisms should allow the reviewer to easily find the reference.) | Vendor's Compensating Controls |
| (if Control Can't Be Met - What is the alternative security controls employed by organization) | Vendor Non-Compliance |
(If you can't meet this control at all please explain why)
| Assessment Objective | Control/Enhancement Discussion | SOA Policy Number 1 | SOA SubSection 1 |
| AC- Access Control | Account Management | AC-2 | a. Define and document the types of accounts allowed and specifically prohibited for use within the system; |
b. Assign account managers;
c. Require [Assignment: organization-defined prerequisites and criteria] 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 [Assignment: organization-defined attributes (as required)] for each account;
e. Require approvals by [Assignment: organization-defined personnel or roles] for requests to create accounts;
f. Create, enable, modify, disable, and remove accounts in accordance with [Assignment: organization-defined policy, procedures, prerequisites, and criteria];
g. Monitor the use of accounts;
h. Notify account managers and [Assignment: organization-defined personnel or roles] within:
1. [Assignment: organization-defined time period] when accounts are no longer required;
2. [Assignment: organization-defined time period] when users are terminated or transferred; and
3. [Assignment: organization-defined time period] 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. [Assignment: organization-defined attributes (as required)];
j. Review accounts for compliance with account management requirements [Assignment: organization-defined frequency];
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. Company XYZ:
Part a. [XYZ] identifies and selects the following types of information system accounts to support business functions: guest, individual, system, and service.
Part b. [XYZ] utilizes the Operations group to manage information system accounts under the authority of the Director of Operations.
Part c. [XYZ] uses job titles and organizational team membership as the conditions for group and role membership. Special duties may be assigned that facilitate group or role membership if approved by the Director of Operations.
Part d. [XYZ] The Systems team, under the authorization of the Director of Operations, specifies authorized users of the information system, group and role membership, and access authorizations and other attributes for each account.
Part e. [XYZ] requires approvals by the Director of Operations for requests to create information system accounts.
Part f. [XYZ] The Systems team creates, enables, modifies, disables, and removes information system accounts in accordance with the [XYZ] Access Control Policy and associated Access Control Procedures.
Part g. [XYZ] The Security and Compliance team utilizes the (XXXX) Security Information and Event Manager [SIEM] to monitor the use of information system accounts via alarms and watchlists on the SIEM.
Part h. The [XYZ] Systems team is notified when accounts are no longer required, when users are terminated, and when individual information system usages changes. Upon termination the Human Resources team creates an Online Project Communication (OPC) ticket, this ticket is processed and sent to the Systems team for account termination.
Part i. The Director of Operations authorizes access to the information system is based on a valid access authorization, intended system usage, justification based on standard duties determined by title and team membership or special duties assigned by a Director.
Part j. The [XYZ] Security and Compliance team reviews accounts for compliance with account management requirements quarterly. This quarterly review is a manual review by the Security and Compliance team with supplemental use of PowerShell scripts.
| Part k. [XYZ] does not issue or allow shared user accounts. | Implemented | Shared (Service Provider and Customer Responsibility) | [XYZ]-Access Control Policy, Page 4, Section 6.2 |
| [XYZ]-Access Control Procedure, Page 6, Sections 3.0 - 5.3 | Account types allowed for use within the system are defined and documented; |
Account types specifically prohibited for use within the system are defined and documented;
Account manager are assigned;
Prerequisites and criteria for group and role membership are required;
Authorized users of the system are specified;
Group and role membership are specified;
Access authorizatons (i.e., privileges) are specified for each account;
Attributes (as required) are specified for each account;
Approvals are required by defined personnel or roles for requests to create accounts;
Accounts are created in accordance with policy, procedures, prerequisities, and criteria;
Accounts are enabled in accordance with policy, procedures, prerequisities, and criteria;
Accounts are modified in accordance with policy, procedures, prerequisities, and criteria;
Accounts are disabled in accordance with policy, procedures, prerequisities, and criteria;
Accounts are removed in accordance with policy, procedures, prerequisities, and criteria;
The use of accounts is monitored;
Account managers and defined personnel or roles are notified within a defined time period when accounts are no longer required;
Account managers and defined personnel or roles are notified within a defined time period when users are terminated or transferred;
Account managers and defined personnel or roles are notified within a defined time period when system usage or the need to know changes for an individual;
Access to the system is authorized based on a valid access authorization;
Access to the system is authorized based on intended system usage;
Access to the system is authorized based on attributes (as required);
Accounts are reviewed for compliance with account management requirements;
A process is established for changing shared or group account authenticators (if deployed) when individuals are removed from the group;
A process is implemented for changing shared or group account authenticators (if deployed) when individuals are removed from the group;
Account management processes are aligned with personnel termination processes;
Account management processes are aligned with personnel transfer processes. Examples of system account types include individual, shared, group, system, guest, anonymous, emergency, developer, temporary, and service. Identification of authorized system users and the specification of access privileges reflect the requirements in other controls in the security plan. Users requiring administrative privileges on system accounts receive additional scrutiny by organizational personnel responsible for approving such accounts and privileged access, including system owner, mission or business owner, senior agency information security officer, or senior agency official for privacy. Types of accounts that organizations may wish to prohibit due to increased risk include shared, group, emergency, anonymous, temporary, and guest accounts.
Where access involves personally identifiable information, security programs collaborate with the senior agency official for privacy to establish the specific conditions for group and role membership; specify authorized users, group and role membership, and access authorizations for each account; and create, adjust, or remove system accounts in accordance with organizational policies. Policies can include such information as account expiration dates or other factors that trigger the disabling of accounts. Organizations may choose to define access privileges or other attributes by account, type of account, or a combination of the two. Examples of other attributes required for authorizing access include restrictions on time of day, day of week, and point of origin. In defining other system account attributes, organizations consider system-related requirements and mission/business requirements. Failure to consider these factors could affect system availability.
Temporary and emergency accounts are intended for short-term use. Organizations establish temporary accounts as part of normal account activation procedures when there is a need for short-term accounts without the demand for immediacy in account activation. Organizations establish emergency accounts in response to crisis situations and with the need for rapid account activation. Therefore, emergency account activation may bypass normal account authorization processes. Emergency and temporary accounts are not to be confused with infrequently used accounts, including local logon accounts used for special tasks or when network resources are unavailable (may also be known as accounts of last resort). Such accounts remain available and are not subject to automatic disabling or removal dates. Conditions for disabling or deactivating accounts include when shared/group, emergency, or temporary accounts are no longer required and when individuals are transferred or terminated. Changing shared/group authenticators when members leave the group is intended to ensure that former group members do not retain access to the shared or group account. Some types of system accounts may require specialized training. P8310 6.3
Controls
| Security Control Family | Control Name | Control/Enhancement | |
| Number | NIST 800-53 Rev. 5 Control/Enhancement | ||
| Detailed breakdown of required controls/enhancements | Vendor's Response | ||
| (Please Address all the controls and control enhancements in DETAIL Controls and Enhancements identified in Column D) | Overall Control(s) |
Implementation Status
| Please select from Drop down | Where does the Control(s) originate from? |
| Please select from Drop down | Supporting Documentation |
| (Policies and procedures must be explicitly referenced (title and date or version) so that it is clear which document is being referred to. Section numbers or similar mechanisms should allow the reviewer to easily find the reference.) | Vendor's Compensating Controls |
| (if Control Can't Be Met - What is the alternative security controls employed by organization) | Vendor Non-Compliance |
(If you can't meet this control at all please explain why)
| Assessment Objective | Control/Enhancement Discussion | SOA Policy Number 1 | SOA SubSection 1 | SOA Policy Number 2 | SOA SubSection 2 | SOA Policy Number 3 | SOA SubSection 3 | SOA Policy Number 4 | SOA SubSection 4 | Arizona Breach Notification A.R.S. § 44-7500 | Arizona Computer tampering A.R.S. § 13-2316 | COBIT Reference (Control Objective) | NIST Cybersecurity Framework (EO 13636) | SANS 20 ('Twenty Critical' Controls) | IRS Publication 1075 | CJIS Security Policy 5.5 | CJIS Security Policy 5.5 map to | |
| NIST Control Enhancements | ISO/IEC 27001:2005 | ISO/IEC 27002:2005 | HIPAA Security | |||||||||||||||
| (45 CFR Parts 164) | FERPA | Public Law 93-579 | Computer Fraud and Abuse Act of 1986 (US) 18 USC 1031 | Gramm-Leach-Bliley Act of 1999 (GLBA) – 15 U.S.C., Subchapter I, Sec. 6801-6809 | Computer Security Act of 1987 – Public Law 100-235 (H.R. 145) | The Children’s Internet Protection Act of 2000 (CIPA) – Public Law 106-554 | The Children’s Online Privacy Protection Rule of 2000 (COPPA) | PCI DSS v3.2 | ||||||||||
| AC - Access Control | Account Management | AC-2 | a. Define and document the types of accounts allowed and specifically prohibited for use within the system; |
b. Assign account managers;
c. Require [Assignment: organization-defined prerequisites and criteria] 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 [Assignment: organization-defined attributes (as required)] for each account;
e. Require approvals by [Assignment: organization-defined personnel or roles] for requests to create accounts;
f. Create, enable, modify, disable, and remove accounts in accordance with [Assignment: organization-defined policy, procedures, prerequisites, and criteria];
g. Monitor the use of accounts;
h. Notify account managers and [Assignment: organization-defined personnel or roles] within:
1. [Assignment: organization-defined time period] when accounts are no longer required;
2. [Assignment: organization-defined time period] when users are terminated or transferred; and
3. [Assignment: organization-defined time period] 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. [Assignment: organization-defined attributes (as required)];
j. Review accounts for compliance with account management requirements [Assignment: organization-defined frequency];
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. USA Up Star is currently finalizing comprehensive security controls and enhancements for all of our infrastructure components that will receive, process, transmit, or store State data. Our efforts span cloud platforms, computers, routers, servers, networks, printers, WiFi systems, and endpoint security measures such as anti-virus and malware solutions, along with rigorous access control protocols to ensure that only authorized personnel have system access. These measures are being designed and refined to meet or exceed state and federal cybersecurity standards, ensuring that our infrastructure remains secure and resilient against emerging threats. Once we are finalized with the security company, we will submit a more detailed overview of our enhanced security framework. Account types allowed for use within the system are defined and documented;
Account types specifically prohibited for use within the system are defined and documented;
Account manager are assigned;
Prerequisites and criteria for group and role membership are required;
Authorized users of the system are specified;
Group and role membership are specified;
Access authorizatons (i.e., privileges) are specified for each account;
Attributes (as required) are specified for each account;
Approvals are required by defined personnel or roles for requests to create accounts;
Accounts are created in accordance with policy, procedures, prerequisities, and criteria;
Accounts are enabled in accordance with policy, procedures, prerequisities, and criteria;
Accounts are modified in accordance with policy, procedures, prerequisities, and criteria;
Accounts are disabled in accordance with policy, procedures, prerequisities, and criteria;
Accounts are removed in accordance with policy, procedures, prerequisities, and criteria;
The use of accounts is monitored;
Account managers and defined personnel or roles are notified within a defined time period when accounts are no longer required;
Account managers and defined personnel or roles are notified within a defined time period when users are terminated or transferred;
Account managers and defined personnel or roles are notified within a defined time period when system usage or the need to know changes for an individual;
Access to the system is authorized based on a valid access authorization;
Access to the system is authorized based on intended system usage;
Access to the system is authorized based on attributes (as required);
Accounts are reviewed for compliance with account management requirements;
A process is established for changing shared or group account authenticators (if deployed) when individuals are removed from the group;
A process is implemented for changing shared or group account authenticators (if deployed) when individuals are removed from the group;
Account management processes are aligned with personnel termination processes;
Account management processes are aligned with personnel transfer processes. Examples of system account types include individual, shared, group, system, guest, anonymous, emergency, developer, temporary, and service. Identification of authorized system users and the specification of access privileges reflect the requirements in other controls in the security plan. Users requiring administrative privileges on system accounts receive additional scrutiny by organizational personnel responsible for approving such accounts and privileged access, including system owner, mission or business owner, senior agency information security officer, or senior agency official for privacy. Types of accounts that organizations may wish to prohibit due to increased risk include shared, group, emergency, anonymous, temporary, and guest accounts.
Where access involves personally identifiable information, security programs collaborate with the senior agency official for privacy to establish the specific conditions for group and role membership; specify authorized users, group and role membership, and access authorizations for each account; and create, adjust, or remove system accounts in accordance with organizational policies. Policies can include such information as account expiration dates or other factors that trigger the disabling of accounts. Organizations may choose to define access privileges or other attributes by account, type of account, or a combination of the two. Examples of other attributes required for authorizing access include restrictions on time of day, day of week, and point of origin. In defining other system account attributes, organizations consider system-related requirements and mission/business requirements. Failure to consider these factors could affect system availability.
Temporary and emergency accounts are intended for short-term use. Organizations establish temporary accounts as part of normal account activation procedures when there is a need for short-term accounts without the demand for immediacy in account activation. Organizations establish emergency accounts in response to crisis situations and with the need for rapid account activation. Therefore, emergency account activation may bypass normal account authorization processes. Emergency and temporary accounts are not to be confused with infrequently used accounts, including local logon accounts used for special tasks or when network resources are unavailable (may also be known as accounts of last resort). Such accounts remain available and are not subject to automatic disabling or removal dates. Conditions for disabling or deactivating accounts include when shared/group, emergency, or temporary accounts are no longer required and when individuals are transferred or terminated. Changing shared/group authenticators when members leave the group is intended to ensure that former group members do not retain access to the shared or group account. Some types of system accounts may require specialized training. P8120 6.2 P8270 6.2 P8280 6.1 - 6.7.1 P8310 6.1 - 6.10 P8320 6.1 - 6.18 [CobiT v5 - High Level Control Objective AP013; DSS02; DSS05]Controls have been defined to ensure system security by defining IT security policies, procedures and standards, and monitoring, detecting, reporting security vulnerabilities and incidents. ID.GV-1, PR.AC-1 Critical Control 15: Controlled Access Based on the Need to Know 9.3.1.1 Access Control Policy and Procedures (AC-1) A.5.1.1, A.5.1.2, A.6.1.1, A.6.1.2, A.6.1.3, A.8.1.1, A.10.1.1, A.10.8.1, A.11.1.1, A.11.3.3, A.11.4.1, A.11.6.1, A.11.7.1, A.11.7.2, A.12.3.2, A.15.1.1, A.15.2.1 5.1.1, 5.1.2, 6.1.1, 6.1.3, 8.1.1, 10.1.1, 10.8.1,11.1.1, 11.2.1, 11.2.2, 11.4.1, 11.7.1, 11.7.2,15.1.1, 15.2.1 HIPAA Security Section - 45 CFR 164.308(a)(3)(ii)(B) HIPAA Security Section - 45 CFR 164.312(a)(1)
| HIPAA Security Section - 45 CFR 164.312(c)(2) | 1.1, 7.1, 7.1.4, 7.3, 8.4, 8.8, 12.1, 12.1.1, 12.3, 12.4, 12.5.1, 12.5.5 | ||||||||||||||||
| Access Enforcement | AC-3 | Enforce approved authorizations for logical access to information and system resources in accordance with applicable access control policies. | Approved authorizations for logical access to information and system resources are enforced in accordance with applicable access control policies | Access control policies control access between active entities or subjects (i.e., users or processes acting on behalf of users) and passive entities or objects (i.e., devices, files, records, domains) in organizational systems. In addition to enforcing authorized access at the system level and recognizing that systems can host many applications and services in support of mission and business functions, access enforcement mechanisms can also be employed at the application and service level to provide increased information security and privacy. In contrast to logical access controls that are implemented within the system, physical access controls are addressed by the controls in the Physical and Environmental Protection (PE) family. | P8320 | 6.1 | P8410 | 6.3 | [CobiT v5 - High Level Control Objective AP013; DSS02, DSS05] Controls have been defined to ensure system security by defining IT security policies, procedures and standards, and monitoring, detecting, reporting security vulnerabilities and incidents. | PR.AC-4, PR.PT-3 | Critical Control 15: Controlled Access Based on the Need to Know | ||||||
| Critical Control 16: Account Monitoring and Control | 9.3.1.3 Access Enforcement (AC-3) | 5.5.2 | AC-03,AC-03(03),AC-03(04) | A.7.2.2, A.10.6.1, A.10.7.3, A.10.7.4, A.10.8.1 A.10.9.1, A.10.9.2, A.10.9.3, A.11.2.2, A.11.5.4, A.11.6.1, A.12.4.3, A.15.1.3 | 10.8.1 11.4.4, 11.4.6, 11.5.4, 11.6.1, 12.4.2 | 7.1, 7.1.2, 7.2, 7.2.1, 7.2.2, 7.2.3, 8.1.5, 8.3, 10.4.2, 1.1.5 | |||||||||||
| Information Flow | |||||||||||||||||
| Enforcement | AC-4 | Enforce approved authorizations for controlling the flow of information within the system and between connected systems based on [Assignment: organization-defined information flow control policies]. | Approved authorizations are enforced for controlling the flow of information within the system and between connected systems based on information flow control policies. | Information flow control regulates where information can travel within a system and between systems (in contrast to who is allowed to access the information) and without regard to subsequent accesses to that information. Flow control restrictions include blocking external traffic that claims to be from within the organization, keeping export-controlled information from being transmitted in the clear to the Internet, restricting web requests that are not from the internal web proxy server, and limiting information transfers between organizations based on data structures and content. Transferring information between organizations may require an agreement specifying how the information flow is enforced (see CA-3). Transferring information between systems in different security or privacy domains with different security or privacy policies introduces the risk that such transfers violate one or more domain security or privacy policies. In such situations, information owners/stewards provide guidance at designated policy enforcement points between connected systems. Organizations consider mandating specific architectural solutions to enforce specific security and privacy policies. Enforcement includes prohibiting information transfers between connected systems (i.e., allowing access only), verifying write permissions before accepting information from another security or privacy domain or connected system, employing hardware mechanisms to enforce one-way information flows, and implementing trustworthy regrading mechanisms to reassign security or privacy attributes and labels. | |||||||||||||
| Organizations commonly employ information flow control policies and enforcement mechanisms to control the flow of information between designated sources and destinations within systems and between connected systems. Flow control is based on the characteristics of the information and/or the information path. Enforcement occurs, for example, in boundary protection devices that employ rule sets or establish configuration settings that restrict system services, provide a packet-filtering capability based on header information, or provide a message-filtering capability based on message content. Organizations also consider the trustworthiness of filtering and/or inspection mechanisms (i.e., hardware, firmware, and software components) that are critical to information flow enforcement. Control enhancements 3 through 32 primarily address cross-domain solution needs that focus on more advanced filtering techniques, in-depth analysis, and stronger flow enforcement mechanisms implemented in cross-domain products, such as high-assurance guards. Such capabilities are generally not available in commercial off-the-shelf products. Information flow enforcement also applies to control plane traffic (e.g., routing and DNS). | P8320 | 6.3 | [CobiT v5 - High Level Control Objective AP013; DSS02, DSS05] Controls have been defined to ensure system security by defining IT security policies, procedures and standards, and monitoring, detecting, reporting security vulnerabilities and incidents. | PR.AC-4, PR.PT-3 | Critical Control 10: Secure Configurations for Network Devices such as Firewalls, Routers, and Switches. |
Critical Control 15: Controlled Access Based on the Need to Know.
Critical Control 17: Data Loss Prevention 9.3.1.4 Information Flow Enforcement (AC-4) 5.10.1 AC-04 A.7.2.2, A.10.7.3, A.10.8.1, A.11.4.5, A.11.4.7, A.12.5.4 10.6.1, 10.8.1, 11.4.5, 11.4.7, 11.7.2, 12.4.2,12.5.4 HIPAA Security Section - 45 CFR 164.308(a)(3)(ii)(B) HIPAA Security Section - 45 CFR 164.308(a)(4)(ii)(B) HIPAA Security Section - 45 CFR 164.308(a)(4)(ii)(c )
| HIPAA Security Section - 45 CFR 164.312(c)(2) | 1.1.3, 1.1.4, 1.2, 1.2.1, 1.2.2, 1.2.3, 1.3, 1.3.1, 1.3.2, 1.3.3, 1.3.4, 1.3.5, 1.3.6, 1.3.7, 1.3.8 | |||||||||||||||||||||||
| Separation of Duties | AC-5 | a. Identify and document [Assignment: organization-defined duties of individuals requiring separation]; and | ||||||||||||||||||||||
| b. Define system access authorizations to support separation of duties. | Duties of indivuduals are identified and documented; | |||||||||||||||||||||||
| System access authorizations to support separation of duties are defined. | Separation of duties addresses the potential for abuse of authorized privileges and helps to reduce the risk of malevolent activity without collusion. Separation of duties includes dividing mission or business functions and support functions among different individuals or roles, conducting system support functions with different individuals, and ensuring that security personnel who administer access control functions do not also administer audit functions. Because separation of duty violations can span systems and application domains, organizations consider the entirety of systems and system components when developing policy on separation of duties. Separation of duties is enforced through the account management activities in AC-2, access control mechanisms in AC-3, and identity management activities in IA-2, IA-4, and IA-12. | P8310 | 6.3.4 | [CobiT v5 - High Level Control Objective AP001; AP007; AP011]Controls have been established for defining the IT processes, organization and relationships to be responsive to business strategy and comply with governance requirements. | PR.AC-4, PR.AC-5 | 9.3.1.5 Separation of Duties (AC-5) | 5.5.1,5.5.2,5.5.2.1,5.5.2.2,5.5.2.3,5.5.2.4,5.13.6 | AC-05 | A.10.1.3 | 6.1.3, 8.1.1, 10.1.3, 11.1.1, 11.4.1 | 6.4.2 | |||||||||||||
| Least Privilege | AC-6 | 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. | The principle of least privilege is employed, allowing only authorized accesses for users (or processes acting on behalf of users) that are necessary to accomplish assigned organizational tasks | Organizations employ least privilege for specific duties and systems. The principle of least privilege is also applied to system processes, ensuring that the processes have access to systems and operate at privilege levels no higher than necessary to accomplish organizational missions or business functions. Organizations consider the creation of additional processes, roles, and accounts as necessary to achieve least privilege. Organizations apply least privilege to the development, implementation, and operation of organizational systems. | P8310 | 6.3.3, 6.4-6.8 | P8320 | 6.4-6.8 | P8410 | 6.4 | A.R.S 13-2316 (A) | [CobiT v5 - High Level Control Objective AP013; DSS02, DSS05] Controls have been defined to ensure system security by defining IT security policies, procedures and standards, and monitoring, detecting, reporting security vulnerabilities and incidents. | PR.AC-4 | Critical Control 12: Controlled Use of Administrative Privileges | ||||||||||
| Critical Control 15: Controlled Access Based on the Need to Know | 9.3.1.6 Least Privilege (AC-6) | 5.5.2.1,5.5.2.2,5.5.2.3,5.5.2.4,5.13.6 | AC-06,AC-06(05),AC-06(09) | A.11.2.2, A.11.4.1, A.11.4.4, A.11.5.4, A.11.6.1, A.12.4.3 | 6.1.3, 8.1.1, 11.1.1, 11.2.2, 11.4.1, 11.4.4,11.4.6, 11.5.4, 11.6.1, 12.4.3 | HIPAA Security Section - 45 CFR 164.308(a)(3)(i) |
HIPAA Security Section - 45 CFR 164.308(a)(3)(ii)(B)
| HIPAA Security Section - 45 CFR 164.308(a)(4)(i) | Computer Fraud and Abuse Act of 1986 (US) 18 USC 1032 - Section 1030. a) 2 | 1.1.5, 7.1, 7.1.2, 7.1.4, 10.4.2, 7.1.1, 7.1.3, 10.2.2, 10.2.5 | |||
| Remote Access | AC-17 | 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. | Usage restrictions are established and documented for each type of remote access allowed; |
Configuration/connection requirements are established and documented for each type of remote access allowed;
Implementation guidance is established and documented for each type of remote access allowed;
Each type of remote access to the system is authorized prior to allowing such connections. Remote access is access to organizational systems (or processes acting on behalf of users) that communicate through external networks such as the Internet. Types of remote access include dial-up, broadband, and wireless. Organizations use encrypted virtual private networks (VPNs) to enhance confidentiality and integrity for remote connections. The use of encrypted VPNs provides sufficient assurance to the organization that it can effectively treat such connections as internal networks if the cryptographic mechanisms used are implemented in accordance with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines. Still, VPN connections traverse external networks, and the encrypted VPN does not enhance the availability of remote connections. VPNs with encrypted tunnels can also affect the ability to adequately monitor network communications traffic for malicious code. Remote access controls apply to systems other than public web servers or systems designed for public access. Authorization of each remote access type addresses authorization prior to allowing remote access without specifying the specific formats for such authorization. While organizations may use information exchange and system connection security agreements to manage remote access connections to other systems, such agreements are addressed as part of CA-3. Enforcing access restrictions for remote access is addressed via AC-3. P8320 6.13 [CobiT v5 - High Level Control Objective AP013; DS05]Controls have been defined to ensure system security by defining IT security policies, procedures and standards, and monitoring, detecting, reporting security vulnerabilities and incidents. PR.AC-3, PR.PT-4 Critical Control 7: Wireless Device Control.
Critical Control 12: Controlled Use of Administrative Privileges.
Critical Control 13: Boundary Defense.
Critical Control 14: Maintenance, Monitoring, and Analysis of Security Audit Logs 9.3.1.12 Remote Access (AC-17)
| 4.0 Secure Storage—IRC 6103(p)(4)(B); (4.7 Telework Locations) | 5.5.6,5.5.6.1,5.5.6.2,5.10.1.5,5.10.1.2 | AC-17,AC-17(01),AC-17(02),AC-17(03),AC-17(04),AC-17(06) | A.10.6.1, A.10.8.1, A.10.8.5, A.11.4.1, A.11.4.2, A.11.4.6, A.11.7.1, A.11.7.2 | 10.6.1, 10.8.1, 11.1.1, 11.4.1, 11.4.2, 11.4.4,11.4.6, 11.4.7, 11.7.1, 11.7.2 | 8.1.5, 12.3.8, 12.3.9, 12.3.10, 12.5.5, 2.3, 7.1, 7.1.1, 7.1.2, 7.1.3, 12.3 | |
| Wireless Access | AC-18 | a. Establish configuration requirements, connection requirements, and implementation guidance for each type of wireless access; and | ||||
| b. Authorize each type of wireless access to the system prior to allowing such connections. | Configuation requirements are established for each type of wireless access; |
Connection requirement are established for each type of wireless access;
Implementation guideance is established for each type of wireless access
| Each type of wireless access to the system is authorized prior to allowing such connections. | Wireless technologies include microwave, packet radio (ultra-high frequency or very high frequency), 802.11x, and Bluetooth. Wireless networks use authentication protocols that provide authenticator protection and mutual authentication. | P8320 | 6.14 | [CobiT v5 - High Level Control Objective AP013; DSS02, DSS05] Controls have been defined to ensure system security by defining IT security policies, procedures and standards, and monitoring, detecting, reporting security vulnerabilities and incidents. | PR.PT-4 | Critical Control 7: Wireless Device Control | 9.3.1.13 Wireless Access (AC-18) | 5.13.1,5.13.1.4,5.13.1.1,5.13.1.3 | AC-18,AC-18(01),AC-18(05) | A.10.6.1, A.10.8.1, A.11.4.1, A.11.4.2, A.11.4.6, A.11.7.1 | 10.6.1, 10.8.1, 11.1.1, 11.4.1, 11.4.2, 11.4.4,11.4.6, 11.4.7, 11.7.1, 11.7.2 | 1.1.2, 2.1.1, 4.1.1, 12.3 | |
| Access Control For | |||||||||||||
| Mobile Devices | AC-19 | 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. | Configuration requirements are established for organization-controlled mobile devices, including when such devices are outside of the controlled area; |
Connection requirements are established for organization-controlled mobile devices, including when such devices are out of the controlled area;
Implementation guidance is established for organization-controlled mobile devices, including when such devices are outside of the controlled area;
The connection of mobile devices to organizational systems is authorized. A mobile device is 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 functionality may also include voice communication capabilities, on-board sensors that allow the device to capture information, and/or built-in features for synchronizing local data with remote locations. Examples include smart phones and tablets. Mobile devices are typically associated with a single individual. The processing, storage, and transmission capability of the mobile device may be comparable to or merely a subset of notebook/desktop systems, depending on the nature and intended purpose of the device. Protection and control of mobile devices is behavior or policy-based and requires users to take physical action to protect and control such devices when outside of controlled areas. Controlled areas are spaces for which organizations provide physical or procedural controls to meet the requirements established for protecting information and systems.
Due to the large variety of mobile devices with different characteristics and capabilities, organizational restrictions may vary for the different classes or types of such devices. Usage restrictions and specific implementation guidance for mobile devices include configuration management, device identification and authentication, implementation of mandatory protective software, scanning devices for malicious code, updating virus protection software, scanning for critical software updates and patches, conducting primary operating system (and possibly other resident software) integrity checks, and disabling unnecessary hardware.
| Usage restrictions and authorization to connect may vary among organizational systems. For example, the organization may authorize the connection of mobile devices to its network and impose a set of usage restrictions, while a system owner may withhold authorization for mobile device connection to specific applications or impose additional usage restrictions before allowing mobile device connections to a system. Adequate security for mobile devices goes beyond the requirements specified in AC-19. Many safeguards for mobile devices are reflected in other controls. AC-20 addresses mobile devices that are not organization-controlled. | P8320 | 6.15 | [CobiT v5 - High Level Control Objective AP013; DS05]Controls have been defined to ensure system security by defining IT security policies, procedures and standards, and monitoring, detecting, reporting security vulnerabilities and incidents. | PR.AC-3, PR.PT-2 | Critical Control 12: Controlled Use of Administrative Privileges. | |||
| Critical Control 14: Maintenance, Monitoring, and Analysis of Security Audit Logs | Access Control for Mobile Devices (AC-19) | 5.13.1.2,5.13.1.2.1,5.13.1.2.2,5.13.1.4,5.13.2,5.13.3,5.13.6,5.13.7.2.1,5.13.7.3 | AC-19,AC-19(05) | A.9.2.5, A.10.4.1, A.10.7.3, A.11.4.3, A.11.4.6, A.11.7.1 | 10.4.1, 11.1.1, 11.4.3, 11.7.1 | 4.2, 12.3, 12.3.1, 12.3.2, 12.3.3, 12.3.4, 12.3.5, 12.3.6, 12.3.7 | ||
| AT- Awareness and Training | Literacy Training and | |||||||
| Awareness | AT-2 | 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 [Assignment: organization-defined frequency] thereafter; and
2. When required by system changes or following [Assignment: organization-defined events];
b. Employ the following techniques to increase the security and privacy awareness of system users [Assignment: organization-defined awareness techniques];
c. Update literacy training and awareness content [Assignment: organization-defined frequency] and following [Assignment: organization-defined events]; and
d. Incorporate lessons learned from internal or external security incidents or breaches into literacy training and awareness techniques. Security literacy training is provided to system users (including managers, senior executives, and contractors) as part of initial training for new users;
Privacy literacy training is provided to system users (including managers, senior executives, and contractors) as part of initial training for new users;
| Organizations provide basic and advanced levels of literacy training to system users, including measures to test the knowledge level of users. Organizations determine the content of literacy training and awareness based on specific organizational requirements, the systems to which personnel have authorized access, and work environments (e.g., telework). The content includes an understanding of the need for security and privacy as well as actions by users to maintain security and personal privacy and to respond to suspected incidents. The content addresses the need for operations security and the handling of personally identifiable information. | ||||||
| Awareness techniques include displaying posters, offering supplies inscribed with security and privacy reminders, displaying logon screen messages, generating email advisories or notices from organizational officials, and conducting awareness events. Literacy training after the initial training described in AT-2a.1 is conducted at a minimum frequency consistent with applicable laws, directives, regulations, and policies. Subsequent literacy training may be satisfied by 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. Updating literacy training and awareness content on a regular basis helps to ensure that the content remains relevant. Events that may precipitate an update to literacy training and awareness content include, but are not limited to, assessment or audit findings, security incidents or breaches, or changes in applicable laws, executive orders, directives, regulations, policies, standards, and guidelines. | P8210 | 6.2.1 | [CobiT v5 - High Level Control Objective AP007] Controls have been defined to educate and train users. | PR.AT-1, PR.AT-5 | Critical Control 9: Security Skills Assessment and Appropriate Training to Fill Gaps | 9.3.2.2 Security Awareness Training (AT-2) |
| 6.0 Other Safeguards—IRC 6103(p)(4)(D);(6.2 Training Requirements) | 5.2.1.1,5.2.1.2,5.2.1.3 | AT-02,AT-02(02) | A.6.2.2, A.8.2.2, A.10.4.1 | 6.2.2, 8.1.1, 8.2.2, 9.1.5, 10.4.1 | HIPAA Security Section - 45 CFR 164.308(a)(5)(i) | Computer Security Act of 1987 – Public Law 100-235 (H.R. 145) - Sec. 5 |
| Computer Security Act of 1987 – Public Law 100-235 (H.R. 145) - V. Section 5 | 12.6.1 | |||||
| AU - Audit | ||||||
| and Accountability | Audit Record Review, Analysis, and Reporting | AU-6 | a. Review and analyze system audit records [Assignment: organization-defined frequency] for indications of [Assignment: organization-defined inappropriate or unusual activity] and the potential impact of the inappropriate or unusual activity; |
b. Report findings to [Assignment: organization-defined personnel or roles]; 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. System audit records are reviewed and analyzed frequency for indications of inappropriate or unusual activity and the potential impact of the inappropriate or unusual activity;
Findings are reported to defined personnel or roles;
| The level of audit record review, analysis, and reporting within the system is adjusted when there is a change in risk based on law enforcement information, intelligence information, or other credible sources of information. | Audit record review, analysis, and reporting covers information security- and privacy-related logging performed by organizations, including logging that results from the monitoring of account usage, remote access, wireless connectivity, mobile device connection, configuration settings, system component inventory, use of maintenance tools and non-local maintenance, physical access, temperature and humidity, equipment delivery and removal, communications at system interfaces, and use of mobile code or Voice over Internet Protocol (VoIP). Findings can be reported to organizational entities that include the incident response team, help desk, and security or privacy offices. If organizations are prohibited from reviewing and analyzing audit records or unable to conduct such activities, the review or analysis may be carried out by other organizations granted such authority. The frequency, scope, and/or depth of the audit record review, analysis, and reporting may be adjusted to meet organizational needs based on new information received. | P8330 | 6.5 | [CobiT v5 - High Level Control Objective MEA02.01-02] Controls have been defined to monitoring and evaluating internal controls. | DE.AE-2, DE.AE-3, DE.DP-4 | Critical Control 14: Maintenance, Monitoring, and Analysis of Security Audit Logs | 9.3.3.7 Audit Review, Analysis, and Reporting (AU-6) | 5.4.1,5.4.3 | AU-06,AU-06(01),AU-06(03) | A.10.10.2, A.10.10.5, A.13.1.1, A.15.1.5 | 10.10.2, 10.10.5, 13.1.1, 15.1.5 | 10.6.3, 12.10.1, 12.10.5, A-1.3, 10.6, 10.6.1, 10.6.2, 10.5.1, 10.5.2 | |
| Audit Record Generation | AU-12 | a. Provide audit record generation capability for the event types the system is capable of auditing as defined in AU-2a on [Assignment: organization-defined system components]; |
b. Allow [Assignment: organization-defined personnel or roles] 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. Audit record generation capability for the event types of the system is capable of auditing is provided by system components;
Defined personnel or roles is/are allowed to select the event types that are to be logged by specific components of the system;
| Audit records for the event types that include the audit record content are generated. | Audit records can be generated from many different system components. The event types specified in AU-2d are the event types for which audit logs are to be generated and are a subset of all event types for which the system can generate audit records. | P8330 | 6.1 | [CobiT v5 - High Level Control Objective MEA02.01-02] Controls have been defined to monitoring and evaluating internal controls. | Critical Control 14: Maintenance, Monitoring, and Analysis of Security Audit Logs | 9.3.3.12 Audit Generation (AU-12) | 5.4.1,5.4.1.1,5.4.1.1.1 | AU-12 | A.10.10.1, A.10.10.2, A.10.10.4, A.10.10.5 | 10.10.1, 10.10.4, 10.10.5 | 10.2, 10.2.1, 10.2.2, 10.2.3, 10.2.4, 10.2.5, 10.2.6, 10.2.7, 10.1, 10.3, 10.3.6, 10.5.1 |
| CA - Assessment, |
Authorization and Monitoring
Control Assessments CA-2 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 [Assignment: organization-defined frequency] 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 [Assignment: organization-defined individuals or roles]. An appropriate assessor or assessment team is selected for the type of assessment to be conducted;
A conrol assessment plan is developed that describes the scope of the assessment, including controls and control enhancements under assessment;
A control assessment plan is developed that describes the scope of the assessment, including assessment procedures to be used to determine control effectiveness;
A control assessment plan is developed that describes the scope of the assessment including the assessment environment;
A control assessment plan is developed that describes the scope of the assessment, including assessment roles and responsibilities;
A control assessment plan is developed that describes the scope of the assessment, including the assessment team;
A control assessment…
This is the start of the file's text. The full file is on GovTribe.
File details come from the government source that posted it. Updated .