How to make practical use of paper security, or why do we need compliance with 152-ФЗ and PCI DSS in one cloud
Our Cloud-152 IaaS platform is simultaneously certified according to PCI DSS and has a certificate of conformity 152- for UZ-2 (without actual threats of the 1st and 2nd type). The same platform is also included in the scope of our information security management system (ISMS), which we have certified according to ISO / IEC 27001: 2013. I’ll definitely tell you about this and the STAR Cloud Security Alliance (CSA), too, but today I will focus on the advantages of the PCI DSS and 152- synergies for our customers.
We live in Russia, our customers mainly do business in the Russian Federation, and everyone has to comply with the requirements of Russian legislation in the field of personal data protection. The same Federal Law “On Personal Data” dated July 27, 2006 No. 152- and corrections to it from 242-Federal Law of July 21, 2014 regarding the processing of personal data of citizens of the Russian Federation in databases located on the territory of the Russian Federation. Not everyone needs GDPR, and I will also take this topic beyond the scope of this article.
152- was conceived to protect the rights of PD subjects. The law does not provide ready-made recipes for the protection of personal data through the introduction and configuration of protective equipment (SZI). If you go down to a more “specific” level of Government Decree No. 1119, FSTEC Order of Russia No. 21 and FSB Order of Russia No. 378, then it’s more about the fact that funds are available (in some cases certified), and not how this should be set up to be safe.
PCI DSS defines data security requirements in the payment card industry. The scope of its action is associated with money, which everyone traditionally protects with particular care. It has more specifics, requirements and reading sheets :).
It may seem strange to someone that the connection itself on the same PCI DSS and 152- platform, but for us this makes sense. This is not just about two in one bottle, but, more importantly, the combination of paper and practical security.
I’ll give a few examples about this system of “checks and balances”.
Example 1. A certificate for infrastructure that meets the requirements of 152-FZ is issued for 3 years. During this time, nothing in the infrastructure should change, or it must necessarily be agreed with the organization that issued the certificate. Certification is equal to fixing the system for three whole years. How the infrastructure meets the requirements from verification to verification is on the conscience of the certified.
PCI DSS has a shorter audit cycle: an audit every year. In addition to this, a pentest (external and internal intruder) is held 2 times a year and an Approved Scanning Vendor (ASV) scan 4 times a year. This is enough to keep the infrastructure in good shape.
Example 2. Certification according to 152- has its own price, and these are limitations in the choice of software and means of protection. If you are going to undergo certification, then all of them must be certified . Certified - means not the latest versions of software and SZI. For example, PAC CheckPoint is certified, the 2012 model range, firmware R77.10. The certification is now R77.30, but vendor support already ends in September 2019. PCI DSS does not have such requirements (except for the scanner - it should be from the list of approved ones). This allows you to use parallel protection tools that have no problems with the relevance of versions.
Example 3. Both 152- and PCI DSS require a firewall (ME). Only the FSTEC of Russia simply requires its presence, and in the case of certification, it also requires a certificate of compliance with the requirements of the FSTEC of Russia. At the same time, FSTEC has no requirements for its configuration and maintenance. In fact, the firewall can simply be, but it works correctly and if it works in principle, it is not spoken of in the document. The same situation is with antivirus protection (SAVZ), intrusion detection (SOV) and information protection from unauthorized access (SZI from NSD).
Inspections of certifying organizations also cannot guarantee that everything works as it should. Often, everything is limited to uploading all the firewall rules. It also happens that they simply remove the checksums from the files of the Gaia OS (CheckPoint OS). These files change dynamically, and their checksum too. There is little sense in such checks.
There are also the requirements of manufacturers of certified SZI for their installation and operation. But in my practice I saw very few certifications (not state secrets), during which the performance of the technical specifications at the SZI would be checked.
The PCI DSS standard requires an analysis of the firewall rules by the certificate holder once every six months. Once a month, DataLine cybersecurity center experts check the ME rules in Cloud-152 to find unnecessary, temporary and irrelevant. Each new rule passes through our Service Desk, a description of this rule is recorded in the ticket. When a new rule is created on the ME, the ticket number is written in the comment.
Example 4. The order of the FSTEC of Russia No. 21 implies the need for a vulnerability scanner, again certified for certification. As an additional measure, a pen-test is provided, testing of IP for penetration in clause 11.
The reports from these scanners are also fun. When our clients pass certification of their IPs hosted in Cloud-152, often the certifying organization wants to receive a blank report that does not contain vulnerabilities in the certified IP. In addition, certifiers are usually limited to internal scans. External scanning in my practice was done by certifiers only a few times, and these were offices with a name.
PCI DSS clearly prescribes not only the presence of a scanner, but also a regular ASV scan (Approved Scanning Vendor) 4 times a year. According to its results, the vendor’s engineers check the report and give an opinion. And penetration testing for Cloud-152 is carried out 2 times a year in accordance with PCI DSS requirements.
Example 5. Multifactor authentication. Order No. 21 of the FSTEC of Russia does not explicitly state this requirement. PCI DSS, however, requires multifactor authentication.
Now let's see how the standard and the law “coexist” on the same infrastructure.
The Cloud-152 control segment and the client area are located on different physical equipment in dedicated racks with access control and video surveillance.
Cloud-152 is built on VMware vSphere 6.0 (certificate No. 3659). In the near future we will switch to 6.5, and 6.7 will be already under inspection control.
We do not use additional SPI at the virtualization level, since we sign a tight SLA with clients for the availability of the IaaS platform, so we try to minimize additional points of failure.
The Cloud-152 control segment is separated from DataLine, client networks, and the Internet using a certified Check Point hardware and software system that combines the functions of a firewall and intrusion detection tool (certificate No. 3634).
Client-side administrators pass SafeNet Trusted Access (STA) two-factor authentication before gaining access to virtual resources.
Cloud-152 administrators connect to the cloud through the control and monitoring tool for privileged users of SKDPU (certificate No. 3352). Next, two-factor authentication also passes, and only then gain access to Cloud-152 management. This is required by the PCI DSS standard.
As a means of protection against unauthorized access, we use SecretNet Studio (certificate No. 3675). Anti-virus protection is provided through Kaspersky Security for virtualization (certificate No. 3883).
Three scanners are involved in Cloud-152 at once:
In addition, 4 times a year we carry out a mandatory ASV scan for PCI DSS.
As SIEM, Splunk is used, which is no longer sold in the Russian Federation. Now we are in the process of searching for a new solution, we are conducting tests. SIEM is required for PCI DSS compliance.
Cloud-152 Scheme
Now that I’ve described in detail how compliance with PCI DSS in the IaaS platform under 152- helps to achieve real security, you may ask: why complicate things like this when you can make it work without any PCI DSS. Yes, it is possible, but together with PCI DSS we have proof of this in the form of a certificate, which we confirm annually.
We live in Russia, our customers mainly do business in the Russian Federation, and everyone has to comply with the requirements of Russian legislation in the field of personal data protection. The same Federal Law “On Personal Data” dated July 27, 2006 No. 152- and corrections to it from 242-Federal Law of July 21, 2014 regarding the processing of personal data of citizens of the Russian Federation in databases located on the territory of the Russian Federation. Not everyone needs GDPR, and I will also take this topic beyond the scope of this article.
152- was conceived to protect the rights of PD subjects. The law does not provide ready-made recipes for the protection of personal data through the introduction and configuration of protective equipment (SZI). If you go down to a more “specific” level of Government Decree No. 1119, FSTEC Order of Russia No. 21 and FSB Order of Russia No. 378, then it’s more about the fact that funds are available (in some cases certified), and not how this should be set up to be safe.
PCI DSS defines data security requirements in the payment card industry. The scope of its action is associated with money, which everyone traditionally protects with particular care. It has more specifics, requirements and reading sheets :).
It may seem strange to someone that the connection itself on the same PCI DSS and 152- platform, but for us this makes sense. This is not just about two in one bottle, but, more importantly, the combination of paper and practical security.
I’ll give a few examples about this system of “checks and balances”.
Example 1. A certificate for infrastructure that meets the requirements of 152-FZ is issued for 3 years. During this time, nothing in the infrastructure should change, or it must necessarily be agreed with the organization that issued the certificate. Certification is equal to fixing the system for three whole years. How the infrastructure meets the requirements from verification to verification is on the conscience of the certified.
PCI DSS has a shorter audit cycle: an audit every year. In addition to this, a pentest (external and internal intruder) is held 2 times a year and an Approved Scanning Vendor (ASV) scan 4 times a year. This is enough to keep the infrastructure in good shape.
Example 2. Certification according to 152- has its own price, and these are limitations in the choice of software and means of protection. If you are going to undergo certification, then all of them must be certified . Certified - means not the latest versions of software and SZI. For example, PAC CheckPoint is certified, the 2012 model range, firmware R77.10. The certification is now R77.30, but vendor support already ends in September 2019. PCI DSS does not have such requirements (except for the scanner - it should be from the list of approved ones). This allows you to use parallel protection tools that have no problems with the relevance of versions.
Example 3. Both 152- and PCI DSS require a firewall (ME). Only the FSTEC of Russia simply requires its presence, and in the case of certification, it also requires a certificate of compliance with the requirements of the FSTEC of Russia. At the same time, FSTEC has no requirements for its configuration and maintenance. In fact, the firewall can simply be, but it works correctly and if it works in principle, it is not spoken of in the document. The same situation is with antivirus protection (SAVZ), intrusion detection (SOV) and information protection from unauthorized access (SZI from NSD).
Inspections of certifying organizations also cannot guarantee that everything works as it should. Often, everything is limited to uploading all the firewall rules. It also happens that they simply remove the checksums from the files of the Gaia OS (CheckPoint OS). These files change dynamically, and their checksum too. There is little sense in such checks.
There are also the requirements of manufacturers of certified SZI for their installation and operation. But in my practice I saw very few certifications (not state secrets), during which the performance of the technical specifications at the SZI would be checked.
The PCI DSS standard requires an analysis of the firewall rules by the certificate holder once every six months. Once a month, DataLine cybersecurity center experts check the ME rules in Cloud-152 to find unnecessary, temporary and irrelevant. Each new rule passes through our Service Desk, a description of this rule is recorded in the ticket. When a new rule is created on the ME, the ticket number is written in the comment.
Example 4. The order of the FSTEC of Russia No. 21 implies the need for a vulnerability scanner, again certified for certification. As an additional measure, a pen-test is provided, testing of IP for penetration in clause 11.
The reports from these scanners are also fun. When our clients pass certification of their IPs hosted in Cloud-152, often the certifying organization wants to receive a blank report that does not contain vulnerabilities in the certified IP. In addition, certifiers are usually limited to internal scans. External scanning in my practice was done by certifiers only a few times, and these were offices with a name.
PCI DSS clearly prescribes not only the presence of a scanner, but also a regular ASV scan (Approved Scanning Vendor) 4 times a year. According to its results, the vendor’s engineers check the report and give an opinion. And penetration testing for Cloud-152 is carried out 2 times a year in accordance with PCI DSS requirements.
Example 5. Multifactor authentication. Order No. 21 of the FSTEC of Russia does not explicitly state this requirement. PCI DSS, however, requires multifactor authentication.
Now let's see how the standard and the law “coexist” on the same infrastructure.
About the Cloud-152 device
The Cloud-152 control segment and the client area are located on different physical equipment in dedicated racks with access control and video surveillance.
Cloud-152 is built on VMware vSphere 6.0 (certificate No. 3659). In the near future we will switch to 6.5, and 6.7 will be already under inspection control.
We do not use additional SPI at the virtualization level, since we sign a tight SLA with clients for the availability of the IaaS platform, so we try to minimize additional points of failure.
The Cloud-152 control segment is separated from DataLine, client networks, and the Internet using a certified Check Point hardware and software system that combines the functions of a firewall and intrusion detection tool (certificate No. 3634).
Client-side administrators pass SafeNet Trusted Access (STA) two-factor authentication before gaining access to virtual resources.
Cloud-152 administrators connect to the cloud through the control and monitoring tool for privileged users of SKDPU (certificate No. 3352). Next, two-factor authentication also passes, and only then gain access to Cloud-152 management. This is required by the PCI DSS standard.
As a means of protection against unauthorized access, we use SecretNet Studio (certificate No. 3675). Anti-virus protection is provided through Kaspersky Security for virtualization (certificate No. 3883).
Three scanners are involved in Cloud-152 at once:
- Certified XSpider (Certificate No. 3247) to comply with 152-FZ requirements. We use it once a quarter.
- Nessus for the actual work of searching and analyzing vulnerabilities within the Cloud-152 platform.
- Qualys is the scanner we need for external scanning according to PCI DSS requirements. We use it monthly, and sometimes more often.
In addition, 4 times a year we carry out a mandatory ASV scan for PCI DSS.
As SIEM, Splunk is used, which is no longer sold in the Russian Federation. Now we are in the process of searching for a new solution, we are conducting tests. SIEM is required for PCI DSS compliance.
Cloud-152 Scheme
Now that I’ve described in detail how compliance with PCI DSS in the IaaS platform under 152- helps to achieve real security, you may ask: why complicate things like this when you can make it work without any PCI DSS. Yes, it is possible, but together with PCI DSS we have proof of this in the form of a certificate, which we confirm annually.
All Articles