A bit about ASC Alert in Log Analytics workspace

Microsoft introduced Continuous Export in Azure Security Center allowing you to export security recommendation and alert to a Log Analytics workspace. You might wonder if data structure in alert is different from the data which is collected from configuring ASC data collection.

This article is going to reveal a bit about the difference which would be helpful for you to explain to your customers.

Previously ASC allowed you to specify a Log Analytics workspace to store what its collects including security events (from Windows OS virtual machine). Not only security event if you pay attention enough you will notice that ACS alert is also collected into the workspace.

The collection is executed by ASC-custom configuration made in virtual machine agent (at the time you enable provisioning).

Microsoft gives details on ASC data collection here.

The data schema of SecurityAlert data type that Continuous Export gives you has no difference from the one you configure for data collection.

{
    "id": "/subscriptions/67d6179d-a99d-4ccd-8c56-4d3ff2e13349/resourceGroups/calendar-app-rg/providers/Microsoft.Security/locations/centralus/alerts/2518278514569233960_839a3cef-2389-4f42-9fe4-38e153c4fc24",
    "name": "2518278514569233960_839a3cef-2389-4f42-9fe4-38e153c4fc24",
    "type": "Microsoft.Security/Locations/alerts",
    "properties": {
        "vendorName": "Microsoft",
        "alertDisplayName": "Suspicious authentication activity",
        "alertName": "Login_BF_ValidUserFailed",
        "detectedTimeUtc": "2019-11-22T19:02:23.0766039Z",
        "description": "Although none of them succeeded, some of them used accounts were recognized by the host.\r\nThis resembles a dictionary attack, in which an attacker performs numerous authentication attempts using a dictionary of predefined account names and passwords in order to find valid credentials to access the host.\r\nThis indicates that some of your host account names might exist in a well-known account name dictionary.",
        "remediationSteps": "1. Enforce the use of strong passwords and do not re-use them across multiple resources and services \r\n2. In case this is an Azure Virtual Machine, set up an NSG allow list of only expected IP addresses or ranges. (see https://azure.microsoft.com/en-us/documentation/articles/virtual-networks-nsg/)\r\n3. In case this is an Azure Virtual Machine, lock down access to it using network JIT (see https://docs.microsoft.com/en-us/azure/security-center/security-center-just-in-time) ",
        "actionTaken": "Detected",
        "reportedSeverity": "Medium",
        "compromisedEntity": "winapp-vm",
        "associatedResource": "/subscriptions/67d6179d-a99d-4ccd-8c56-4d3ff2e13349/resourceGroups/calendar-app-rg/providers/Microsoft.Compute/virtualMachines/winapp-vm",
        "subscriptionId": "67d6179d-a99d-4ccd-8c56-4d3ff2e13349",
        "instanceId": "839a3cef-2389-4f42-9fe4-38e153c4fc24",
        "extendedProperties": {
            "activity start time (UTC)": "2019/11/22 19:02:23.0766039",
            "activity end time (UTC)": "2019/11/22 19:55:55.4916754",
            "attacker source IP": "IP Address: 116.12.212.244",
            "attacker source computer name": "Unknown",
            "number of failed authentication attempts to host": "14",
            "number of existing accounts used by source to sign in": "1",
            "number of nonexistent accounts used by source to sign in": "13",
            "top accounts with failed sign in attempts (count)": "DEFAULTACCOUNT (1), DELEON (1), DB_SERVICE (1), DMKG (1), DDANIEL (1), DATAX (1), DWORSLEY (1), DXX8 (1), DEMO (1), DOCT (1)",
            "was RDP session initiated": "No",
            "end Time UTC": "11/22/2019 19:55:55",
            "resourceType": "Virtual Machine",
            "enrichment_tas_threat__reports": "{\"Kind\":\"Link\",\"Value\":\"https://interflowwebportalext.trafficmanager.net/reports/DisplayReport?callerIdentity=ddd5443d-e6f4-441c-b52b-5278d2f21dfa&reportCreateDateTime=2019-11-22T14%3a17%3a57&reportName=MSTI-TS-Brute-Force.pdf&tenantId=63ab72ec-5edd-4f4d-9fc8-6c7548d53430&urlCreateDateTime=2019-11-22T14%3a17%3a57&token=C0rtOH4lVAsWeSolv8nyBgGNPlZnzQRNbc7%20Ofa4HHM=\",\"DisplayValue\":\"Report: Brute Force\"}"
        },
        "state": "Active",
        "reportedTimeUtc": "2019-11-22T20:32:49.5935177Z",
        "confidenceReasons": [],
        "canBeInvestigated": true,
        "isIncident": false,
        "entities": [
            {
                "$id": "centralus_1",
                "hostName": "winapp-vm",
                "azureID": "/subscriptions/67d6179d-a99d-4ccd-8c56-4d3ff2e13349/resourceGroups/calendar-app-rg/providers/Microsoft.Compute/virtualMachines/winapp-vm",
                "omsAgentID": "c4f699eb-7b6e-4be4-8231-c9da8d55c904",
                "type": "host"
            }
        ]
    }

There are the following differences I’d see:

  • Destination Workspace: this would be a big thing. While data collected by ASC can be stored in a local workspace, data that Continuous Export feature exports can be stored in another subscription’s workspace. This is a huge advantage in a large environment when you would like to centralize ASC data for security operation.
  • Transfer method: the data collection is done by agent while the continuous export would be done by a queue messaging service.
  • TimeGenerated: would be different since the two features use different transfer method

Be aware of data duplication that may exist when you work with ASC connector in Azure Sentinel and have Data collection and Continuous Export used together.

This entry was posted in Azure Security Center and tagged . Bookmark the permalink.

4 Responses to A bit about ASC Alert in Log Analytics workspace

  1. Pingback: Work with Azure Security Center Alert from Azure Sentinel | All about security on Microsoft Azure

  2. Pingback: Audit Azure Security Center in your tenant - All about security on Microsoft AzureAll about security on Microsoft Azure

  3. Pingback: Azure Security Center ARM Template - Microsoft Azure Security RandomnessMicrosoft Azure Security Randomness

  4. Pingback: An analysis of Suspicious Authentication activity from Azure Security Center

Leave a Reply