My first use case


What is a Use Case?
A Use Case is a package of items that together provide a solution (e.g. automating phishing threats, reducing false positives, orchestrating incident investigations, etc.).
Once a Use Case is published to the Chronicle Marketplace, it is available for all Chronicle users to use.
A Use Case package consists of Test Cases, Connectors, Playbooks, and also Integrations and rules of mapping & modeling.

Creating a Use Case


Creating a use case starts with defining the problem/threat your use case solves, which should be followed by preparing use case alerts, extracting entities, building a playbook, and finally- uploading the Use Case for approval. Each of these steps will be explained in detail in the next section. If you're facing any issues creating your use case, you can contact us in the Support Slack Channel.

Step by Step Guide

1. Define the Use case

Write a description of the security threat you are solving with the use case. Define what kind of alert will be handled and what is the detection product that generates it.
For example, CrowdStrike - Falcon Overwatch via Malicious Activity.
The next thing you should do is draw an incident response, orchestration, or automation process, to handle this alert.

2. Prepare Use Case Alerts

You can create a custom Alert / Event according to a real data case.
Generate sample security alerts/events from a detection tool to simulate the use case.
Go to Cases, and under the plus sign click on "Simulate Cases".


Then, click in the opened window.

Why Create a Simulation Alert?
When you create a Simulation Alert, you can always use it to test the playbook and the use case. Also, this simulation will be part of the use case package.

How do you simulate an alert?
Fill in the fields of the simulation alert based on the alerts you prepared for the use case.

Simulation Alert Fields:

Next, you need to create a simulation alert in Chronicle, based on your sample alert/event.

  • "Source \ SIEM Name":
    Displays the source of the alert, be it a SIEM or another detection tool.
    Example: This field has the value "Arcsight", a SIEM product.
    If the alerts are generated by the product itself, and Chronicle pulls it from there- add the product name here.
  • "Rule Name":
    Displays the SIEM rule that generated the alert.
    Example: This field has the value "Data Exfiltration" which is a SIEM rule.
    If no SIEM is involved, just add the name of the alert generated by the detection product.
  • "Alert Product":
    Displays the detection tool that generated the alert.
    Example: The Alert Product is a DLP (Data Loss Prevention) product.
  • "Alert Name":
    Displays the name of the alert as generated by the product.
    Example: The alert name is"Data Exfiltration". (Meaning, unauthorized movement of data of any sort).
  • "Event Name":
    Displays the name of the base event that triggered the alert.
    Example: The event name is "Data Exfiltration" since it is also the name of the event.
  • "Additional Alert Fields":
    Displays usually an alert is generated by a SIEM, It displays additional content for easier incident response.
    Example 1: SIEM fields like Severity, Impact, Sensitive Assets, etc.
    Example 2: If no SIEM is involved, just add one field with the name of the alert (alert_name:).
  • "Additional Event Fields":
    Displays all the raw security data used in incident response. Add here all the data from the sample alert you are using for the use case.
    Use the exact schema of fields found in the sample alert.
    Most Common Use - Put here the security data from your alert (e.g src_ip, dest_port, email_headers, etc.)

3. Extract Entities (Map & Model the data)

Select the visualization model of the alert (the entities Chronicle should extract and the relations between them), and map the raw data fields into the selected model.


You can get here by clicking on the configuration icon on the event (As seen in the below screenshot). More information on how-to can be found here: Getting Started with Chronicle, Create Entities, Mapping and Modeling.


The next thing you should do is check if all the entities are created accordingly.

You can view the entities under the case tab, Entities Highlights. Click View More on each entity to make sure the mapping is properly configured.

4. Build a Playbook

First, you want to define the incident response flow for the alert, be it a chart or a drawing. Then, design the flow you defined as a Chronicle playbook. To do so, you need to download and configure the integrations you would like to use in the playbook. See here: Chronicle Marketplace, Configure Integrations.

See here how to Create and Run a Playbook.

  • Configuring Actions in the Playbook

    "Action Type" - Select whether this action should run automatically or manually (wait for a human approval).
    "Choose Instance" - Select Dynamic.
    "If Step Fails" - Choose whether the playbook will stop if the action fails or it will skip to the next action.
    "Entities" - Select what type of entities this action should affect (of those you extracted in your simulation alert).
    Other parameters - Fill in the action-specific parameters based on the documentation of the integration
  • Configuring Conditions in the Playbook

    Determine the amount of branches - add branches with the "Add Branch" button.
    For each branch define the conditions that will trigger this branch.
    Use placeholders (square brackets) to reference conditions to Event data, Previous Action results, and more
    Important note - Use tools you can actually test in your flow.
    Test on live data - Set up a connector that can pull alerts similar to the example alert you created for simulation. Configuring the Connector.

    To Test The Connector:

    1. First Save the configuration of the connector.
    2. Click on "Run Connector Once" to make it pull an alert from the source.
    3. "Sample Alerts" will show an alert you can ingest into Chronicle.
    4. "Output" will show the script logs to indicate the success or failure of the execution.
    More information regarding testing the connector can be found here, with an example of an Email connector with a Phishing Email alert.

    Be sure to verify that the same mapping applies to the real alert so that Chronicle is able to extract the relevant entities. Also, make sure that the playbook runs end to end on the alert and performs the defined logic.
    (Try both with malicious and non-malicious alerts).

5. Write a Guide

The Use Case you're creating will be used by other Chronicle users. In order to improve their experience, it's highly recommended to attach additional content to each use case, in which you should:

  • Explain the use case and its value to the SOC.
  • Provide recommendations to further improve the Use Case.
  • Explain in a few words how to run the use case with simulation data.
  • Guide the user about how to run the use case on actual data generated by them.
  • Explain How to get free licenses for the tools in use (if there are such).
  • Include a How-to on setting up the connector.

The guide can be attached in the "Publish Use Case", later on.

6. Publish The Use Case

It's time to assemble your Use Case. Navigate to the Chronicle Marketplace and click the Use Cases tab. Click format_list_bulleted and choose Create New Use Case.


In the opened window, fill in the details and add the items you developed - Test cases, Playbooks, and Connectors.
In the description category, you can add the guide you've previously written. If it is too long, you can write a short description and attach a link to your full guide.
Now, before you click save- you can export the Use Case. And after that, you can click save. But, don't worry - You can also export it later.
So after you click Save, you can export the package as a ZIP file, import it for testing, And finally, if all goes well, publish the Use Case to submit it for approval.