Appropriate log management tools can greatly reduce the burden on managing enterprise system log data. However, unless organizations put the necessary time and effort into this tool, the best tool will soon become a poor tool. Diana Kelley provides six log management best practices to ensure success.
The layman uses the tool and is still a layman.
If you are not prepared to spend time and energy installing and managing log management tools properly, do not waste your money on the log management system. The log management system must be properly configured to correctly parse the events and logs in your network so that the reports can be of commercial and technical value. Another "stupid" error is that critical security events are missed because you do not browse and review the alarm console. Therefore, do not make mistakes that only focus on log management technology and do not focus on system usage.
Streamline RFP Request proposals through predefined requirements)
Creating RFP Request proposals and requirement statement is a time-consuming process. Once defined, some requirements can be reused in the subsequent RFP. This is common when developing log management requirements, because the basic requirements of log management, such as the log file format, the data written into the log file, and so on, are the same and can be pre-defined. Another benefit of using predefined requirements is that this ensures that requirements are consistent while streamlining the RFP cycle.
Are you sure you have the required information?
To write effective association rules, the log management system must have sufficient contextual data for analysis. For example, to determine where a specific traffic or behavior comes from, you need to know the source IP address information, which means that the log management system must first record the IP address information, in this way, the engine can parse it. For example, if you want to write a log analysis rule to alert the behavior of the target device or application, the relevant log data must first record the behavior.
Not limited to Static Analysis
The last thing most organizations need to do is to fill in data that does not have an overall analysis model into another large table, and then use this large table for event analysis. Alarms set based on the baseline of expected or acceptable behaviors are generated by analyzing the features of a single record in a large table and by analyzing the features of a set of records. Consider the logon records of key databases. Generally, the two logon failures are set to the baseline that triggers the alarm. However, if the password policy of the database system changes from using simple dictionary words to using more than eight non-dictionary word strings, the baseline for the number of Logon failures may increase because the user needs to adapt to the new policy. Log Management Systems with intelligent sensing capabilities should be able to adjust to monitor development trends and provide feedback to administrators. The administrator can temporarily change the alarm threshold using this trend information.
Use log data to describe what is happening or is happening
"Logs are an excellent source of information for fault detection ". In most cases, all the information required by the user to determine the cause of the fault can be found in the log file. During the crisis, managers often have to enter the passive mode. They can only judge what is happening by intuition, speculation, and piecing together irrelevant information that cannot be further divided. Logs are records of real events. The log management system allows management personnel to write and generate reports for fault information in real time, so as to tell the response team what happened in the network.
Beyond the scope of security itself
The log management system is an excellent security device information collection and analysis tool. It can be used not only for security awareness, but also for other purposes. For example, you can use this information to analyze your customer experience in ten business relationships. Many WEB application analysis systems cannot provide fine-grained views that demonstrate real customer experience. Well-designed application system logs can record these customer experiences. The log management system can use these logs to analyze the customer experience and extend the application field of the log management system to security analysis.
Note: This article is published on TT security. Here, I want to talk about some of my understanding of these six best practices on the basis of the original article, hoping to help readers understand the meaning of the original article.
1) log management is a tool rather than a decision-making system. Therefore, good tools also need to be used by people. Tools only improve human efficiency and do not replace people. Log Management LM) or log audit products.
2) many basic requirements of log management are relatively fixed, which is determined by the operating principle of the log management log audit system. I have analyzed the principle many times before, including here, and here), and I will not repeat it here. In advance, we can define our network's requirements for log management's EPS performance, storage requirements for time and space), the types of logs to be analyzed, the requirements for query performance and availability, and so on.
3) "It's hard to be a man without rice ". Log auditing is based on logs. Good products. If logs are missing, the previously set analysis results cannot be achieved.
4) audit rules should be dynamic and change according to actual environment changes. This means that in most cases, the analysis rules cannot be written into the system, but are customized according to the actual situation. There can be templates, but many parameters must be specific.
5) logs are really useful. Some people compare them to the gold mines of security analysts, but they still need help from log management tools to extract real security issues from the gold mines, otherwise, it would be a haystack.
6) log management is useful not only to security auditors, but also to system performance and fault analysis personnel, and even to business departments. However, at that time, log management was not a simple log security audit system. The principles were similar, but the analysis targets were different.