Detection Alerts

I would like to be able to get an email alert when a detection fires. I understand you can create an alert and at best try and reference the protocols that the Detection is using, but this doesn’t work well. Why have these great Detections and not be able to get notified when one fires? Instead of having to choose a Detection Category and then what protocols to use why not have the exact Detections listed there? This would be extremely helpful!

Thanks,
Erick

2 Likes

Thanks for this feedback; it’s great to hear that there are specific detection types you find valuable enough to want in your email inbox.

When we approach the subject of detection alerts, one of our early concerns was how alert configurations would withstand changes in how we lay out our detection taxonomy. In the early days of Reveal(x) detections didn’t even have a single type field; they had titles, categories, and protocols.

Now that Detection.type exists, it’s possible to imagine choosing one from a list and saying “email me when this one fires,” if we can answer the question, “what should we do if that detection type goes away?” This question is less academic than it sounds: We’ve subdivided a number of detection types into more specific types over the life of Reveal(x), e.g. foo becomes foo_scan and foo_exploit.

The question is, “what does the alert creator want the system to do now?” Never sending another email because Detection.type === "foo" is never true again probably isn’t correct.

The best option is probably to - when a detection type is retired - somehow tell the alert recipients (or a system admin) so they can fix the problem. We could try to track the two successor types for foo, but over multiple generations of edits that could lead to some weird end states which would probably surprise the alert creator.

That explains why it’s more labor-intensive to build than it sounds, but the larger reason we haven’t done this is that customer feedback on detection notification has pushed us in a different direction, towards the DETECTION_UPDATE trigger event. Using this trigger event, it’s possible to feed detections into a SIEM, Slack, Microsoft Teams, a ticketing system, or anything else that ExtraHop can communicate with using Open Data Streams.

The trigger approach is less batteries-included than alerts, but many teams have found they prefer the control it affords them in choosing which detections to forward and how to format them. At the end of this year we’re going to be introducing new functionality for the trigger and the REST API which will make detections more expressive and easier to work with in both these APIs surfaces.


We’re going to continue investing in surfacing ExtraHop’s findings in the most useful ways we can. We’d love to know more about which detection types you’re looking to get via email and what information you look for in that message. Please feel free to reply here, or if you’d like to share screenshots or anything you can send a private message to me or @swagatdasgupta.

We fire the detection in our Ticket system JIRA. That works pretty well… I started with the KB article here: https://docs.extrahop.com/current/detections-configure-ticket-tracking/

this KB article has still some mistakes don’t know I already informed Cal about, but nevermind. Here is my first version of the JIRA Trigger

if (!Detection.riskScore)
{
    return
}

var priolevel = "";

if (Detection.riskScore < 61) {return} //Trivial
if (Detection.riskScore > 60 && Detection.riskScore < 71) {return} //Minor
if (Detection.riskScore > 70 && Detection.riskScore < 81) {priolevel = "Major"}
if (Detection.riskScore > 80 && Detection.riskScore < 91) {priolevel = "Critical"}
if (Detection.riskScore > 90) {priolevel = "Blocker"}

// Type trigger code below
const summary = "[ExtraHop Detection] - " + Detection.id + ": " + Detection.title;
const description = "Risiko Rating: " + Detection.riskScore + "\n" + "ExtraHop has detected the following event on your network: " + "\n" + Detection.description
const environment = "Here is the Link: https://<your_environment>/extrahop/#/detections/detail/" + Detection.id
const payload = {
"fields": {
     "project":
     {
         "key": "TEST"
     },
    "summary": summary,
    "environment": environment,
    "assignee": 
    {
        "name": "User"
    },
    "issuetype":{
        "name": "Incident"
    },
    "priority": {
        "name": priolevel
    },
    //"labels": '["Extrahop"]',
    "customfield_10006":"EPIC Ticket Number",
    "description": description
}
};

var headers_custom = {
    "Content-Type":"application/json",
    "accept":"application/json"
};

Remote.HTTP('jira').post({path: "/rest/api/2/issue/", headers: headers_custom, payload: JSON.stringify(payload)})

The ODS Target should be configured like this:

Name: jira
Host: your_jira_address
Port: 443
Type: HTTPS
Additional HTTP header: Authorization: Basic username:password (Base 64 coded)
Authentication: None

TEST CONFIGURATION:
Method: GET

Options:

{
"path": "/rest/api/2/issue/DEMO-12",
"headers": {
"accept": [
"application/json"
],
"content-type": [
"application/json"
]
},
"payload": ""
}

To check the values you want to use in your Jira you can create a Test Ticket with all the values and try to get out the Field description with following link:

https[://]/rest/api/2/search?jql=project=PROJECTKEY&maxResults=200

So this is basically for JIRA but it should work for every ticket tool with an API :slight_smile:

Hope this helps!

BR, Florian

2 Likes