Introduction
If you are an IT security professional then you have a number of tools in your tool-belt. Or maybe you have an understanding of many different ways to address IT security topics.
One of those security topics is too learn to read the computers logs, and to learn how to address findings in this computer logs.
The Windows Event Viewer
One great source of computer logs is the Windows Event Viewer.
This was Microsoft’s attempt at consolidating all logs into one place. I think the idea was good but the program wasn’t implemented very well. In other words, there’s a surprisingly high learning curve to use this program. The good news is the program is powerful, there’s a filtering filtering capability that is some help, and the program allows you to view the system logs of other computers. (Assuming you have the applicable security).
It’s good to study these logs. Look for errors and attempt to resolve those errors. Bear in mind that if you are primarily an IT security professional, then you probably have access to PC techs and other it professionals to assist you. It may be the PC Techs jobs to address errors.
You need to understand the difference between normal traffic and suspect traffic.
application logs
Another source of logs come from the application logs.
Most applications that are installed on the computer do some sort of logging. You ought to inventory the programs installed on the computer and learn how they log, and then learn those log files as well.
There are a couple of considerations about application logs to keep in mind.
Application updates may change the way that application performs logging. It’s good to study the logging behaviors after each upgrade. The vendor may make changes that you should be aware.
Some non mature applications may leak sensitive information into the logs (like passwords). If you find these sort of leaks, report it to the vendor or programmer and request an update.
Some applications will post their data both to the system log and to their own proprietary logs. It’s good to understand the differences between those logs. (As you might be able to edict the number of logs to monitor)
The Baseline
When out comes to logging management there’s a term used out there called baseline. This refers to was the log looks like normally. For example when you first format a computer and install the operating system.. that could be considered a baseline. Maybe setting up 5 computers could produce the same base line. You install several more applications and everything is running normally then maybe for that computer that is the new baseline. You give the computer to someone they start using the computer properly then that could be considered the baseline.
The point is you want to train yourself into knowing what the baseline is, and you want to train yourself into identifying deviations from the baseline. These are where your skills as an IT security start coming into play.
It’s also important to know that each computer may have it’s own baseline but maybe computers used by groups (like engineering, or clerical) may have similar baselines.
Application updates.
Vendors will update there applications for a number of reasons.
• To fix a bug
• To better secure an application
• To add features.
I think the first 2 bullets are the vendor priorities. But for these reasons you want to keep this applications current. But a side effect is what they log may change.
It’s good to restudy the logs an application produces to learn about the logging changes. Sometimes this changes could be important during incident tracking.
Consolidating logs
Many organizations will attempt to consolidate their logs. The advantage of the consolidated log is you only have one place to check logging. If that central location supports rules, then applying the rule could apply to all logs.
Further research is SEIM - SEIM platforms are designed to connect logs.
Keeping logs
A question that crossed my mind is how long do you keep logs?
This is tough to answer. Here’s a couple of answers.
- Find a company policy that tells you how long. Create one if needed. Don’t keep them any longer.
- Until you have reviewed them.
- Forever.
You can see by the second and third bullets that the answers vary widely.
Pros and cons
Until you have reviewed them. The problem is you could miss something that later becomes important. Sometimes that later importance turns into ‘what do you mean you deleted the logs!’ This could result in lost jobs.
Forever The problem here is logs take a lot of space. Consequently, log management tools slow down, log storage become expensive, some people get overwelmed - but that’s probably a fault of the program.
If you look at the cons of Forever vs until you have reviewed them, then the first bullet ‘as long as the policy says (and no longer)’ becomes a very good answer. Hopefully management is included on the responsibiliy channel when you are following company policy.
example
Example Yahoo breach - more information: https://www.upguard.com/blog/biggest-data-breaches-us a data breach started in 2013 went to 2016. Here you can see that they kept records for a number of years, so they were able to trace it back to when out first started.
Also, if you read the article it seems to me that penalties increase (in yahoo’s case $35 million) If the response is considered slow or unresponsive.