Link Search Menu Expand Document
Wortell

Usecases

The concept of use cases is very broad. A use case could, for instance, cover the installation of a bumper bar on a car; in the security world, they usually cover an attack method or analysis. An example can be a usecase covering a ransomeware attack. The usecase contains all the logic (instructions) to detect the attack and tasks te respond on this attack. Security products that are being used by Wortell Managed Detection and Response cover a wide range of attacks. By creating usecases Wortell is able to add value on top of these security products.

Wortell has a team of security researchers that improve and create new usecases. Usecases can be created for various reasons:

  • To detect and respond on new attacks, for example zero-day attacks
  • To create respond and detect customer (or sector) specific attacks

The development of usecases is showed in the following diagram:

Define

In order to start with the development a usecase needs to be defined. As part of the define phase of use-case development, Wortell (possibly together with the customer) will set the goal for the usecase. Defining the goal of a usecase is important, it describes why a usecase is created.

This goal will later be evaluated in the testing phase of the usecase development process

Example: “This usecase needs to detect RDP backdoors, so attempts to implement RDP backdors can be detected and mitigated”

Design

In this phase the usecase will get designed. As part of this phase Wortell will investigate what logic is needed to fullfill the usecase goal.

After this step has been completed, it is clear how to detect the behaviour/anomly that is defined in the usecase goal and what stepts are required to respond on this usecase.

Example:

Detection
---------
Configure event logging for scheduled task creation and changes by enabling the "Microsoft-Windows-TaskScheduler/Operational" setting within the event logging service. Several events will then be logged on scheduled task activity, including: 

Event ID 106 on Windows 7, Server 2008 R2 - Scheduled task registered 
Event ID 140 on Windows 7, Server 2008 R2 / 4702 on Windows 10, Server 2016 - Scheduled task updated 
Event ID 141 on Windows 7, Server 2008 R2 / 4699 on Windows 10, Server 2016 - Scheduled task deleted 
Event ID 4698 on Windows 10, Server 2016 - Scheduled task created 
Event ID 4700 on Windows 10, Server 2016 - Scheduled task enabled 
Event ID 4701 on Windows 10, Server 2016 - Scheduled task disabled 

Response
--------
A) Disable scheduled task 
B) Kill process with name "plink.exe"

Develop

In this step of the usecase development process, a Azure Sentinel Detection will get created and a Vidara Automation Rule with task defintions is created.

The detection logic as defined in the design phase will get translated to a KQL Query (Kusto Query Language).

Incidents in Vidara are resolved using Wortell’s own Task Based Incident Handling approach. In this approach all activities that need to get executed to triage, investigate and respond on an incident are defined in (automated) tasks. When the incident is created, an automation rule automatically adds the tasks to the incident. Depending on the type of task, tasks can be executed automatically or manually.

Defining tasks and automation rules will make sure that each time the incident occurs, Wortell will respond in the same way.

Test

Each created usecase needs to get tested. Wortell has multiple test/lab environments that can be used to test the usecase.

It is important to get back to the definition of the usecase again and determine if the developed usecase does fullfill the defined goal.

As tests in testing/lab environments have succeeded, the usecase will get deployed to the Usecase Insider Ring. By default customers are assigned to the stable ring, it is however possible for customers to join the insider ring.

During the testing phase, bugs can be found. When bugs are found. Bugs will be resolved by the usecase developer and the usecase will get redeployed.

Deploy

When there are no bugs/findings found during testing, the usecase will get deployed to the stable ring. All customers that are subscribed on services that include the Wortell Protect Usecase library will receive the new usecase.

*If the usecase is created specifically for a customer, the usecase is only deployed in the tenant of that customer.

Evaluate

Usecases are evaluated periodically. The result of the evaluation can be:

  • The usecase triggers to many false-positive alerts. It requires tuning.
  • Research shows new detection possibities, the usecase needs to be altered to include these new detection possibilities.
  • The usecase works perfectly, altering the usecase is not needed.
  • The usecase is obsolete. It can be removed.