One surefire way to find out what security issues are present within your organization is to fall victim to an attack. When the dust has settled, a detailed report consisting of logs, changes, and attack report data will often outline everything that was vulnerable, pointing the way toward remediation tasks necessary to close any holes.
There is, of course, a much better way that doesn’t involve falling prey to a cyberattack. Instead of waiting to become a victim and reacting to it, a more proactive approach is to regularly perform vulnerability assessments of the devices and services on your network to obtain reports on what issues are found, their degree of severity, and what steps must be taken to correct these vulnerabilities.
“Security is always going to be a cat-and-mouse game because there’ll be people out there that are hunting for the zero day award, you have people that don’t have configuration management, don’t have vulnerability management, don’t have patch management.” – Kevin Mitnick, security consultant, hacker, and author.
With the quote above in mind and considering that the enterprise network may not necessarily belong to you, there are a few things to work out before loading up the latest copy of Kali Linux and performing every scan you can think of. There may be repercussions—organizational, financial, regulatory, and almost certainly legal—that you may want to work out with various stakeholders at the company before proceeding with any penetration testing engagement.
Communicate with stakeholders
If you think the scanning process is the most important part of the assessment, you’re gravely mistaken. As mentioned above, communication is the crux of what makes (or breaks) a penetration testing engagement. It’s the fine line between being authorized to perform this engagement on behalf of the company or getting into hot water over a perceived hacking attempt.
First, identify the stakeholders including the relevant members such as management, security, networking, and IT department members, and heads of human resources, perhaps, board members…anyone who should be part of the conversation should be included.
Plan the scope and scale of the scans
Once the stakeholder team has been identified, the various members must determine the scope and scale of the assessment, including devices, subnets, and services that should be targeted, as well as those that are strictly off-limits. Additionally, include information about to when scans should take place, especially when assessments have the potential to affect network use and resources due to the processes involved in scanning.
The determination of what’s going to be scanned, when, and how, including the assets that are to be excluded, should all be placed into the Rules of Engagement document and adhered to explicitly in order to minimize the possibility of causing damage to or negatively impacting business continuity.
Gather target information
With the rules established and the scope identified, it’s time for the engagement to begin. Depending on what type of penetration test was agreed upon—white, gray, or black-box testing—little, all, or no information may be available to you. Assuming no information is provided, it’s best to begin with the information gathering stage, using tools like Nmap to perform discovery scans to the devices, networks, and ports that services are running on to not only paint a picture of the testing landscape but also to gain insight into the applications and services running on target devices.
By fingerprinting each device, important details will be made available and allow the tester to identify the tools required to best continue the vulnerability assessment. Bear in mind that while general-purpose scanners may provide a significant amount of insight into possible vulnerabilities, in the interest of being as thorough as possible, certain tools are designed for a specific service assessment, such as those that are optimized for web servers or application fuzzing.
Moving forward with critical assessments will come after all device data has been obtained using a mix of general-purpose vulnerability assessment tools and specialized ones, as needed. No two assessments are alike, so what tools are used, how they’re configured, and how the assessment process is carried out will vary greatly on a number of internal and external factors. With this in mind, it is important to configure the tools and their respective plugins and modules in line with the rules of engagement to limit the damage that may be caused to systems due to aggressively configured scans.
Fine-tuning scans is often a good test to perform before beginning the actual assessment just to obtain some baselines so as to not push the limits of the devices being tested. Further optimization is often necessary during engagements to account for variations that may occur, including increasing or decreasing utilization.
Correlate feedback into reports
As each of the tools is run during the assessment, they will inadvertently provide data based on the device responses. This data will need to be correlated in groups if not done so already by the respective tools into various threat categories ranging in severity. This helps to identify, at a glance, the most important threats to the least. However, before moving forward with creating these reports and even less so dispersing them to stakeholders, it is imperative that test results be verified as true positives to prevent spending time and effort in correcting issues that may not exist.
Multiple reports should be created containing various levels of detail and technical information, depending on the intended audience. For instance, board members and upper management may prefer a summary view of the items found based on priority level, beginning with high-threat category items. By contrast, IT pros that will be tasked with the remediation process will likely appreciate a more detailed report explaining which systems are affected and how to perform corrective measures.
Perform risk assessment based on report data
With the assessments complete and verified, and reports generated, stakeholders should reconvene to perform risk assessments of devices with vulnerabilities to determine how to proceed with correcting issues (mitigation), understanding the risk and choosing to leave affected device(s) as-is (acceptance), immediately discontinuing use of devices and services (avoidance), or implementing third-party solutions to replace existing ones (transference).
Each system will have its own set of requirements to best handle the threat assessment and will likely require a unique solution to the other items on the list. Again, in an effort to minimize risk and optimize the amount of time spent to best remediate concerns, having a clear-cut plan of action detailing how to proceed will serve to quickly and efficiently resolve assessment items and get devices and services secured.
Implement remediation tasks
With all aspects of the assessment complete, risks assessed, and reports provided to each of the key stakeholders, remediation may now commence addressing the findings of the report. While all tasks should be completed as soon as possible, it is a best practice to begin addressing high-priority threats first, then moving down to medium, and finally low-priority threats to minimize the possibility of devices or services becoming compromised and exploited by shrinking the overall attack surface while simultaneously limiting the severity of the potential fallout.
Once remediations have been performed, great care should be taken to verify that assessments have indeed been corrected. Sometimes this can occur simply by patching devices and re-running the software updates to confirm that any pending updates have been installed. Other times, performing the test engagement again can both confirm that previously identified issues have been addressed, while further providing if additional (and sometimes previously missed issues) have arisen.
Schedule scans for regular assessments
Vulnerability assessment scanning should be scheduled as part of an ongoing change management process, focused on maintaining a high-level security posture for the devices and services that make up the organization’s network.
Depending on the needs of the company and corporate policies, including regulation requirements, it is highly advisable for an ongoing strategy to be implemented that will conduct regularly scheduled assessments of the security posture to determine not only where issues may exist, but how they are to be corrected in the future.