This content is part of the Essential Guide: How to define SIEM strategy, management and success in the enterprise

Five tips to improve a threat and vulnerability management program

Utilize these five simple tips from expert Diana Kelley to improve your enterprise's threat and vulnerability management program.

Modern enterprise cybersecurity teams must be prepared to deal with a barrage of new and rapidly evolving threats....

From script kiddies to sophisticated hackers working for criminal organizations, if an enterprise doesn't have plans in place to deal with such threats, it will pay the price in expensive, embarrassing data breaches.

An effective threat management program is undoubtedly a vital ingredient for any enterprise security team dealing with the modern threat landscape, but keeping such a program running smoothly takes time and ongoing planning. Resources must be allocated to put a program in place that can deal with a multitude of attacks.

In this tip, we will offer five best practices that companies can implement to increase the effectiveness of their threat and vulnerability management program.

No. 1: Manage alerts

If a tree falls in the woods and no one is there to hear it, does it make a sound? This old philosophical question comes to mind when thinking about threat management. Like that tree, are alerts about suspicious activity and anomalous behavior that can signal an attack in progress that an administrator doesn't see or review really alerts? The most important thing a company can do to get a handle on threat management is to ensure that someone is there to review and respond to an alert that's been triggered. To meet this requirement, most organizations should assign a dedicated resource, or resources, with the remit to review log and alert consoles on a daily basis.

At the daily alert review level, it's not uncommon to see organizations assign different specialists to review different alert consoles. For example, a firewall operations expert may be in charge with reviewing firewall rule changes and alert logs, while an applications engineer may be responsible for reviewing the logs and alerts from the Web application firewalls and Web app scanners.

No. 2: Take a holistic view

In the realm of detection evasion, attackers are growing increasingly sophisticated, as can be seen with their use of multi-channel attacks and other techniques that are designed to fly below security radars. An example of a multichannel attack is the seemingly innocuous spear SMSish (SMS phish to a smartphone), which fools the user into clicking on a link that leads to a rogue site that has been designed to look legitimate. The user may then be tricked into entering sensitive data or clicking on a link that infects the targeted machine with a bot. Once the user's sensitive information has been collected, the attacker attempts to log in to a system and dig deeper into the corporate network for more valuable information.

Most organizations already monitor for threats and suspicious activity on most devices, including wired desktops, wireless tablets, smart devices, laptops, Web applications, databases and servers. To catch multichannel attackers, organizations should corral alerts from all of those systems into a single console where correlation rules can filter the seemingly innocuous activity that, when combined, creates a single, organized attack.

No. 3: Reduce false positives

Excessive alerts and false positives ratchet up the "noise" ratio so high that it can be difficult (if not impossible) to sift through all the available data to find the truly malicious events. If an organization's administrators can't discern important alert signals through all the less insignificant events, the alert system becomes useless. To reduce the number of false positives produced, an enterprise should first analyze the alert output of its threat-warning console, or consoles, and determine if the rules can be tuned to reduce the false positive noise, or filter alerts by level of confidence so that admins can see which ones are more likely to be relevant.

One way to lower those levels without losing critical alerts is to set threshold levels that match normal activity on the network. For example, a company that forces all users to change passwords on the same 90-day cycle might find that failed logins increase significantly on the day after the end of a cycle. To account for this occurrence, a rule that normally signals an alert after three failed logins could be increased to five failed logins on days following the password change. The logins could also be linked to other threat indicators, such as attempts to log in using the same ID from different IP addresses, to increase accuracy.

Keep in mind that over-tuning or setting thresholds too low will result in false negatives, so test thresholds carefully before implementation.

No. 4: Integrate with the SOC

As mentioned above, aggregating threat information into a single console gives organizations threat visibility across the whole enterprise. To gain even deeper visibility, a company can integrate that single-console(or multiconsole) view with its security operations center (SOC). At most companies, the SOC's main purpose is to monitor security activity and respond to attacks quickly, which makes integrating the threat management program with the SOC something of a no-brainer.

To integrate threat information with the SOC, filter alert information into a SIEM system and log data into either the SIEM or whatever is being used for log centralization. Next, create rules in the SIEM, log aggregation tool, or both to parse through alert information and flag legitimate attack activity for further investigation or response. To integrate effectively, make sure that engineers and administrators in the SOC have access to the standard operating procedures for incident response, so that the team knows the correct escalation paths, communication protocols and approved response activities.

No. 5: Validate remediation activities

In the heated atmosphere of an incident response, organizations can easily overlook validating the remediation activities. Even during routine activities like patch management, many companies fail to close the remediation loop with validation. Did the patch get loaded properly? Did it close the intended vulnerability? Without testing, an organization can't be certain that the remediation was successful and the threat exposure was closed.

Complete the threat management cycle with steps for validation. These can include rescanning systems to validate patches and performing application and network Penetration testing to confirm that fixes or controls are blocking vulnerabilities as expected.


The modern threat landscape is complex and attacks come in from multiple channels and sources. Organizations need to have a multichannel approach to managing and responding to threat activity. Rolling up activity data into the SIEM, or other management console, and having trained professionals review the alert data will increase situational awareness and improve response time and efficacy. And when patches or controls are in place for remediation, don't forget to validate that they are installed and working. Stopping all attack activity is impossible, but by taking steps to improve a threat and vulnerability management program, businesses can avoid a incident becoming catastrophic.

From the editors: More on threat and vulnerability management

About the author:
Diana Kelley is a partner with Amherst, N.H.-based consulting firm SecurityCurve. She formerly served as vice president and service director with research firm Burton Group. She has extensive experience creating secure network architectures and business solutions for large corporations and delivering strategic, competitive knowledge to security software vendors.

This was last published in October 2012

Dig Deeper on SIEM, log management and big data security analytics