Last updated at Wed, 15 May 2019 14:48:02 GMT
If your app handles payments, you are undoubtedly familiar with the security rules surrounding credit card transactions. The Payment Card Industry (PCI) Security Standards Council has written a lengthy document for keeping card data safe to reduce fraud. If you want to take credit cards through your app, you’ve undoubtedly heard of the PCI Data Security Standard (DSS).
What role does application security have in your security strategy? Well, keeping you out of the headlines is one important one – the breach de la semaine is Ticketmaster, which I hope to write a follow-up post on. If you want an in-depth analysis now, don’t miss Kevin Beaumont’s take. (We’ll have a lot more to say about this because the attack vector used in the compromise is new and not really well-addressed by the current PCI standard.)
Not making headlines is most obvious result of an effective information security program (with apologies to Sir Arthur Conan Doyle, it is too bad that security is often the dog that does not bark; that is, there is never a story about a breach that does not occur). To achieve that goal, the PCI DSS outlines a comprehensive information security program for protecting credit card data.
The current version of the PCI DSS is 3.2.1, recently published in May 2018. The general areas of the DSS reflect the evolution of information security, starting with reminders to change your default passwords and use network-layer protection. For the purpose of this blog post, I’m going to focus on the requirement to “[d]evelop and maintain secure systems and applications,” given how many attacks occur at the network layer.
Section 6.6 notes that public-facing applications exposed to the fury of the Internet need continuous protection, and must be protected against the emerging threat landscape by using vulnerability assessment tools, or by installing a system that checks all web traffic in front of web-based systems. The DSS offers a WAF as an example, though the goals would be met by a next-generation WAF or RASP. Auditors need to ensure that the system is installed (no shelfware allowed!) and is configured to “either block web-based attacks, or generate an alert that is immediately investigated.” Given the expense in building a round-the-clock security operations team to manually assess alerts, almost everybody opts to use a technical solution.
The tCell approach to application security is based on using visibility into the application’s run-time behavior, rather than intercepting network traffic to make predictions about an application’s response to attacks. With deep visibility into how your application normally behaves, we can generate alerts only for traffic that deviates from the norm and matches an attack classification. Our sophisticated cloud analytics system classifies traffic in real-time and virtually eliminates false positives.
We hired Strata Consulting, experts in many types of technology compliance work including (of course!) PCI, to analyze PCI compliance requirements with respect to the tCell product. Their report is here. The bottom line: PCI DSS section 6.6 requires that you protect applications, but its broad guidance allows you to pick an automated technical solution that meets requirements. You don’t need to go with a last-generation security product because you’re free to pick something that meets your needs in today’s high-velocity DevOps world. Looking for a way to protect cardholder data in your app? We’d love to hear from you!