- Did CardSystems Solutions break any federal or state law?
Yes.
CardSystems Solutions was charged by the Federal Trade Commission “with
violation of the Federal Trade Commission Act, 15 U.S.C. § 45 et seq;” [1] – “Unfair
methods of competition in or affecting commerce, and unfair or deceptive acts
or practices in or affecting commerce, are hereby declared unlawful.” [2]
The FDC complaint says that CardSystems Solutions’ “failure to employ
reasonable and
appropriate security measures to protect personal information it stored caused or is likely
to cause substantial injury to consumers that is not offset by countervailing benefits to
consumers or competition and is not reasonably avoidable by consumers. This practice
was, and is, an unfair act or practice.” [3]
- In June 2004, an external auditor certified CardSystems Solutions as Payment Card Industry Data Security Standard- (PCI DSS-) compliant. What is your assessment of the auditor’s findings?
In June 2004, Savvis Inc. certified CardSystems Solutions to be PCI DSS compliant. However, in 2005, CardSystems was subjected to a crippling data breach and a security assessment done at that stage proved that the company was not PCI DSS compliant.
In the light of these findings, I think
Savvis Inc. wasn’t thorough, wasn’t careful enough, wasn’t accurate, and wasn’t
complete in their auditing process.
However, one may give Savvis the
benefit of the doubt, as the audit had been done almost a year ago, and
CardSystems Solutions was due for their annual audit in the month the breach
was discovered. [4]
In a wired.com article from June 2006 (when the breach was made public), it is
interesting to read that in June 2003, CardSystems attempt to get PCI DSS
compliant had been rejected by Visa as “they had more work to do to become more
fully compliant” and was approved the following year after Savvis’ audit. [4]
A comparison between the failed Visa report and the one that Savvis presented
could show the levels of negligence or even corruption.
Security expert Schneier, in the same article says that “the compliance process
has to have integrity” as “a lot of (compliance involves) self-certification.
It’s things you say you do. And it’s only audited minimally.”
I do think the authenticity and accuracy of the auditors’ methods and evaluations, becomes very questionable.
- Can CardSystems Solutions sue the auditor for not performing his or her tasks and deliverables with accuracy? Do you recommend that CardSystems Solutions pursue this avenue?
I think while CardSystems is mostly to
blame for the breach, Savvis, the external auditors, share some of that
responsibility. And yes, they can sue Savvis for not performing their audit
with accuracy and completeness.
I do recommend that CardSystems Solutions sue Savvis as it is necessary for
auditors to be held accountable for the accuracy and authenticity of their
reports. Further, the risk of legal action can also “force increased scrutiny
on largely self-regulated credit card security practices.” [5]
In fact, in June 2009, four years after the breach, Savvis was taken to court by
Merrick Bank, who had contracted with CardSystems during the time of the
breach. (In 2009, CardSystems had already gone out of business.)
Merrick Bank v. Savvis Inc. was seen as a “legal first” where an auditor was held
liable for a data breach. [5]
- Who do you think is negligent in the case study and why?
I think while CardSystems Solutions is definitely
negligent in this case, the auditors Savvis Inc. may be shown to be negligent
as well.
The security assessment done after the breach showed that-
- The attack was through an SQL injection on a
public user interface [5]
CardSystems should have designed their interfaces and databases more securely and tested them more rigorously and regularly. - The system did not have strong passwords [5]
This points to lack of company policies on passwords and negligence of Admins.
- The system did not have adequately secure
firewalls and the anti-virus wasn’t update with latest definitions. [5]
This is a the most basic security measure and it points to grave negligence on the part of CardSystems Solutions.
The lack of a secure firewall can also show that Savvis Inc., was negligent in their audit. - CardSystems was “improperly holding consumer
credit card data by keeping a file on credit card transactions that failed to
receive authorization.” [7]
In fact, in a July 2005 CNN web article, Bill Reeves, the then CardSystems’ Senior Vice President is quoted: “We were out of compliance and we recognize that file was out of compliance with the association rules.” [7]
Apart from these glaring indications of negligence, I also think the company analysts should be aware of the audits, even when done by third-parties. They need to perform their own internal audits periodically to help maintain the compliance standards. CardSystems definitely neglected in doing this.
- Do the actions of CardSystems Solutions warrant an “unfair trade practice” designation as stated by the Federal Trade Commission (FTC)?
Yes, I do think that the actions of CardSystems Solutions warrant an “unfair trade practice” designation by the FTC.
A PCI DSS compliance implies an acceptable
level of security standards, which help stakeholders to trust and deal with the
company. CardSystems had a responsibility towards maintain this.
The security assessment that was done after the breach showed many grave
vulnerabilities, lack of adequate security and also negligence on the part of
CardSystems Solutions.
The February 2006, FTC press release states that “CardSystems kept information it had no reason to keep and then stored it in a way that put consumers’ financial information at risk” [6] and that their “failure to employ reasonable and appropriate security measures to protect personal information it stored caused or is likely to cause substantial injury to consumers that is not offset by countervailing benefits to consumers or competition and is not reasonably avoidable by consumers. This practice was, and is, an unfair act or practice.” [3]
- What security policies do you recommend to help with monitoring, enforcing, and ensuring PCI DSS compliance?
Some specific policies which help with monitoring, enforcing, and ensuring PCI DSS compliance could be [8]-
- Firewall Requirements and Configuration Policy
- Anti-Virus Policy
- Software Development Secure Coding Guidelines and Training Policy
- Custom Application Code Change Reviews Policy
- Security Patch Management Installation Policy
- Data Retention and Disposal Policy
- Strong Cryptography and Protocols Policy
- Database Access & Configuration Settings Policy
- Internet Access to the Cardholder Data Environment Policy
- Configuration Standards for All System Components Policy
- Changing of Vendor Supplied Default Settings Policy
- Non-Console Administrative Access Policy
- Sensitive Authentication Data (SAD) Storage Policy
- Data Control & Access Control Policies
- Shared, Group, Generic, and Other Authentication Methods Policy
- Media Storage, Distribution and Classification Policy
- Media Destruction Policy
- Physical Security Policy
- Securing of Audit Trails Policy
- Security Logs & Events Policy
- Workstation & Laptop Usage Policy
The first ten would have especially helped in the given CardSystems case study.
- What security controls and security countermeasures do you recommend for CardSystems Solutions to be in compliance with PCI DSS requirements?
- Firewall Requirements and Configuration – this would have ensured that most secure firewall was installed and configured.
- Anti-Virus Updating – ensuring the anti-virus is always updated with the latest definitions
- Software Development & Secure Coding – this would have prevented the vulnerability in the user interface which allowed the SQL injection
- Security Patch Management – all software are regularly updated with latest security patches
- Data Retention and disposal – this would have prevented the storage of the card holders’ information in unencrypted text files (which the company admitted to doing)
- Strong Cryptography and Protocols Policy – no data would be unencrypted
- Database Design and Access – secure database designs and access control, could have prevented the SQL injection from manipulating it, even if the user interface had allowed it in
- Periodical internal audits – could have ensured that the firewall and anti-virus was secure enough and updated
- What was the end result of the attack and security breach to CardSystems Solutions and its valuation?
The security evaluation that followed the attack and breach showed that CardSystems Solutions was not PCI DSS compliant. Investigation done by the Federal Trade Commission further exposed their flaws and negligence, and the FTC alleged that CardSystems Solutions [6] –
- created unnecessary risks to the information by storing it;
- did not adequately assess the vulnerability of its computer network to commonly known or reasonably foreseeable attacks, including “Structured Query Language” injection attacks;
- did not implement simple, low-cost, and readily available defenses to such attacks;
- did not use strong passwords to prevent a hacker from gaining control over computers on its computer network and access to personal information stored on the network;
- did not use readily available security measures to limit access between computers on its network and between its computers and the Internet; and
- failed to employ sufficient measures to detect unauthorized access to personal information or to conduct security investigations.
CardSystems Solutions was charged by the Federal Trade Commission “with violation of the Federal Trade Commission Act, 15 U.S.C. § 45 et seq;” [1] – “Unfair methods of competition in or affecting commerce, and unfair or deceptive acts or practices in or affecting commerce, are hereby declared unlawful.” [2]
CardSystems Solutions was subsequently
dropped by Visa and AmericanExpress.
The company ceased to exist after it was acquired by Pay By Touch in December
2005.
- What are the possible consequences associated with the data loss?
The first fallout would be fraudulent
purchases and card usage – resulting in massive financial losses and mayhem, as
“over 40 million” [7] cards’ accounts were exposed.
The second, and equally important one, would be identity theft, as sensitive
personal and financial data was breached. This data could be used for gaining
access to other databases which relied on the same identity parameters for
authentication, and the consequences could expand to more crime and complete
identity theft.
- Who do you think is ultimately responsible for CardSystems Solutions’ lack of PCI DSS compliance?
CardSystems Solutions is responsible for the breach. They need not have the policies, the controls, measures and practices to prevent, detect or handle breaches and to safeguard and protect the network and the data. As a PCI DSS compliant company they had a legal and moral responsibility to adhere constantly to the standards and not only rely on annual audit reports.
- What should CardSystems Solutions have done to mitigate possible SQL injections and data breaches on its credit card transaction-processing engines?
Some ways that CardSystems could have mitigated possible SQL injections are [9]-
- Secure software design and development – this will take care of input data evaluation and implementing input constraints.
- Security software testing – Apart from regular checks, it will also detect stray unused dead-end interfaces which may be outdated, unlinked and unused (orphan pages), but highly vulnerable
- Updates and patches – on all software – in-house and third-party ones.
- Secure database designs – to prevent, log and shutdown unauthorized queries and unrecognized (like dynamic SQL)
- Encryption – of all data – input, on the network, in the database.
- Passwords – frequently updates strong passphrases, instead of weak passwords
- True or false: Although CardSystems Solutions had proper security controls and security countermeasures, it was not 100 percent PCI DSS-compliant because the company failed to properly implement ongoing monitoring and testing on its development and production systems.
True.
Even if we assume that the audit done by Savvis in June 2004 was accurate, and
that CardSystems Solutions was authentically 100% PCI DSS -compliant at that
time, it was their (CardSystems’) responsibility to implement ongoing
monitoring and testing on its production and development systems.
This would have ensured that the compliance standards were maintained, without a break, until the next annual audit, and it could have prevented the breach.
References
[1] Federal Trade Commission. DECISION AND ORDER. 199-226. Retrieved from https://www.ftc.gov/sites/default/files/documents/cases/2006/09/0523148cardsystemsdo.pdf
[2] 15 U.S. Code § 45 – Unfair methods of competition unlawful; prevention by Commission. (n.d.). Retrieved from https://www.law.cornell.edu/uscode/text/15/45
[3] Federal Trade Commission. COMPLAINT. Retrieved from https://www.ftc.gov/sites/default/files/documents/cases/2006/02/0523148complaint.pdf
[4] https://www.wired.com/2005/06/cardsystems-data-left-unsecured/
[5] In Legal First, Data-Breach Suit Targets Auditor. (n.d.). Retrieved from https://www.wired.com/2009/06/auditor_sued/
[6] CardSystems Solutions Settles FTC Charges. Retrieved from https://www.ftc.gov/news-events/press-releases/2006/02/cardsystems-solutions-settles-ftc-charges
[7] Breach affects 40M+ credit cards. (n.d.). Retrieved from http://money.cnn.com/2005/06/17/news/master_card/
[8] Complete Policy List. (n.d.). Retrieved from https://pcicompliance.stanford.edu/complete-policy-list
[9] 10 Ways to Prevent or Mitigate SQL Injection Attacks. (n.d.). Retrieved from http://www.enterprisenetworkingplanet.com/netsecur/article.php/3866756/10-Ways-to-Prevent-or-Mitigate-SQL-Injection-Attacks.htm