| Source | Azure Portal | ||
| Display name | Microsoft Managed Control 1110 - Audit Storage Capacity | ||
| Id | 6182bfa7-0f2a-43f5-834a-a2ddf31c13c7 | ||
| Version | 1.0.0 Details on versioning |
||
| Category | Regulatory Compliance Microsoft Learn |
||
| Description | Microsoft implements this Audit and Accountability control | ||
| Additional metadata |
Name/Id: ACF1110 / Microsoft Managed Control 1110 Category: Audit and Accountability Title: Audit Storage Capacity Ownership: Customer, Microsoft Description: The organization allocates audit record storage capacity in accordance with Ability to retain at least 90 days’ worth of logs. Requirements: Audit records for each Azure service are captured by the Geneva Monitoring Agent (MA) and retained in a service-specific Azure storage account. The MA collects data from the service assets and automatically uploads to the service storage account. Each storage account is allocated sufficient storage capacity for the retention of at least ninety (90) days’ worth of logs online and is monitored for usage by the service teams. If a storage account is near capacity, either - service teams are notified by Azure Storage automatically and the service teams creates an additional storage account or expand the current account’s capacity; or, if the service team has configured Azure Storage for auto-expansion, the storage is increased as needed. Each service team is responsible for its own log capacity planning. If the service team does not expand capacity for any reason, due to the high volume of events received, Azure audit collection settings are to overwrite when capacity is exceeded. The MA then sends the collected logs from the service-specific storage into a central log storage cluster known as the parsing engine. This local cluster stores centrally aggregated log data for the purposes of standardizing the ingested log data, such as time, date, field titles, etc., and parsing the data for alerting via multiple microservices. The logs do not reside on these servers long-term; once parsed, logs are provided to Kusto and Jarvis. Kusto and Jarvis then retain the parsed data as read-only, ensuring the integrity of the centralized logs, automatically growing the backend data storage. There is no hard limit associated with the central storage. Azure currently defines baseline requirements for local security audit log storage capacity to a window of at least ten (10) minutes of events on even Azure’s most active hosts. Events are continuously sent to Geneva Monitoring, which has adequate storage capacity to handle the volume of events captured due to auto-expansion. In the event of an audit failure or audit storage capacity being reached, Azure monitoring tools generate near-real time alerts to the C+AI Security Engineering team, who are assigned to address the processing failure. |
||
| Mode | Indexed | ||
| Type | Static | ||
| Preview | False | ||
| Deprecated | False | ||
| Effect | Fixed audit |
||
| RBAC role(s) | none | ||
| Rule aliases | none | ||
| Rule resource types | IF (2) Microsoft.Resources/subscriptions Microsoft.Resources/subscriptions/resourceGroups |
||
| Compliance | Not a Compliance control | ||
| Initiatives usage | none | ||
| History | none | ||
| JSON compare | n/a | ||
| JSON |
|