INCREASE APPLICATION SECURITY FOR PCI DSS VERSION 3.1 SUCCESS
Protect Critical Enterprise Applications and Cardholder Information with Enterprise Application Access Scope and Audience This guide is for anyone who needs to understand how Enterprise Application Access (EAA) can meet the requirements outlined in the Payment Card Industry Data Security Standard version 3.1 (PCI DSS). The PCI DSS was developed to assist organizations in ensuring a comprehensive structure for the protection of Cardholder Data (CHD) by incorporating a multitude of validated requirements for People, Process, and Technology controls. Merchants who process, store, or transmit credit card information must comply with PCI DSS. EAA assists organizations in addressing multiple requirements as part of an overall PCI compliance program. Introduction The Payment Card Industry Data Security Standard (PCI DSS) has rigorous and prescriptive requirements for securing access to internal systems for the purposes of remote administration and support. With the goal of ensuring a comprehensive structure for the protection of Cardholder Data (CHD), remote access is one of the most sensitive areas of PCI DSS. EAA helps companies protect the integrity of their network and the privacy of sensitive data, like credit card information. EAA delivers a radical new approach to secure access that meets the strict requirements for remote access in environments subject to PCI DSS for all enterprise applications hosted behind data center firewalls and hybrid cloud environments. EAA is more simple, secure, and convenient to deploy than existing products. Unlike traditional VPNs, VDI, and remote desktop solutions, EAA: Ensures remote access users only get access to the specific applications they are authorized for and nothing else on the network. EAA s unique dual-cloud architecture closes all inbound access access to your infrastructure, reducing your attack surface. No one can get to apps directly; enterprise applications are hidden from the Internet and public exposure Provides secure remote access to applications in minutes. EAA s initial deployment and ongoing support require no network changes, endpoint clients, or truck rolls. The IT workload is lightened substantially, enabling teams to work on more strategic initiatives Integrated logging and reporting of all accesses. EAA keeps a complete audit trail of access attempts to each application, including a searchable transcript of each SSH administrative session Enables a fast, seamless, and hassle-free end-user experience. Instead of using a cumbersome VPN client, end users gain access to applications through any browser or mobile app. They enter their credentials username, password, and optional multi-factor authentication to identify themselves and are dynamically provisioned access to private enterprise applications This document focuses on the information security features of EAA as it pertains to the PCI DSS and assumes you already have a basic understanding of both EAA and the PCI DSS. Additional information on the PCI DSS program can be found at www.pcisecuritystandards.org.
Payment Card Industry Data Security Standard Compliance EAA contains various security and administrative capabilities that can be used to meet the PCI DSS requirements. The table below describes some of these features as well as which PCI DSS requirement(s) each feature may meet in the customer s environment. This list is not intended to be exhaustive, but rather a highlight of the key controls to consider in regards to the PCI DSS program. 1. Install and Maintain a Firewall Configuration to Protect Cardholder Data 1.3 : Prohibit direct public access between the Internet and any system component in the cardholder data environment 1.3.1 : Implement a DMZ to limit inbound traffic to only system components that provide authorized publicly accessible services, protocols, and ports 1.3.2 : Limit inbound Internet traffic to IP addresses within the DMZ 1.3.3 : Do not allow any direct connections inbound or outbound for traffic between the Internet and the cardholder data environment EAA acts as a cloud-based perimeter that locks down all inbound access to connected internal resources while providing secure access without ever exposing the resources to public-facing networks (the Internet), thus providing logical separation between internal assets and the Internet. 2. Do Not Use Vendor-Supplied Defaults for System Passwords and Other Security Parameters 2.3 : Encrypt all non-console administrative access using strong cryptography. Use technologies such as SSH, VPN, or TLS for web-based management and other non-console administrative access All management and data connections in EAA utilize n number of mutually authenticated Transport Layer Security (TLS) sessions at all layers and enforce v1.2 for connectivity. Enterprise applications and resources are always accessed over secure HTTPs connectivity through EAA, irrespective of how they are configured and which ports they are listening on (HTTP, SSH, HTTPS, RDP, or VNC) internally within the data center or VPC.
4. Encrypt Transmission of Cardholder Data Across Open, Public Networks 4.1 : Use strong cryptography and security protocols (TLS, IPSEC, SSH, etc.) to safeguard sensitive cardholder data during transmission over open, public networks EAA utilizes n number of mutually authenticated Transport Layer Security (TLS) sessions at all layers and enforces v1.2 for all data and management connectivity over open and public networks (the Internet). Enterprise applications and internal assets are always accessed over secure HTTPs sessions through EAA, irrespective of how they are configured and which ports they are listening on (HTTP, SSH, HTTPS, RDP, or VNC) internally within the confines of the data center or VPC. 7. Restrict Access to Cardholder Data by Business Need-to-Know 7.1 : Limit access to system components and cardholder data to only those individuals whose jobs require such access 7.1.3 : Assign access based on individual personnel job classifications and functions 7.2.2 : Assign privileges to individuals based on job classifications and functions EAA restricts access to specific systems components, applications, and other resources based on least privileges and role-based principles.
8. Identify and Authenticate Access to System Components 8.1.1 : Assign all users a unique ID before allowing them to access system components or cardholder data 8.1.5 : Manage IDs used by vendors to access, support, or maintain system components via remote access as follows: Enabled only during the time needed and disabled when not in use Monitored when in use 8.1.8 : If a session has been idle for more than 15 minutes, require the user to re-authenticate in order to re-activate the terminal or session 8.2 : In addition to assigning a unique ID, ensure proper user-authentication management for non-consumer users and administrators on all system components by employing at least one of the following methods to authenticate all users: (i) Something you know, such as a password or passphrase; (ii) something you have, such as a token device or smart card; or (iii) something you are, such as a biometric 8.2.1 : Using strong cryptography, render all authentication credentials (such as passwords/phrases) unreadable during transmission and storage on all system components 8.3 : Incorporate two-factor authentication for remote network access originating from outside the network by personnel (including users and administrators) and all third parties (including vendor access for support or maintenance) EAA enforces unique IDs and role-based access control within the EAA Directory. In addition, EAA can leverage existing User Authentication Directories and/or SSO solutions for a seamless integration with current RBAC implementations. EAA supports multi-factor authentication (MFA) to further secure your applications. MFA enables an additional security layer for passwords, decreasing the risk of unauthorized users from accessing applications. When a user attempts to access an application, the user will be required to provide a pin code received via a verified email address or mobile telephone number.
10. Track and Monitor All Access to Network Resources and Cardholder Data 10.1 : Implement audit trails to link all access to system components to each individual user 10.3 : Record at least the following audit trail entries for all system components for each event: 10.3.1 : User identification 10.3.2 : Type of event 10.3.3 : Date and time 10.3.4 : Success or failure indication 10.3.5 : Origination of event 10.3.6 : Identity or name of an affected data, system component, or resource EAA provides a full audit trail of successful and denied logins, incorporating all required event details including: User identification Type of event Date and time Success or failure indication Origination of event As the global leader in Content Delivery Network (CDN) services, Akamai makes the Internet fast, reliable, and secure for its customers. The company s advanced web performance, mobile performance, cloud security, and media delivery solutions are revolutionizing how businesses optimize consumer, enterprise, and entertainment experiences for any device, anywhere. To learn how Akamai solutions and its team of Internet experts are helping businesses move faster forward, please visit www.akamai.com or blogs.akamai.com, and follow @Akamai on Twitter. Akamai is headquartered in Cambridge, Massachusetts in the United States with operations in more than 57 offices around the world. Our services and renowned customer care are designed to enable businesses to provide an unparalleled Internet experience for their customers worldwide. Addresses, phone numbers, and contact information for all locations are listed on www.akamai.com/locations. 2016 Akamai Technologies, Inc. All Rights Reserved. Reproduction in whole or in part in any form or medium without express written permission is prohibited. Akamai and the Akamai wave logo are registered trademarks. Other trademarks contained herein are the property of their respective owners. Akamai believes that the information in this publication is accurate as of its publication date; such information is subject to change without notice. Published 12/16.