Building Trust with Dynamic Insights

Beyond Automation

At JASK, Insights are the primary workflow items and are being produced as a result of intelligent clustering of notable events (‘Signals’) by proprietary JASK algorithms. JASK Insights represent the initial stages of collecting critical incident data, and include valuable information like enrichments, enterprise context, as well as critical data artifacts, like indicators of compromise (IoC’s). The intent of Insights is to automate the early stages of cybersecurity investigations, and to provide as much relevant information as possible to enable fast, accurate decisions by the information security analysts.

Although we’d like to cover most of this process with automation, we also recognize the fact the best security analysis solutions combine intelligent algorithms with direct user feedback. With that in mind, several things, which provide more granular control of the Insights, are possible:

  • A new Insight can be manually created
  • Signals can be added to an Insight
  • Signals can be removed from an Insight
  • An Insight can be deleted, thereby ‘unbinding’ the Signals
  • Insights can be generated based on a configurable Custom Insight Rule


Let’s dig in.


Creating and Managing an Insight

Let’s start with an obvious example. Let’s say the Insight generation algorithm has grouped a handful of Signals, and some of them do not belong to the case. A Signal can be easily unlinked from the Insight:

As a result, the “liberated” Signal is now available to be used by another Insight.

Suppose you find an interesting Signal that hasn’t triggered an Insight. Now you can use the action under ‘Related Insights’ to create one, and add the Signal to it:

Your new Insight will appear under ‘Related Insights’ for that Signal. We can now open it and add even more Signals to it:

A Search bar will prompt the user to identify which Signals they will want to add. Only Signals related to the Entity around which the Insight was built will show in the search.

And now, if we decide to delete the Insight altogether, we can do this as well:

As a result, the Signals are unclustered and can be used elsewhere.

The best part of this feature is that these actions will be interpreted implicit user feedback for both Signals and Insights, and will allow JASK to track the Confidence measurements of the content producing both Signals and Insights, as derived from user’s actions.

Custom Insight Language

Before Dynamic Insights, Custom Insights were possible, but fairly restrictive. Custom Insight definition relied on very specific Signals to trigger in order to function:

Now we have a new tab available in the Custom Insights section of the Content menu. It gives us a bit more definition flexibility, which has a powerful implication. In addition to specifying Signal names, we can now leverage Signal Categories, as well as apply boolean logic to our statements.

Auto-complete is also available. Just typing a field name or value (case insensitive), hit Enter key and the top result from the Suggestions box will appear in the Expression window.

The important point to note is that with exception of then operator, which ensures that multiple Signals will be matched in the order they’re generated, each expression statement may match one or more Signals. For example, if the expression is looking for name:blah and category:A , the logic will match on a single Signal that has both name:blah and category:A, but it will also fire on two separate Signals, one matching name:blah and another Signal matching category:A.

We plan to continue developing this syntax to cover more ground within the JASK application, in places like search, system object filtering, and other parts of the UI.


Complete Syntax

Here’s the specification for the syntax currently supported at Advanced Custom Insights:

Field Match

A field match looks like the following:



It returns whether any Signal in the sequence has value in field_name, case-insensitive.


Multi-word values must be quoted, eg field_name:”hi there”.


The only fields as of right now are:

  • name
  • category
  • stream


Matching obscures/ignores whether the field itself can have multiple values (like category). Ie, it implicitly checks whether any value in field_name is value, whether there is one value or many.



You can join expressions together with infix operators, eg name:foo and name:bar. The operators are:

  • and: requires that each joined expression occur in the set of signals, but not necessarily the same signal. Eg name:foo and category:bar would fire on {name: ‘foo’, category: ‘notBar’}, {name: ‘notFoo’, category: ‘bar’} or {name:’foo’, category:’bar’}
  • or: requires that either joined expression occur in the set of signals
  • then: is an operator that enforces order. It attempts to satisfy the left-hand expression, consuming Signals until it does. If it does, it then attempts to satisfy the right-hand expression with the Signals it hasn’t consumed. e.g., name:foo then category:bar only works if there are multiple Signals, and one with name: foo precedes the one with category: bar.
Share on