Critical Assets – Security and Compliance

hax0rz oh gn0!

I’m addressing this about 6 months too late, but there was an extremely repetitive, relatively ignorant article that was written by M. E. Kabay which rehashes the topic of whether or not you should hire hackers for what seems to be the hundredth time. There are additional comments on Brad Johnson’s blog here:  http://systemexperts.blogspot.com/2009/10/hiring-hackers-please-dont-by-brad.html

The only people who argue against hiring hackers are people who are riding their coat tails, or trying to create controversy that simply isn’t there. Put simply, the information security industry was -created- by the very  hackers that the article suggests you shouldn’t trust. The concept of compliance regimes, security standards, controls, and technologies like firewalls, IDS/IPS, DLP, etc… wouldn’t exist without the need for security, and the need for security is addressed by these companies… right… the ones created by hackers.

In fact, suggesting that you shouldn’t ever hire a hacker to work on your security project is analogous to suggesting that a doctor who has performed exploratory surgery on a patient with success is somehow less qualified to address your ailment.

Chris and Al,  both of whom I have seen own various parts of our nation’s infrastructure first hand, are two of the most respected early security technology executives in the industry. Maybe you’ve heard of their companies: Secure Networks, and ISS.  Sorry guys, you’re outed. It’s been like 20 years, so I’m pretty sure you’re safe from a statutes perspective. Point being that hackers are the primary people who are responsible for you having an industry to work in.

Its just funny to me that people are still having this conversation, because the argument that no one should hire hackers is silly. If you want to buy a product or have a service executed that even remotely involves security, you WILL be hiring a hacker, and you don’t really have a choice in the matter. If you end up with zero hacker involvement, you may want to review the efficacy of the product or service you just bought.

Whenever we do a pentest that has a social engineering phase in it, an important part of the test is to consider all of the parties involved, the vector of attack, and the potential outcome of the attack. By doing this, you

only add the necessary amount of risk to the business required in order to demonstrate the vulnerability.

Either that, or you trigger an emergency alert scenario that goes out to all credit unions on behalf of the NCUA.

This happened during a penetration test being run by a company called “Microsolved” which was being conducted for a specific credit union.

This is a pretty clear example of how a poorly planned social engineering scenario can backfire, and falsely alert thousands of people to a scenario that doesn’t exist, wasting potentially millions of dollars in prep time and execution of incident response plans for an incident that didn’t exist.

Don’t get me wrong, mock scenarios are great for testing plans. They are however, not that great when they

exercise plans of companies who are not involved in the penetration test.

Furthermore, the guy at the bank who was responsible for the pentest apparently went on vacation while the test was occurring:

“But, on the day the package was received, the person responsible for the test was out of the office. So the employee who received the suspicious letter, which bore a NCUA logo and the bogus signature of former Chairman Michael Fryzel, reported it to the NCUA fraud hot line.”

The other part of this story that I found fascinating is the NCUA’s response to all of this, which pretty clearly had little to no executive involvement, and wasn’t reviewed by anyone with responsibility for security or compliance. They say, and I quote:

“Credit unions are not authorized to create facsimile documents bearing NCUA logos or signatures, or to improperly represent communications from NCUA, even during the legitimate conduct of business, such as a computer security assessment.”

Seriously? The federally sponsored organization that supervises federal credit union activity is more concerned with….improper logo usage than they are with the implication that they were tricked into sending out alert letters to nearly 8000 companies.

I guess I’d better take this Kellog’s sticker off my sniper rifle. They might get the wrong idea about me being a cereal killer.

I found myself in a weird position today, listening to an old friend tell me that Bob Russo from the SSC had apparently gone madly insane and started asserting very specific claims on the behalf of vendors – in this case Core Impact. I like Bob, and i’ve never heard him directly say anything that was contradictory to the reality of PCI, nor do I know him to be a crazy person.

So I decided to listen to this interview, and compare it to Core’s claims. Here is Core’s press release from November:

http://www.coresecurity.com/content/cipf-enables-organizations-to-prioritize-security-risks-and-maintain-pci-compliance

where Core claims, and I quote:

“In a recent webcast hosted by Core Security, Bob Russo, general manager of the PCI Security Standards Council, reaffirmed that internal use of a penetration testing software solution such as IMPACT meets the specific testing guidelines of DSS and confirmed that reports produced by such technologies will be accepted by certified auditors as proof of compliance with that portion of the mandate. The statement refutes some existing market misconceptions that DSS requires third-party penetration testing.”

In fact,what Bob says is almost the complete opposite of this. Here is a transcription from the audio, starting at roughly 45:00:

Mike @ Core Security: “I dont know exactly what you think on this one but we’ve had a few people who’ve said … they were told by their auditors that reports from our pentesting product, core impact, might or might not be accepted, but in reading the standard it says that pci has no reporting requirements for pentesting. so is it basically, go back to .. if you can document that you’ve conducted a pentest, with or without our product.. if you’ve documented that you have conducted an effective test, and as long as the auditor can make sense of it, is that acceptable to you or to the PCI standard?”

Bob Russo @ PCI SSC: “That is acceptable to us. We don’t look for specifics on the pentest. Again, that would be up to the assessor and you would have to convince the assessor that the pentest is in fact valid.”

Mike @ Core Security: “So you have to just basically say ‘I did it and heres the results’ so you’re judging the quality of the pentest and the document, not necessarily the audit trail if you will…”

Bob Russo @ PCI SSC: “That is correct.”

This has got to be one of the worst examples of vendor BS I have seen to date. Bob is obviously responding to the part about “if the auditor can make sense of it,” and this statement is used in Core’s press release to make Bob look like he’s inferring that:

“CORE IMPACT = PENETRATION TESTING.”

The standard does not “say that there are no specific requirements.”

It says that you need to conduct a penetration test, and the person conducting needs to have a clue about what a pentest is and how to execute one. Running a scan with impact and executing a pentest are vastly seperate excercises, and I would love to hear someone from Core try to refute this. Be forewarned though, I have an army of people with various colored hats, myself included, prepared to clue you in, deeply.

During the Q&A Bob never indicates that “reports produced by such technologies will be accepted”... by anybody. Instead, he reasserts that its not the SSCs job or interest to review any of these reports, and that the PCI assessor of record will be the one to review the reports and make a determination as to their legitimacy.

Frankly, if I were still a QSA and someone handed me a core impact report, I would suggest that the results of that report would make a very nice addendum to a real pentest report.

Core goes on further to suggest that Bob directly indicated that Core Impact reports will directly suffice PCI DSS requirement 11.3.

“confirmed that reports produced by such technologies will be accepted by certified auditors as proof of compliance with that portion of the mandate. The statement refutes some existing market misconceptions that DSS requires third-party penetration testing.”

Mike,  this never happened and you know it. See the transcript of your own interview for an example.

I can tell you that I listened to this entire 1 hour webcast in hopes of finding out what sort of disorienting malaria Bob had acquired so that I could recommend an appropriate physician and find out where to send the get well card. As it turns out, he has in fact not gone crazy, and he hasn’t said anything that even comes close to supporting the claims that Core is making.

Core Technologies on the other hand, is asserting that the SSC has somehow endorsed their product as being capable of directly sufficing a PCI requirement, and that my friends… is nonsense.