Thursday, April 9, 2009

What happens when a company gets hacked?

So what exactly happens when a company's website gets hacked. Is there anything setup that actually tries to identify if sensitive information has been obtained? Is there anything setup that helps verify that the company has indeed identified the issue and verified that the vector has been secured. I am going to have to say that for the majority if companies out there, the answer is no. What I have seen from personal experience is that the most important aspect of being hacked as a company, is to get the site back online and do anything necessary to make sure that the trust of the customer has not been lost. Currently, the way that things are setup (such as PCI), most companies do not disclose that they have been compromised, because it will have a serious impact in the trust of their site ultimately ending up with fewer sales.

There is something seriously wrong with this.

There is nothing that really mandates that a company disclose any information to the public or their customer other than individual state laws that have been put in place that most companies don't even know about. Now, I understand that we will always be faced with this issue that we will always have companies that will do anything necessary to not disclose their compromise and we will never be able to fully eliminate this issue.

What I believe that needs to be accomplished, is that PCI sets up a requirement or method that ASV/QSA's must take if a customer informs them that they have been compromised. There must be a standard setup that an ASV/QSA can follow that mandates the company to disclose the issue. It must also be the ASV/QSA's job to work with the company, to assist with identifying the vector that the compromise occurred with, and verifying that the vector has been secured.

If a company is required to disclose a compromise no matter what the size or impact may be, they will be a little more proactive in making sure that their website is secure. I understand that a company must worry about the affect of a disclosure but honestly, they have been compromised, and they should not have a choice. Their customers have the right to know that the site was insecure and that their personal information might have been revealed.

Also going in parallel with the fact that they have been compromised, is the understanding their website was indeed insecure and therefore they should not solely be responsible for mitigating the issue. They should be required to have their ASV/QSA assist them with the compromise and verify that they have indeed resolved all issues of insecurity.

If anyone out there knows the security of their website better than the company itself, I would say that it is their ASV/QSA or the attacker who was able to compromise their site. As an ASV/QSA you are usually able to get an opinion of the companies level or activeness in security by being able to monitor how long it takes them to fix an issue or their overall understanding of security. From this information the ASV/QSA will be able to generate a basic opinion of the companies overall determination to be secure. This can be used to assist the company in making sure that they are conducting the right operations to secure the website and are getting it right the first time. At the same time, the ASV/QSA can assist the company in preparing a public statement that identifies to their customers that they have been compromised. This will also verify that the company does not take the compromise lightly and release a public statement that does not accurately describe the level of compromise.

I want to close by asking, if any of you even know that Visa has a document of "What to do if Compromised" and if you have ever heard of a company ever following the procedure.
http://usa.visa.com/download/merchants/cisp_what_to_do_if_compromised.pdf

Also Check out.
PCIsecuritystandards.org keyword search for "Hacked"
PCIsecuritystandards.org keyword search for "Compromised"
Ill save you the excitement, They return 0 Results

What about these answers from the PCI council

If my business was deemed compliant but my system was still breached and payment account data compromised after the fact, what liability would my business incur?
--The PCI Security Standards Council is not responsible for levying any financial or operational consequences on businesses that have either been breached or are suspected of an account data compromise. These businesses should contact the individual payment brands regarding next steps, such as contacting law enforcement, or obtaining other relevant information, including potential consequences should a compromise have occurred.

Will the PCI Security Standards Council be involved in performing forensics investigations as a result of an account data compromise event?
--The PCI Security Standards Council will not conduct forensics investigations either directly or through a third party in the event of an account compromise.

1 comments:

5h4d0w said...

All shopping cart apps will need to be PA-DSS compliant by July 1, 2010. I found this entry on the xcart forum:

As many of you may know, as of July 1, 2010 you will be required to use a PA-DSS certified shopping cart if you want to accept credit card payments ON your site. That means using a payment gateway like Authorize.net AIM where the user inputs their credit card data on the final page of checkout. This requirement will be necessary to maintain PCI-DSS compliance, which is required for ALL companies who process credit cards for sales.

An alternative will be to use an offsite gateway, meaning sending the user to the actual payment gateway site (like 2checkout and PayPal) where you enter the credit card data. This will allow you to avoid the PA-DSS compliance issue, but as you also know it looks rather unprofessional.