Security Operations

Introduction

Devo Security Operations (SecOps) is a purpose-built, context-rich application framework that automates security expertise, speeds investigation and triage, reduces required resources, and magnifies response capability.

The application uses different types of sources to detect and manage security threats. For instance, events from firewalls, IDS, or proxies as in any Devo domain. This information could generate alerts, but also entities. An entity is something or somebody involved in any type of threat or associated with other suspicious entities. An entity may be a source IP or a server, but also a URL or a user. SecOps stores all the entities in a graph state database and uses them to relate the alerts and get valuable information about the origin of the threat to complete an investigation.

There is another source very important for SecOps: the feeds that come from the Devo MISP system. This system searches on the internet for any suspicious security feed and recovers all of them into different files that are stored in the Devo system as lookup files.

Once the sources are prepared, we only need to configure the proper alerts to take advantage of all this information. SecOps is mainly based on a set of alerts that need to be set on Devo tables using the Devo alerting framework. These alerts have been created by following specific security rules in order to cover the highest number of attacks. For instance, looking for strange user behavior, port scanning, denials of service, wrong URLs, large and uncommon user agents or suspicious interactions with DNS servers.

Finally, Devo uses flows configured in the system to enrich data from the alerts with feeds that come from different external sources and also create automatic investigations with no need for user interaction.

With all this information coming from different sources, users can access the application and start triaging alerts, creating investigations, and performing hunting to search for specific events in the whole system.

Security Operations required permissions

In order to use SecOps properly, users need a series of permissions assigned to their roles. Admin users in Devo can add and manage role permissions in the Administration → Roles area of Devo.

If you are an Admin user, go to the Administration → Roles area, access these tabs and assign the following options to your SecOps users:

Permissions tab

These are the minimum required permissions to use SecOps:

Applications tab

SecOps users may have access to SecOps applications with and without entities. Assign the following permissions as required:

• Security Operation with entity analytics

• Security Operation without entity analytics

Alerts tab

By default, SecOps users should have access to all the alerts, but Admin users may assign only specific SecOps alerts to users if needed.

Lookups tab

By default, SecOps users should have access to all the required lookups. However, Admin users may also assign specific lookups required for some alerts to be installed.

How does Security Operations classify alerts?

SecOps alerts are mainly based on real-time data uploaded to Devo union tables, although this information is usually complemented with lookup tables (files with security feeds from MISP services) and machine learning models.

As said above, alerts are based on Devo union tables, so the application only needs to take information from those tables. For instance, alerts are taken from the firewall.all.traffic union table. This table gathers information from all the firewall technologies in the platform, so any customer could share data from different firewalls (Paloalto, Sophos, Juniper...) and the Security Operations application will set the alerts (and other necessary insights) using only the union table. There are union tables for each technology: firewall, web, proxy, edr, domains, authentication...

SecOps alerts are divided into four categories:

• Detection - Detections are static definitions based on known behaviors. These are alerts that pose a critical threat and must be triaged and added to an investigation immediately. For example, an RDP session occurred between <IP> and <IP> more than ‘X’ times in ‘Y’ minutes.

• Observation - Observations refer to a change in the behavior of an entity in a specific time period. These alerts pose a low threat and should be added to an investigation depending on the circumstances and user's criteria (for example, if there is a high number of these types of alerts). For example, an entity or customer role change in the server.

• Analytic - Analytics provide expertise across raw data, and provide insight from the data itself. These alerts do not pose a threat by themselves, but might be added to certain investigations to complement them. For example, look for a specific virus hash in a hash table.

• Models - Alerts obtained by running a machine learning model. For example, a Windows program shows a high number of DLLs and it is difficult to tell if it is suspicious or not by only analyzing raw data, so it is analyzed by running a machine learning process.

Apart from these categories, each alert has a priority level defined in SecOps: Info (1), Low (2), Medium (3), High (4), or Critical (5). 

Finally, alerts are also classified following the MITRE ATT&CK definition of techniques and tactics. Each tactic has several techinques and alerts are assigned the ones that best define their nature. Learn more about the MITRE ATT&CK system here.

Security Operations lookups

There are three types of lookups in SecOps: main lookups, multi-lookups, and dynamic lookups.

• Main lookups are available only on the domain the SecOps app is installed. The installation of these files is performed by the Devo team and they could be watched and modified by Admin users. The most important lookup is SecOpsAlertDescription, which contains the list of predefined alerts used in SecOps.

• Multi-lookups are available to all domains, but users cannot modify them. Some of them are SecOps configuration files, and some others store security information that comes from MISP services. This information is periodically updated in different ways. Some are static (for example CheckBackdoorConnection), some are updated weekly (for example SuspiciousFileExtension) and some others are updated daily (for example. farsight feeds).

• Dynamic lookups are not-editable files that are periodically updated. The periodicity depends on the necessities of the alerts. These lookups contain values that are calculated with real data and are constantly changing. This data is used to improve the behavior of the alerts. For instance, we can calculate the daily or weekly average of DNS traffic detected by a firewall. This average is stored in the dynamic lookup and then we can trigger an alert when detecting peaks.

Devo SecOps provides customers with a set of predefined security alerts designed by experts, which are one of the basic aspects of the application. Users can tune these alerts attending to their necessities, or create new custom alerts to include them in the SecOps application.

User roles in the Security Operations app

In order to use the Security Operations app, you only need to be given access to the domain by the domain admin. Once a user is given access to use SecOps, he or she could access the whole app without any restriction (this fact could change in future releases). The difference with other Devo vertical apps is that in SecOps, all actions could be persistent. This is very important when the app is deployed to run in a Security Operation Center environment (SOC).

Users in a SOC could be divided into operators and analysts. Although the Devo role to use SecOps may be the same for all, the way of using the app is clearly different depending on the type of user, and all of them have to share the actions and investigations done with the others when they finish the work shift. You could also have different levels of analysts; some of them may only take a quick look at the Overview Dashboard, open investigations, and write notes defining a suspicious event that needs to be investigated. Then, they may share the investigation with an operator to do a much deeper analysis or hunting.