Jay Butler, Senior Technical Consultant
Annual vulnerability assessments (VA) are intended to uncover every aspect of a computer network that could be exploited for unauthorized activity. Performed by an independent, non-regulatory firm, assessments involve numerous components including a final report on the various findings. The report is usually segmented into an external section and an internal section with each respective finding rated high, medium, or low. The external “pen test” results are typically very sparse because the assessor does not have physical access to the network, and the testing area is smaller compared to the internal network. Furthermore, external testing is performed remotely via the Internet, an area where many businesses have setup a strong security fortress. Financial institutions employ several managed security layers including advanced firewalls and sophisticated Intrusion Prevention Systems (IPS) forming a strong barricade against hostile Internet activity. Because this probably describes your network as it relates to the external portion of a VA, I want to use this brief article to help you better understand how to interpret the internal findings.
The internal network findings comprise a majority of the assessment report because there is far more to be analyzed via direct access to the network. In a sense, there is no need for a “pen test” to determine accessibility because the assessor is typically granted an available work space to connect their computer and even provided a network user account. All components of the private network such as servers, workstations, routers, and printers are scanned via a direct physical connection no different than a user’s workstation. Once physically connected to the network, most security measures can eventually be circumvented by someone with even a minimal skill set. Financial institutions do not allow physical access to their network by unchecked sources, so this is an important factor in measuring the risk of each internal finding. By no means does this or any other mitigating factor completely nullify a finding; in fact, severe exploitations commonly occur from someone that has been purposefully granted network access, such as a user or outside vendor. Therefore, it is important to actively monitor and strictly limit access by using the “only allow what is required” rule. User accounts and their access methods must be reviewed regularly and adjusted according to the rule. Maintaining strict access control is a critical starting point in addressing most internal findings.
How to address the specifics of each finding varies significantly, but I think most fall into one of two categories: software updates or configuration changes. Software updates such as Microsoft Critical and Security Updates rectify known weaknesses in Microsoft software. Sometimes the vulnerability is only theoretical and may have no known cases of exploitation; however, all compatible security updates should be maintained. The key here is compatibility. Just because a VA lists the vulnerability does not mean it can be completely closed on every network. When Internet Explorer 7 was released, many found it incompatible with their business applications. Even though it quickly became a finding on most VA’s, it took awhile for application updates from vendors to allow for full compatibility with IE7.
Compatibility is one of numerous valid reasons that explain why some findings cannot be eliminated completely; very high cost for minimal benefit is another valid reason, albeit subjective. The response to such findings should include a written explanation along with a description of other mitigating factors. For vulnerabilities in older versions of Internet Explorer, other factors include a stateful packet inspection firewall with content filtering and IPS. Other software updates may not significantly improve security if at all, so cost/benefit analysis is critical in making measured decisions. For example, upgrading to the latest version of antivirus software can be costly and may not improve virus protection at all.
In the configuration change category, findings sometimes target required and legitimate network functions such as Task Manager. Backup “NAS” servers that run Symantec Continuous Protection Server (CPS) require Task Manager for volume shadow copy. Other servers may also need Task Manager, so findings like these require scrutiny before remediation. Internet Information Services (IIS) should also only be enabled on servers that require it such as WSUS and Microsoft Exchange. Rather than maintaining a sound configuration and continuous updates, its best to uninstall IIS from servers that do not require it.
Some findings recommend a costly configuration change that may not provide worthwhile benefits. For example, making MS Exchange server available in the DMZ requires an additional server and sophisticated configurations. An outsourced solution like Gladiator eShield makes more sense in most cases. eShield provides better security by way of an advanced email firewall that includes specialized email protection and spam filtering. Another option that may be a better cost/benefit is to implement an internal email firewall.
The actual cost to completely mitigate certain findings in the”configuration change” category is often difficult to measure, so it’s important to analyze risk. Hidden long-term costs include administrative overhead associated with very sophisticated implementations. As the network becomes more secure, the cost to maintain and scale it increases. If the risk is high or involves a regulatory requirement, the cost may be unavoidable and thusly justified. In other cases, the risk may be relatively low and/or already include sufficient mitigating defenses. Sometimes the assessor may simply be overzealous with his findings.
I believe the internal portion of most Vulnerability Assessments can be better described as a Network Assessment. Not every finding is a vulnerability per se because not all mitigating factors may be considered. Task Manager is not a vulnerability when used for legitimate purposes and safeguarded via network access control. Moving Exchange to the DMZ is not a necessary mitigation (or possible without an additional server) where Gladiator eShield is employed. Other findings may require a very high cost for very little gain. Keep in mind that assessors strive to find something and everything to prove their value, so a “clean” Vulnerability Assessment may not ever be reasonably obtained. Besides, that is not a necessary goal. The VA is an analysis of the network useful for exposing otherwise unknown facts about the environment. It must be appropriately responded to, but that does not always equate to making large scale changes. Often, a thorough written response is all a finding requires. Bank examiners will not be looking for a perfectly clean VA as much as they will be looking for evidence that you have assessed and considered all facets of your network.