Like every IT department, you started protecting your network with a few point solutions that focused on the security of a particular part of your environment. But as your security strategy matured, you quickly realized that the point solution methodology simply doesn’t scale: you don’t have time to master multiple platforms, you need singular visibility across all solutions, and you need to leverage data from multiple solutions to provide better context when assessing the current state of security.

So, like most organizations, you’ve either invested in, or are considering, a Security Information and Event Management (SIEM) solution. If you’re not familiar with SIEM, it is a log consolidation, analysis, reporting, and alerting solution that corroborates security event data from many sources to give you visibility into what’s going on anywhere in your environment.

SIEM solutions have their benefits – a single security view across all your systems and applications, activity insight using multiple sources to provide context, correlation of otherwise disparate data sets, and many more.

But SIEM solutions aren’t without their challenges as well:

• A single solution means very large data sets to filter through, correlate, and find instances of suspicious or abnormal activity

• Improper configuration of correlated events can result in lots of false positives

• Requires significant expertise to truly benefit from the solution

At the end of the day, the SIEM solution itself is a means to an end – better security, first through detection of anomalous behavior and then through providing context around user activity. And that’s where SIEM solutions shine – SIEM solutions can have so much detail on user actions, that it’s tough to find an alternate.

But consider that the only reason organization’s need all that user activity data is usually because threat detection did not happen early enough. Think about it: if you can detect (and, potentially, stop) a threat well before any malicious actions take place, there’s no need for any activity data (in fact, there will be none). And if there’s a way to more easily achieve that end, it’s worth exploring.

So, allow us to make the case for a single, simplified way of providing better security, without the complexity of a SIEM scenario – that being the use of a logon management solution such as UserLock – to provide better security in the area of threat detection.

In this whitepaper, we’ll define logon management, go over what it takes to detect a potential threat, and look at how (and how well) each type of solution addresses the problem.

The concept of Logon management may be a bit foreign to many organizations, as most haven’t even taken steps to properly monitor all logon activity. The idea behind Logon Management is to not just audit logons (you can do that with SIEM alone), but to add policies and restrictions around logons as well, so that the logon itself becomes a managed event. Don’t want anyone logging on with admin rights after hours? Logon Management addresses that. Limit access to your Domain Controllers to only in-house machines on a certain subnet? That too.

In essence, logon management makes the logon itself a scrutinized and protected event. The ability to successfully logon (and remain logged on) becomes more than just whether the right credentials are used.

There are four basic features to Logon Management:

• Policies & restrictions: Instead of simply allowing everyone to log onto whatever they want, Logon Management uses policy-based restrictions to define who can logon, how (e.g. RDP, local), from where, how often, and when.

• Monitoring & auditing: Every logon is monitored and tested against existing policies to determine if a logon should be allowed.

• Alerting & responding: Alerts are used to notify IT (or appropriate users), of both successful logons and failed logon attempts. As well as logons being denied, logoffs can be forced - both manually and automatically - to ensure security at the logon.

• Reporting: This should go beyond just an audit report of who logged in where. Because Logon Management is taking action (in both the allowing and denying of logons), reporting is necessary to ensure security and compliance.

Now, admittedly, this looks, sounds, and functions nothing like a SIEM solution. However, aside from the auditing functionality, it is a completely different solution than SIEM. And that might be a bit confusing – everyone knows an SIEM solution is the choice of solution for detecting just about anything in your environment.

So, how does logon management help with detecting threats, when compared to a SIEM solution?

Let’s begin by establishing what kinds of threats we’re talking about. You’ve got both external threats and insider threats to be concerned about.

Insider threats are, generally, difficult to spot, as users are simply misusing their existing credentials to act on their own behalf. External threats tend to be thought of as being a bit easier to detect, as actions like exfiltration of massive amounts of data stand out as being unusual.

The key to detecting either type of threat is watching for anomalous behavior. It’s one of the reasons SIEM is a common choice for threat detection. But, let’s see how Logon Management stands up.

To create this comparison, let’s use a few fundamental security goals each of the solutions should attempt to reach:

1. Identify the potential threat as early in the attack process as possible. The earlier detection occurs, the less damage the threat actor (whether internal or external) can do.

2. Create as few false positives as possible. Detection is all about watching behavior and determining if its abnormal and/or suspect. If detection parameters are too broad, IT is spending their time chasing ghosts and not stopping threats – which brings us to the last goal…

3. Stop the threat. This is more an idealistic goal, as not every solution has the capability. But, at a minimum, we’re looking for contextual detail in this comparison to assist with this goal.

A SIEM solution has the benefit of potentially collecting log data from nearly every part of an attacker's kill chain – from initial infection of an endpoint to compromising elevated credentials, to lateral network movement, and finally to the intended malicious activity (e.g., to exfiltrate data, to encrypt it for ransom, etc.).

But most organizations leverage SIEM solutions to watch for those security events that an existing third-party solution isn’t already addressing. Take your endpoint protection for example. Organizations with ample endpoint protection aren’t necessarily interested in piping all the endpoint data around which processes are being run, etc. into a SIEM solution.

That means SIEM is being used to watch activity that specifically can indicate a threat – file activity, web browsing, downloads, uploads, etc. And since your organization is unique, no SIEM solution, out of the box, knows what exactly to look for. Sure, they have machine-learning, etc. that can help spot anomalies, but it has no idea of a user copying 100 files is good or bad.

At the end of the day, you’re going to need to define what a threat looks like. And that’s a problem – as IT is thinking about threat actions that, if detected, mean the threat actor is already taking action. Which means, SIEM may be detecting too late.

So, you widen the scope of what defines threatening activity to include more, just “suspicious” activity. And now you’ll find yourself with many more false positives.

And, if you are to spot an unusual activity in a SIEM solution, because you are probably detecting the threat action itself, SIEM has done little to stop the threat.

Because most SIEM solutions today can ingest data from just about any and every system, application, etc., it’s highly likely it can be used to detect a potential threat. The challenge is will it be a case of too little, too late?

One common action that all attackers must perform is log on – authentication is a necessary part of the lateral movement process or attackers will get no further than the initially compromised endpoint. Insiders need to authenticate as well, so the logon becomes a pivotal point in both attacks.

So, rather than focusing on all the countless possible ways attackers can attempt to infect endpoints, compromise credentials, move laterally, and malicious act against your organization, why not simply watch for the one common action they can’t get around: logons. Let’s look at how Logon Management would address both internal and external attacks.

No insider wants to be caught, so misusing their credentials often occurs after hours, or remotely, to avoid drawing attention. Logon Management policies should be configured based on the risk of an individual’s role within the organization – if they have access to financial, personal, or IP data, for example, their logons would come under far more scrutiny than someone with no access to valuable data.

So, when they logon from home on a Saturday at 11:30pm, what happens? Logon Management spots the abnormal activity, and acts accordingly, based on defined policies. Everything from alerts, logon approvals, or even logon denial can come into play.

External attackers establish a foothold via a compromised endpoint. They then work to identify elevated credentials and use those credentials to laterally move around the network – eventually finding their way to a system housing valuable data.

When an external attacker attempts to authenticate to, let’s say, a server from a compromised endpoint, they’re not concerned about making it look like it’s a normal business function – this is about getting to valuable data as quickly as is possible without being noticed.

So, when a request is made to log on to that server, Logon Management spots the abnormal logon request, and based on policies, denies the logon, and notifies IT of the failed logon attempt.

First, the logon itself is detected as a potential threat action, identifying the threat potential very early in the attack process.

Next, the logon is denied, stopping the threat.

False positives are avoided through a number of methods that include configurable policies to define what is and isn’t “normal” on as granular as a per account basis, the analysis of normal logons so only truly abnormal logon occurrences trigger, and policy actions that don’t deny the logon, but request approval from a peer or manager. It is this last one that truly avoids false positives. A simple phone call from a manager to their employee is all that’s needed to allow access when it’s deemed appropriate, thus keeping IT from spinning their wheels chasing false potential threats.

The following table provides an overview comparison of how SIEM and Logon Management each attempt to address the detection of threats.

In short, SIEM, while capable of spotting unusual activity, does little to spot a threat without the specific defining parameters from IT. And even when a threat potential is identified, it’s already too late, as the files have been accessed, and the data exfiltrated.

Logon Management provides a protective layer at the logon, which logically exists before a threat actor can take action, with the added ability to stop the actor entirely – no logon, no threat.