Antes de realizar un proyecto de hacking ético, test de penetración o auditoria de seguridad surgen ciertas preguntas comunes que nos gustaría responder. Estas son las FAQ (Frequent Asked Questions) que surgen antes de afrontar un proyecto de este tipo.
¿Porqué realizar una Auditoría de seguridad?
Las razones son muy variadas, aunque las más comunes son: prepararse para auditorías corporativas obligatorias, auditorías de certificación (ISO27000, SOX, Basilea, VISA, etc.), cambios recientes en la infraestructura, comprobar el funcionamiento de nuevos productos tecnológicos, iniciarse en la gestión de la seguridad o un plan director de seguridad, conocer las prioridades de inversión en seguridad, justificar inversiones o proyectos, conocer el riesgo potencial existente, etc.
¿Como se van a ver afectados mis sistemas durante la auditoría?
Para responder a esta pregunta se debe tener en cuenta que nuestro objetivo durante estos proyectos es el de vulnerar la confidencialidad de los sistemas de información de la forma más discreta y sigilosa posible.
La afectación típica que reciben los sistemas, es un ligero incremento de tráfico provocado por los distintos tipos de ataque que en la mayoría de casos es imperceptible. En casos en que el cliente desee realizar algún tipo de prueba específica que pueda comprometer la disponibilidad o integridad de algún sistema concreto, se advertirá y se tomarán las medidas de seguridad necesarias para provocar un impacto controlado.
¿Qué tipos de auditorías de seguridad se realizan?
Hay varias formas de catalogarlas y definirlas. Una forma común es catalogarlas por la red dónde se encuentra el atacante, interna o externa (perimetral). Aunque la categorización que más nos gusta es la siguiente:
- Caja Negra: Se trata de la auditoría en los que el atacante no debe conocer ningún detalle de los sistemas a auditar, sólo información mínima y realiza un ataque externo.
- Caja Gris: En este caso se realiza desde dentro de la organización. Se conecta un portátil a una toma de red, o se accede a un ordenador con un perfil estándar y privilegios limitados.
- Caja Blanca: Este tipo de auditorías se realizan desde dentro de las instalaciones del cliente. Se da a los auditores credenciales válidas y una lista de IPs o de servidores de los cuales se quieren auditar riesgos y vulnerabilidades.
- Aplicación Web: En este tipo de auditoría se revisa la seguridad de una aplicación web específica. Por norma general se auditan los riesgos más comunes, publicados en OWASP Top 10. Es común realizarlas antes de poner en producción la aplicación web, o para auditar su seguridad si ha sido realizado por un tercero.
- Completa: Es una combinación de las anteriores (sobre todo de las 3 primeras), es habitual realizarlas cuando se quiere hacer un análisis general de la seguridad de una organización. Los resultados son muy completos y abarcan muchos ámbitos (webs, arquitectura de redes, DMZ, correo, hardware, software, wifi, configuración, intranet, proxy, firewall, etc.).
¿Qué tipo de ataques se realizan en una auditoria?
Esta respuesta es compleja, ya que dependerá del tipo de proyecto y del sistema a auditar. Si se trata de una aplicación web, se suelen auditar los OWASP top 10. Si es un ataque externo, se probaran escaneos, ataques de fuerza bruta y diccionario, fallos de configuración de hardware y software, errores conocidos, etc. Si es un ataque interno se auditará la seguridad de la plataforma de trabajo, configuración correcta, contraseñas por defecto o compartidas, etc. Se debe tener en cuenta que una de las limitaciones dentro del alcance es la temporal, esto merma las capacidades de algunos tipos de técnicas como es el de fuerza bruta o el análisis de código.
¿Cómo se garantiza la confidencialidad?
En cualquier proyecto, se realizan contratos de confidencialidad, aunque en este caso, no se debe olvidar que se está redactando un “manual de intrusión” en la organización, por lo que los datos son especialmente sensibles. Todos los datos que se recopilan durante la auditoría son encriptados de forma segura tanto durante el transporte como dentro de nuestras oficinas. Sólo el personal que participa en el proyecto tiene acceso a los datos. Una vez finalizado el proyecto, entregados los documentos al cliente, y firmado el acuerdo de cierre, estos son eliminados definitivamente de nuestros sistemas.
¿Cuál es el resultado de este tipo de proyectos?
Se obtiene uno o varios informes de auditoría (dependiendo del alcance) en el que se detallan paso a paso las acciones realizadas por el equipo de auditores señalando las vulnerabilidades y la criticidad de éstas. Según se acuerde se pueden auditar o crear políticas de seguridad, definir planes directores de seguridad, dar formación en seguridad a distintos roles dentro de la organización, etc.
¿Cuáles son las reacciones ante los resultados?
Curiosamente la reacción más habitual en las auditorías de seguridad completas es la sorpresa, aunque hay que diferenciar dos perfiles que son el técnico y el de negocio. El técnico en muchos casos ya conoce algunas de las carencias técnicas, y se sorprende de la criticidad de otras. En algunos casos sale reforzado en su opinión de ser más estricto con la seguridad a nivel organizativo. El perfil orientado a negocio también queda sorprendido ya que en algunos casos no eran conscientes del potencial peligro al que estaban expuestos. Cuando los resultados son muy distantes a lo esperado, crece la focalización en la seguridad de la empresa a nivel técnico y organizativo. Es muy importante dejar claro que el objetivo del proyecto es mejorar la seguridad global y no señalar a nadie.
En definitiva, detrás de todo proyecto de hacking ético existe una metodología contrastada de gestión de proyectos que se encarga de que se ejecuten todas las pruebas de forma rigurosa y controlada, hecho que nada tiene que ver con los falsos tópicos existentes sobre la figura del hacker, donde un personaje excéntrico a altas horas de la madrugada trata de acceder a los sistemas basándose en su inspiración, y sin tener en cuenta las consecuencias de sus acciones.
Esta respuesta es compleja, ya que dependerá del tipo de proyecto y del sistema a auditar. Si se trata de una aplicación web, se suelen auditar los OWASP top 10. Si es un ataque externo, se probaran escaneos, ataques de fuerza bruta y diccionario, fallos de configuración de hardware y software, errores conocidos, etc. Si es un ataque interno se auditará la seguridad de la plataforma de trabajo, configuración correcta, contraseñas por defecto o compartidas, etc. Se debe tener en cuenta que una de las limitaciones dentro del alcance es la temporal, esto merma las capacidades de algunos tipos de técnicas como es el de fuerza bruta o el análisis de código.
¿Cómo se garantiza la confidencialidad?
En cualquier proyecto, se realizan contratos de confidencialidad, aunque en este caso, no se debe olvidar que se está redactando un “manual de intrusión” en la organización, por lo que los datos son especialmente sensibles. Todos los datos que se recopilan durante la auditoría son encriptados de forma segura tanto durante el transporte como dentro de nuestras oficinas. Sólo el personal que participa en el proyecto tiene acceso a los datos. Una vez finalizado el proyecto, entregados los documentos al cliente, y firmado el acuerdo de cierre, estos son eliminados definitivamente de nuestros sistemas.
¿Cuál es el resultado de este tipo de proyectos?
Se obtiene uno o varios informes de auditoría (dependiendo del alcance) en el que se detallan paso a paso las acciones realizadas por el equipo de auditores señalando las vulnerabilidades y la criticidad de éstas. Según se acuerde se pueden auditar o crear políticas de seguridad, definir planes directores de seguridad, dar formación en seguridad a distintos roles dentro de la organización, etc.
¿Cuáles son las reacciones ante los resultados?
Curiosamente la reacción más habitual en las auditorías de seguridad completas es la sorpresa, aunque hay que diferenciar dos perfiles que son el técnico y el de negocio. El técnico en muchos casos ya conoce algunas de las carencias técnicas, y se sorprende de la criticidad de otras. En algunos casos sale reforzado en su opinión de ser más estricto con la seguridad a nivel organizativo. El perfil orientado a negocio también queda sorprendido ya que en algunos casos no eran conscientes del potencial peligro al que estaban expuestos. Cuando los resultados son muy distantes a lo esperado, crece la focalización en la seguridad de la empresa a nivel técnico y organizativo. Es muy importante dejar claro que el objetivo del proyecto es mejorar la seguridad global y no señalar a nadie.
En definitiva, detrás de todo proyecto de hacking ético existe una metodología contrastada de gestión de proyectos que se encarga de que se ejecuten todas las pruebas de forma rigurosa y controlada, hecho que nada tiene que ver con los falsos tópicos existentes sobre la figura del hacker, donde un personaje excéntrico a altas horas de la madrugada trata de acceder a los sistemas basándose en su inspiración, y sin tener en cuenta las consecuencias de sus acciones.
