Logs, Logs, and More Logs: Why You Need SIEM and How to Make It More Effective
Four score and one post ago, we talked about Baltimore’s beleaguered IT department, which is in the throes of a ransomware-related recovery.
Complicating the recovery mission is the fact that the city’s IT team didn’t know when the systems were compromised initially. They knew when the systems went offline, but not if the systems were infected earlier. The IT team can’t go back and check a compromised system’s logs because ransomware rendered the infected computers inaccessible.
Anyone who has worked in IT operations knows logs can contain a wealth of valuable information. Logs are usually the first place you go to troubleshoot or detect problems. Logs are where you can find clues of security events. Commonly, though, you can end up having to sift through a lot of data to find the information you need.
In any ransomware or security attack, a centralized logging server or Syslog is an invaluable resource to trace back and correlate events across a plethora of servers and network devices. Aggregation and correlation are jobs for a SIEM.
All About Those SIEMs
SIEM is mostly mentioned as an acronym, not its extended form of Security Information and Event Management tool. SIEMs serve an essential role in security threat detection and commonly make up a valuable part of an organization’s defense-in-depth strategy.
SIEM tools also form the basis for many regulatory auditing requirements for PCI-DSS, HIPAA, and NIST security checks, as well as aid with threat detection.
In a video recording of a session at RSA 2018, a presenter asked the audience who was happy with their current SIEM. When no hands went up, the presenter quipped that maybe the happy people were in the next room.
If I were in that room, I wouldn’t raise my hand either. On a previous contract, our SIEM tool consumed terabytes upon terabytes of space. When it came to time to pull information, the application was slow and unresponsive. Checking the logs ourselves was a more efficient use of time. So, why did we do this? Our SIEM was a compliance checkbox.
Extending SIEMs With UEBA and SOAR
SIEMs are much more than compliance checkboxes. User and Entity Behavior Analytics (UEBA) and Security Orchestration, Automation, and Response (SOAR), when bundled with SIEMs, offer additional features to extend security event management features.
UEBAs look for normal and abnormal behavior for both users and entities to improve visibility across an organization. By using advanced policies and machine learning, UEBAs improve visibility to help protect against insider threats. However, like SIEMs, UEBAs may require fine-tuning to weed out the false positives.
SOARs, on the other hand, are designed to automate and respond to low-level security events or threats. SOARs can provide similar functionality to an Intrusion Detection System (IDS) or Intrusion Prevent System (IPS), without the manual intervention.
At the end of the day, SIEMs, SOARs, UEBAs, and other security tools can be challenging to configure and manage. It makes sense for organizations to begin outsourcing part of this responsibility. Also, you could argue that applications reliant on machine learning belong in cloud-like environments, where you could build large data lakes for additional analytics.
In traditional SIEMs, feeding in more information probably won’t result in a better experience. Without dedicated security analysts to fine-tune the data collected, many organizations struggle with unwieldy SIEMs. While it’s easy to blame the tool, in many cases, the people and processes contribute to the implementation woes.