“Because according to the logs, you’ve already come into the building at 1 am, 3 am, 4 am, 7 am and 8am. Oh, and you’re still in there.”
Security logs are critical for any organization of almost any size. This is because it doesn’t matter if you have 50 people or 5 million; it is still vitally important to protect the people at your locations, your assets and your data.
For the purposes of this article, we’ll be looking specifically at Windows 10 security logs. But because of the sheer number of events that can get generated, we’ll be going into a few more advanced topics as well.
Accessing security logs
Like most Windows logs, we can access these via Event Viewer. This time around, we’ll go straight there by clicking on Start and typing in “Event Viewer”.
Once in Event Viewer, we’ll want to drill down through Windows Logs and click on “Security”.
As you can already see, security logs generate a LOT of activity. If you don’t see anything in here, there is a major problem somewhere which will need to be addressed.
To access the settings for your security log, you’ll want to right-click on “Security” and select “Properties”.
The size of your file is directly related to the amount of events that get generated and how far back you need to go. For example, with the current configuration on this system, the log is currently able to show data going back approximately one and a half months. That’s not bad for a single workstation, but we’re going to have significantly more data to parse through in a larger environment.
Let’s say for a moment that we wanted to record all user logons to the network from all of our workstations. While we could try to pull logs from every single workstation, that would produce an enormous amount of noise for not a lot of bang. If our network is Active Directory-based, however, we could pull our scope back and specifically target our Domain Controllers. This could then show every Domain logon attempt in a much easier to manage way.
What we will want to do if we decide to go this route is make sure that we are auditing both successes and failures for logon attempts. Why is this important? Successes will show us who is logging in when, but failures will show us what accounts may be getting attacked — hundreds or thousands of potential logons over a short period of time that we might not see if we don’t have our auditing settings set up properly.
The easiest way to do this will be to create a Group Policy Object containing our auditing settings, which can then be applied to whatever systems we choose in the future. You’ll want to access Group Policy Management through your method of choice, select the GPO object you wish to use, right-click on it and select “Edit”.
Once the GPO has come up, we’ll want to navigate downwards to “Computer Configuration, Policies, Windows Settings, Security Settings, Advanced Audit Policy Configuration, Audit Policies, Logon/Logoff”.
There are a number of possible settings here and Microsoft provides a list of their own recommended best practices, but the ones for our example today will be focusing primarily on user logins. This means that we’re going to be most interested in three specific options: Audit Logon, Audit Logoff and Audit Account Lockout. For all three of these, we’re going to want to double-click on the text on the right side of the screen and make sure to select “Success and Failure”.
The short answer for why we want to add in all of these is simple: we need to know when users login and logoff in order to create a baseline for user activity. Once we have that, we can tell more easily if user accounts login at strange times, or log in repeatedly without ever logging off as in our example.
Lockout tracking also provides another metric to see if particular users continually become locked out for one reason or another. This can be especially useful to tell if particular accounts are possibly being targeted maliciously.
But all of this information being gathered on a minute-by-minute basis can very quickly become more than a single person can handle without help. Fortunately, that’s where Security Information and Event Management (SIEM) can come into play.
There are a number of different software packages online that are designed around the idea of gathering log files and other data from a wide variety of sources and centralizing it for easier management, analytics and storage. These range from tools to automatically pull in data once a day to real-time smart analytics capable of sending alerts if preset conditions are met.
While a large number of them are designed strictly for large enterprises, there are several others that have a considerably lower entry point. One that can run the gamut from small to large organizations for example is Snort — available here. This open-source program can aggregate logs but also works as a network intrusion detection system and can capture packets for later analysis. Be sure to check out a wide variety before making the jump to see what is best for you and your organization.
Security logs are another one of those things that a lot of people don’t really pay attention to until it’s almost too late. Fortunately, it is possible to offload some of that responsibility as long as you can take the time to set things up properly and make sure that it continues working as expected.