The e-commerce and retail fields have undergone mammoth changes over the last decade. Paying in hard cash has almost become a thing of the past. Credit and debit cards are now being used to conduct millions of transactions and e-shopping purchases on a daily basis worldwide. But this new reality has also introduced numerous security perils.
2014 saw the number of reported breaches in USA skyrocket to a record number of 783, according to a study released by the Identity Theft Resource Center (ITRC). More than 675 million records with personal information have been compromised since 2005. These developments have led to the creation of a standard for all organizations handling credit and debit card data.
The Payment Card Industry Data Security Standard (PCI DSS) consists of a set of 12 requirements that help create a secure environment for all companies that process, store or transmit credit card information. The PCI DSS was created jointly in 2004 by four major credit-card companies: Visa, MasterCard, Discover and American Express.
PCI DSS talks extensively about using secure applications in payment mechanisms and e-commerce websites/servers. Source Code Analysis (SCA) is an AppSec solution that ticks the PCI DSS checkboxes.
Exponential Rise in Cybercrime
To understand the dangers of operating without PCI DSS compliance, it’s important to take look at the Target hackings that took place during the holiday season of 2013. Extensive privacy violation took place due to the breach and the commercial giant had to eventually shell out millions of dollars for damage control and other added expenses.
The hacking events took place around the Black Friday of 2013, with the initial exposure made on the Krebs on Security blog. Over 40 million credit and debit card account numbers were reportedly compromised in just a couple of weeks. The culprit was a third party component in the system that was not compliant with the PCI DSS protocol.
Similar hackings also took place at the premises of another mega-retailer, Home Depot. Just like with the Target, these breaches took place around September 2014. Around 56 million payment card details were compromised and over 53 million customer email IDs were harvested. Hackers reportedly infiltrated the company databases via a vulnerable supplier.
These are only two instances amongst a series of hackings that are taking place all around the world on almost a daily basis. These can be related to poor application code integrity, software bugs or simply careless storage of sensitive data. As a result, the PCI DSS standard has become mandatory for US merchants since 1 January 2015.
How does PCI DSS address application layer security?
Out of the total 12 requirements in the PCI DSS protocol, there are 3 requirements that are directly related to application security. These AppSec related requirements are:
Requirement 3: Protect Stored Cardholder Data
With online payments and transactions gaining steam, millions of users input their personal details and payment method data. This sensitive information is stored either in the organizations databases or on third-party servers, which need to be secure in order to prevent catastrophes similar to those mentioned earlier in the article.
PCI DSS stresses the importance of using proper encryption tools and techniques while handling sensitive information. There should also be no sending of unprotected Primary Account Numbers (PANs) using unencrypted emails or instant messaging. Subsection 3.4 of the PCI DSS specification even talks about rendering PAN data unreadable whenever possible.
Requirement 6: Develop and maintain secure systems and applications
The exponential rise in cybercrime has made software vendors play catch-up with the hackers and release security patches. This allows the closing of the loopholes created by unsecure coding practices and development flaws. E-commerce and financial concerns should make sure these patches are applied as soon as they are officially released.
PCI DSS also recommends proper QA after applying the aforementioned software patches, which often create conflicts with previously defined security configurations.
Requirement 11.3: Implement a methodology for application layer app testing
Application layer vulnerabilities are risky if exposed and exploited, calling for the implementation of application testing solutions. While PCI DSS speaks about Penetration (Pen) Testing, other techniques such as Static Application Security Testing (SAST) can also be used to secure the applications being used for transactions and data storage.
Enforcing PCI DSS Compliance with Source Code Analysis
While Pen Testing is a viable tool to test the robustness of the application after its release, it’s has limited coverage and is quite costly to implement on a constant basis. Organizations need more comprehensive methods to secure their code. The two main methodologies in practice today are Static Application Security Testing (SAST) and Dynamic Application Security Testing (DAST).
Dynamic Application Security Testing (DAST), also known as Black Box testing, is an effective and proven solution. But its inherited qualities such as incapability to scan uncompiled code and inability to secure the Software Development Life Cycle (SDLC) in CICD or Agile/DevOps environments can be detrimental to the security efforts. This is where SAST or White Box testing enters the picture.
Source Code Analysis (SCA), a leading SAST solution, helps enforce PCI DSS compliance by:
- Scanning source code and locating vulnerabilities early in the SDLC.
- Having the ability to be integrated in CICD and Agile/DevOps scenarios.
- Enabling security automation at all stages of the development process.
- Providing wide scripting language and framework coverage.
- Pinpointing flaws and simplifying/shortening the remediation process.
PCI DSS has become a necessity due to the consumer activity shifting towards online and computerized methods. While robust applications with good code integrity is not enough to achieve full PCI DSS compliance, it’s crucial in shutting down the loopholes that let the hackers in more often than not.