Vulnerability Assessment Methodology
Vulnerability assessment and overall risk mitigation strategies are at the very core of any effective security program. Not only does it play a crucial role for any entity, it may also be required by various compliances such as HIPAA and PCI. Though assessments may come in many forms, we will be focusing primarily on vulnerability scanning and remediation. This article aims to educate readers on best-practices and lay the foundation for establishing their own program.
Vulnerability scanning largely comes in two forms: internal and external. The cheapest and easiest, by far, will be the external scan. With your scanner in hand (Nexpose, Qualys, Retina and Nessus are a few that come to mind), you essentially set it to scan the public IP address of your network and leave it to its own devices. Depending on how you configure the scan, it will tell you any open ports and services running on your firewall. Keep in mind that it’s usually best to perform external assessments from actually outside the network. Basically all we’re trying to do here is verify that our access rules are locked down accordingly and, for example, RDP isn’t open to the entire world. I say that specifically because it’s an unfortunately common occurrence.
Second, and most important, is our internal scan. Most organizations that take security seriously have these going in regular intervals. Our internal scan is meant to check for a number of critical items:
Missing patches and outdated software - Anything out of the ordinary here may indicate that your patch-management system isn’t working properly
Misconfigured systems - Default credentials, outdated firmware, and the like
Poorly configured GPOs - Weak password policies, access controls, etc
Organizational-specific items - These will be your web services, your home-brewed applications, and so on. These are often audited by external parties as well in gray or black box tests.
Before digging into the remediation for your scans, it’s important to go in with a mindset that security is meant to be an ongoing effort, not a one-and-done project. That said, the size of the reports resulting from these scans will generally seem overwhelming. In the SMB space, a client network of 100-200 devices could easily yield a 1,200-page remediation report for an all-audits scan. What separates an effective security team from an ineffective one will be their ability to prioritize risks and remediate based on that. Both NIST and OWASP provide the necessary methodology for doing so, and they essentially say the same thing: Determine the most likely and most impactful vulnerabilities and start there. Mission-critical devices deserve the highest-priority attention, and include things like your internet-facing security appliances, your application and file servers, and often times even the devices belonging to organizational people-of-importance. Prior to moving into the scanning process itself, it’s helpful to be familiar with the CVE database and the Common Vulnerability Scoring System.
With all of that verbiage out of the way we can move into the actual process of performing a scan. For our demonstration, I’ll be using Nessus because it’s widely used in the professional space and it takes about 5 minutes to download the trial version. Once you’re at the main dashboard, simply select New Scan. Nessus and other professional scanners come pre-loaded with a number of scan “templates” which feeds right into the first step of security auditing: Identify the scope of the project. Are we performing a regulatory scan? Are we scanning for outdated software? Are we looking for a particular vulnerability? Or maybe we just want to do a full scan of our entire network to establish a baseline. This decision will largely be up to you given your specific scenario but, for our demonstration, I’ll be doing a basic network scan.
As with any scanner, we’ll have a number of customizable options prior to launching the scan:
Flipping through the options, there are a number of noteworthy settings worth mentioning.
Always, always, always configure your scans to authenticate with credentials. Scans configured without these will only be able to report a fraction of the story
For the sake of organization, it helps to give a name and possibly a description of your scan, depending on how many and how often you are performing them
Select your targets. This can be individual addresses or entire subnets. Depending on your scanner, you should be able to configure or upload address groups to make this process easier. Also, are there any addresses you want to avoid scanning? These applications will attempt to log into every machine with whatever set of credentials you give it. For miscellaneous network devices like switches and battery backups that may not necessarily follow the credential format of domain\username, you may be setting off a ton of IDS alarms for someone else to deal with. It’s best to coordinate these with members of those respective teams
What ports do you want to scan? Common ports may be faster, but hitting all ports will build a better picture
If it’s not already defaulted, make sure you allow the use of CVSS scoring. This will help you prioritize remediation
There will be a ton of other bells and whistles for you to play with based on the vendor you use, and those are largely for you to choose from based on your use case. For our simple demonstration, I’d say this is ready to go. Our second step in vulnerability assessment is simply conduct the assessment.
Now, one thing that can be said about all scanners is that they take a long time to do their job. They’re referencing databases containing thousands upon thousands of vulnerabilities so, if you plan on assessing hundreds of devices, it’s best to proactively run the scan a day or two before you need the report. Once the report is in hand, step three is to communicate the results with the appropriate team members and team leaders.
Depending on the report you have the scanner spit out, you’ll essentially see a colorful, picture friendly vulnerability summary of your network. Most scanners categorize vulnerabilities as high, medium, low and other, or some variation of that:
“Critical” vulnerabilities are generally the ones that are highly exploited in the wild. That being said, this does not mean that your informational alerts should go unattended. You should be able to select a single host and drill further into the possible vulnerabilities affecting it:
A quality scanner will even offer recommendations for remediation:
The bottom line of vulnerability assessment is to slowly reduce the number of items requiring some form of remedial action. As stated previously, this is meant to be an ongoing effort so, if your team is experiencing a regular decline in vulnerabilities, you’re doing something right. A portion of this process, however, is accepting risk. In rare scenarios it may be decided to leave a host unprotected or unmaintained. There’s an actual formula for doing so but basically, if the cost for protecting something outweighs it’s worth to your organization, or if a particular machine is due to be replaced, sometimes we can let these things slide. Once the remediation project is handled, we move on to our fourth and final stage: Maintain assessment and learn from your mistakes. As security professionals, it’s our job to ensure all of our bases are covered and our team members are able to conduct business in a safe environment. Failing to stay proactive and better ourselves professionally will render our efforts useless.
