Security Assessment Pitfalls: Avoid the Trap
FishNet Securitys Assessment Team has delivered on thousands of projects involving Vulnerability Assessments, Penetration Tests, Wireless Security Assessments and Social Engineering. During these engagements, we frequently observe a number of recurring themes in regards to common findings and vulnerabilities. This blog brings to light several of those themes and provides some guidance for clients to consider when preparing for security assessments as well as things to focus on for remediation of findings.
Things we commonly see in a Security Assessment…
1) Patch and Vulnerability Management – For various reasons such as change control, legacy platforms, etc., clients often don’t patch consistently, especially third-party applications. They may patch the operating system, but often the weaknesses are in things like third-party ftp servers, web applications, etc. This is a process problem, especially on the apps that can’t be automatically patched or updated.
2) Configuration Management – Shortcuts in configurations i.e. not changing default settings in wireless devices, routers, switches, etc. Often these settings aren’t configured until it’s too late because it can be complicated and usually involves a lot more work, but when it’s not done properly, it’s a serious vulnerability. Inconsistent configurations (using same example, maybe most were set correctly, but 30 systems were missed … only requires one to exploit). Default accounts & passwords are also still a regular configuration management issue that we frequently discover. This is really a process problem.
3) Applications (SQL Injection) – On external penetration tests where some companies are pretty diligent on their external patching, we still see SQL Injection as a possible attack vector. On that note, SQLi is also a recurring vulnerability we often see as well. This is more of an application development issue.
4) Social Engineering – The ultimate people problem. This includes all forms of convincing people to do things they aren’t supposed to do such as spear phishing for email addresses or getting users to access malicious sites, talking people into letting us into the wrong places in a facility, tailgating, etc. Tons of possible scenarios here, but these are probably the most significant people/process security problems companies face today.
Top customer takeaways from Security Assessment projects…
1) Don’t just patch the vulnerability, figure out why it happened and how to fix it in the future.
2) Passing an external penetration test does not mean you’re secure or impenetrable, or that you don’t have vulnerabilities on your internal network -- a crunchy outer shell usually indicates a gooey inside. There are many ways for an attacker to get into a company, many of which have nothing to do with hacking the perimeter so always consider spear phishing, physical access, etc. when creating your assessment requirements.
3) Data isolation and segmentation on an internal network really does help. Internal networks are inherently weaker because there are end-users involved. Don’t store your sensitive secrets in an area where end-users have full access.
4) Process audits are necessary. Most customers have existing patch and configuration processes, yet we almost always find weaknesses in the one thing that was “forgotten” or “couldn’t be patched because of some legacy requirement." Audit your configurations and patching periodically to ensure they are happening according to process and best practices.
5) User education, user re-education, and looking at ways to protect the end-users from themselves -- think Security Awareness Program and make sure to test and measure its effectiveness.
6) Outbound filtering. When an attacker breaks into an environment, they are looking to open outbound shells or connectivity. That goes for phishing and other attacks as well. When we spearphish a client we’re trying to get them to click on something and have it open an outbound shell. That’s much harder when the client is performing outbound filtering at the firewall. Reduce the ability for an attacker who gets malicious code into an organization to use that code to actually gain access.