| Compliance |
The following 14 compliance controls are associated with this Policy definition 'Virtual machines should be connected to a specified workspace' (f47b5582-33ec-4c5c-87c0-b010a6b2e917)
| Control Domain |
Control |
Name |
MetadataId |
Category |
Title |
Owner |
Requirements |
Description |
Info |
Policy# |
| AU_ISM |
582 |
AU_ISM_582 |
AU ISM 582 |
Guidelines for System Monitoring - Event logging and auditing |
Events to be logged - 582 |
|
n/a |
The following events are logged for operating systems:
• access to important data and processes
• application crashes and any error messages
• attempts to use special privileges
• changes to accounts
• changes to security policy
• changes to system configurations
• Domain Name System (DNS) and Hypertext Transfer Protocol requests
• failed attempts to access data and system resources
• service failures and restarts
• system startup and shutdown
• transfer of data to and from external media
• user or group management
• use of special privileges. |
link |
2 |
| CCCS |
AU-12 |
CCCS_AU-12 |
CCCS AU-12 |
Audit and Accountability |
Audit Generation |
|
n/a |
(A) The information system provides audit record generation capability for the auditable events defined in AU-2 a. of all information system and network components where audit capability is deployed/available.
(B) The information system allows organization-defined personnel or roles to select which auditable events are to be audited by specific components of the information system.
(C) The information system generates audit records for the events defined in AU-2 d. with the content defined in AU-3. |
link |
7 |
| CCCS |
AU-3 |
CCCS_AU-3 |
CCCS AU-3 |
Audit and Accountability |
Content of Audit Records |
|
n/a |
(A) The information system generates audit records containing information that establishes what type of event occurred, when the event occurred, where the event occurred, the source of the event, the outcome of the event, and the identity of any individuals or subjects associated with the event. |
link |
3 |
| CCCS |
SI-4 |
CCCS_SI-4 |
CCCS SI-4 |
System and Information Integrity |
Information System Monitoring |
|
n/a |
(A) The organization monitors the information system to detect:
(a) Attacks and indicators of potential attacks in accordance with organization-defined monitoring objectives; and
(b) Unauthorized local, network, and remote connections;
(B) The organization identifies unauthorized use of the information system through organization-defined techniques and methods.
(C) The organization deploys monitoring devices: (i) strategically within the information system to collect organization-determined essential information; and (ii) at ad hoc locations within the system to track specific types of transactions of interest to the organization.
(D) The organization protects information obtained from intrusion-monitoring tools from unauthorized access, modification, and deletion.
(E) The organization heightens the level of information system monitoring activity whenever there is an indication of increased risk to organizational operations and assets, individuals, other organizations, or Canada based on law enforcement information, intelligence information, or other credible sources of information.
(F) The organization obtains legal opinion with regard to information system monitoring activities in accordance with orgnanizational policies, directives and standards.
(G) The organization provides organization-defined information system monitoring information to organization-defined personnel or roles at an organization-defined frequency. |
link |
5 |
| CMMC_L3 |
AU.2.041 |
CMMC_L3_AU.2.041 |
CMMC L3 AU.2.041 |
Audit and Accountability |
Ensure that the actions of individual system users can be uniquely traced to those users so they can be held accountable for their actions. |
Shared |
Microsoft and the customer share responsibilities for implementing this requirement. |
This requirement ensures that the contents of the audit record include the information needed to link the audit event to the actions of an individual to the extent feasible. Organizations consider logging for traceability including results from monitoring of account usage, remote access, wireless connectivity, mobile device connection, communications at system boundaries, configuration settings, physical access, nonlocal maintenance, use of maintenance tools, temperature and humidity, equipment delivery and removal, system component inventory, use of mobile code, and use of Voice over Internet Protocol (VoIP). |
link |
15 |
| CMMC_L3 |
AU.2.042 |
CMMC_L3_AU.2.042 |
CMMC L3 AU.2.042 |
Audit and Accountability |
Create and retain system audit logs and records to the extent needed to enable the monitoring, analysis, investigation, and reporting of unlawful or unauthorized system activity. |
Shared |
Microsoft and the customer share responsibilities for implementing this requirement. |
An event is any observable occurrence in a system, which includes unlawful or unauthorized system activity. Organizations identify event types for which a logging functionality is needed as those events which are significant and relevant to the security of systems and the environments in which those systems operate to meet specific and ongoing auditing needs. Event types can include password changes, failed logons or failed accesses related to systems, administrative privilege usage, or third-party credential usage. In determining event types that require logging, organizations consider the monitoring and auditing appropriate for each of the CUI security requirements. Monitoring and auditing requirements can be balanced with other system needs. For example, organizations may determine that systems must have the capability to log every file access both successful and unsuccessful, but not activate that capability except for specific circumstances due to the potential burden on system performance.
Audit records can be generated at various levels of abstraction, including at the packet level as information traverses the network. Selecting the appropriate level of abstraction is a critical aspect of an audit logging capability and can facilitate the identification of root causes to problems. Organizations consider in the definition of event types, the logging necessary to cover related events such as the steps in distributed, transaction-based processes (e.g., processes that are distributed across multiple organizations) and actions that occur in service-oriented or cloudbased architectures.
Audit record content that may be necessary to satisfy this requirement includes time stamps, source and destination addresses, user or process identifiers, event descriptions, success or fail indications, filenames involved, and access control or flow control rules invoked. Event outcomes can include indicators of event success or failure and event-specific results (e.g., the security state of the system after the event occurred).
Detailed information that organizations may consider in audit records includes full text recording of privileged commands or the individual identities of group account users. Organizations consider limiting the additional audit log information to only that information explicitly needed for specific audit requirements. This facilitates the use of audit trails and audit logs by not including information that could potentially be misleading or could make it more difficult to locate information of interest. Audit logs are reviewed and analyzed as often as needed to provide important information to organizations to facilitate risk-based decision making. |
link |
15 |
| CMMC_L3 |
AU.3.046 |
CMMC_L3_AU.3.046 |
CMMC L3 AU.3.046 |
Audit and Accountability |
Alert in the event of an audit logging process failure. |
Shared |
Microsoft and the customer share responsibilities for implementing this requirement. |
Audit logging process failures include software and hardware errors, failures in the audit record capturing mechanisms, and audit record storage capacity being reached or exceeded. This requirement applies to each audit record data storage repository (i.e., distinct system component where audit records are stored), the total audit record storage capacity of organizations (i.e., all audit record data storage repositories combined), or both. |
link |
7 |
| CMMC_L3 |
AU.3.048 |
CMMC_L3_AU.3.048 |
CMMC L3 AU.3.048 |
Audit and Accountability |
Collect audit information (e.g., logs) into one or more central repositories. |
Shared |
Microsoft and the customer share responsibilities for implementing this requirement. |
Organizations must aggregate and store audit logs in a central location to enable analysis activities and protect audit information. The repository should have the necessary infrastructure, capacity, and protection mechanisms to meet the organization’s audit requirements. |
link |
8 |
| IRS_1075_9.3 |
.17.4 |
IRS_1075_9.3.17.4 |
IRS 1075 9.3.17.4 |
System and Information Integrity |
Information System Monitoring (SI-4) |
|
n/a |
The agency must:
a. Monitor the information system to detect:
1. Attacks and indicators of potential attacks
2. Unauthorized local, network, and remote connections
b. Identify unauthorized use of the information system
c. Deploy monitoring devices: (i) strategically within the information system to collect agency-determined essential information; and (ii) at ad hoc locations within the system to track specific types of transactions of interest to the agency
d. Protect information obtained from intrusion-monitoring tools from unauthorized access, modification, and deletion
e. Heighten the level of information system monitoring activity whenever there is an indication of increased risk to agency operations and assets, individuals, other organizations, or the nation, based on law enforcement information, intelligence information, or other credible sources of information
f. Provide information system monitoring information to designated agency officials as needed
g. Analyze outbound communications traffic at the external boundary of the information system and selected interior points within the network (e.g., subnetworks, subsystems) to discover anomalies--anomalies within agency information systems include, for example, large file transfers, long-time persistent connections, unusual protocols and ports in use, and attempted communications with suspected malicious external addresses
h. Employ automated mechanisms to alert security personnel of inappropriate or unusual activities with security implications (CE11)
i. Implement host-based monitoring mechanisms (e.g., Host intrusion prevention system (HIPS)) on information systems that receive, process, store, or transmit FTI (CE23)
The information system must:
a. Monitor inbound and outbound communications traffic continuously for unusual or unauthorized activities or conditions (CE4)
b. Alert designated agency officials when indications of compromise or potential compromise occur--alerts may be generated from a variety of sources, including, for example, audit records or inputs from malicious code protection mechanisms; intrusion detection or prevention mechanisms; or boundary protection devices, such as firewalls, gateways, and routers and alerts can be transmitted, for example, telephonically, by electronic mail messages, or by text messaging; agency personnel on the notification list can include, for example, system administrators, mission/business owners, system owners, or information system security officers (CE5)
c. Notify designated agency officials of detected suspicious events and take necessary actions to address suspicious events (CE7)
Information system monitoring includes external and internal monitoring. External monitoring includes the observation of events occurring at the information system boundary (i.e., part of perimeter defense and boundary protection). Internal monitoring includes the observation of events occurring within the information system.
Information system monitoring capability is achieved through a variety of tools and techniques (e.g., intrusion detection systems, intrusion prevention systems, malicious code protection software, scanning tools, audit record monitoring software, network monitoring software).
Strategic locations for monitoring devices include, for example, selected perimeter locations and nearby server farms supporting critical applications, with such devices typically being employed at the managed interfaces. |
link |
5 |
| IRS_1075_9.3 |
.3.11 |
IRS_1075_9.3.3.11 |
IRS 1075 9.3.3.11 |
Awareness and Training |
Audit Generation (AU-12) |
|
n/a |
The information system must:
a. Provide audit record generation capability for the auditable events defined in Section 9.3.3.2, Audit Events (AU-2)
b. Allow designated agency officials to select which auditable events are to be audited by specific components of the information system
c. Generate audit records for the events with the content defined in Section 9.3.3.4, Content of Audit Records (AU-3).
|
link |
7 |
| IRS_1075_9.3 |
.3.3 |
IRS_1075_9.3.3.3 |
IRS 1075 9.3.3.3 |
Awareness and Training |
Content of Audit Records (AU-3) |
|
n/a |
The information system must:
a. Generate audit records containing information that establishes what type of event occurred, when the event occurred, where the event occurred, the source of the event, the outcome of the event, and the identity of any individuals or subjects associated with the event
b. Generate audit records containing details to facilitate the reconstruction of events if unauthorized activity or a malfunction occurs or is suspected in the audit records for audit events identified by type, location, or subject (CE1) |
link |
3 |
| IRS_1075_9.3 |
.3.6 |
IRS_1075_9.3.3.6 |
IRS 1075 9.3.3.6 |
Awareness and Training |
Audit Review, Analysis, and Reporting (AU-6) |
|
n/a |
The agency must:
a. Review and analyze information system audit records at least weekly or more frequently at the discretion of the information system owner for indications of unusual activity related to potential unauthorized FTI access
b. Report findings according to the agency incident response policy. If the finding involves a potential unauthorized disclosure of FTI, the appropriate special agent-in-charge, Treasury Inspector General for Tax Administration (TIGTA), and the IRS Office of Safeguards must be contacted, as described in Section 10.0, Reporting Improper Inspections or Disclosures.
The Office of Safeguards recommends agencies identify events that may indicate a potential unauthorized access to FTI. This recommendation is not a requirement at this time, but agencies are encouraged to contact the Office of Safeguards with any questions regarding implementation strategies. Methods of detecting unauthorized access to FTI include matching audit trails to access attempts (successful or unsuccessful) across the following categories: Do Not Access List, Time of Day Access, Name Searches, Previous Accesses, Volume, Zip Code, Restricted TIN
It is recommended the agency define a frequency in which the preceding categories are updated for an individual to ensure the information is kept current. |
link |
3 |
| NIST_SP_800-171_R2_3 |
.3.1 |
NIST_SP_800-171_R2_3.3.1 |
NIST SP 800-171 R2 3.3.1 |
Audit and Accountability |
Create and retain system audit logs and records to the extent needed to enable the monitoring, analysis, investigation, and reporting of unlawful or unauthorized system activity |
Shared |
Microsoft and the customer share responsibilities for implementing this requirement. |
An event is any observable occurrence in a system, which includes unlawful or unauthorized system activity. Organizations identify event types for which a logging functionality is needed as those events which are significant and relevant to the security of systems and the environments in which those systems operate to meet specific and ongoing auditing needs. Event types can include password changes, failed logons or failed accesses related to systems, administrative privilege usage, or third-party credential usage. In determining event types that require logging, organizations consider the monitoring and auditing appropriate for each of the CUI security requirements. Monitoring and auditing requirements can be balanced with other system needs. For example, organizations may determine that systems must have the capability to log every file access both successful and unsuccessful, but not activate that capability except for specific circumstances due to the potential burden on system performance. Audit records can be generated at various levels of abstraction, including at the packet level as information traverses the network. Selecting the appropriate level of abstraction is a critical aspect of an audit logging capability and can facilitate the identification of root causes to problems. Organizations consider in the definition of event types, the logging necessary to cover related events such as the steps in distributed, transaction-based processes (e.g., processes that are distributed across multiple organizations) and actions that occur in service-oriented or cloud-based architectures. Audit record content that may be necessary to satisfy this requirement includes time stamps, source and destination addresses, user or process identifiers, event descriptions, success or fail indications, filenames involved, and access control or flow control rules invoked. Event outcomes can include indicators of event success or failure and event-specific results (e.g., the security state of the system after the event occurred). Detailed information that organizations may consider in audit records includes full text recording of privileged commands or the individual identities of group account users. Organizations consider limiting the additional audit log information to only that information explicitly needed for specific audit requirements. This facilitates the use of audit trails and audit logs by not including information that could potentially be misleading or could make it more difficult to locate information of interest. Audit logs are reviewed and analyzed as often as needed to provide important information to organizations to facilitate risk-based decision making. [SP 800-92] provides guidance on security log management. |
link |
54 |
| NIST_SP_800-171_R2_3 |
.3.2 |
NIST_SP_800-171_R2_3.3.2 |
NIST SP 800-171 R2 3.3.2 |
Audit and Accountability |
Ensure that the actions of individual system users can be uniquely traced to those users, so they can be held accountable for their actions. |
Shared |
Microsoft and the customer share responsibilities for implementing this requirement. |
This requirement ensures that the contents of the audit record include the information needed to link the audit event to the actions of an individual to the extent feasible. Organizations consider logging for traceability including results from monitoring of account usage, remote access, wireless connectivity, mobile device connection, communications at system boundaries, configuration settings, physical access, nonlocal maintenance, use of maintenance tools, temperature and humidity, equipment delivery and removal, system component inventory, use of mobile code, and use of Voice over Internet Protocol (VoIP). |
link |
40 |
|