March 21, 2018 at 21:35How to Get PCI DSS Certified: IT Grad Experience
In one of our previous posts, we noted that we successfully recertified our infrastructure on PCI DSS and talked about the types of PCI DSS hosting: co-location, IaaS Basic and IaaS Advanced. Today we’ll talk more about the certification process itself and our own audit experience. / photo NTNU CC
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 the management of the organization is enough to answer these questions:
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 must pay a fine in the amount of 10 to 200 thousand dollars, depending on:
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 will describe how this process went.
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 that define 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.
The next step is preparing the infrastructure. If the organization undergoes an audit for the first time, then the 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 each client segment.
Inside the perimeter is an NTP server, logging services, antivirus, firewall, as well as solutions to prevent cyberattacks and control data safety. You can see our network diagram here .
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 utility 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.
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).
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.
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 fix 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. We were also told about weak passwords and excess 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.
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 promptly 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:
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 the management of the organization is enough to answer these questions:
- Does the company work with PD card holders?
- 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 must 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 will 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 that define 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 the 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 each client segment.
Inside the perimeter is an NTP server, logging services, antivirus, firewall, as well as solutions to prevent cyberattacks and control data safety. 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 utility 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 fix 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. We were also told about weak passwords and excess 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 promptly 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: