maxkabakov - Fotolia
Considerations for SIEM logging software and storage
SIEM systems aggregate a lot of data across all types of infrastructure. For regular audits, admins should address notification settings, analysis protocols and storage locations.
Now that security information and event management tools cover so many infrastructure areas, admins must regularly audit these systems. These portals should help raise immediate issues for the system or admins to deal with, but regular checks through the SIEM logging setups can help to identify other areas worth an admin's attention.
However, the extreme volume of possible data does require admins to filter close to the data sources. This means the use of intrusion detection/prevention systems that have some degree of analytical capability that can decide to leave data where it is, delete it or send it to a more central system for further analysis. This is where problems can occur, as this analysis deals with a subset of the actual data, it is incomplete.
The SIEM system must be able to pull any other required data in real time. This is an extra workload on the network -- make sure that the chosen SIEM logging tool does this data pull in an intelligent manner that makes any required analysis easier.
To move or not to move data
Consider a firewall that maintains extensive logs. Source and target addresses, ports being used and type of traffic are all logged. The majority of this data is normal activity and not immediately needed. Many firewalls can analyze this data but are set up to retain data over a certain timeframe.
Generally, admins can leave most of the data in its default storage location. If there is a need for a forensic analysis, there should be enough data in the firewall's own storage to investigate.
Where the firewall identifies an alert as outside of agreed parameters, the system might execute its own remedial actions. If the firewall system does not understand what is happening, then it can raise an alert for admin intervention. This is where an intermediate data collection device can be used to decide whether there really is a problem.
If the device decides there isn't a problem, then the data can be left where it is in the store. If the system believes that there is a problem, then it can pull any required data from the firewall, such as packet data against a specific port or data streams coming from a specific IP address, and place it in a secondary store. These stores can either help the device complete a further detailed analysis or make the SIEM logging data available to a more central analytical program.
This can be the same for most devices across an IT network -- servers, storage and network devices will have their own data stores. Some smaller devices may have smaller stores or have nonpersistent stores. SIEM should pull the data from these nonpersistent locations into intermediate permanent stores as required.
Keep policies and playbooks up to date
When it comes to advanced analysis, SIEM logging must work with policies the organization sets and defines, as well as the vendor's base algorithms and heuristics, to deal with as many security issues as possible. Pattern matching is a key part of how SIEM tools operate.
Admins should maintain up-to-date versions of patterns and rules released by the vendor. They must also ensure they maintain their own internal policy list to respond to what they -- and the organization -- see as specific threats in the industry.
With these rules and policies, admins can more easily identify and remediate common problems they find as they maintain infrastructure security and availability. They can also more easily trace the problem's progression of a problem. Important information to use includes time of initiation of an issue, how many times the issue occurred -- such as traffic load -- and when the problem stopped.
This granular knowledge means that admins can more closely define the parameters around an issue and focus on that specific time period, rather than wasting time in dealing with unrelated data.
Any chosen tool set should provide admins a quick and easy way to see what is going on. Admins should look for SIEM logging tools that can intelligently aggregate multiple smaller technical issues into one larger issue.
For example, rather than show an alert for multiple ports on a firewall and for the slow running of a server, the SIEM system can show that there is an ongoing distributed denial-of-service attack against a specific workload. With single-click drill-down functions, and single-click remediation capabilities, actions such as throttling or shutting down a port gives admins valuable information and time savings.
Dig into the archives
When it becomes necessary to carry out forensic analysis, SIEM logging tools must be able to track back through past events. As long as admins identify the breach quickly enough, they may have enough information with access to original data held across the various devices.
However, admins should recognize the original data may have been corrupted during the attack or the data stores might not go back far enough for comparison. It is important for SIEM logging protocols to aggregate data into archival stores.
These archival stores are where admins can go for a copy of uncorrupted and complete data should there be a need to drill down into any problem, and also be the data source when part (or all) of a system is down and the original stores are unavailable. These stores do not replace the need for real-time storage and analysis, but manage the data aggregation as a low-priority task as a data backup activity.
