We are living in the age of the Internet. It seems like everyone has a presence on the Internet these days. People can now perform research online, read books online and even shop online. Large amounts of sensitive information flow through the veins of the internet on a daily basis. In order to protect this data we turn to our dear friend known as SSL (Secure Sockets Layer).
SSL is a protocol used to protect sensitive data flowing over the Internet from unauthorized parties. SSL verifies that the site claiming to be XYZ Bank is really XYZ Bank, and then encrypts the information traveling between the user and XYZ Bank. SSL is used when you buy the newest book from Amazon, or when you win that newest item on e-bay. SSL has become a cornerstone for protecting most sensitive data that is sent over the Internet.
In light of the fact that SSL is so important to Internet security, it is odd that vulnerabilities related to SSL implementation are found in many organizations. I have performed many vulnerability scans and it is amazing to see the amount of vulnerabilities, related to SSL. In honor of the many SSL implementation vulnerabilities I continue to find on a daily basis, I figured that this would be a good time to talk about a couple of them.
The first vulnerability I would like to discuss is the use of SSLv2. SSLv2 has many security flaws, but I am going to focus on the ability to downgrade the encryption used to establish SSL connections. Generally encryption negotiation of SSL connections works as follows: Suppose that a web server supports LOW, MEDIUM and HIGH levels of encryption. A user needs to connect to the server to perform some kind of action (such as online banking). The user supports SSL connections using LOW, MEDIUM and HIGH levels of encryption. In most cases the server and user will choose the highest form of encryption both of them support. Therefore the server and user will connect using HIGH encryption since both user and server support this level of encryption.
SSLv2 has been found to have a Ciphersuite rollback attack (Page6: http://www.schneier.com/paper-ssl.pdf). This attack works as follows: Suppose that a web server supports LOW, MEDIUM and HIGH levels of encryption. A user needs to connect to this server to perform some kind of action. The user supports connections using LOW, MEDIUM and HIGH levels of encryption. An evil hacker sits between the user and the server. The evil hacker intercepts the user’s SSL request, and modifies the request in order to make the server think the user only supports LOW encryption. Although both the user and the server support HIGH encryption, the connection between them is established using LOW encryption.
In most cases it is trivial to disable SSLv2. On new versions of Microsoft Windows SSLv2 can be disabled by modifying the underlying system’s registry. SSLv2 can also be disabled in Apache by making small changes to the httpd.conf file.
Disable SSLv2 in Windows: http://support.microsoft.com/kb/187498
Disable SSLv2 in Apache: http://apachehacker.com/kabir/security/disabling-weak-ssl-v2-support-in-apache-server.html or http://adamyoung.net/Disable-SSLv2-System-Wide
The second vulnerability I would like to rant about is the availability of weak encryption settings on a server, which could be used to establish SSL connections. It is not uncommon to find weak encryption settings enabled on a server. One such weak encryption algorithm is named DES. DES stands for Data Encryption Standard and only uses a 56-bit key to encrypt data. In April of 2006 DES was broken in nine days at a cost of $10,000 in hardware costs. Within a year the average time needed to break DES encryption was reduced to only 6.4 days (http://en.wikipedia.org/wiki/Custom_hardware_attack#History). It is important to note that when using DES encryption the possibility exists that an attacker may be able to see what you are sending in only 6.4 days. This is a rather scary thought! If an attacker were able to find your credit card or social security number in 6.4 days would you be concerned? The answer in most cases is a resounding YES!
The majority of weak SSL encryption vulnerabilities can be fixed rather easily. Most versions of Microsoft Windows can have weak encryption disabled by simple registry changes. Apache can disable weak encryption through simple changes in the httpd.conf file. In order to protect consumer data it is vital to disable support for weak encryption.
Disable Ciphers in Windows: http://support.microsoft.com/default.aspx?scid=kb;EN-US;245030
Disable Weak Ciphers in Apache: http://qaix.com/java-programming/487-339-ssl-server-supports-weak-encryption-vulnerability-read.shtml
Unfortunately I cannot address all SSL vulnerabilities in a single post. Time would fail me if I were to talk about Self Signed Certificates, Signature Verification Failure, X.509 MD5 Signature Collisions, Improperly Used Certificates, or Expired Certificates. To summarize SSL is a critical protocol used to ensure Security on the Internet and I have found it to be broken in many implementations. Now I ask you. How will you help defend the integrity of the Internet?
-Gary McCully
Read more!
Friday, January 15, 2010
Thursday, January 14, 2010
Writing Security Policies and Procedures
Anyone who has ever written a set of policies and procedures knows how time consuming, headache ridden and tedious they are to create. For those of you who are in need of updating or creating new policies and procedures, this blog will be going over some things to keep in mind. We’ll also go over tips to making your writing easier for you and easier for your users to understand.
Whether you’re just starting to write brand new policies and procedures or you’re doing your yearly updates on existing ones, I think the thing that everyone needs to keep in mind is simplicity. So that means, for any lawyers that may be reading this, you guys aren’t allowed to write these. This also means that the techie-guys that don’t know how to speak to normal people, you aren’t allowed to write these either. There are some companies out there that have policies that have the procedures right in the same document, and this single document spans hundreds of pages. Who will honestly read and follow that?
Now I know there are a ton of policies and procedures that are needed for different aspects of business but we are only going to look at the one that most people see: the End User Security Policy. The ideas we cover for this policy can easily be applied to any other policy you’re putting together. This end user security policy is notoriously filled with jargon that lawyers and techies love to throw in there. People, you have to realize that your end users need to be able to read and understand this policy so that they can easily remember it and apply it when necessary. They shouldn’t be long, there’s no need for that. The policy should be short enough that people can read and interpret it within 10 mins. Any longer than that and your end users will read half of it, maybe skim the rest of it and throw it in a big pile of papers on their desk. That creates two problems: 1. they didn’t read the whole thing, and 2. they won’t sign off on it that they did read and understand it.
Many end user policies are not enforceable based solely on the language used in the policy, or the fact that the policy doesn’t set metrics on what will happen if you do break the policy. The policy has to be enforceable, and when you are writing the policy you have to think of what you would do, seriously, in the same situation. If you say, you have to set a strong password for your windows login, there’s no way around that in a domain, so you don’t have a choice, you have to follow that. But let’s say you specify to your end users that if they receive corporate mail to their phone they have to have it password protected. Are you going to do that on your phone? Do you have a way to enforce that? Are you planning on running an internal security assessment to test this? If you find a user not doing that, what is the penalty? Is the penalty the same for every user? (The answer to that question had better be YES! Otherwise you’re going to be talking to those pesky lawyers about discrimination!)
What would you do if a user brought their home laptop in and plugged it in to the corporate network? Or worse, a wireless access point? What is the policy on that and what are the repercussions? What about non-employees such as contractors, visitors and such? Make sure to set the policy on this stuff, and remember to make it enforceable. Now if you say something like, the person who does this is fired, then what are you going to do if the CEO brings his son to work? His kid gets on the network just to use the internet. Are you going to fire the CEO?
What security methods are you going to make your end users aware of? Do they need to understand what drive encryption is or how to use it? Your end users may be complete tech novices, but your security policy/end user information technology policy should try to lay out what a user needs to know. And in this they need to understand the expectation of privacy. The expectation of privacy shouldn’t be documented too much here because you should have logon banners on every single network device that can be logged into. But you should explain what the banner says and what it means. And technically, if you don’t remove the expectation of privacy on a company computer or network device, then your user still maintains it, so make sure you stay consistent.
Obviously if your end security policy exists then you need to have an end user security procedure document as well. Every policy document should have a corresponding procedure document. And this procedure document needs to be referenced in your policy document. So, for instance, if your policy states that you have to make sure Windows Updates are installed every month, you should follow that up with something like, “Page 7 of the End User Procedures document explains how to do this.” You can’t expect your end users to know what Windows Updates are, let alone how to install or make sure they are installed every month. Try to do this as often as possible. It may take a lot of time to set up initially, but you can cut down on a lot of IT helpesk calls if you reference your procedures and keep all of this documentation easily accessible on the corporate intranet website. C’mon, throw a dog a bone. We aren’t the police here, we’re here to help, not criminalize.
Security doesn’t only mean network equipment either, now does it? Physically speaking, how do company employees get in the building? Do you require swiping an ID badge at every outside door? How about pin numbers or cipher locks? What doors do you not allow people to use unless emergency? Who gets keys to the building? What’s the policy for getting an ID badge or set of keys to the building? There are a lot of things to think about from an end user perspective. Be sure to go through every possible scenario that your company has and address it in your policy and explain how to do it in your procedures. Again, what about non-employees in the building? Do you require people without badges to show proof of who they are or ask questions on how they got in?
How about protecting intellectually property? What is the company policy for that one? This one is a touchy subject that needs to be discussed with some folks at the top of the chain. If you can get the Director of HR, the CEO and your CIO/CSO to give you their opinions on this first, you’d be in a better place to write this policy. Either way, when writing this policy, you have to make sure you are consistent. Any contradictions in your policies and procedures and you can throw these out the window.
Lastly, now you need to follow what you wrote and so does everyone else in the company. That means that all employees should review the policies once a year and sign off that they read them. Encourage people to ask questions. Get a training group together if needed. And if you think you’re going to get away with not having to follow your own document, you better believe other people are going to try their best not to follow it as well. If you made the cool-aid, you better drink it, unless you’re a malicious person by nature, then you shouldn’t be making cool-aid, let alone writing security policies. If you follow these simple tips, I promise that writing your company information technology and security policies and procedures will be much easier, not to mention that your end users will follow them much better.
Read more!
Whether you’re just starting to write brand new policies and procedures or you’re doing your yearly updates on existing ones, I think the thing that everyone needs to keep in mind is simplicity. So that means, for any lawyers that may be reading this, you guys aren’t allowed to write these. This also means that the techie-guys that don’t know how to speak to normal people, you aren’t allowed to write these either. There are some companies out there that have policies that have the procedures right in the same document, and this single document spans hundreds of pages. Who will honestly read and follow that?
Now I know there are a ton of policies and procedures that are needed for different aspects of business but we are only going to look at the one that most people see: the End User Security Policy. The ideas we cover for this policy can easily be applied to any other policy you’re putting together. This end user security policy is notoriously filled with jargon that lawyers and techies love to throw in there. People, you have to realize that your end users need to be able to read and understand this policy so that they can easily remember it and apply it when necessary. They shouldn’t be long, there’s no need for that. The policy should be short enough that people can read and interpret it within 10 mins. Any longer than that and your end users will read half of it, maybe skim the rest of it and throw it in a big pile of papers on their desk. That creates two problems: 1. they didn’t read the whole thing, and 2. they won’t sign off on it that they did read and understand it.
Many end user policies are not enforceable based solely on the language used in the policy, or the fact that the policy doesn’t set metrics on what will happen if you do break the policy. The policy has to be enforceable, and when you are writing the policy you have to think of what you would do, seriously, in the same situation. If you say, you have to set a strong password for your windows login, there’s no way around that in a domain, so you don’t have a choice, you have to follow that. But let’s say you specify to your end users that if they receive corporate mail to their phone they have to have it password protected. Are you going to do that on your phone? Do you have a way to enforce that? Are you planning on running an internal security assessment to test this? If you find a user not doing that, what is the penalty? Is the penalty the same for every user? (The answer to that question had better be YES! Otherwise you’re going to be talking to those pesky lawyers about discrimination!)
What would you do if a user brought their home laptop in and plugged it in to the corporate network? Or worse, a wireless access point? What is the policy on that and what are the repercussions? What about non-employees such as contractors, visitors and such? Make sure to set the policy on this stuff, and remember to make it enforceable. Now if you say something like, the person who does this is fired, then what are you going to do if the CEO brings his son to work? His kid gets on the network just to use the internet. Are you going to fire the CEO?
What security methods are you going to make your end users aware of? Do they need to understand what drive encryption is or how to use it? Your end users may be complete tech novices, but your security policy/end user information technology policy should try to lay out what a user needs to know. And in this they need to understand the expectation of privacy. The expectation of privacy shouldn’t be documented too much here because you should have logon banners on every single network device that can be logged into. But you should explain what the banner says and what it means. And technically, if you don’t remove the expectation of privacy on a company computer or network device, then your user still maintains it, so make sure you stay consistent.
Obviously if your end security policy exists then you need to have an end user security procedure document as well. Every policy document should have a corresponding procedure document. And this procedure document needs to be referenced in your policy document. So, for instance, if your policy states that you have to make sure Windows Updates are installed every month, you should follow that up with something like, “Page 7 of the End User Procedures document explains how to do this.” You can’t expect your end users to know what Windows Updates are, let alone how to install or make sure they are installed every month. Try to do this as often as possible. It may take a lot of time to set up initially, but you can cut down on a lot of IT helpesk calls if you reference your procedures and keep all of this documentation easily accessible on the corporate intranet website. C’mon, throw a dog a bone. We aren’t the police here, we’re here to help, not criminalize.
Security doesn’t only mean network equipment either, now does it? Physically speaking, how do company employees get in the building? Do you require swiping an ID badge at every outside door? How about pin numbers or cipher locks? What doors do you not allow people to use unless emergency? Who gets keys to the building? What’s the policy for getting an ID badge or set of keys to the building? There are a lot of things to think about from an end user perspective. Be sure to go through every possible scenario that your company has and address it in your policy and explain how to do it in your procedures. Again, what about non-employees in the building? Do you require people without badges to show proof of who they are or ask questions on how they got in?
How about protecting intellectually property? What is the company policy for that one? This one is a touchy subject that needs to be discussed with some folks at the top of the chain. If you can get the Director of HR, the CEO and your CIO/CSO to give you their opinions on this first, you’d be in a better place to write this policy. Either way, when writing this policy, you have to make sure you are consistent. Any contradictions in your policies and procedures and you can throw these out the window.
Lastly, now you need to follow what you wrote and so does everyone else in the company. That means that all employees should review the policies once a year and sign off that they read them. Encourage people to ask questions. Get a training group together if needed. And if you think you’re going to get away with not having to follow your own document, you better believe other people are going to try their best not to follow it as well. If you made the cool-aid, you better drink it, unless you’re a malicious person by nature, then you shouldn’t be making cool-aid, let alone writing security policies. If you follow these simple tips, I promise that writing your company information technology and security policies and procedures will be much easier, not to mention that your end users will follow them much better.
Read more!
Tuesday, December 29, 2009
The MasterCard Hokey Pokey
Earlier this year, MasterCard issued a somewhat radical change for their SDP program stating that Level 2 Merchants had to have an onsite assessment by a QSA by the end of 2010 as stated here:
http://www.mastercard.com/us/merchant/pdf/SDP_Program_Revisions.pdf
However, this hokey pokey move put the Level 2 Merchants "in" the same boat as Level 1 merchants significantly upped the ante. First of all, it would certainly mean an increased cost for their PCI program by requiring an audit. But more importantly, many of these merchants would no longer be able to just claim they are following PCI via an SAQ form but would now have to prove it to an auditor. That really was the alarming part.
Needless to say, MasterCard got a lot of complaints from merchants and even banks. So, they did the hokey pokey and put their Level 2 Merchants back "out" - at least partly. Now they have moved the date back to mid 2011 and they have conceded that the SAQ can still be done, only now the company must send an employee to training before that employee can perform the SAQ.
http://www.mastercard.com/us/sdp/merchants/merchant_levels.html
On a positive note, this was a wake up call for Level 2 Merchants to enforce the understanding that no matter what size they are, compliance is really to the PCI DSS in full - not just filling out a form.
As far as the banks, who really need to absorb these positions and communicate them back to the merchants, we are still waiting to see how they consistently position this. For example, will the person trained also have to sign the SAQ? Are they liable for a breach? Will the annual test be the same as the QSA? Do they need to have cyber liability insurance like a QSAC needs to? How will there be enough training sessions to cover all the Level 2 Merchants?
Ultimately, this still leaves the merchants with the decision of whether it's more valuable to pay someone internally to go to training or engage a QSA to perform an onsite assessment. The burden to be compliant is the same, but clearly a QSA has more experience. Given the number of breaches that still occur, one would hope that merchants want their program evaluated with the most due diligence.
Read more!
http://www.mastercard.com/us/merchant/pdf/SDP_Program_Revisions.pdf
However, this hokey pokey move put the Level 2 Merchants "in" the same boat as Level 1 merchants significantly upped the ante. First of all, it would certainly mean an increased cost for their PCI program by requiring an audit. But more importantly, many of these merchants would no longer be able to just claim they are following PCI via an SAQ form but would now have to prove it to an auditor. That really was the alarming part.
Needless to say, MasterCard got a lot of complaints from merchants and even banks. So, they did the hokey pokey and put their Level 2 Merchants back "out" - at least partly. Now they have moved the date back to mid 2011 and they have conceded that the SAQ can still be done, only now the company must send an employee to training before that employee can perform the SAQ.
http://www.mastercard.com/us/sdp/merchants/merchant_levels.html
On a positive note, this was a wake up call for Level 2 Merchants to enforce the understanding that no matter what size they are, compliance is really to the PCI DSS in full - not just filling out a form.
As far as the banks, who really need to absorb these positions and communicate them back to the merchants, we are still waiting to see how they consistently position this. For example, will the person trained also have to sign the SAQ? Are they liable for a breach? Will the annual test be the same as the QSA? Do they need to have cyber liability insurance like a QSAC needs to? How will there be enough training sessions to cover all the Level 2 Merchants?
Ultimately, this still leaves the merchants with the decision of whether it's more valuable to pay someone internally to go to training or engage a QSA to perform an onsite assessment. The burden to be compliant is the same, but clearly a QSA has more experience. Given the number of breaches that still occur, one would hope that merchants want their program evaluated with the most due diligence.
Read more!
Thursday, December 24, 2009
MS08-067 Strikes Again
Firewalls, anti-virus, and intrusion detection systems can protect you from many things threatening you information security. What about your employees? Can they be easily locked down? The quick answer is no. The human element is the weakest link, and the following story is no exception.
While performing a social engineering attack, we were given a list of users to impersonate. The goal was to retrieve passwords verbally for either email or a website. On the site, I noticed that if your account was locked you could get a PIN from IT to unlock it.
I placed a call to the IT department using a spoofed number and made sure the IT person, we'll call him Joe, knew I was pressed for time. I told him I needed a PIN because my account was locked and he asked me for my name first. The person I was impersonating had a difficult name to spell, but I attempted to spell it for him and made a little joke about how difficult the name was to spell. Joe chuckled a bit and said he could send the PIN to my voicemail.
I told Joe I was calling from my mobile phone and didn't have access to my voicemail at the moment. I reminded him that I really needed to get my PIN quickly so I could log-in and asked what my options were. Joe said that if I verified the employee number he could give the PIN to me over the phone. I told him I would have to look for it and to hold for a minute.
After thinking about what to do next, I figured all was lost. So I decided to have a little bit of fun first. After about a minute, I picked the call back up and said, "Okay, I got it. It is MS08-067."
There was a brief pause and Joe said, "Your new password is _____."
I was stunned and I didn't think he was being serious until I logged in successfully. I told him thank you and how much I appreciated his help. From there, I continued accessing everything that I could log-in to and retrieved corporate email, social security numbers, pay rates, and gained access to the employee database. While Joe probably felt pretty good about helping me, I was helping myself to all of his co-workers' and corporate information.
Experience teaches us that it is human nature to want to help someone in need. We all aspire to be a hero of sorts. It may be just helping out that person on the phone, or holding a door open for someone with their hands full. Just keep in mind that while your intentions may be good, theirs may not be.
Education is very important. Teach your employees it is okay to question others. People who believe that they can't be social engineered most likely have already fallen to victim to it.
How do YOU protect yourself?
By Chris Murrey
Read more!
While performing a social engineering attack, we were given a list of users to impersonate. The goal was to retrieve passwords verbally for either email or a website. On the site, I noticed that if your account was locked you could get a PIN from IT to unlock it.
I placed a call to the IT department using a spoofed number and made sure the IT person, we'll call him Joe, knew I was pressed for time. I told him I needed a PIN because my account was locked and he asked me for my name first. The person I was impersonating had a difficult name to spell, but I attempted to spell it for him and made a little joke about how difficult the name was to spell. Joe chuckled a bit and said he could send the PIN to my voicemail.
I told Joe I was calling from my mobile phone and didn't have access to my voicemail at the moment. I reminded him that I really needed to get my PIN quickly so I could log-in and asked what my options were. Joe said that if I verified the employee number he could give the PIN to me over the phone. I told him I would have to look for it and to hold for a minute.
After thinking about what to do next, I figured all was lost. So I decided to have a little bit of fun first. After about a minute, I picked the call back up and said, "Okay, I got it. It is MS08-067."
There was a brief pause and Joe said, "Your new password is _____."
I was stunned and I didn't think he was being serious until I logged in successfully. I told him thank you and how much I appreciated his help. From there, I continued accessing everything that I could log-in to and retrieved corporate email, social security numbers, pay rates, and gained access to the employee database. While Joe probably felt pretty good about helping me, I was helping myself to all of his co-workers' and corporate information.
Experience teaches us that it is human nature to want to help someone in need. We all aspire to be a hero of sorts. It may be just helping out that person on the phone, or holding a door open for someone with their hands full. Just keep in mind that while your intentions may be good, theirs may not be.
Education is very important. Teach your employees it is okay to question others. People who believe that they can't be social engineered most likely have already fallen to victim to it.
How do YOU protect yourself?
By Chris Murrey
Read more!
Friday, December 18, 2009
Are Your Applications PA-DSS Compliant?
The PA-DSS deadline is closer than you may realize and there is bound to be a mad-rush at the end. July 2010 is the deadline for Phase 5 of Visa’s “Payment Application Security Mandates”. By that date, Visa is requiring that acquirers certify that all their merchants and processors are using PA-DSS certified payment applications. Did you get that? Stop, backup, read it again. If you are using a purchased payment application (those that are sold, distributed or licensed to third parties), it better be on the PA-DSS list.
PA-DSS is nothing new. It was introduced in 2007 as the successor to Visa’s Payment Application Best Practices (PAPB), which is intended to help software vendors and others develop secure payment applications, which could include anything from a POS system to online shopping cart software. PA-DSS requires that payment application be assessed by a 3rd-party, pass a series of security tests, and adhere to leading-practices before it can be distributed. If it fails any part of the assessment, it cannot be used as a payment application.
What does this deadline mean? First, it means that merchants’ time of using anything but compliant payment applications is nearing an end. Second, any new merchant applying for a merchant account will have to, as one of the steps to getting the account, show the acquirer, that they are using a PA-DSS certified payment application.
It's unclear how hard of a stance the payment brands are going to take on non PA-DSS or PCI compliant payment applications. If they go the full mile, they could shut down any organization whose credit card processing isn't compliant. They could also hand down some major fines for non-compliance. No one really seems to know what those fines are, but obviously if credit card data is compromised while you are non-PCI compliant, you could be subject to hefty fines. With the ability to accept credit cards at stake, trusting non-compliant applications hardly seems like a risk worth taking.
July will be here quicker than you might realize. Are you ready? It's quiet in here... can you hear the echo?
Read more!
PA-DSS is nothing new. It was introduced in 2007 as the successor to Visa’s Payment Application Best Practices (PAPB), which is intended to help software vendors and others develop secure payment applications, which could include anything from a POS system to online shopping cart software. PA-DSS requires that payment application be assessed by a 3rd-party, pass a series of security tests, and adhere to leading-practices before it can be distributed. If it fails any part of the assessment, it cannot be used as a payment application.
What does this deadline mean? First, it means that merchants’ time of using anything but compliant payment applications is nearing an end. Second, any new merchant applying for a merchant account will have to, as one of the steps to getting the account, show the acquirer, that they are using a PA-DSS certified payment application.
It's unclear how hard of a stance the payment brands are going to take on non PA-DSS or PCI compliant payment applications. If they go the full mile, they could shut down any organization whose credit card processing isn't compliant. They could also hand down some major fines for non-compliance. No one really seems to know what those fines are, but obviously if credit card data is compromised while you are non-PCI compliant, you could be subject to hefty fines. With the ability to accept credit cards at stake, trusting non-compliant applications hardly seems like a risk worth taking.
July will be here quicker than you might realize. Are you ready? It's quiet in here... can you hear the echo?
Read more!
Friday, December 11, 2009
Securing a PCI compliant vendor
Seven restaurants are suing Radiant Systems and Computer World for producing and selling insecure systems that led to security breaches, which then led to fines and other costs for the breached companies.
The restaurants claim that they were sold a product that was not PCI compliant, and the two vendors should be held responsible for the data lost and the money spent as a result of the breach.
Radiant Systems is a point of sale terminal company and Computer World is the company that sold and maintained the Radiant Systems product. The question is, should the vendors or the restaurants be held responsible for the data breach? After reading a blog that left the matter undetermined, it was necessary to clear up the confusion.
First off, a ROC or SAQ from the restaurants must have signed off on the product. As a certified QSA, the first thing we would do is check the PCI list to ensure that the product is listed. The point of sale system is certified by version. While version 1.0 of the product may be certified, 1.5 may not be. The restaurants should have spent the time and money to determine that the vendors and the products purchased would be keeping their company data secure, and they clearly did not.
Anyone can say they are PCI compliant. It's a very lucrative business right now, and many people are falsely claiming compliance to make money. As a business who is interested in hiring a vendor to provide or implement a product, it is your responsibility to research the vendor and choose the best product. Ultimately, the fault falls upon the breached restaurants.
An easy way to prevent situations like this in your company:
Read more!
The restaurants claim that they were sold a product that was not PCI compliant, and the two vendors should be held responsible for the data lost and the money spent as a result of the breach.
Radiant Systems is a point of sale terminal company and Computer World is the company that sold and maintained the Radiant Systems product. The question is, should the vendors or the restaurants be held responsible for the data breach? After reading a blog that left the matter undetermined, it was necessary to clear up the confusion.
First off, a ROC or SAQ from the restaurants must have signed off on the product. As a certified QSA, the first thing we would do is check the PCI list to ensure that the product is listed. The point of sale system is certified by version. While version 1.0 of the product may be certified, 1.5 may not be. The restaurants should have spent the time and money to determine that the vendors and the products purchased would be keeping their company data secure, and they clearly did not.
Anyone can say they are PCI compliant. It's a very lucrative business right now, and many people are falsely claiming compliance to make money. As a business who is interested in hiring a vendor to provide or implement a product, it is your responsibility to research the vendor and choose the best product. Ultimately, the fault falls upon the breached restaurants.
An easy way to prevent situations like this in your company:
- Look at the PCI list. PCI provides an Approved Service Provider list that includes products, product versions and the codes used. Before bringing in any vendor to your company, check the list to be sure their product is PCI compliant.
Read more!
Friday, December 4, 2009
iPhone App Developer Sued for User Phone Number Theft
As the saying goes, it’s not IF, but WHEN will your personal information will be stolen in a data breach.
On October 8, 2009 I wrote a blog entitled “What’s the Value of Your Mobile Phone’s Address Book?” which highlighted the fact that iPhone applications have access to your phones entire address book and you are trusting that the developer is (hopefully) not a rogue one. This has been known since at least January 26, 2009. The possible abuse that my blog was aimed at pointing out to readers came to light recently. A class action lawsuit has been filed against app developer Storm8 and the full details of the proceedings can be found here.
Read more!
On October 8, 2009 I wrote a blog entitled “What’s the Value of Your Mobile Phone’s Address Book?” which highlighted the fact that iPhone applications have access to your phones entire address book and you are trusting that the developer is (hopefully) not a rogue one. This has been known since at least January 26, 2009. The possible abuse that my blog was aimed at pointing out to readers came to light recently. A class action lawsuit has been filed against app developer Storm8 and the full details of the proceedings can be found here.
Read more!
Subscribe to:
Posts (Atom)
Posts
