Why SOCs Need Security Analytics?

In the last few year, I’m sure you have used or heard the term “security analytics” more than any other industry term. However, many people are still trying to figure out what it’s really about. I’d like to share some of my thoughts on security analytics, and what it can for any organization.

Most security incidents are caused by things corporate end users have done. For example, let’s talk about John Doe. John’s day starts by swiping his card into the physical access system (PAS) to get into his place of employment. He then logs into the VPN via his laptop, checks email and accesses various business apps he needs to be productive. During breaks, he’ll also use his corporate laptop to check out what’s being talked about in the news, get updates from friends on social media sites, and sometimes shop. At the end of the day he swipes his card in PAS again and drive home. When he’s not in the office, he can connect to VPN system from his home or a hotel, if he’s travelling.

Now, lets think about this from a security operations point of view:

The PAC system generates logs and sends them to the SIEM system. The Active Directory (AD) keeps track of end users’ logins and the SIEM has multiple rules enabled to alerts on suspicious activity. For example, alerts are generated if brute forces are detected or if regular user accounts are connect to privileged systems.
The web proxies block inappropriate sites automatically. The SIEM system also raises alerts when some traffic is allowed by firewalls but matches threat intelligence fed into the SIEM. Security teams then investigate traffic and take appropriate decisions based on investigation outcome.
SIEM also has rules that detect if VPN access is done from IP’s that are flagged by threat intelligence.
Application access is controlled by identity governance solutions (mostly) or manually.

This rule-driven approach:

Overall view is not visible to the SOC team. Everything appears in silos as different activities. Analysts are expected to build the storyboard after an investigation.
Has a high number of false positives as the SIEM fires individual alert for every single activity.
Needs well-skilled analysts
Misses security incidents if the rules don’t match the malicious user’s activity or activity performed by insiders.

Security analytics brings a different approach to handle these issues as well as detecting more incidents. Security analytics systems take data from various data sources like AD, SIEM, DLP and also other IT systems like HRMS, etc. The data is in the form of user profiles, logs, network sessions, as well as endpoint data — this data is generated when a user or system performs an activity. There are only a few solutions already available that focus on user behavior. They are called as UBA (User Behavior Analytics) or UEBA (User and Entity behavior analytics). These systems often integrate with identity management systems to track user identity, behavior and access activity. Its focus is to identify issues with user behavior, but the system can also identify issues around network behavior or system behavior.

Once the data is collected, the system uses machine learning, statistical algorithms and other mechanisms to analyze the data. This analysis helps a SOC team compare an entity’s behavior with its historic behavior as well as entity’s behavior with its peers/population. For example, John Doe and his sales team will typically access the same systems, web portals and other apps that help them accomplish their daily priorities. You’ll see a similar pattern across an organisation’s different departments – like HR, finance and marketing.

This analysis generates scores to individual activities performed by a user as part of his/her behavior. Overall an aggregated score is then presented to the SOC analyst to help him decide if the behavior is good or bad.

Let’s take the same example above and pass it through an analytics solution that is reading all your logs, network sessions, profile from HRMS, access rights within the governance system, as well as, end point data.

User “John Doe” is connected from a source country where organisation has no presence- Score 92
User “John Doe” is connected from a source IP thats part of a threat intelligence feed- Score 100
User “John Doe”s vpn duration is 4 hours vs Avg of 8 hours for his group-Score 82
User “John Doe” connected in a timezone different than his profile timezone- Score 80
User “John Doe” transmitted over 1 Gb of data. Compared to his avg of 300 mb and group avg of 250 mb.-Score 80
User “John Doe” VPN Session duration is over 6 hours compared to his historic avg of 20 mins and group avg of 1 hour. Score 90
User “John Doe” downloaded applications that are part of the sys internals tool list(by matching hash)- Score 95
A few more… around system or network session data.
Over all risk score is 95

The system will also add identity context stating that the user is part of a sales team (HRMS). His last PAS log was 7 days back. The user’s IN office location is set to “Travel”. Other contexts, like asset or group, can also be there.

The SOC analyst can understand the entire view and can then make informed action on what’s happening. Is this user travelling? Or, were his credentials stolen? Leveraging security analytics can help detect threats faster and make a SOC team’s life easier.

The post Why SOCs Need Security Analytics? appeared first on Speaking of Security - The RSA Blog and Podcast.