How to Get PCI DSS Certified: IT Grad Experience

In a previous post, we noted that we successfully recertified our infrastructure for PCI DSS and talked about the types of PCI DSS hosting: co-location, IaaS Basic and IaaS Advanced. Today we’ll talk in more detail about the certification process itself and our own audit experience.


/ photo NTNU CC

Who needs certification?


The requirements of the standard apply to all enterprises that process, transfer or store data of at least one credit card. In one of our previous articles, we provided a simple flow chart to help you understand who needs PCI DSS certification.

Its essence lies in the fact that it is enough for the management of the organization to answer these questions:

  1. Does the company work with PD card holders?
  2. Do company work processes affect the safety and security of card data?

If the answer to both of these questions is yes, then the company needs to be certified. For non-compliance with PCI DSS, the organization is required to pay a fine in the amount of 10 to 200 thousand dollars, depending on:

  • type of payment system (Visa or MasterCard);
  • company status (member, service provider or trade organization);
  • repeatability of the violation (first, second and subsequent).

The first time we certified on PCI DSS back in 2015, becoming one of the first cloud providers to be audited for compliance with the requirements of the standard.

Next, we describe how this process went.

Stage 1: preparation of documentation


Before undergoing an audit, the company must prepare regulatory and administrative documents on information security (instructions, regulations, policies). At the time of the first certification, most of them were already developed by us, but some still had to be finalized.

For example, we had to edit a policy that contains goals, objectives and ways to ensure information security in the enterprise. We have also revised the regulations defining the principles for managing vulnerabilities and incidents. For example, we have formed the “Regulation for managing access to information assets” - it describes the rules for working with access rights and the requirements for user credentials.

Note that all documents must be reviewed and adjusted annually. Especially if there were changes in the IT structure of the company.

Stage 2: building IT infrastructure


The next step is preparing the infrastructure. If the organization undergoes an audit for the first time, then management needs to determine the scope that will be certified, that is, limit a separate infrastructure unit that will support all processes subject to certification. This is necessary so that you do not have to accompany any changes to the infrastructure with new tests for compliance with the requirements of the standard.

To do this, we had to organize a separate infrastructure with a dedicated network, deploy ESX, vSphere and vCenter servers, install switches and a firewall to prevent attackers. We duplicated all this equipment, and then made diagrams of services, networks and business processes.

The certified infrastructure must be separated from other networks of the organization - access to it must be provided through an isolated interface. To fulfill this requirement, we use a VPN with 2FA and isolate the segment of each client.

Inside the perimeter is an NTP server, logging services, antivirus, firewall, as well as solutions to prevent cyberattacks and control the safety of data. You can see our network diagram here .

Stage 3: Pentest


Pentest is conducted by a special team on behalf of the audit company. Auditors check the operation of the solutions that are used to protect the data of cardholders, and identify potential security holes.

Before we begin to check the infrastructure for penetration resistance, our team prepared two ospreys. The first with service services and applications involved in testing. On the second, a VM with OS was configured, the necessary rights were assigned to the corresponding accounts.


/ An example of an osprey with hosted services and applications
Pentest of our infrastructure was carried out in several stages.

Nmap scan

Auditors checked the white IP addresses of our company. On machines with public IP addresses, they could not find open ports (only those that were responsible for the functioning of our infrastructure were open).

VPN connection and internal network check

The pentest team tried to access from an untrusted network. The test results showed that it is impossible to penetrate the IT-GRAD infrastructure via VPN without 2FA. Checking the internal network also did not reveal violations.

Attempt to access infrastructure connection by account

On a third-party resource (this resource was iaas-blog.it-grad.ru), the experts obtained the credentials of one of our colleagues. This colleague also had an account in the tested IT-GRAD infrastructure. The auditors tried to log in using his account and password, but they did not succeed because the network was quite segmented.

In total, according to the results of the audit, we found 7 vulnerabilities of varying degrees of criticality: one high and 3 medium and low levels of “danger”.

Our most critical vulnerability - WAF malfunctioning - arose because the firewall used could not cope with complex attacks. In order to eliminate the vulnerability, we deployed the Apache web server with the Modsecurity module, and then updated the WAF signature database.

There were three vulnerabilities of the middle level. The first is the included TRACE method, which attackers can use, for example, for cross-site scripting . To eliminate the vulnerability, we deactivated the TRACE method.

The second mismatch is the lack of secure HTTP headers. Vulnerability can cause attackers to attack the user interface. We solved this problem by enabling secure headers on the corresponding application server.

And the third vulnerability is the vulnerability of software on one of the hosts (due to an outdated version of the software). To fix this vulnerability, we set up regular software updates on all nodes.

Among the low criticality vulnerabilities, auditors found test data with password hashes in the production environment. They also pointed out unreliable passwords and unnecessary software. We replaced the vulnerable passwords with secure ones and deleted unused data and software. After fixing all the vulnerabilities, we successfully passed the repeated pentest.

Stage 4: final audit


At the last stage of the audit, the auditor evaluates the completeness and parameters of software and hardware, network topology, OS configuration, isolation of infrastructure segments and other characteristics. In addition, he can check the documentation and knowledge of employees, ask questions of an organizational or technical nature.

If your company shows slight deviations from the requirements of the standard, they can be eliminated during the audit. For example, we found an inactive computer account in Active Directory, which we quickly deleted.

If you needed to change something before or during the audit, this is not a problem either. The main thing here is to make changes as required by PCI DSS.

For example, before an audit, we at IT-GRAD needed to track the loading and unloading of files on an SFTP server. To do this, we had to urgently write a decoder for the avusm server. Without a decoder, the server did not save the necessary messages, because it could not “parse” the logs and generate alerts.

Ultimately, we received a PCI DSS compliance certificate and became one of the first IaaS providers in Russia to provide a PCI DSS hosting service.



PS Some material on the topic from the First Corporate IaaS Blog: