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 sistemaSistema 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ónxxxxxxxxxxxxxxxxxx
4.3.Sistemas excluidos del alcance de las pruebas
Sistema 5: IP: Sistema Operativo: Descripción del sistemaSistema 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ónxxxxxxxxxxxxxxxxxx
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.
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:
- Introducción
- Resumen Ejecutivo
- Metodología utilizada
- Vulnerabilidades identificadas
- Recomendaciones para la subsanación de las vulnerabilidades
- Conclusiones
- Anexo I: Evidencias
2 comentarios:
Hola es NIST 800-15 o 800-115?
Hola Edison,
Es NIST 800-115, se trataba de una errata. Bien visto, ;)
Publicar un comentario