Closing the Loop: SIEM Integration into SOAR Toolkits
SIEM tools are often seen as feeding into human security operations centers, generating reports or alerts to be handled by humans. While SIEM tools have always had some ability to automatically tweak infrastructure based on alerts, many higher ed IT teams justifiably didn’t trust SIEM products to actually touch things without humans approving changes. SIEM products have advanced considerably and can now be important and trusted parts of automated network operations.
These more advanced capabilities feed directly into security orchestration, automation and response (SOAR) toolkits being embraced by higher ed IT teams in order to reduce human error and speed deployment of changes across their networks. SIEM has the ability to become a valuable input to SOAR, letting complex campus networks respond immediately to security attacks before they can spread.
SIEM products can reach out and touch firewalls and routers, inserting blocks in real time for attackers coming from the internet or moving laterally across a campus network. SIEM tools also can feed directly into endpoint security tools, such as desktop anti-malware, delivering faster protection when a new attack is detected. More important for hesitant higher ed teams, SIEM vendors now have decades of experience with these tools and are finally able to deliver security value and faster-than-human responses without putting day-to-day operations at risk.
LEARN MORE: How to demystify security automation for university IT teams.
More Data Sources Mean Smarter Rules for SIEM in Higher Ed
SIEM products often specialize in one part of a network’s security infrastructure. This could be log entries from servers, for example, but not logs from firewalls, or vice versa. During the early days of SIEM deployment, IT teams would use these specializations along with default rule sets delivered with the SIEM tools to help filter and prioritize events.
SIEM tools are shifting into a more whole-network model, accepting greater varieties of data feeds, and are delivering more intelligent rule sets correlating diverse types of device events. This shift is driven by a new interest in zero-trust networking, which focuses on user authentication and more contextual information. Some SIEM products call this capability user and entity behavior analytics as a way of highlighting their more advanced rule sets.
Higher ed IT teams may have reservations about UEBA; after all, it’s actually plausible that a professor is legitimately trying to connect from North Korea and shouldn’t be blocked. But the value of integrating additional data sources will pay off even if not all UEBA rules apply for higher education. SIEM vendors including Splunk and Microsoft Azure Sentinel are adding internal data sources such as identity and access management logs and posture checking from VPN and endpoint security gateways. They are also pulling external threat feed information and using it to make decisions on how to react to internal events. While there will always be false positives, higher ed IT teams can leverage this improved threat intelligence when integrating SIEM with their security operations workflows, whether automated or manual.
DISCOVER: Here are four things to know about passwordless authentication.
SIEM Cloud Integration in Higher Ed: Finally, or Only Sort Of?
With more colleges and universities embracing a hybrid cloud model, properly integrating cloud data sources into SIEM has been a priority for higher ed IT teams since the first service moved off campus. Some of the delay has been due to cloud services vendors who hadn’t figured out how to share log information with their tenants, but all major Software as a Service and Infrastructure as a Service vendors are now ready to deliver some types of events to customer SIEM systems, whether on-premises or in the cloud.
The flip side, of course, is that the SIEM tools must be ready to consume this data, and the data has to be useful. For SaaS-type services, it’s easy to assume that application-layer data isn’t that different from other on-campus services. However, the complexities of large SaaS deployments and multitenancy make it difficult to deliver the same information as on-campus services. For example, heavy use of load balancers and reverse proxies makes IP address information almost useless, doubly so when the users are themselves behind a campus or home address translator. This means that SIEM products need to use other tools, such as user identification rather than IP, to try to correlate events.
The result is that while the cloud-based event logs are available, higher ed IT teams may have to start from scratch to make sense of these logs, rather than simply feed them into existing rules.
