Real Time Workflow

The Real Time Workflow Method for the Activate Framework is based on several SIOC concepts. The first of these is having a Main Channel to see the actionable correlation events as the rules engine correlates all the incoming events. The Main Channel is an active channel, and is also known as the triage channel. we will use these terms interchangeably. The second SIOC concept is the SOC stages, which tells the analysts the state of an event. The SOC stages are accessed for each event by the active channel by selecting an event in the channel, right-clicking on it, and selecting "Annotate Events..." (or Ctrl+T).

Working with the Main Channel

The Main Channel (/All Active Channels/ArcSight Activate/Workflow/Main Channel) selects correlation events from Activate rules that have set the Event Annotation Stage to Triage. This triage channel is typically monitored by a Level 1 Analyst throughout the day. The responsibility of the analyst monitoring the triage channel is to evaluate the event, decide whether it can be quickly remediated or needs further investigation. If it can be quickly remediated, then the triage analyst can perform the remediation steps. If further investigation is needed, the triage analyst can change the stage of the event and assign it to another analyst for investigation and remediation.

Note that monitoring the triage channel for hours on end can be tedious and cause events to be accidentally closed. We recommend that analysts be rotated on and off "triage duty" every couple of hours or so.

The SOC Stages

The SOC stages are comprised of three levels, System, 1: Investigating, and 2: Final.

System Stages

The System stages have three different stages. These are the stages that most rules will be set in the event annotation stage field.

Triage

The Triage stage (/All Stages/SOC Stages/System/Triage) is the stage that the Activate Framework uses for events that are actionable and warrant the time of an analyst to investigate.

System Monitored

The System Monitored stage (/All Stages/SOC Stages/System/System Monitored) is used for building baselines and tracking event as they continue. Events in this channel should be periodically reviewed, but they are mostly continuations of ongoing conditions that have already been sent to the triage channel, or they are conditions that do not meet the criteria of an actionable event, but may be used by other rules when the conditions become actionable.

Testing

The Testing stage (/All Stages/SOC Stages/System/Testing) is used for testing rules under production conditions. This stage is typically used by content developers once the rule(s) they are developing have been developed on a test environment, and moved to a staging environment, and are considered ready for production. This is the final stage of testing (in a production environment) before changing the rule to set the event annotation stage to Triage or System Monitored. The goal of this stage is to determine the behavior of the rule and its impact on the system.

1: Investigating

The investigating stages are used by analysts to help with assigning events to other analysts. A triage analyst will typically use the Level 1 Investigating stage when assigning an event to another Level 1 analyst. Based on your processes, your triage analyst may also use the other stages.

Level 1 Investigating

The Level 1 Investigating stage (/All Stages/SOC Stages/1: Investigating/Level 1 Investigating) is used for the initial investigation of an event after it has been triaged. After this investigation is completed, one of the other "1: Investigating" stages may be selected and the event assigned to another analyst, or the event may be closed by setting the stage to one of the "2: Final" stages.

Level 2 Review

The Level 2 Review stage (/All Stages/SOC Stages/1: Investigating/Level 2 Review) is used when a Level 1 analyst has completed their investigation, but either needs review by a more senior analyst before closing or the event needs a more experienced or specialized analyst to complete the investigation. After this investigation is completed, one of the other "1: Investigating" stages may be selected and the event assigned to another analyst, or the event may be closed by setting the stage to one of the "2: Final" stages.

Engineer Review

The Engineer Review stage (/All Stages/SOC Stages/1: Investigating/Engineer Review) is used when the event is caused by some deficiency somewhere in the system. This deficiency could be due to a potential false positive condition, an error in the way a device logs, a misconfiguration in a connector, or a problem with a rule's conditions or aggregation settings, or some other issue. Changing the event annotation stage to Engineer Review should be accompanied by assigning it to the proper ArcSight engineer responsible for that area of ESM management. After this investigation is completed, one of the other "1: Investigating" stages may be selected and the event assigned to another analyst, or the event may be closed by setting the stage to one of the "2: Final" stages, but typically, the engineer will use a specific 2: Final stage once any issues have been resolved (e.g., No Further Action Required - Engineer).

Engage External Team

The Engage External Team stage (/All Stages/SOC Stages/1: Investigating/Engage External Team) is used when your process dictates that an event or incident should be turned over to another team or organization, such as HR, law enforcement, etc. Depending on your processes, this may be the final stage for this event, or it could be set to one of the "2: Final" stages (e.g., Case Created).

2: Final

The stages in the 2: Final group are used for closing out events in the active channel workflow. Remember, just because an event gets closed here, that doesn't necessarily mean that the incident or investigation has ended. If you use ArcSight ESM cases or export the events to an external ticketing system, the investigation may continue without the ability to track the event within ESM.

Case Created

The Case Created stage (/All Stages/SOC Stages/2: Final/Case Created) is used when your process requires that a case be created for the investigation. Not every event should become a case, but you can add events to existing cases. For that, use the Added to Case stage.

Added to Case

The Added to Case stage (/All Stages/SOC Stages/2: Final/Added to Case) is used when your process requires a case for investigation and a case for this event and its parameters already exists.

No Further Action Required - Engineer

The No Further Action Required - Engineer stage (/All Stages/SOC Stages/2: Final/No Further Action Required - Engineer) is used when an engineer has evaluated and corrected any issues resulting in the triggering of the event. See the section on the Engineer Review stage for more details on when this stage could be appropriate.

No Further Action Required - Level 1

The No Further Action Required - Level 1 stage (/All Stages/SOC Stages/2: Final/No Further Action Required - Level 1) is used when the process for investigating or remediating a situation has been completed by a Level 1 analyst. This stage should not be used if the event is considered a false positive. If the analyst feels that there is a possibility of a false positive, the event should be passed to either the Level 2 Review stage or the Engineer Review stage.

No Further Action Required - Level 2

The No Further Action Required - Level 2 stage (/All Stages/SOC Stages/2: Final/No Further Action Required - Level 2) is used when the process for investigating or remediating a situation has been completed by a Level 2 analyst. This stage should not be used if the event is considered a false positive. If the analyst feels that there is a possibility of a false positive, the event should be passed to the Engineer Review stage.

No Further Action Required - Triage

The No Further Action Required - Triage stage (/All Stages/SOC Stages/2: Final/No Further Action Required - Triage) is used when the process for investigating or remediating a situation has been completed by the triage analyst. This stage should not be used if the event is considered a false positive. If the triage analyst feels that there is a possibility of a false positive, the event should be passed to the Level 1 Investigating stage, the Level 2 Review stage, or the Engineer Review stage.

Working with Event Annotation

For details on how to annotate events, please see the Collaborating on Event (Event Annotation) section in the ArcSight Console User's Guide. You can find this in the online help by searching for 'annotation').

Comments with Event Annotation

From a best practices perspective, every time an event is passed to another analyst or another stage, there should be a comment to explain the circumstances or why.

Event Annotation or Cases?

Event annotation is a good way of dealing with issues, but there are limitations. The first, most obvious limitation is the retention policy of your ESM installation. If an event investigation's time is approaching the system's event retention period, then you should definitely consider transferring to a case system, such as ESM's case resources. In some conditions, starting a case could be required by your corporate policy.

-- PrenticeHayes - 22 Mar 2017
Topic revision: r5 - 06 Feb 2018, PrenticeHayes


 


Activate Wiki 2.1.0.0

This site is powered by FoswikiCopyright &© by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Foswiki? Send feedback