In the wonderful world of cybersecurity, one of the favorite tools to use to detect malicious attempts to breach and compromised data is a tool we call SIEM.
SIEM: Security Information and Event Management
Not only can it help us detect events when it’s configured correctly it can even help us learn and identify malicious behavior so that we can turn these observations into future security alerts.
Unfortunately, SIEM is not an easy technology to play with. It’s not something you can buy and unbox and be up and running. It requires careful scoping, strategic placement, the inclusion of specific technology log converters referred to as ‘parsers’ (more on this later), and a high technical skillset to administer, maintain, and mature.
At the heart of a SIEM system is a log management system. The purpose of this article to cover the basics of a what a log management is so that it can either help get you started in log management or help you get started with a solid platform to use to build a SIEM.
Let’s get started.
What is Log Management?
It’s an organized and systematic approach to collecting log files from technology resources and storing them centrally so that they can be reviewed, stored, and used for other technology processes.
The key takeaway here is moving the log files from technology assets (routers, servers, web applications, endpoints, firewalls) and moving them to a central place.
Why move log files to a central place?
Log files that are determined to be important should be moved to a central location for a couple of reasons:
1. Availability: If an asset goes down the logs go with it. Often times all logs will be lost. Even if that server or asset is a part of a back and recovery management process, backups are usually not in real time and there will be a delta from the time the last log files were backed up to the time the log files were lost.
Forwarding important log files to a central log management system will provide redundancy and higher Availablity of these important log files.
2. Integrity: If the logs need to be reviewed for compliance, or for forensic purposes it’s always better to have the logged forwarded to a central log management server because there is better opportunity to retain the integrity of the log file here. They are usually marked, and fewer people have the opportunity to change, delete, and alter the attributes tot eh log file.
3. Visibility: This is one of the highest process improvements that lead to a gain in productivity. Because you can configure all important log files to go to a central location, you can also set up a log viewing dashboard with read-only rights for users that should have it. But doing this the users that need to review log files have one central dashboard to view, query, and review log files instead of manually connecting to each individual system they want to see the log files on.
The other nice thing is the reduction of security log files that occur when users leverage a central viewing dashboard rather than connecting to assets with security privileges (created additional access log files).
You now have the opportunity to provide more people with visibility to log files without provisioning them to the technology resources they would have needed before to get this data.
It’s important to point out that the way systems natively create and maintain logs is based on their individual system policies. This includes what types of events they log, which criticality of logs are stored, and how long they store the logs. For example, on Windows machine here are the event classifications that can be configured for logging:
| Event type | Description |
|---|---|
| Error | An event that indicates a significant problem such as loss of data or loss of functionality. For example, if a service fails to load during startup, an Error event is logged. |
| Warning | An event that is not necessarily significant, but may indicate a possible future problem. For example, when disk space is low, a Warning event is logged. If an application can recover from an event without loss of functionality or data, it can generally classify the event as a Warning event. |
| Information | An event that describes the successful operation of an application, driver, or service. For example, when a network driver loads successfully, it may be appropriate to log an Information event. Note that it is generally inappropriate for a desktop application to log an event each time it starts. |
| Success Audit | An event that records an audited security access attempt that is successful. For example, a user’s successful attempt to log on to the system is logged as a Success Audit event. |
| Failure Audit | An event that records an audited security access attempt that fails. For example, if a user tries to access a network drive and fails, the attempt is logged as a Failure Audit event. |
(credit: https://docs.microsoft.com/en-us/windows/desktop/eventlog/event-types)
Log retention is usually set to a disk space requirement or a time frame. It’s a bad practice to configure a system to store logs for a specific amount of length, without careful consideration, because most log files are stored to the system drive by default. Too many log files could cause the system to drive to fill up. When this happens it can cause the system to crash and become unrecoverable.
A common practice has been to assign the logs files a specific amount of disk space and when that disk space is full, then they should start overwriting the oldest log entries. This is good for system availability, but bad for log retention because if an event happens that can generate a large number of logs can then prevent old logs from being reviewed.
By forwarding these events to a central log management system allows you to remove the burden and risk of log storage off the individual system. This prevents system drives from being filled up and crashing and prevents the overwriting of older log files that might be needed for review.
What exactly is the central log management system?
A central log management system is a combination of log management software running on a server, or set of servers, with a high about of bandwidth, processing power, and a lot of data storage. This system will usually have a database, or a set of databases also running on it.
It’s a beefed-up server with a lot of network throughput and a lot of storage space with fast write capability.
This usually comes in the form of a network appliance (which is really a server). The reason it usually comes as an appliance is that manufacturers and vendors sell it this way so that they can ensure it has enough resources for the job. The truth is the software is more complicated than the hardware aspect, but without enough resources powering the box the software will fail. Vendors are careful to perform a scoping call before recommending the right product. This sole purpose of this scoping call is to determine how many logs, how much space, how much bandwidth, and how much retention (how long logs are stored) is required so that the log management server can handle it.
What systems should send their logs to the central log management system?
It’s like raising a child, things change as they mature.
Basic log management systems will include critical systems, systems that are under compliance requirements.
As the scope and purpose of the log management program mature you can see the inclusion of web servers, authentication servers, application servers, some network event logging, and even the inclusion of endpoints.
Unless specifically required for the program database logs are seldom forwarded to a central log management system. Databases have different sets of logs, and if they are required for your program careful review should be performed before ingestion. The biggest trouble is that the database creates a lot of logs and this can overwhelm a central logging system quickly.
Can I send anything to the log management system?
Before sending logs to the log management system you need to make sure the system can ingest the logs correctly. To do this they need to be ‘parsed’. This means all the data that makes up that log message needs to be broken out and organized to it can be organized and stored correctly.
Logs messages come with all kinds of data in them. Most often they will include things like:
* Time & Date
* User Account
* Event Classification
* Source
* Destination
* Log Type
Not all systems organize this data in the same way. That’s why a parser is important. A parser is a software that knows how the originating system prepares log messages and can organize them for proper storage in the log management system.
These parsers can run at the log management system, or they can run on agents. Agents can run on centralized servers strategically placed in the environment, or agents can run on the system that is the source of the log messages, thus parsing the messages before they are sent off.
So before you consider including a system for log forwarding to the centralized log management system, look at the documentation for the log management system you’re using and see if a parser is required or and agent installation is required to properly organize and store the data.
How long should I store log for?
This is a money question. The purpose of the log management system is to retain and store logs in a central and secure location. The reason to do this is to either:
1. Meet regulatory requirements for log retention
2. Meet policy requirements set for by the business in the information security policy
3. Best practice
4. Personal desire & interest (this gets fun).
So how long you store logs for should be dictated first by requirements from outside regulations, or inside the policy.
After that consider other logs that would be beneficial to store for your unique business. For this, a tabletop review with IT parties can help review and determine what systems are good candidates for log forwarding. There are some best practice guides, but they will focus more on the implementation than the specific types of systems. The best resource I can recommend is either:
1. Industry groups: Other businesses in your industry have invested in asking this same question. They are great to leverage and get ideas from and hear how and why they made the determines they did for system log ingestion.
2. Vendor Partner: The fear is vendors will tell you to include more systems than what you need, because the more you include in a logging program the bigger the central log system you’ll need and the bigger their sale. But the truth is, if you find one, the representatives from these companies are the most highly trained and knowledgeable resources you will find. They bath in this stuff. Even the best consultants will fall short of the vendor reps.
3. Professional Consultant: If you want a non-biased perspective it might be a good idea to find a consultant. Try to find one that has clients and experience in your specific industry (to point number 1).
Finally, there will come a point when everything you need to include, and everything you should include, has been set up and configured. At this point double check the central log system has space and resource availability for additional log sources and have fun. These systems may not be apparent at first, but once you grasp the power of this system problems will start to come to mind that could potentially be solved by a central log server.
Examples might include a web server fails over about the same time every week (it’s always a Tuesday). A user continually gets locked out of their account after changing the password. There is an outage on an application and the developer claims ‘nothing changed’.
Conclusion
Hopefully, this has given you a good idea of the purpose, scope, and power of a central log management system. Our hope is that it has been a teaser for the great and almighty SIEM system.
There is a whole set of logs all of the network resources create specifically to ‘Security’ events! What if we could capture all of these security events and review them? What if we could correlate multiple events from diverse sources? What if we can leverage the power of correlation to alert us when something out of the ordinary happens? And what if this could all be done from one central dashboard?
Yes, that my friend, is the power of SIEM. It’s not easy, but it’s good.
What are some log management best practices?
If you still want to learn more about log management we’ve provided some resources below.
https://www.whatsupgold.com/best-practices/event-log-management/
https://logdna.com/what-is-log-management/
Recent Comments