As you know, I pretty much constantly complain that noone ever does anything to inherently make better the state of data security when it comes to credit cards. The brands are always blame shifting, and merchants get left holding the liability bag and paying for everything.
Well, I'm not going to suggest that First Data has solved all of these problems, but what I will say is that I think they've put a stake in the ground with this new service. Their new, "Secure Transaction Management" service utilizes RSA's tokenization technology on the endpoints to minimize the usage of credit card data throughout the enterprise. Partnering with RSA on this product gives some credence to it. Merchants aren't inclined to trust a payment processor who makes claims about the security of a technology unless a trusted 3rd party gets involved and makes it so.
This obviously isn't my Utopian solution. I think card data needs to be public key exchange based, starting on the card. I realize that this makes me some sort of fringe lunatic thinker. However, given that wholesale changes at Visa aren't likely, First Data's STM seems like a pretty good idea.
The only concerning part of the press release was this:
"The service uses First Data infrastructure by storing credit card data in secure servers for future retrieval by the merchant if necessary, while returning tokens to the merchant for use in their systems, Capellas said."
There's still a certain amount of faith that this product places in the merchant to determine what is "necessary." People like to store things that they're not supposed to, and making the data available to them practically guarantees that they'll find a way to use it inappropriately.
That said, this is the first time I've seen a payment processor take an active roll in providing a product which has a security provision layer as a core part of the offering. Nice work guys.
One piece of advice:
keep an eye on those "secure servers" that store data for "future retrieval."
Wednesday, September 23, 2009
Tuesday, September 1, 2009
Social Engineering Implications - Improper Logo Usage!
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
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
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.
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.
Wednesday, June 3, 2009
Cardsystems (PaybyTouch) Suing Their QSA - Savvis
In a move that everyone seems to think is paramount, but in actuality was truly inevitable, a QSAC is being sued over delivering a compliant ROC to an entity that was compromised.
The only surprising part is that its Cardsystems. Right... the one you kept hearing about over and over, about 5 years ago. The Cardsystems board was forced to sell thecompany to PayByTouch Processing as a result of Visa taking the company off of VisaNet post-breach. I know this case all too well. I'm the one who did the follow up assessments post acquisition.
From the wired article:
"Visa executive told an audience earlier this month that the companies were not compliant, though auditors certified they were. “No compromised entity has yet been found to be in compliance with [the standards] at the time of the breach,” she said."
I love how Visa and the SSC keep sticking to their guns on this one even though everyone knows its a bag of BS. I even call it a bag of BS on the interview I did with exotic liability. Why is it BS? Because anyone canwalk into any merchant or service provider, compliant or not, and find 1000 little nuances that probably don't matter and use them interpretively to MAKE the merchant not compliant.
The bottom line here is that Cardsystems is going to drop this case. Why? Because they don't have one!
First of all, QSACs and QSAs have NO legal or contractual obligation to provide an accurate report. They have a moral responsibility to do the right thing. Big whoop. Secondly, I know for a fact that none of the people who were working at Savvis and were on this project are still there, and good luck rounding them all up. Thirdly - Cardsystems as a corporation is nothing more than a shell at this point. I'm guessing that the judge will see right through this feeble attempt at a cash grab for what it is... completely lame corporate behavior with no merit.
On top of all that - why would you wait 5 years to suddenly decide that you need to lay blame for your own crappy security infrastucture work on an auditing firm who's job it was to evaluate it for a 3rd party? Seriously, get a mirror. I've seen your network. Even in its repaired, remediated state, its not all that much to write home about.
Cardsystems - This suit is a joke. You're not going to win. Try to fade out of the media limelight slowly so that noone notices how lame you are. By the way - nice job laying off all the people who fixed your security problems as soon as the heat was off (Hi Kurt, Hi Joe). That was a really classy move.
Savvis - Bummer fellas. I guess the good news is that your company is bigger than theirs, so you'll win the standoff if that's what it comes down to.
The only surprising part is that its Cardsystems. Right... the one you kept hearing about over and over, about 5 years ago. The Cardsystems board was forced to sell thecompany to PayByTouch Processing as a result of Visa taking the company off of VisaNet post-breach. I know this case all too well. I'm the one who did the follow up assessments post acquisition.
From the wired article:
"Visa executive told an audience earlier this month that the companies were not compliant, though auditors certified they were. “No compromised entity has yet been found to be in compliance with [the standards] at the time of the breach,” she said."
I love how Visa and the SSC keep sticking to their guns on this one even though everyone knows its a bag of BS. I even call it a bag of BS on the interview I did with exotic liability. Why is it BS? Because anyone canwalk into any merchant or service provider, compliant or not, and find 1000 little nuances that probably don't matter and use them interpretively to MAKE the merchant not compliant.
The bottom line here is that Cardsystems is going to drop this case. Why? Because they don't have one!
First of all, QSACs and QSAs have NO legal or contractual obligation to provide an accurate report. They have a moral responsibility to do the right thing. Big whoop. Secondly, I know for a fact that none of the people who were working at Savvis and were on this project are still there, and good luck rounding them all up. Thirdly - Cardsystems as a corporation is nothing more than a shell at this point. I'm guessing that the judge will see right through this feeble attempt at a cash grab for what it is... completely lame corporate behavior with no merit.
On top of all that - why would you wait 5 years to suddenly decide that you need to lay blame for your own crappy security infrastucture work on an auditing firm who's job it was to evaluate it for a 3rd party? Seriously, get a mirror. I've seen your network. Even in its repaired, remediated state, its not all that much to write home about.
Cardsystems - This suit is a joke. You're not going to win. Try to fade out of the media limelight slowly so that noone notices how lame you are. By the way - nice job laying off all the people who fixed your security problems as soon as the heat was off (Hi Kurt, Hi Joe). That was a really classy move.
Savvis - Bummer fellas. I guess the good news is that your company is bigger than theirs, so you'll win the standoff if that's what it comes down to.
Monday, May 4, 2009
PCI Penetration Testing: Core Impact Lies.
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 fact,what Bob says is almost the complete opposite of this. Here is a transcription from the audio, starting at roughly 45:00:
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:
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.
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.
Tuesday, March 17, 2009
QSAs: SecurityMetrics in Remediation
Noone at SecurityMetrics had any comment on why the company was sent into remediation. As you'll notice, Chris Konrad from Fortrex kindly stepped up and posted the yesterday about the plan to remediate, and the company's committment to resolve the internal issues that caused the status change. Anyone from SecurityMetrics? PSC?
Monday, March 9, 2009
How to Choose a PCI Assessor
Choosing an assessor is a lot like choosing a car. Some of them get you there quickly, some of them are reliable, and your mileage may vary. There are a number of factors to consider, including:
Ask to See Your QSA’s Resume
There are A LOT of people in the information security space, and their backgrounds vary pretty wildly. Make sure that you are comfortable with the skillset of your assessor, his or her work experience, and their knowledge of PCI. Also, make sure that the person who shows up is in fact the person who’s resume you reviewed. You may want to interview them as well to insure that they have a knowledge level that you're comfortable with.
Talk to other Merchants
There are people out there who have gone through this multiple times, and have probably used more than one assessor. Ask them what they thought about the assessor meeting their expectations in terms of technical abilities, and delivery timeframes.
Timeframe to Completion / QSA Availability
What is sales willing to commit to on paper in terms of having an assessor at your facility? How long will the assessment take? The answer may surprise you. If you’re a level 1 service provider, and they’re only going to spend 3 days reviewing your security controls, you may want to keep shopping. On the other hand, if its going to take 6 months to complete the assessment, that's probably less than optimal as well.
Your assessor should be able to start within 30 days, and given that there are 200+ requirements that need to be answered for with interviews, observation, and direct evidence gathering, the process will take some time. For an average level 1 merchant , 60-90 days is a reasonable expectation if you've been through the process before and are prepared.
Perform a “Pre-Assessment” Yourself
Understand what the scope of your environment is, and try to anticipate the results of your assessment. This will allow you to speak to the issues with confidence. In the event that you disagree with your assessor on a particular technology or architecture, you’ll be able to defend your position on its deployment without having to use your bank as an intermediary.
(Shameless Plug: We help a lot of people with this.)
Talk to your bank
Do they have a solid reputation with your acquiring bank and/or the card brands that you work with? Banks have to review a lot of scan reports, ROCs, and self assessment questionnaires. They see the cumulative results of many different assessors, and can provide you with valuable input as to who has delivered consistent, quality assessments. On the other hand, some assessors have a practice of "partnering" with banks, and those banks use that assessor as their "preferred assessor," making the recommendation somewhat worthless, because the answer is always the same, irrespective of the situation.
Thursday, March 5, 2009
QSAs: PSC and Fortrex First to Go Down in New SSC Quality Assurance Program
Neither the principals of PSC (Payment Software Company) or Fortrex, Inc. (both Qualified Security Assessors) had any comment when asked about why their companies were put on probation by the PCI Security Standards Council in late January.
Both companies appear to be lacking the appropriate work papers that are required as supporting documentation to PCI assessments. All QSACs were told about the SSC reviews of work materials in July of last year, so unless they just weren't collecting or keeping their evidence, i'm unsure how you would screw up this badly. Maybe they didn't believe the QA program was real?
What will be interesting to see is whether or not they are able to recover from this. I suppose that if Trustwave can be the assessor of record for 2 of the 3 most major breaches in world history and noone wants to talk about it that these guys will be fine by next quarter.
Both companies appear to be lacking the appropriate work papers that are required as supporting documentation to PCI assessments. All QSACs were told about the SSC reviews of work materials in July of last year, so unless they just weren't collecting or keeping their evidence, i'm unsure how you would screw up this badly. Maybe they didn't believe the QA program was real?
What will be interesting to see is whether or not they are able to recover from this. I suppose that if Trustwave can be the assessor of record for 2 of the 3 most major breaches in world history and noone wants to talk about it that these guys will be fine by next quarter.
Subscribe to:
Posts (Atom)