jueves, 28 de febrero de 2013

Implementando el Requerimiento 1 de PCI DSS (II)

Continuando el análisis del primer requerimiento del estándar PCI DSS iniciado en la entrada previa, ahora nos toca analizar el requerimiento 1.3:

1.3 Prohíba el acceso directo público entre Internet y todo componente del sistema en el entorno de datos de los titulares de tarjetas.

1.3.1 Implemente un DMZ para limitar el tráfico entrante sólo a aquellos componentes del sistema que proporcionan servicios, protocolos y puertos con acceso público autorizado.

1.3.2 Restrinja el tráfico entrante de Internet a las direcciones IP dentro del DMZ.

1.3.3 No permita ninguna conexión directa de entrada o salida de tráfico entre Internet y el entorno del titular de la tarjeta.

1.3.4 No permita que las direcciones internas pasen desde Internet al DMZ.

1.3.5 No permita que llegue tráfico saliente no autorizado proveniente del entorno de datos del titularde la tarjeta a Internet.

1.3.6 Implemente la inspección completa, también conocida como filtrado dinámico de paquetes. (Es decir, sólo se permite la entrada a la red de conexiones establecida).

1.3.7 Coloque los componentes del sistema que almacenan datos de titulares de tarjetas (como una base de datos) en una zona de red interna, segregada desde un DMZ y otras redes no confiables.

1.3.8 No divulgue direcciones IP privadas ni información de enrutamiento a partes no autorizadas,

  • Traducción de Dirección de Red (NAT)
  • Ubicar servidores que contengan datos de titulares de tarjetas detrás de servidores proxy/firewalls o cachés de contenido,
  • Eliminación o filtrado de anuncios de enrutamiento para redes privadas que emplean direcciones registradas,
  • Uso interno del espacio de dirección RFC1918 en lugar de direcciones registradas.
El objetivo de disponer de firewalls de perímetro es proteger y controlar las conexiones entre los sistemas públicos y el entorno de datos de tarjeta, por lo que no deben existir conexiones directas (que no estén siendo filtradas por los firewalls) entre Internet y el entorno de datos de titulares de tarjeta) ya que anularían la eficacia de las defensas perimetrales.

La organización debe contar con una DMZ que gestione las conexiones entre Internet u otras redes no confiables y los servicios internos que deban ser públicamente accesibles, como los servidores web, los frontales de correo electrónico, etc.. Todas las conexiones que se inicien desde Internet u otras redes no confiables deben tener como destino direcciones IP pertenecientes a la DMZ, no debiéndose permitir en ningún caso el acceso directo a equipos de la red interna de la organización. Esto nos permitirá monitorizar y restringir el tráfico o el contenido previniendo el libre acceso entre redes no confiables y redes que sí lo son. Así mismo, todos los elementos que almacenen datos de tarjetas deberán estar siempre alojados en la red interna y segregados (mediante firewalls o routers con ACLs) de la DMZ, Internet o cualquier otra red no confiable.

Adicionalmente, deberá evitarse las conexiones directas, tanto en sentido entrante como saliente, entre internet y el entorno de datos de tarjeta. Por lo tanto, además de limitar este tipo de conexiones al mínimo indispensable por motivos de negocio, se deberá utilizar siempre algún dispositivo o sistema que actúe como proxy o proxy inverso y que esté alojado en la DMZ para habilitar este tipo de conexiones.

Por otro lado, el estándar obliga a que los firewalls perimetrales se configuren para bloquear cualquier paquete que llegue desde internet cuya IP de origen se haya “spoofeado” para que coincida con alguna dirección del rango interno de la red de la organización. Así mismo, los firewalls deben configurarse con la característica de “stateful inspection” habilitada para garantizar que tan sólo permitan “respuestas” a conexiones que efectivamente hubieran sido iniciadas anteriormente.

Por último, el requerimiento 1.3.8 intenta evitar que se facilite información de enrutamiento o de red a terceros que pueda ser utilizada por un potencial atacante para conseguir sus objetivos de una manera más sencilla. Por ello, el estándar propone la utilización de NAT, o de cualquier otra técnica que permita garantizar que no se revela el direccionamiento interno de los sistemas de nuestra organización en los paquetes de comunicaciones que se envían a terceros.

Y por fin llegamos al último subrequerimiento del requerimiento 1 del estándar:

1.4 Instale software de firewall personal en toda computadora móvil o de propiedad de los trabajadores con conectividad directa a Internet (por ejemplo, laptops que usan los trabajadores), mediante las cuales se accede a la red de la organización.

Este requerimiento exige que se instale firewall personal en los siguientes grupos de equipos:
  • En los equipos portátiles propiedad de la empresa que se vayan a conectar a la red corporativa.
  • En los equipos portátiles propiedad de los trabajadores que se utilicen para acceder a la red de la organización (por VPN o físicamente en la red local).
  • En los equipos de sobremesa propiedad de los trabajadores que se utilicen para acceder a la red de la organización (por ejemplo, vía VPN).
Además, el requerimiento obliga a que las reglas del firewall personal sean mantenidas por la organización y que se garantice que los trabajadores no pueden alterar dichas reglas ni deshabilitar el software instalado.

El objetivo de este requerimiento es evitar que equipos que se hayan conectado directamente a Internet sin contar con la protección de las defensas perimetrales de la organización puedan ser un foco de infección y anular la efectividad de dichas medidas en la empresa.

Como vemos, dependiendo de la organización y el escenario en el que nos movamos, puede ser harto complicado cumplir este requerimiento si no impedimos que los usuarios puedan acceder a la red de la organización con equipos de su propiedad. De todas formas, se nos presentan múltiples alternativas para abordar el cumplimiento de este requerimiento. Dos ejemplos de estrategias que podrían ser válidas para algunas organizaciones:

  • Prohibir la conexión a la red de la organización de ordenadores que sean propiedad de los trabajadores (ya se sabe, muerto el perro...).
  • En caso de que sea indispensable que los usuarios se conecten con ordenadores de su propiedad vía VPN, utilizar concentradores VPN que incorporen análisis de cumplimiento de políticas por parte de los clientes (para que verifiquen que el antivirus y el firewall personal estan habilitados y bien configurados antes de permitir el acceso a la red de la Organización.

Por otro lado, es importante recordar que se deben establecer reglas estrictas en el firewall personal, y que estas reglas deben ser mantenidas por la organización impidiendo en todo caso que los usuarios las puedan cambiar o deshabilitar, por lo que se hará necesario contar con un software que no pueda ser administrado por los usuarios que permita la configuración y gestión centralizada de las reglas a establecer.

Para finalizar esta segunda entrada sobre el requerimiento 1 de PCI DSS, me gustaría dar mi visión sobre el cumplimiento del mismo por parte de las organizaciones. Si bien es cierto que estos son requerimientos que, en mayor o menor medida ya se cumplen en la mayoría de organizaciones a poco que tengan una mínima madurez en seguridad de la información (pocas organizaciones me he encontrado que no dispongan de firewalls implementados en todas sus conexiones a Internet, aunque siempre hay alguna...) lo más frecuente es que la documentación (requerimiento 1.1) brille por su ausencia. También es muy frecuente que al analizar las reglas implementadas en un firewall aparezcan uno o varios “permit any” que impedirían la certificación PCI y cuya sustitución por reglas concretas suele dar más de un quebradero de cabeza al departamento de comunicaciones de la organización. Por último, como ya hemos comentado, el requerimiento 1.4 puede ser también un hueso duro de roer en función de la cultura existente en la organización en relación al uso de portátiles y/o ordenadores que sean propiedad de los trabajadores.

No hay comentarios: