Security Challenge #2 – PCI DSS

Hi all,

For all of you asking me for a PCI DSS specific scenario, I’ve prepared a challenge depicting a situation I faced a couple of years ago. The process is fairly simple, but there were so many non-compliances that the manager who hired us started to think about becoming a gardener (lol!).

For those of you familiar with PCI DSS, be my guest and share your knowledge with the readers! If you haven’t heard of PCI DSS yet, time to get hold of the standard ( and start studying!

Feel free to comment, recommend and criticize as usual!


No related content found.

Filed Under: Challenges


RSSComments (11)

Leave a Reply | Trackback URL

  1. Joey says:

    Non-compliance noted by the “Steps” above, A through S.

    A) I assume “accounting” is using source documents for CHD. No indication how the source CHD is handled, or whether it is securely destroyed.

    B) Clear text file created containing CHD without encryption. No file with CHD should be stored on media without at the very rigorous security policy.

    C) Using the same password for long periods of time run the risk it will be compromised. Also the Zip encryption has been broken and is not sufficient to protect CHD data.

    D) The CHD file is stored on an insecure file system on a notebook which can be lost or stolen. Secure hard drive encryption should be used to protect the data if/when the notebook is lost and/or stolen. Use of a notebook capable of rendering the hard drive unreadable upon unauthorized access attempt is recommended.

    E) FTP is not a secure protocol, data is transferred in the clear, use of SFTP is recommended.

    F) Same non compliance security flaw as noted in B and D above, file stored on an insecure file system using a poor encryption technology — Zip. Disk encryption, or file system encryption at the very least, application ASE128 encryption is recommended.

    G) Indications that an automatic system decrypts the Zip file, suggesting the Zip password may be insecurely stored for use by the process extracting the CHD file. Again, the CHD file is in clear text on an insecure file system.

    H) CHD file lingers even longer on a common location of an insecur file system.

    I) Again, FTP is an insecure transport mechanism, sending the CHD file contents in the clear over the network. It is possible any system on the network could capture the transmission with an off-the-shelf or free network sniffer.

    J) Finally at least the CHD file is on a secure file system, but odds are the file system by other users of the Application Server who may have be able to read its contents.

    K) Possibly too many users have clear-card access to the CHD during tranaction processing. Only a select few users should have clear-card access, all others should have masked-card access.

    M) Same non compliance as in F above without even the “feel good” attempt at securing the CHD file; it is not even Zipped with encryption.

    N) Yet another insecure network transmission, see Step I above.

    O) CHD data is not stored encrypted in the DB. Obviously DB data will never never implement Key Roll to attain compliance.

    P) CHD data should be obfuscated as soon as it use is no longer needed. Source documents/media should be aged and securely deleted when its usefulness has passed. CHD data here remains in clear-text, not even poorly protected via Zip.

    Q,R and S) CHD data should never be stored with being properly and completely obfuscated and NEVER use to feed DR systems with CHD in the clear. Might as well put it on the Web yourself, save a hacker some steps!

  2. JJ says:

    Wow, you broke into the bank where I work and stole one of our network diagrams. Y’all just hire the wrong type of QSA.

    1. Install DLP on all desktops, servers and exit points. DLP fixes everything wrong with a flat network and unencrypted servers.

    2. Install NAC on the non-data center switches to keep unauthorized sniffers off the network. Yes, apparently it is OK to have a malware-installed sniffer on one of our servers.

    3. Pass GO and collect your RoC and bonus.

  3. Sankar P says:

    – CHD environment needs to be isolated from rest of the internal network – Create network segmentation for Credit card Data Holder Env.
    – Same FTP account should not be used at all the places – create a unique account and password on each of those servers.
    – CHD should not be kept without masking. – Enable CHD masking at Application and DB Servers
    – Access to temp and Contractors need to be limited at the Application servers
    – OS needs to be enabled with additional logging (ex: Capture all Security Events – Failure logons, Administrator activities, etc)
    – Generic/shared ids should not be used to access the servers. Create unique id for each sysadmins and operators
    – Secured FTP needs to be used among store server and HQ Servers.
    – A file which contains the credit card holder data should not be stored in clear text – Encrypt in transit and at store
    – Unique password need to be used to zip and unzip the files
    – Files and dbs, which contain CHD needs to be encrypted on all the servers
    – CHD data should not be kept indefinitely. It needs to be cleaned up as per the Record retention policy
    – CHD needs to be securely transferred to the backup media and tapes should be kept securely at offsite.

  4. Pavel Mir says:

    1) the Problem: the General-purpose password. The decision: Individual user name or the Ciphered technical key – Alladin or P Card.

  5. Pavel Mir says:

    I write, not so attentively getting a grasp, time hasn’t enough. That that I see at first sight:

    1) the Problem: the General-purpose password. The decision: Individual user name or (криптоключ.

    2) the Problem: the input in OS Is registered only successful.
    The decision: Hardware-software system of technical protection with the closed environment (Electronic lock). Similar systems register abortive attempts of an input with даными about attempt (why attempt was unsuccessful).

    3) the Problem: Single-level access at Financiers and contractors.
    The decision: Sharing of users/groups on access type, the mandatory access pattern is desirable. To provide access to system/files only to those users, which файлынеобходимы for operation.

    4) the Problem: On FTP the data is transferred not by a safe method.
    The decision: Enciphering of the channel or VPN.

    5) the Problem: Incorrect segmentation of a network.
    The decision: a network Partition on the protected subnets, on a category to the information/access level.

  6. Marc Segarra López says:

    Hi all,

    I’ve seen that the fact of encryption of CHD in the transmission between the servers has been state as non-compliance. But if the transmission between the servers (all included in the CDE) is in a local area network then there is no need to encrypt the transmission, PCI Requirement 4 only applies to transmission over open, public networks. FTP protocol used is a non-compliant requirement due the use of non-secure protocols because the credentials are sent in clear but the information sent is encrypted in a zip file (I guess with an appropriate encryption algorithm).

    In addition, segmentation is not a PCI DSS requirement, so a flat network is not necessarily a non-compliant requirement.

    I just want to clarify these points because sometimes the QSA’s tend to require more than the PCI DSS requires.

  7. David Dann says:

    Yes, there are plenty of control deficiencies and bad practices in this scenario but I note the absence of that critical term, “card holder data” anywhere in the diagram or in the Info section. There is also no graphic or explanation of the transaction flow or business logic beyond the very vague “transactions are processed’ in the application server. Should we take it upon assumption that the files referred to in the diagram contain credit card data?

    Under PCI DSS what is in scope is the cc data environment. It’s possible, based on the information that is presented, that the actual credit card transaction flow in this case is tokenized and that would put it out of scope.

  8. Daniel says:

    Apani EpiForce reduces the burden of demonstrating regulatory compliance:

    * Meet regulatory security requirements without having to replace or rewrite existing applications
    # Central policy based management for the encryption of sensitive customer data in motion, including user names and passwords, and protect this data while at rest
    # Create closed user groups to ensure access to corporate applications is allowed only from authorized nodes
    # Dynamically segment the network (security zoning) through a centralized console without modifying any existing hardware; this enables the IT organization to reap the benefits of network segmentation (increased security and lower operating costs), without having to sacrifice network flexibility
    # Provide a strong audit trail for regulatory compliance audits.
    # Implement a solution that can scale to true enterprise levels while allowing phased deployments. EpiForce automatic enforcement of security policies offer a cost effective, innovative solution through the use of logical security zoning.
    # Complement plans for a ‘next generation’ network with enhanced security architecture, rather than simply block security threats at the perimeter.

  9. Ratan Jyoti says:

    Following is my pointwise analysis of the problem.Possible problems, solutions have been given against each observation.Applicable sections of PCI DSS has also been mentioned.

    1. Context :
    More info/ Access to servers is restricted to sysadmins and operators – account ‘srvadm_01’

    Problem :
    Generic Password has been used

    Possible Solution(s) :
    All users should be identified with a unique user name
    This will ensure accountability
    Generic or Group user like ‘srvadm_01’ should always be avoided

    Reference/ Applicable PCI DSS Clause :

    2. Context : More info/ Operating system logging successful logons
    Problem : Only successful logons are recorded.

    Possible Solution(s) :
    Both successful and unsuccessful logon attempts must be securely logged
    Logs from networking components, Database, Applications should be securely logged as per the best log management practices
    Reference/ Applicable PCI DSS Clause : Various sections of 10.2 like 10.2 5

    3. Context : More info/ Finance team including temps and contractors have access to application server for reporting. CHD masking is not needed, according to user
    Problem : depends on the nature of access as the Breaches by third – party such as outsourcers, contractors are noticed quite often
    Possible Solution(s) :
    Limit access to those individuals whose job requires such access.
    Use access on the basis of need to know, Least privilege and specific job responsibilities
    deny all access unless specifically needed and approved
    Use multifactor authentication when allowing third party access
    Ensure third party is PCI DSS compliant and auditable
    CHD masking must be ensured
    Compensating control wherever applicable must be in place eg. activity logs of contractors and other department officials must be verified by competent official.
    Reference/ Applicable PCI DSS Clause : 7.1 , 7.2 , 8.3, 12.10.3. ,12.3.10
    4. Context : More info/ One FTP account is used for all iSuck stores. Due to recent PCI DSS talks management wants to implement Windows EFS to the FTP and application servers
    Problems :
    Accountability cannot be ensured.
    Critical data is being transferred by FTP which is not a secure method
    File is transferred in clear text

    Possible Solution(s) :
    All users should be identified with a unique user name
    Secure File Transfer method (channel) should be used.
    Encryption should be used before file transfer
    Common password should not be used. A system based on asymmetric algorithm should be adopted to enable a unique set of key between two users.
    Checksum or hash should also be verified by system/manually(as per Card Data Environment) before processing a received/transferred file

    Reference/ Applicable PCI DSS Clause : 8.1, 12.3.10,3,4

    5.Context : More info/ Internal network is flat
    Problems :
    There is no segmentation of the network
    Possible Solution(s) :
    Adequate network segmentation, isolating systems that store, process, or transmit cardholder data from those that do not, may reduce the risk of system compromise.
    Reference/ Applicable PCI DSS Clause : 3.4

    6. Context : Diagram/ C
    Problems : file is zipped with the same password
    Possible Solution(s) :
    Suitable encryption method may be used
    Hash check should be ensured
    Suitable transfer (secure channel) should be used
    Different set of password/keys should be used to transfer between two entities
    Accountability should be ensured by using account with respective user name and not a generic username and password
    compensating control may be used

    Reference/ Applicable PCI DSS Clause : Various

    7. Context : Diagram/ D,E,F
    Problems :
    Manual copy, FTP, Unencrypted zip & Unzip
    Possible Solution(s) :

    Accountability should be ensured by user specific username and password
    A symmetric encryption may be used
    Secure channel may be used
    hashing algorithm may be used

    Reference/ Applicable PCI DSS Clause : Various
    8. Context : Diagram/ K, L
    transactions are processed by Finance team
    Possible Solution(s) :
    Segregation of duties must be ensured
    Maker and Checker system should be introduced

    Reference/ Applicable PCI DSS Clause : Various

    9. Context : Diagram/ N
    Problems :
    Unencrypted communication between application server and Database
    Possible Solution(s) :
    Channel should be secure
    Suitable policy should be in place
    Periodic Testing should be there

    Reference/ Applicable PCI DSS Clause : Various

    10. Context : Diagram/ B,M, P
    Problems :
    CHD is not masked and transferred and processed in clear text at various points
    CHD Data kept indefinitely.

    Possible Solution(s) :
    CHD as per PCI DSS requirement must not be recorded
    In selective cases where the same is allowed should be masked and transfer should be in encrypted channel
    the full contents of any track from the magnetic stripe should not be stored
    Account holder ’ s name , Primary account number, Expiration date, Service code in permitted case may only be stored with suitable masking and protection mechanism
    Card validation code and value, PIN and PIN block should not be stored
    Render PAN, at minimum, unreadable anywhere it is stored
    Sensitive authentication data subsequent to authorization should not be stored

    Reference/ Applicable PCI DSS Clause : 3.3, 3.4,3.2,, 3.2.3

    11. Context : Diagram/ O
    Problems :
    unencrypted database with critical data
    Possible Solution(s) :
    Critical data as per PCI DSS norms must be encrypted by suitable algorithm,
    Data at rest must be protected
    cardholder data storage should be at a minimum level

    Reference/ Applicable PCI DSS Clause : 3.1 and various other sections of 3

    12. Context : Diagram/ O,R
    Problems :
    unencrypted data is sent to backup tape
    Possible Solution(s) :
    Sensitive data including data on portable digital media, backup media, in logs, and data received from or stored by wireless networks should be encrypted and be at minimum level

    Reference/ Applicable PCI DSS Clause : 3.4

    Ratan Jyoti, CISSP,CISA,CEH
    Senior Manager (Information Security)
    Vijaya Bank,Bangalore.

  10. Petros Gionsi says:

    Hi Adriano – bored at home so I thought I would have a go … I like the challenges you are putting up!!

    Some holes I can see:

    1) Generic Server Admin Login should be user bound to a specific person.

    2) Operators should also have named logons specific to them.

    3) Operating System should also be logging non successful logons.

    4) Temps and Contractors needing access should be more carefully thought about.

    5) CHD should be masked appropriately.

    6) Need more specific FTP accounts for stores and users but the FTP access itself is suspect. Is it secure FTP, how are passwords protected, is ot over an SSL channel and is there an access controled per IP address etc etc.

    7) Internal network needs to be partitioned into appropriate zones with firewalls and IPS blocking access appropritely.

    8) FIle Servers should be in DMZ with App Servers in a restricted zone behind firewalls and potentially the Database in another segregated network zone behind the App Servers.

    9) All transmission of CHD between servers must be encrypted.

    10) CHD must be encrypted in storage as well.

    11) An assessment needs to be made as to is teh data being stored for a valid business purpose – if no valid purpose exists why are we even storing it?

    12) “Same Old” Password probably needs to be made more secure – maybe consider also using some sort of session key that changes regularly to encrypt the file and send over a secure SSL link.

    13) In summary file is loaded to many locations unsecurely and stored unsecurely within the environment.

    14) It also looks like the data stored on the backup tape is not encrypted and could be easily compromised – sounds like it is stored inteh office environment so would be easy for anybody to pick it up and walk away with it …

  11. I don’t have time at the moment to go through this and really tear it down, but a few quick and easy wins for iSuck to do would be issue the accountant at iSuck Store a new laptop with Full disk encryption (FDE), or if that accountant is a 3rd party contractor, require in their contract that such be provided.
    Then encrypt transmission at points E, I and N. FTP has 2 main encryption variants FTPS and SFTP that would be fairly simple to switch over to. Next I’d probably look at the backup processes..then the core business processes.