Knowledge Base Best Practices

Cloud Based Point of Sale and E-Commerce

TSYS offers multiple secure payments solutions for its partners' cloud-based Point of Sale systems and E-Commerce sites. While TSYS' products are designed to keep cardholder data out of our partners' (and your merchants') environments, it's important to note that certain technical and operational requirements may still apply, and that attacks against your POS or E-Commerce site that may compromise cardholder data are still possible. Below are some best practices that many of our partners employ and can help protect your sites - and mitigate the damages - from things such as:
  1. Various Cross Site Scripting (XSS) attacks, which would execute scripts in the contexts of your users' browsers.
  2. Injection attacks, which might allow a malicious third party to deliver a payload to your site that would make an XSS attack possible.
Disclaimer: It is important to understand that while we've included a number of website security best practices below in order to help you meet your security obligations when handling sensitive information like cardholder data and personally identifiable information, this list is neither infallible nor exhaustive, nor should you solely rely on the information provided as authoritative in how to secure your sites. You are responsible for your site's security in compliance with PCI-DSS and applicable federal, state, and local privacy laws, so you must take appropriate measures to ensure the safety of the cardholder and personally identifiable information that your web sites might collect. And remember - if you are a merchant, or you are a provider helping merchants accept payments - be it in store or online - you are still in scope for the requirements and obligations of PCI-DSS regardless of any technological solutions that you may implement.

We recommend that all E-Commerce and POS vendors familiarize themselves with the PCI DSS E-Commerce Guidelines and PCI Best Practices for Securing E-Commerce documents, and the guidance & responsibilities enumerated therein.

Summarized Best Practices

  • Incorporate an application security framework, such as the OWASP Top 10, into your SDLC. As software increases in importance, and as breaches continue to proliferate through the application layer, organizations will need a proven and holistic approach to security. An application security program that uses a mix of technologies and services to secure the entire application landscape, and each application throughout its lifecycle, is becoming a necessity. The OWASP Top 10 Cheat Sheet provides a developer-centric defensive cheat sheet and presents a quick reference based on OWASP Testing Project to help developers identify common risks and vulnerabilities.
  • Incorporate Secure Coding Practices into your SDLC. The OWASP Secure Coding Practices Quick Reference Guide is a technology agnostic set of general software security coding practices, in a comprehensive checklist format, that can be integrated into the development lifecycle. At only 17 pages long, it is easy to read and digest. The focus is on secure coding requirements, rather than on vulnerabilities and exploits. It includes an introduction to Software Security Principles and a glossary of key terms. It is designed to serve as a secure coding kick-start tool and easy reference, to help development teams quickly understand secure coding practices.
  • Defend yourself against Cross Site Scripting (XSS) attacks. Cross-site scripting (XSS) attacks bypass a browser's same origin policy by tricking a site into delivering malicious code along with the intended content. This is a huge problem, as browsers trust all of the code that shows up on a page as being legitimately part of that page's security origin. The XSS Cheat Sheet is a dated but representative cross-section of the methods an attacker might use to violate this trust by injecting malicious code. If an attacker successfully injects any code at all, user session data is compromised and information that should be kept secret is exfiltrated to The Bad Guys. While there are a huge number of XSS attack vectors, following a few simple rules can help defend and protect your sites and customers against this serious attack vector.
  • Implement a Content Security Policy (CSP). A restrictive Content Security Policy, implemented using the "Content-Security-Policy" HTTP header, can help prevent against XSS attacks by disallowing browsers from downloading malicious scripts, and preventing malicious scripts from uploading data to untrusted servers. A CSP is a browser side mechanism which allows you to create source whitelists for client side resources of your web application, e.g. JavaScript, CSS, images, stylesheets, fonts, and other resources used in serving up your web pages. The CSP - via a special HTTP header - instructs the browser to execute, download, or render resources from only those sources you've whitelisted.
  • Validate your inputs.  User input could come from a variety of sources - an end-user, another application, a malicious user, or any number of other sources. It is always recommended to prevent attacks as early as possible in the processing of the user’s (attacker's) request. Input validation can be used to detect unauthorized input before it is processed by the application, as data originating from a third party cannot be trusted and must be subject to scrutiny. Most application development frameworks have standard, built-in routines to help you validate inputs against common errors.
  • Implement Strict-Transport-Security. HTTP Strict Transport Security (HSTS) is a simple and widely supported standard to protect visitors by ensuring that their browsers always connect to a website over HTTPS. HSTS exists to remove the need for the common, insecure practice of redirecting users from http:// to https:// URLs.
  • Disable autocomplete on any form fields that may contain sensitive data. This prevents browsers from storing Cardholder Data.
  • Ensure sensitive data is not stored in cookies.
  • Implement X-Permitted-Cross-Domain-Policies. This HTTP header behaves much like a Content Security Policy, except it applies to Adobe Acrobat/Flash content. You can configure Acrobat products to allow cross domain access for PDFs in one domain that attempt to access data from another domain. By default, when requested content is not from the same origin as the requesting document, Acrobat and Adobe Reader automatically attempt to load a server-based policy file from that domain to get permission for such access. Default behavior is subject to customization by administrators, IT, workflow stakeholders, and others who need to enable or disable cross domain access.
  • Implement a Web Application Firewall in front of your application servers. A web application firewall (WAF) is an application firewall for HTTP applications. While proxies generally protect clients, WAFs protect servers. A WAF is deployed to protect a specific web application or set of web applications. WAFs apply a set of rules to an HTTP conversation, helping prevent against common attacks such as cross-site scripting (XSS) and SQL injection.
  • Implement an Intrusion Detection System (IDS). An intrusion detection system (IDS) is a device or software application that monitors a network or systems from malicious activity or policy violations. Any detected activity or violation is typically reported either to an administrator or collected centrally using a security information and event management (SIEM) system. A SIEM system combines outputs from multiple sources, and uses alarm filtering techniques to distinguish malicious activity from false alarms.
  • Implement an Intrusion Prevention System (IPS). An Intrusion Prevention System (IPS) is a network security/threat prevention technology that examines network traffic flows to detect and prevent vulnerability exploits. Vulnerability exploits usually come in the form of malicious inputs to a target application or service that attackers use to interrupt and gain control of an application or machine. Following a successful exploit, the attacker can disable the target application (resulting in a denial-of-service state) or can potentially access to all the rights and permissions available to the compromised application.
  • Run vulnerability scans against your software, such as Burp Suite or OWASP ZAP. You can use these tools to scan all of your applications regularly to gain an enterprise-wide view of your exposures. Tools like Burp and ZAP show you exactly where the most significant vulnerabilities exist, and you can drill down into individual applications, or even single URLs and parameters, to view vulnerabilities in more detail. Issues are classified by type and severity, and contain full details of how to remediate each vulnerability. Issues are also mapped to common vulnerability classification schemes, such as CWE and the OWASP Top Ten, to help you quickly understand the nature of each issue in familiar terminology.
  • Harden your servers and applications using a well-established framework, such as the CIS Controls or NIST Cybersecurity Framework. These controls are a prioritized set of cyber practices created to stop today’s most pervasive and dangerous cyber attack, and are developed, refined, and validated by a community of leading experts from around the world. Organizations that apply just these controls can typically reduce their risk of cyberattack substantially.
  • Work with security experts and QSAs. If you are creating a payment application, you are part of the PCI chain and should work with qualified experts to ensure your solution is secure and PCI compliant.