Vulnerability Assessments are not Penetration Tests!

Too often I, as well as many of my co-workers, go into a client and throughout whatever assessment I am working on, general questions come up like, “when’s the last time you’ve had a pen test?” And the client responds, “Ohhh, we do those annually with ‘Some Corporation.’ ” And after looking at ‘Some Corporation’s’ website and seeing what they consider to be a penetration test, I am again disgusted to see that they show up with a vulnerability scanner, run it, validate some findings, and are off to their next client.


Now I know these are some brash comments made toward some random security companies, but let’s be honest here: If you’re going to do something, do it right the first time and provide your client the value of the assessment they paid for. Additionally, give the client what they paid for. If I go to a salesman to buy a sports car and he tries to sell me a Honda Civic, I’m going somewhere else to get what I asked for. On the other side of the coin is the fact that a lot of companies that want a penetration test don’t really understand what it is to begin with. It seems to me that gone are the days of true pen testing when the dreaded “Red Team” shows up to strike real fear into the hearts and minds of Security Practitioners at Fortune 1000 companies.


Any kid in their parent’s basement with savvy computer skills can fire up a Nessus scanner, Web Application Scanners, or Qualys Guard against a network and some of those people can actually interpret the results to make sense out of them. Trust me, everyone on SecureState’s Profiling Team can do that with their eyes closed, but how many security companies out there can actually run a legitimate pen test? I’m not calling anyone out and challenging them, but in all reality, I just want to know how many companies are willing to admit that what they call a “Penetration Test” is actually just a vulnerability assessment? Even worse is the number of companies who perform so called “penetration tests” and truly believe that a vulnerability assessment is the same thing as a pen test.

So let’s all be clear here: a true penetration test is over 85 percent manual and the remaining 15 percent can be a vulnerability scanner to get some other findings in a report in order to provide additional value to the client. And let’s also define manual attacks as to not be ruling out all tools. Using a port scanner is way different than using nCircle, Qualys, or Nessus. Automated scanners like these are the tools that don’t really help a pen test. And just because you use a tool like the Metasploit Framework and many of the tools in Back|Track 4, doesn’t mean you are running a vulnerability scanner. NMAP has the ability to run scripts as well, but again, it doesn’t belong in the Vulnerability Scanner category.

Many times, companies perform Attack and Penetration's due to compliance, or potentially other reasons, which is a bad idea. It gives those companies the opportunity to choose malicious compliance over the desire for truly assessing the security of the entire company. Malicious compliance is a term used when companies do the bare minimum in order to achieve a stamp of approval for whatever standards they are trying to satisfy the needs of. When companies choose to perform pen tests on only their systems affected by compliance, such as PCI or HIPAA systems, they are missing entire networks of systems which aren’t tested. When this happens, companies aren’t getting the true value of what a Pen Test can provide.

SecureState is a trend setting company, and this is where we are going to step in and say, “We Pen Test!” The PCI DSS Council has at least defined what they consider a penetration test. In section 11.3 the Council defines it to be: “vulnerability assessment simply identifies and reports noted vulnerabilities, whereas a penetration test attempts to exploit the vulnerabilities to determine whether unauthorized access or other malicious activity is possible.” Even the EC Council states that, “Penetration testing simulates methods that intruders use to gain unauthorized access to an organization’s networked systems and then compromise them. Penetration testers may use proprietary and/or open source tools to test known technical vulnerabilities in networked systems. Apart from automated techniques, penetration testing involves manual techniques for conducting targeted testing on specific systems to ensure that there are no security flaws that may have gone undetected earlier.”

The SecureState Profiling Team utilizes lower risk vulnerabilities in some systems with additional vulnerabilities in other systems and links them together into larger attacks. By pulling off an attack in this fashion, the Profiling Team utilizes what is called the Vulnerability Linkage Theory in which we can show why it's important to maintain system baselines and other security measures. The Vulnerability Linkage Theory shows how the attack was pulled off by coupling vulnerabilities in many systems to result in the end compromise. For instance, username enumeration from a website, coupled with a brute force attack on the mail system, could allow SecureState to access mail from a company. From here we can email the tech support team and social engineer them into divulging information on how to access the corporate VPN and voila: access to the internal corporate network. There is no way a vulnerability scanner can do that.

Penetration tests zero in to specific systems in order to break in and see what information can be divulged. Pilfering computers and file shares will explain the benefits of Pen Tests by finding the important documents and unencrypted data. Even finding password protected Microsoft Office files can be cracked to release potentially serious data about a company we’re hacking into. Pen Tests can also be used by Security Departments to show why things need to be fixed and get budget to move forward.

There are conflicting views on Pen Tests and Vulnerability Scans. Pen Tests aren’t performed to find vulnerabilities; they are done in order to compromise systems and networks. The main difference between the two is that in a pen test the attackers are actually exploiting vulnerabilities in systems, adding user accounts, and compromising machines across the network. A full or total compromise, which means total control over the entire network, is the end goal of a pen test. Throughout a pen test, the attackers will inevitably generate a list of findings. Many of these findings may be the same as what a vulnerability assessment will also come up with, but there are many vulnerabilities that scanners just can’t find, which leads to the fact that tools can’t think; consultants can. Consultants are able to interpret results and decide on how to use them in order to leverage certain attack vectors against machines and networks.

Don’t get me wrong: I am not discounting the need, want, or value of a vulnerability assessment. These assessments, as well as pen tests, have their place and need. What I am saying is that these assessments need to be better understood in order to know how and when they should be performed. Additionally, there have been companies that run regular vulnerability assessments and the same vulnerabilities keep coming up every single scan. These companies are either overwhelmed with the amount of vulnerabilities present in their networks and don’t know how to fix them, or they don’t see the value or need in fixing them. Penetration tests can enforce the reasoning. In turn, by better understanding what the difference is, the clients will understand what to expect as a final product and won’t be dissatisfied with the results of each test.

Read more!

Hungry, Hungry, HIPAA

Over the last year we have seen a small surge in HIPAA assessments from our clients. The few years leading up to that were pretty darn quiet compared to the initial storm when the regulation first came out. So why is that? Well, it’s something we say over and over and that’s “no one does security unless they have to,” though there is some due diligence. But that’s all about to change.

With HIPAA, other than some initial work a long time ago, it wasn’t that scary until the audits started. And most of the work was done under some risk-based assessment that likely favored the business over security. Even so, statistically speaking, your organization isn’t likely to get ‘hit’ any time soon based on the number of audits being performed. In previous postings, we tried to make it easy for you and talked about using the NIST 800-66 framework.

Now despite all our efforts, the current administration – like them or not – realizes that HIPAA still needs more teeth. I don’t know about you, but the $100,000 HIPAA audit fine for an organization in Seattle was nearly laughable compared to the millions of dollars being levied for PCI. So of course your ‘risk assessment’ is going to say doing security isn’t worth it versus the costs given what we’ve seen to date. So we need to make it more painful, right? Make it so that you feel like you have to do it, right?

Buried within the American Recovery and Reinvestment Act of 2009 (ARRA) signed in February is the Health Information Technology for Economic and Clinical Health Act's (HITECH Act) – though this isn’t really high tech, go figure. This includes quite a few revisions to HIPAA such as increased coverage for non-entities. But the high impact area is mandatory breach notification and subsequent requirements. To enforce this, it is tied to increased penalties, fines and overall liability, and improved enforcement. Fines can reach $1.5M now. Civil lawsuits can now leverage HIPAA. And finally, there is an increase in audits.

So, do we have your attention now? It’s time for organizations to dust off their HIPAA compliance manuals from 5+ years ago and get some new, independent review on what the real risks are and using an accepted framework. It’s time for organizations to get risk assessments performed, like penetration tests that truly simulate breaches to see if it could really happen there. Failure to do some assessment/audit work prior to a CMS audit is likely going to result in fines and reactive security, or worse, a very expensive breach. It’s better that experts like SecureState find the problem than CMS or the hacker – and for a lot less.

Read more!

Preparing for HIPAA: Round Two - The Audit

The big buzz this year around security assessments and audits is all about HIPAA. This was #6 in SecureState's Top 8 of 08 and, to say the least, there’s quite a bit of tension in the air as organizations hold their breath. While PCI is still the most active, all of our clients with HIPAA concerns – which is many – are on constant watch to see what HIPAA is really going to mean. To date, HIPAA has been a little weak as organizations have been left to their own devices to operate around a risk-based approach for HIPAA. But that approach has time and time again proven to not be diligent enough and/or favors the business over security. But now, the audits are happening, HIPAA is getting some teeth, and most organizations are scrambling to figure out what ‘their’ interpretation is and if what they did is enough. Everyone knows that the first audit was done last year at a hospital and have seen the list of‘42 questions’ that were asked. But those hardly helped as they really didn’t indicate what the expectations were. Now other HIPAA organizations are being audited including retailers and insurers. The results are supposed to be posted on the CMS/HHS site, but so far nothing is out there. But hope is not lost as the details emerge from our clients and other information.

First of all, it is important to realize who is doing the audits. It is KPMG’s government practice and working for a government agency. As such, it should be expected that they would leveraging NIST standards. The second indicator is from NIST itself. The CMS/HHS first worked with NIST to develop the 800-66 publication for understanding and implementing the HIPAA Security Rule. But that proved to be fairly vague and mainly referencing a bunch of other NIST standards but not providing a lot of ‘how’. Based on that type of feedback, they have issued a draft version ( http://csrc.nist.gov/publications/drafts/800-66-Rev1/Draft_SP800-66-Rev1.pdf ) that has finally provided a solid understanding of how to implement the Security Rule – by mapping it to NIST 800-53 that outlines ‘recommended controls’, not unlike ISO 27002 (formerly 17799). Ultimately, this has been further confirmed in reviewing some of the HIPAA audit draft reports that NIST 800-53 is the core of the KPMG audit framework.

So now you know what they are looking for and what to expect. If you were looking for a solid ‘checklist’ for gapping your HIPAA program, look no further than NIST 800-53, or even better, the draft of NIST 800-66. The draft is great as it also has sample questions that the auditor might be asking as well – hint hint. The other referenced NIST standards can also be helpful, especially if your organization uses a particular technology extensively e.g. 800-124 draft on cell/PDA security. Regardless of what the checklist is, the bottom line is HIPAA has not had a strong enough impact for organizations, much like SOX. As a result, companies aren’t really getting secure as originally intended. Every hospital or insurance company we have reviewed has failed system audits and penetration testing - and we're the good guys. Getting compliant, even to a higher level, isn’t getting secure. And odds are, your organization has more than HIPAA data out there.

So do the right thing, do due diligence, do it soon, and get your organization to a defensible position before the audit. Base your decisions on the intent of the controls outlined in 800-53/66, not the wording or sample interpretation. Don't wait for the audit, findings and fines - or even worse - the breach. It's a lot more expensive to implement security after the fact than before.

Read more!