Overview
The Security Flow Waiter, Remove Pending Action, and Sync nodes provide the ability to manage an Incident by allowing for a user decision point, flow based removal of decision points, and synchronization points to manage manual and automated decision making. The changes made by the nodes are viewable on the Incident Timeline, Incidents Screen, and the Incidents List. For more information on status changes see Incident Statuses and Transitions.
Functionality
The Pending Action & Sync nodes expose the following functionality:
- Pause a flow at a synchronization point until all messages are processed and, optionally, all pending actions are completed via the
NL Syncnode. - Create pending actions, user decision points, via the
NL Waiternode. - Remove existing pending actions via the
NL Remove Pending Actionnode.
Flow Nodes
The display name of the node within the flows.
Use the Priority field to order pending actions within an incident timeline. The priority is used to sort pending actions from highest value to lowest value. A higher priority value will show up above other pending actions in the incident timeline and, conversely, lower priority values will appear below other pending actions. The sorting applies to the view within a timeline and works across pending actions, regardless of the NL-Waiter.
If Batch Pending Actions is checked, pending actions with the same Incident ID will be batched into one pending action instead of one pending action per message received at the NL Waiter node.
Additionally, Batch On Field further ensures that batching is based on more than just the Incident ID. Batching is based on the value of the selected Batch Field. The field may be an object consisting of a hierarchy of data as well. Batch On Field mode is the recommend default configuration when dealing with Indicators of Compromise (IoCs).
Perform Batch on Field Across Incidents provides a mode of operation to process all pending actions across incidents with the same Batch Field on the same waiter node. When selected, all incidents waiting on the exact same field value will continue on with a single click irrespective of the Incident ID.
Configured Outputs defines the list of outputs. There must always be at least two outputs. If less than two outputs are defined, additional defaults are added in automatically until two outputs are defined.
- Output Label: The output label for the output. This label is also used for this path’s button when viewing on the Incident related UI pages.
- Button Color: The button color for the output on the Incident related UI pages.
- Button Icon: The button icon for the output on the Incident related UI pages.
- All messages have finished processing throughout the rest of the flows.
- A small delay has elapsed before continuing. This is to handle asynchronous messages coming from broadcast nodes. For example, the Virus Total integration may be configured to respond at a rate of once every 15 seconds.
Messages may also be conditionally blocked until all pending actions from the NL-Waiter nodes for the message are processed.
If Group By Message ID is unchecked and Join Messages is unchecked, every arriving message object will be passed along from this node regardless of message ID (msg._msgid).
If Group By Message ID is unchecked and Join Messages is checked, the first message is used as the template message and the data found at Combine Each is converted to an array. In a similar fashion to the join node, the Combine Each data from the remaining messages with the same message ID (msg._msgid) are appended to the array. A single message is passed along with an array in the Combine Each location.
If Group By Message ID is checked and Merge Grouped Messages is unchecked, only the first message object identified by message ID (msg._msgid) will be passed along from this node. Grouping is a useful mechanism to prevent multiple versions of the same message ID from reaching a point in the flow. This is useful for limiting operations which should only be done once for a message, such as an Office 365 (O365) Security and Compliance search.
If both Group By Message ID and Merge Grouped Messages are checked, non-conflicting portions of the message objects identified by message ID (msg._msgid) are merged together and a single merged message is passed along from this node. This is useful for combining information from disparate flow pathways back into a single message.
The display name of the node within the flows.
Determines if messages are grouped together prior to sending out. If this is unchecked and Join Messages is unchecked, every arriving message object will be passed along from this node regardless of message ID (msg._msgid).
If Group By Message ID is checked and Merge Grouped Messages is unchecked, only the first message object identified by message ID (msg._msgid) will be passed along from this node. Grouping is a useful mechanism to prevent multiple versions of the same message ID from reaching a point in the flow. This is useful for limiting operations which should only be done once for a message, such as an Office 365 (O365) Security and Compliance search.
If both Group By Message ID and Merge Grouped Messages are checked, non-conflicting portions of the message objects identified by message ID (msg._msgid) are merged together and a single merged message is passed along from this node. This is useful for combining information from disparate flow pathways back into a single message.
When Group By Message ID is unchecked, this option is available for selection. If Join Messages is checked, the first message is used as the template message and the data found at Combine Each are converted to an array. In a similar fashion to the join node, all Combine Each data from the remaining messages with the same message ID (msg._msgid) are appended to the array.
While joining sounds similar to the behavior when both Group By Message ID and Merge Grouped Messages are checked, this mode creates an array of received data at Combine Each instead of merging data together.
When both Group By Message ID and Merge Grouped Messages are checked, non-conflicting portions of the messages are merged together. Conflicting portions of the message are overwritten at the deepest level possible. This is useful for combining information from disparate flow pathways back into a single merged message.
If Group By Message ID is unchecked and Join Messages is checked, the Combine Each message data must exist in the incoming message and will be combined into an array stored at the same location upon output from this node.
The number of seconds the node waits before the message is passed on, if all conditions are met.
By default, Pending Actions (NL Waiter) is checked. When checked, this node will block until every pending action has had a decision made. If unchecked, this node will not use pending actions to determine if blocking should be performed.
Remove Mode and, optionally, based on the Batch Field. This node is useful for flows in which one decision can determine the behavior of the rest of the flow. For example, consider a phishing email containing a large number of unknown Indicators of Compromise (IoCs) within it. Those unknown IoCs are waiting for a decision to be made. Once a decision is made to distrust a single IoCs, the entire phishing email can be considered untrusted. The display name of the node within the flows.
If Batch On Field is checked, the Batch Field must be supplied. This configuration is useful when a flow pathway trusts an Indicator of Compromise (IoC) after another pathway in the flow ended up at a NL-Waiter node requiring a choice. This allows for the clearing of a single pending action request based on the batched value.
As defined by status transition rules in the system, a waiting Incident can not be closed until all pending actions are addressed. This node will clear out all the desired pending actions based on the selected Remove Mode.
- Selected NL Waiter(s): Pending actions for the Incident blocked at the designated
NL-Waiternodes on the same tab. This is a safer mode of operation. - All Pending Actions: All pending actions for the Incident.
Learn More
Success
The flow used for this example is highlighted in orange.
The NL Waiter nodes (6a, 6b, 6c) create the pending actions with the payload, timestamp, and configured buttons as shown below.
The NL Remove Pending Action node used in this example is configured to remove all pending actions when the ‘Clear’ pathway is selected from one of the NL Waiter nodes. The following entries are added to the Incident Timeline as shown below.
Metro Office Park
2950 Metro Drive, Suite 104
Bloomington, MN 55425
Phone: +1 952-500-8921
©Nevelex Labs, LLC. 2018-2023, All Rights Reserved.
EULA