Security 101

Introduction

Almost any web application or mobile app can add payment processing, but integrating payment processing via mobile payment SDKs, APIs or web services engenders a security responsibility with the developer as much as with the end-user merchant. The following represents a high-level summary of some key security considerations for developers integrating with the Apriva Gateway™ to add payments to their mobile, web, traditional and/or unattended POS solutions.

Security Goals

• Maximize privacy and trust for users of payment systems
• Minimize fraud from cardholder not present (CNP) transactions
• Comply with all local laws and Payment Card Industry (PCI) standards

PCI, PCI DSS and PA-DSS

The major card brands of the Payment Card Industry (PCI) formed the Security Standards Council (SSC) in 2006.  The SSC manages a set of security requirements called the PCI Data Security Standards (PCI DSS) to mitigate fraud by better protecting cardholder data.  PCI DSS applies to any organization that comes in contact with payment card data, and compliance with the PCI DSS is enforced for banks, merchants, and service providers.  The liability for breaches of PCI DSS compliance can include fraud losses, brand damage, lawsuit exposure, and government oversight, so understanding the standards and developing solutions that comply with them is critical to anyone integrating payment processing.

Apriva, as a service provider, maintains PCI DSS compliance.

There is also a set of requirements for software developers and payment application vendors collected in the PCI Payment Application Data Security Standards (PCI PA-DSS).  PA-DSS was designed to help software vendors secure payment applications to protect storage of prohibited data, including the full magnetic stripe and the three- or four-digit security code (CAV2, CID, CVC2, CVV2) or PIN/PIN block found on payment cards.

For details on the current standards, please visit the PCI website at www.pcisecuritystandards.org. 

PCI DSS and PA-DSS for Mobile

With regard to integrating payment processing for mobile transactions or building a mobile credit card processing app, the PCI Security Standards Council has determined that one of the major risk factors is the environment the application operates within and the ability of that environment to support the merchant in achieving PCI DSS compliance.  As a result, the PCI SCC has categorized mobile payment acceptance applications into three separate categories based on the type of underlying platform and the platform’s ability to support PCI DSS compliance:

1. Mobile Payment Acceptance Application Category 1 – Payment application operates only on a PTS-approved mobile device.
2. Mobile Payment Acceptance Application Category 2 – Payment application meets all of the following criteria:
   
   1. Payment application is only provided as a complete solution “bundled” with a specific mobile device by the vendor;
   2. Underlying mobile device is purpose-built (by design or by constraint) with a single function of performing payment acceptance; and
   3. Payment application, when installed on the “bundled” mobile device (as assessed by the Payment Application Qualified Security Assessor (PA-QSA) and explicitly documented in the payment application’s Report on Validation (ROV), provides an environment which allows the merchant to meet and maintain PCI DSS compliance.
3. Mobile Payment Acceptance Application Category 3 – Payment application operates on any consumer electronic handheld device (e.g., smart phone, tablet, or PDA) that is not solely dedicated to payment acceptance for transaction processing.

For more information on these categories and PCI DSS and PA-DSS for mobile, please review the Mobile FAQs at https://www.pcisecuritystandards.org/documents/pa-dss_mobile_apps-faqs.pdf

Until the development of appropriate standards, PCI-SSC has provided security guidelines to help software developers and payment application vendors develop secure mobile payment applications until mobile point-of-sale payment applications can be certified. 

The council has released a guidance document on security best practices for Mobile Acceptance Application Category 3 devices, and recommended using the PA-DSS requirements as additional security guidance securely building and configuring these applications.  These recommendations include:

• Use Secure Coding practices:  Use industry-recognized secure coding practices when developing mobile POS payment applications to build secure and minimize vulnerabilities.
• Apply Software updates:  Distribute securely software updates to the applications and ensure the update source is properly authenticated.
• Manage Lost/Stolen devices:  Be able to manage lost and/or stolen devices through remote disabling of the payment application either from the remote mobile device or backend server.
• Protect Data/Privacy with Encryption:  Use of industry leading asymmetric and symmetric encryption algorithms for data-in-transit and data-at-rest.

For more details on mobile payment security guidelines for developers, please review the following PCI documents:

• www.pcisecuritystandards.org/documents/Mobile_Payment_Security_Guidelines_Developers_v2.0.pdf.

• www.pcisecuritystandards.org/documents/pa-dss_v3.2pdf

Secure Coding Practices

Merchants are ultimately responsible for protecting cardholder data at the point of sale and as that data flows into the payment system.  Software developers can help merchants with payment security by building POS and payment systems that:

• Force the use of Strong Passwords:  During the installation of POS systems, installers often use the default passwords for simplicity on initial setup.  Unfortunately, the default passwords can be easily obtained online by cybercriminals.  As such, it is highly recommended that business owners change passwords to their POS systems on a regular basis, using unique account names and complex passwords.
• Manage Vulnerabilities: New threats and risks are identified every day.  So for systems that have updates, make sure to apply critical and high security patches when they become available.  Make sure to retrieve those updates from trusted vendors and sources.
• Install Malware Protection Software:  Deploy security software to detect and prevent malicious software threats.  Make sure to keep malware signatures up-to-date and only download from trusted sources.
• Disable Unnecessary Functions:  Encourage system users to disable any unnecessary features and functionality.  Do so reducing the threats that can be used against systems in the environment.
• Protect Account Data:  Implement an access control model that only allows authorized personnel access to data based on need.  For those users who don’t need access, don’t give it to them. Use access permissions to limit access accordingly.

For more information on payment security guidelines for merchants, please review the

www.pcisecuritystandards.org/documents/Mobile_Payment_Security_Guidelines_Merchants_v2.0pdf

Developers can implement secure application standards by leveraging a combination of industry standards and secure application development tools.  Two of the more significant industry standards providing guidance on secure application development include OWASP and OpenSAMM. 

OWASP

The Open Web Application Security Project (OWASP) is a security project and an emerging standards body whose goal is to create a set of commercially viable standards tailored to specific web-based technologies.  The primary aim of the OWASP ASVS Project is to improve application-level security.  The OWASP community includes individuals and organizations around the world working to create application security articles, methodologies, documentation, tools, and technologies.

OWASP has created a comprehensive manual for architects, developers, consultants, and auditors, guiding the design, development, and deployment of secure Web Applications and Web Services.  The Development Guide is referenced by many leading government, financial, and corporate standards and is the Gold standard for Web Application and Web Service security.  The current version can be found at https://www.owasp.org/index.php/Category:OWASP_Guide_Project.

For more information on current OWASP standards, initiatives, and resources please visit www.owasp.org.

OpenSAMM

The Software Assurance Maturity Model (SAMM) is a framework that helps organizations develop and design a software development security plan that meets the specific risks the organization faces.  The model provides a strategy for assessing the software security practices of an organization and measuring improvement along the way.  OpenSAMM is divided into four security areas:  Governance, Construction, Verification, and Deployment.  These areas then contain security processes (e.g., Security Requirements, Code Review, Security Testing, and Vulnerability Management) that are evaluated against a maturity level to measure where the existing software security program exists.  The current version of the OpenSAMM model can be found at http://www.opensamm.org/downloads/SAMM-1.0.pdf.

For more information on OpenSAMM related initiatives and resources, please visit http://www.opensamm.org/.

Application Security Tools

Risks and vulnerabilities are constantly emerging based on advancements in technology and changes in our daily lives.  Software development similarly has coding languages that evolve and change, underlying platforms that move between local data centers and the cloud, and a growing need for dynamic, web-accessible content.

To help manage the security risks within developed applications, application security tools are available to help test web applications and mobile apps for known coding vulnerabilities and issues.  The use of static code analysis tools and dynamic security scanners can help bolster the security of new applications, and integrating analytic tools within the development lifecycle is key to managing security risk during application development.

Some common tools include:

• Static Application Security Testing (SAST):  A set of tools that analyze application source code, byte code and binaries for application development and design conditions that present security vulnerabilities in a non-running state.
• Dynamic Application Security Testing (DAST):  Tools that detect security vulnerabilities in an application, predominantly web applications and their HTTP, HTTPS, and HTML interfaces.
• Interactive Application Security Testing (IAST):  Testing platforms that integrate static code analysis techniques with dynamic application testing to provide detailed recommendations on correcting and addressing security vulnerabilities.

Protect Data/Privacy

Finally, the PCI DSS standards require that the sensitive authentication data found on the credit card is not stored on local devices or networks.  This includes the full magnetic stripe, the 3 or 4 digit security code (CAV2, CID, CVC2, CVV2), or the PIN/PIN block found on the card, as this data provides additional layers of security when a primary account number and expiration date are known.

For recurring payments, merchants may store account numbers and expiration dates, but that stored data must be carefully secured and still represents a tremendous risk to the merchant (as the 2013 holiday breach at Target Corporation dramatically showed).