Cómo hacer un uso práctico de la seguridad del papel, o por qué necesitamos cumplir con 152-ФЗ y PCI DSS en una nube

Nuestra plataforma Cloud-152 IaaS está certificada simultáneamente según PCI DSS y tiene un certificado de conformidad 152- para UZ-2 (sin amenazas reales del primer y segundo tipo). La misma plataforma también se incluye en el alcance de nuestro sistema de gestión de seguridad de la información (SGSI), que hemos certificado de acuerdo con ISO / IEC 27001: 2013. Definitivamente le contaré sobre esto y sobre STAR Cloud Security Alliance (CSA) , pero hoy me centraré en las ventajas de PCI DSS y las sinergias 152-- para nuestros clientes.


Vivimos en Rusia, nuestros clientes hacen negocios principalmente en la Federación Rusa, y todos deben cumplir con los requisitos de la legislación rusa en el campo de la protección de datos personales. La propia Ley Federal "sobre datos personales", de fecha 27 de julio de 2006, número 152-and, y sus correcciones de la Ley 242-Federal de 21 de julio de 2014 sobre el procesamiento de datos personales de ciudadanos de la Federación de Rusia en bases de datos ubicadas en el territorio de la Federación de Rusia. No todos necesitan GDPR, y también llevaré este tema más allá del alcance de este artículo.

152- fue concebido para proteger los derechos de los sujetos con EP. La ley no proporciona recetas listas para la protección de datos personales a través de la introducción y configuración de equipos de protección (SZI). Si baja a un nivel más "específico" del Decreto del Gobierno No. 1119, la Orden de Rusia FSTEC No. 21 y la Orden FSB de Rusia No. 378, entonces se trata más sobre el hecho de que hay fondos disponibles (en algunos casos certificados), y no cómo se debe configurar para estar a salvo

PCI DSS define los requisitos de seguridad de datos en la industria de las tarjetas de pago. El alcance de su acción está asociado con el dinero, que todos tradicionalmente protegen con especial cuidado. Tiene más detalles, requisitos y hojas de lectura :).

Puede parecer extraño a alguien que la conexión en sí en la misma plataforma PCI DSS y 152-, pero para nosotros esto tiene sentido. No se trata solo de dos en una botella, sino, lo que es más importante, la combinación de papel y seguridad práctica.
Daré algunos ejemplos sobre este sistema de "controles y equilibrios".

Ejemplo 1. Se emite un certificado de infraestructura que cumple con los requisitos de 152-FZ por 3 años. Durante este tiempo, nada en la infraestructura debe cambiar, o necesariamente debe acordarse con la organización que emitió el certificado. La certificación equivale a arreglar el sistema durante tres años completos. La forma en que la infraestructura cumple con los requisitos desde la verificación hasta la verificación depende de la conciencia del certificado.

PCI DSS tiene un ciclo de auditoría más corto: una auditoría cada año. Además de esto, se realiza un pentest (intruso externo e interno) 2 veces al año y un escaneo del Proveedor de Escaneo Aprobado (ASV) 4 veces al año. Esto es suficiente para mantener la infraestructura en buen estado.

Ejemplo 2. La certificación según 152- tiene su propio precio, y estas son limitaciones en la elección del software y los medios de protección. Si va a someterse a una certificación, todos ellos deben estar certificados . Certificado: significa no las últimas versiones de software y SZI. Por ejemplo, PAC CheckPoint está certificado, la gama de modelos 2012, firmware R77.10. La certificación ahora es R77.30, pero el soporte del proveedor ya finaliza en septiembre de 2019. PCI DSS no tiene tales requisitos (excepto para el escáner, debe ser de la lista de aprobados). Esto le permite utilizar herramientas de protección paralelas que no tienen problemas con la relevancia de las versiones.

Ejemplo 3. Tanto 152- como PCI DSS requieren un firewall (ME). Solo el FSTEC de Rusia simplemente requiere su presencia, y en el caso de la certificación, también requiere un certificado de cumplimiento de los requisitos del FSTEC de Rusia. Al mismo tiempo, FSTEC no tiene requisitos para su configuración y mantenimiento. De hecho, el firewall simplemente puede ser, pero funciona correctamente y si funciona en principio, no se menciona en el documento. La misma situación es con la protección antivirus (SAVZ), la detección de intrusos (SOV) y la protección de la información contra el acceso no autorizado (SZI de NSD).

Las inspecciones de las organizaciones de certificación tampoco pueden garantizar que todo funcione como debería. A menudo, todo se limita a cargar todas las reglas de firewall. También sucede que simplemente eliminan las sumas de verificación de los archivos del SO Gaia (CheckPoint OS). Estos archivos cambian dinámicamente, y su suma de comprobación también. Tiene poco sentido en tales controles.

También hay requisitos de los fabricantes de SZI certificados para su instalación y operación. Pero en mi práctica vi muy pocas certificaciones (no secretos de estado), durante las cuales se verificaba el desempeño de las especificaciones técnicas en el SZI.

El estándar PCI DSS requiere un análisis de las reglas del firewall por parte del titular del certificado una vez cada seis meses. Una vez al mes, los especialistas del centro de ciberseguridad DataLine verifican las reglas de ME en Cloud-152 para encontrar innecesarias, temporales e irrelevantes. Cada nueva regla pasa a través de nuestro Service Desk, una descripción de esta regla se registra en el ticket. Cuando se crea una nueva regla en el ME, el número de ticket se escribe en el comentario.

Ejemplo 4. La orden del FSTEC de Rusia No. 21 implica la necesidad de un escáner de vulnerabilidad, nuevamente certificado para la certificación. Como medida adicional, se proporciona una prueba de lápiz, prueba de IP para penetración en la cláusula 11.

Los informes de estos escáneres también son divertidos. Cuando nuestros clientes pasan la certificación de sus IP alojadas en Cloud-152, a menudo la organización certificadora desea recibir un informe vacío que no contenga vulnerabilidades en la IP certificada. Además, los certificadores generalmente se limitan a escaneos internos. El escaneo externo en mi práctica fue realizado por certificadores solo unas pocas veces, y estas fueron oficinas con un nombre.

PCI DSS prescribe claramente no solo la presencia de un escáner, sino también un escaneo ASV regular (proveedor de escaneo aprobado) 4 veces al año. Según sus resultados, los ingenieros del proveedor verifican el informe y emiten una opinión. Y las pruebas de penetración para Cloud-152 se llevan a cabo 2 veces al año de acuerdo con los requisitos de PCI DSS.

Ejemplo 5. Autenticación multifactorial. La Orden N ° 21 del FSTEC de Rusia no establece explícitamente este requisito. Sin embargo, PCI DSS requiere autenticación multifactor.

Ahora veamos cómo el estándar y la ley "coexisten" en la misma infraestructura.

Sobre Cloud-152


El segmento de control Cloud-152 y el área del cliente están ubicados en diferentes equipos físicos en bastidores dedicados con sistemas de control de acceso y video vigilancia.

Cloud-152 está construido en VMware vSphere 6.0 (certificado No. 3659). En un futuro cercano cambiaremos a 6.5, y 6.7 ya estará bajo control de inspección.
No utilizamos SPI adicional a nivel de virtualización, ya que firmamos un SLA estricto con los clientes para la disponibilidad de la plataforma IaaS, por lo que tratamos de minimizar los puntos de falla adicionales.

El segmento de control Cloud-152 está separado de DataLine, las redes de clientes e Internet mediante un sistema de hardware y software Check Point certificado que combina las funciones de un cortafuegos y una herramienta de detección de intrusos (certificado No. 3634).

Los administradores del lado del cliente pasan la autenticación de dos factores SafeNet Trusted Access (STA) antes de acceder a los recursos virtuales.
Los administradores de Cloud-152 están conectados a la nube a través de un medio de monitoreo y seguimiento de las acciones de los usuarios privilegiados de SKDPU (certificado No. 3352). A continuación, también se aprueba la autenticación de dos factores, y solo entonces obtienen acceso a la administración de Cloud-152. Esto es requerido por el estándar PCI DSS.

Como medio de protección contra el acceso no autorizado, utilizamos SecretNet Studio (certificado No. 3675). La protección antivirus se proporciona a través de Kaspersky Security para virtualización (certificado No. 3883).

Tres escáneres participan en Cloud-152 a la vez:

  • Certificado XSpider (Certificado No. 3247) para cumplir con los requisitos de 152-FZ. Lo usamos una vez por trimestre.
  • Nessus para el trabajo real de búsqueda y análisis de vulnerabilidades dentro de la plataforma Cloud-152.
  • Qualys es el escáner que necesitamos para el escaneo externo de acuerdo con los requisitos de PCI DSS. Lo usamos mensualmente y, a veces, con más frecuencia.

Además, 4 veces al año realizamos un escaneo ASV obligatorio para PCI DSS.

Como SIEM, se usa Splunk, que ya no se vende en la Federación Rusa. Ahora estamos en el proceso de encontrar una nueva solución, estamos realizando pruebas. Se requiere SIEM para el cumplimiento de PCI DSS.

Esquema Cloud-152

Ahora que he descrito en detalle cómo el cumplimiento de las PCI DSS en la plataforma IaaS bajo 152- ayuda a lograr una seguridad real, probablemente se pregunte: ¿por qué complicar cosas como esta cuando puede hacer que funcione sin ninguna PCI DSS? Sí, es posible, pero junto con PCI DSS tenemos prueba de esto en forma de certificado, que confirmamos anualmente.

Source: https://habr.com/ru/post/465223/


All Articles