PCI-DSS 3.2 compliance with EFT
Enforced multi-factor authentication (MFA)
- This does not necessarily mean you need to rush out and buy a One-Time-Password solution, such as SecureID or SMS Passcode. Of course, the Advanced Authentication Module (AAM) supports these, but there are alternatives. You can enable Password and Private Key authentication, or restrict users so they can only log in from their explicit IP address. Automated accounts set up in EFT typically use IP and Private Key authentication to achieve MFA. But if your accounts are not tied to specific IPs, you can run an “Activity – By User (Detailed)” report to show which IP addresses each account is connecting in from. These can then be attached to the account so users can only access the account from this address.
You can find out more about MFA in EFT in our Top Tip, Implementing Multi-Factor Authentication on EFT Server.
Encrypt data at rest and in transit
- Encrypting data in transit and at rest can be as simple as:
– Making sure connections into your system are not using FTP or HTTP.
– Enabling either PGP encryption or using the EFS function of the High Security Module (HSM).
Most external connections are probably already using SFTP or FTPS as their protocol, but we have seen an increasing number of Information Security Officers requesting moving all internal transfers to secure protocols too. Many servers do not store data encrypted at rest, especially if the data is then passed on to a remote location. Enabling encryption at rest is as simple as clicking a tick box on the “folders” tab of the server. With EFS ticked, EFT will automatically handle encryption and decryption on the fly as the file is accessed.
You can find out more in our Top Tip, Encrypting data at rest.
Protect shared data using secured accounts
- If your organisation has to share data with external third parties, EFT’s Workspaces module will secure the files and protect your data. Users have to register and authenticate themselves to collect the files, avoiding data falling into the wrong hands. This is a secure alternative to sending messages and files containing cardholder data by email. Email does not require authentication and is not automatically encrypted at rest.
You can find out more in our Top Tip, How to control and improve the use of workspaces in your EFT system.
Implement a least privilege access model
Least privilege means restricting user and administrator rights so they can only access the data and functions they really need. This can reduce the risk of data loss and security breaches.
Get technical advice to help configure admin user accounts in our Top Tip, Securing your administrator access.
Review compliance regularly
- PCI-DSS requires a quarterly review of the compliance status of your systems. Even if your sites are not built using the PCI compliance mode, if you have the High Security Module (HSM), you can still run a PCI compliance report to show your system state. This will alert you to any failures or weak points, which you should then address immediately. You can build a scheduled rule to generate this report, which will make sure it doesn’t get missed. EFT Enterprise has the scheduler included, whereas SMB requires an optional module – you can speak to your account manager for more details.
Read up on how to generate an automated report rule in our Top Tip, How to generate a summary transmission report in EFT ARM.
Expire deprecated encryption standards
- You need to get rid of SSL and TLS v1. This is not a requirement until later in the year but SSL v3.0 and TLS v1 can be turned off easily by unchecking the boxes on the server’s “security” tab in the EFT console. Doing this now will allow you to see which connections are using these outdated protocols and address any issues before the deadline, as well as making your system more secure.