Many if not most organizations are already operating at a capacity to sustain the existing work without taking on significant amounts of new work. Since a vulnerability scanning program has the potential to add quite a bit more effort, not only for your security staff but also for operations staff, this makes it fairly important to ask the right questions before you commit.
Some questions you may want to consider:
1. Why do I need to scan my assets?
This is probably the most obvious of the questions on the surface. Once you explore it, it becomes less obvious and more complex. For example, it may be simple to say that regulatory requirements demand this. However, what is really required, and why is it required? That will shape what kinds of scanning you do, the frequency with which you do it, and even what you do with the scan findings. So, consider whether you are doing this to audit your patch management processes, discover unknown vulnerabilities, discover asset management problems, inventory management problems, or if there is some other issue. But, have a goal in mind up front. Vulnerability scanning can do all of these things, and you will quickly find yourself overwhelmed if you don't identify your focus and prioritize what you want to get out of the exercise.
2. Do I have the resources to do this?
It might take one FTE to set up a scanner and some scans and schedule them. But, you'll also need time to tune the scan policy to remove things that you no longer care about. This includes management of environmental exceptions for different asset types and groupings, and may tie in to risk management or other documentation processes. You also need time to work with GRC staff to align scan policies with program requirements, time to analyze the scan results in order to refine scanning strategy, time to parse the results, time for coordinating remediation with systems owners-- including technical assistance if your administrators aren't well trained, and time to identify system owners (and possibly update inventory, depending on the stratification of your environment). Depending on how complex your environment is, you may have a hardware or host OS owner, an OS owner (for virtual), an application owner, multiple middleware owners, and you may have to track individual web sites, individual cluster members, registration of virtual IPs, and multiple sets of privileged credentials depending upon how you conduct your scans). And, don't forget maintenance. Updating the policy set, adding new plugins, testing new plugins, updating the scanner software, patching the host OS, troubleshooting errors and issues with the scanner all require time, too. Don't plan on an individual. Plan on a team, and don't rely on cross-training to give you the redundancy you need to keep stable.
3. Do I have the buy-in to do this?
Vulnerability identification, by its nature, involves telling someone that his/her baby is ugly. And remediation efforts, by their nature, involve more work from somebody. Tweaking the patch management solution, marshaling resources to create a standard build image, updating the inventory management system, applying missing patches, or changing configurations are all likely products of the vulnerability management process. There will be resistance to doing all of these things if the right buy-in isn't obtained from all the stakeholders well in advance of your efforts.
4. Do I have the scope of authority to do this?
Even if everyone agrees that these tasks must be done, there is likely to be disagreement about who should do them, and when they should be done. Resource limitations affect every organizational area, not only Infosec, so it will be important for you to establish responsibilities and measures of accountability for all stakeholders. Be especially careful to avoid a situation where your vulnerability management organization has all of the responsibility for ensuring that things are fixed, but none of the power to get them fixed. If this happens, operational areas with the power to fix things might place vulnerability management activities at the bottom of the priority list, and without any consequences, the program will shudder to a halt without realizing any of your goals. Accountability and priority should be established up front for all participating organizational areas.
5. Am I even ready for this?
As mentioned above, you can expect vulnerability management to have tie-ins to patch management, systems administration, inventory management, incident management, and GRC. If you don't have a strong inventory management system, you might find yourself spinning your wheels when you run your scans. How do you fix a problem with a system you don't recognize, or whose owner you can't identify? The same can be said about systems administration and patch management. If you can't handle exceptional configurations and respond to the vulnerabilities you find, you might regret your new found knowledge. So, be prepared to deal with these issues as they arise, or make sure you've done the necessary up-front planning.
No comments:
Post a Comment