PCI DSS 3.0 - ¿Es necesario restringir la salida de SSH y / o RDP?

Question

PCI DSS 3.0 - ¿Es necesario restringir la salida de SSH y / o RDP?

#1 de sebastian nielsen (1 votos)

1

Esta pregunta surge mucho al igual que las evaluaciones para diferentes clientes. Actualmente recomiendo lo siguiente:

Todas las salidas SSH y amp; RDP bloqueado por defecto desde la red del usuario (no CDE)
Todas las salidas SSH y amp; RDP bloqueado por defecto de la red de producción (no CDE)
Todas las salidas SSH y amp; RDP bloqueado de forma predeterminada desde el Entorno de datos de tarjeta (CDE)
Todas las salidas SSH y amp; RDP para empresas requiere un ticket de control de cambios y un ticket de excepción

Cito la sección 1.2.1 de PCI DSS 3.0 como justificación. Sin embargo, no se establece explícitamente que esto es necesario. Recibo más rechazo que esto es demasiado extenso.

Razones del requisito en mis conclusiones:

SSH permite la conexión de salida desde las comunicaciones seguras de los hosts dinámicos, especialmente cuando se conecta a la producción
La desactivación debe ser parte de una estrategia de protección de DLP
Sigue los principios de negar todo para mayores protecciones
Evita la luz de la luna a otros clientes / clientes mientras esté en este horario de compañías

¿Pero hay algún requisito explícito, que pueda articularse, que PCI DSS requiera este modelo?

ssh pci-dss

pregunta hackajar 13.11.2014 - 19:03

fuente

1 respuesta

Lea otras preguntas en las etiquetas ssh pci-dss

¿Qué podría suceder si los metacaracteres de expresiones regulares que usan un grupo de captura con nombre no están codificados? detección de VPN con cliente instalado [cerrado]

score 1 · Accepted Answer

Puede aislar la red de usuario y la red de producción completamente del CDE, por lo que un compromiso total del entorno no CDE no puede comprometer de ninguna manera, reducir la seguridad, o de alguna otra manera, afectar el entorno CDE.

Si lo hace, entonces la red de usuario y la red de producción se considerarían fuera del alcance de PCI.

Sin embargo, es una buena higiene de la computadora seguir bloqueando los valores predeterminados de salida de SSH / RDP para evitar que el malware "llame a casa". Pero al aislar el CDE del entorno no CDE para obtener fuera del alcance de la red de usuario y de la red de producción, entonces no es necesario tener ningún procedimiento "estricto" para abrir los puertos. Por ejemplo, no es necesario seguir los procedimientos de PCI-DSS para abrir puertos en la parte de la red que no es CDE.

Luego puede tener cerrado SSH / RDP, pero aquellos que necesitan SSH / RDP para negocios simplemente necesitan llamar por teléfono y tener el puerto abierto frente a ellos.

Por lo tanto, coloca el CDE con su propio firewall, en una conexión de Internet WAN pública, y la red de usuario / red de producción, en una Otra conexión WAN con su propio firewall. Esto hará que la red CDE y la red de usuario / producción estén completamente separadas.

Ninguna parte de la red de producción o usuario puede estar autorizada para pasar el firewall CDE. Todo antes de que el firewall CDE deba tratarse como WAN cuando se habla de cumplimiento con PCI-DSS.

Tenga en cuenta que el Firewall CDE también debe colocarse dentro de los límites físicos del entorno PCI-DSS de CDE, por lo que el firewall CDE en sí mismo obtiene la misma seguridad física que el entorno CDE.

Tenga en cuenta que la parte "iluminada por la luna" no es algo definido por PCI-DSS. PCI-DSS se trata de proteger a sus clientes, no a usted mismo. Al obtener fuera del alcance de su red de usuarios y de la red de producción, no necesita preocuparse por proteger a sus clientes cuando jueguen con la red de usuarios y la red de producción, solo tiene que preocuparse por usted mismo.

Por lo tanto, si luego desea tener una protección "a la luz de la luna", depende de la Compañía. No tienen que pensar un poco en el PCI-DSS cuando jueguen con la red de producción / usuario si el entorno CDE está segmentado correctamente.