Las FAQ del Hacking Ético

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.

Nos podría pasar a todos

La seguridad de la red es un tema muy de moda últimamente con las noticias que llegan desde Sony en relación a su Play Station Network (PSN). Los datos de 77 millones de usuarios, incluidos datos bancarios y contraseñas, han sido robados por un grupo de hackers paralizando el acceso durante 9 días de la Play Station Network de Sony. A día de hoy se conocen aún pocos detalles sobre el suceso como la autoría, el alcance real del ataque y la finalidad de éste.

Esta noticia lleva a varias reflexiones:

¿Si le ha pasado a Sony, podría suceder en mi organización?

¿Dispongo de las medidas de seguridad necesarias para evitar un ataque de hacking?

En caso que sucediera ¿Cuánto tardaría en detectarlo?

¿Nuestra organización puede permitirse soportar un escándalo similar?

A pesar de que Sony es una compañía fuerte y consolidada, todavía no se conoce el impacto que producirá en la imagen de marca y en la confianza de sus clientes, ya que la información robada es crítica por su repercusión mediática y por el temor de sus clientes a ver expuestos en la red sus credenciales y sus datos bancarios. Por este motivo es muy importante en nuestras organizaciones saber qué datos son especialmente críticos, quién tiene acceso a éstos y si están debidamente protegidos.

Las Auditorías de Seguridad o Tests de Penetración se realizan para prevenir este tipo de ataques. Se simula la ejecución de un ataque informático realizado por un hacker de la forma más realista posible. Estos proyectos son una buena forma de auditar la seguridad interna o perimetral de la organización, no sólo para ayudar al Departamento TIC a justificar inversiones que la organización no percibe como prioritarias, sino también para conocer la respuesta a estas preguntas:

¿Qué nivel de madurez tiene nuestra seguridad de la información?

¿Cuáles son nuestras vulnerabilidades críticas?

¿Qué debe cambiar en nuestro sistema o nuestros procedimientos para ser mejorar la seguridad?

¿Son efectivas nuestras medidas de seguridad?

Es importante destacar que no se audita la seguridad solamente a nivel técnico sino también a nivel de procedimientos y políticas. La mayoría de las vulnerabilidades que se encuentran en este tipo de auditorías pueden ser subsanadas aplicando medidas organizativas, políticas de seguridad adaptadas a la organización y formación a los usuarios. La concienciación de los usuarios a todos los niveles es fundamental en la seguridad, de nada sirven las mejores y más caras soluciones de seguridad sin unos procedimientos y sin una cultura de seguridad organizativa. Los resultados de un test de penetración son una buena herramienta para lograr dicha concienciación.

La seguridad de la información es una cadena que siempre se rompe por el eslabón más débil. Por este motivo, es imprescindible conocer las vulnerabilidades existentes para saber qué medidas pueden mejorar la seguridad proactiva, la seguridad activa y la seguridad reactiva. Llegando a la conclusión de que no deberíamos esperar sufrir un incidente para invertir en seguridad.

El ROI (Retorno de la Inversión) en seguridad es mucho mayor en la prevención que en la reparación, sobretodo porque existen casos en que el daño puede ser irreparable.

Plan de Contingencia. ¿Cómo?. ¿Cuándo?

Algunos de vosotros nos habéis preguntado respecto de los criterios de activación del Plan de Contingencia. Para ello recurriremos a la guía 800-34 del NIST: Contingency Planning Guide for Information Technology Systems.

Para fijar conceptos, empecemos estableciendo en qué consiste realmente el plan. Estamos hablando, básicamente, de restaurar la interrupción de los servicios de TI:

1. Recuperando las operaciones de TI en una ubicación alternativa.
2. Recuperando las operaciones de TI con equipamiento alternativo.
3. Realizando alguno de los procesos de negocio soportados por dichos servicios mediante medios manuales.

Una vez tenemos el plan montado y probado, éste debe ser activado sólo cuando la evaluación de daños indica que uno o más de los criterios de activación se cumplen. Estos criterios son únicos para cada organización, deben ser claros y pueden basarse en:

1. La seguridad del personal y/o la magnitud de los daños sobre las instalaciones.
2. La extensión de la avería según criterios físicos, operacionales o financieros.
3. La criticidad del sistema afectado.
4. La previsión de la duración de la interrupción en base a los RTOs establecidos en el BIA. Este punto está relacionado con el anterior.

Por ejemplo, podemos establecer que nuestro plan se activará:

1. Cuando el tiempo de recuperación previsto de cualquiera de los servicios excede el tiempo máximo establecido.
2. Cuando transcurrido el 50% del tiempo máximo para la recuperación de un servicio, no haya sido posible identificar su causa.

Plan de Contingencia y catálogo de servicios de TI

Últimamente se han escrito en este blog diferentes puntos clave a tener en cuenta durante la realización de un Plan de Contingencia. El Plan de Contingencia tal como sabemos, trata de planificar la restauración de los servicios de TI ante una situación de desastre.

Como explicamos en su día, la primera fase del plan, el Análisis de Impacto (BIA), consiste en:

1. Identificar los procesos más críticos del negocio y los servicios de TI que los soportan.


2. Determinar el impacto si uno o varios de estos servicios de TI se ven afectados total o parcialmente.


3. Definir los requerimientos de recuperación establecidos por el negocio - tiempo máximo de interrupción o RTO y máxima pérdida de datos permitida o RPO.

En el momento de realizar el BIA, los requerimientos de recuperación del negocio se recogen a través de entrevistas con los responsables de las diferentes áreas o departamentos de la organización: RR.HH, compras, marketing, logística, producción, etc. El objetivo de dichas entrevistas es averiguar qué servicios de TI usa cada área o departamento.

Sin embargo, en este punto debemos preguntarnos si sabemos cuáles son los servicios de TI que ofrecemos. No se puede empezar la casa por el tejado, por lo que tanto el negocio como el Departamento de TI deben conocer cuáles son los servicios de TI que se ofrecen y soportan desde TI y en qué consisten.

El problema radica en que si no tenemos esta información:

1. Es complejo traducir lo que percibe el negocio con respecto a lo que ofrece TI.


2. Es fácil que el entrevistado no hable de todos los servicios de TI que utiliza. Disponer de un listado de servicios de TI ayuda a no dejarse nada en el tintero durante la realización de las entrevistas.

Por tanto, se hace necesario disponer de este catálogo de servicios de TI lo más fiel a la realidad posible.

Nuestra recomendación es incluir dentro del proyecto de Plan de Contingencia una revisión de los servicios de TI para poder conocer qué elementos los soportan (infraestructura, aplicaciones, etc.) y tener la habilidad de identificarlos durante las entrevistas. El uso de este catálogo reducirá el riesgo de repetir entrevistas y agilizará el proyecto con la seguridad de ser exhaustivos durante el proceso.

Como ya sabréis o habréis podido deducir de lo explicado hasta ahora, el catálogo de servicios es la herramienta que permite a los departamentos de TI categorizar de una manera ordenada cuales son los servicios de TI que se están provisionando y soportando. El catálogo de servicios de TI permite al departamento de TI describir:

1. Qué está proporcionando TI al negocio: cómo está ayudando a soportar los procesos de negocio de la organización.


2. Cómo lo está proporcionando: infraestructura, aplicaciones, personas, procesos de TI, niveles de disponibilidad y seguridad, garantías de continuidad, costes, etc.

Con esta entrada completamos el trimestre dedicado a los Planes de Contingencia. Si alguno de vosotros tiene alguna pregunta, necesita más información del tema o quiere aclarar algún concepto, por favor no dudéis en escribir vuestros comentarios o poneros en contacto con nosotros.

El próximo trimestre, hablaremos de las auditorías técnicas de seguridad o hacking éticos.

Plan de Contingencia. Aspectos a tener en cuenta

Informe de situación del CPD

Dentro del análisis de riesgos es imprescindible evaluar el conjunto de sistemas que forman parte del CPD y conocer exactamente las condiciones en que se encuentran. Para ello es conveniente realizar un estudio detallado de las condiciones que cumplen, con el objetivo de definir un conjunto de medidas correctoras, dirigidas a mejorar la seguridad física de la sala y optimizar la disponibilidad de los servicios de TI.

Como valor añadido, este análisis nos permitirá establecer recomendaciones con el objetivo de perseguir la máxima eficiencia energética de cada uno de los sistemas y así reducir el consumo energético del conjunto del CPD y, en consecuencia, los costes asociados.

De esta forma y una vez implementadas las recomendaciones resultantes, la organización habrá minimizado los riesgos que pueden afectar al CPD, aportando estabilidad y seguridad a todos los procesos de negocio.

El análisis ha de contemplar los siguientes aspectos:

• Sistema de cerramiento de la sala.
• Sistema eléctrico.
• Sistema de alimentación interrumpida.
• Sistema de climatización.
• Sistema de protección contra incendios.
• Sistema de monitorización de alarmas.
• El estado general de la sala, en cuanto a distribución, orden, limpieza, y nivel de respeto intrínseco de las condiciones de seguridad, control de accesos así como otros criterios técnicos específicos vitales en este tipo de entornos.

Manuales técnicos y “checklists funcionales”

Para que la recuperación de los servicios en el entorno de contingencia y su posterior restitución a la situación original sea un éxito, es imprescindible:

Definir cómo “levantaremos” la infraestructura que soporta los servicios de TI – equipos, bases de datos, comunicaciones, etc.- en los diferentes entornos.

Definir cómo comprobaremos que los procesos de negocio asociados a dichos servicios funcionan correctamente. Hemos de comprobar si podemos seguir haciendo pedidos, facturando, vendiendo, etc…

Para realizar el primer punto debemos definir todos aquellos manuales técnicos asociados. Manuales cuya ejecución se comprobará durante las pruebas y cuya responsabilidad de realización recae sobre el personal de TI.

Para realizar el segundo punto debemos definir todos aquellos “checklists funcionales” asociados a los procesos de negocio soportados por los servicios de TI. La responsabilidad de su realización recae sobre las diferentes unidades de negocio.

Proceso de gestión de la continuidad y disponibilidad de los servicios de TI

Una vez realizado el plan de contingencia, si queremos que sea algo vivo y útil, es fundamental establecer las bases para una gestión eficaz y eficiente, que proporcione continuidad en el tiempo al resto de trabajos realizados durante la creación del plan. Para ello, será necesario definir el proceso de gestión de la continuidad y disponibilidad de los servicios de TI.

La definición de este proceso implica, a su vez, la definición de los siguientes elementos:

• Objetivos de cada proceso.
• Actividades de cada proceso y roles y responsabilidades asociados a cada una de ellas de manera que quede claro quién hace qué dentro del proceso.
• Relaciones con el resto de procesos, principalmente gestión de incidencias, problemas, configuración y cambios.
• Las entradas del proceso definirán qué es lo que este proceso requiere de los demás.
• Las salidas del proceso definirán qué información se debe entregar al resto de procesos.
• Métricas e indicadores que describan cómo se debe medir el proceso.

Este proceso nos permitirá:

• Determinar claramente las responsabilidades dentro del ciclo de diseño, transición y operación de los servicios de TI.
• Que los servicios de TI se diseñen para alcanzar los requerimientos de disponibilidad y continuidad del negocio.
• Que se establezcan las bases para la mejora continua de los servicios de TI.
• Que se facilite la justificación del coste de las inversiones asociado a la disponibilidad y continuidad de los servicios.
• Adoptar una mentalidad proactiva.

Retos de la gestión de la LOPD en grandes organizaciones

Las grandes organizaciones, con grandes grupos de empleados, un número importante de departamentos o varias delegaciones y/o sucursales, necesitan poder gestionar y mantener toda la información y documentación asociada al cumplimiento de la LOPD de forma centralizada y actualizada.

Además, este tipo de organizaciones tiene la necesidad de enmarcar las medidas exigidas por la LOPD y su Real Decreto dentro del cumplimiento general de las obligaciones legales, reglamentarias o contractuales y de los requisitos de seguridad de la organización que pueden venir determinados por estándares internacionales como ISO27000 o SOX.

Abast Grup y ECIJA le invitan a un seminario en el que examinaremos la forma de abordar el cumplimiento de lo exigido por la LOPD y le mostraremos herramientas que le permitirán gestionar y cumplir con lo establecido por la ley y su Real Decreto de una manera eficaz.

El evento se realizará el día 1 de marzo en las oficinas de Abast en Barcelona (C/Equador, 39-45). El evento se iniciará a las 9:30 y finalizará, como muy tarde, a las 12:30. A continuación os detallamos la agenda del mismo:

• Café de bienvenida y entrega de la documentación
• Retos de gestión de la LOPD en grandes organizaciones.
  • David Ortega - Director de Consultoría y Auditoría de TI de Abast
• Demostración práctica de la herramienta Ecija DPServer.
  • Álvaro Écija Bernal - Socio Director de ECIJA
• Caso de éxito. Pendiente de confirmar
• Ruegos y preguntas
• Aperitivo

Si estáis interesados podéis inscribiros en www.abast.es/seminarios o llamando al 902 486 901.

¿Cómo hacer un Plan de Contingencia?

A medida que las organizaciones dependen más y más de la tecnología, que se ha convertido en un componente clave de la mayor parte de los procesos de negocio, la disponibilidad de los servicios de TI es imprescindible para su supervivencia. Esta disponibilidad se consigue mediante la definición e implementación de un Plan de Contingencia cuyo objetivo consiste en garantizar que se puede recuperar la infraestructura de TI que soporta dichos servicios dentro de los plazos y con el nivel de servicio acordado y necesario para el negocio.

Beneficios

1. Reducción de aquellos riesgos que, en caso de materializarse las amenazas que les originan, pueden representar pérdidas ingentes de capital, bien por facturación fallida, por reposición de los daños causados, por pérdida de oportunidad de negocio, por reclamación de clientes, por sanciones legales, etc.
2. Ahorro de tiempo y dinero al afrontar y corregir situaciones nefastas antes de que ocurran y nos obliguen a resolverlas con prisas y a cualquier precio.
3. Mejora de la imagen y revalorización de la confianza en la empresa de los accionistas, inversores, empleados, proveedores y clientes al mostrarles que se toman medidas diarias para garantizar la continuidad del negocio.

Retorno de la Inversión

La metodología para desarrollar el plan tiene como objetivo principal ayudar a la organización a garantizar que se implementan las medidas y estrategias de recuperación que el negocio realmente necesita y puede permitirse.

Es fundamental, por tanto, entender que significa para el negocio la no disponibilidad de sus sistemas y realizar las acciones y planes necesarios para evitar que ocurra. La clave para lograr esta comprensión es la calificación (la validación con el negocio) de lo que significa realmente el tiempo de inactividad y, a continuación, la cuantificación (medición) de las consecuencias para el negocio. Se trata, por tanto, de estimar el coste de mejorar la infraestructura de TI actual frente a las pérdidas por no disponibilidad.

Metodología

Básicamente, un proyecto de Plan de Contingencia consiste en:

1. Análisis de impacto en el negocio. Consiste en identificar los procesos más críticos del negocio, los servicios de TI que los soportan, determinar el impacto si uno o varios de estos servicios de TI se ven afectados total o parcialmente y definir los requerimientos de recuperación establecidos por el negocio – tiempo máximo de interrupción y máxima pérdida de datos permitida -.
2. Análisis de riesgos. Consiste en estimar el riesgo potencial al que están sometidos los sistemas de TI, evaluando el impacto asociado a la materialización de una amenaza, y definir aquellas recomendaciones o controles preventivos que permitan reducir o eliminar dicho riesgo.
3. Definición de las estrategias de recuperación. Consiste en establecer los escenarios de recuperación en función de las amenazas determinadas en el análisis de riesgos y los requerimientos de negocio definidos en el análisis de impacto. En esta fase se define el escenario tecnológico óptimo para soportar los procesos de negocio, atendiendo a las disponibilidades del servicio.
4. Desarrollo e implementación del Plan de Contingencia. Una vez definida la estrategia de recuperación, el plan debe definir y establecer aquellos procedimientos, manuales técnicos y checklists funcionales que permitan restaurar los servicios de TI (sistemas, operaciones y datos) después de una emergencia o afectación total o parcial de estos servicios. La implementación del plan consiste en la ejecución de las recomendaciones establecidas en el análisis de riesgos y el escenario tecnológico definido.
5. Prueba y mantenimiento del plan. Las pruebas del plan son esenciales para identificar las deficiencias de planificación y preparación del personal. Además, el plan debe ser un documento vivo que se actualiza periódicamente para mantenerse al día con los cambios en los sistemas de TI.

Aspectos importantes a tener en cuenta:

1. Es aconsejable, en algunos casos imprescindible, utilizar una herramienta para realizar el análisis de riesgos. En el mercado existen diversas herramientas y cada una de ellas tiene sus ventajas e incovenientes: PILAR, Meycor, Proteus, Ecija (PCN, SGSI), etc.
2. Es necesario definir los procesos de continuidad y disponibilidad de TI que permitan mantener actualizado el plan frente a los cambios continuos de la infraestructura y servicios de TI, considerando de forma especial su integración con el proceso de gestión de cambios.
3. Un punto delicado es la definición de los criterios de activación del plan. El plan debería activarse cuando la evaluación de los daños indique que se han cumplido uno o más de estos criterios.
4. Las estrategias de recuperación nos definen el escenario tecnológico que cumple con los criterios de continuidad del negocio. El desarrollo del plan de contingencia asociado puede verse aplazado hasta la implementación de dicho escenario. Esto puede conllevar una inversión económica considerable que deberá pasar, entre otras cosas, por un proceso de aprobación que se puede dilatar en el tiempo. Entre tanto, es aconsejable definir un plan provisional basado en "best effort" - intentar solucionarlo lo antes posible - que prevea qué hacer en caso de activación del plan.