A SIEM-security information and event management, or conversely security incident and event management, or security incident and event manager--is a powerful set of tools that, among other things, collects logs and aggregates and correlates those logs in a way that security managers can actually use. As Keren explains it (in a brief report we'll be publishing soon): "The correlation engine (using correlation rules or filters) takes different logs from different sensors and merges them together into one event. Furthermore, it uses information from the knowledge base and decides if this is an incident or just an event." By "knowledge base" he means the SIEM's information on log sources, the criticality of each system, a list of attacks and their severity-info the SIEM will use to determine how to define and respond to each incident.
Tehila's main tasks are to host government ministries' public-facing Web sites and Web services and to serve as ISP for government ministries (which is where the big challenges come in). The security team had first tried implementing a SIEM on Tehila six years ago, but Keren dubs the project a failure, and he shut it down about a year-and-a-half ago.
"We did it poorly," he confessed. "Poor planning. Poor management."
Part of the trouble, according to Keren, was inadequate coordination between the security team and other concerned parties. This lack of coordination actually caused Keren to leave out one segment when soliciting bids from vendors. Further, once they'd contracted a vendor, they didn't pay enough attention to what precisely the vendors were doing.
Now the Tehila security team is in the midst of a second go with a new operational design. One of the first building blocks is to learn exactly what your organization needs and expects from the SIEM; and Keren recommends you don't outsource this "theory phase." "You could hire a consultant," said Keren, "but they have an agenda. Any contractor or vendor always has their own agenda.
"For the theory phase you don't need to know a lot about SIEM," he added. "You just need some basic knowledge of SIEM. The more important thing is to really understand your organization's needs."
Further, once you've completed the theory phase and actually gotten a vendor working on the implementation, Keren advises you keep a close eye on their work, get your hands a little dirty and make sure the project suits your requirements.
Tehila's requirements border on massive. Keren says that about 60,000 government users use the ISP and approximately 10 million unique users use the ASP, and that Tehila is the target of huge numbers of attacks--thus the security team logs everything.
"We have a lot of logs," Keren said. "About 2-3G per hour." Hence, the need for a rich SIEM to make those logs intelligible and effective.
One place that the SIEM's available offerings falls short, Keren said, is in the task of finding Trojans--there was no distinct control available to specifically identify what's a Trojan and what isn't. So another, quite important, quite innovative segment of Tehila's SIEM project is the creation of a Trojan analysis system, which will apply 15 tests to the SIEM's information in order to sniff out the Trojans amidst so much data.
Keren said that the Israeli e-government's SIEM may not exactly work for an enterprise environment-which is why the all-encompassing theory phase is so important.
"The SIEM is the heart of your security system," he said. "If the SIEM goes wrong, the security is wrong."
In the July issue of the Alert (CSI members only), we'll be publishing Keren's complete run-down of the project, "Searching for the Needle: Insights from Implementing a Security Information and Event Management Center in the Israeli E-Government Project."