martes, 7 de junio de 2011

¿Que debería buscar en un informe de un análisis de vulnerabilidades, o un ethical hacking un auditor de TI?

Hace un par de días, me encontré con esta pregunta en un foro, y pensé que sería interesante comentarlo aquí en el foro. (A parte, que como ando como loco preparandome para un exámen, como que he tenido el blog y a mis queridos lectores un poco abandonados, y darles refritos de otros lados, como los resultados electorales(salió sin querer mi querido WC, no te lo tomes a mal ;) jeje), la salida del backtrack5, sobre la venta del código fuente de Zeus, sobre botnets, sobre malware, phishing, o algo de game hacking que estuve revizando hace poco (saben que es un mundo donde se mezclan muchos conocimientos distintos?... en fin, ese tema será para mas adelante) tal vez les escriba sobre algunos temas en los que he andado metido en estos días (gestión de proyectos y cosas de esas)... así que creo que algo de volcado de memoria de mis épocas de auditor podría serles útil, antes que ya no lo recuerde mas... (como el "pensieve" en el que dumbledore guardaba sus memorias, pues el mío será este blog... jejeje). Y de verdad ando medio loco con esto de la estudiada, mas la chamba (el trabajo), mas las elecciones (que nos tienen locos a todos los peruanos), y un rompecabezas de 5000 piezas, que si no lo termino pronto, me sacan a mi o al rompecabezas de la casa (tengo secuestrada la mesa del comedor de la casa), y también mi oficina donde hago research, y como vivo en un departamento de 2 dormitorios, sólo queda la cocina y la sala libres, se imaginan que en casa no les hace mucha gracia no? jejeje...

En fin... retomando con nuestro tema, cuando se trata de un auditor de TI, en mi experiencia personal, la revisión que haga sobre la documentación, los procesos, los estándares, buenas prácticas de plataforma de seguridad, procesos de control de acceso, de ciclo de vida de desarrollo de software, y así todo lo que pueda ocurrirsele o toda referencua que pueda surgir, desde el primer día en que mandan su requerimiento formal de información al auditado, parte por lo general de un alcance mayor, y tiende a ser un soporte para una revisión mayor... (o al menos así creo que debería ser)

A que me refiero con esto, me refiero a que por lo general una auditoría de TI, va a ser un soporte a una auditoría contable, una auditoría de revisión de estados financieros (que podría ser sarbanes oaxley), una revisión de cumplimiento de PCI (Payment Card Industry, no vayan a pensar que de Peripheral Component Interconnect), o un análisis de brechas, GAP Analysis "como le dicen" (lease con voz de dady ricky de pataclaun, no me gustará el programa, pero su personaje es bastante pintoresco) ya sea de la ISO/IEC 27001, o de la NTP ISO/IEC 17799 (nuestra norma técnica peruana equivalente a lo que sería la ISO 27002), o una revisión para hipaa relacionado con la privacidad de la información en temas de salud (aunque a la fecha no aplica como una exigencia en muchos países latinoamericanos, el Perú no es una excepción), u otras de revisión de procesos de TI, que podría ser basada en Cobit, para evaluar el grado de madurez de los controles de seguridad, o podría ser basada en ITIL, para los temas de Gestión de TI, sin embargo, todas, o muchas de ellas, van a considerar el tema de la evaluación de vulnerabilidades, como un control realizado, o como una exigencia para el caso de muchos estándares.

Pues la revisión de los informes de seguridad, va a ser parte de la mayoría si no de todos los procesos de revisión antes mencionados, sin embargo, algo que debe quedar en claro para el auditado (a manera de defensa), en que dichas revisiones normalmente están acotadas, es decir, tienen un alcance finito, lo cual es lógico, ya que aplicar dichos estándares a toda la organización, si bien es el ideal, pero a veces tiende a ser complicado, sobretodo en organizaciones que tienen ya una forma de trabajo (y cuando digo forma de trabajo, me refiero tanto a los procedimientos, a los sistemas, como a la gente). Recuerden esto, cuando les vengan con una observación de por que no se aplicó el análisis a toda la organización, el alcance puede ser un salvavidas, o un veneno mortal.

Sobre esa base, digamos que lo primero va a ser, el tener claro el alcance de trabajo, esto tiende a ser útil para poder determinar los tiempos de ejecución, así como la cantidad de tareas y el tipo de profesionales, o el perfil que debe de tener el equipo o la persona a ejecutar las acciones, dimensionar las horas y el costo que implicará.

Luego como auditor, pensaría en algunas cosas, por ejemplo, tratando de pensar como el especialista que realizó la evaluación, sin perder mi objetividad de auditor, pensaría, en que procesos se vieron afectados, y de acuerdo a mi marco de trabajo o alcance(definido anteriormente) lo que debió pasar es que se identificaran los equipos que afectan a los procesos, la información, o los sistemas que están (cuando menos) directamente relacionados con mi alcance, y a partir de ahí debí hacer una evaluación, que debe ser estructurada y metodológica, para evaluar todos los sistemas bajo el mismo nivel de rigurosidad. Así no sucede que evalué mas un equipo, por que tenía mas vulnerabilidades, pero el otro que estaba mas difícil, casi ni lo toqué.

Pues partiendo desde esta "lógica", el informe debería tener el alcance definido, la metodología utilizada, la escala de medición (para medir que es alto, que es medio y que es bajo, por mencionar un formato de clasificación).

De ahí lo obvio que pensaría encontrar son las vulnerabilidades identificadas, las que deberían tener una explicación o una referencia que explique en que consisten, y luego la clasificación para cada una de ellas, de ahí, ya a gusto del especialista, la forma de agrupar la información, por equipo, por vulnerabilidad, por puerto, por criticidad, en fin, al final variará en mi opinión, de acuerdo a la facilidad o dificultad para analizar y procesar toda la información presentada.

Pues otro tema que considero que debería aparecer, es una evidencia que muestre que realmente existe la vulnerabilidad y no se trata de un falso positivo, y para terminar esta sección, esperaría la recomendación para su remediación.

Al final, un resúmen de lo identificado, y por ahí anexos de evidencia, a veces hasta incluyen anexos en CD's con la evidencia con los datos generados sin procesar, en fin, la presentación y las formas de aquí en adelante varían por muchas razones, las exigencias de la revisión, lo acordado con el cliente, lo contratado previamente, requerimientos legales, en fin.

Algunos preparan una presentación, con lo resaltante, y lo demás, lo incluyen en un grueso y denso informe con miles de páginas que esperamos todos (por el sufrimiento de tanto arbolito) que lo lean algún día y le hagan caso al mismo, conclusiones, y recomendaciones.

Bueno pues... eso es lo que esperaríamos encontrar creo yo en un informe de pentesting.

Pero la pregunta no ha sido respondida del todo. Y digo esto, por que considero que adicionalmente, hay cierta información que se encuentra necesariamente en el informe, pero es aquella a la que hay que prestarle atención, es decir, al seguimiento.

El realizar análisis de vulnerabilidades, es importante, creo yo, sin embargo tiene muchas variables, que hacen que dicho informe pueda ser mucho mas completo o cercano a la realidad, ya que considero que todo sistema tiende a ser vulnerable, la diferencia estará en cuanto tiempo es el que te toma vulnerarlo, es por ello que el hallazgo de las brechas de seguridad, dependerá mucho de la experiencia y capacidades del especialista que ejecute la evaluación. Es por ello que en lo personal como auditor, preferiría preocuparme, del seguimiento y la corrección de las vulnerabilidades, debilidades y amenazas, identificadas. Esto debido a que es necesario, no sólo conocer las falencias en materia de seguridad en nuestro sistema, si no que también es importante saber:

- Si dicha información ha sido atendida en el tiempo.
- Si se han tomado las medidas correctivas que eviten la recurrencia de vulnerabilidades en ese u otros sistemas.
- El uso de buenas prácticas para el desarrollo seguro, o para la corrección oportuna de las brechas identificadas.

Por otro lado, hacer un análisis histórico de informes previos con la intención de evidenciar la recurencia en las vulnerabilidades identificadas, también permite identificar si dichas mejoras, o correcciones, están siendo incluidas dentro de los estándares de seguridad de plataforma, o de desarrollo de aplicaciones seguras.

También es importante saber cuales fueron las pruebas realizadas, lo cual nos da una idea del tipo de trabajo que se realizó y cual fué su duración, ya que una evaluación de 40 horas (1 semana), 160 horas (1 mes) o una evaluación de 8 horas (un día) van a tener un alcance distinto, y un nivel distinto de profundidad para la identificación de vulnerabilidades. Existen muchas fuentes de vulnerabilidades conocidas que considero deberían ser evaluadas de manera obligatoria, por ejemplo, el Top Ten de OWASP es lo mínimo que debería de considerarse para la evaluación de vulnerabilidades en Web.

Adicionalmente, habrán casos en los que las vulnerabilidades son analizadas, pero por decisiones del negocio, se opta por no corregir la falencia de seguridad, sin embargo, esta decisión involucra un análisis que sustenta dicha decisión, este análisis debería ser la evidencia que sustente la no ejecución de correcciones en la seguridad. (Un análisis de riesgo sobre la vulnerabilidad, puede ser un muy buen sustento a manera de control compensatorio).

También puede suceder, que nos encontremos con casos en los que muchas vulnerabilidades aún no se encuentran corregidas, o "parchadas" debido a que la evaluación se realizó hace poco, y no ha habido tiempo suficiente para su corrección, o aún se encuentran evaluando si la corrección de seguridad no afectará a este u otros sistemas. Pues bien, lo que se esperaría tener es un plan de acción aprobado, o sustentos que demuestren las coordinaciones orientadas a corregir las falencias identificadas, es un buen punto de partida. Aunque ahí si pensaría en revisar con mayor detenimiento los informes anteriores, para verificar si hay vulnerabilidades recurrentes.

Este puede ser un buen sustento, y en todo caso, puede ser una observación o recomendación en caso de encontrarse fallas recurrentes.

Como ven hay muchas cosas que pueden ser obtenidas de dichos informes.

Bueno, espero que esta publicación pueda ser de ayuda para mis amigos auditores, (recuerden, no es que los auditores les tengan odio, son sólo negocios, y al final de cuentas son profesionales y es su trabajo).

Un abrazo, y estamos leyendonos.

4 comentarios:

Anónimo dijo...

Este blog es algo confuso.

Ing. Juan Pablo Quiñe dijo...

mmmm mi querido anónimo, que es lo que te parece confuso? de repente tienes alguna sugerencia que pueda servir para mejorarlo.

Rolyn dijo...

ta bacan el post pero es muy largo, un sugerencia de pata, dosifica, mandalo por partes.

Ing. Juan Pablo Quiñe dijo...

Se agradece la recomendaciòn... pero lo siento, lastimosamente no programo el tamaño de los posts, al final de cuentas, cuando tengo un tiempo en el día (o en el mes), me siento, y empiezo a escribir, y no paro hasta sentir que abarqué el tema en cuestión, si lo parto en partes, probablemente, pierda la idea principal en el limbo, en todo caso como pata, te sugiero leelo por partes ;)

Happy reading.

JP