this pagepdf-1.5 %µµµµ 1 0 obj >> endobj 2 0 obj ... ®â oƒ6¯òæ ïþj %- %xÛ uj...

PCI DSS Segmentation Assessment: Case study

Public Network Intelligence India 1

PCI DSS SEGMENTATION ASSESSMENT

AUTHOR: UDIT PATHAK

SENIOR SECURITY ANALYST [email protected]



NOTICE

All rights reserved. No part of this publication may be reproduced, distributed, or transmitted in any

form or by any means, including photocopying, recording, or other electronic or mechanical

methods, without the prior written permission of the publisher, except in the case of brief

quotations embodied in critical reviews and certain other non-commercial uses permitted by

copyright law.

Nothing in this document constitutes a guaranty, warranty, or license, expressed or implied.

Network Intelligence disclaims all liability for all such guaranties, warranties, and licenses, including

but not limited to: Fitness for a particular purpose; merchantability; non infringement of intellectual

property or other rights of any third party or of Network Intelligence; indemnity; and all others. The

reader is advised that third parties can have intellectual property rights that can be relevant to this

document and the technologies discussed herein, and is advised to seek the advice of competent

legal counsel, without obligation of Network Intelligence.

Network Intelligence retains the right to make changes to this document at any time without notice.

Network Intelligence makes no warranty for the use of this document and assumes no responsibility

for any errors that can appear in the document nor does it make a commitment to update the

information contained herein.

Copyright Copyright. Network Intelligence (India) Pvt. Ltd. All rights reserved.

Trademarks Other product and corporate names may be trademarks of other companies and are used only for

explanation and to the owners' benefit, without intent to infringe.

CONTACT DETAILS Company Network Intelligence India Pvt. Ltd. Address 204, Ecospace IT Park, Off Old Nagardas Road, Andheri (East) Mumbai –

400069.

Email address [email protected] Website www.niiconsulting.com

mailto:[email protected]

http://www.niiconsulting.com/



DOCUMENT SUBMISSION DETAILS Company Network Intelligence India

Document Title PCI DSS SEGMENTATION ASSESMENT

Version No Version 1.0

Date 30th January-2016

Classification Public

Document Type Final

DOCUMENT HISTORY Date Version Author Comments

30-01-2016 1.0 Udit Pathak Final



Contents 1. Introduction .................................................................................................................................... 5

1.1 Phase 1: IT infrastructure and network segmentation ........................................................... 5

1.2 Phase 2a: Validating effectiveness of segmentation (SETUP): ............................................... 8

1.3 Phase 2b: Validating effectiveness of segmentation: ............................................................. 9

2. Conclusion: ...................................................................................................................................... 9

3. Annexure: ...................................................................................................................................... 10

4. References: ................................................................................................................................... 10



1. Introduction The PCI DSS standard recommends networks that process, store or transmit card holder data should be segregated and segmented from network environments that don’t deal with card holder data to ensure security.

During a PCI DSS certification audit, the PCI QSA, will foremost define the scope of audit. This includes all systems and process which store, transmit or process card information of users or those that are connected to these systems.

Network segmentation helps in reducing the scope of card-processing networks, cost of PCI assessment, difficulty of implementing PCI and risk; if segmentation is not in place, the entire network will be in scope.

As per PCI Standard v3, “To be considered out of scope for PCI DSS, a system component must be properly isolated (segmented) from the cardholder data environment (CDE), such that even if the out-of-scope system component was compromised it could not impact the security of the CDE.”

Thus the idea behind network segmentation (segregation) is to store, transmit or process card information at limited locations in the network. In this document we explore a scenario with both CDE and non-CDE systems and how best such segmentation may be achieved.

Scenario: Business process management centre with a mix of PCI and non-PCI compliant processes

1.1 Phase 1: IT infrastructure and network segmentation

PCI Standard provides multiple ways of separating a CDE from non-CDE.

One way could be by placing a firewall (PCI req. 1.1) between a CDE and non-CDE or to simply configure a router with the proper ACLs (Access Control Lists).

Another approach is by creating VLANs (Virtual LANs) and segregating them via ACLs. However, using only the VLAN ACLs might not be sufficient for the segregation. VLAN ACLs will have to be carefully configured on the switch and routers as a mis-configured rule can lead to incorrect segmentation

Physical separation (also called as air-gap) of CDE systems from the non-CDE systems.

A Business process management centre is designed to cater to multiple clients (processes) from different locations.

Let us consider a business process management centre for a banking process which requires a dedicated setup spread across four geographical locations in India – this will help the centre to cater to different regions in different local languages.

During the initial ‘process go-live’ phase, we adopted the approach of segmenting the network using ACLs on VLANs and a firewall. Region-wise four zones were selected:

East

West

North

South

The West zone was designated as the central location, responsible for managing the entire IT infrastructure. The South zone was designated as the DR site (along with business operations). The North and the East zones provided local IT support to business.



All the above locations also had many other processes running. PCI and non PCI processes were part of same Active Directory domain. Each process had its own Organizational Unit (OU) and users were part of their respective OUs. Desktop level access control was done for each process individually.

Figure 1 AD Structure

Being a shared infrastructure (for different customers of the business process management centre), the banking process (CDE) was segregated from other processes by implementation of ACLs on the core switch.

However, during the first PCI assessment, the QSA extended the assessment to entire network; reason being that the implemented segmentation was ineffective. As the PCI and non-PCI processes were in the same infrastructure, it was possible to access resources from either of the two processes. Though ACLs has been implemented ACLs but IT application servers (like the domain controller, antivirus server, patch management server, ticketing portal etc.) were common between the two environments. This violates the PCI requirement that the segmentation be such that a compromise of the non-CDE environment does not impact the CDE environment.



Figure 2 High Level Diagram (Before segmentation)

Referencing the above diagram, we may note the following potential issues for PCI DSS compliance:

- As there was a single domain, all the users were able to login to the systems provided for PCI process.

- Support function’s systems (HR, Admin, IT team supporting other processes) also came under the scope of PCI.

- Though firewall and ACL were in place, CDE was accessible from non-CDE through shared services.

A second approach proposed was to completely segregate the CDE network and have a separate AD domain for the same.

For all the four locations, a different LAN network was setup. However, to provide additional support to the PCI processes, connectivity from non-PCI west zone office was provided to the central and DR sites (both of which are part of the CDE) - later on, support services were made available from within the CDE environment itself. CDE access was to be provided only through a terminal server (i.e. only port 3389 was allowed for remote desktop connection).

The approach seemed very systematic and doable. To ensure that there is no impact on the business, first a replica of current AD structure was created and then PCI sites were cut off with rest of the sites. This assured minimum down time and the goal of segmentation was achieved.



Figure 3 High Level Diagram (Post segmentation)

1.2 Phase 2a: Validating effectiveness of segmentation (SETUP):

From PCI DSS version 3.0 onwards, verification of network segmentation using penetration test is mandatory.

“The scope of penetration testing is the cardholder data environment and all systems and networks connected to it. If network segmentation is in place, such that the cardholder data environment is isolated from other systems, and such segmentation has been verified as part of the PCI DSS assessment, the scope of the penetration test can be limited to the cardholder data environment.”

“Implement a methodology for penetration testing, and perform penetration tests to verify that the segmentation methods are operational and effective”

To meet the above requirements and at the same time ensuring that business is not affected, we followed an approach that resulted in effective segmentation confirmed as valid by the QSA.

- Understand the scope and infrastructure. This will help you find out the critical systems and CDE. Following reference items would usually be available with the organization for audit purposes:

o Network architecture diagram. o Card data flow diagram. (This will help you find out the critical systems).

- Obtain the list out all the approved and documented open ports and documents (as per PCI Req. 1.1.6) for the CDE.



- Review the network device configurations (at the CDE perimeter) and identify any unwanted/ suspicious rule configured. In very large networks, with numerous internal LAN segments, it may not be feasible for the penetration tester to conduct specific tests from every individual LAN segment. In this case, the testing needs to be planned to examine each type of segmentation methodology in use (i.e., firewall, VLAN ACL, etc.) in order to validate the effectiveness of the segmentation controls

- Obtain the list of VLANs (CDE and non-CDE). In case of very large network, a representative subset can be used for testing to reduce the number of segmentation checks that need to be performed.

- The assessment should be done both from inside and outside of the network (PCI Testing Guidance #2.2. Scope):

o Designate a scan host in both the networks (CDE and Non-CDE) to check the effectiveness of the segmentation in place.

o Run the port scan from CDE host to non-CDE VLANs, and non-CDE host to CDE VLAN.

1.3 Phase 2b: Validating effectiveness of segmentation:

To confirm the effectiveness of segmentation test, a port scan was performed using the above setup. From non-CDE, all the VLAN for CDE were scanned (production, server, network, training etc.) and likewise from CDE all the identified VLANs for non-CDE were scanned (these were the VLANs of IT support functions which previously had direct access to CDE). Below is a sample of ports accessible between the two networks all of which did not have documented business justification:

Port

22 3389

445 8080

3390 80

3391 8443

6129 389

443 23

2. Conclusion: After highlighting all these observations to the management and technology team, emergency changes were raised; all the required accesses were documented and unwanted accesses was removed. Access to the terminal server was also restricted only to the specific users and VLANS.

Finally, it was ensured that from non-CDE, only port 3389 was accessible for the CDE, and to put additional control, RDP access group was created for the terminal server which provided access to only the authorized users (having ID in new the domain which was now in the CDE). A re-assessment of the environment was done to validate the effectiveness of the network segmentation – the outcome of which demonstrated satisfactory network segmentation.

Below were the key leanings from this activity:

- Always review the configuration post changes. - Review firewall ACLs and switch VLANs at-least quarterly. - Segmentation is a must to make PCI DSS compliance less complicated. Segmentation tests

should be performed.



- All changes should be done via a comprehensive change management process. A review of changes on the different components of the infrastructure should be done to identify any un-authorized changes in the CDE perimeter which may compromise the network segmentation put in place.

3. Annexure: CDE (cardholder data environment) : A cardholder data environment (CDE) is a computer system or networked group of IT systems that processes, stores and/or transmits cardholder data or sensitive payment authentication data. A CDE also includes any component that directly connects to or supports this network.

Non-CDE (non cardholder data environment): A non-cardholder data environment (CDE) is a computer system or networked group of IT systems that is separated from CDE and doesn’t processes, stores and/or transmits cardholder data or sensitive payment authentication data.

Air gapping: Air gapping is a security measure that involves isolating a computer or network and preventing it from establishing an external connection.

An air gapped computer is physically segregated and incapable of connecting wirelessly or physically with other computers or network devices.

Scan host: A scan host is the computer / server from where the testing will be performed. Depending upon the size and the network architecture multiple scan hosts needs to be identified. The penetration tester should verify that each network segment reported to be isolated from the CDE truly has no access to the CDE.

Critical systems: The term “critical systems” is used in the PCI DSS to reference systems that are involved in the processing or protection of cardholder data.

4. References: http://searchsecurity.techtarget.com/

www.pcisecuritystandards.org

https://www.pcisecuritystandards.org/documents/Penetration_Testing_Guidance_March_2015.pdf

http://searchsecurity.techtarget.com/

http://www.pcisecuritystandards.org/



this pagepdf-1.5 %µµµµ 1 0 obj >> endobj 2 0 obj ... ®â oƒ6¯òæ ïþj %- %xÛ uj...

Documents