“Have you run vulnerability scans? Have you factored penetration tests into your test strategy? Have you made sure that security standards are met? Is the final product compliant with the procedures? Do we need penetration tests?” These are questions I get to hear every day at the client site. I worked on a couple of projects in last year and both of them required penetration testing, port scans, and vulnerability scans. Initially, I was scared to hear any of these buzzwords but was curious to understand why and how they are important, as these were all requirements in the BRS. With the refinement of the testing process at my client site and engaging performance testers early on project, I was able to make decisions on non-functional testing scope and get the overall test strategy in shape.
‘Hardening‘ a device requires known security ‘vulnerabilities’ to be eliminated or mitigated. A vulnerability is any weakness or flaw in the software design, implementation, or administration of a system that allows a threat to exploit a system or process’s weakness. There are two main areas to address in order to eliminate security vulnerabilities: configuration settings and software flaws in program and operating system files. Eliminating vulnerabilities will require either ‘remediation‘ – typically a software upgrade or patch for program or OS files – or ‘mitigation‘ – a configuration settings change. Hardening is required equally for servers, workstations, and network devices such as firewalls, switches, and routers.
A vulnerability scan or external penetration test will report on all vulnerabilities applicable to your systems and applications. You can buy in third party scanning/pen testing services, such as NGS. Pen testing by its very nature is done externally via the public internet as this is where any threat would be exploited from. Vulnerability scanning services need to be delivered in situ on-site. This can either be performed by a third party consultant with scanning hardware, or by purchasing a ‘black box’ solution whereby a scanning appliance is permanently sited within your network and scans are provided remotely. Of course, the results of any scan are only accurate at the time of the scan which is why solutions that continuously track configuration changes are the only real way to guarantee the security of your IT estate is maintained.
‘Remediation‘ of a vulnerability results in the flaw being removed or fixed permanently, so this term generally applies to any software update or patch. Patch management is increasingly automated by the Operating System and Product Developer – as long as you implement patches when released, then in-built vulnerabilities will be remediated.
Configuration-based vulnerabilities have no more or less potential for damage than those which require remediation via a patch, although a securely configured device may well mitigate a program or OS-based threat. The biggest issue with Configuration-based vulnerabilities is that they can be re-introduced or enabled at any time – just a few clicks are needed to change most configuration settings.
Unfortunately, all the time! Worse still, often the only way that the global community discovers a vulnerability is after a hacker has discovered it and exploited it. It is only when the damage has been done and the hack traced back to its source that a preventative course of action, either patch or configuration settings, can be formulated. There are various centralized repositories of threats and vulnerabilities on the web such as the MITRE CCE lists and many security product vendors compile live threat reports or ‘storm center’ websites.
“So all I need to do is to work through the checklist or test scripts and then I am secure?” In theory, but there are literally hundreds of known vulnerabilities for each platform; even in a small IT estate, the task of verifying the hardened status of each and every device is an almost impossible task to conduct manually.
Even if you automate the vulnerability scanning task using a scanning tool to identify how hardened your devices are before you start, you will still have work to do to mitigate and remediate vulnerabilities. But this is only the first step; if you consider a typical configuration vulnerability, for example, a Windows server should have the guest account disabled. If you run a scan, identify where this vulnerability exists for your devices, and then take steps to mitigate it by disabling the guest account, then you will have hardened these devices. However, if another user with administrator privileges then accesses these same servers and re-enables the guest account for any reason, you will be left exposed. Of course, you won’t know that the server has been rendered vulnerable until you next run a scan which may not be for another 3 months or longer.
Device hardening is an essential discipline for any organization serious about security. Furthermore, if your organization is subject to any corporate governance or formal security standard, such as PCI DSS, SOX, HIPAA, etc., then device hardening will be a mandatory requirement. All servers, workstations and network devices need to be hardened via a combination of configuration settings and software patch deployment – any change to a device may adversely affect its hardened state and render your organization exposed to security threats. Vulnerability scanning is a requirement in almost all projects involving new infrastructure or changes to the existing infrastructure. As a test authority, you should own the responsibility to make sure the security requirements are covered and the external cost for pen tests and scans is factored in the test estimates.
