Vulnerability Management…What is that?
by Andrew Brooker, CISSP @ http://www.secureconnect.com . February 9, 2010 . 3:18PM
“Maintain a Vulnerability Management Program – What in the world is that?!?” No doubt many have said that to themselves and even if the words are defined the meaning is still unclear. Interestingly enough, the concept of “managing” vulnerabilities can be an effort in herding cats.
The difficulty lies in the defective software and operating systems – we have accepted the defects to be normal and without ability to change. However, if it were a defective car or television, we would return it, call the headquarters to complain, and phone the BBB in an effort to curb future problems. Without much uproar from buyers, the software companies have no motivation to change. So here we are with the problem; keeping a handle on these vulnerabilities isn’t difficult because the landscape is changing, but instead, because more defects are being found. In most cases it is nearly the same vulnerability being exploited in a slightly different fashion or better yet, a technique used on one application, then ported to another vendor’s product. What are we to do?
Avoid. So the major payment card brands (Visa, Mastercard, Discover, JCB, and American Express) and the Security Standards Council do understand the importance of getting to the source – avoiding defects in manufacturing. A good portion of Requirement 6 (6.3, 6.4, 6.5) is about avoiding vulnerabilities by having quality (I mean secure) development. It underscores initial avoidance by ensuring systems and applications are up-to-date before going into production. And it underscores ongoing avoidance by adhering to set policies, standards, testing, and change control to preserve the environment.
Know. Vendors are reactive when it comes to vulnerability discovery and remediation. They wait for someone to bring a problem to their attention. Then they prioritize what they will create a “patch” for. Considering this is the general approach, from a security standpoint, it is too late. Staying in the loop is crucial to ensure we can stay as forward as possible in this lagging process. Enrolling in Internet weather, vendor, and industry alerts is must. Though you may find redundancy in notifications, what you derive is a better determination of risk. Understand that vendor rating systems are skewed and often don’t accurately portray the impact a vulnerability may have. Balancing the volume of patches to be applied and the downtime you need is a real challenge; having the right information to make the right decisions is required. (Requirement 6.1, 6.2)
Apply. Now you know and half the battle is won. The other half: Acting on what you know. Requirement 6.1 sets the standard at a one month cycle. Keep in mind that this is your cycle; however it is defined in your policy. The goal is to stay on top of all the critical patches and ensure they are applied quickly. In reality, this standard is not stringent enough for most organizations, as many of the recent vulnerabilities require immediate response, and one month is merely academic. Remember, we are discussing vulnerabilities, not patching; as such, we can’t forget about anti-malware (or application white-listing). With an estimated one-million new pieces of malware each year, it would be irresponsible not to have some malware mitigation in place. Not only can anti-malware assist with the “defects”, it provides the much needed protection from users. Clicking the wrong pop-up, the wrong hyper-link, or opening the wrong attachment in an email can provide a whole host of issues, you don’t want to deal with! Do the right thing; use a widely accepted anti-malware or true application white-list. Make sure it is running and the signatures/policies are up-to-date. Often, even if the mitigation software can stop or remediate the rogue software, it can serve to alert of the activity taking place allowing you to take action.
I gave the indication that this process is a battle that can be won. Maybe that is true, but it is the war that cannot. With all things security related it is about posing “best-effort”. Specifically with “managing vulnerabilities,” it is the notion of containment not control that should come to mind. Follow good practice, stay informed, and act quickly – this is the best that can be done until the root problems are addressed.
