Celebrate from the mountain tops! Visa got some RSS! Hopefully they will be dutifully (or have scripts) updating the feed, unlike the PCI SSC's feed (which currently does not include their latest skimming guide) that traditionally lags behind. RSS is a GREAT way to keep your stakeholders in touch with your programs, but you really do have to stay on top of it!
FINALLY! An official statement from MasterCard! Last night, MasterCard posted a four page FAQ on their website to help us deal with the onslaught of buzz that came from their original posting. Some of it anecdotal and humorous (albeit literally true), some of it from this very blog.
Here's the meat of what you need to know:
Time will tell, but in order for MasterCard to avoid something like this in the future, they really need to communicate better to ALL of their stakeholders, not just their members. All it would have taken is a quick run of the new program by a few key outsiders to point out some of the issues that have been addressed above, thus re-framing the new requirements and avoiding this mess.
Don't worry, you don't need to tear up your existing compliance assessment. Troy Leach recently alerted the world, via press release, that PCI DSS version 1.2.1 is now the most recent version of PCI DSS, though he states, "As there are no changes to the intention or requirements of the DSS, your compliance programs will be unaffected by the change from DSS 1.2 to DSS 1.2.1."
This change is minor in nature, and does not constitute a new version per the PCI Lifecycle document released earlier this year. Most of the changes are typos or alterations in the document, some based on new policies or fees.
Let's walk through the changes.
Three documents were modified with this new version. For PCI DSS, the following four changes were made:
As many of us in the industry had suspected, Visa has delayed its payment application security mandates two years to 2010 (newly boarded merchants) and 2012 (all merchants). The information was officially released on June 24, but I certainly did not see any public reference to it until recently. This is rumored to be largely in response to a low supply and high demand issue in the fuel industry.
So those of you that were dealing with unrealistic deadlines, you've got a reprieve! Keep pushing though, don't be one of those guys limping in at the eleventh hour!
On Monday, I told you all about a MasterCard fine schedule but I was unsure on when it was going to start. Well, as it turns out Level 2 and 3 merchants are being fined NOW, not sometime after the December 2010 date.
That's right, some Level 2 merchants have already received their first $25K fine from MasterCard under their new fine program. Apparently, that's how many of the acquirer's found out about the program!
OK, SOMEONE out there has some explaining to do. Like, right now. Who poked MasterCard hard enough to wake them from hibernation?
When it comes to actions against merchants, MasterCard has typically been much quieter than Visa. We've had several customers come to us with new fines from MasterCard that will begin sometime in the next 18-21 monthsNOW.
Why the ambiguity? None of our customers seem to have a date when the fines start! This is a huge assumption here, but I will suggest that the fines would start after the 2010 deadlines for Level 1 & 2 merchants.
Revisiting those deadlines, Level 1 & 2 merchants must produce a Report on Compliance from a QSA by December 31, 2010. Non-compliant Level 1 & 2 Visa merchants are currently being fined under the Visa Compliance Acceleration Program (CAP) as follows:
Level 1 & 2 merchants will be treated the same. We already know they are the same from the new reporting and validation requirements, but they will also be the same from a fine perspective! Level 3 merchants, currently NOT fined by Visa, will also be subject to fines (though in a much smaller amount than Levels 1&2). My understanding (though their appears to be some question about this) is that these fines are assessed quarterly until compliant1.
MasterCard rolled out another change to acquirers as well, and require newly boarded Level 1 & 2 merchants to provide a compliant ROC from a QSA before they are allowed into the network. So those Level 2 merchants that have been changing processors every year, it finally caught up to ya!
None of this information is published on the MasterCard SDP website, nor was I able to get this information directly from MasterCard, so your best bet is to contact your acquiring bank to understand how this new policy from MasterCard will affect your business.
_________________________________
1 OK smart guy, I know what you are thinking. What happens in Quarter 5?!? Again, this seems a bit unclear but it appears that the fines reset to the lowest amount and continue their normal escalating procedure.
The following is a guest post by Bindu Sundaresan, a consulting manager in our Risk & Compliance consulting practice.
With the current "non-stimulating" economy, there is a lot of talk about the "stimulus" bill which is impacting all areas of the US economy. One such impact is the reason for today's blog post.
A portion of the new economic stimulus bill, called the Health Information Technology for Economic and Clinical Health Act (the "HITECH Act"), will have a significant impact on Health Insurance Portability and Accountability Act of 1996(HIPAA). This new law revives HIPAA (which has been around for over a decade), but has many a time gone unnoticed/ not strongly enforced, and no incentive to comply, amongst the other regulatory demands.
Changes to HIPAA become effective one year after the enactment of the HITECH Act—February 17, 2010—but proactive actions have to be taken by healthcare providers and their partners in order to comply with the new law.
There is the need for some reworking and rethinking by "covered entities" and "business associates"- the terms that HIPAA created for the parties dealing with health information.
"Covered entities" include physicians, hospitals, health plans and health care clearinghouses, who store, process, or transmit health information.
"Business Associates" are those who use health information to perform services on behalf of a covered entity, such as legal, accounting, consulting or administrative work.
Highlights from the HITECH's impact on HIPAA:
It's been a little over a week now since MasterCard tool the PCI world by surprise and changed their reporting requirements for Level 2 merchants. Whether you are currently a Level 1 or Level 2 merchant, these changes affect you. Here's the summary and rundown.
MasterCard posted a change to their Site Data Protection program that requires Level 2 merchants to use a QSA and perform an on-site assessment before December 31, 2010. In addition, Level 1 merchants that were previously self-assessing may not self assess anymore, and must use a QSA for their PCI Assessments. This is a dramatic change from the current, industry wide requirement of self-assessing for merchants processing less than six million transactions annually, and allowing merchants that process more than six million transactions annually self assess if they choose.
So far, none of the other card brands have changed their status; however, if you have a business unit defined as a Level 2 merchant with any card brand, you are automatically a Level 2 with MasterCard and are now required to have an on-site assessment. Below are a few clarifying points around the change to the levels from an inside source.
Parts of this may not be as relevant to some Level 1 merchants, after Visa clarified their expectations of what makes up a Level 1 merchant earlier this year. If you are a Level 1 merchant in one country or region, and are also a merchant of a lesser level elsewhere in the world but share data with (or are connected to) the Level 1 merchant operations, all operations should be treated as a Level 1 and reported that way.
For example, Garrett's Gas Guzzling Garage operates 800 car repair locations across the United States. Garrett's recently opened twenty locations in Mexico City to help maintain and upgrade the fuel efficiency of older cars with a patented fuel particalizer. Even though the twenty Mexico locations process through Bancomer locally, the data is shared with the US Headquarters for settlement, reconciliation, and analysis. According to Visa's rules, the Mexican entity is considered a Level 1 based on its relationship with the parent, and a Level 1 assessment must be performed.
When in doubt, always ask your acquirer(s) what is expected of you. Some acquiring institutions may still treat certain subsidiaries as lower levels depending on the circumstances.
Regardless, your PCI Team is ready to assist you with any new PCI needs that you may have! Click here to email us to get in touch with one of our seasoned QSA consultants!
Don't write Savvis off yet! Dave Navetta posted an update to the Merrick v. Savvis case that every QSA is closely watching. Savvis filed a motion to dismiss in response to the lawsuit.
I'm not a lawyer, but I'm glad David is. He explains the reasoning, and even mentions that Merrick's potential procedural error (or end-around) could get this case dismissed before the substantive merits of the case can be explored, thus continuing to leave the world in the dark about more potential liabilities involved with performing PCI Assessments.
Go check it out!
Javelin Strategy & Research posted an update to the new MasterCard Requirements. After speaking with John Verdeschi, Robert Vamosi pointed out an error in our initial analysis. After re-reading my material, I looked at one piece of information and made a leap (incorrectly) about the intent.
John clarified that the intent is to use the next eighteen months as a transition period. Level 2 merchants should both submit a SAQ, and also have an On-Site assessment completed so they can submit a Report on Compliance by December 31, 2010.
This means that Level 2 Merchants effectively have eighteen months to complete a readiness assessment, remediate, and validate compliance.
Sorry for the confusion folks, and thank you to Robert & John for setting us straight!
VeriSign is sending a consolidated information briefing on this update with some special discounts on our consulting services for Level 2 Merchants. If you don't get your copy of this alert by Friday, please email me so that you have the information needed to get the discount!
You've probably heard about it by now. Thanks to a friend doing business in Nevada, I was alerted to this new law last week. Nevada is now the second state to enact laws requiring companies to comply with PCI (though, arguably, the Massachusetts Identity Theft Prevention Regulations seemed to have been lifted at a high level from PCI), the first being Minnesota.
David Navetta has a great analysis from a legal perspective, and Chris Mark published his thoughts as well. One thing that is interesting about the Nevada law is an apparent Safe Harbor provision.
Will this added pressure force more religious views on payment security and compliance inside companies? Or will companies continue to roll the dice with their compliance?
You decide!
On Wednesday, we discussed MasterCard's new requirement for Level 2 merchants to have an on-site assessment performed instead of submitting the Self-Assessment Questionnaire. This news prompted a flurry of information around the new requirement and has merchants asking lots of questions.
I clarified a couple of items from my last post and wanted to make sure they were clear.
Thanks to Smiley for the tip!
MasterCard has posted a change to their Site Data Protection program that requires Level 2 merchants to use a QSA and an on-site assessment. This is a dramatic change from the current, industry wide requirement of self-assessing for merchants processing less than six million transactions annually.
While this is definitely going to put a dent in Level 2 merchant budgets from this point on, I truly believe that this is a smart move by MasterCard. Level 2 merchants are extremely significant in size, many of which being household names. Unfortunately, PCI self-assessments are typically poorly handled simply due to the complexity of the standard and lack of training provided to those individuals performing the assessment. When our folks are contracted to review these, we typically find that a previously fully in-place Self Assessment Questionnaire is only about 70% accurate. Meaning, that 30% of the items answered "Yes" or "N/A" are actually "No."
So far, none of the other card brands have changed their status.
It's unclear if others will follow suit, but regardless, if you are defined as a Level 2 merchant with ANY card brand, you are automatically a Level 2 with MasterCard, and are now required to have an on-site assessment.
I hate to be a cynic.
OK, fine. SOMETIMES I get secret enjoyment out of being a cynic. Kind of like the enjoyment of making fun of someone in a way that they don't know they are being made fun of. Or that satisfaction of eating candy from your kid's Halloween stash knowing they will never miss it (unless your kid is Ms. KJ... you know who you are, you little Halloween candy auditor you...).
The NRF and others "ganged up" on PCI yesterday by sending a letter demanding easier treatment under the standard. I understand the intent, and applaud them for sending the letter across. While there may be a valid point or two buried in there, I think this is a sad day for Merchants.
I have said many times before, PCI is NOT the scariest thing out there. Savvy merchants have figured out how to win within the rules as opposed to digging their heels in like my 4 year old son when it's time to go inside, running down the sidewalk screaming NOOOOOOOOOOOOOOO. Savvy merchants know that these rules, while a little bit broad reaching, can help them solve OTHER security issues, and help their company realize that security is much more than dealing with fraud & shrink.
These merchant associations only represent a vocal minority among their constituency. Most merchants I deal with really want to get security right, and have conceded that if it has to start with PCI, then that's where it has to start. There are those few that fight you tooth and nail on every single requirement, pushing for a ruling that gets them the easiest pass with the fewest amount of dollars spent. Unfortunately for QSAs, they are also the most likely to be breached, and the ones that will turn on you in an instant, throwing you under the bus.
As another industry expert said (I can't remember who to attribute it to), "It's a scary time to be a QSA!"
Luckily for our customers, we take a partnership approach versus an audit approach. Our customers love the collaborative process that our assessment takes, and understand the value and cost of information security.
If you are a member of these associations and are unhappy with the direction they are taking, I urge you to speak out! Breaches involving PII are much more costly and dangerous to the longevity of the business, and without PCI to raise the general information security flag, your business is next!
Do you remember debate or speech class? I remember having a professor assign me the counterpoint position on an issue in which I didn't agree. I always thought that the other guy had it easy if our beliefs were the same because he already believed what he was saying.
I recently read an article by Ariel Silverstone in CSO Magazine entitled "Where PCI DSS Still Falls Short (and How to Make it Better)" in which Ariel seems to have been put in a similar situation. Either she was asked to publish something (anything), or asked to specifically publish something on PCI; regardless, she should have spent a little bit more time on research than she did. After reading her positions, I'm pretty sure she didn't ask any QSAs (or anyone that have been in the industry for more than a few weeks) for assistance during her research phase.
After reading the article, I felt cheated. I picked up the text thinking that I would find some insightful points by a former consultant and current professional affected by PCI. Instead, I was subjected to an article that set up the shot but didn't follow through.
Her first points are definitely on-point, if not historical in nature. The first thing I have to take issue with is her comment on scoping and comparing PCI DSS to the SAS 70 Type II (note: not type I). While you can carve out specific scope for PCI and validate it like you would a SAS 70, that's not necessarily a bad thing. Sometimes that is required for a business to do depending on how they are set up. It's up to the enforcement entity that accepts the Report on Compliance (i.e., a card brand or bank) to decide if it meets their requirements. Companies that do IT hosting and management require this kind of flexibility, otherwise they would be forced to apply PCI to all of their customers.
Ariel suggests splitting up the requirements, but it is clear to me that she didn't read past Page 3 of the PCI DSS. While in some cases you could extract the top level requirements (particularly the short ones), it is unrealistic to simply group top level requirements together. For example, some elements of Requirement 11 can overlap with Requirement 6, and others should potentially be found elsewhere in the standard. Making blanket statements about the top level requirements is a dangerous game to play.
Next she talks about the concept of segmentation. PCI DSS does not require segmentation, but if you have a diverse network, it is highly recommended to reduce scope. She takes the concept of segmentation and applies it to requirement 6.1 (ok, I guess she did make it past page 3, I stand corrected), further questioning the rationale of thirty days vs any other number of days.
Part of making a standard is that you have to draw a line in the sand SOMEWHERE. Otherwise you will have people asking those kinds of questions versus actually progressing toward a goal. The point is to patch systems quickly, or to at least mitigate the risk such that the vulnerability could not be exploited (say by removing a .DLL file. Thank YOU .art vulnerability!).
The next one is a common mistake made by many professionals--including QSAs. The old One Function Per Server requirement (2.2.1). Proper virtualization can be used (including with mainframes) to allow multiple functions in the same piece of hardware while meeting the intent of the requirement. She says she was not aware of any research that proved this requirement reduced the risk associated with breaches. I've not looked for it, so I'll assume it doesn't exist. Regardless, any certified security professional will understand the concept of an enclave, and knows that proper access controls must be put in place to prevent a vulnerability in a DNS server leading to a dump of customer data. I've been calling that an "intrusion path" for years. It's the concept of many successful complex attacks. I compromise X on one server, which leads me to access Y on the same server, which then leads me to Z on another server, and so on.
It's just plain riskier.
The next suggestion (4 if you are keeping score), along with content in Suggestion 7, illustrates Ariel's lack of experience in the PCI world. Suggestion 4 discusses requirement 3.1 and the somewhat contradicting concept of keeping the storage of cardholder data to a minimum while using business, legal, and/or regulatory purposes to define what is stored and for how long.
One thing I've learned about people is that they are much less likely to stick with an off position if they are forced to write it down--especially in public companies where documentation like that could become part of legal discovery. Instead, we have conversations over the phone or in crowded coffee shops, confident that never writing it down will allow us to slip by undetected if something bad happens. I personally believe the intent of this requirement is to force businesses to write down their retention plans, see what they look like on paper, and adjust if necessary. I can't tell you how many times I've been told that data must be retained for ten years, only to have the same person come back to me in a week to deliver a scaled back version of the stance on paper.
Suggestion 7 screams "outsider with a lack of experience." I remember sitting in difficult meetings in 2004 getting yelled at by all kinds of executives because I was telling them how to run their business. You can't go from zero to eleven in a matter of minutes (unless you are Spinal Tap of course); you have to ease your way there. If the PCI Council saw fit to require internal encryption in the next version of the standard, I firmly believe there will be a revolt.
If you are not encrypting at least some internal communication of data you deem sensitive, you have a lot more faith in the security of your satellite offices than you probably should. Ever walked into a retail store only to see the system room door wide open? Do you think the corporate data center door is also wide open (hint: it's not, and usually surrounded by lots of security)? I'm not saying that we should encrypt everything, but that is one we should leave to the merchant or service provider to decide.
Oh, and I'm pretty sure that FTP or "automated tools" are not the same as "end-user messaging technologies." And no, it is not OK to send unencrypted data over the internet with FTP.
Skipping back a bit, Suggestions 5 and 6 are a little odd to me. Flexibility will allow for companies to deploy something that is best suited for their environment. The standard used to suggest TripleDES and AES as two encryption algorithms to be used, but there are plenty of other algorithms that are considered strong (if not stronger) that are acceptable. For example, Two-Fish is a fantastic algorithm (implemented correctly of course), and should be allowed on PCI related systems.
Final thought on that suggestion, the PCI Council should NOT be accepting legal risk for mandating particular encryption algorithms or key strengths. She points out why with the Zimmerman reference. Every company should do their own legal analysis to determine the best course of action for them.
I think you should read her article and form your own opinion, but I view it as a slightly embarrassing show peppered with valid points here and there. A prime example of why you should fully research a hot topic like PCI before publishing a "thought leadership" piece.
David Navetta published a fantastic article in this month's ISSA Journal entitled, "Who is Minding the Legal Risk around PCI" that takes a deep dive into the legal ramifications of not complying with the standard. If you do not get the journal, first off, go join the ISSA! It comes free with your membership!
In the meantime, jump over to David's blog to read the article! Towards the latter part of the article, David lays out two very real risks that I have discussed many times in this blog such as QSA shopping, rubber stamping, and scoping.
Enjoy, and have a great weekend!
I'll admit, I'm not the insomniac whose brain refuses to shut down because of something like a skimmer. They do scare me. Less from a personal liability perspective and more from a corporate liability perspective.
Have you ever seen a real-life example of an ATM that has been doctored with a skimmer? Today is your lucky day! One Gizmodo reader submitted his pictures and story.
Maybe I'm crazy, and maybe it's just not that big of a deal anymore. The bad guys are getting very crafty now, and able to fit skimmers to specific ATM models. It used to be that if you used an ATM regularly, it would be very easy to tell if someone had tampered with it. Stray wires, duct tape (NOT DUCK TAPE), odd cameras or mirrors, all of which should be red flags to any user of that magical machine that makes you feel like you win every time you play with it!
Remember those old "fake ATMs" that were essentially just big skimming devices? I think many of us became wary of the generic ATM machine in a parking lot after that. But we're not talking about that here. We're talking about the ATM near your house that you visit every week, and you may not even be able to detect it!
At a minimum I would suggest that you disable the ability to withdraw funds from anything but a checking account from an ATM. Hopefully that should at least minimize the amount of money you would be out if you fell victim to such an attack. Any more suggestions than what is above might stray into the personal finance realm, and I'll let those guys blog about that!
If you missed it, you can see a recording here! See what the Twitterverse had to say here by searching for #pcihearing. TONS of coverage on this.
First, I am very proud of our congress for putting this hearing together. It is clear how serious this situation is when listening to the prepared, pointed statements read in the beginning. I hope I don't make anyone upset, but I do giggle a little bit when non-techie folks trip up on techie terms. I certainly expect someone would giggle at me if I were reading a statement of detailed medical terms and missed the words. Regardless, huge props for taking the issue on.
In the next paragraphs, clicking on the individual's name will bring up their prepared, written transcript that is summarized in the briefing.
After the opening statements from Chairwoman Clarke and Chairman Thompson, Ms. Rita Glavin, Acting Assistant Attorney General, Criminal Division, Department of Justice spoke about her experience with card breaches and investigations. The committee had a few questions for her, but I don't see a written transcript for hers or any of the later testimony. I'm pretty sure they had someone taking the entire text down, but I don't see it posted.
Next, they welcomed up the next group of folks, starting with Bob Russo, General Manager of the PCI Security Standards Council. Bob did a good job of explaining what PCI is, and how the PCI DSS, PA-DSS, and PCI PED Standards work to protect cardholder data. He also re-iterated Visa's general statement from earlier this month that no breached entity has ever been found to be in full compliance with the PCI DSS.
Up next, W. Joseph Majka, Head of Fraud Control & Investigations. His statements touched items such as the VISA Compliance Acceleration Program that is fining merchants today, and how VISA cooperates with law enforcement to assist in the prosecution of the bad guys. He also discussed the removal of RBS Worldpay and Heartland Payment Systems from the CISP Compliant List of Service providers. Looking back on it, I wonder if that action was done knowing that this hearing was on the horizon.
Following Mr. Majka was Michael Jones, CIO of Michael's Stores. One of his statements was a little odd to me, the whole security policy question. I think that has been addressed by the council in the FAQ. If not, it has been discussed at length in various areas, and I believe he would have gotten a good answer from the Council if he submitted a question.
Mr. Jones also brought up the chargeback thing, and I'm really struggling with this. Unique approval IDs exist for every card brand as of last year, and we have been able to get EVERY one of our customers processing chargebacks from their banks WITHOUT storing the full PAN (yes, Hogan references this in his statement too... ugh). Next he makes an incorrect statement that PCI requires card data to be encrypted. PCI requires card data to be rendered unreadable, encryption being one of the many methods that can be implemented to accomplish this. His points on sending encrypted info to the bank is well taken, but again, he might need to push hard on his acquirer. Many acquirers or processors offer this. You can also protect card data in flight without dealing with acquirer specifics by using site to site VPNs or SSL tunnels.
Next, he insinuates that end to end encryption would have prevented several prominent breaches. I'm too close to those matters to say definitively on this blog; however, one point I will make is that end to end encryption only works if it is truly end to end. Internal network encryption that does not start at the PED has a great shot of being vulnerable to attack. How? We're seeing attacks where hackers upload debugging software to POS controllers, or even terminals, and scrape memory. This means that they can see the information before the encryption routine occurs. Uploading this type of software to a PED device is much more difficult (if not impossible) to do, that is why the encryption must happen there.
Next, Mr. Jones talks about how SOX covers PCI. Some cases, yes, but not in the way it was presented. He makes it seem like SOX & PCI are big duplicates.
His next point talks about how the merchant ends up holding the bag in a breach scenario. He is absolutely correct here. What he fails to mention is that the merchant MUST comply with other regulations, not just PCI, and that it is the merchant's choice to either 1) be responsible with the data they have, or 2) stop accepting credit cards. I know several merchants who have stopped accepting cards, or completely outsourced the processing of cards for this very reason. Sure it costs more, but think about it. That's the compliance cost right there. Now you are not holding the bag, especially since I believe there is little or no brand damage suffered by a retailer caught in a breach.
Retailers DO have the largest financial impact, especially from fines from ADCR (Visa) or other recovery methods. Wow, he called the card brands Card Monopolists!
Next, Mr. Dave Hogan, CIO of the National Retail Federation. Ahh, Dave, Dave, Dave... I had really high hopes for his statement after he started off with some fantastic points. Maybe he fired his old writer? I won't summarize everything, you can watch the video.
But then the propaganda started coming out. I disagree with his point about the standards constantly changing. They change on a set schedule of every two years, the last one actually relaxed several requirements from PCI DSS 1.1.
I want to point something out here... The "game is always changing" mode of thinking is ALL RELATIVE. I've seen merchants move mountains when it comes to reacting to the market, such as standing up stores in record time, moving products that are virtually guaranteed to sell to the front of the store, and slashing prices to compete with the down-the-street guy. Taking two (or more) years to implement a standard is certainly telling of where the focus is when you think about how quickly some companies react to market conditions.
It's all about the mindset.
Lots of finger pointing here for sure from the merchant side, but arguably they have the most to lose.
Will PINs solve Hogan's point number 2? No. The same systems are used for Credit & Debit, and companies will continue to expose the system's flaws by storing said PIN data and having it subsequently breached.
I'm not going to summarize the entire Q/A, you need to watch it. Suffice to say, GOOD stuff in here. A couple of highlights...
Mr Lujan did miss one point that Bob was trying to make. In the fire inspector example, Bob was revealing a potential issue that can occur in how companies become compliant, maintain compliance, and potentially suffer a breach. Mr. Lujan pointed to the QSA (he used the term regulator, which can definitely be a problem), while Bob seemed to point to the merchant (which can also be a problem).
Hogan also did his whole thing about merchants being required to store cardholder data. I've said it before, this is total hogwash and I still can't believe that he is spreading this nonsense. Every customer of ours has been able to address this with their acquirer such that they are not required to store this data.
Mr. Jones hits it right on the nose in this interchange. Merchants MUST work with their acquirer to accomplish this! If the acquirer is not doing their job properly, maybe it's time to change to an acquirer that will (WHO MOVED MY CHEESE!??)!
One thing that I'm really worried about... Let's say that the card brands "fix" the system, and make it hack proof. What will the bad guys attack at merchants next? If you want to look at the two competing problems here, problem one is that the payment system IS insecure. I don't think you will find anyone that will disagree with that. Problem two is so much worse... many corporations are ALSO insecure!
Mr. Hogan mentions that companies replaced good security programs with new programs to cover PCI. PCI is NOT a security program, and was never meant to be one. That said, I would challenge Mr. Hogan to show me a good security program, pre-PCI, that is better than what merchants and service providers have now, post-PCI. If the old program was good, but replaced because of PCI, the company doing the implementation missed the mark.
Bigtime.
Regardless of the outcome, this was an extremely productive session, and I hope to see more testimony and more written statements from the committee and witnesses on this subject. I think that all of the panelists (yes ALL.. every one of them) showed a great amount of courage today standing up in a session like this and discussing serious issues with payment security, and I only hope that this leads to a better understanding of data and payment security.
You can be a victim, or you can be the victor. The path is up to you.
The following is a guest post by Frank Castaneira. Frank is a Sr. Consulting Manager inside the Global Security Consulting practice at VeriSign.
Matt Hines recently wrote about the PCI Council discussions on applicability and adequacy of the PCI Standard given reported breaches of validated entities such as Hannaford and Heartland. Branden recently discussed the PCI Council conversation on March 6. Branden suggested greater visibility by the Council into the incident response process. This posting amplifies on that solution and provides other perspectives.
The discussions mentioned in Mr. Hines article focused on the QSA (Qualified Security Assessor) posture that an annual on-site assessment is relevant only for that point in time. Although, I recognize the issue (point in time), my experience tells me that the real case in these breaches is that the entity really wasn't "compliant". Yes, a QSA attested to that compliance, but I bet the breach exploited a vulnerability (or multiple vulnerabilities) covered by the standard, and should have been caught by the QSA.
Of course, one cannot exclude the following scenario as possible:
Administrator (insider) is seduced by someone with connections to overseas organized crime. During the encounter, Administrator removes the private key-encrypting-key from a company safe. Encryption scheme is then exploited and the ill-gotten data is sold or transferred to a crime ring.
The previous example is purely fictional and designed to illustrate a point. The PCI standard is not perfect, nor will it prevent all forms of cardholder fraud. It is; however, a solid security baseline when validated through the eyes of a good assessor with a competent and quality-minded program behind him. Adherence to all the requirements will significantly lessen your risk-footprint, and practically eliminate the statistic of breached compliant entities. Note that organized crime feasts on the easiest kill, and compliance with the DSS builds a fence that is unattractive in comparison with other targets in the wild.
If the source of recent compromises becomes part of public record, my wager is that obvious errors and omissions by the QSA will be revealed. Although, all QSAs are required to take annual training and must pass a certification test, only very few create robust assessor programs that include peer reviews, significant onsite interviews, and data collection, and collaborative forums to discuss grey areas.
It is also important to acknowledge the client's quandary as they followed the rules. Level 1 Merchants and all Service Providers must use an approved assessor from the QSA list. Aren't all assessors the same; at least in PCI Council's eyes? If client picks an assessor from the list using any of the following criteria such as existing relationships, geographic proximity, or best price, then what could be the downside?
So enough of my competitive pandering; here is what I propose as a potential solution to improving the reputation and significance of the DSS.
Access to Investigations
As identified by Branden, the PCI Council is not currently an active participant of the breach investigative process. The Brands, sponsor bank, compromised entity, law enforcement, and of course, the assessor (Qualified Incident Response Assessor) are the only parties typically involved. The final incident report must include a section on PCI compliance status. This is more than just a checkbox on whether someone previously attested to their compliance, but a rather cursory review by the QIRA of all twelve DSS requirements (mini on-site assessment). This section is particularly important to the Council in determining whether the original assessment was properly performed. However, the content of the report is not typically shared with the Council.
The Brands do have visibility and influence into the PCI Council, but the Council deserves an earlier warning of new threats that may influence the DSS, and immediate feedback on sub-standard assessments that may have prevented the fraud in the first place.
The Council already shares NDAs with the Brands, and as the QSA licensing body may leverage its authority to place one under remediation (same as with its QA program). If the errors on the assessment contributed to the actual compromise and it was more than a lapse in point in time, then the Council should enforce its charter and discipline the QSA as necessary. This may weed the field of uncommitted QSAs, but will definitely heighten the thoroughness of those who decide to offer their clients the expert risk protection they were sold. This will allow a footnote or parenthetical on any new statistic involving compliant breaches (attested by a QSA in remediation).
Last night, Visa, Inc. collected a list of dates for upcoming compliance and published them on their website as "Key Dates." If you ever wondered what dates you needed to hit for Visa, Inc., they are all listed right there!
Some of the dates are news to this blogger, so it's nice to see something official and published, not just things we hear through the grapevine or by talking to various pundits in the industry. The next deadline they list is on March 31, U.S. Level 1 and Level 2 Merchants Prohibited Data Retention Attestation Deadline (applies to newly identified Level 1 and Level 2 merchants late 2007 and early 2008).
Were you planning on returning to RSA this year but were caught in a RIF? RSA wants to help!
They recently announced a scholarship opportunity targeting unemployed security practitioners that have recently attended the RSA conference. In order to receive this scholarship, you must:
Thankfully, no video submissions are required.
For more info, go here: http://www.rsaconference.com/2009/us/scholarship.htm.
You've probably seen the story by now... it's out there. Here is one link, and you can likely find MANY others.
Here's my question. If they are taking them off the list versus leaving them under review, are they saying that they never should have been certified in the first place? And if they are saying that, doesn't this mean they are declaring shenanigans on the review by the QSA of record? Do I sense a trickle down effect here?
Sometime over the last two days, the PCI Security Standards Council released their Prioritized Approach guideline for implementing PCI v1.2. Go download it and take a look.
This document is probably useful for a merchant who has never heard of PCI. It details the priority they believe merchants should assign to every PCI Requirement and places them in to one of six buckets. For those merchants and service providers that are currently working through their gaps, or are already compliant, this spreadsheet will probably not be useful.
The danger with this document is it makes sweeping assumptions that every organization is the same, and therefore should prioritize the same. The provided spreadsheet is locked, so if you want to customize it for your organization you must do a select all, copy, and paste into a new document.
Any tools that merchants or service providers use to assist in their remediation planning or execution must be customized to their organization. The tool has a nice framework, but you should not use it out of the box without modifying it to match your organization. It's missing the testing procedures that QSAs use to identify gaps, which is probably something that your teams will want to see to ensure their actions will result in a successful passing assessment.
Something like this should come out of a compliance readiness assessment and mention specific gaps that are found in the environment, with corresponding remediation activities and teams responsible for completing the actions. Regardless, it is worth a look to see if it is something that you can use to assist in your remediation efforts.
VeriSign provides something similar to this. If you are interested in this sheet and want a copy, please shoot me an email and I'll see if I can wrastle the documents out of Levinson & Springfield's hands to send your way!
I'm too tall to even come close to pulling off Joe Pesci. So just think about the scene in Goodfellas where Tommy DeVito is pulling Henry Hill's leg in the restaurant.
How am I funny?!
Anyway, if you are looking at my blog and you see a little badge on the upper right with a link to the Social Security Award and are wondering what that funny business is, I'll tell ya! The Security Blogger Meet-Up at RSA is coming soon, and they are going to have some awards this year! There are five awards that will be given out. They are:
So, if you think I am funny, follow the directions at http://www.socialsecurityawards.com/ and tell them! Or if you think I am totally un-funny, tell them that too! You don't have to vote for every category, but if you have the time and can think of a blogger to put in every one, consider throwing that blogger a virtual bone by voting for him or her!
Are you one of the many companies that rely on satellites to communicate with your, uh... satellite offices? We security professionals often ask hard questions about how that data is protected en-route and usually are quickly dismissed with a "Oh, it is too hard to do and would require a six-figure investment in hardware to accomplish."
Well, thanks to Adam Laurie, you can do it for around $1,000!
If you are relying on satellite communications, you should now be asking those hard questions of your provider, and making sure that you have acceptable encryption on those lines preventing someone from intercepting or injecting traffic into that stream.
It's official, I was selected as Payment Security Professional of the Year by the Society of Payment Security Professionals!
The Society has gained a ton of momentum in the industry and launched their two excellent certifications, the Certified Payment-card Industry Security Manager (CPISM), and Certified Payment-card Industry Auditor (CPISA). If you are looking to get into this industry, or work for a company subject to PCI compliance and have responsibility for PCI, you should have these certifications.
This training is better than the training that we receive as QSAs for a few reasons, but mainly because it covers a much wider base than just PCI-DSS. Anyone that has heard me speak about the negatives associated with a breach and/or non-compliance has heard me say that PCI is not the scariest thing out there. The training covers those scarier items in addition to the basics of PCI.
Thank YOU to all that nominated me and thank YOU to the board for selecting me! I am extremely flattered to be selected for this award!
I'm not Seth Meyer. I'm not a television star. I don't have a team of writers feeding me stuff on cue cards.
That said....
According to an article by Fred Aun, Peter Alguacil from Pingdom released a report recently suggesting "there are probably 219,000 sites with outdated SSL certificates."
Probably.
Fred, who rounded the original 219K figure from Peter up to 250K in his posting, goes on to describe the "bit of math" that Peter used to come to this conclusion using data from two different sources. First, Netcraft estimates there are one million sites with valid SSL certificates. Next, a report by Venafi released in 2007 suggests 18% of Fortune 1000 sites had expired certificates. So then Peter does the math and says that since Netcraft does not count invalid certificates, if we were to estimate 18% of one million, we'd probably end up with 219,000 sites.
That sounds a lot like the math we used to get in the venture capital world during the Dot Com boom. "There are 300 million people on the internet, and if I can get just 1% of those to pay me $20, we will have $60 million in revenue! IT'S SO FREAKING EASY! So your $10 million, no strings attached, cash investment is basically like buying bars of gold and leaving them in a vault! CHA-CHING BABY!"
Are there sites out there with expired certificates? Abso-freaking-lutely. Are they sites that you use every day and trust? Probably not.
Sure, we're all human, and sometimes we make mistakes. If a large company does not single source its certificates through a company like VeriSign that can offer a managed solution to prevent something like that from happening, it is feasible that sites like Google or Yahoo could end up with an invalid certificate for a few hours. It has happened in the past.
The moral of this story is, any time an alert comes up in your browser about a problem with a certificate, you should be wary. There are too many attacks out there to ignore those warnings.
The moral of this blog post is math is great. "Dot Com math" should be questioned.
Evan Schuman of StorefrontBacktalk has a pretty shocking article today. Apparently, the Heartland malware hid in the unallocated file space.
Right on the heels of my last blog post too. Nuts.
Our forensic examiners at VeriSign look for this type of malware during every investigation because it is not a new trick. It surprises me that it was almost missed. Even still, I stand by my original premise which is that the standard (properly implemented) would prevent this. In order to get the malware on there, a software flaw or credential had to be exploited. Both of those vulnerabilities are addressed by PCI-DSS.
What is more troubling is the same noise that came out after the Hannaford breach last year. Bill Homa, their CIO at the time, first said that PCI was not hard enough (seriously?!? If it was harder, do you think there would be more adoption?), and that end to end encryption would have saved the day. On the surface, I disagree.
At this time, banks cannot process encrypted credit card data (PIN Debit may be the only exception). At some point during the many processes that occur in order for money to actually change hands as a result of a credit card transaction, the data must be decrypted. I'm not saying there are not opportunities to increase the security of payment data, or even take large areas of your network out of scope, but just saying that end-to-end encryption is the solution is irresponsible.
Let's take this example that is fictitious, but not so much so that I have not seen this in the field somewhere. Merchant A encrypts everything from the POS Controller to the back office processing. That leaves the POS Terminal to POS Controller link vulnerable, as well as the machine that does the processing to send transactions to the bank. You could not solely rely on encryption to protect you here, you would need to make sure the rest of the standard is properly enforced on those key machines.
Another example, where the POS Terminal to Controller link is encrypted, but nothing past that. It leaves the controller open to attack, especially if it has access to the internet (don't laugh... I have seen that on many occasions).
I understand minimizing the exposure of unencrypted card data, but even with malware combing through memory, that is not something that we should rely on (or that a developer should argue when you are conducting a PCI Assessment).
We should continue to pursue end-to-end encryption solutions because it will make life for Merchants a TON easier, and will boost the overall security inside the payment process. Remember though, if you take away one vulnerability, the bad guys will find another. I predict you will see an increase in the threats against the devices themselves. More skimming devices, and more fake ATMs/PEDs are coming. That's a management and training problem to fix (NOT a technology problem).
I stand by my original point. The standard, properly implemented, could have prevented a breach like this.
It's one week later. With limited public announcements, what is this post going to tell you? Well, let's start off by stating what it won't tell you. You won't find any gory details about the breach or the other parties involved. You won't find anything here that cannot be deduced using public information sources. You won't find anything here that has not been stated before.
So what use is it? How about we assemble some key points and do a little bit of analysis to understand how something like this can be prevented in your company.
According to the original press release, the investigation uncovered malicious software that compromised data that crossed Heartland's network. Before we start attacking PCI and saying that the standard should require encryption over any network, let's think about what the standard does today that would prevent that.
To start, PCI Requirement 5.1.1 states:
Ensure that all anti-virus programs are capable of detecting, removing, and protecting against all known types of malicious software.
We don't know what kind of malware this is, so we don't know if there are signatures to detect it; however, there are many types of software that can detect malware without signature. White-listing software is particularly useful here, and properly managed could easily have thwarted this breach.
Next, let's have a look at PCI Requirement 6.1:
Ensure that all system components and software have the latest vendor-supplied security patches installed. Install critical security patches within one month of release.
Malware rarely finds its way onto a system that is fully patched. Exceptions would include a zero-day exploit, or someone that already had administrative credentials for the machine in question. Zero-day exploits for machines behind firewalls are not as probable as those in front of them (or workstation/desktop machines). Administrative credentials could be particularly crippling, but getting access to them can be tricky. You would not typically see those outside the corporate network, unless the attack targeted an individual or team inside of a company. Besides, we know that no default credentials should work because of PCI Requirement 2.1 (Always change vendor-supplied defaults before installing a system on the network).
OK... One more, and then I will stop (although you can keep going). PCI Requirement 11.5:
Deploy file-integrity monitoring software to alert personnel to unauthorized modification of critical system files, configuration files, or content files; and configure the software to perform critical file comparisons at least weekly.
This one is the key. Malware cannot go undetected on systems that have proper file-integrity monitoring performed. Note I said PROPER, but let's face it. Even a BASH script that computes a SHA-1 hash on all the files in a particular tree will find malware when it compares those hashes to previous versions.
CEOs, keep reading. Your part is coming, but first I need to address the CISO that is screaming at me right now.
Yes Mr. CISO, you are well informed. A targeted attack can be pretty effective against the base controls I mention above. The reality is that targeted attacks don't happen (in the US anyway) as much as you might think because the basic security principles mentioned above are simply not being followed. Why would a criminal invest countless hours and money creating a targeted attack when generic malware works just as well?
Mr. CISO, you should not give up. You need to understand the risks in your environment, and that starts with strategic things like governance, and tactical things like mapping out data flows. This also means that when you are ready to ask for funding to address a risk, you don't tell the board that the world will end with EVERY SINGLE ITEM on your agenda. Pick something appropriate, and SELL IT.
I know, you hate salespeople. Face it, if you are going to be effective, you will become one.
Now, Mr. CEO. As the Chief chief, you are responsible for all the things that happen on your watch. If a data breach occurs, you can bet that your compensation will suffer, your employees will suffer (through layoffs and poor financial performance), and in some extreme cases you will find yourself reporting to outside legal counsel instead of the board (this happens more often than you think). I'm not saying you should throw all of the company's money toward security, but you should be taking it seriously. Make your CISO (or CIO... and if that is the case, go get a CISO) do his research and justify his position. When he does, you should listen.
What can we all learn? Going through the motions of something like PCI without actually committing to it will land you in the "PCI Validated, but Compromised" bucket like so many before you. The Anti-PCI crowd comes in two flavors, the "It's Too Damn Hard" flavor, and the "It's Doesn't Address X Issue" flavor. Both of those flavors have valid points, but they are sooo 2006. 2009 is the time to OWN your security, and PCI is a great place to start.
If you are shopping for the easiest pass, or looking for an assessor that will pass a halfway implemented control, you are asking for trouble. 2009 is yet another year to do more with less, but don't skimp on something like this. A good assessor will provide you with the concrete evidence you require to secure funding and fix problems you have been sitting on for years. It's time to take security and PCI seriously and get your program in place to maintain them every single day. Why? Because breaches put their victims at a competitive disadvantage to their peers, thus impacting their long-term outlook.
Need help on finding a place to start? Drop us a line! We can help!
We've got another one in the news. Heartland Payment Systems recently reported a breach that may have affected up to 100 million cards.
That's a lot.
Heartland joins another elite group of companies that suffered a breach, but was also validated as compliant by a QSA. I want to make something very clear in this next paragraph, but before I do, none of the comments here should be tied directly to any incident that has been in the news. We keep our customer lists private unless we get permission to use one as a reference.
There is a big misnomer out there that needs to be cleared up. I've even written about it before in this blog. In our investigations of PCI related breaches, we have NEVER concluded that an affected company was compliant at the time of a breach. PCI Assessments are point-in-time and many companies struggle with keeping it going every day.
Is there a problem with PCI? If there is one, the problem lies in the QSA community (or internal auditors that have not been through something like the CPISA training), not the standard itself. The new QA program aims to fix this, and time will tell if it hits the mark. The only snag I can see there is that virtually every question that is posed to the Council nowadays comes back with a standard answer that looks something like this:
The PCI Council empowers QSAs to make a determination if the stated controls meet the intent of the requirement. It's up to the QSA.
In some cases, this answer is warranted. I've heard of some of the questions they get. Things from "Does X technology meet Requirement 5 (usually from that technology vendor)" to questions that arguably look like free consulting. I do believe the Council has taken such a strong stance against making specific interpretation rulings that there will be room for a QSA to wiggle out of potential liability if they are remarkably good at paperwork.
So, to recap, our experience shows companies that suffer a breach are not compliant with the entire standard at the time of the breach. We should refrain from saying that another PCI Compliant company was breached because the facts show that it just is not true.
James DeLuccia IV noticed that Discover has officially matched their merchant levels to Visa (sorta). While this is a big step for Discover, I think most will find that they become Level 1 merchants of Visa before they become Level 1 merchants of Discover.
There are exceptions. Some merchants are exclusively Discover. Those merchants will have to double check their levels (if Discover has not already told them they are a Level 1) to see if they have new compliance requirements.
Greetings all! Join me for a Free Compliance Webcast put on by BrightTALK! I'm one of the featured speakers and will be discussing "Beating PCI in 2009!" You can review the agenda and register here: http://www.brighttalk.com/webcasts/2158/attend. You should also be able to look below this paragraph and log in and register there!
Finance and Commerce Magazine published an article based on a survey revealing that most companies are unprepared for IT risks.
*blink*
What? You mean that with all the emphasis we put on it, and all the spending after some of the biggest breaches in history, we're still not ready? This is not coming from the consultant who sees this stuff every day, this is coming from people working for these unprepared companies.
With the economic situation as it is, will your own employees finally turn on you and take advantage of weak security controls in your network?
This may be an unpopular position, but while the risk is definitely much higher for insider threat, it doesn't seem to make the news as much as the external breaches do. Maybe it is because most of the employees that are in a position to take advantage of something like that have too much to lose by committing such a crime.
This blogger is not sure.
Maybe things will get nasty for those companies who have ignored good security with employees facing the threat of an imminent layoff or being financially overextended. I would suggest there is a better chance of a hacker using an employee to exploit these poor controls, probably without them knowing it is happening.
Be it through phishing, social engineering, or just the right place at the right time, appropriate motivation may end up costing companies and their customers big dollars in 2009.
What a confusing time it is for me those of us who just like sitting around all day and poking at the interweb through a browser. We have a rather nasty 0-Day exploit for Internet Explorer roaming around, and Mozilla Firefox makes Bit9's list as one of the most vulnerable applications in 2008 (surprisingly, IE is not on there).
The Internet Explorer 0-Day is so bad that some experts are urging users to switch to another browser. Naturally, the first choice for a number of users would be Firefox. But now Bit9 has released this telling report saying that it was one of the most vulnerable apps in 2008.
So where do you turn? Well, the list is not the prettiest. You could go with Chrome, but then you read the EULA. You could try Opera or Safari, but both have also seen major security vulnerabilities this year.
Maybe it's just time to punch out for 2008?
Less than two months after its release, we've seen our first announcement from a company that has become compliant!
I think that companies will find 1.2 easier to comply with when they examine it in detail. Have you performed a gap analysis yet? If not, maybe the downtime around the holidays (as long as it does not impact holiday lockdown!) would be good to review your last ROC and see what changes you may need to make!
The transition of PABP to PA-DSS looks more complete every day. In the last 24 hours, the PCI Council has posted their validated application list. Many of these applications were grandfathered under various versions of PABP and will have to be reviewed under PA-DSS in the next one to two years.
As of today, 85 payment applications are listed from 55 vendors.
The PCI Security Standards Council released the new version of the Self Assessment Questionnaires yesterday, as well as a new Navigating PCI-DSS for version 1.2.
VeriSign's Managed Security Services group provides all kinds of services to assist organizations in the heavy lifting associated with some security tasks. Those tasks that are easy if you have one, but not easy if you have a thousand.
In a recent internal email string, one of our engineers told us they are seeing a dramatic increase in the amount of PDFs that have malicious JavaScript embedded in them. These exploits use the OpenAction function (like the HTML document.onload() function) as a vehicle to obtain full machine compromise with a root kit. I'm not sure why we feel the need to embed scripting into a PDF (isn't that what the web and offline browsing is for?), but it appears that once again functionality has usurped security.
I guess the next step is to make text files more functional so we can exploit those.
According to this article from Information Week, "only 35% of Oracle users continuously monitor for suspicious activity."
Ouchtown, population YOU, bro. Well 65% of you.
Let's assume that this study is accurate (based on the installations of Oracle that I have seen, I would guess it is pretty close if not optimistic). This means that there are databases out there, probably with sensitive data in them, that are compromised and the DBAs or security teams don't even know it. Many DBAs simply give up on patching these installations thanks to a rather messy process, so the problem could even be worse.
The study specifically states that continuous monitoring (minus a definition on what that means) is performed by 35% of the respondents. Another 32% monitor once per day, 23% once per week, and 9% once per month. Apparently, a couple of respondents also chose to say they monitor once per YEAR (1%).
Daily monitoring COULD be useful, but it is not nearly as useful as real-time monitoring. It really depends on what the respondents are doing. If continuous monitoring means that they are pinging the database every few seconds to make sure it responds, that's not the kind of monitoring that I'm talking about here. I'm talking about real-time monitoring that could help a DBA or security analyst determine if a breach has occurred, or is occurring. Ideally, seeing the attack in progress would help stem the amount of data lost.
Most Oracle installations after version 10 can support some kind of minimal audit logging without a major performance hit. I don't know of any Oracle DBA that would turn on audit logging for every table in their database, but there are key schemas that should be monitored. This will require someone do some analysis though, and with most of us continually being asked to do more with less, I bet this task quickly is tossed by the wayside.
Application vulnerabilities make matters worse by exposing these databases to compromise more and more every day. Companies driving major e-Commerce installations from databases are an obvious first target, but don't forget Extranet sites for vendors, or poor network segmentation that exposes databases to a relatively large population of employees (that we all hope are on the straight and narrow).
I would be interested to see this survey expanded beyond the scope of Oracle. I bet that the numbers are pretty similar in the Microsoft SQL world as well as in any of the Open Source databases (PostgreSQL, MySQL). My guess is that two databases that would buck this trend would be DB2 and Informix, but that's just a crazy guess by a crazy blogger.
Billy Rios, application security extraordinaire, posted commentary on Sandro Gauci's paper entitled "Surf Jacking - HTTPS will not save you." It's based on an attack called "Side Jacking" that was introduced during the 2007 BlackHat conference. Essentially, this type of attack allows someone to hijack a web session which would give them access to your account on a particular website.
Branden... In English please...
Ok, so let's say you make use of some stretch time that the office gives you (assuming they know about it), and head down to the coffee shop of your choice to get a nice fresh cuppa. You bring your laptop with built-in WiFi with the full intention of working on that presentation for Johnson. That guy can't seem to finish any of his work, and you get stuck cleaning up the mess. The only way you can deal with this kind of crap is to change your surroundings.
So you order that Triple Venti Carmel Macchiato with a dousing of cinnamon and two (not one, not three) mint leaves because it is your guilty pleasure and the guys from work are not within earshot to rip me endlessly for it until I curl up in the corner, sobbing quietly while looking for my blankey.
Anyway... so you pop open your laptop and there Johnson's presentation sits. Flipping through the cluttered and incomplete slides makes it hard to keep your drink down, so you decide to log into your bank account and see if you have enough reserves to take a sudden unpaid vacation. You hop onto the free WiFi that is so graciously offered by the coffee shop, and proceed to log in. Of course, your bank is smart and uses SSL to secure your connection, but someone was lazy when they coded the application and forgot to make the cookies secure.
No, not the biscotti that you have been gnawing on, a web cookie. Web applications often use cookies to identify different user sessions. That way, John Doe does not get John Q. Public's information (how embarrassing).
So now, we have unsecured cookies traveling back to the client! "But Branden," you protest, "all of the data is wrapped in SSL? What's the worry?"
According to Gauci, the cookie could be retrieved if you look at your bank account and open a new browser window to book travel to AnywhereButHereistan. Simply opening a new window to a non-secure site opens the possibility for an attacker nearby to inject an HTTP Redirect (302) message that will then transmit that session cookie in the clear!
Now the attacker copies the cookie, drops it into his browser, and takes over your session! YIPES!
Rios points out that this is a very simple fix (use the secure flag), but lazy development and poor security review in the SDLC promotes security vulnerabilities like this one. If this is not addressed early in the development process, Rios points out that you could get coded into a corner and have a major rewrite on your hands.
At any rate, those of you who have been solely relying on SSL (or EV-SSL) to ensure your web applications are secure, you should consider having someone like VeriSign's ESS do a security review of those applications to ensure flaws like this don't leave your customers screaming!
Cyber-Ark has released a new study (article on ars technica) suggesting that 88% of IT workers would steal data if fired.
Every 88 in 100 IT employees would steal data if they were shown the door. That's more than the 4 out of 5 dentists that recommend chewing Trident after meals!
I'm not sure who they were polling, but it sure makes IT folks look like a bunch of criminals. At a minimum it does reinforce one point that often shows up in my presentations. At the end of the article, we learn that every third administrator would write down an administrative password. Administrators are often the worst offenders when it comes to breaking security policies and procedures.
This is why data security is so important. With proper security, you could easily remove the ability for 86 of those 88 folks to walk out the door with decrypted data. With good network controls, you could also prevent it from leaving the premises BEFORE a firing would occur. And as we know, once the data walks out the door, the lawsuits usually come directly following.
Last month, we saw Kaminsky release details around a particularly nasty flaw in the DNS infrastructure. The tubes exploded with traffic on this flaw and security pundits beat their chests, telling the masses that they have been reporting this for years.
Well, it's a new month, and we have a new flaw.
Slashdot has posted a story about a BGP flaw that has been around for years that could easily bring down major portions of the internet. Wired has an article here, and the PDF of the presentation by Kapela and Pilosov is here.
I was a system and network administrator in a previous life (and to date have only had one system of mine EVER hacked... that pesky IMAP flaw in 1997 taught me a TON about security), and I always marveled at how easy it was to goof up parts of the Internet with bad BGP announcements. Thankfully, we were too small to ever be a victim of such an attack, but I do remember fat fingering IP space and seeing my goofed up announcements propagate quickly across the internets. I also got a kick out of a goofed up as-path prepend statement I did once (which is exactly how part of this attack works).
Ahh, those were the good old days.
But apparently, the good old days are still around! Imagine being able to target specific users to read all of their email before they can. Or maybe launch attacks on the inside of your own company (many companies use IBGP to route internally, some use straight BGP) to learn about an impending layoff. This is a classic Man in the Middle attack (MITM), and should reinforce our beliefs that the Internet (and maybe your internal network) IS NOT to be trusted.
Kapela and Pilosov state that the only way to fix this problem is with "perfect filtering." That will never happen. A better way is to start wrapping your traffic inside SSL or other types of encryption technologies that include assurance and integrity checks.
What will it be next month?
Entitled, The Carl Method to Security, I compare CIOs to our lovable friend Carl Spackler when it comes to reacting from a breach. If you read this and don't believe me, just troll the news for recent CIOs responding to breaches.
I don't need to make this stuff up, people do it quite nicely on their own. Just like that time I was in the Las Vegas airport and a TSA agent came over the PA and said, "To the person who left your dentures and hearing aid at the security checkpoint, if you can hear me, please return to claim your items."
See? Don't need to make it up.
Anyway, go check it out!
ZDNet is reporting that Oracle has released an emergency patch today, the first of which that has been released since their quarterly update cycle. I can just hear the Oracle DBAs of the world screaming and bitching about this.
I know the Oracle code base is mammoth, but wouldn't it be nice for them to do a full security code review (which VeriSign's Enterprise Security Services group offers) to shore up some of these things. I don't think anyone at Oracle is delusional enough to believe that they are extinction proof, but something like this may go a long way to ensure that the tusky software giant remains in play well into the future.
Don't worry, you are not alone. A partnership of several companies released DLP In Depth today, a website that is set off to unravel the mystery of Digital Loss Prevention (DLP). DLP technologies have been around for some time, but last year we saw a fury of activity in that market as RSA picked up Tablus, and Symantec picked up Vontu.
At VeriSign, we regularly recommend using DLP products as part of your security strategy. Knowing where your data lives is the first step to being able to secure it.
So if you are looking for more info on DLP, go check out www.dlpindepth.org!
Before you click on the link to read the article, I should warn you. Things got a little silly with this one. I even had to edit a cleverly-placed word as my editor threw up a little when he hit publish on this one.
Anyway... I hope you enjoy the July edition of Herding Cats entitled, The Forward Looking Future!
Oh, and it looks like Twitter lost me. I'm there, but you can't see my updates. *shrug*
Dave Taylor has another guest post on StoreFrontBackTalk, this one alluding to a lack of audit resources to mind the storefront (like Minding the Gap!).
Store front security continues to be an issue for retailers even outside of PCI. Take physical security for example. Realize that a major retailer's data center tends to be a hardened facility that is not easily accessed (with the exception of a few notable ones that are for another post). There are security guards, badged access, and sometimes even man traps. Now visit that same retailer's store front. You might find accessible Ethernet jacks, or worse, a system room door that is unlocked or left wide open. Walk into there with an official ID and you might just jack in to that same VLAN or security level as if you jumped through all the hoops at the data center!
The point that Dave makes is the same one I'll make here. There are two things that will greatly mitigate the risks associated with weak physical security in the stores.
The deadline has passed, do you know where your children web application firewalls are? If you scratched your head and then saw a shiny object fly by to steal your attention, you are not alone. Information Security Magazine interviewed me for an article on this topic. Go check it out!
Are you making the trek to DC next week for the Gartner IT Security Summit? VeriSign will be there, and I'll be speaking on Monday, June 2, at 4:15PM in Potomac 6. It's time to discuss the classic transmogrification, changing the tactical PCI approach to strategery.
Phew!
Anyway... Come see my presentation or stop by the VeriSign booth!
Greetings everyone! Go check out my guest post on Karen Swim's fantastic blog, Words for Hire.
"Step 1: Extinguish the precipitous rubescent LED-based luminosity!"
The Register is reporting that McAfee's "Hacker Safe" sites are not so much. In the security industry, we typically refrain from saying things are 100% secure, simply because the only 100% secure computer is the one that does not exist.
GloboTV (via Gizmodo) has a story (in Brazilian Portuguese) about some crooks that used the Eee PC to steal customer's debit information at ATMs.
Tee Hee.
If you are not a member if the ISSA, click here to go sign up! I am a monthly columnist in the ISSA Journal--the publication for the association. This month I tell you how you can learn something from the Department of Homeland Security and Ron "Tater Salad" White.
Thanks SC Magazine! We've been recognized as the Best Security Company in 2008! Here's the part of VeriSign that I represent!
VeriSign's Enterprise Security Group (ESG) provides a best of breed suite of solutions for global companies. Beginning with our iDefense Intelligence Service that provides detailed threat information in advance. Vendors are notorious for taking anywhere from 90-180 days to patch discovered vulnerabilities. iDefense can help you understand how to mitigate before patches are available.
From there, our Managed Security Services (MSS) group provides some of the best managed security services to customers according to the Gartner Magic Quadrant. Why not let your security staff concentrate on adding real security value and outsource your security device management to us?
Finally, VeriSign's Global Security Consulting (GSC) practice that provides a valuable mix of Risk & Compliance and Technical services. From PCI to Application Testing and Code Review, we do it all. Our consultants are seasoned (average 8-9 years experience) and provide customers with executable, tactical solutions rooted in sound security strategy to all levels of management.
Sharon Gaudin at Computerworld writes about a new way to use RFID tags. In this article, a new physical security technique is discussed where a worker who walks into a restricted area would pick up hundreds of tiny RFID sensors on their shoes. As they track their feet across the doormat on the way out, sensors pick up that this employee has entered a restricted area, and then release the hounds.
Cooler than LED Throwies? You be the judge.
In an unpublished (and scrapped to my knowledge) Top 10 Security Predictions for 2008, I predicted that we would see a breach in 2008 from an entity that had validated compliance (hey, come on.... It's true, I promise). Does that mean that the standard is not tough enough? Or that companies validating compliance are having a hard time maintaining it? Or possibly that a QSA is not doing their job properly?
The first has been discussed at length in the industry. While there are loud detractors to the standard, insiders agree that compliance does not equal security. Compliance is a baseline and security should be layered on top. The PCI standard as it stands is GOOD. Getting companies to comply and build additional security on top is the challenge. If I had a hundred dollars for every time I heard the phrase, 'What is the bare minimum I must do to comply,' this blog would not exist.
Unfortunately, with something as divisive as PCI, you will have people complaining about how hard it is, and then folks saying it's not hard enough. Rock? Meet hard place.
For the second, VeriSign answered struggling (shout-out to the P1) entities cries for help and instituted a service called PCI Program Management. This longer process sets up a program to support and maintain PCI. If you have an existing security program, we work within the guidelines of that program, and hopefully help improve it overall. Our goal is to get companies set up to maintain compliance on their own, as opposed to being afraid that one of the thousands of change control documents is overlooked and pushes them out of compliance.
That last one is a big ouch, but if you have been dealing with PCI for some time it makes perfect sense. How can it be possible to get a small PCI Assessment quote for 15K from one vendor and a 40K quote from another? We must not be comparing apples-to-apples. Do you notice that some QSAs are easier than others? How much management confidence do you have in the findings from the assessment? 15K or 40K?
The great QSA equalizer of 2008 was supposed to be the PCI Q/A Program that the council is instituting this year, not a breach of a validated entity (remember, validated is not the same thing as compliant). Time will tell as details come out how this will affect the industry, but I am betting it will force entities to look more closely at the QSA's work product.
Merchants & Service Providers alike can alleviate something like this happening by first checking the history of the QSA and lobbing a couple of hardball questions prior to starting the engagement. This can tell you how effective the assessment is. Is the majority done remotely? Do they recommend achievable controls? Are they missing things that you know are not compliant?
But most importantly, entities subject to PCI can avoid this by building a solid program to maintain their PCI compliance day-in and day-out. Don't aim for the minimum, aim for security without impacting the business. VeriSign believes in this mantra and ensures that its importance is conveyed to our customers.
StorefrontBackTalk's Evan Schuman writes about a serious hole in an airport wireless network that could allow people to reroute luggage.
Oops... More reasons to carry-on.
As it relates to PCI, VeriSign has extensive experience in the travel industry and has dealt with some of the challenges that airlines have. Like a few other industries, it is very unique in its constraints around compliance and security. For instance, something you may not know is that the airports typically own all of the networking and computing equipment used by their tenants. So unlike most companies that have control over the chain of systems that deal with sensitive data, airlines may be forced to start off with a lack of control at the front lines.
Hopefully, this incident will be a reality check for airports.
WJLA News reports that a University of Virginia graduate student and two fellow hackers have cracked code contained in smart cards. Information security rears it's head again!
The company claims they only got a portion of the code, but depending on what they got, it could be enough to launch a feasible attack against those keys. Any reduction in bits can make a huge difference in the time required to retrieve a key.
You know, those smart card guys would have gotten away with a sub-par setup if it weren't for those meddling kids...
Greetings folks! How about a headline wrap-up? Ready? OK!
USA Today had an interesting article on Monday detailing how Cybercrooks are getting craftier (is that a word? more crafty? more craftierest?) on the scams designed to trick people into parting with personal information. A couple of the attacks listed include:
And here's someone else with too much time on their hands (thanks Springtown!)!
As a follow up to the last article, here's a pretty interesting story about a teenager in Poland who figured out a way to control how trains change tracks. He didn't hack through the internet, or some rogue access point at a station. He used a TV remote.
Between this and the Boeing 787 Dreamliner's issues, I wonder if this will force companies to take a hard look at the software they use to drive their products.
After getting an extended battery for my laptop (yaay! Less whipping out the iGo for power on the plane!), I am wondering if anyone has had problems with the new TSA Battery Guidelines. My battery is well below any proposed limit, and I rarely check bags (thank YOU London Airports!), but it seems any time a new TSA regulation is put into place there can be some difference in interpretation.
What say you?
While sitting in the Courtyard this morning in Sterling, VA, I saw that Dan Frost of the USA Today is warning of the Evil Twin problem with wireless networks.... again. I seem to remember seeing this pop up in the past, but this problem has been around as long as wireless has been in cafes.
So, watch out.... again!
According to an interview on 60 Minutes, the National Retail Federation's position (says Dave Hogan, NRF's CIO) is that the Card Associations are at fault for credit card fraud because the card associations require retailers to store consumer's CC data. I can't believe how wrong these guys are and that they are taking the national spotlight to try and scare consumers into believing this lie.
He also says he is not sure how vested the credit card companies are in securing customer data. The funny thing is the whole PCI Standard "thing" came BECAUSE the card associations are interested in securing customer data, not the other way around.
And the notion of fines being a revenue stream are absurd. Look at the amount of cash that issuers and the members of Visa & MC are charged in fraud losses each year. We all hope that these fines go to promoting securing credit card data and lessening the impact of compromises to issuers. Is it? I certainly hope it is not another "Let's get a state lottery to fund public education" bit.
Visa & MasterCard DO NOT require retailers to store customer data. Retailers sometimes do this as a convenience due to some failure in the process, such as a missed transaction. But the real problem comes in the lack of data cleaning and disposal by those collecting it.
There is absolutely no reason to keep a full credit card past settlement.
...
Stop and think about that.
NO REASON to keep the data past settlement. Yet millions of retailers do! Why? Convenience? Cause the "man" is out to get them and withhold revenue?
Nah, more likely, "Because that's the way we have always done it." In fact, we've had customers who have decided that they will just take chargebacks as an acceptable loss because the cost of securing and holding data is too expensive.
Acquirers can and have offered to store data on a retailers behalf, but of course for added cost. Big surprise, security costs! Because so many retailers drive cost through the floor, they accept risk they cannot afford. Did TJX think they would spend over a half billion dollars this year cleaning up after a horrible breach? Probably not.
Mark Rasch is also seen in this piece and is absolutely correct in that retailers do not do enough to help secure data. Why not? Because it is not in their nature!
Retailers are good at retailing, not information security. Identity Theft is forcing retailers to grow security brains and start to implement good controls to protect customers data. Does your company? Is your company taking the "I'm compliant until I'm compromised" stance?
Will it take a TJX like event happening to your company to get the fire started?
Have you got your ISSA Journal for October in the mail yet? If not, click on over to their website and you will see that they featured my article!
USA Today published a rather comical headline last week about airport security and security screening -- Most fake bombs missed by screeners.
FAKE bombs.
Wouldn't you want to let FAKE bomb parts pass through and catch the ACTUAL bomb parts? I'm not sure what this study shows. Does it show that the TSA is doing their job well? Hard to say. I think it would be interesting if they redid the study (with some kind of get out of jail free card) with ACTUAL bomb parts. I can only hope that they would be stopped.
