OSSIM 17. PCI DDS

Después de varias entradas (1, 2, 3, 4, 5, 6, 7 , 8. 9 10, 11, 12 13, 14.,15, 16 )sobre el mundo SIEM y OSSIM, en esta ocasión vamos a hablar de una de esas normas relacionadas con la seguridad, y que sospecho que no todo el mundo es conocedor de ella.

PCI DDS: Payment Card Industry Data Security Standard. Norma en castellano.

A resumidas cuentas se trata de una norma internacional para aplicar a TODOS los agentes que intervienen en transacciones comerciales via internet mediante tarjetas de crédito/débito. Resalto TODOS ya que existe la falsa sensación entre la comunidad de que esta norma solo es aplicable si almacenas datos bancarios de clientes (e-commerce) y si usas la típica pasarela de pago de tu banco (tpv virtual) estás exento de aplicarla.

Nada mas lejos de la realidad. Lo que si es cierto es que existen varias niveles o modalidades a aplicar según la categoría de uso en la que te encuentres: no son las mismas medidas de seguridad a aplicar las que debe cumplir un banco, que una tienda online de barrio, pero en ambos casos existe normativa. Algo parecido a los niveles de seguridad de la española LOPD ( Ley Orgánica de protección de datos).

El objetivo de este artículo no es destripar la norma, sino darle un enfoque práctico.

Suelo leer varios blogs de seguridad "organizativa" o "none-tech" que dedican sendos posts a la "seguridad". Suelo ser de los que piensa que un buen responsable de seguridad o CISO debe tener tanto el aspecto técnico como el aspecto organizativo. No deberías ser consultor en seguridad si no sabes lanzar un NMAP, al igual que no deberías ser un CISO si no conces la legislación y normas que nos rodean. Prefiero el segundo caso dado mi pasión por la tecnología.

Tengo que decir sobre esta norma y su respectiva certificación algo que suelo decir para el resto de certificaciones, ya sean tipo ISO o tipo producto ( MCSE, VMWARE, CISCO, etc). Tener la certificación PCI-DDS no te proporciona seguridad, pero tener seguridad si que te proporciona poder optar a la certificación. Quiero decir con esto que lo importante no es la certificación en si, sino el trabajo que subyace para obtenerla. Si el trabajo ha sido pagar a una consultora, osea nulo, no tiene ningún sentido, mas el puro tramite de cumplir unas exigencias de cara a clientes/proveedores.

Entonces por qué habla de esta norma, cuando lo que realmente importa es la seguridad subyacente? Sencillo. Vamos a comentar los 12 aspectos principales que ocupan la PCI -DSS.( via wikipedia)

• Desarrollar y Mantener una Red Segura
  • Requisito 1: Instalar y mantener una configuración de cortafuegos para proteger los datos de los propietarios de tarjetas.
  • Requisito 2: No usar contraseñas del sistema y otros parámetros de seguridad predeterminados provistos por los proveedores.
• Proteger los Datos de los propietarios de tarjetas.
  • Requisito 3: Proteger los datos almacenados de los propietarios de tarjetas.
  • Requisito 4: Cifrar los datos de los propietarios de tarjetas e información confidencial transmitida a través de redes públicas abiertas.
• Mantener un Programa de Gestión de Vulnerabilidades
  • Requisito 5: Usar y actualizar regularmente un software antivirus.
  • Requisito 6: Desarrollar y mantener sistemas y aplicaciones seguras.
• Implementar Medidas sólidas de control de acceso
  • Requisito 7: Restringir el acceso a los datos tomando como base la necesidad del funcionario de conocer la información.
  • Requisito 8: Asignar una identificación única a cada persona que tenga acceso a un computador.
  • Requisito 9: Restringir el acceso físico a los datos de los propietarios de tarjetas.
• Monitorizar y probar regularmente las redes
  • Requisito 10: Rastrear y monitorizar todo el acceso a los recursos de la red y datos de los propietarios de tarjetas.
  • Requisito 11: Probar regularmente los sistemas y procesos de seguridad.
• Mantener una Política de Seguridad de la Información
  • Requisito 12: Mantener una política que contemple la seguridad de la información

Aunque suelen sonar a las típicas medidas de seguridad de la gente que "speak security" pero no las practican, nada mas lejos de la realidad te pregunto ¿ En tu organización, use tarjetas de crédito o no, implementa TODAS estas medidas?.

Este informe de Forbes con las 6 causas de fallo en las implementaciones de PCI te puede servir de ayuda para aclarar los conceptos mentales que empiezas a barajar :-)

Puede ser una buena ayuda para el departamento IT estas norma para impulsar la compra de material o servicios relacionados con la seguridad. Que tu jefe no piense que quieres un firewall para jugar o para llevarte una comisión.

Bueno, después de esta mini introducción vamos a ver que relación guarda con OSSIM.

La consola SIEM de OSSIM nos permite realizar varias de las acciones requeridas en la norma PCI DDS pero de momento, solo en versión 2.0. La actual norma versiona 3.0. Sospecho que la versión de pago AlienVault USM si adapta los requisitos a la norma 3.

También podríamos validar ciertos aspectos de la ISO 27001 pero le tengo manía. Por varias razones, pero principalmente por dos: por cobrar por descargar la norma y por la cantidad de empresas que venden seguridad cuando venden papeles.

Principalmente OSSIM lo que hace es comprobar el manejo de cada una de las áreas en base a los eventos que tiene. Por ejemplo, si tiene eventos de nuevo host descubierto porque tenemos Nagios activado y buscando cada cierto tiempo, entiende que cumplimos esa norma.
En el caso de que nos aparezca un campo sin comprobar, podemos vincularle un evento concreto para que sepa que cumplimos con esa parte de la norma gracias a esos eventos que añadimos.

Recuerda que esto es una guia orientativa del estado de tu cumplimiento PCI DDS, no es una herramienta completa que te "regale" la norma. Lo que si es cierto es que contamos con alugnos Reports preconfigurados válidos para apoyar la norma.

Podemos aglutinar las 12 grandes normas PCI en 6 respecto a OSSIM:

• Gestión de activos. Mediante las opciones de ASSETS e INVENTORY de OSSIM podemos descubrir, identificar y monitorizar nuestros activos, algo básico en todo esto. Debemos saber que tenemos que asegurar, pero de manera dinámica, no basta con un inventario "estático" de hace un año, sin actualizar.
• Análisis de vulnerabilidades. Mediante la integración de Openvas en OSSIM podemos programar auditorias de vulnarabilidades tal y como indica la norma. Hago ENFASIS en que no es lo mismo un Vuln Scan. que un Pen Test que luego me critcaís por ahí xD. Lo vimos aquí y aquí.
• Detección de amenazas. Mediante el uso de sistemas HIDS/IDS y la monitorización de ficheros podemos realizar este punto perfectamente con OSSIM, como hemos visto en los artículos de Snort y OSSEC File Integrity.
• Monitorización. La base de OSSIM es la monitorización de logs, mediante plugins OSSIM o mediante OSSEC. PCI DDS tmbien hace hincapié en la monitorización de servicios/aplicaciones y flujo de red.
• Inteligencia. El motor de inteligencia OSSIM proporciona correlación de eventos de distintas fuentes para proporcionar algo más que visionado de logs, inteligencia. El típico ejemplo: si detectas intentos de login a un servidor SSH ( log ssh) y se produce una ejecución de comandos elevada desde la misma ip ( log kernel) y se abre un puerto ( log de servicios ) vistos en conjunto es una alarma, visto por separado son simples logs de actividad.
• Revisión. La consola de OSSIM nos permite revisar todos los puntos anteriores e implementar medidas para la solución.

No todo es oro lo que reduce, y debemos ser conocedores de la norma en profundidad para poder realizar o aprovechar sus beneficios.

Un ejemplo claro de la norma: 

10.7 Conserve el historial de pistas de auditorías durante, al menos, un año,con un mínimo de disponibilidad para análisis de tres meses (por ejemplo, en línea, archivados o recuperables para la realización de copias de seguridad).

La versión gratuita de AlienVault, OSSIM solo permite guardar XXX registros, por lo que debemos jugar con una estrategia de consolidación de logs mediante el reenvio de información hacia un syslog pasivo. En otro post os explicaré como podéis realizarlo mediante Tablas Sql y mediante ejecución de scripts.

Un informe cualquiera de fugas de información, como pueda ser este de Verizon indica que:

1. 79% de las víctimas fue por razones oportunistas. Esto quiere decir que no es lo mismo hacer un google hack y buscar servidores "facilones" que buscar la manera de entrar en un sistema concreto. Esta parte tiene mucho de concienciación.
2. 96% de los ataques no fueron de alto valor técnico. Es decir, buscar una sql inyection en un portal para sacar la información no tiene mucho componente técnico, por lo que lo puede llevar a cabo mucha más gente. Ese 4% es el que preocupa :-).
3. 94% de los datos provenía de servidores, y no de malas prácticas por parte de usuarios ( client side).
4. 85% de los incidentes fueron detectados pasadas semanas, es decir, cuando el daño ya está hecho y tenemos menos medidas para mitigarlo.
5. 92% de los incidentes fue descubierto por terceras partes, es decir cuando aparecen en un foro, en un defacement o un servicio de monitorización externo. Este punto hace evidente la necesidad de saber el estado de tus sistemas, y no confiar en el appliance de 1000$ o 10000$ sino en una estrategia global que contemple todos los vectores de ataque.
6. 97% de los incidentes podrían ser evitados con medidas sencillas. Tirón de orejas para el CISO !!!
7. 96% de las víctimas de incidentes NO tenían una política real de cumplimiento PCI. Insisto en el comienzo, tenerla no garantiza nada, pero este dato es muy revelador.

Espero que os hayan gustado estas reflexiones sobre PCI y alguno de los detalles comentados en OSSIM. Gracias por leerme !!!

Quieres ver un video?

Recuerda que puedes buscar entre mis libros de hacking en español en en recopilatorio de libros sobre hacking