I have come across many prospects over the last 15 years that are only trying to acquire a SIEM solution to satisfy a compliance requirement, or what we call in the industry, “check-box purchasing” – they have a minimum set of requirements specific to only one business unit or compliance mandate that is completely siloed from the rest of the organization.
Here is how this conversation usually goes:
Client: “we would like a SIEM tool that will help us monitor our 200+ Windows Servers for PCI-DSS compliance”
Me: “What other event sources are you going to be monitoring with the solution?”
Client: (Stunned look) “we only need to monitor our servers.”
Me: “PCI-DSS requirement 10 states you have to monitor the logs from all of your security devices and servers that are deemed critical assets.”
Client: “our department is only responsible for the servers we listed.”
Me: “To get value out of a SIEM solution and monitor all 12 PCI requirements you need audit logs from all of your devices and contextual information regarding your network, asset and vulnerability data – and that will just get you started.”
Client: “Perhaps we need to increase the scope – we’ll get back to you.”
While the Centralized Log Management (CLM) and Security Information and Event Management (SIEM) vendors will be lined up around the block to influence the sale, the vendor you choose should be a trusted advisor. They will be interested in providing you the most value from your investment and assist you in designing a solution to satisfy many business problems that goes beyond a traditional security-centric SIEM. This is why you will need to identify key device types and the value that can be derived by cross correlating the log data with business context to align monitoring with your governance, security and compliance initiatives.
The SIEM Value Derived from Heterogeneous Device Logging
While each of the event sources you collect events from will provide distinct reporting and alerting value, combining many different “types” of event sources will derive immediate intelligence about the business and help analysts establish baselines of threat activity. One of the other benefits is that incidents can be prioritized by business value, threat classification and the additional context can help reduce the plethora of false-positives or false-negatives that plagues every CLM solution.
Additionally, the multitude of the various technologies have their own management and reporting solutions that become “silos of information” that only the black-belts responsible for each of the device types are able to decipher. This makes security intelligence and investigations near impossible when an analyst has to request log data from the owners or log in to many different systems to find the evidence to support their cause. Essentially, they would have to piece together the clues and manually normalize the data using a technique called “Spreadsheet Kung Fu”, which would be fraught with assumptions and inference.
Below is a list of different device types and the value that can be derived from each when correlated together. The list isn’t exhaustive and I’m not suggesting you need everyone mentioned to successfully deploy a SIEM, but the more data feeds you can correlate, the more intelligence you will have available in the future to expand and grow with your business (click “more…” for complete article):
In a not-too-distant past I worked for a large telco company, first as a network firewall administrator and eventually made my way into the security team as a network security specialist, responsible for developing and auditing the network security standards. While I wrote many network-related standards and best-practices documents, the following was definitely one of my favorites (or favourites here in Canada, eh!). I had to convert and sanitize the content and while it is very lengthy (and not suitable for a blog), I figured I give it a shot at posting to my site. Please note, we had a mix of Check Point and Cisco PIX firewalls when this document was first authored. The newer, Next-Gen Firewalls (or Application Firewalls – layer 7) may conflict with the following rule order.
A special thanks to Yuri Kopylovski who prodded me, moderated and, otherwise, helped me co-author this guide and to the many folks at www.anti-online.com who benefited from the content over the years. This was originally published in 2007 under my alias “aciscorouter” and has since been edited to include suggestions from the Anti-Online community.
You will note that the rule order is identified in the first column I provide with the samples under all descriptions (i.e. the very first rule is a drop rule against the firewall and the very last should be a “clean-up” rule). However, this is a best-practice – order your rules any way you see fit (…and report back to me and let me know how that works for you)!