How To Manage Vulnerabilities

Vulnerability management is the practice of finding, indexing, analyzing and remediating weakness in systems to improve their security. In traditional enterprise environments, this is achieved by scanning endpoints with software like Tenable Nessus or Qualys.

Scanning can take many forms, most commonly a range of IP addresses or hostnames are feed into the vulnerability management tool and scanned at intervals then the results from these scans are compared against a database of known vulnerable configurations, if the results of a scan match, a vulnerability is added to the reports and operators are made aware.

On the surface this sounds like a simple undertaking however in most cases, it isn't. There are common issues in vulnerability management practices across the industry, in this post I hope to highlight some of them and explain how to avoid them.

Credentials

During early implementation its common for administrators not to use privileged credentials for scanning through fear of breaking things or losing control of privileged credentials. Not using privileged credentials, such as an administrator account in a windows environment, leads to scan data being fallible because the vulnerability tool cannot access the information inside a target system that it needs. This problem may be easier to explain with a real-world analogy;

A shopkeeper hires an external auditor to count stock out of hours, the shopkeepers only condition is the auditor has to conduct his counting by looking through the window of the store, they cannot come inside. The auditor arrives at the store, counts the stock by looking through the window then makes an estimation on the volume of stock that is out of sight. In this scenario, through no fault of their own, the data the auditor provides is unreliable.

Preferably the auditor would have a key to the store so they could go inside and take accurate measures of the stock. This data would be preferable because it would be dramatically more accurate.

By giving our vulnerability management platform privileged credentials we are allowing it to take accurate readings from our systems instead of just looking through the window. As a technical example, an uncredentialed/non-privileged scan may detect an open port but it most likely won't show a critical, exploitable flash player vulnerability inside the target system. The flash player vulnerability is a more desirable find, a great case for credentialed scanning.

Now that we have a good understanding of why we need credentials, we need to get them, again not always as easy as it sounds. Handling privileged credentials comes with obvious risks which will make any administrator hesitate, and rightly so. Losing control of a privileged account is a great risk with devastating side effects.
Such risks are mitigatable and hesitations comforted with careful planning and technically informed decisions around the credentials. Most vulnerability analysts will leap to the easiest solution by asking for a Domain Admin account for use in scanning, without doubt, the administrators and senior management will scowl.

Instead of looking for broad access across the network try to be particular with your privileges. Looking to scan workstations? Set up a service account that is only administrator on workstations. Hoping to scan servers? Request a service account which has privileges on those servers. This way, if one of your service accounts is compromised its scope for abuse is reduced to just those servers and not the whole domain as would be the case when using domain admin privileges.

It is of course also important to practice good password hygiene when handling privileged accounts. Be sure to store passwords in a safe place like a password vault or key management server and regularly review access. Make your service account passwords long, complex and if possible regularly rotate them automatically to further reduce the risk of abuse.

The final hurdle when obtaining scanning credentials is convincing cagey administrators to hand over the keys to their kingdom. It is common for administrators to be reluctant especially in the early days of a new vulnerability management program. This can normally be overcome with level headed technical discussion, real world evidence and an understanding that the risk of a vulnerability going unnoticed and being exploited outweighs the much smaller risk of credentials being stolen and used against you.

If your organization really won't give you credentials there is another option, all is not lost. Some vulnerability management software offers local scanning capabilities known as Agent Scanning. Agents are high privileged services that run locally instead of over the network. Agent scans are often less resource-intensive, faster and do not require all the fuss of juggling credentials. There is, of course, the matter of maintaining yet another agent on your endpoints.

Summary:

• Credentialed scanning is critical to an effective vulnerability management program.
• Scanning without credentials is inefficient and not painting a full picture of your vulnerability landscape.
• Credentialed scanning does not need to be access all all areas, it's better to grant narrow administrative access to particular groups of systems on a per-account basis.
• If credentials are unobtainable or a machine is remote, local agents can be used instead.

Scanning

Our newly acquired credentials are useless without a scan to use them in. Vulnerability management software will allow you to configure scans with a wide range of options; Duration, plug-ins, ports, time outs, brute forces, safe checks, the list goes on. It is outside the scope of this document to advise extensively on the various configurations available across vulnerability management software because there is drastic variation between each vendor. It's generally advisable not to tinker with default settings at all unless advised by somebody trained in the particular product you are using. In some cases, tweaking scan configurations can cause more problems than the perceived benefits of doing so in the first place. You may alter a scan setting which quietly ruins the next scheduled scan, it is often too late once the mistake is realized upon review of the scan results.

In an ideal world, you should aim to scan your user endpoints weekly, this frequency is above and beyond what most regulators believe to be necessary but user-facing software becomes vulnerable very quickly. Chrome, Firefox, Flash and Reader patches are released on what seems to be a weekly basis, you want to stay up to date with these fluctuations in vulnerabilities to keep your user endpoints up to date because those are the machines most likely to be attacked via phishing or browser interaction. People are the weak point. More static and locked down systems can comfortably be scanned less frequently, once or preferably twice a month is acceptable if you're doing things properly. Painting a clear picture of the vulnerability landscape around you is key, the more frequent you scan the clearer the picture becomes.

Painting this picture won't be easy to start with because probing an entire network for vulnerabilities is going to cause ripples in your IT organization. Weather alerting the security team or knocking over some sensitive system, there will be casualties as you learn to adapt your scan configuration for your environment. It's important to keep a cool head and take in your stride that in the beginning, the platform will cause issues, you should be open to working with the people coming to you with complaints and not against them.

Causing a beloved system to go offline is frustrating for the owner, work closely with them to either resolve the conflicts or if nothing else exclude the system from scanning with an accepted risk signed by a company senior. In most cases the scan can be adjusted in such a way that the target system does not fall over, hopefully diplomatic minds will prevail. Beware, as mentioned earlier tweaking scan settings can have silent but deadly consequences. Take care when modifying scans, take advice from somebody qualified in your particular vulnerability management tool. If you have hired in a consultant to assist you, ask questions, there are none that are stupid.

Process

When it comes to vulnerability management (as with most IT initiatives) there should be a method to your madness. Your team should work with infrastructure and others to agree on an approach that works for everyone. You should aim to have your process and expectations defined in a simple easy to understand document. Try to squeeze the whole thing into a maximum of two pages, anything longer becomes easy to ignore and update.

Vulnerability management relies heavily on organization, repetition and process, writing easily understood documentation makes all of these things easier for everyone and as an added bonus documenting your process means you have a handy policy paper you can hand to auditors when asked; What are we doing about vulnerabilities?

In an ideal world your process document should illuminate at least the following topics clearly:

• Target time to remediate - A time window in days that your organization will endeavor to fix vulnerabilities within. A good rule of thumb is within 30 days for exploitables, the sooner the better.
  
• What is done when  - A guide for the scanning and patching cycle frequency.
  
• Who does what - Names of the the people who are responsible for the program, key stakeholders for example.
  
• Change Process - What the business expects for change requests to authorize patching. Can the security analyst apply updates whenever they like or must they let the patches bed in on a test environment first?

Last but not least try not to vilify anyone at any point during your vulnerability management program. Sometimes human error will prevail and a scan will splutter, this could lead to a vulnerability not being patched within your agreed timeframe. It's important not to scold people for simple human error mistakes which should be made impossible by a proper, robust process. There should be no room for ambiguity, each m0ving piece of the puzzle should know what they are doing and when.

All things considered a good, well oiled vulnerability management platform should bring comfort to the security team, not stress. Try to make the whole thing simple, repeatable and enjoy the fruits of your labor in the form of a less vulnerable environment.

Thank you for taking the time to read this post, if you disagree with my thought process or in someway find this advice incorrect id be interested in hearing from you @secprentice and will endeavor to update the article accordingly.