Vulnerability Assessment Process

Let’s make a high level overview of the best practices of vulnerability assessment process implementation in an organisation. From Wikipedia: ”A vulnerability assessment is the process of identifying, quantifying, and prioritizing (or ranking) the vulnerabilities in a system.” How do the most organisations implement this process? The common approach is to implement the vulnerability scanning solution. There are a large number of vendors on the market who provide comprehensive vulnerability scanning solutions.

Most of the scanners can be divided in to two categories:

Web application scanners, like Acunetix, WebInspect, NetSparker;
Network and infrastructure scanners like Nessus, Metasploit (yes, it is not just an exploitation tool – the auxiliary modules can help you to perform the vulnerability scan as well), Qualys. These scanners can perform web application assessment as well, but their features are limited.

The process usually is very straightforward: define the scope of the vulnerability assessment, get the permission for the audit, run the scan, analyse the results, fix the issues. However, every step brings a lot of challenges that require particular skills and knowledge from the analyst to make this process effective. This article won’t cover the end-to-end vulnerability process, but will focus more on analysing the results, discovering issues, prioritising them and make proper recommendations to remediate them.

Get the right skills

First of all, let’s try to understand who should be involved in analysing results. The correct answer is: various teams and departments should be involved in this process.

Security professional. Since the report contains technical security issues and describes the most common hacking techniques to exploit the issues, a skilled security professional should be involved. The security analyst should have appropriate skills, knowledge and experience to understand the issues, assess a business impact and provide appropriate recommendations to fix them. Ideally the analyst should have some sort of recognised security certification and background to help them in this process. Examples of technical certifications are GWAPT, GPEN, OSCP etc. In addition they should have excellent communication skills to explain the issues to other teams.
Network or System administrator. If the report contains results for network or operating system vulnerability scan, the results should be discussed with the IT operational department to verify them and eliminate false positives. It is necessary to consult with the IT operations team as they have knowledge of the internal systems and can provide valuable feedback for the risk assessment process. However, it should be considered that administrators tend to lower those risks as they will be responsible for fixing the issues and most of the time they don’t want the auditors to discover any high risk items. Separation of duties should be enforced.
Web developers. This team will be quite useful during web application analysis. Have a chat with them before starting the scan to understand an application’s functionality and technologies to make sure you don’t miss any critical requirements during the vulnerability scan. Sometimes companies use external vendors to create web apps, so make sure you receive all the relevant documentation and APIs (for web services) beforehand. After getting results, send them to the vendor for a validation and feedback.
Senior management. It is absolutely critical to have senior management support and deliver the results to them, as they will be responsible for allocating a budget to fix the issues. Senior managers usually don’t have technical background, which is why vulnerabilities should be explained in non-technical terms and as simple as possible. The vulnerability scanners can produce an executive summary section with nice graphics, numbers and tables, but it is usually more effective just to have a 5 minute face-to-face chat and explain them what the risks are. Use such terms as “compliance”, “risks”, “brand damage”, “privacy concerns”, “penalties” etc.
Legal and regulatory. If a scope includes any systems which hold customer or employees personal data, have your legal or regulatory department review the issues. The privacy laws are very strict in countries like UK, Australia, US, EU etc. and any breach of personal data can cause severe penalties for an organisation. In addition, if the scope includes systems that process credit card information, that organisation should be PCI DSS compliant.

First look at the report

You have just received a report from the vulnerability scanning solution. What are the first things you need to look at?

Scope. Make sure all the necessary URLs and IP addresses were covered in the report. A few things can go wrong. For example, when performing a web application scan the crawler doesn’t always discover all of the content on the web site. Admin pages, subdirectories, subsites might not be discovered because there is no direct link from the main site. If this happens make sure you manually add required URLs and rescan again. For network assessment, double check IP addresses. Sometime firewalls block whole subnets so that scanners can’t communicate with targeted computers. Host based firewalls can also block traffic.
Scanning errors. When analysing the report, you might see that ports were open during the initial scan, but after a few minutes they’ve been closed. This might indicate that a IPS or WAF firewall is in place and blocks the analyst’s IP address. Vulnerability scanners usually produce an error saying they can’t connect to the target anymore and require input from an analyst.
Plugins / signature version. It is always recommended to use the latest plugins during the scanning. If plugins are more than one or two weeks old, critical vulnerabilities might be missed. New vulnerabilities are discovered every day and vendors do a great job to update the signatures within reasonable timeframes.
Date and time. If analysing a report performed by a third party company or even by developers/network admin/test team, the date of the report is critical When scanning preproduction environments, the version should be close to the final production version to make sure there were no modifications to the code or environment after the scan. If the report is old, you might want to retest findings or cover new functionality that was developed after the scan.

Common high risk issues

Suppose you are analysing the network or infrastructure vulnerability scanning report. What issues should be looked at with high priority?

Missing security patches. It is very common to see that servers, workstations, database servers, web servers are missing critical security patches. Even today when most companies have established patch management process, it is not unusual to see, for example, legacy / dev / test Windows servers with missing MS08-067 security patch. Why this patch is important? This patch fixes the vulnerability which is widely exploitable by Conficker worm, which caused a lot of problems back in 2008. The Metasploit framework has a working exploit for this vulnerability as well, which allows a remote attacker to gain full control over the server. Make sure you subscribe to Microsoft patch alerts and also for the security RSS feed to be aware which vulnerabilities have exploits in the wild.

Top 10 products with the most reported vulnerabilities. Report by Qualys.png

Default or easy passwords. These are probably the most dangerous and the most common security issues. How many of your Cisco routers have a default password “cisco”? How many Microsoft SQL servers have empty password for the SA account? If you find these issues on your network, you probably have some serious gaps in your security processes. The examples above are probably easy to fix or discover. It is more difficult to fix - for example, Tomcat or Jboss servers with default accounts. During the installation process, Tomcat doesn’t offer the administrators to change the default password and installs itself with username “tomcat” and password “tomcat”. Knowing these credentials, it is possible for a potential hacker to change the configuration of the web server or even deploy new applications, which usually provides full access to a server.
Insecure services or protocols. FTP, Telnet, HTTP protocols are still widely used. All these protocols transmit credentials in cleat text. Hackers can sniff a network, intercept traffic or perform Man-in-the-Middle attacks and gain unauthorised access to information. Telnet usually provides command line access to the target device, so integrity or availability of information can be affected. Anonymous FTP servers can provide “write” access to the server, so hackers can store prohibited materials on them, such as cracked software, pirated movies etc.

Web application vulnerability scanning reports usually contain following issues:

SQL injection and XSS vulnerabilities. These vulnerabilities happen because developers don’t validate input or output parameters properly. SQL injection vulnerability allows external attackers to put malicious SQL commands into URL parameters and manipulate backend databases: create, modify, delete the tables, grab users’ passwords, and upload malware on the server. XSS (Cross site scripting) issues allow hackers to attack customers, which affects the company’s reputation and damages the brand. These issues should be fixed as soon as possible.
Encryption issues. SSL v2 currently is considered insecure and was supervised by SSL v3 back in 1996. However, a large number of web sites still support it. Recommendation? Disable it! All browsers releases after 1997 support SSL v3 so there shouldn’t be compatibility issues. If a user connects to a web sites (eCommerce, banking application etc.) usingSSL v2, hackers sniffing the traffic have a very good chance to decrypt it and get access to credentials. In addition, if you are running online shop and process credit card details, having SSL v2 enabled on your web site means failing PCI DSS compliance.
Click jacking and Cross-frame scripting. This is very debatable topic and there are a lot of articles and talks about this at the time of writing this article. Should we rank this vulnerability as high critical or informational? Burp Suite reports XSF issues as informational (not even low), Acunetix and Netsparker don’t even report on them. HP WebInspect will raise this as a high risk issue which should be fixed as soon as possible. Let’s understand the impact of this issue: XSF allows potential hackers to put a web site inside a frame and force users to perform transactions they probably don’t want. For example, a user might see a web site saying “Click here to win an iPad”, but in reality when a user clicks the button, they will make a bank transfer to the hacker’s account. So if you run a highly sensitive application, you should definitely fix this issue. In case you are running a marketing web site without any user interaction, you might ignore them.

*Burp suite reporting potential Clickjacking attack*

False positives

All reports (remember, ALL reports) contain false positives. Even if a vendor of the vulnerability scanner tells that their product doesn’t produce false positives, it is not exactly correct. Indeed vulnerability may be on the web site, but the severity should be always questioned. All the web sites are different depending on the business requirement and no security product has a signature database that fits them all. Some common false positives are listed below:

Outdated software. Most vulnerability scanners determine a software version based on a banner it presents. For example, when you connect to the Apache web server, headers or error messages usually tell you which version of software is used. Can you trust this information? No. Administrators can easily change a version number to trick the potential attackers. They can increase the version number to make an impression that they are running the latest version of the software. Or they may even want to decrease the version to create a honeypot, so that hackers spend their time attacking less valuable asset. Sometimes updates don’t increase the version number: for example, if you are running Apache on Red Hat, security patches won’t affect the version.
Brute force attacks. It is very usual to see the vulnerability scanners reporting that a web application is vulnerable to brute force attack. How do they check it? They try the same credentials several times, usually five or ten times, and analyse the reaction to this activity. They expect that the web application will present an error after ten times saying that the account is locked and a user should contact the support department or use the password forget link. But what if the web application doesn’t display an error but still blocks an account? This case is very difficult to handle and should be verified manually by the security analyst. The verification is very straight forward: just try to login to the account after ten unsuccessful login attempts. If you can login in, then you have an issue. If not, mark the issue as a false positive.
Changed admin credentials or paths. One of the best practices is to assign the “administrator” account to Guest usergroup and rename the real admin account to something not obvious, for example “John”. This may trick the hackers to spend valuable time to try to brute force the password for low privileged account. Unfortunately, this may trick the vulnerability scanners as well. So make sure you understand the environment and double check all the issues before you escalate the issues to the senior management.

False negatives

How can you find false negatives in the report? The simple answer: you can’t. False negatives are the vulnerabilities which were not discovered by the scanner, but present on the real site. The security analyst should be aware when false negatives can happen and make sure they are discovered by manual testing.

Out-of-Band Authentication. In order to improve the security, many companies implement two factor authentication or user registrations with out-of-band communications. This includes sending SMS to a customer mobile phone, calling a customer, sending emails or using a Mobile application to login. The tester should manually review the login process and see if there are potential security issues. Is the new password sent to the user in clear text? Is the SMS code predictable, for example incremental? Is it possible to hijack a customer account if a hacker has physical access to the phone? Create use or business cases and try to understand the end-to-end data flow to perform a comprehensive risks assessment.
Business login flaws. For a complex application, which gathers data from different sources and have multiple user profiles and products, each business transaction should be analysed for potential issues. The vulnerability scanners can tell if input fields don’t filter the malicious code, but they can’t tell you whether your business process is well designed or not. Do you remember the recent vulnerability in Skype? Hackers could hijack users account by simply contacting the support department! The user validation was based on telling five contact details from the list, email that was used during the registration and a full name. All these details can be easily obtained or discovered, so a large number of accounts were compromised. Definitely a business process flaw.
Restricted pages and lack of privileges. A typical marketing web site has in average two or three privilege levels (user level and admin), but a banking application may have more than a hundred different roles and hundreds of different privileges. In order to perform the comprehensive vulnerability assessment, you need to create N*M size matrix, where N is a number of privileges, M is a number of functions and test all input parameters using different credentials. Vulnerability scanners can do a good job for small applications; however, complex web portals require a lot of manual configuration from the security analyst.

Follow up on the findings

So now you have vulnerability reports produced by a scanner and you have eliminated all false positives and negatives. What is the next step?

Categorise findings. Depending on your company’s risk appetite and risk management matrix, you need to assign the appropriate risk level to the issues. I recommend you work closely with the risks management department (if you have one) or someone from the senior management to understand the real impact on your organisation. Popular risk matrixes are 5x5 and 3x3, but you can find organisations using 3x5, 5x7, 5x3 and others. The simpler the matrix the better, however, it needs to have enough flexibility to categorise the risks.
Send the technical finding to the IT team. Work closely with the network admins, web developers and system administrators to resolve the issues. Share the recommendations provided by the vulnerability scanner (make sure you understand them first) and be prepared to clarify them or answer additional questions. The technical teams will try to avoid making any changes on the production systems as it might break the existing functionality. If the changes are necessary or affect a large number and system downtime is required, make sure you implement them on the test or developer system first, validate that the issue is fixed and then implement the changes in production environment.
Retest the issues after they are fixed. When you get the confirmation from the IT team that the issues are fixed and the risks are remediated, retest is required to validate this. You might want to rescan the whole system or the application if the time allows, or just manually validate the findings from the initial report. Some issues are pretty straightforward to retest, for example if the web site is using SSL certificate or not, Telnet port is opened or closed etc. However, such issues as XSS vulnerabilities, insufficient access controls for the network folders, password policies require some time to validate.

Keeping the records

If your company performs the security assessment of one web site once per year, you probably can just keep the report in the email or on a network folder. But what if you have hundreds of web sites and critical systems and you perform the assessment every three month?

Excel spread sheets. All vulnerability scanners allow exporting the results to CSV or XML files. Excel is a very powerful tool to sort, analyse and monitor the results. You can import the results from multiple scans, track the statistics and build trends. Put the information about the remediation activities and follow ups. Pivot Tables will help to generate the reports across multiple security scans and build nice graphs, which can be used in management presentations. Of course, Excel has its drawbacks. Managing and consolidating results for more than a hundred systems will be a nightmare. The average scan contains about fifty to eighty finding per system, so for a hundred web sites the report can contain 50000 rows. If you perform the scan more than twice per year, it will become unmanageable.
Vulnerability management software. You need to clearly understand the difference between two products: vulnerability scanner and vulnerability management software. Some vendors, as Nexpose, include the vulnerability management software in the package with vulnerability scanner; some sell them separately, for example Nessus. A vulnerability scanner actively communicates with the target system, sends the malicious packets and analyses the results, which can then be exported to PDF, HTML, CSV and other formats. Vulnerability management software gets the results and provides a comprehensive dashboard to present the results. It can build trends, sort the results by criticality, and keep additional records, for example business purpose of the system or location. The reporting component allows generating the compliance reports against widely used standard, for example PCI DSS, ISO 27001, or again the corporate policies, for example the percentage of computers with outdated software or weak password policy.
3rd party bug tracking software. If you perform the web application assessment, the web developers might want the results to be imported into bug tracking software. Popular systems are Jira, Bugzilla and Zoho Bugtracker. This approach provides faster fixing times because the developers are familiar with the software and use it on a day-to-day basis. Some vulnerability scanners, for example HP Fortify, provide the integration out of the box so the export process is very simple. The drawback of this approach is limited reporting. The bug tracking tools have their own prebuild reports, which may not be suitable for security issues and are not aware of industry standards. You can always create your own report, but it will take time and effort.

Summary

The network and web application vulnerability management process is very important to keep the organisation secure and minimise the risk of compromise. Vulnerability scanners will help to proactively identify issues before the external hackers can discover them. To achieve the best results reports should be analysed and appropriate actions should be undertaken to mitigate the risks.

The security analyst should have experience and knowledge of common hacking attacks and mitigation strategies;
Obtain the feedback from the IT team and senior management when categorising issues and assessing the security risk;
Try to reduce the number of false positives to make sure you focus on important issues;
Review the scope manually to ensure the vulnerability scanners have covered all the functions, inputs and services;
Keep records to show to external auditors, senior management or other team members.

Remember, the main purpose of the vulnerability management process is to reduce the risk to acceptable level. Tools like vulnerability scanners can provide the data and perform some routine tasks, but team input is absolutely required to achieve the best results.

On the Web

http://en.wikipedia.org/wiki/Vulnerability_assessment - The overview of the vulnerability assessment process

http://www.imperva.com/resources/glossary/clickjacking_ui-redressing.html - Clickjacking explained

http://hothardware.com/News/Skype-Account-Hjiack-Vulnerability-Via-Skype-Support-Discovered/ - Skype Account Hijack Vulnerability

http://www8.hp.com/us/en/software-solutions/software.html?compURI=1337262#.Uor4wNLilwY – HP Web Inspect vulnerability scanner

https://community.qualys.fr/servlet/JiveServlet/previewBody/1541-102-1-1535/Sourcefire%2025%20Years%20of%20Vulnerabilities%20Research%20Report-%20A4%20(1)%20-%20copie.pdf – Qualys report on most common vulnerabilities.

http://www.acunetix.com/security-audit/siteauditreport.pdf - Acunetix report sample

http://portswigger.net/burp/samplereport/BurpScannerSampleReport.html - burp suite sample report

http://www.tenable.com/products/nessus/sample-reports - Nessus sample reports

Glossary

Vulnerability assessment - A process for identifying inadequate computer and network securities that cause technological weaknesses. Assessments also generally include methods for prioritizing and implementing additional security measures for fixing and protecting systems.
Application programming interface (API) - In most procedural languages, an API specifies a set of functions or routines that accomplish a specific task or are allowed to interact with a specific software component.
Intrusion prevention systems (IPS), also known as intrusion detection and prevention systems (IDPS), are network security appliances that monitor network and/or system activities for malicious activity.
A web application firewall (WAF) is an appliance, server plugin, or filter that applies a set of rules to an HTTP conversation.
The Payment Card Industry Data Security Standard (PCI DSS) is a proprietary information security standard for organizations that handle cardholder information for the major debit, credit, prepaid, e-purse, ATM, and POS cards.
SA account - The sa account is created during the installation process of the MS SQL server and the sa account has full rights in the SQL Server environment. By default, the sa password is blank (NULL), unless you change the password when you run the MSDE Setup program.
Out-of-Band Authentication is the use of two separate networks working simultaneously to authenticate a user.
Use case- In software and systems engineering, a use case is a list of steps, typically defining interactions between a role (known in Unified Modeling Language (UML) as an "actor") and a system, to achieve a goal. The actor can be a human or an external system.