Carbon Black Cloud: SOAR Use Cases

Summary

The goal of this document is to list the most common integration use cases for a SOAR (Security Orchestration, Automation, and Response). While many of the use cases are security focused, there is overlap into the IT Operations space as well.

Authentication

All API requests can be performed on the hostname URLs specified per environment see Construct your Request in the Authentication guide.

There is no longer a need to use api- URLs for any Carbon Black Cloud APIs.

There are 4 types of API keys:

  • Custom: Role Based Authentication; based on “Access Levels” which provide granular CRUD permissions
    • Already in use by Platform (general Carbon Black Cloud APIs), Enterprise EDR (ThreatHunter), Audit & Remediation (LiveOps) APIs
  • API: Used by legacy Endpoint Standard APIs for Audit Logs and Policy Management
    • Roadmap: “API” keys will be deprecated in favor of “Custom” keys (RBAC)
    • Timeline: Key type will be deprecated after new versions of the APIs that support RBAC are released. New API versions are planned for CY22 and there will be a minimum 12 month window of support before decommissioning.
  • SIEM: Used only for Notifications
  • DEPRECATED LiveResponse: Additive to key type “API”, provides access to the Live Response API
    • “LiveResponse” keys have been deprecated in favor of “Custom” keys (RBAC).
    • Live Response v6 using Custom API keys was released in April 2021 at which point the v3 API was marked deprecated

Data Ingestion workflows

The Data Forwarder is the recommended method to stream Endpoint Events and/or Alerts to the SIEM, SOAR, or Data Lake solution.

For customers and partners unable to use the Data Forwarder due to the AWS S3 requirement, the Alerts API can be used to get alerts from Carbon Black Cloud. See the VMware Carbon Black Cloud Alert Export Best Practices guide for recommended implementation details.

SOAR Actions

SOAR actions can generally be broken into three categories:

  1. Context (get more information about what happened)
  2. Remediation (mitigate the threat)
  3. Orchestration (coordinate the workflow)

Asset Nomenclature

Assets are referenced by a few names throughout Carbon Black Cloud. Throughout CY21-CY22, these names will likely converge in the UI and APIs to asset

  • Endpoint: A conventional compute instance – such as a laptop, server, or VDI instance
  • Device: Often used interchangeably with Endpoint
    • You’ll often see this as the label in APIs (e.g. Devices API, device_id)
  • External Device: A USB device, the subject of the Endpoint Standard capability Device Control
  • Workload: vSphere based virtual machine
  • Sensor: The Carbon Black Cloud agent, runs on an endpoint or workload
    • Often used in conjunction with the version of software running (e.g. Windows Sensor v3.6)
  • Asset: A placeholder used for anything that’s not a workload, endpoint, or container. Sometimes used as the super-set of inventory.

Notes:

  1. Platform denotes an API accessible to any Carbon Black Cloud customer regardless of whether they have Endpoint Standard, Enterprise EDR, or a package such as Endpoint Advanced and Endpoint Enterprise
  2. Live Response requires creating a session before running a command
  3. Hash Banning was previously an Endpoint Standard only capability; it rolled out to Enterprise EDR in 2021 (with the same API), but requires the customer have a Windows 3.7 sensor version
  4. Vulnerability Assessment for Endpoints was introduced in August 2021; it is available to customers with the Endpoint Advanced or Endpoint Enterprise packages (not available to customers with standalone Endpoint Standard or Enterprise EDR)
  5. The Policy API will likely be upgraded in the future to use RBAC. Some elements of the path, request, and response are likely to change as well.

Best Practices

Multi-tenancy

Currently, every tenant in Carbon Black Cloud requires a separate API key. If your solution supports multitenancy and partners may have multiple Carbon Black Cloud customers, consider supporting multi-tenancy in the SOAR configuration, such as:

  • Enabling multiple configurations, one per org
  • Using the org_key (from the alert, or whatever data set kicked off the SOAR workflow) to automatically choose the correct org key

Roadmap: Organizations setup as MSSPs in Carbon Black Cloud will be able to create an API key that works for each of their child tenants. Many APIs require the child tenant org key to be passed in the request URI. This could simplify the configuration for orgs setup as multi-tenant in Carbon Black Cloud.

Data Ingest/Normalization

Once you’ve identified which actions from the table above, identify the associated input metadata. This likely includes (but is not limited to):

  • org_key
  • device_id
  • process_guid
  • hash (sha256)

Ensure these fields are parsed from the alert, endpoint event, or other data sources and available to an analyst for automated or ad-hoc workflow creation.

Python SDK

Python developers should use the CBC SDK:

  • Simplifies complex workflows, such as asynchronous searching, LiveResponse, and threat intel operations
  • Simplifies future API changes, reducing the amount of your code needing to be updated
  • Offers a variety of credential storage options
  • Built, maintained, and tested by the Carbon Black Cloud Developer Relations engineering team
    • And open source to collect and include community feedback

Be sure to configure the integration_name parameter. Instructions on where to configure the parameter can be found here.

If your integration uses CBAPI, we strongly recommend upgrading to CBC SDK for Carbon Black Cloud integrations. No new functionality will be introduced to CBAPI. For instructions on migrating see here.

User Agent

If you are not using the Python CBC SDK, set the user agent to help identify your script or application. This ensures that in the future if an API has been deprecated, we can proactively reach out and help you migrate to the supported routes.

Our recommended format is: <integrationName>/<integrationVersion> <languageName>/<languageVersion>

For example: ContosoSOAR/1.3 Powershell/6.0.0

SOAR Workflows

Workflows are chains of actions that are linked together, often to gather context and remediate a specific type of incident.

Note: This section is a living document. If you have SOAR workflow or playbook suggestions, please reach out to the Developer Relations team.

Ransomware

  • Confirm the ransomware is a true positive
    • Search for file modifications from the suspicious process
    • Search for registry modifications to keys such as the desktop background
  • Identify the C&C
    • Find any network connections the process has made; note the IP address and domain
  • Identify lateral movement
    • Has this process been seen on other endpoints?
  • Remediate
    • Quarantine the impacted endpoints to prevent further spread
    • Ban the hash of the ransomware
    • Block the identified C&C IPs and domains with network tools (such as firewall or proxy)

Malware

Kick off the Malware workflow when CBC Endpoint Standard generates an alert of type CB Analytics that contains any of the following:

  • Reason Code: T_RUN_MALWARE, T_RUN_VIRUS, T_REP_VIRUS
  • TTPs: RUN_BLACKLIST_APP, RUN_MALWARE_APP, DETECTED_MALWARE_APP, MALWARE_DROP, COMPANY_BLACKLIST, DETECTED_BLACKLIST_APP

The Malware workflow may look something like this:

  • Context: Did the malware run?
    • If run_state = DID_NOT_RUN, this indicates CBC will alert on malware detected on disk
      • These alerts generally have a lower severity
      • The key next steps below:
        • What other endpoints has this malware been seen on?
        • Deleting the malware from the endpoint (Live Response delete file)
    • If run_state = RAN, the malware at least attempted to run
      • All the steps in the workflow below should be executed
  • Context: If the malware ran, was it blocked or terminated?
    • The sensor_action field of the Analytics alert
    • If it was not blocked, increase the alert’s criticality and triage immediately
  • Context/Remediation: Is the malware still running?
    • Action: List running processes on endpoint
    • If so, kill it. Action: Kill process on endpoint
  • Context: What other endpoints has this malware been seen on?
    • Action: Search for processes by query
    • Expand scope, investigation, and remediation to each of those endpoints
  • Context: Identifying how the malware got onto the endpoint
    • Action: Search for processes by query with a query like filemod_name:malware.exe
    • This may require walking the process tree, which is well suited to the CBC UI
      • URL: https://{cbc_environment}/analyze?processGUID={process_guid}&deviceId={device_id}
  • Context/Remediation: Is the process making network connections?
    • Action: Search for process events by process GUID and (optional) event query
      • This can be scoped down with a query of event_type:netconn and limiting the timeframe to around the alert for longer-running processes
    • Where were the connections connecting to?
      • Is this a C2 server? Normally this takes the expertise of a threat analyst
      • If so, block the IP or Domain via the customer’s choice of network tool (e.g. firewall,
    • If a suspicious IP/Domain is discovered, get all processes and endpoints that made the same network connection.
      • This can help detect polymorphic malware
      • Action: Search for processes by query where the query specifies the netconn_ipv4, netconn_ipv6, or netconn_domain fields
    • The context can be further enriched by pivoting into network lookups in other security software (firewall, proxy, IPS/IDS)
  • Remediation: Reduce risk of further damage or spread
    • In high-confidence, high-risk situations, quarantine the endpoint so it can only communicate with Carbon Black Cloud
      • Action: Quarantine (or Unquarantine) an endpoint
    • A less intrusive way of reducing risk is to move the endpoint to a pre-created restrictive policy, such as one that doesn’t allow Powershell or unknown processes to run.
      • First capture the original state of the endpoint, including its current policy so it can be moved back post-incident.
        • Action: Get endpoint info
      • Action: Update the endpoint policy
  • Remediation: Watchlists (EEDR Only)
    • Add any discovered IoCs (such as hash, IPs, etc) to Watchlist to detect & alert on the behavior in the future
      • Action: Add (or remove) an IoC from a Watchlist
    • If UBS is enabled
      • Submit binary to Sandbox
  • Remediation: Live Response
    • If the current Policy does not have Live Response enabled, temporarily move the endpoint to a policy that does.
      • First capture the original state of the endpoint, including its current policy so it can be moved back post-incident.
        • Action: Get endpoint info
      • Action: Update the endpoint policy
      • You’ll need to wait for the endpoint to pick up this change and the new policy to take effect
      • Action: Kill process on endpoint
      • Action: Delete file on endpoint
  • Remediation: Ban the hash
    • If this is a new instance of confirmed malware, ban the hash with Action: Ban (or unban) Process Hash
    • Take care not to ban known-good process hashes, as that can have catastrophic impact on a customer environment (e.g. powershell.exe or svchost.exe)
      • The alert may have the process reputation available, which is key context for an analyst to have (avoid banning COMMON_WHITE_LIST, TRUSTED_WHITE_LIST, etc)
  • Orchestration: Keep the CBC Alert up to date
    • Throughout the workflow, ensure you’re keeping an alert up to date in CBC with context gathered during the investigation
    • Action: Add a note to an alert
  • Orchestration: Create a ticket
    • Some customers may require other teams take action, from the IT team patching, re-imaging, and cleanup to the Network team managing blocking IPs/domains.
    • Creating a ticket full of the context gathered above is a productive way to facilitate a warm handoff to other parts of the organization
  • Orchestration: Post-incident, ensure you have:
    • Moved the endpoint back to its original policy
      • Action: Update the endpoint policy
    • Action: “Quarantine (or unquarantine) an endpoint`
  • Orchestration: Close the alert
    • When the incident has been fully resolved, close the alert in CBC (ideally with resolution comments) so another analyst doesn’t pick it up
    • Action: Dismiss an alert (with or without a comment)

Credential Theft

When an analyst receives an alert generated by Carbon Black Cloud Endpoint Standard (NGAV) that could indicate credential theft, such as memory scraping of a system process, their next questions are likely:

  • Was the memory scraping attempt successful?
  • Who was logged in at the time?

This is often an extension of the Malware workflow above, but can be identified with TTPs such as READ_SECURITY_DATA, DUMP_PROCESS_MEMORY, and MITRE_T1003_OS_CREDENTIAL_DUMP.

  • Context: Who was logged in?
    • If the workflow is executed immediately after the alert, use Live Query to get the logged in users
      • Action: Submit LiveQuery Run with query SELECT * from logged_in_users
    • For Windows systems you can also get Event Logs (such as 4624) to find recent authentications
      • Action: Submit LiveQuery Run with query SELECT * FROM windows_eventlog WHERE channel = 'Security' AND eventid in (4624, 4625, 4647)
  • Remediation: User Management
    • Leverage the customer’s primary IAM tool to enforce a range of behavior such as:
      • Forcing the user to reauthenticate with multi-factor-auth
      • Resetting the user’s password
      • Locking out the user’s account

Device Control

A Device Control alert occurs when an unapproved external USB device is inserted into a protected endpoint and blocked.

  • Get information about the USB device
    • Has the USB device (or similar models) been seen on other endpoints?
    • Are others of the same vendor/product approved?
  • If the device is valid and should not be blocked, add it to the approved list
  • If the device is not valid and should remain blocked, but the analyst wants to reduce future alert noise, dismiss all future alerts for this USB device.

Tuning Alerts & reducing alert fatigue

The Recommendations capability provides context around actions customers can take to reduce false positive alerts in their environment.

  • Group alerts by the threat_id, which will identify the top alerts by type
  • Use the Get Alert Recommendations action to identify if there are any recommendations associated with these alerts
  • Surface this information to an analyst, who can (manually) initiate an automated workflow that will either:
    • Apply the recommendation (for example, add the hash, cert, or IT tool to the Whitelist/Allow List)
    • Dismiss all future alerts for this threat

Vulnerability

SOAR workflow to create ticket for devices with CRITICAL CVEs

  • Every X minutes
    • Get all CRITICAL CVEs (docs)
    • For each CVE
      • Get Device Vulnerabilities (docs)
      • Optionally automatically take an action(s)
        • Move Policy
        • Isolate
        • Deploy patch script if available for CVE
      • Create ticket in ticketing system (SNOW, Jira, Remedy, etc.)
Last modified on March 9, 2022