For years I’ve worked with commercial security products and services and worked to incorporate them into a cohesive security program to provide my company with effective protection. This has proven challenging since the operation of these tools was always obscured to me. Setting up open source tools in lab provided transparency and control that I didn’t have with the commercial products we used on the production network.
Let me use IDS as an example, I’ve used both commercial tools and managed services for intrusion detection and prevention. In both cases I receive alerts for activity that is indicated to be an attack. In both cases there is no detail information about the alleged attack. I have to place some level of trust in the vendor that the rule that fired the alert was accurate. This on the surface it would seem obvious the rules would be accurate with the occasional false positive.
When I’m able to see these rules, the first step in responding to an alert is to review the rule and determine the likelihood that the rule is an accurate finding. From that point I’m able to prioritize how much effort and how quickly I investigate the event. If the rule is poorly written or overly general I remove the rule from my ruleset. If the rule is well written and unlikely to be a false positive I can increase the priority and pursue the investigation. If I’m unable to evaluate the rule directly I am left guessing at a priority to investigate the event and I’m only able to validate the rule through a lengthy investigation of the event. With hundreds of events being reported daily it’s impossible to investigate each of them to resolution.
Approaching this task with a long view plan, you can save the output of each investigation and learn what alerts are valid and which are overly general. Since there are often thousands of rules in the rulesets of these products and the vendor is adding to them constantly the task of tracking which rules provide accurate results and which do not is nearly impossible, even if the tool provides an ability to document your evaluation of the rule. When these tools or services are provided by a third party the rule sets are considered proprietary and integral to the value of the company. In all cases it’s been difficult for me to get the detail of the rule from the vendor in some it’s been impossible.
This complaint applies across almost all products in the information security realm, currently the vast majority of these are signature based reactive tools. Anti-Virus (AV), Intrusion Detection / Prevention Systems (ID/PSs), Security Information and Event Managers (SEMs), and Vulnerability Assessment Scanners (VA Scanners). Responding to the indications from these products requires a depth of experience in both information security and operations that isn’t found often. The volume of alerts from these products and the scarcity of the people able to respond appropriately to them creates a challenging situation for any team.
Open source tools have both open code that can be freely modified by anyone and they also have an open ruleset that can be trimmed or expanded by the user. These freedoms offer the chance to tune the rulesets to produce valuable output. It still requires a significant effort but the effort produces permanent value immediately. The savings on purchase price will be offset by the cost of experienced people and time required to implement the solutions. It’s truly a situation where people make all the difference.