As is applicable for any project, the success of the vulnerability assessment depends on estimations that are close to the actual. Output from the scoping and planning phases helps in estimating the most important factor in a vulnerability assessment—the time required to complete the assessment.

If a tester is having a very good experience running assessments over a scoped environment or similar, then the estimation is done on the basis of previous experience. If a tester is new to the environment then previous tests reports and communications are referred to for estimation. Additionally, a tester considers additions and changes in scope, involvement of third-party services / service providers, if any, and updates the estimates accordingly.

Once rough estimates are ready, time padding is considered and time is added over the anticipated time required. This time padding is usually set at 20%. This helps the tester to deal with any unsolicited challenges that they may face during execution.

The following are a few of the unsolicited challenges/problems that one can face during the execution of the vulnerability assessment:

• Network security devices blocking scans: Network security devices such as firewalls, intrusion prevention systems (IPS), and unified threat management (UTM) detect scanning traffic as malicious traffic and block all the requests sent by the vulnerability scanner. Once alerts are generated on the respective network security devices, the tester needs to ask the network administrator to whitelist automated scanner IPs and manual testing machine IPs.
• ‎Assets not responding as side effects of certain tests: Some scanning signatures leave assets in DoS mode. In such cases, a tester needs to identify such assets and fine-tune the scanning profiles so that comprehensive scanning can be performed on these systems. Often, such scan-sensitive systems are closed source and out-of-the-box solutions.
• ‎Scan impacting business critical service(s) and hence scanning needs to be stopped abruptly: Some vulnerability scanning signatures may break certain services on systems. As the business is always the priority, scanning has to be stopped and business-critical services need to be recovered. A tester needs to perform scanning on such assets separately with less intensive and/or fine-tuned scanning profiles in nonbusiness hours.

• Blocking user IDs allocated for scanning: While performing authenticated scans because of heavy traffic to centralized Identity Access Management Systems (IDAM), login attempts may get classified as malicious and scanning accounts may get blocked.
• ‎Slowing down the network because of scanning traffic and hence delays are introduced in report generation: While performing automated scans, aggressive and intensive scanning profiles creates overhead on network traffic. This may slow down the network or put some of the network devices in the fail-closed state, preventing scanning requests from reaching assets.

Usually, this padding is not completely utilized. In such cases, to be fair to the customer, the tester can use this extra time to add more value to the vulnerability report. For example:

• Exploring identified critical vulnerabilities in-depth to find out the implications of vulnerabilities on overall infrastructure security
• Running some more manual POCs over critical, highly severe vulnerabilities reported to minimize false positives
• Conducting a detailed walkthrough of a vulnerability report for the stakeholders
• Providing additional guidance on vulnerability closure 

Time estimations are done in the form of man-hours required for testing but the tester should also consider that deploying more personnel for a project is not always going to reduce timelines.

For example, when an automated vulnerability assessment suite/scanner initiates testing over a network segment or group of assets, the time required to conduct tests depends on the infrastructure involved, the number of assets to scan, the performance of assets, network traffic, the intensity of test profiles, and many other external factors. As tester interaction is hardly required for automated scanning, deploying more testers in this phase is not going to reduce the time. However, it's not the case with manual testing. Manual test cases can be executed in parallel by multiple testers at a time, reducing timelines considerably.

Another factor to consider is the extent or intensity of the tests to run on assets. For critical assets, in-depth testing is required with more intense scanning profiles, whereas for noncritical assets just an overview is usually enough. Running intense scan profiles for automated as well as manual testing takes considerably more time than that of normal scanning profiles.

The outcome of a time estimation exercise is definite drop-dead dates. A vulnerability assessment should always begin on the preplanned date and should be completed on the estimated end date. As vulnerability assessment covers vast infrastructure, many system owners and third parties are actively involved in the exercise. The additional responsibility to support vulnerability assessment is usually an overhead for the stakeholders involved. Hence, in order to keep them organized, synchronized, motivated, and supported during the VA exercise, finite drop-dead dates are very important.