Security Guide Version 3.0 October 2014. Using the Cryptzone s AppGate TM. Server to Achieve PCI DSS v3.0 Compliance

Security Guide Version 3.0 October 2014 Using the Cryptzone s AppGate TM Server to Achieve PCI DSS v3.0 Compliance

Contents Preface... 3 PCI DSS Overview of Requirements... 4 Use of Network Segmentation... 5 Segmentation with AppGate... 6 PCI DSS Requirements... 7 1: Install and maintain a firewall configuration to protect cardholder data... 8 2: Do not use vendor- supplied defaults for system passwords and other security parameters... 10 3: Protect stored cardholder data... 11 4: Encrypt transmission of cardholder data across open, public networks... 11 5: Use and regularly update anti- virus software or programs... 12 6: Develop and maintain secure systems and applications... 12 7: Restrict access to cardholder data by business need- to- know... 13 8: Identify and authenticate access to system components... 14 9: Restrict physical access to cardholder data... 15 10: Track and monitor all access to network resources and cardholder data... 16 Summary... 17 High- level separation and protection... 18 More Information... 19 About Cryptzone... 19 Page 2 of 19

Preface This document summarizes the twelve Payment Card Industry (PCI) Data Security Standard (DSS) Requirements and Security Assessment Procedures, and highlights some of the new updates in Version 3.0. The context is however limited to many areas in which the use of Cryptzone s AppGate Server can deliver compliance against the standard. Implementation of the PCI DSS requirements have always had a financial incentive (in the form of fine avoidance), but as many of the recent very high profile data breaches have shown, the financial cost of non- compliance can be considerably more costly than any fine. In what is arguably the highest profile data breach to date; Target now estimates (as of Aug 2014) that losses from a 2013 data breach that compromised credit cards and account information for 40 million shoppers could cost upwards of $148 million. Rumor has it that the latest Home Depot breach could eclipse these figures. New in 3.0 is a whole section entitled Best Practices for Implementing PCI DSS into Business- as- Usual [BAU] Processes. Taken in conjunction with the real- life example above, this is one of the most important additions in V3.0. The 6 sub sections (covering monitoring, failure control, change processes, organizational change, process audits and technology reviews) are all very requirements orientated, but the real point of this is in the title Business- as- Usual. Firstly as long as requirements, such as PCI DSS, are something you do once or twice per year before an assessment, then we have all missed the point. Secondly using the two worlds model one for PCI DSS and the other for BAU may seem like an okay idea, but it is akin to trying to drive two cars at once! The trick is to take as many of the PCI DSS requirements as possible and to use them for BAU. Rather than making your business processes more complex, achieving compliance should be seen as an opportunity to get rid of poor outdated practices and equipment and invest in new ones, which not only meet these requirements, but also benefit the wider business improving access to systems, authentication processes, network utilization, reduced remediation costs, etc. With headline numbers, such as those from the Target data breach, there has never been a better time to justify adopting a new approach to building secure networks. Page 3 of 19

PCI DSS Overview of Requirements The twelve PCI DSS requirements are organized into six logically related groups called the control objectives. The following table illustrates commonly used elements of cardholder and sensitive authentication data whether storage of each data element is permitted or prohibited and if each data element must be protected. This table is not exhaustive, but is presented to illustrate the different types of requirements that apply to each data element. Data Element Storage Permitted Primary Account Number (PAN) Yes Yes Cardholder Name Yes No Service Code Yes No Expiration Date Yes No Full Magnetic Stripe Data CAV2/CVC2/CVV2/CID PIN/PIN Block No No No Render Stored Account Data Unreadable PCI DSS requirements are applicable if a Primary Account Number (PAN) is stored, processed, or transmitted. If a PAN is not stored, processed, or transmitted, PCI DSS requirements do not apply. These security requirements apply to all system components. System components are defined as any network component, server, or application that is included in or connected to the cardholder data environment [CDE]. The cardholder data environment is that part of the network that possesses cardholder data or sensitive authentication data. Much of the information included in this document has been taken from the PCI DSS Requirements and Security Assessment Procedures, Version 3.0 November 2013 created by the PCI Security Standards Council LLC. The PCI Security Standards Council is an open global forum for the on going development, enhancement, storage, dissemination and implementation of security standards for account data protection. Read all about the standard at https://www.pcisecuritystandards.org/. The 12 main areas covered by the PCI DSS Requirements and Security Assessment Procedures are summarized below. Page 4 of 19

Build and Maintain a Secure Network Requirement 1: Requirement 2: Protect Cardholder Data Requirement 3: Requirement 4: Install and maintain a firewall configuration to protect cardholder data Do not use vendor- supplied defaults for system passwords and other security parameters Protect stored cardholder data Maintain a Vulnerability Management Program Requirement 5: Requirement 6: Implement Strong Access Control Measures Requirement 7: Requirement 8: Requirement 9: Regularly Monitor and Test Networks Requirement 10: Requirement 11: Maintain an Information Security Policy Requirement 12: Encrypt transmission of cardholder data across open, public networks Protect all systems against malware and regularly update anti- virus software or programs Develop and maintain secure systems and applications Restrict access to cardholder data by business need- to- know Identify and authenticate access to system components Restrict physical access to cardholder data Track and monitor all access to network resources and cardholder data Regularly test security systems and processes Maintain a policy that addresses information security for all personnel There is no defined network security approach to meeting the PCI DSS Requirements. However, one of focus areas that can enable compliance is the use of Network Segmentation. Use of Network Segmentation Network segmentation of, or isolating (segmenting) the CDE from the remainder of an entity s network is not a PCI DSS requirement. However, it is strongly recommended by PCI DSS as a method that may reduce: The scope of the PCI DSS assessment The cost of the PCI DSS assessment The cost and difficulty of implementing and maintaining PCI DSS controls Page 5 of 19

The risk to an organization (reduced by consolidating cardholder data into fewer, more controlled locations) New in 3.0 is the statement To be considered out of scope for PCI DSS, a system component must be properly isolated (segmented) from the CDE, such that even if the out- of- scope system component was compromised it could not impact the security of the CDE. So without adequate network segmentation, which isolates systems that store, process, or transmit cardholder data from those that do not, then the scope of the PCI DSS assessment could easily extend to include the entire network. The key point here is compromised component this means that none of the inherent security controls within that component can be trusted, such as user authorization, code execution, network communications, firewall rules, etc. This new statement almost mandates the adoption network segmentation, since there has to be some form of fire- break between the CDE and the rest. This means the adoption of internal network firewalls, routers with strong access control lists, or devices such as the AppGate Security Server (which can restrict access to a particular segment of a network) should now be considered. Segmentation with AppGate To get the most from this document, it is important to have a high level understanding about how the AppGate system works, especially in the context of securing internal networks. The case in point protecting the CDE, is actually exactly why the product was developed (the CDE was in this case a large business military projects network). The Zero- Trust Model Cryptzone has adopted is based on a set of guiding principles that no- one is trusted until proven otherwise. The biggest issue with traditional flat networks is that they are based on the Trust Model. They assume all devices on the network are correctly behaved, benign and will abide by the network policies distributed by a directory server. Flat networks also depend on devices being known to the network for the security policies to actually work. The rise (and fall) of Network Access Control systems was the result of trying to mitigate these risks associated with unknown devices appearing on a business networks. But this is a near impossible battle to win. The BYOD revolution has seen hundreds upon thousands of unsanctioned, unaudited devices enter, and leave, the workplace. Access to enterprise apps used to be confined to corporate- approved on- premise desktops and a few laptops for the fortunate. Now we connect to business systems on personal smartphones, across unsecured Wi- Fi networks in public places. The recent data here is staggering. IDC says that 95 percent of workers have used their personal devices in a work context. 30-40 percent use at least two devices to access corporate IT systems. By far the biggest part of any enterprise network is the user community and this is the least trusted area as well. So how should we be thinking about security now? What s needed is a new model a model that secures services, applications and resources through access controls located closer to the applications themselves and to shrink the footprint of the trusted network to the point where you can keep the bad guys out and the valuables secure. In the case of the CDE shrinking (and securing) the at- risk network is the only logical way of achieving compliance cost effectively. The AppGate Server was designed as a secure access gateway for use inside company networks; think of it as part firewall, part router, part VPN. Because of the security model adopted it can also be used as an access solution at the firewall/perimeter as well. Either way, AppGate starts in a deny- all mode access to all services is blocked until access is explicitly requested and authorization is granted. Secure, encrypted service tunnels are established for each individual service, and any non- authorized service or device isn t merely blocked at the IP or port it s simply non- existent it isn t there at all. Page 6 of 19

If AppGate Servers are located at the appropriate points in a business network then it is possible to start to deliver on the Zero- Trust Model. With them in place there is effectively a closed firewall that won t allow traffic to pass. So with a compromised machine on the network (that ignores any network policies) it still won t be able to explore the network for other interesting machines or ones which are unpatched. The same goes for compromised accounts, even if these are used to access a machine, those credentials alone might not be sufficient to allow access through an AppGate which uses context- aware policies even within the walls of a business. The use of network friendly application layer protocols and support for VLANS means it is easy to set up and manage segmented networks, providing the secure separation of users and critical systems, while also enabling essential connectivity and secure access for authorized users. If network segmentation is used to reduce the scope of the PCI DSS assessment, the segmentation must be adequate. At a high level, adequate network segmentation isolates systems that store, process, or transmit cardholder data from those that do not. Even with a clear understanding of what is in- scope for the CDE, there are other business needs related to storage, processing and transmission of related information, so this is no easy task. Restricting cardholder data flows to as few locations as possible by eliminating the saving of data unnecessarily, will certainly help. There may also be some scope for consolidation of servers possibly into a VM environment for easy segmentation. The real problem often lies in gluing the systems/connectivity back together afterwards. This might extend to reengineering long- standing business practices relating to the network's configuration, the way it is used and even the location of users on the network. This is where the real strength of AppGate lies. All user connections run over the existing network but are encrypted. This makes the gluing much easier to implement, because many less changes are required to the physical network, and the new and old connectivity models can co- exist for a period of time. Effectively a secure virtual network is overlaid onto the physical one. This also has major advantages when looking at, for instance, network resilience since the virtual network will simply inherit any resilience improvements made to the underlying network. PCI DSS Requirements The flexibility of the AppGate solution means it will help to meet 10 of the 12 PCI DSS requirements. But more importantly the adoption of network segmentation will reduce the extent of the in- scope systems making the whole compliance process simpler and faster. Below, requirements 1 to 10 are each covered separately. For most requirements the relevant sub- sections have been highlighted. In each case a commentary has been added explaining how AppGate can be used to provide that specific compliance mandate. The last two requirements; 11: Regularly test security systems and processes and 12: Maintain a policy that addresses information security for all personnel, are not areas where the use of AppGate can help deliver PCI compliance. Having said that, if its use makes for a simpler way of achieving PCI compliance then there Page 7 of 19

are some second order benefits, such as reduced scope for system/vulnerability scanning and simplified information policies. 1: Install and maintain a firewall configuration to protect cardholder data Firewalls are devices that control computer traffic allowed between an entity s networks (internal) and untrusted networks (external), as well as traffic into and out of more sensitive areas within an entity s internal trusted networks. The cardholder data environment is an example of a more sensitive area within an entity s trusted network. A firewall examines all network traffic and blocks those transmissions that do not meet the specified security criteria. All systems must be protected from unauthorized access from untrusted networks, whether entering the system via the Internet as e- commerce, employee Internet access through desktop browsers, employee e- mail access, dedicated connections, such as business- to- business connections, via wireless networks, or via other sources. Often, seemingly insignificant paths to and from untrusted networks can provide unprotected pathways into key systems. Firewalls are a key protection mechanism for any computer network. AppGate is a certified firewall and can be classed as an internal firewall as far as protecting/segmenting the PCI at- risk network. The crucial difference with AppGate is that it blocks those transmissions that do not meet the specified security criteria on a per user basis rather than an IP address making traceability much easier. 1.1 Establish firewall and router configuration standards that include the following: 1.1.4 Requirements for a firewall at each Internet connection and between any demilitarized zone (DMZ) and the internal network zone. AppGate fulfills the requirement to have a firewall between any given zones, although its role should be focused on user centric traffic, rather than bulk traffic. 1.1.6 Documentation and business justification for use of all services, protocols, and ports allowed, including documentation of security features implemented for those protocols considered to be insecure. Through the use of scripts running on the AppGate server it is possible to produce reports documenting all access policies (allowed services, ports, protocols, etc,) that relate to specific groups or users configured. This makes it very quick and easy to ensure services are configured as they should be and align with any business justification. 1.1.7 Requirement to review firewall and router rule sets at least every six months Simplifying firewall rules is probably one of the effective security actions any business can take. The AppGate system generates firewall rules on an as- needed basis from predefined policies. So, if you were to take out a server (i.e. it no longer requests any access) then there will be no rules for that server present in the firewall. Another advantage is that far fewer policies are required than rules because the same policy can generate numerous rules. This makes the reviewing of rule sets a much less onerous task. Page 8 of 19

1.2 Build firewall and router configurations that restrict connections between untrusted networks and any system components in the cardholder data environment. AppGate can handle connections from both trusted and non- trusted networks. Because it is context aware it is very easy to create policies that adapt according to a user s situation. 1.2.1 Restrict inbound and outbound traffic to that which is necessary for the cardholder data environment, and specifically deny all other traffic. Context aware and dynamically generated rule sets offer a big advantage over static rule sets that can easily limit legitimate users access, because of the very simple rule- sets they use. Rule sets comprise a whitelist, so by default all other traffic will be denied. 1.2.2 Secure and synchronize router configuration files. At boot the most recent configuration with all the latest security settings is used by default. Older configurations including the original start- up configuration can be chosen by an administrator and set as the boot image if required for any reason. 1.2.3 Install perimeter firewalls between all wireless networks and the cardholder data environment, and configure these firewalls to deny or, if traffic is necessary for business purposes, permit only authorized traffic between the wireless environment and the cardholder data environment. AppGate servers can be used as firewalls to wireless networks. Furthermore all connections are encrypted end- to- end using algorithms like AES 128 and AES 256. So as well as securing wireless traffic, it is possible to build a virtual secure network over the standard wireless network for PCI users. 1.3 Prohibit direct public access between the Internet and any system component in the cardholder data environment. AppGate is a stateful firewall as well as an access control solution. One of the key features of an AppGate is that it is all- off in the no- connections state. So if an AppGate is used for user access to the CDE then by default access is blocked unless a user with valid credentials is connecting. 1.3.2 Limit inbound Internet traffic to IP addresses within the DMZ. Several of the current flood of retail break- ins have been successful only because poorly configured jump- servers have been targeted in the DMZ. Limiting access to the DMZ is sensible, but the systems in the DMZ need to be properly secured and appropriate for the task being asked of them. Many organizations just deploy a Windows terminal server in the DMZ and this is not an ideal use for them. By locating an AppGate in the DMZ, it is possible to configure it as a jump- server with automatic strong security. It can work as a redirection/proxy server for any users requiring access to the CDE. When traffic is allowed then the system hides internal addresses through the use of local host addressing and NAT [1.3.8]. 1.3.4 Implement anti- spoofing measures to detect and block forged source IP addresses from entering the network. (For example, block traffic originating from the Internet with an internal source address.) This is a new requirement in 3.0. The AppGate system has a built- in automatic IP block that stops any repeated attempts to break- in. 1.4 Install personal firewall software on any mobile and/or employee- owned computers with direct connectivity to the Internet (for example, laptops used by employees), which are used to access the organization s network. Part of the AppGate solution includes the AppGate Device Firewall that works with the AppGate Security Server to protect the user s device and the network. The Device Firewall controls all inbound and outbound traffic on all adapters and network interfaces enforcing dynamic policies. For example, all connections can be closed except the link to the AppGate before the user is permitted to connect to the CDE. The Device Page 9 of 19

Firewall can also make sure that user workstations cannot communicate with each other, restricting the ability of viruses and worms to spread between systems. The firewall is centrally managed and easy to install. It has no GUI on the client machine, so users do not have to make decisions about traffic filtering. 2: Do not use vendor- supplied defaults for system passwords and other security parameters. Malicious individuals (external and internal to an entity) often use vendor default passwords and other vendor default settings to compromise systems. These passwords and settings are well known by hacker communities and are easily determined via public information. 2.1 Always change vendor- supplied defaults and remove or disable unnecessary default accounts before installing a system on the network. Each AppGate is supplied with complex and unique administrative and root passwords by default. The default settings are all- off so there is no possibility to compromise protected systems, unless you have the unique password(s). 2.2 Develop configuration standards for all system components. Assure that these standards address all known security vulnerabilities and are consistent with industry- accepted system hardening standards. 2.2.2 Enable only necessary services, protocols, daemons, etc., as required for the function of the system. AppGate has all unnecessary daemons removed from the system. All ports are blocked except the 2 or 3 required for the correct operation of the server. 2.2.3 Implement additional security features for any required services, protocols, or daemons that are considered to be insecure for example, use secured technologies such as SSH, S- FTP, SSL, or IPSec VPN to protect insecure services, such as NetBIOS, file- sharing, Telnet, FTP, etc. As well as performing the required firewalling/routing functionality AppGate uses SSH to tunnel any insecure protocols. So, if there was http traffic being used then this could be tunneled easily. 2.3 Encrypt all non- console administrative access using strong cryptography. Use technologies, such as SSH, VPN, or SSL/TLS for web- based management and other non- console administrative access. The AppGate system is very often used as a hub for administrative access control. A portal view of all the systems allows access from a single point, provides strong encryption (both sides of the AppGate) and enables centralized logging and reporting of all administrative accesses. 2.6 Shared hosting providers must protect each entity s hosted environment and cardholder data. These providers must meet specific requirements as detailed in Appendix A: Additional PCI DSS Requirements for Shared Hosting Providers. A.1.2 Restrict each entity s access and privileges to its own cardholder data environment only. Where AppGate is used as the entry point then it manages the authentication process (which can be multi factor). Thereafter AppGate uses those (trusted) credentials to access downstream systems. This ensures that users will not be able to switch context from one environment to another once through the entry point. A.1.3 Ensure logging and audit trails are enabled and unique to each entity s cardholder data environment and consistent with PCI DSS Requirement 10. Where it is possible to identify the different cardholder data environments from the access point (different ports on a server, different URLs, different VMs, etc) then the system will keep accurate logs of who has had access to which systems. Page 10 of 19

3: Protect stored cardholder data Protection methods, such as encryption, truncation, masking, and hashing are critical components of cardholder data protection. If an intruder circumvents other security controls and gains access to encrypted data, without the proper cryptographic keys, the data is unreadable and unusable to that person. The AppGate system itself does not provide encryption of data at rest, so the majority of the section does not apply. However please note that Cryptzone s Simple Encryption Platform provides encryption capabilities and its Secured ecollaboration module can apply policy based encryption to information stored in a Microsoft SharePoint environment. 3.5 Document and implement procedures to protect keys used to secure stored cardholder data against disclosure and misuse: 3.5.1 Restrict access to cryptographic keys to the fewest number of custodians necessary. It is possible to control access to any servers/services using the AppGate system including key stores. Access would be policy based, strong/certificate based authentication could be used and access limited to known PCs or IP addresses. Again centralized logging and reporting of all key store access could be provided. 4: Encrypt transmission of cardholder data across open, public networks Sensitive information must be encrypted during transmission over networks that are easily accessed by malicious individuals. Misconfigured wireless networks and vulnerabilities in legacy encryption and authentication protocols continue to be targets of malicious individuals who exploit these vulnerabilities to gain privileged access to cardholder data environments. Even though the title implies encryption should be used over public networks, it would be better to try to encrypt as much of any transmission as possible. This is especially the case from say POS machines back to the CDE. AppGate was originally developed to meet precisely this internal security need and encrypts data irrespective of the network. 4.1 Use strong cryptography and security protocols (for example, SSL/TLS, IPSEC, SSH, etc.) to safeguard sensitive cardholder data during transmission over open, public networks. AppGate supports the use of strong cryptography and security protocols, such as secure sockets layer (SSL)/transport layer security (TLS) and SSH technology to safeguard sensitive cardholder data during transmission over any network. 4.1.1 Ensure wireless networks transmitting cardholder data or connected to the cardholder data environment, use industry best practices (for example, IEEE 802.11i) to implement strong encryption for authentication and transmission. This refers to a network security technique and the use of the WPA2 standard. AppGate offers application security in the form of end- to- end encryption (App to CDE), so in this respect it is easy to meet the requirements for encryption on Wireless Networks. However as well as protecting the data itself the authentication element will prevent malicious users from gaining a foothold on the host network. So if an application security approach is taken then the access points should be connected directly to a dedicated port on the AppGate. In this way AppGate s strong authentication requirements mean that it is impossible to gain any access to the wider network, even if the access point has been compromised. Strong cryptography for authentication and transmission of cardholder data is required to prevent malicious users from gaining access to the wireless network or utilizing wireless networks to access other internal networks or data. Page 11 of 19

This guidance note is important. Wireless networks can be used as entry points for malicious users as the nature of radio waves means they are open networks. Ideally any network segmentation being used for PCI DSS should consider segmenting the Wireless networks, so that if one were compromised, then access to the wider network infrastructure would not be so easily achieved. 5: Use and regularly update anti- virus software or programs Malicious software, commonly referred to as malware including viruses, worms, and Trojans enters the network during many business- approved activities, including employee e- mail and use of the Internet, mobile computers, and storage devices, resulting in the exploitation of system vulnerabilities. Anti- virus software must be used on all systems commonly affected by malware to protect systems from current and evolving malicious software threats. Additional anti- malware solutions may be considered as a supplement to the anti- virus software; however, such additional solutions do not replace the need for anti- virus software to be in place. 5.1 Deploy anti- virus software on all systems commonly affected by malicious software (particularly personal computers and servers). When the AppGate system is used as the hub in a PCI DSS network design then, whenever a new machine tries to establish a connection to the CDE, it can be asked to deploy any specific required software such as a- v. 5.2 Ensure that all anti- virus mechanisms are maintained as follows: Are kept current, Perform periodic scans, Generate audit logs which are retained per PCI DSS Requirement 10.7. The AppGate system is designed to check the status of specified files in the file system of all connecting PCs. So for instance the date on any a- v signature files could be checked and tested to make sure they are no more than x days old. 5.3 Ensure that anti- virus mechanisms are actively running and cannot be disabled or altered by users, unless specifically authorized by management on a case- by- case basis for a limited time period. The AppGate system can check the MS Security Centre or the list of running processes. Only PCs meeting the required actively running policy will be allowed to connect. It is also possible to start processes such as a- v when a- v is not detected as a running process and then to delay opening any connection to the CDE to allow time for it to work. 6: Develop and maintain secure systems and applications Unscrupulous individuals use security vulnerabilities to gain privileged access to systems. Many of these vulnerabilities are fixed by vendor- provided security patches, which must be installed by the entities that manage the systems. All critical systems must have all appropriate software patches to protect against the exploitation and compromise of cardholder data by malicious individuals and malicious software. As well as rephrasing this sentence the word critical was removed in 3.0. Numerous network breaches have started in areas outside of the CDE and because of a lack of network segmentation have spread into the CDE. By looking at implementing better access controls to all systems then they will benefit from the security gains this provides as well. 6.4.1 Separate development/test and production environments & Page 12 of 19

6.4.2 Separation of duties between development/test and production environments AppGate is designed to provide the separation of development, test, and production environments when you implement Separation of Duties at the business level. An Admin in the test environment may not have the same level of access in the production environment. Using AppGate admin access to the production environment could always include a pop up message such as the one to the right: 6.4.5.4 Back- out procedures. For each change, there should be documented back- out procedures in case the change fails or adversely affects the security of an application or system, to allow the system to be restored back to its previous state. The AppGate system allows snapshots to be made at any time. The system can be rebooted of any of these snapshots. 6.5.8 Improper Access Control, such as insecure direct object references, failure to restrict URL access, and directory traversal (Properly authenticate users and sanitize input. Do not expose internal object references to users.) Strictly this sits in section 6 Address common coding vulnerabilities in software- development processes, however where applications have not got sufficient in built controls (either by design or through coding shortcomings), then AppGate will whitelist exactly what access rights a user has. So this will effectively, filter URLs, limit available ports, restrict directory access, etc. 6.5.10 Broken authentication and session management This is a new requirement in 3.0 from June 30 2015. A more intelligent mechanism is required which relies less on reusing cookies or just replaying username/password pairs. A session should be based on additional parameters that can be used to validate the identity of the user. 7: Restrict access to cardholder data by business need- to- know To ensure critical data can only be accessed by authorized personnel. Systems and processes must be in place to limit access based on need to know and according to job responsibilities. Need to know is when access rights are granted to only the least amount of data and privileges needed to perform a job. 7.1 Limit access to system components and cardholder data to only those individuals whose job requires such access. AppGate is a true access control system as opposed to an authorization system (AD / LDAP). This means entitled individuals will have to be authorized AND be provisioned access to CDE systems/data. 7.1.2 Restrict access to privileged user IDs to least privileges necessary to perform job responsibilities. Privileged users may have more rights within LDAP/AD such as admin rights to all Linux servers. However when using AppGate and working in the CDE access to specific systems may be denied or may require enhanced authentication. 7.1.3 Assign access based on individual personnel s job classification and function. Any attributes in LDAP/AD can be mapped into the AppGate context. These can then be used to enable specific services, folders of services or the overall role on an individual basis. Page 13 of 19

7.2 Establish an access control system for systems components with multiple users that restricts access based on a user s need- to- know, and is set to deny all unless specifically allowed. By default AppGate denies all access. Any whitelisted access can be tailored to users or groups of users. As well as simple on/off access some traffic can be filtered. So, one group might have access to just one web page (for data input) but nothing else. 7.3 Ensure that security policies and operational procedures for restricting access to cardholder data are documented, in use, and known to all affected parties. This new requirement in 3.0 is a pointer to the adoption of network segmentation. If access controls are placed at the boundaries between segments then the policies and operational procedures are technically enforced. The AppGate system even has the ability to push content to new/existing users, so that a web page covering procedures could be opened when they connect. 8: Identify and authenticate access to system components Assigning a unique identification (ID) to each person with access ensures that each individual is uniquely accountable for their actions. When such accountability is in place, actions taken on critical data and systems are performed by, and can be traced to, known and authorized users and processes. In 3.0 the heading Identify and authenticate access to system components has been changed from Assign a unique ID to each person with computer access and and processes has been added to the end of the description. These changes are critical securing CDE in the future. Moving away from the belief that (a person s) identity is everything to the idea that identifying adequately the source of access requests (human or otherwise) is a subtle, but important move. Identification should be contextual, which is a concept supported in the AppGate system. Different situations should require different means of providing adequate proof. The effectiveness of a password is largely determined by the design and implementation of the authentication system particularly, how frequently password attempts can be made by an attacker, and the security methods to protect user passwords at the point of entry, during transmission, and while in storage. This paragraph is new in 3.0 and reinforces the need to address the issues relating to authentication more holistically than just thinking password every time, which goes beyond the scope of this document. 8.1 Define and implement policies and procedures to ensure proper user identification management for non- consumer users and administrators on all system components as follows: The use of stolen credentials to mount some of these recent cyber attacks means this section has come under the spotlight. In the new 3.0 this sub section has been expanded out into 8 new topics. In general terms the AppGate system is based on any request for access being accompanied by an identity. So no access is allowed but based on a firewall rule. So for every access request granted there will be a session ID tied to the requester s identity, which links all the related log entries together. 8.1.3 Immediately revoke access for any terminated users. AppGate uses a live link to the identity management system (LDAP), so if a record has been deleted or deactivated then access will not be possible for that user. 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 period needed and disabled when not in use. Monitored when in use. There is a local database in the AppGate system that can be used for vendors (to keep them quite separate from BAU users). These accounts can be switched on or off with a check of a box. Page 14 of 19

8.1.6 Limit repeated access attempts by locking out the user ID after not more than six attempts. The AppGate system runs an anti- bot algorithm which automatically locks out the account after 3 (configurable) wrong guesses within a 30 second (configurable) window. 8.1.7 Set the lockout duration to a minimum of 30 minutes or until an administrator enables the user ID. The lock out is managed by the system automatically, but the time window can be configured. 8.1.8 If a session has been idle for more than 15 minutes, require the user to re- authenticate to re- activate the terminal or session. An inactivity timer in the AppGate system automatically logs the user out after a configurable period. 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: Something you know, such as a password or passphrase; Something you have, such as a token device or smart card; Something you are, such as a biometric. In general terms the AppGate can be configured to work with many different forms of authentication service. These include: Password (local and via LDAP/AD), One- Time- Password via GSM/SMS, SecurID, Radius, Certificate, Public Key. All the authentication processes are handled within the related IETF standard for SSH so all such processes are handled in a completely secure way. 8.2.3, 8.2.4, 8.2.5,8.2.6 all relate to password management. Where the AppGate system is used for password management then all aspects of password setting / strength/changing can be configured according to the required policy. 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). Even for the same account ID it is possible to configure different forms of authentication depending on the users context (such as outside the network). Therefore, if a password was used on the trusted network, then a token could be mandated when remote access is attempted. 8.4 Document and communicate authentication procedures and policies to all users. The AppGate system includes built- in messaging capabilities. So, for instance, if a user were to try logging in to the CDE with only password authentication, then access would be granted but only to a message which might contain the instructions for obtaining usage policies for use of a stronger form of (two factor) authentication. 8.5 Do not use group, shared, or generic IDs, passwords, or other authentication methods as follows: 8.5.1 Additional requirement for service providers: Service providers with remote access to customer premises (for example, for support of POS systems or servers) must use a unique authentication credential (such as a password/phrase) for each customer. There is a local database in the AppGate system that can be used for vendors (to keep them quite separate from BAU users). These accounts can be set up easily and controlled separately from LDAP/AD. 9: Restrict physical access to cardholder data Any physical access to data or systems that house cardholder data provides the opportunity for individuals to access devices or data and to remove systems or hardcopies, and should be appropriately restricted. Page 15 of 19

If it is not possible to effect physical separation then the more rigorous controls required by PCI DSS will have to be applied to all systems. Although the AppGate is in no way a physical access control system, it can facilitate the physical separation of the data and systems, thus limiting the requirements on physical access. AppGate can be configured to use an AppGate Satellite, which is in effect a remote 4 port NIC. The connection from the Satellite to the AppGate is an encrypted point- to- point connection. So, by using a Satellite any number of small groups of (remotely located) PCI related servers could be easily moved to a secure location. 10: Track and monitor all access to network resources and cardholder data Logging mechanisms and the ability to track user activities are critical in preventing, detecting, or minimizing the impact of a data compromise. The presence of logs in all environments allows thorough tracking, alerting, and analysis when something does go wrong. Determining the cause of a compromise is very difficult, if not impossible, without system activity logs. 10.1 Implement audit trails to link all access to system components to each individual user. When AppGate is used as a hub for access and specific applications/networks are set up to only allow inbound connections from the AppGate system, then users have to be authenticated by the AppGate first. This means that it is possible to link each subsequent access to any system to the original user identity. AppGate can also pass identity information on so that the users of downstream systems always use the same identities. 10.2 Implement automated audit trails for all system components to reconstruct the following events: 10.2.1 All individual accesses to cardholder data AppGate can log every individual access (to AppGate) and then all actual onward connections to the CDE. The whole user session is logged including how they authenticated, when a specific service was started, etc. 10.2.3 Access to all audit trails AppGate records all changes and access to the log system itself. AppGate can also be used as a hub for log access control. Specific log servers can be located behind the AppGate server to force access via this one mechanism. Administrative users would then be required to log into AppGate first and have each subsequent connection they established would be logged. 10.2.4 Invalid logical access attempts Invalid attempts to log into the AppGate system are logged. 10.2.5 Use of and changes to identification and authentication mechanisms including but not limited to creation of new accounts and elevation of privileges and all changes, additions, or deletions to accounts with root or administrative privileges Both the usage and configuration of authentication mechanisms are all recorded in the logs 10.2.6 Initialization, stopping, or pausing of the audit logs The logs are handled by a separate log daemon. The starting and stopping of all daemons (including the log daemon) are recorded in the logs. 10.2.7 Creation and deletion of system- level objects AppGate logs any changes within the administration including creation and deletion of objects. 10.3 Record at least the following audit trail entries for all system components for each event: User identification, Type of event, Date and time, Success or failure indication, Origination of event, Identity or name of affected data, system component, or resource. Page 16 of 19

AppGate offers detailed logging of all access events. These include full details of the context of the user access and the resources to which they were connected. 10.4 Using time- synchronization technology, synchronize all critical system clocks and times and ensure that the following is implemented for acquiring, distributing, and storing time. AppGate uses Network Time Protocol (NTP) servers to ensure time is in sync. 10.5 Secure audit trails so they cannot be altered. The AppGate server has a mandatory log record system, which guarantees an access request can not be granted unless a log record has been written. This uses a disk based double buffer, so even power disruptions can not be used to loose log records. Once safely written to disk the records are also duplicated amongst members of a cluster, so even in the event of a node failure log records for that node would still be available. 10.5.1 Limit viewing of audit trails to those with a job- related need. 10.5.2 Protect audit trail files from unauthorized modifications. AppGate can be used as a hub for log access control. Specific log servers can be located behind the AppGate server to force access via this one mechanism. User access could then be restricted to job- related only. 10.5.3 Promptly back up audit trail files to a centralized log server or media that is difficult to alter. 10.5.4 Write logs for external- facing technologies onto a log server on the internal LAN. AppGate logs can be stored on box or sent securely off to a remote syslog server if required. Summary The AppGate Security Server makes it easier to be compliant with PCI DSS for every type of organization. AppGate is an integrated, context- aware security gateway that connects users, applications and services. By integrated we mean AppGate combines authentication with authorization. Authentication is managed via a local account database or integration with LDAP or Active Directory services. Authorization is managed not by a set of static firewall rules, but by dynamic rules that can be configured based on a user- definable set of contextual criteria user, role, location, configuration, and more. The system grants access on an app- by- app basis, providing a secure, point- to- point tunnel for each service requested by the user rather than open access to an entire network segment. And a centralized management and logging interface provides the proverbial single pane of glass for policy management, audit and reporting. AppGate can function as a classic firewall on the perimeter, but it s designed to be a gateway for all users both inside and outside the corporate firewall. Through this unique approach of segmenting networks and use of dynamic rules that facilitate context- aware access, AppGate is a truly cost- effective compliance enabler addressing external business and CDE related security concerns. The new requirement to ensure security controls continue to be properly implemented, PCI DSS should be implemented into business- as- usual (BAU) activities as part of an entity s overall security strategy should not be forgotten. The adoption of a Zero- Trust Model for the enterprise can actually enhance and modernize the whole network. Zero- Trust means better controls permit/deny access than were used before. This in turn make its possible to allow access where before the all on/off model meant access was often denied because of a lack of control and monitoring. When this model is adopted beyond just the CDE, an enterprise is able to monitor much more easily the effectiveness of its security controls on an ongoing basis, and maintain their PCI DSS compliant environment in between PCI DSS assessments at the same time. Page 17 of 19

Re- establish connectivity fast Once segments have been created, connectivity can be re- established quickly and easily to allow essential access for authorized users and systems. For example. a critical systems such as SAP can be isolated from the CDE whilst still allowing say invoicing information to be passed across. Where network layer 3 connectivity is required, the built- in stateful firewall functionality can allow traffic between servers. Streamlined user experience Users may initiate a secure connection from virtually any type of device: a desktop PC, laptop, Smartphone or PDA, if the policy permits. Kerberos authentication streamlines the process for authenticated users to access resources on a segmented network. Where networks are isolated, entitled users already logged onto one network will be able to connect to a different segment from the same machine. High- Level Separation and Protection All access is blocked until the user s identity is authenticated and their access rights have been confirmed. Where access is not granted, services are invisible making it impossible to see or attack corporate assets. Administrators have precise control over who should have access to protected resources, at what time, from which location, from which devices etc. Network traffic is encrypted as standard giving each user a private, secure connection and preventing other users sniffing data. Unauthorized, unencrypted traffic is blocked automatically. Compliance, auditing and logging In addition to detail logging of all access attempts valid or not, a valid user s access records are all recorded. The same contextual information that drives the access decisions is also recorded in the logs providing a very high integrity audit trail. Log levels can be tuned for all the different processes running in an AppGate server allowing detail analysis when required. Reporting tools and alerts allow data to be analyzed both in real time and after the fact. Truly flexible control of secure access Access entitlement is based on the user s identity and contextual criteria, such as time of day and user s location, providing greater security and flexibility than can be achieved with conventional firewalls. It is easy to remove permissions when the user has moved or left the organization. Page 18 of 19

Security Guide Version 3.0 - October 2014 Policy can be used to isolate a user s machine from the local network when they connect to a different segment if required. All access is monitored and logged. Alarms can be defined. For example when particular systems are accessed, and sent to external systems for immediate action. Painless segmentation of mature networks A single appliance can support multiple secure domains on the network, removing the need to change the network architecture to isolate critical systems. Up to twelve internal security domains or segments can be created to protect critical assets. For example, development data, manufacturing systems or PCI at- risk server Segment configuration, security policies and user access rights are defined centrally. All traffic from users to application servers on these networks will be checked and controlled reducing the need for internal firewalls. More Information If you would like to know more about Cryptzone s AppGate Security Server, please visit our website: http:///products/appgate/overview About Cryptzone Cryptzone is a global provider of data security and identity and access management (IAM) solutions. The company s information security offerings are designed to secure access and protect critical data, services and applications, without impacting how organizations and users work. For over a decade, enterprises have turned to Cryptzone to galvanize their network security with responsive protection and access intelligence. More than 700 public sector and enterprise customers, including some of the leading names in technology, manufacturing and consumer products, trust Cryptzone to keep their data and applications secure. Cryptzone is headquartered in Boston, MA, with research, engineering and development teams located in Gothenburg, Sweden and is a portfolio company of Medina Capital, a high- growth equity investment firm focused on the IT infrastructure sector. United States: +1.855.427.9789 Sweden: +46 31 773 86 00 United Kingdom: +44 1252 419990 Email: sales@cryptzone.com Twitter: @cryptzone Copyright 2014, Cryptzone. All rights reserved. Cryptzone, The Cryptzone Logo and AppGate are trademarks of Cryptzone, or its affiliates. Microsoft is a registered trademark of Microsoft Corporation in the United States and/or other countries. All other product names mentioned herein are trademarks of their respective owners. Page 19 of 19