Algunos "Quickwins" en seguridad de la información

En algunas organizaciones existe una fe ciega en que el mejor camino para mejorar la seguridad es gastar más y más dinero en hierro y licencias. Más firewalls, más IDS y el WAF más caro. Sin embargo, en este post me gustaría repasar tres actividades básicas para mejorar la seguridad de una organización, que no necesariamente requieren comprar ningún hardware o software adicional.

La primera de estas actividades es el bastionado de los sistemas. Bastionar o asegurar correctamente un sistema no es una tarea complicada. Existen multitud de guías específicas sobre cómo bastionar sistemas concretos, pero incluso realizando un bastionado básico se puede incrementar en gran medida la seguridad de una infraestructura sin tener que invertir un esfuerzo desmesurado en ello. Los pasos básicos a seguir para bastionar un sistema son:

• Elimina o al menos deshabilita los servicios de red y los programas innecesarios, dejando únicamente habilitados aquellos que son necesarios para que el sistema desempeñe su labor. De esta manera se reduce drásticamente la superficie de exposición del sistema.
• Revisa los usuarios existentes en el sistema, cambiando contraseñas por defecto y minimizando los permisos de cada usuario de manera que tengan los mínimos necesarios para desarrollar sus actividades.
• Documenta los servicios de red necesarios y los puertos usados por cada uno de estos servicios. Esta documentación será de mucha utilidad para diseñar las reglas a implementar en los firewalls de red.
• Mantén el sistema actualizado al último nivel de parches de seguridad publicados por el fabricante. Esta actividad es básica para prevenir que un atacante utilice vulnerabilidades conocidas para comprometer la seguridad del sistema.
• Instala y mantén un firewall en el servidor (puede ser el propio firewall de Windows o un IPtables en el caso de linux) permitiendo únicamente el tráfico entrante y saliente que sea estrictamente necesario. Filtrar el tráfico entrante permite garantizar que aunque algún servicio no necesario se haya dejado habilitado por error, éste no será accesible desde la red. Filtrar el tráfico saliente puede permitir mitigar el impacto causado por una infección de malware que intente abrir conexiones salientes, y prevenir la fuga de datos usando conexiones de red a servicios que el servidor realmente no requiere.

Otra actividad básica a desarrollar es definir, implementar y mantener un programa de gestión de vulnerabilidades adecuado para la organización.

Si queremos gestionar las vulnerabilidades de nuestros sistemas, debemos seguir los siguientes pasos básicos para su correcta gestión: detectarlas, clasificarlas, priorizarlas, asignarlas, resolverlas y verificar su correcta resolución: 

1. Detectar: Hay múltiples fuentes o vías que debemos usar para detectar las vulnerabilidades existentes en nuestros sistemas. Las más comunes serán los avisos de alerta temprana de CERTs o de los propios fabricantes, los resultados de los escaneos de vulnerabilidades periódicos que se deberían realizar sobre la infraestructura y las aplicaciones y los resultados de las pruebas de penetración que se realicen.
2. Clasificar: Una vez detectada una vulnerabilidad, el siguiente paso a realizar debería ser clasificarla según el riesgo que suponga para nuestra organización. Para ello, se deberían considerar factores como el impacto que podría suponer, y la facilidad de explotación. Dado que la resolución de vulnerabilidades es un proceso que puede llevar días, semanas o incluso meses, aquellas vulnerabilidades que sean consideradas más críticas deberían ir acompañadas de un plan de acciones compensatorias para mitigar el riesgo que suponen hasta que sean definitivamente solventadas.
3. Priorizar: Una vez clasificadas según su riesgo, deberán priorizarse. Estos es, definir un tiempo límite en el que cada vulnerabilidad debería estar resuelta. El estándar de seguridad en datos de tarjetas de pago PCI DSS propone un mes de tiempo límite para las vulnerabilidades más críticas y tres meses de tiempo límite para el resto. En cualquier caso, tanto los niveles de clasificación como los tiempos de resolución deberían adaptarse a la realidad de cada organización.
4. Asignar: El siguiente paso es asignarlas. Es decir, determinar de quien es la responsabilidad de resolver cada una de las vulnerabilidades dentro del plazo correspondiente.
5. Resolver: El responsable de resolver cada vulnerabilidad deberá encontrar la solución a la misma, seguir el proceso de la organización para la gestión de cambios, es decir, probarla adecuadamente para descartar cualquier impacto negativo derivado de ésta y proceder a su resolución.
6. Verificar: Por último, se debe verificar que la solución resuelva la vulnerabilidad de manera eficaz.

Por último, quisiera hablar de la concienciación en seguridad de la información dirigida a los empleados y proveedores de la organización.

Más de una vez he oído a profesionales de seguridad argumentando que las acciones de concienciación no son efectivas y que por mucha concienciación que se realice, el factor humano seguirá siendo el principal riesgo de cualquier organización. Mi opinión al respecto es que la concienciación sí es efectiva e indispensable,  aunque no por ello suficiente. Dicho de otro modo, es cierto que concienciar al personal no elimina los riesgos de seguridad que provienen de errores humanos pero sin duda los mitiga y en todo caso evita que los usuarios puedan escudarse tras el desconocimiento al perpetrar ciertos tipos de acciones que comprometan la seguridad de los activos de información de la organización.

Por supuesto, existen más acciones que se pueden llevar a cabo sin una gran inversión económica para aumentar el nivel de seguridad de las organizaciones, como por ejemplo segmentar correctamente la red, establecer procesos de desarrollo seguro, de gestión de cambios, de respuesta ante incidentes, etc. Sin embargo, los tres propuestos considero que son una excelente base por la que empezar a mejorar la seguridad de nuestra organización.

Auditar la seguridad de un sistema Linux

El propósito de este post es detallar qué tipo de revisiones se deben realizar en un equipo linux para determinar si cumple con los requisitos de seguridad del estándar PCI DSS. Para ello, siempre que sea posible, vamos a detallar los comandos a utilizar para obtener la información necesaria en cada caso.

No obstante, aunque el propósito principal sea auditar el cumplimiento de PCI DSS, las revisiones propuestas pueden utilizarse como punto de partida para cualquier revisión de seguridad de un equipo linux que se quiera realizar.

Todos los comandos indicados en este post han sido probados en un equipo Ubuntu 12.04, por lo que es posible que algunos de ellos deban ser modificados para que funcionen correctamente en otras distribuciones de linux. Podemos utilizar el comando lsb_release -a para conocer la versión exacta del sistema que estamos revisando, o bien obtenerla del archivo /etc/os-release.

 

Requisito 1: Install and maintain a firewall configuration to protect cardholder data

El comando

Iptables -L -v

mostrará las reglas de firewall utilizadas en el equipo. En caso de tratarse de un equipo portátil, se debería revisar el cumplimiento del req 1.4 de PCI DSS que exige que se instale y se mantenga un firewall personal en este tipo de equipos. En todo caso, es aconsejable revisar las reglas de fw definidas en el equipo ya que en determinadas circunstancias pueden servir como control compensatorio ante la ausencia de cumplimiento de otros requerimientos del estándar.

 

Requisito 2: Do not use vendor-supplied defaults for system passwords and other security parameters

Para verificar algunos aspectos del cumplimiento de este requisito, podremos utilizar los siguientes comandos:

Dpkg -l

Nos permitirá listar todos los paquetes instalados con objeto de detectar paquetes innecesarios que debieran haber sido desinstalados.

route -n

Nos permitirá listar todas las rutas definidas en el sistema. Adicionalmente, el análisis de los siguientes ficheros nos permitirá determinar si se ha modificado la resolución de nombres del sistema o si se ha personalizado el encaminamiento:

/etc/resolv.conf

/etc/hosts

/etc/nsswitch.conf

Adicionalmente, se debería revisar el archivo

/etc/passwd

para detectar la existencia de cuentas de usuario innecesarias o por defecto que deberían haber sido ser borradas o deshabilitadas.

Así mismo, se debería revisar la guía de hardening documentada por la organización para este tipo de sistemas e identificar cualquier comprobación adicional que deba ser realizada para garantizar que está siendo correctamente aplicada.

También es importante identificar cual es la función primaria de este servidor, y aprovechar la revisión para identificar cualquier paquete o servicio que no tenga sentido para dicha función primaria. Así, por ejemplo, si la función primaria del servidor es la de actuar como servidor web, tendrá sentido que localicemos paquetes de apache instalados, pero no lo tendría que encontráramos paquetes de Oracle o Nessus. La existencia de dichos paquetes nos podría hacer sospechar que el servidor se está utilizando para más de una función primaria y por lo tanto se está incumpliendo el requisito 2.2.1.

Podemos utilizar los siguientes comandos para listar todos los procesos en ejecución, así como los servicios escuchando en los puertos UDP y TCP con objeto de verificar que no hay procesos o servicios innecesarios ejecutándose y que todos los que se están ejecutando están adecuadamente documentados y justificados:

ps -edf

Lsof -i UDP -n -P

Lsof -i TCP -n -P

También se debería revisar el contenido de la carpeta

/var/spool/cron/crontabs

para detectar la existencia de tareas programadas.

Adicionalmente, deberemos revisar este listado de procesos y servicios para identificar protocolos inseguros (FTP, Telnet, etc..) y verificar que se hayan documentado e implementado medidas de seguridad adicionales para estos protocolos.

Finalmente, para terminar con la revisión de este requisito, revisaremos el siguiente fichero para revisar la configuración de SSH existente en el servidor:

cat /etc/ssh/sshd_config

En este archivo podemos verificar en qué puerto se ejecuta SSH, qué versiones se permiten (únicamente debería estar permitida la v2, ya que la v1 es vulnerable) y qué protocolo de cifrado se está utilizando para garantizar que se utiliza un protocolo suficientemente robusto. Adicionalmente, se debería revisar que el valor de AllowTcpForwarding sea “no”, al no ser que se justifique la necesidad de utilizar este servidor como salto para administrar otros equipos.

 

Requisito 6: Develop and maintain secure systems and applications

Para revisar este requisito, tenemos que validar que no existen versiones inseguras de software en el sistema. Con este propósito en mente, podemos utilizar los siguientes comandos:

Uname -a

Este comando nos permitirá conocer la versión del kernel y verificar que no existan vulnerabilidades conocidas para esta versión, es decir, que el kernel esté correctamente parchedo.

Por otro lado, con:

Dpkg -l

listaremos todos los paquetes instalados en el sistema y sus respectivas versiones, por lo que podremos realizar la misma operación buscando versiones para las que existan vulnerabilidades conocidas y que por lo tanto debieran estar parcheadas o actualizadas para cumplir este requisito de PCI DSS.

Finalmente, se deberá analizar el fichero

/etc/passwd

para verificar que no existen cuentas de usuario correspondientes a personal de desarrollo ni cuentas de pruebas o testing que no hayan sido borradas en la puesta en producción del sistema.

 

Requisito 7: Restrict access to cardholder data by business need to know

Con el propósito de verificar el cumplimiento del requisito 7 de PCI DSS, se pueden realizar las siguientes revisiones:

/etc/sudoers

/etc/pam.d/sudo

/etc/pam.d/su

En estos ficheros podremos revisar qué usuarios tienen permiso para aumentar sus privilegios a root y en qué condiciones pueden hacerlo. Se deberá comprobar que todos los casos estén debidamente documentados y justificados.

Se deberá revisar que ni el fichero

/etc/shadow

ni sus posibles backups puedan ser leídos por los usuarios.

Por otro lado, se deberá comprobar que los ficheros setuid no puedan ser editados por usuarios no autorizados para aumentar de esta manera sus privilegios en el sistema. Podemos utilizar el siguiente comando para dicha revisión:

find / -perm -4000 -ls 2> /dev/null

Los siguientes comandos nos permitirá listar los ficheros que pueden ser leídos por cualquier usuario y que no están ubicados en /proc:

find / -type f -perm -006 2>/dev/null | grep -v /proc

find / -type f -perm -002 2>/dev/null | grep -v /proc

Se deberán analizar los ficheros obtenidos para ver si existe una justificación para los permisos que tienen establecidos.

Por otro lado, se deberá revisar el fichero

/etc/passwd

para verificar qué shell tiene asignada cada usuario y qué usuarios no tiene asignada ninguna shell.

Así mismo, se deberá revisar el fichero

/etc/security/access.conf

para comprobar si existen restricciones en el login de usuarios. Este fichero permite configurar limitaciones al tipo de acceso que puedan tener determinadas cuentas, por ejemplo, impidiendo el acceso remoto a la cuenta root, o el acceso mediante consola a determinadas cuentas de usuario o aplicación.

Finalmente, se deberá revisar el fichero

/etc/security/capability.conf

para confirmar que existe la linea “none *” no comentada (sin #), y que no se han asignado capacidades extras a usuarios sin que exista un motivo justificado para ello.

 

Requisito 8: Identify and authenticate access to system components

Para verificar la mayoría de los aspectos incluidos en el requisito 8 de PCI DSS será necesario revisar el archivo

/etc/pam.d/common-password

En este archivo podremos revisar qué algoritmo se está usando para el hash con el que se guardan los passwords en /etc/shadow y verificar si se está usando pam_cracklib.so para configurar una política de contraseñas suficiente para dar cumplimiento al requisito 8.2.1 de PCI DSS:

 

Requisito 10: Track and monitor all access to network resources and cardholder data

Para analizar el cumplimiento de este requisito de PCI DSS debemos revisar dos aspectos; la configuración de tiempo y la configuración de syslog.

Revisando el siguiente archivo podremos conocer la zona de tiempo UTC que está siendo utilizada por el sistema:

/etc/timezone

Mediante el siguiente comando, podremos verificar la configuración de servidores NTP que está siendo utilizada para la sincronización horaria del sistema:

Ntpdate

Por otro lado, el siguiente comando nos permitirá saber si el proceso de syslog está habilitado:

ps -edf | grep syslog

Revisando el fichero

/etc/rsyslog.conf

se puede verificar si está habilitado el servicio syslog para recibir eventos de otros sistemas o dispositivos y qué permisos van a tener los ficheros de logs generados.

Finalmente, mediante la revisión del fichero

/etc/rsyslog.d/50-default.conf (o su equivalente indicado al principio del fichero /etc/rsyslog.conf)

podremos identificar qué eventos se están generando y en qué rutas se están guardando estos ficheros de logs (o a qué servidores se están enviando). De esta manera, podremos verificar si se está cumpliendo el requisito de centralizar todos los eventos de seguridad generados por los sistemas incluidos en el alcance de PCI DSS.

 

Requisito 11: Regularly test security systems and processes

Revisar qué tipo de software de monitorización de integridad de ficheros tiene instalado el sistema. En función del tipo de mecanismo que se esté utilizando, se deberán realizar las revisiones pertinentes para garantizar que se cumple el requisito 11.5 de PCI DSS, es decir, que al menos semanalmente se comprueban la modificaciones realizadas en ficheros considerados críticos como ejecutables del sistema, ejecutables de aplicaciones, ficheros de parámetros y configuraciones, histórico de logs u otros archivos que no deban cambiar frecuentemente y se consideren críticos para la seguridad del sistema o de los datos.

Espero que la entrada os guste y os sea de utilidad y, por supuesto, si alguien detecta algún error o tiene alguna sugerencia de mejora de cara a realizar este tipo de auditorías, se agradecerá cualquier aportación al respecto.

¿Aún no me sigues en twitter?: @omarbenjumea
http://about.me/omarbenjumea

Plan de Respuesta ante Incidentes de Seguridad & PCI DSS

No hay organización que esté a salvo de sufrir un incidente de seguridad.  Se puede tardar más o menos en padecerlo y en resolverlo, ser más o menos grave, o incluso puedes no enterarte de que estás teniendo un incidente de seguridad (no, tranquilos, no voy a hablar de APTs), pero en algún momento tu organización necesitará reaccionar ante un incidente.

Por ello, toda organización debería contar con un plan de respuesta ante incidentes de seguridad coherente con el impacto potencial que un incidente de seguridad pueda llegar a suponer para su negocio. La ausencia de un plan de respuesta ante incidentes de seguridad puede incrementar considerablemente el tiempo de reacción ante un incidente e incluso puede provocar que la respuesta no sea la adecuada y acabar agravando el impacto del mismo.

El apartado 12.10 de PCI DSS v3 requiere a las organizaciones afectadas por el estándar que implementen un plan de respuesta de este tipo y que estén preparadas para responder de inmediato ante cualquier compromiso en sus sistemas. En este sentido, lo que exije el estándar es que el plan de respuesta incluya en su alcance todos los elementos claves que son necesarios para que la organización responda de manera efectiva en caso de que el compromiso pueda afectar a los datos de titulares de tarjeta. Sin embargo, puestos a desarrollar un plan de respuesta, pienso que es ridículo ceñirse únicamente al ámbito de PCI DSS, ya que con poco más esfuerzo podemos contar con un Plan de Respuesta que alcance a toda la organización y que nos permitirá responder de una manera eficaz y eficiente en caso de que se produzca un incidente.

Veamos pues las pautas a seguir para desarrollar un Plan que nos permita cumplir con el requisito 12.10 de PCI DSS pero que a su vez nos prepare para actuar ante incidentes que afecten a otros ámbitos de nuestra organización.

Preparación

En la fase de preparación deberemos llevar a cabo las siguientes actividades principales:

1- Tener claro el alcance de nuestro Plan. No es lo mismo preparar un Plan ante Incidentes de Seguridad que acotar el alcance únicamente a incidentes de Seguridad de la Información, de seguridad laboral, de seguridad patrimonial, etc... Para cumplir con PCI DSS, el alcance del Plan debe incluir como mínimo, todos los sistemas críticos dentro del ámbito de procesado, almacenaje y transferencia de datos de titulares de tarjeta.

2- Se deben definir y documentar los roles y las responsabilidades de todos los participantes en el Plan de Respuesta ante Incidentes.

3- Aunque numerosas metodologías de gestión de incidentes de seguridad proponen la realización de un análisis de riesgos, incluido el recien publicado marco de ciberseguridad del NIST, yo soy partidario de realizar únicamente un BIA (Business Impact Analisys) que nos permita tener claro qué impacto puede tener un inciente en diferentes ámbitos (legal, financerio, operativo, daños humanos, reputación). Hay diferentes metodologías o aproximaciones para realizar un BIA pero mi recomendación, sobretodo en una primera implantación del Plan, es optar por una que sea suficientemente simple como para tener un BIA realista en poco espacio de tiempo. Es importante señalar que este BIA no debe limitarse a analizar incidentes que dañen la disponibilidad de la información, puesto que no se trata de preparar el Plan de Continuidad de Negocio, si no que se tiene que tener en cuenta también los impactos en cuanto a pérdida de confidencialidad e integridad de la información, así como otros tipos de incidentes no relacionados con la seguridad de la información en caso de que el alcance del Plan sea tal.

4- Definir que escenarios de incidentes se pueden producir partiendo del análisis realizado en el BIA. Es decir, documentar todos aquellos sucesos que puedan causar los principales impactos identificados en el punto anterior. Es recomendable en una primera redacción del Plan no ser excesivamente ambicioso y agrupar e unificar la respuesta ante incidentes de manera que el volumen de escenarios sea manejable. No nos servirá de nada documentar 500 posibles casuísticas si luego vamos a tardar 5 años en redactar los procedimientos de respuesta para cada una de ellas.

5- Documentar los mecanismos establecidos para poder detectar la materialización de los escenarios definidos en la fase anterior. En esta fase es muy probable que se identifiquen deficiencias o imposibilidades en la detección de algunos de los escenarios. En aquellos casos en los que sea viable, se debe preparar un plan de mejora destinado a implantar controles o mejoras que permitan la detección en un tiempo tolerable de dichos escenarios. Al considerar los elementos que pueden disparar el procedimiento de gestión de incidentes, PCI DSS obliga a que como mínimo se consideren los sistemas de monitorización de la organización, como son los IDS/IPS, los firewalls o los sistemas de monitorización de la integridad de los ficheros (FIM).

6- Documentar los criterios de clasificación de los incidentes. Se debe definir una taxonomía y los criterios para clasificar un potencial incidente en su correspondiente categoría. Nuevamente, mi recomendación es que prime la simplicidad no definiendo más de 10 categorías diferentes de incidentes para facilitar su clasificación.

7- Documentar los procedimientos de actuación en caso de materialización de cada tipo de incidente. Los procedimientos deben incluir el detalle de acciones a realizar para:
* Contener el incidente.
* Solventar el incidente.
* Recuperar la operativa normal.
Entre estos procedimientos, se deberán incluir o referenciar los procedimientos del Plan de Continuidad de Negocio que deban ser seguidos en caso de que el incidente afecte a la continuidad del mismo.
Adicionalmente, para cumplir con PCI DSS, se deberán incluir o referenciar los procedimientos de copias de respaldo de los datos y cualquier aspecto o requisito legal a considerar en caso de incidente.

8- Documentar las estrategias y procedimientos de comunicación ante un incidente de seguridad. Es decir, qué se debe decir, a quién se debe decir y cómo se debe decir en cada caso, o en todo caso, definir claramente quien es el responsable de tomar estas decisiones en caso de incidente. El daño a la imagen o la reputación de la compañía puede variar enormemente en función de qué se comunique y cómo se comunique a raíz de un incidente de Seguridad. Para cumplir con PCI DSS estas estrategias deberán incluir, como mínimo, el procedimiento a seguir para comunicar cualquier compromiso de datos de tarjeta a las marcas de tarjeta de pago.

9- El Plan debe ser comunicado y distribuido entre todos los afectados y se debe garantizar su disponibilidad durante un potencial incidente. Es decir, si uno de nuestros escenarios posibles es que por motivo de un DoS se nos caigan nuestros sistemas corporativos, no guardemos únicamente en ellos nuestro Plan de Respuesta ante Incidentes, puesto que no podremos recuperarlo cuando lo necesitemos. Así mismo, si uno de los escenarios contemplados es el no poder acceder a la oficina, tampoco nos serviría de nada tenerlo impreso en nuestro escritorio.

10- Se deben definir y establecer las vías necesarias para que cualquiera pueda notificar a los responsables la ocurrencia de un posible incidente. Estas vías deben ser sencillas, rápidas y contar con diversas alternativas por si una de ellas fallara.

11- El equipo de respuesta ante incidentes debe estar convenientemente entrenado y con una disponibilidad de 24x7 para actuar en caso de que se materialice un incidente para evitar que el retraso en su resolución pueda agravar su impacto y consecuencias. Por otro lado, la correcta procedimentación de la actuación y formación del equipo son vitales para impedir que las actividades realizadas para solventar el incidente puedan degradar o corromper las evidencias necesarias para la adecuada investigación forense del incidente.

12- Se debe planificar un plan de pruebas que permita tener un alto grado de seguridad de que el Plan propuesto funciona correctamente en caso de incidente. Las pruebas, que deberán realizarse como mínimo anualmente, son críticas para garantizar que los procedimientos definidos son realmente eficaces y que todo el personal afectado tiene conocimiento necesario de los mismos. En este sentido, será necesario probar únicamente aquellas tipologías de incidentes que no se hayan dado realmente durante el año, no siendo necesario probar los procedimientos que se hayan usado realmente durante el año, al no ser que se hayan sido mejorados o modificados.

Durante el incidente.

Durante el incidente se deben tener en cuenta los siguientes aspectos:

1- Se deben seguir los procedimientos definidos en el Plan en cada caso.
2- Se debe mantener una bitácora detallada con todos los sucesos y actuaciones llevados a cabo durante el incidente.
3- Se debe priorizar la contención del incidente.
4- Una vez contenido, se debe proceder a su resolución.
5- Finalmente, una vez resuelto, se debe proceder a la recuperación de los sistemas afectados.

Mejora continua:

PCI DSS, y cualquier metodología de gestión de incidentes de seguridad que se precie, exige que se incluya un apartado específico de mejora continua en el plan de respuesta ante incidentes de manera que se analice la actuación y resolución ante cada incidente de seguridad para detectar áreas de mejora en los procesos de detección o respuesta ante los incidentes.

Para ello, se deben analizar los outputs, entendiendo qué ha pasado y por qué ha pasado, para cada uno de los incidentes sufridos así como de las pruebas realizadas y analizar qué mejoras se pueden implementar en el Plan en diversos ámbitos:

* Mejoras en la prevención de los incidentes.
* Mejoras en la detección de los incidentes.
* Mejoras en la contención y resolución de los incidentes.
* Mejoras en la recuperación de los equipos o del negocio.
* Mejoras en el plan de pruebas.
* Mejoras en los escenarios de incidentes definidos.
* Mejoras en la formación del personal.

Por último, también es importante tener en cuenta el plan dentro de la gestión del cambio de la organización, de manera que se actualice el Plan de Respuesta ante Incidentes siempre que algún cambio en los sistemas o la organización deje obsoleto algunos de los procedimientos definidos.



En definitiva, se trata de contar con un Plan documentado, distribuido, probado y conocido que permita actuar de la mejor manera y en el menor tiempo posible ante un incidente de seguridad con el objetivo de minimizar el impacto en diversos ámbitos que dichos incidentes pueden suponer para nuestras organizaciones.

Metodología de Test de Intrusión (Requisito 11.3 de PCI DSS)

 Tal y como comentaba en la anterior entrada, uno de los nuevos requisitos de la PCI DSS v3 consiste en disponer de un procedimiento que describa la metodología a seguir en la realización de los test de intrusión internos y externos. El presente post tiene como objetivo ayudaros a cumplir con dicho requisito, ya que he desarrollado un procedimiento de ejemplo que podrá ser fácilmente adaptado a la casuística concreta de vuestra Organización.

Espero que os sea de utilidad, y cualquier comentario o propuesta de mejora será bienvenida.

1.Introducción

1.1.Objetivos

El propósito del presente documento es establecer una metodología para la planificación, ejecución y revisión de las pruebas de intrusión a realizar con carácter anual en la Organización. Esta metodología, basada en el estándar NIST SP 800-115 permitirá seguir un proceso consistente y repetible en cada una de estas pruebas, garantizando la calidad y fiabilidad de las mismas.

La responsabilidad de llevar a cabo estas pruebas de intrusión anuales será del departamento XXXX pudiendo ser ejecutadas tanto por personal interno como por personal externo siempre y cuando sea ejecutado por profesionales especialistas en la realización de pruebas de intrusión que cuenten con la experiencia y los conocimientos necesarios.

Finalmente, cabe señalar que el propósito de las pruebas a realizar será identificar las vulnerabilidades que pudieran ser explotadas por un atacante para vulnerar la seguridad de los sistemas de la Organización comprometiendo de esta manera la confidencialidad, integridad o disponibilidad de la información almacenada, procesada o transmitida por estos.

Cabe señalar que este procedimiento incluye todos los requisitos mínimos establecidos por el requisito 11.3 del estándar PCI DSS.

1.2.Alcance

El alcance de las pruebas de intrusión incluye los siguientes elementos:

• Pruebas de intrusión externas, es decir, analizando las vulnerabilidades que podrían ser explotables por un atacante ubicado en Internet:
  • Pruebas en formato de caja negra: sin usuarios ni información previa.
  • Pruebas en formato de caja gris: sin usuarios, pero contando con el detalle de las aplicaciones y de la infraestructura perimetral de la organización.
  • Pruebas en formato de caja blanca: contando con los usuarios de aplicación o de sistemas suficientes como para acceder a las áreas autenticables accesibles desde internet que quieran ser probadas.
• Prueba de intrusión internas, es decir, analizando las vulnerabilidades que podrían ser explotables por un atacante con acceso a la red interna de la Organización:
  • Pruebas en formato de caja negra: sin usuarios ni información previa.
  • Pruebas en formato de caja gris: sin usuarios, pero contando con el diagrama de red de la organización. Adicionalmente, si existen diversos segmentos de red utilizados por usuarios con diferente nivel de privilegios (por ejemplo, usuarios normales y usuarios administradores) se permitirá a los auditores realizar las pruebas desde diversos segmentos de red.
  • Pruebas en formato de caja blanca: contando con usuarios de dominio, usuarios de sistemas o usuarios de aplicación. El método a seguir es asignar los mismos perfiles y privilegios de acceso a los auditores que los que se asignan a los usuarios para los que queremos verificar el nivel de seguridad de los sistemas. Por ejemplo, si lo que queremos ver es qué vulnerabilidades puede aprovechar un proveedor para comprometer la seguridad de nuestra organización, se les debería asignar a los auditores usuarios con el mismo perfil y privilegios que se asignarían a dicho proveedor.
• Pruebas de explotabilidad. Tanto para las vulnerabilidades identificadas en las pruebas internas como para las identificadas en las pruebas de intrusión externas, se deberá verificar si realmente son explotables siempre y cuando se den las siguientes circunstancias:
  • Se determine que el riesgo de ejecutar el exploit es asumible. Hay que tener en cuenta que la ejecución de un exploit siempre conlleva un cierto nivel de riesgo de provocar una denegación de servicio en el sistema o aplicación objetivo.
  • Exista un exploit público disponible para la vulnerabilidad.
  • Pueda generarse un exploit a medida en un tiempo y con un esfuerzo razonable dentro de la planificación de las pruebas a realizar.
• Documentación de las pruebas realizadas, los hallazgos obtenidos, sus respectivas evidencias, las conclusiones alcanzadas y las recomendaciones emitidas para solventar las vulnerabilidades identificadas durante las pruebas.
• Verificación técnica y captura de evidencia tras la resolución de cada una de las vulnerabilidades reportadas durante las pruebas.

1.3.Asunciones y limitaciones

En este apartado debería identificarse (en caso de que las hubiera) cualquier asunción o limitación que sea aplicable, tanto para la organización como para el equipo que realizará las pruebas.

1.4.Riesgos

En este apartado deberían listarse los riesgos inherentes a la realización de las pruebas de intrusión en los sistemas de información de la organización. Adicionalmente, debería indicarse para cada uno de ellos las medidas de mitigación que serán adoptadas. Algunos ejemplos podrían ser:

Riesgo: denegación de servicio en elementos de red o servidores debidos a la ejecución de escaneos de red.

Contramedida1: Los escaneos de red se realizarán de manera controlada, notificando a los responsables el inicio y finalización de los mismos para permitir su monitorización durante las pruebas. Ante cualquier indicio de problema se abortará el escaneo en curso.

Contramedida2: Se configurarán las herramientas de escaneo de tal manera que el volumen de paquetes enviados o sesiones establecidas por minuto no supongan un problema para los elementos de red de la Organización. En este sentido, será necesario realizar los primeros escaneos de manera muy controlada y utilizando configuraciones mínimas que podrán ir ampliándose en la medida que se compruebe que los volúmenes establecidos no supongan ningún perjuicio para los dispositivos de red o servidores de la Organización.

Riesgo: En el transcurso de las pruebas, si los auditores tienen éxito en las pruebas podrían tener acceso a información confidencial de la Organización.

Contramedida1: Tanto el proveedor a título de persona jurídica, como los profesionales que participen en las pruebas a título individual, deberán firmar acuerdos de confidencialidad en los que se detallen las responsabilidades asumidas en caso de incumplimiento de los mismos.

Contramedida2: Los documentos y evidencias generados por el equipo de auditoría tendrán la clasificación de información confidencial y sólo deberán ser accedido por el personal autorizado en base al principio de necesidad de conocer.

Contramedida3: El equipo de auditoría aplicará todas las medidas necesarias para evitar que la confidencialidad de la información de la organización pueda verse comprometida por culpa de las pruebas realizadas. Estas medidas incluirán el cifrado de los informes y evidencias y el enmascaramiento de todos aquellos datos especialmente sensibles que se hayan incluido en los informes o evidencias generados.

2.Logística

2.1.Personal

A continuación se listará el personal clave que participará en el proyecto por parte de la Organización:

• Responsable técnico del proyecto: XXXXX
• Director de Seguridad: XXXXXX
• Responsable de Sistemas: XXXXX
• Responsable de Comunicaciones: XXXXX
• Responsable de la aplicación YYYY.com: XXXXX

En el Anexo I “Fichas de contacto” se listarán los teléfonos y mails de contacto de todo el personal involucrado en las pruebas. tanto por parte del proveedor como por parte de la Organización. Será de especial relevancia identificar correctamente los métodos y las personas de contacto en caso de incidencia grave, tanto por parte del proveedor como por parte de la Organización.

2.2.Calendario

Las pruebas de intrusión deberán contar con un cronograma en el que se detallen las principales tareas y los principales hitos a alcanzar durante las pruebas. En este sentido, deberán planificarse como mínimo las siguientes fechas:

• Actividades previas al proyecto
• Reunión de Inicio del proyecto
• Inicio y fin de pruebas externas
• Inicio y fin de pruebas internas
• Reuniones de seguimiento del proyecto
• Entrega de informes
• Presentación de resultados
• Reunión de finalización del proyecto

2.3.Lugar de las pruebas

Las pruebas de intrusión externas se realizarán de manera remota desde las instalaciones del proveedor.

Las pruebas de intrusión internas se realizarán en la oficina XXXX de la Organización. Se deberá buscar una ubicación en la que el equipo de auditoría cuente con acceso a la red y puestos de trabajo suficientes.

Se deberán gestionar los permisos de acceso al edificio con la suficiente antelación para garantizar que el equipo pueda acceder sin problemas durante el periodo planificado.

2.4.Equipos para la realización de las pruebas

La totalidad de las pruebas será realizada desde los equipos del equipo de auditoría propiedad del proveedor por lo que no se requieren equipos para la ejecución de las mismas.

El único requisito en este sentido será el disponer de un cable de red activo para cada miembro del equipo de auditores con acceso al segmento o segmentos asignados en cada caso.

3.Estrategia de comunicación

3.1.Comunicación general

Se llevarán a cabo las siguientes reuniones entre el equipo de auditoría y la Organización durante el transcurso del proyecto:
Reunión previa
Canal: Telefónico
Asistentes necesarios: XXXXXX
Asistentes opcionales: XXXXXX
Reunión de Inicio
Canal: Presencial. En las oficina YYYYY de la Organización.
Asistentes necesarios: XXXXXX
Asistentes opcionales: XXXXXX
Reunión Seguimiento 1
Canal: Telefónico
Asistentes necesarios: XXXXXX
Asistentes opcionales: XXXXXX
Reunión Seguimiento 2
Canal: Telefónico
Asistentes necesarios: XXXXXX
Asistentes opcionales: XXXXXX
Reunión presentación de resultados
Canal: Presencial. En las oficina YYYYY de la Organización.
Asistentes necesarios: XXXXXX
Asistentes opcionales: XXXXXX
Reunión cierre
Canal: Presencial. En las oficina YYYYY de la Organización.
Asistentes necesarios: XXXXXX
Asistentes opcionales: XXXXXX

3.2.Respuesta y gestión de incidentes

En caso de que se produzca un incidente durante la ejecución de las pruebas que tenga un impacto en los sistemas o servicios de la organización, dicho incidente deberá ser puesto de inmediato en conocimiento de los responsables de la gestión de incidentes en el proyecto tanto de la Organización como del proveedor. Los teléfonos de contacto de ambos responsables se encuentran detallados en el Anexo II “Contactos ante incidentes”. En dicho anexo se incluye también el escalado a seguir para la resolución de dichos incidentes.

El proveedor seguirá las indicaciones del equipo de gestión de incidentes de la organización para contener y solucionar cualquier impacto causado por las pruebas de intrusión.

Una vez identificado un incidente, las pruebas de intrusión deberán ser detenidas de inmediato y no serán retomadas hasta recibir la autorización por parte del responsable técnico del proyecto por parte de la Organización.

4.Sistemas y redes objetivo

Cabe señalar que para que el procedimiento cumpla con PCI DSS se deberá incluir entre los sistemas y redes objetivo, al menos, los siguientes:

• Todos los sistemas y aplicaciones que formen parte del perímetro del entorno de datos de titulares de tarjeta (CDE).
  
  

4.1.Sistemas incluidos en el alcance de las pruebas

Sistema 1: IP: Sistema Operativo: Descripción del sistema
Sistema 2: IP: Sistema Operativo: Descripción del sistema
Red Wifi XXXXYYYYY
xxxxxxxxx

4.2.Aplicaciones incluidas en el alcance de las pruebas

Aplicación 1: URL: Descripción de la aplicación
xxxxxxxxxxxxxxxxxx

4.3.Sistemas excluidos del alcance de las pruebas

Sistema 5: IP: Sistema Operativo: Descripción del sistema
Sistema 6: IP: Sistema Operativo: Descripción del sistema
xxxxxxxxx

4.4.Aplicaciones excluidas del alcance de las pruebas

Aplicación 3: URL: Descripción de la aplicación
xxxxxxxxxxxxxxxxxx

5.Ejecución de las pruebas

5.1.Pruebas no técnicas

A continuación se detallarán las pruebas no técnicas que se deberán realizar durante las pruebas de intrusión. Cabe señalar que algunas de estas pruebas pueden combinarse con pruebas de tipo técnico para aumentar su efectividad:

• Intento de acceso a las instalaciones de la organización sin identificación previa, haciéndose pasar por empleados de la Organización.
  
• Revisión de papeleras o contenedores en busca de información sensible de la Organización.
  
• Intento de obtención de datos confidenciales mediante el uso de técnicas de ingeniería social, tanto presenciales como telefónicas.
  

(Cabe señalar que estas pruebas son un ejemplo. Cada Organización puede añadir o eliminar pruebas de este tipo según sus circunstancias y objetivos).

5.2.Pruebas técnicas

Las pruebas técnicas a realizar seguirán las pautas establecidas en la metodología OSSTMM. Las pruebas deberán realizarse a nivel de red, de sistemas y de aplicación y garantizar que se identifiquen, al menos, las vulnerabilidades documentadas por OWASP y SANS, así como las que se identifican en el estándar PCI DSS v3 que son las que se listan a continuación:

• Inyecciones de código, de SQL, de comandos del sistema, de LDAP, Xpath, etc..
• Buffer overflows.
• Almacenamiento inseguro de claves criptográficas
• Comunicaciones inseguras
• Gestión de errores incorrecta
• Cross-site scripting (XSS)
• Control de acceso inapropiado.
• Cross-site request forgery (CSRF).
• Rotura de autenticación y gestión de sesiones incorrecta.
• Cualquier otra vulnerabilidad considerada como de Alto Riesgo por parte de la organización.

Adicionalmente, se deberán llevar a cabo pruebas destinadas a validar la eficacia de los controles establecidos para segmentar el entorno de datos de titulares de tarjeta (CDE) del resto de sistemas y redes de la Organización.

6.Gestión de la información

Cabe señalar que toda la información generada en el marco de las auditorías será propiedad de la Organización y tendrá la clasificación de Confidencial. Por lo tanto, se deberá almacenar y transmitir siempre de manera cifrada.

Los reportes y evidencias generados tan sólo deberán ser accedidos por el personal autorizado por parte de XXXXX. Dicha autorización se realizará siempre bajo el principio de necesidad de conocer.

La información relativa a la auditoría se almacenará únicamente durante por un plazo de X años, siendo eliminada de forma segura e irrecuperable después de dicho plazo.

El proveedor se compromete a almacenar la información relativa a la auditoría únicamente por un plazo de X meses, comprometiéndose así mismo a eliminarla de forma segura e irrecuperable transcurrido dicho plazo.

6.1.Evidencias

Para todos los hallazgos o vulnerabilidades identificados durante las pruebas realizadas se generará y documentarán las evidencias suficientes para demostrar la existencia de las mismas. El formato de las evidencias puede ser variable en cada caso; capturas de pantalla, salidas de herramientas de seguridad, fotografías, documentos físicos, etc...

6.2.Entregables

Como resultado de las pruebas realizadas deberá generarse un documento que incluya, al menos, los siguientes apartados:

1. Introducción
2. Resumen Ejecutivo
3. Metodología utilizada
4. Vulnerabilidades identificadas
5. Recomendaciones para la subsanación de las vulnerabilidades
6. Conclusiones
7. Anexo I: Evidencias

Nueva PCI DSS v3

Éste mes de noviembre ha visto la luz la tercera versión de PCI DSS. El nuevo documento incorpora unos cuantos cambios respecto a la versión anterior tanto en los apartados introductorios como en los propios requisitos y procedimientos de prueba.

La mayoría de los cambios tienen como principal objetivo aclarar cuestiones que en la versión anterior se prestaban a malinterpretaciones o que habían suscitado numerosas dudas a las organizaciones o incluso a los QSA. Sin embargo, también nos encontramos con algunos cambios de mayor calado, como nuevos requisitos, requisitos modificados para hacerlos más exigentes, o modificados para dar mayor flexibilidad en su cumplimiento.

Vamos a analizar todos esos cambios de mayor importancia que incluye la nueva versión:

• Encontramos un nuevo apartado llamado “Implementing PCI DSS into Business-as-Usual” en el que se presentan una serie de buenas prácticas y recomendaciones sobre cómo se debería implementar PCI DSS de manera que se integrara en los procesos de las organizaciones. Cabe destacar que se trata justamente de una serie de buenas prácticas y que por lo tanto no son de obligado cumplimiento ni reemplazan ninguno de los requisitos de las normas PCI DSS. En un futuro 'post' entraré en detalle a analizar este apartado ya que vale la pena revisarlo en profundidad.
• Se ha modificado la tabla en la que se presentan los requisitos, de manera que ahora se incluye una columna en la que se explica la motivación de cada requisito, tal y como en la v2 se hacía en la “navigating guide”. Me parece un cambio muy positivo, ya que esta explicación permitirá en muchos casos entender de forma más completa que se está solicitando exactamente en cada requisito del estándar sin tener que ir a consultar un documento adicional.
• Se han modificado los requisitos 12.1.1 y 12.1.2 de la v2 en los que se solicitaba que todos los requisitos contasen con los procedimientos documentados necesarios. En la v3, se han eliminado incluyéndose en un apartado específico de cada uno de los 11 primeros requisitos. De esta manera no queda duda de qué procedimientos deben documentarse en cada caso.
• Se incluye el requisito 2.4 en el que se indica que la organización debe mantener un inventario de los componentes incluidos en el alcance de PCI DSS para ayudar en el uso de los estándares de configuración a aplicar por la organización para mantener la seguridad de los sistemas.
• Como ya es sabido, el requisito 5 de PCI DSS exige el uso de antivirus en todos los sistemas del alcance excepto en aquellos que se considere que no se ven afectados por malware (Mainframe, AS400, UNIX, etc... ). Como novedad, en la nueva versión se incluye el nuevo requisito 5.1.2 en el que se establece la necesidad de seguir la evolución de los riesgos debidos al malware en sistemas que habitualmente no se ven afectados por malware y en su caso sacarlos de esta categoría.
• Otro nuevo subrequisito incluido dentro del requisito 5 ha sido el 5.3 que solicita que las soluciones antivirus se mantengan activadas y no puedan ser deshabilitadas o alteradas por los usuarios.
• El requisito 6.5.10 se considerará una buena práctica no obligatoria hasta el 1 de junio de 2015. Este requisito establece que en los procedimientos y políticas de desarrollo se deben contemplar medidas que prevengan ataques contra los marcos de autenticación y la gestión de sesiones web, incluyendo los siguientes aspectos:
  • Marcar los tokens de sesión (por ejemplo las cookies) con el flag “secure”.
  • No exponer las ID de sesión en la URL.
  • Incorporar tiempos de expiración y rotación adecuados para las ID de sesión después de un login correcto.
• Se ha modificado el requisito 8.2.3 de manera que este requerimiento ahora establece los mínimos en cuanto a complejidad y tamaño de la contraseña pero permite una mayor flexibilidad en su cumplimiento. Aunque sigue exigiendo que se use una contraseña de 7 o más caracteres y que incluya tanto caracteres numéricos como alfabéticos, se da la posibilidad de utilizar otros tamaños o complejidades siempre y cuando se mantenga igual o mayor robustez en la contraseña a utilizar.
• Se ha incluido un nuevo requisito (8.5.1) que aplicará únicamente a los proveedores de servicios y que obliga a estos a utilizar credenciales diferentes para el acceso remoto a los sistemas de cada uno de sus clientes. Este requisito será considerado una buena práctica no obligatoria hasta el 1 de julio de 2015.
• El nuevo requisito 8.6 obliga a que, en caso de utilizar mecanismos de autenticación diferentes al de usuario/contraseña, estos mecanismos estén ligados de manera unívoca a cuentas de usuario individuales y garantizar que sólo el usuario apropiado pueda hacer uso de dichos mecanismos.
• El requisito 9.3 también es de nueva aparición en esta versión y establece la necesidad de controlar el acceso físico a las áreas sensibles por parte del personal 'onsite'. Así mismo, se deberá contar con procedimientos para autorizar el acceso y revocar dicho acceso de manera inmediata cuando el personal deje de prestar sus servicios en la organización.
• Otros requisitos de nueva aparición en esta versión son los que van del 9.9 al 9.9.3. Estos requisitos exigen que se protejan los dispositivos que capturan los datos de tarjeta directamente mediante la interacción física con las mismas (lectores de tarjeta, etc..). Concretamente, los requisitos solicitan que se mantenga una lista de los dispositivos existentes, que se inspeccionen visualmente de forma periódica para detectar anomalías en los mismos y que se entrene al personal para que pueda detectar si los dispositivos han sido sustituidos o manipulados.
• El requisito 10.5.2 refuerza los requisitos asociados a la generación y revisión de registros de log al requerir que se registren los cambios en los mecanismos de identificación y autenticación, incluyendo la creación de nuevas cuentas o el incremento de privilegios, como por ejemplo el uso del comando “su”.
• El 10.2.6 también se ha visto modificado para solicitar que se incluyan los eventos correspondientes a la parada o pausa de los logs de auditoría, además de la reinicialización o borrado de los logs que ya se exigía en la versión anterior.
• También se ha aumentado la exigencia del requisito 11.1.1 que ahora solicita que se documente el inventario de puntos de acceso wireless autorizados y su correspondiente justificación de negocio.
• Por su parte, el requisito 11.1.2 de nueva creación en la v3 establece la necesidad de que los procedimientos de respuesta ante incidentes detallen el curso de acción a seguir en caso de detectarse redes Wireless no autorizadas en las revisiones trimestrales.
• El requisito 11.3 es uno de los cambios más significativos de esta nueva versión. Tiene carácter de buena práctica hasta el próximo 1 de julio de 2015 fecha a partir de la cual se considerará de obligado cumplimiento. El requisito obliga a que las organizaciones cuenten con una metodología documentada a seguir para la realización de los test de intrusión anuales, tanto internos como externos, con independencia de que sean ejecutados de forma interna por personal de la propia organización o se subcontraten a una organización externa. Esta metodología deberá contemplar, al menos, los siguientes aspectos:
  • Deberá estar basada en aproximaciones aceptadas por la industria, como por ejemplo la NIST SP800-115.
  • Debe incluir en su alcance todo el perímetro de datos de titulares de tarjeta y los sistemas considerados críticos.
  • Debe incluir pruebas desde dentro y desde fuera de la red, es decir, pruebas de intrusión externas e internas.
  • Debe incluir pruebas específicas para validar que los controles establecidos para segmentar la red o para reducir el alcance de PCI DSS sean correctos y efectivos.
  • Debe incluir pruebas de penetración en la capa de aplicación incluyendo, al menos, las vulnerabilidades listadas en el requisito 6.5 de PCI DSS. Es decir, inyecciones, buffer overflows, almacenamiento inseguro de claves criptográficas, comunicaciones inseguras, gestión incorrecta de los errores, XSS, control de acceso inapropiado, Cross-site request forgery (CSFR), roturas de autenticación o de la gestión de sesiones, o en general cualquier vulnerabilidad categorizada como crítica por parte de la Organización.
  • Debe incluir pruebas de penetración en la capa de red que incluyan tanto los componentes y dispositivos de red como sistemas operativos.
  • Debe incluir la revisión de las amenazas y vulnerabilidades que hayan afectado a la organización en los últimos 12 meses.
  • Debe especificar el periodo de retención de los resultados de las pruebas de penetración y los resultados de las actividades dirigidas a remediar las vulnerabilidades detectadas.
• Adicionalmente, el nuevo procedimiento de test 11.3.b solicita que se corrijan todas las vulnerabilidades explotables encontradas durante las pruebas de intrusión y que se repitan dichas pruebas para verificar dichas correcciones.
• El requisito 11.5 también ha sido modificado para dar mayor flexibilidad en su cumplimiento. Ahora, en lugar de exigir que se instale un FIM, se solicita que se instale algún mecanismo de detección de cambios que permita alertar al personal de modificaciones no autorizadas en ficheros críticos de los sistemas, ficheros de configuración o ficheros de contenido y que se configure el software utilizado para realizar las comparaciones de estos ficheros al menos semanalmente en busca de cambios. Así mismo, el requisito 11.5.1 obliga a disponer de un procedimiento implementado para responder a cualquier alerta generada por la solución de detección de cambios que se utilice.
• Se ha modificado el requisito 12.2 (antiguo 12.1.2) de manera que ahora no sólo se exige la realización de un análisis de riesgo anual, si no también después de cualquier cambio significativo en el entorno (por ejemplo, adquisiciones, fusiones, traslados de sede, etc..).
• El nuevo requisito 12.8.5 solicita que se mantenga documentado el detalle de qué requisitos de PCI DSS son gestionados por cada proveedor de servicios contratado y cuales son gestionados directamente por la entidad.
• Y por último, el nuevo requisito 12.9 será de aplicación únicamente a los proveedores de servicio y se considerará una buena práctica hasta el 1 de julio de 2015. Este requisito obligará a los proveedores de servicios a proveer y firmar con sus clientes de un clausulado específico en el que reconozcan explícitamente su responsabilidad en la gestión de la seguridad de los datos de titulares de tarjeta de sus clientes.

En conclusión, pienso que todos los cambios incluidos en la nueva versión del estándar son positivos y que nos encontramos ante un estándar más claro, con menos zonas grises y que permitiría a las organizaciones que lo implementen no sólo cumplir con PCI DSS si no además mejorar de forma significativa la seguridad de los datos de titulares de tarjeta que almacenen, transmitan o procesen.

PCI_DSS_v3.pdf

PCI_DSS_v3_Summary_of_Changes.pdf

Twitter: @omarbenjumea

Linkedin: http://www.linkedin.com/in/omarbenjumea

Nueva ISO27001:2013

Por fin tenemos disponible la nueva versión de la 27001. Está versión 2013 incluye bastantes cambios y el propósito de este post es echarles una ojeada de alto nivel a las principales novedades.

En primer lugar, la nueva versión se adapta al Anexo SL de ISO. Esto significa, que la distribución de apartados y fases de la norma será extremadamente similar con el resto de normas que también se están adaptando a este anexo. En la práctica, lo que se propone es que las organizaciones puedan contar con un único marco de gestión común en el que se encuentren integradas las diferentes ISO que tengan implementadas.

A continuación listaremos otros cambios significativos introducidos por la nueva versión:

• La definición del contexto pasará a tener una importancia clave como inicio de la planificación del SGSI. 
• Aparece una nueva cláusula específica para tratar del Liderazgo en el SGSI. Por lo tanto, este concepto cobrará especial importancia en las transiciones a la versión de 2013.
• Se elimina el concepto de acciones preventivas siendo sustituido por el de gestión de riesgos y oportunidades.
• Se referencia la ISO31000 como marco de gestión de riesgos, por lo que, alineado con el anexo SL, se busca que la gestión de riesgos también sea homogénea a nivel corporativo. De esta manera las organizaciones podrán comparar riesgos de diferentes tipologías (de la información, riesgos laborales, riesgos financieros, etc..).
• El hecho de alinearse con la ISO31000 provoca a su vez que los requisitos del análisis de riesgos sean más genéricos y con menor detalle que los que se definínan en ISO27001:2005 e ISO27005. El propósito es facilitar la realización de análisis de riesgos en otros sistemas de gestión que hasta la fecha no lo incorporan (como la gestión medioambiental, la de calidad o la de servicios TI).
• Los objetivos de seguridad deberán ser aprobados por negocio y se deberán destinar los recursos necesarios para su consecución. Se realizará especial hincapié en este aspecto, por lo que la asignación de recursos deberá quedar debidamente evidenciada.
• Aparece un concepto nuevo de gran importancia que será el de comunicación a las partes interesadas.
• Otro cambio relevante es que se abandona el concepto de propietario del activo y se reemplaza por propietario del riesgo.
• Se pasa de los 133 controles del anexo A a 114 controles. En realidad no se eliminan controles, tan sólo se procede a una reordenación reformulando buena parte de ellos.

La nueva versión mantiene el esquema PDCA. La distribución de cláusulas en el esquema será la siguiente (cabe señalar que la estructura es idéntica para todas las ISO que van adoptando el anexo SL):

PLAN

• Cláusula 4 Contexto: En la nueva versión cobra una importancia capital definir adecuadamente el contexto, tanto interno como externo de la organización. Es decir, tener bien presente el ecosistema en el que nos movemos para que el resto de decisiones que se adopten en el SGSI hayan considerado adecuadamente la realidad actual. Además, el concepto de contexto se alinea perfectamente con el de la ISO31000 en cuanto a definición del contexto en el que se debe realizar en análisis de riesgos.
• Cláusula 5 Liderazgo: Como hemos comentado con anterioridad, se trata de una cláusula totalmente nueva. En esta nueva versión la definición de liderazgo y responsabilidades será central, con el objetivo de garantizar que se destinan los recursos necesarios para garantizar la consecución de los objetivos definidos.
• Cláusula 6  Planificación: En esta cláusula se definen los requisitos de realizar un análisis de riesgos usando la ISO31000 como marco de referencia y se definen los requisitos a cumplir en cuanto a definición de objetivos y su planificación. La declaración de aplicabilidad se mantiene sin apenas cambios.
• Cláusula 7 Soporte/Apoyo: En esta cláusula se definen los requisitos en cuanto a formación, asignación de recursos, concienciación, comunicación y gestión documental. Además, se exigirá que las tareas de mantenimiento del SGSI se deban realizar de forma distribuida durante el año. Así mismo, como hemos comentado antes, se da gran importancia a la gestión de la comunicación a las partes interesadas, debiendo definirse qué se debe comunicar, a quien se de comunicar y cómo se debe comunicar.

DO

• Cláusula 8: Esta es la cláusula del anexo SL que más cambiará para cada ISO ya que el DO de la 27001 será totalmente diferente al DO de la ISO de gestión medioambiental, de calidad o cualquier otra ISO. En esta cláusula es donde, en base a la declaración de aplicabilidad realizada se deberá llevar a cabo la implantación de los controles pertinentes.

CHECK

• Cláusula 9: La cláusula novena definirá los requisitos en cuanto a métricas e indicadores del SGSI. En esta nueva versión se refuerza la exigencia en cuanto a definición e implantación de métricas.

ACT

• Cláusula 10: La última cláusula pone el foco en la mejora continua. En este aspecto, los cambios respecto a la versión 27001:2005 son mínimos.

En conclusión, aunque sigue siendo la ISO27001, su adaptación al anexo SL y los cambios incluidos en la nueva versión van a exigir un esfuerzo importante de adaptación a realizar en 2014 por parte de las empresas que quieran mantener su certificación. Después de esta primera revisión a alto nivel de las novedades que incluye la ISO estoy convencido que los cambios son a mejor y que redundarán en una mejora de la eficiencia de los SGSI que utilicen esta norma como base para su implementación.


twitter: @omarbenjumea
linkedin: http://www.linkedin.com/in/omarbenjumea

¿Vale la pena certificar nuestro SGSI?

De un tiempo a esta parte le he estado dando vueltas a la utilidad de certificarse en ISO27001. Conozco el estándar desde hace muchos años, tanto desde el punto de vista de consultor como de auditor interno, de implantador y de operador/administrador del SGSI (Sistema de Gestión de la Seguridad de la Información). La teoría está clara; estar certificado te permite contar con la confirmación de un tercero “independiente” que garantiza que el sistema de gestión de la información de tu organización cumple con los requisitos del estándar. Esto se supone que ha de ser una ventaja competitiva frente a otros competidores no certificados debido al aumento de confianza que el sello debería proporcionar en clientes y proveedores.

Y aunque puede que esto sea cierto en algunos casos, pero en mi opinión, no lo es en la mayoría. La ISO27001 sigue siendo una gran desconocida fuera del sector de TI y en muchos casos también dentro del propio sector. Así mismo, es muy raro el caso en el que un pliego o una RFP exijan que los proveedores estén certificados e incluso son raros los casos en los que se indica que la certificación será tenida en cuenta en la adjudicación del proyecto o servicio.

Estoy de acuerdo en que hoy en día es indispensable para toda empresa contar con un SGSI si se desean mitigar los riesgos que afectan a su información de una forma eficiente, y la ISO27001 es una excelente opción (aunque no la única) en la que basarlo. La ISO permite racionalizar los esfuerzos que se dedican a la seguridad, de manera que se optimiza la reducción de riesgo para una determinada inversión en seguridad. Además, establece un ciclo de mejora continua que también es indispensable para mantener unos niveles de seguridad aceptables a lo largo del tiempo.

Sin embargo, debería ponderarse con cuidado la decisión de abordar un proceso de certificación, teniendo en cuenta los beneficios y los esfuerzos que de ello se derivará. Dado que los auditores de certificación se focalizan en formalismos (no puede ser de otra manera en una auditoría de pocos días), puede ocurrir que los mayores esfuerzos en la implantación del SGSI no se dediquen estrictamente a montar el Sistema de Gestión más adecuado a nuestra organización, si no que es frecuente que los mayores esfuerzos se dediquen a cumplir con todos los formalismos documentales que exige la norma. Esto significa además, que nuestro SGSI perderá flexibilidad, ya que una vez adquirida la certificación no querremos arriesgarnos a perderla.

También hay que tener en cuenta que todo el tinglado de la certificación y los certificadores puede resultar en sí mismo perjudicial para el cumplimiento efectivo del estándar. Por un lado tenemos empresas certificadoras que se ganan la vida acreditando a las organizaciones y, especialmente, recertificándolas año tras año. Además, son competencias unas de las otras, por lo que cada una toma su rol. Tenemos las empresas en las que todo el mundo sabe que es fácil certificarse, y las empresas en las que se supone que es más difícil hacerlo. En cualquier caso, todas comparten el mismo objetivo (y no es mejorar la seguridad de sus clientes); certificar a tantas empresas como sea posible y fidelizarlas para continuar recertificándolas año tras año. Por otro lado, tenemos a los auditores, autónomos subcontratados por las certificadoras, que en muchas ocasiones realizan una interpretación extremadamente subjetiva del estándar llegando a establecer no conformidades u observaciones que en nada ayudan a mejorar la seguridad de la Organización. Sin embargo, deben ser acometidas si se quiere mantener la certificación. Creo que coincidiréis conmigo en que no es el ecosistema más propicio para la mejora

En conclusión, aunque puede ser muy beneficioso en determinadas circunstancias o para determinadas organizaciones, pienso que se debe considerar detalladamente hasta que punto los esfuerzos destinados a implantar o mantener un SGSI certificable merecen la pena en la mayoría de los casos. Si no tenemos claro que el hecho de certificar nuestro SGSI vaya a tener un ROI aceptable, pienso que es mejor dedicar los principales esfuerzos a tener un SGSI lo más eficaz y alineado con nuestra organización posible aunque no cumpla todos los requisitos necesarios para que la empresa certificadora de turno nos conceda su sello.

Mitigar ataques Pass-the-Hash by Microsoft

El otro día me topé con un documento de Microsoft que desconocía sobre cómo mitigar los riesgos de sufrir un ataque de tipo "Pass the Hash". El documento se puede descargar haciendo click aquí.

En primer lugar, recordemos qué es un ataque de tipo Pass-the-Hash. Este tipo de ataque consiste en capturar las credenciales de acceso a un equipo y usar dichas credenciales para autenticarse en otros equipos de la red. El concepto es muy similar al de un robo de contraseña, pero en este caso lo que se roba en lugar de ser la contraseña es el hash de una contraseña o bien un ticket de sesión válido.

Para llevar a cabo este tipo de ataque se necesita tener acceso con permisos de administración local en el equipo en el que se haya logado el usuario del que queremos obtener las credenciales. El caso más típico es el de obtener acceso con privilegios de administrador local en un equipo con pocas medidas de seguridad, por ejemplo una estación de usuario o un servidor de desarrollo y utilizar este acceso para hacerse con las credenciales de otro usuario con mayores privilegios que se haya logado recientemente en ese equipo, por ejemplo, un controlador de dominio que haya accedido para llevar a cabo taréas administrativas.

El documento de Microsoft propone considerar las siguientes medidas de seguridad para mitigar el riesgo de sufrir un ataque de este tipo:

• Restringir y proteger las cuentas de dominio que cuenten con privilegios elevados:
• Evitar usar los usuarios administradores de dominio para logarse en equipos con un nivel bajo de seguridad que puedan ser comprometidos, como por ejemplo, equipos de usuarios, servidores no productivos, etc..
• Proveer a los administradores de sistemas de usuarios con privilegios de administración separados de sus cuentas de usuario normales.
• Utilizar sólo determinadas estaciones de trabajo para realizar las tareas administrativas.
• En el Directorio Activo, asegurarnos que las cuentas privilegiadas estén marcadas con la opción "Sensitive and cannot be delegated".
• No configurar servicios o tareas programadas que utilicen usuarios con privilegios en el dominio en equipos con un bajo nivel de seguridad, como las estaciones de trabajo o entornos no productivos.
• Restringir y proteger las cuentas locales con privilegios de administrador:
• Evitar que las cuentas locales con privilegios administrativos puedan ser utilizadas para la administración remota de los equipos.
• Denegar explícitamente el logon de red y el uso de Escritorio Remoto para todas las cuentas locales con privilegios administrativos.
• Usar passwords únicos en cada máquina para las cuentas locales con privilegios administrativos.
• Usar firewalls de sistema para restringir el tráfico entrante a los sistemas:
• Usar el firewall de windows u otro firewall de Host para restringir al mínimo indispensable el tráfico entrante (y saliente) de todos los servidores y estaciones de trabajo.
• Quitar los privilegios de administrador local a los usuarios normales:
• Para evitar que el compromiso de una cuenta de usuario permita realizar un ataque de este tipo, es necesario que los usuarios no cuenten con privilegios de administrador local de sus estaciones de trabajo.
• Configurar un proxy de salida para denegar el acceso a Internet a cuentas privilegiadas. En el propio documento de Microsoft viene el detalle de cómo realizar esta configuración.
• Garantizar que las cuentas privilegiadas no tengan asignados buzones de Exchange o de otros servicios de correo electrónico.
• Usar herramientas de administración remota que no dejen hashes o tickets guardados en las estaciones remotas a las que se accede. (Si alguien sabe qué herramientas de administración remota cumplen esta premisa se agradecerán los comentarios ya que es algo que aún no me he puesto a analizar.. ;) )
• Evitar acceder con cuentas privilegiadas a entornos de menor seguridad como estaciones de trabajo o equipos no productivos para evitar que el compromiso de estos equipos comprometa a su vez los equipos más críticos. Para evitar esto sería recomendable que los administradores contaran incluso con diversas cuentas de usuarios en función de la sensibilidad de los equipos a administrar. Por ejemplo, Administrador_Desarrollo, Administrador_Workstations, Administrador_DMZ y Administrador_Servidores.
• Mantener actualizados sistemas operativos y aplicaciones de forma que el usuario no pueda conseguir comprometer una cuenta con privilegios locales de administración y por lo tanto no pueda comprometer a su vez cuentas con privilegios en el dominio.
• Bastionar y gestionar adecuadamente la seguridad de los controladores de dominio. Si el atacante directamente compromete un controlador de dominio, ya no necesitará llevar a cabo un ataque PassTheHash...
• Eliminar los hashes LM. Para ello es necesario que todos los controladores de dominio sean al menos Windows Server 2008.

Y por último, aunque no se menciona en el documento de Microsoft, yo añadiría la necesidad de contar con una adecuada segmentación de red que permita garantizar que, aunque se comprometa una credencial de administrador de dominio en un determinado servidor o estación de trabajo, el atacante no pueda logarse directamente en el resto de servidores de la estación. Con una segmentación adecuada limitaríamos el impacto del compromiso a la VLAN de la máquina comprometida.