Auditorías de Seguridad Informática - sergiob.org³n General de Servicios de Cómputo Académico...
Transcript of Auditorías de Seguridad Informática - sergiob.org³n General de Servicios de Cómputo Académico...
©Todos los derechos reservados 2010 Dirección de Telecomunicaciones Subdirección de Seguridad de la Información/UNAM-CERT
Auditorías de Seguridad Informática
CONTENIDO
1. Introducción .......................................................................................................................................... 5
Objetivo de la auditoría ............................................................................................................................ 5
Definiciones............................................................................................................................................... 6
Evaluación (Assessment) ....................................................................................................................... 6
Alcance (Scope) ..................................................................................................................................... 6
Objetivos ............................................................................................................................................... 6
Objetivo de las políticas ........................................................................................................................ 7
Controles ............................................................................................................................................... 7
No conformidades ................................................................................................................................. 8
Remediación ......................................................................................................................................... 8
Mitigación ............................................................................................................................................. 8
Causa raíz .............................................................................................................................................. 9
Politicas, estándares, mejores prácticas y procedimientos ...................................................................... 9
Baselines ............................................................................................................................................... 9
Checklists .............................................................................................................................................. 9
Políticas ............................................................................................................................................... 10
Procedimientos ................................................................................................................................... 10
El rol del equipo de auditoría .................................................................................................................. 10
Integrando un equipo de auditoría efectivo ........................................................................................... 10
Mantenimiento de la experiencia ........................................................................................................... 11
2. Proceso de Auditoría ........................................................................................................................... 11
Determinando qué auditar ..................................................................................................................... 11
Análisis de riesgos ................................................................................................................................... 12
Dirección General de Servicios de Cómputo Académico Subdirección de Seguridad de la Información / UNAM - CERT
Auditorías de Seguridad Informática
Etapas de una auditoría .......................................................................................................................... 19
3. Técnicas de auditoría .......................................................................................................................... 20
Auditoría de planes de continuidad del negocio y de recuperación de desastres ................................. 20
Auditoría de redes .................................................................................................................................. 22
Auditoría de redes inalámbricas ......................................................................................................... 22
Bluetooth ............................................................................................................................................ 22
Wireless ............................................................................................................................................... 23
Auditoría de aplicaciones ........................................................................................................................ 40
Pruebas de caja blanca ........................................................................................................................ 41
Pruebas de caja negra ......................................................................................................................... 42
Pruebas de caja gris ............................................................................................................................ 43
Auditoría de binarios ........................................................................................................................... 44
Auditoría de bases de datos.................................................................................................................... 46
Auditando Bases de DAtos .................................................................................................................. 49
Listeners de Oracle .............................................................................................................................. 50
Autenticación en Oracle ...................................................................................................................... 51
Autenticación en SQL Server ............................................................................................................... 51
Usuarios y Roles .................................................................................................................................. 52
Perfiles ................................................................................................................................................ 52
Privilegios ............................................................................................................................................ 53
Paquetes ............................................................................................................................................. 54
Cuentas por default ............................................................................................................................ 55
Contraseñas ........................................................................................................................................ 56
Respaldos ............................................................................................................................................ 56
Auditando la Base de Datos ................................................................................................................ 56
Dirección General de Servicios de Cómputo Académico Subdirección de Seguridad de la Información / UNAM - CERT
Auditorías de Seguridad Informática
Herramientas ...................................................................................................................................... 57
Otras aspectos a considerar ................................................................................................................ 57
Auditoría de Sistemas de Gestión de Seguridad de la Información (Según la serie ISO/IEC 27001:2005)
................................................................................................................................................................ 58
Etapas de auditoría ............................................................................................................................. 59
Tipos de auditoría ............................................................................................................................... 61
Certificación del SGSI 27001 ............................................................................................................... 63
Proceso de auditoría ........................................................................................................................... 67
Realizar las actividades de auditoría ................................................................................................... 71
Preparar, aprobar y distribuir el informe de auditoría ....................................................................... 86
Conducir el seguimiento de la auditoría ............................................................................................. 88
Dirección General de Servicios de Cómputo Académico Subdirección de Seguridad de la Información / UNAM - CERT
Auditorías de Seguridad Informática
1. INTRODUCCIÓN
La auditoría en general, es descrita como la función de medir algo en comparación con un estándar.
Mientras que los auditores de sistemas tienden a enfocarse en utilizar la auditoría para medir la
seguridad a lo largo del tiempo, en realidad la auditoría puede aplicarse a cualquier cosa.
Los tres lugares más efectivos para aplicar la auditoría en las tecnologías de la información son:
1. A nivel Políticas
2. A nivel Procedimiento
3. A nivel Sistema
Se puede llamar al nivel como nivel aplicación, sin embargo no significa software, si no el punto donde
se aplican las políticas y procedimientos.
Las auditorías son de varias formas y tamaños, entre las más comunes se encuentra la de alineación.
Una auditoría de alineación o cumplimiento consiste en medir que tan bien un sistema o proceso se
alinea con las políticas y/o procedimientos que han sido definidos en la organización. Una auditoría de
seguridad, es una auditoría más general utilizada para medir una política, procedimiento o la misma
auditoría en base a una mejor practica, para determinar si es necesaria una mejora en particular.
Una definición simple de auditoría es que la Auditoría contesta a la pregunta: ¿Cómo sabes si…?
Por ejemplo considere las siguientes preguntas por cada rubro:
Implementación de Política de Seguridad en su organización
o ¿Cómo sabe si es efectiva?
o ¿Cómo sabe si los empleados la siguen?
Instalación de nuevo firewall (o cualquier otro sistema)
o ¿Cómo sabe si realmente protege a la organización?
Como puede ver, no importa lo que una organización haga para protegerse, se debe de preguntar,
¿Cómo sabes si..?, y los auditores contestan esta pregunta por medio de la validación.
OBJETIVO DE LA AUDITORÍA
El principal objetivo del auditor es: Medir y reportar sobre el riesgo. El auditor ha sido autorizado por la
administración para realizar preguntas difíciles sobre la organización, en un esfuerzo para entender
mejor el cómo es que la organización funciona, y para identificar los riesgos que existen para la misión y
objetivos de la organización. Después de medir el riesgo, los auditores realizan un reporte sobre estos
riesgos, de manera que la administración pueda actuar.
Dirección General de Servicios de Cómputo Académico Subdirección de Seguridad de la Información / UNAM - CERT
Auditorías de Seguridad Informática
Un objetivo secundario del auditor, el cual no se muestra en la mayoría de la bibliografía, es reducir el
riesgo al incrementar la concientización. Una vez que el auditor identifica riesgo (alguna cosa que afecte
la misión y objetivos de la organización), el reporta a la administración de manera que estos puedan
actuar; en otras palabras, el auditor se apoya de la concientización de la administración para que los
riesgos puedan ser reducidos. De hecho, si la administración no quisiera reducir los riesgos, no tendrían
un auditor en primer instancia.
DEFINICIONES
Antes de adentrarnos en el tema de auditoría, repasaremos algunos de las definiciones con las cuales un
auditor debe estar familiarizado.
EVALUACIÓN (ASSESSMENT)
Una evaluación al contrario de una auditoría, es una medición arbitraria o subjetiva. Típicamente, se
utilizan evaluaciones para medir el cómo una auditoría alcanzo sus objetivos (en otras palabras, que tan
efectiva fue la auditoría), que tan bien se aseguro un sistema y como consecuencia, que (otra) cosa
podría salir mal.
Cada auditoría incluye recomendaciones de qué es lo que se debe hacer para mejorar el estado de
seguridad deseado de un sistema, sistemas o procesos. ¿Cómo logramos esto? Por medio de la
evaluación.
ALCANCE (SCOPE)
Antes de que una auditoría sea realizada, necesitamos identificar claramente qué es lo que vamos a
auditar. Esto es llamado el alcance de una auditoría o también llamada la entidad a auditar (Auditable
Entity).
Esencialmente el alcance es la definición de qué es de lo que vamos a ser responsables de auditar. Al
definir el alcance, al auditor debe trabajar de manera cercana con las personas que solicitaron la
auditoría, y el personal de seguridad informática de la organización. Estos individuos estarán en la mejor
posición para entender que objetivos buscan cumplir sus políticas y procedimientos, y que alcance las
medirá de una mejor manera.
OBJETIVOS
Existen 2 tipos de objetivos con los cuales un auditor debe estar familiarizado. La auditoría por sí misma
tiene un objetivo, mientras que las políticas, procedimientos y sistemas tienen objetivos también.
El objetivo de la auditoría es parte de lo que estamos definiendo en el alcance o en la entidad a auditar.
El objetivo es esencialmente lo que estamos buscando lograr o medir a través del proceso de auditoría.
Esto puede ser tan simple como un intento de medir si un sistema ha sido comprometido al comparar
Dirección General de Servicios de Cómputo Académico Subdirección de Seguridad de la Información / UNAM - CERT
Auditorías de Seguridad Informática
una configuración base conocida del sistema o tan complejo como medir que tan alineada esta una
organización a una serie de políticas y procedimientos.
OBJETIVO DE LAS POLÍTICAS
El objetivo de la política es simplemente lo que la política o procedimiento esta supuesto a cumplir o
lograr. Por ejemplo consideremos la siguiente política:
“Todos los usuarios deben autenticarse en un sistema con su propio nombre de usuario y contraseña”
¿Cuál es el objetivo de esta política?
Si analizamos esta política detenidamente, nos podremos dar cuenta que existen varios objetivos dentro
de ella. Primero, la política busca diferenciar a todos los usuarios en un sistema de manera única.
Segundo, esta política requiere que a todos los nuevos usuarios se les proporciones un nombre de
usuario y contraseña, en un tiempo considerable, debido a que, de manera implícita en el objetivo,
todos los usuarios deben tener un nombre de usuario y contraseña cuando lo necesiten.
Si estamos realizando una evaluación con una solución de análisis de vulnerabilidades, claramente
nuestro objetivo es identificar vulnerabilidades en la infraestructura de la organización.
Al identificar el alcance con objetivos claros es un paso muy importante que en la mayoría de las
ocasiones los auditores y otros profesionales de seguridad no le dan el tiempo adecuado. La definición
de los objetivos y alcance, no necesita tomar mucho tiempo, pero puede servir para proteger la
infraestructura a evaluar y al auditor mismo de problemas durante el proceso de auditoría.
CONTROLES
Desde una perspectiva de políticas y procedimientos, los controles son el “Como” la organización va a
cumplir con esos objetivos. Si los objetivos son el “Que”, los controles son el “Como”.
Considere la política del tema anterior:
“Todos los usuarios deben autenticarse en un sistema con su propio nombre de usuario y contraseña”
¿Qué controles pueden ayudarnos a cumplir con este objetivo?
Primero que nada, el tener un proceso de administración de usuarios adecuado no serviría como
control, porque este proceso incluiría procedimientos para obtener cuentas de usuario y contraseñas en
un periodo de tiempo aceptable para la organización. Podríamos encontrar durante la auditoría, que los
usuarios pueden utilizar otras cuentas de usuario para iniciar sesión. Un control adicional podría ser el
asegurar que los usuarios inicien sesión desde sus computadoras, utilizando algunas restricciones del
sistema operativo. Un control más estricto podría ser el uso de dispositivos como tarjetas inteligentes o
tokens para la autenticación. El control con un nivel de restricción más severo sería el uso de
dispositivos biométricos para que un usuario pueda iniciar sesión en un sistema remoto.
Dirección General de Servicios de Cómputo Académico Subdirección de Seguridad de la Información / UNAM - CERT
Auditorías de Seguridad Informática
Para generalizar nuestro ejemplo, considere el Active Directory de Microsoft Windows. El Controlador
de Dominio actúa como punto de control para asegurar el uso de un nombre de usuario y contraseña.
Control podría tener un segundo significado, podríamos en alguna ocasión referirnos a un “Control de
Auditoría”. En este caso, nos referimos a algo que utilizamos para medir el desempeño de un control
dentro de un sistema o procesos. En este caso, el control de auditoría sería la bitácora del controlador
de dominio configurado para registrar los inicios y cierres de sesión así como las fallas en la
autenticación.
NO CONFORMIDADES
Una no conformidad es simplemente algo que no cumplió los objetivos que fueron establecidos por
medio de políticas y procedimientos, y que fue identificado durante el proceso de auditoría. en nuestro
ejemplo anterior donde instalamos un controlador de dominio de Windows, como control para el uso de
usuario y contraseña que registra toda la actividad en una bitácora como un control de auditoría,
cuando realizamos la auditoría, descubrimos que alguien ha comprometido una contraseña, o que una
persona sigue utilizando la cuenta de otra persona. En ambos casos el controlador de dominio falla al
cumplir los objetivos que establecimos en la política, y será una no conformidad que se integrará en el
reporte final.
REMEDIACIÓN
Una vez que encontramos una no conformidad, el siguiente paso es dar una recomendación de alguna
forma de remediación. Si la no conformidad que ha sido identificada fue que las cuentas de usuario no
están siendo eliminadas cuando los empleados dejan de trabajar en la organización, la remediación será
remover estas cuentas. Aún cuando esto puede solucionar el problema, tenemos que ver más a fondo,
esto lo tocaremos en temas más adelante.
Las acciones que recomendemos para la remediación deberán estar basadas en las Mejores Practicas.
Seguramente se estará preguntando: ¿pero qué mejor practica?. En ocasiones, utilizaremos estándares,
o modelos de referencia internacional, o podríamos encontrarnos con que en las políticas o
procedimientos de la organización se hace referencia que mejor practica es la empleada en la misma. En
este caso, estos documentos podrán servirnos para identificar la remediación adecuada.
MITIGACIÓN
En ocasiones no será posible eliminar o remediar un problema. Tendremos que enfrentar el hecho y
admitir que no podremos eliminar un riesgo o amenaza en particular, debido a cómo la tecnología o
proceso es utilizada en la organización.
Cuando esto ocurre, debemos de mitigar el riesgo creado como consecuencia del uso de ese proceso o
tecnología en la organización.
Dirección General de Servicios de Cómputo Académico Subdirección de Seguridad de la Información / UNAM - CERT
Auditorías de Seguridad Informática
CAUSA RAÍZ
Una parte importante de la auditoría es identificar la causa raíz de las no conformidades. Cuando se
trate de la causa raíz, nos enfocaremos en lo que realmente sale mal y no en lo que significa la no
conformidad. Es como si tratáramos con la enfermedad y no con el síntoma. Si llegamos al doctor con
una fractura en el brazo, no nos recetarán una pastilla para el dolor, si no que el doctor revisará el brazo
para identificar la gravedad de la fractura, de lo contrario nunca identificará la causa raíz del dolor.
POLITICAS, ESTÁNDARES, MEJORES PRÁCTICAS Y PROCEDIMIENTOS
En algunas organizaciones, el auditor será responsable de medir las conformidades o reportar el riesgo
sin que la organización especifique un “estándar” en particular, más allá de sus políticas y
procedimientos. Los estándares son muy populares dentro de alunas organizaciones porque pareciera
que todo el trabajo duro ya esta hecho, y lo único que resta es implementar algunos controles para estar
seguros. Para otras, los estándares son vistos como obstáculos monstruosos que deben ser adoptados
debido a regulaciones del gobierno. Independientemente del porque una organización necesita o quiere
implementar un estándar, existen varios de ellos que debemos preguntarnos cual es el mejor para
nosotros.
BASELINES
Uno de los mejores métodos de auditoría es mediante el uso de baselines. Un baseline es un estado
conocido de un sistema. Este estado debe ser seguro, de manera que el auditor pueda confiar en la
integridad del mismo. A lo largo del tiempo el auditor mide que tanto difiere la configuración del
sistema con el baseline inicial.
CHECKLISTS
Los estándares son una excelente referencia para los checklist. Las mejores prácticas o estándares
generalmente están organizados por una lista de controles que deberían ser implementados para
proveer seguridad a la organización. En este caso, ¿Por qué simplemente creamos una lista maestra de
controles basada en diferentes estándares?
Este escenario es apropiado para cuando el auditor busca alinear una organización con un estándar. El
estándar mismo se convierte en un checklist de alto nivel.
Una de las principales herramientas del auditor es el checklist. En ocasiones algunas organizaciones
pueden tener checklist que sufren del mismo problema que las políticas, son muy vagas, sin alcance y no
están basadas en alguna referencia internacional.
Dirección General de Servicios de Cómputo Académico Subdirección de Seguridad de la Información / UNAM - CERT
Auditorías de Seguridad Informática
POLÍTICAS
Los auditores frecuentemente se ven envueltos en la creación y definición de políticas, su contribución
al proceso de creación de políticas es muy importante. Los auditores pueden ayudar a identificar
políticas ambiguas o sin sentido, e influir en la dirección para rechazarlas antes de que se conviertan en
un documento oficial.
PROCEDIMIENTOS
Mientras que una política responde el “Qué” y en ocasiones el “Por qué” hacer algo, el procedimiento se
enfocara en el “Cómo” hacerlo.
Algunas palabras dentro de las políticas o procedimientos como “Debería”, “Podría”, etc., dan pauta a la
interpretación variada de las personas. En ocasiones las organizaciones al documentar sus políticas
prefiere evitar la palabra “Debe” para no ofender a alguien, por lo que usa palabras ambiguas como las
que mencionamos al inicio. Cuando utilizamos palabras como “Será”, “Deberá” o “Debe”.
EL ROL DEL EQUIPO DE AUDITORÍA
El auditor ha sido autorizado por la administración para realizar preguntas difíciles sobre la organización,
en un esfuerzo para entender mejor el funcionamiento interno de la organización, y para identificar los
riesgos que existen para la misión y objetivos de la misma. Sin embargo, es importante que el auditor se
comprometa a crear conciencia dentro de la organización y sobre todo con la administración para que
esta actúe.
INTEGRANDO UN EQUIPO DE AUDITORÍA EFECTIVO
La organización de un equipo auditor requiere de un orden jerárquico que garantice el flujo de la
información de conformidad con la autoridad y responsabilidad asignados a todos y cada uno de sus
integrantes.
Esta división del trabajo posibilita que los miembros del equipo en sus diferentes posiciones, puedan
emplear correctamente su potencial y propicia la apropiada conjunción de conocimientos y criterios
para aplicar la auditoría de manera objetiva y sistemática, conforme a las circunstancias que prevalecen
en cada etapa, reduciendo el margen de error y el riesgo de ocasionar retrasos innecesarios.
La formación del equipo tiene que llevarse a cabo de acuerdo con la naturaleza, alcance, objetivos y
estrategia de la auditoría.
A partir de esto, es necesario que las personas, técnicos y profesionales que se incorporen, tengan una
clara definición del papel que se les ha encomendado, por ello es imprescindible determinar la función
que desempeñarán en el estudio.
Dirección General de Servicios de Cómputo Académico Subdirección de Seguridad de la Información / UNAM - CERT
Auditorías de Seguridad Informática
La división del trabajo en relación con las funciones que tienen que cumplir, se lleva a cabo
considerando los siguientes puestos:
Coordinador General. Como responsable de la auditoria es necesario que sea poseedor de una
gran experiencia en la materia, la cual puede derivarse de su formación académica y/o
profesional, así como de su trayectoria y orientación personal.
Líder de proyecto. En su carácter de enlace entre el coordinador general, el personal destacado
en la auditoria, la organización y entorno, el líder representa el eslabón clave para que los
objetivos, programa y estrategias propuestas sean susceptibles de alcanzarse.
Asistente o analista de proyecto. Como personal de primera línea, es el responsable de atender
directamente a todo el personal que, de una u otra manera, interviene en la auditoria, además
de ser quien va a manejar directamente los papeles de trabajo que contienen los hallazgos,
evidencias y observaciones necesarios para derivar los criterios y propuestas que consoliden la
aplicación de la auditoria.
MANTENIMIENTO DE LA EXPERIENCIA
Las Tecnologías de Información están cambiando constantemente. Por lo tanto, es importante que los
auditores mantengan su competencia por medio de la actualización de sus habilidades actuales y que
obtengan capacitación sobre nuevas técnicas de auditoría y áreas de tecnología. El auditor debe de
mantener su competencia técnica a través de una educación profesional continua.
Durante la planificación de la auditoría, se deben de tomar en cuenta las habilidades y los conocimientos
de los auditores, y se asigne al personal para tareas específicas de auditoría.
2. PROCESO DE AUDITORÍA
Uno de los problemas de la auditoría es que los expertos en la industria les piden a los profesionales el
realizar algo, pero pocas veces les dicen cómo. Aquí revisaremos el proceso de auditoría paso a paso.
DETERMINANDO QUÉ AUDITAR
Comúnmente el alcance de la auditoría define como el ¿Qué? de una auditoría. Cuando estamos
definiendo nuestro alcance, no debemos distraernos con el ¿Cómo?. El cómo, o más específicamente,
cómo vamos a medir o auditar algo, es el detalle de algo que haremos en el futuro en nuestro proceso
de auditoría. El auditor realizará una investigación después de definir qué es lo que va a auditar, para
determinar el cómo (y en ocasiones averiguar si es posible) auditar lo contenido en el alcance.
El qué auditar vs el cómo auditar
Supongamos que tenemos que auditar el firewall de una organización, ¿qué harías? Y ¿por qué quieres
hacer eso?.
Dirección General de Servicios de Cómputo Académico Subdirección de Seguridad de la Información / UNAM - CERT
Auditorías de Seguridad Informática
Suena razonable el decir que al auditar un firewall, debemos determinar si el firewall esta protegiendo a
la organización de ataques o tráfico malicioso. Podemos hacer un mal trabajo, si pensamos en el ¿cómo?
de manera muy temprana. La mayoría de los auditores dirán lo siguiente:
“Para cumplir con los objetivos de mi auditoría de este firewall, voy a revisar las reglas de filtrado para
asegurarme que estén bloqueando el tráfico malicioso, anómalo o algún ataque”.
Esto suena bien, pero no es suficiente.
Si el auditor simplemente revisa las reglas del firewall, realmente no sabrá si el firewall esta protegiendo
o no a la organización. Lo único que sabrá, será si las reglas listadas por el firewall están correctas o no.
¿Es posible que el firewall permita pasar más tráfico del que sus reglas dicen? Lamentablemente la
respuesta es si!!!!. Por lo tanto, si solo revisamos las reglas, solo sabremos qué es lo que hace el firewall
en papel. ¿Cómo sabemos que esta configuración cumple con las políticas de la organización? Tenemos
que validar el firewall.
Cuando decimos que un firewall ha sido “validado” estamos diciendo que, no sólo revisamos las reglas
del firewall en busca de algún error, si no también hicimos pruebas sobre el firewall, enviando tráfico
valido y no valido a través del firewall para validar qué tipo de tráfico realmente esta dejando pasar.
El punto es el siguiente: si consideramos el ¿Cómo? muy temprano como auditores, cabe la posibilidad
de que nos encontremos con un problema, el cual no sabremos resolver (p.e. auditar algún sistema del
cual no tenemos experiencia). En casos como éste, es muy común que en lugar de encontrar una forma
de medir el ¿Qué?, cambiamos el ¿Qué? por algo que sepamos “Cómo” auditar.
Mientras que esto nos permitirá terminar la auditoría, es muy peligroso. Cuando cambiamos el “Qué” es
muy posible que nos estemos cegando a nosotros mismos de los riesgos que buscamos medir o verificar
desde un inicio.
La moraleja de esta historia es:
“Siempre averigua el “Qué” primero, y preocúpate por el “Cómo” después”
Otro ejemplo cuando el alcance y los objetivos han sido mal establecidos, será aquel análisis de
vulnerabilidades que consideramos unas páginas atrás. Si tu objetivo es identificar vulnerabilidades,
entonces ir un paso adelante e intentar explotar estas vulnerabilidades estará más allá de nuestro
alcance, y podría ponernos en una posición muy complicada. Por otro lado, si nuestro objetivo es
identificar vulnerabilidades y lo único que hacemos es enumerar los equipos de la red, claramente no
estamos cumpliendo con los objetivos de la auditoría, dado que nuestros criterios de verificación
fallaron al cumplir con los objetivos, y requieren ser ajustados.
ANÁLISIS DE RIESGOS
Dirección General de Servicios de Cómputo Académico Subdirección de Seguridad de la Información / UNAM - CERT
Auditorías de Seguridad Informática
La información de una organización, y los sistemas, aplicaciones y redes que la respaldan son activos importantes. La confidencialidad, integridad y disponibilidad de los activos puede ser esencial para mantener la ventaja competitiva, flujo efectivo, rentabilidad, cumplimiento legal y la imagen de una organización. Los sistemas, aplicaciones y redes de una organización pueden ser el objetivo de una variedad de amenazas serias, incluyendo fraude cibernético, espionaje, sabotaje, vandalismo y otras fuentes de fallas o desastres. Los métodos y técnicas utilizados para el análisis y evaluación de riesgos aplican a sistemas de gestión de seguridad de la información, sistemas e instalaciones de información específica pero también pueden dirigirse a componentes o servicios individuales de sistemas cuando es práctico, realista y útil. El análisis y evaluación de riesgo incluye la consideración sistemática de lo siguiente:
a) Consecuencia: se refiere al daño comercial que podría resultar de una violación importante de la seguridad de la información, tomando en cuenta las consecuencias potenciales de pérdida o falla de la confidencialidad, integridad y disponibilidad de la información.
b) Probabilidad: consiste en la probabilidad realista de que ocurra la mencionada violación a la luz de las amenazas, vulnerabilidades y controles en vigor
El proceso de análisis y evaluación de riesgos incluye:
I. La selección de un método de análisis y evaluación de riesgo el cual deberá ser adecuada para los requisitos identificados de seguridad de la información, legales y regulatorios.
II. Determinación de los criterios determinantes para aceptar los riesgos e identificar los niveles aceptables de riesgo.
III. Identificación, análisis evaluación de los riesgos. IV. Evaluación de opciones para el tratamiento del riesgo, selección de objetivos de control y
controles para reducir los riesgos a niveles aceptables.
El resultado de un análisis y evaluación de riesgos contribuye para que la organización pueda guiar y determinar las acciones y prioridades adecuadas para el tratamiento con el fin de gestionar los riesgos a la seguridad de la información. Un análisis y evaluación de riesgo depende de los siguientes factores:
- La naturaleza de la información y sistemas de la empresa. - El objetivo comercial para el cual se utiliza la información. - El entorno en el cual se utiliza y opera el sistema. - La protección que proporcionan los controles establecidos.
La figura 2.1 ilustra el proceso de análisis y evaluación del riesgo:
Dirección General de Servicios de Cómputo Académico Subdirección de Seguridad de la Información / UNAM - CERT
Auditorías de Seguridad Informática
a) Caracterización del sistema:
En la evaluación de riesgos para un sistema de TI, el primer paso es definir el alcance. En este paso, los límites del sistema de TI son identificados, junto con los recursos y la información que constituyen el sistema. La caracterización de un sistema de TI establece el alcance del esfuerzo de evaluación de riesgos, delinea la autorización de funcionamiento (o acreditación) fronteras, y proporciona información (por ejemplo, el hardware, software, conectividad del sistema y la división responsable o personal de apoyo) esenciales para la definición del riesgo.
Figura 2. 1 Proceso de análisis y evaluación del riesgo.
Dirección General de Servicios de Cómputo Académico Subdirección de Seguridad de la Información / UNAM - CERT
Auditorías de Seguridad Informática
b) Identificación de las amenazas:
Una amenaza es la posibilidad de aprovechar una vulnerabilidad para causar algún daño. Una
vulnerabilidad es una debilidad que puede ser explotada accidental o intencionalmente. Para
determinar la probabilidad de una amenaza, se debe considerar la fuente de amenaza, los
posibles puntos vulnerables y los controles existentes.
El objetivo de este paso es identificar las fuentes potenciales de amenaza, así como la
identificación de las amenazas aplicables al activo en cuestión.
c) Identificación de las vulnerabilidades:
El análisis de la amenaza a un sistema de TI debe incluir un análisis de las vulnerabilidades
asociadas con el entorno del sistema. El objetivo de este paso es desarrollar una lista de las
vulnerabilidades del sistema (defectos o puntos débiles) que podrían ser explotados por las
fuentes potenciales de amenaza.
d) Análisis de control :
El objetivo de este paso es analizar los controles que se han implementado, o están previstos
para su aplicación, por la organización para minimizar o eliminar la posibilidad (o probabilidad)
de que una amenaza aproveche una vulnerabilidad y se afecten activos de la organización.
e) Determinación de la probabilidad:
En esta etapa se determina cual es la probabilidad de que una amenaza aproveche una
vulnerabilidad y como consecuencia se afecten los activos de la organización.
Para la determinación de la probabilidad se deberán considerar:
Motivo y capacidad de la fuente de amenaza
La naturaleza de la vulnerabilidad
Existencia y eficacia de los controles actuales
La probabilidad que una vulnerabilidad potencial podría ser aprovechada por una fuente de
amenaza puede ser descrita como alta, media o baja.
f) Análisis del impacto:
La mejor forma de cuantificar el nivel de riesgo es determinando los efectos adversos
resultantes por la explotación de la vulnerabilidad. Antes de dar inicio al análisis de impacto es
necesario obtener información relacionada con la misión del activo dentro del proceso, que
sistemas o información crítica es utilizada y el grado de sensibilidad de la misma.
Dirección General de Servicios de Cómputo Académico Subdirección de Seguridad de la Información / UNAM - CERT
Auditorías de Seguridad Informática
g) Determinación del riesgo:
El objetivo de este paso es evaluar el nivel de riesgo una vez identificada las amenazas y las
vulnerabilidades. La determinación del riesgo para una particular amenaza/vulnerabilidad puede
ser expresada en función de:
- La probabilidad de que una amenaza pueda aprovechar una vulnerabilidad.
- La magnitud del impacto de que una amenaza haya aprovechado una vulnerabilidad y el
ataque haya resultado exitoso.
- La efectividad de los controles existentes para reducir o eliminar el riesgo.
h) Recomendaciones de control:
Durante éste paso del proceso, se proporcionan los controles que podrían mitigar o eliminar los
riesgos identificados y que puedan afectar la operación de la organización. El objetivo de los
controles se recomienda para reducir el nivel de riesgo para el sistema de TI y sus datos a un
nivel aceptable. Los siguientes factores deben ser considerados en la recomendación de los
controles y las soluciones alternativas para minimizar o eliminar los riesgos identificados:
Eficacia de las opciones recomendadas (por ejemplo, la compatibilidad del sistema)
Legislación y regulación.
Política de la organización.
Impacto operativo.
Seguridad y fiabilidad.
i) Documentación de resultados:
Una vez que la evaluación del riesgo ha sido completado (amenazas y vulnerabilidades
identificadas, los riesgos evaluados y los controles identificados), los resultados deben estar
documentados en un informe.
Un informe de evaluación de riesgos es un documento de gestión que ayuda a la alta dirección,
los propietarios de la misión a tomar decisiones sobre la política, los procedimientos, el
presupuesto y los cambios requeridos.
Dirección General de Servicios de Cómputo Académico Subdirección de Seguridad de la Información / UNAM - CERT
Auditorías de Seguridad Informática
Actualmente existen numerosas metodologías y herramientas para la gestión del riesgo tales como las
que se muestran en la figura 2.2 y se describen en la tabla 2.1:
Figura 2. 2 Metodologías y herramientas para la gestión del riesgo.
METODOLOGÍA / HERRAMIENTA
DESCRIPCIÓN
OCTAVE Operationally Critical Threat, Asset, and Vulnerability Evaluation) El Software Engineering Institute (SEI) de la Carnegie Mellon University, desarrolló OCTAVE. El objetivo principal en el desarrollo de OCTAVE es ayudar a las organizaciones a mejorar su capacidad de gestión y protegerse de los riesgos de seguridad de la información.
Metodología del NIST Metodología del National Institute of Standards & Technology Publicación especial del NIST (SP) 800-30, Guía de Gestión de riesgos de los Sistemas de Tecnología del Gobierno Federal de EU. Esta metodología está destinada principalmente a ser de carácter cualitativo y se basa en información proporcionada por analistas de seguridad especializados que trabajan con los propietarios de redes y expertos técnicos para identificar a fondo, evaluar y
Dirección General de Servicios de Cómputo Académico Subdirección de Seguridad de la Información / UNAM - CERT
Auditorías de Seguridad Informática
gestionar el riesgo en los sistemas informáticos. La metodología del NIST consiste en 9 pasos:
1. Caracterización del sistema 2. Identificación de la amenaza 3. Identificación de vulnerabilidades 4. Análisis de control 5. Determinación de la probabilidad 6. Análisis del impacto 7. Determinación del riesgo 8. Recomendaciones de control 9. Documentación de resultados
FRAP Facilitated Risk Assessment Process FRAP es la creación de Thomas Peltier. Se basa en la aplicación de técnicas de gestión de riesgos de una manera altamente rentable. FRAP usa metodologías formales cualitativas de análisis de riesgos utilizando análisis de vulnerabilidad, análisis del impacto del riesgo, análisis de amenazas y cuestionarios.
COBRA Consultative, Objective and Bi-functional Risk Analysis El proceso fue creado originalmente por C & A Systems Security Ltd. en 1991. Éste se realiza de la forma que la evaluación del riesgo es una cuestión empresarial, más que una cuestión técnica. Se trata de herramientas que se pueden comprar y luego ser utilizadas para realizar la auto-evaluaciones de riesgo, y apelando a los conocimientos de expertos integrados en las herramientas. Las bases de conocimiento principales son:
• Seguridad Informática (o por defecto) • Riesgo Operacional • Nivel de "riesgo ligero" o "alto riesgo" • e-Security
Risk Watch Risk Watch es una herramienta que utiliza una base de datos de conocimiento experto para guiar al usuario a través de una evaluación de riesgos y proporcionar informes sobre el cumplimiento, así como asesoramiento sobre la gestión de los riesgos. Risk Watch incluye información estadística para apoyar la evaluación cuantitativa del riesgo, lo que permite al usuario mostrar el ROI de varias estrategias. Risk Watch tiene varios productos, cada uno centrado a lo largo de diferentes necesidades de cumplimiento. Hay productos basados en estándares del NIST (gobierno de EU.), ISO 17799, HIPAA y estándares de institución financiera (Gramm Leach Bliley, California SB 1386 (normas de Robo de Identidad), Normas de Instalaciones de acceso y las Normas de Sistemas de Información FFIEC).
Tabla 2. 1 Metodología / herramientas análisis de riesgo
Dirección General de Servicios de Cómputo Académico Subdirección de Seguridad de la Información / UNAM - CERT
Auditorías de Seguridad Informática
ETAPAS DE UNA AUDITORÍA
Una metodología de auditoría es un conjunto de procedimientos documentados de auditoría, diseñados
para alcanzar los objetivos de auditoría planificados. Una metodología de auditoría debe ser establecida
y aprobada por la gerencia de auditoría para lograr consistencia en el enfoque de la misma. Esta
metodología se debe formalizar y comunicar a todo el personal de auditoría.
El auditor generalmente seguirá un curso de acción, pasos secuenciales del programa de auditoría para
obtener un entendimiento de la entidad que esta auditando. A continuación se enumeran los pasos de
una auditoría típica:
Fases de la auditoría Descripción
Sujeto de auditoría Identificar el área que será auditada
Objeto de auditoría Identificar el propósito de la auditoría. por ejemplo, un objetivo podría ser determinar si los cambios del código fuente del programa ocurren en un ambiente bien definido y controlado.
Alcance de auditoría Identificar los sistemas, funciones o unidades específicos de la organización que serán incluidos en la revisión.
Planificación de preauditoría Identificar habilidades y recursos técnicos necesarios.
Identificar las fuentes de información para prueba o revisión tales como flujogramas, políticas, estándares, procedimientos y papeles de trabajo de auditorías anteriores.
Identificar las localidades o instalaciones que serán auditadas.
Procedimientos de auditoría y pasos para la recolección de datos
Identificar y seleccionar el enfoque de auditoría para verificar y comprobar los controles.
Identificar una lista de individuos que serán entrevistados.
Identificar y obtener las políticas, estándares y directrices departamentales para realizar la revisión.
Desarrollar herramientas y metodología de auditoría para probar y verificar el control.
Procedimientos para evaluar los resultados de la prueba o la revisión
Especifico de la organización.
Procedimientos para las comunicaciones con la gerencia
Especifico de la organización.
Preparación del reporte de auditoría Identificar los procedimientos de seguimiento de la revisión.
Dirección General de Servicios de Cómputo Académico Subdirección de Seguridad de la Información / UNAM - CERT
Auditorías de Seguridad Informática
Identificar los procedimientos para evaluar/Probar la eficiencia y efectividad operacional.
Identificar los procedimientos para probar los controles.
Revisar y evaluar la calidad de los documentos, políticas y procedimientos.
3. TÉCNICAS DE AUDITORÍA
A continuación se describen algunas técnicas de auditoría para una organización típica.
AUDITORÍA DE PLANES DE CONTINUIDAD DEL NEGOCIO Y DE RECUPERACIÓN DE
DESASTRES
a) Plan de continuidad:
El objetivo de un plan de continuidad de negocio (BCP por sus siglas en inglés Business Continuity Plan) es coordinar la recuperación de las funciones críticas de la organización en caso de que se presente la interrupción de procesos o alguna contingencia. Esto puede incluir contingencias de corto y largo plazo, tales como incendios, inundaciones, terremotos, explosiones y otros desastres naturales (considerados en el Plan de Recuperación de Desastres) o causados por el hombre como huelgas, terrorismo, además de la suspensión de actividades por periodo vacacional. Las prioridades en una contingencia son:
1. Garantizar la seguridad de los empleados y visitantes a las instalaciones. 2. Mitigar los riesgos o limitar el daño que las amenazas puedan causar. 3. Tener planes y procedimientos documentados para garantizar que se ejecuten de manera rápida
y efectiva las estrategias de recuperación de los procesos críticos de la organización.
En caso de que ocurra una contingencia que interfiera con el funcionamiento de la organización, éste
plan va a ser utilizado por las personas responsables de coordinar las acciones necesarias para la
recuperación de las actividades en las áreas respectivas. El plan deberá estar diseñado para contener, o
bien como referencia de lo que podría ser necesario saber en el momento de recuperación.
Puntos importantes que debe contener un Plan de Continuidad del Negocio:
Identificar la misión y las funciones críticas del negocio.
Identificar los recursos que soportan las funciones críticas identificadas.
Identificación de las posibles acciones.
Selección de las estrategias que serán incluidas en el plan de continuidad.
La implementación de las estrategias de para las contingencias.
Realizar pruebas y evaluaciones de la efectividad de las estrategias establecidas.
Dirección General de Servicios de Cómputo Académico Subdirección de Seguridad de la Información / UNAM - CERT
Auditorías de Seguridad Informática
Plan de recuperación de desastres
El Plan de Recuperación de Desastres (DRP por sus siglas en inglés Disaster Recovery Plan) ofrece un
estado de disponibilidad de los sistemas y recursos permitiendo que el personal pueda responder ante
la ocurrencia de algún desastre, definiendo éste término como cualquier evento que pueda causar una
interrupción significativa en las capacidades de procesamiento operacional y/o computacional por un
periodo de tiempo, el cual afecte la operación de la organización.
El Plan de Recuperación de Desastres debe desarrollarse para lograr los siguientes objetivos:
1) Limita la magnitud de cualquier pérdida mediante la reducción del tiempo de interrupción
de los servicios y aplicaciones críticas.
2) Evaluar los daños, su reparación y dar inicio a las acciones requeridas para la recuperación
de las actividades, así como la adecuación del sitio alterno.
3) Recuperar los datos y la información imprescindible para el funcionamiento de las
aplicaciones crítico.
4) Administrar la operación de recuperación de una manera organizada y eficaz.
5) Preparar al personal de tecnología para responder con eficacia ante una situación de
desastre para actuar sobre el proceso de recuperación.
De ésta forma la organización tiene la responsabilidad de responder a cualquier interrupción a corto o
largo plazo de sus servicios, razón por la cual el desarrollo, documentación e implementación del Plan de
Recuperación de Desastres, permitirá la restauración de la disponibilidad de las aplicaciones críticas en
forma oportuna y organizada ante una situación de desastre que afecte las instalaciones y recursos con
los que opera la organización.
Puntos importantes que debe incluir un Plan de Recuperación de Desastres:
Propósito.
Alcance.
Responsabilidades.
Distribución.
Equipos que intervienen en la recuperación y las responsabilidades asociadas.
Descripción de las acciones a realizar ante una situación de desastre.
Escenarios de recuperación (interrupción prolongada de electricidad, inundación,
sismo/terremoto, incendio, desastre total).
Descripción del sitio alterno (en caso de que la organización cuente con ello).
Directorios (con la información de todo el personal).
Inventarios de la organización.
Generally Accepted Principles and Practices for Securing Information Technology Systems
http://csrc.nist.gov/publications/nistpubs/800-14/800-14.pdf
Dirección General de Servicios de Cómputo Académico Subdirección de Seguridad de la Información / UNAM - CERT
Auditorías de Seguridad Informática
An Introduction to Computer Security:The NIST Handbook
http://csrc.nist.gov/publications/nistpubs/800-12/handbook.pdf
Estándar ISO/IEC 27001
http://delivery.acm.org/10.1145/80000/78975/p652-
rohde.pdf?key1=78975&key2=6936314721&coll=GUIDE&dl=GUIDE&CFID=90681242&CFTOKEN=4903647
0
AUDITORÍA DE REDES
La diferencia entre un hacker y un consultor de seguridad son los permisos. Antes de iniciar cualquier
escaneo o pruebas de vulnerabilidades es necesario solicitar permiso de algún jefe superior. Identificar
los tipos de escaneos se realizarán además del tipo de información que se estará buscando y por último
las fechas programadas para ejecutar las pruebas. Un permiso por escrito protege a la compañía y al
auditor.
Es importante definir además el rango de dispositivos que serán verificados. Además es necesario
considerar que las pruebas que se realicen sean fuera de los horarios de oficina pues la falta de algún
servicio de red puede repercutir en la producción de la empresa.
AUDITORÍA DE REDES INALÁMBRICAS
De manera general cuando se realizará una auditoría en redes inalámbricas se inicia identificando los
dispositivos móviles. En muchas organizaciones se hace especial énfasis en los Access Point (APs). Sin
embargo, es necesario considerar otras redes inalámbricas como el Bluetooth, en este curso no se
profundiza en esta tecnología y hace un mayor énfasis en la auditoría de los APs, sin embargo, es
importante tener en mente nuevas tecnologías, las cuales su uso se incrementa día con día.
Se mostrarán algunas herramientas que ayudarán a realizar auditorías en redes inalámbricas.
Posteriormente basado en la auditoria es necesario realizar recomendaciones o acciones para la
mitigación de vulnerabilidades.
Es muy importante tener disponible en todo momento un inventario de APs autorizados, ya que en las
redes inalámbricas un usuario puede instalar y configurar un Access Point con lo que usuarios externos
pueden tener un potencial acceso a los recursos de la red corporativa.
BLUETOOTH
Bluetooth fue diseñado para un rango de alcance corto, las aplicaciones que utilizan Bluetooth a su vez
requieren un ancho de banda muy pequeño. Por ejemplo, esta tecnología puede ser usada fácilmente
para remplazar todos los cables en un escritorio, conectando el teclado, mouse, PDAs, bocinas y otras
cosas. La velocidad de transferencia del Bluetooth es muy baja (aproximadamente 725 Kb/s), lo que la
hace una opción muy pobre que pueda golpear la infraestructura de red. Aún así Bluetooth puede
contener información crítica, y por lo tanto, es necesario ser conscientes con respecto a su seguridad.
Dirección General de Servicios de Cómputo Académico Subdirección de Seguridad de la Información / UNAM - CERT
Auditorías de Seguridad Informática
Para realizar las pruebas y evaluaciones es necesario un equipo de cómputo, preferiblemente con Linux
que tenga el soporte Bluez y un dispositivo Bluetooth. El primero paso es identificar los dispositivos,
visibles y no visibles. Investigar las características de seguridad de cada dispositivo. En el sitio
http://www.betaversion.net/btdsd/ contiene una base de datos de seguridad de dispositivos Bluetooth
un poco anticuada pero puede servir para buscar las características de los dispositivos encontrados.
Una de las grandes preocupaciones hoy en día en los dispositivos Bluetooth es lo fácil que pueden ser
lanzados ataques de denegación de servicio (DoS). Algunos ataques conocidos son los siguientes:
Bluejacking. Es el envío de mensajes masivos a un objetivo
Bluesnarfing. Es el robo de información en teléfonos. Si un teléfono con Bluetooth es
descubierto por un atacante dentro de un rango apropiado (10 metros o menos para
dispositivos de Clase 2 y 3), el atacante puede crear una conexión. Esto le permite descargar
información como puede ser el calendario y la lista de contactos guardados en el dispositivo
móvil así como también las fotos de los igualmente pueden ser descargadas. Lo difícil del
Bluesnarfing es que el intruso debe estar a lo más a 10 metros de distancia del objetivo por un
periodo de tiempo para obtener los datos, pueden ser un par de minutos. La recomendación
para evitar este tipo de ataques es configurar el dispositivo como “no visible” (undiscoverable) o
apagar completamente el Bluetooth.
A continuación se mencionan las herramientas más populares para realizar pruebas de auditoría en
dispositivos con Bluetooth.
Bluez. El proyecto Bluez mantiene la implementación de las especificaciones de los estándares
en dispositivos inalámbricos Bluetooth para Linux.
OpenOBEX. Es una implementación de código libre del protocolo OBEX (Object Exchange) como
el proyecto lo explica, “OBEX es un protocolo de sesión que puede describirse como un
protocolo binario de HTTP”. OBEX es utilizado en redes Ad-hoc para intercambiar objetos como
archivos, imágenes, entradas de calendario (vCal), tarjetas de negocios (vCard), etc.
Redfang. Encuentra dispositivos Bluetooth que estén como no visibles.
Bluesniff. Redfang y Bluesniff pueden ser usados para escuchar conversaciones en dispositivos
Bluetooth.
Btscanner. Es una herramienta que extrae información de los dispositivos Bluetooth, siempre y
cuando no haya una autenticación de par (cuando dos dispositivos Bluetooth solicitan la misma
clave para realizar una conexión).
WIRELESS
Existen dos caminos para realizar una auditoría en los access points disponibles. Se podría hacer del lado
inalámbrico, esto consistiría en caminar sobre todo el entorno e identificar cualquier dispositivo
Dirección General de Servicios de Cómputo Académico Subdirección de Seguridad de la Información / UNAM - CERT
Auditorías de Seguridad Informática
inalámbrico disponible. Herramientas como NetStumbler y Kismet pueden ser usadas para este tipo de
evaluación. Otra opción es del lado de los cables o alámbrico, para este caso Nessus podría ser muy útil.
Nessus tiene un grupo de plugins conocidos como “General” y “Misc” dichos plugins contienen
herramientas para auditar Access Points. Uno de los plugins más útiles para dispositivos inalámbricos es
el 11026 llamado “Access Point Detection” el cual es utilizado para identificar APs. Nessus puede ser
usado para identificar access points inalámbricos desde el lado alámbrico. Existen cuatro técnicas
diferentes que Nessus usa durante este proceso. Si uno de esos métodos funciona, los demás no son
ejecutados.
El primero método es el OS fingerprinting. Nessus se apoya de las capacidades de identificación del
Sistema Operativo proporcionado por nmap para identificar APs. El segundo método es por medio de la
comunicación HTTP de los APs, muchos de los APs son configurados por medio de interfaces HTTP así
que Nessus busca y regresa los resultados para identificarlo. Existe mucha más información en el script
find_ap.nasl el cual es posible leer para entender un poco más cómo es que el script funciona. El tercer
método se conoce como FTP fingerprinting, donde Nessus busca la bandera de FTP, finalmente se tiene
el SNMP fingerprinting (SNMP Simple Network Management Protocol) el cual también es usado cuando
un conjunto de cadenas se identifican. Es posible ver valores como “sysDesc” en este método.
Métodos de búsqueda son usados por Nessus
o OS Fingerprinting
o HTTP Fingerprinting
o FTP Fingerprinting
o SNMP Fingerprinting
Existen algunas ventajas sobre las auditorías en redes alámbricas sobre las redes inalámbricas, la
primera, es que la búsqueda física puede consumir mucho tiempo. Segunda, cuando se hace una
auditoría en redes alámbricas, es poco común tener falsos positivos ya que se tiene conocimiento sobre
el espacio de direcciones del cual se es responsable. En las auditorías de redes inalámbricas es posible
encontrar muchos APs que no tienen nada que ver con la organización. Sin embargo, como auditor no
siempre se sabe si el AP se encuentra dentro de la organización o no.
A continuación se muestran algunos consejos que se deberían seguir para realizar un auditoría en
infraestructuras de redes inalámbricas.
1. Siempre actualizar los plugins de Nessus antes de realizar cualquier escaneo.
2. Seleccionar el plugin #11026 de la familia “General” el cual a su vez contiene el plugin “Access
Point Detection”.
3. Escanear los puertos del 1 al 100 o al menos del 21 al 80 en la red donde se están buscando los
APs.
Dirección General de Servicios de Cómputo Académico Subdirección de Seguridad de la Información / UNAM - CERT
Auditorías de Seguridad Informática
4. Deshabilitar “safe checks”.
5. Habilitar “Enable Dependencies at Runtime”.
Herramientas como NetStumber son muy eficientes para detectar APs que los usuarios
malintencionadamente hayan colocado. NetStumber corre sobre la plataforma Windows y es muy
sencilla su instalación. NetStumber detecta APs que estén realizando broadcasting con su SSID.
Normalmente un experto de seguridad deshabilitaría el broadcast del SSID en los APs, sin embargo,
cuando los usuarios comunes instalan un AP generalmente no tienen una conciencia en seguridad
informática. Por lo tanto NetStumber detectará la mayor parte de APs instalados ilegalmente en el
entorno de la organización.
Dirección General de Servicios de Cómputo Académico Subdirección de Seguridad de la Información / UNAM - CERT
Auditorías de Seguridad Informática
Kismet es otra herramienta que corre en Unix, puede encontrarse información y ser descargada desde
www.kismetwireless.net. El archivo de log creado con Kismet incluso puede ingresarse en Ethereal.
Antes de correr Kismet, es necesario editar los archivos kismet.conf y kismet_ui.conf para que pueda
detectar APs. Además Kismet ofrece un detector pasivo, lo que implica que incluso los AP que estén
configurados para no mandar su SSID por broadcast pueden ser identificados.
Kismet es la contraparte en Unix de NetStumber, sin embargo, es completamente pasivo e indetectable
si es usado correctamente.
Airsnort y WEPCrack son herramientas que fueron diseñadas específicamente para romper llaves de
redes que usan cifrado WEP. A pesar de que estas herramientas aún no han sido modificadas para
trabajar con TKIP (Temporal Key Integrity Protocol o llamado hashing de clave WEP WPA) no debería
mostrar muchas dificultades ya que tanto TKIP como WEP están basadas en RC4.
A continuación se darán una lista de preguntas que el auditor deberá tener presentes al estar realizando
la auditoría de redes.
¿Existe una política de seguridad en las redes WLAN?
¿Existe una política de configuración base?
¿Se ha realizado una evaluación de riesgos en el entorno de la red?
¿Los APs se encuentran físicamente seguros?
¿Existe una apropiada capacitación para los administradores?
¿Cuál es la arquitectura del entorno de la WLAN?
¿Qué tecnología de redes inalámbricas está siendo usada?
¿Los clientes deben autenticarse a las estaciones base?
¿Las configuraciones por default de fábrica, como contraseñas y SSID han sido cambiadas?
¿Con qué regularidad se cambian las contraseñas y las llaves de cifrado?
¿El equipo está realizando broadcast del SSID?
Dirección General de Servicios de Cómputo Académico Subdirección de Seguridad de la Información / UNAM - CERT
Auditorías de Seguridad Informática
¿La información y datos son cifrados?
¿Las conexiones que se realizan son registradas?
¿Existen bitácoras que son revisadas regularmente para encontrar intentos de conexiones no
autorizados?
¿Existe un procedimiento para mantener a los usuarios, darlos de alta o baja?
¿Los clientes están correctamente configurados con un Firewall personal?
AUDITORÍA DE SISTEMAS OPERATIVOS
Los conceptos en la primera parte del presente capítulo están enfocados a versiones comerciales de
sistemas Windows, las versiones más recientes de Windows Server y se tocarán muy temas sobre
Windows Vista y Windows 7.
Microsoft oficialmente ha dejado de dar soporte a Windows NT Workstation, Windows NT Server y
Windows 2000 Server y Profesional, lo que implica que el uso de estos sistemas operativos incrementan
considerablemente el riesgo de sufrir un incidente en redes corporativas ya que las nuevas
vulnerabilidades no serán reparadas por Microsoft a menos que alguna organización pague o contrate el
soporte directamente.
Existen varios documentos que pueden ayudar a un auditor para realizar una auditoría exitosa, por
ejemplo el US National Institute of Standards and Technology (NIST) tiene bastantes documentos que
son totalmente gratis y pueden descargarse desde csrc.nist.gov. La “Serie 800” es una buena guía para
comenzar, sobre todo la publicación 800 – 26 “Security Self – Assessment Guide for Information Security
Technology Systems”, esta guía proporciona un marco de alto nivel para las auditorías incluyendo un
checklist para auditorías. Los checklist generalmente están referenciados con apoyo de otras
instituciones como el NIST y el FISCAM (Federal Information System Control Audit Manual).
Microsoft también ha hecho un gran esfuerzo por documentar aspectos de seguridad de sus sistemas
operativos, incluyendo recomendaciones (algunas listas de checklist) en la seguridad de los sistemas
operativos y algunas aplicaciones.
Auditar un sistema operativo es examinar dicho sistema en un simple punto tratando de verificar que la
configuración es apropiada conociendo previamente los estándares de la organización. Pero eso no es
todo el trabajo, la auditoría también consiste en monitorear sistemas y redes en tiempo real para
detectar cualquier problema y corregirlo.
IDENTIFICANDO EL SISTEMA
El primer paso es obtener la mayor información sobre el sistema que será auditado, qué versión de
Windows está corriendo, Windows 2003, Windows 2005, Windows 2008, Windows 7, etc., conociendo
Dirección General de Servicios de Cómputo Académico Subdirección de Seguridad de la Información / UNAM - CERT
Auditorías de Seguridad Informática
la versión de Windows es posible saber que herramientas se podrán usar, algunas herramientas nativas
proporcionadas por Microsoft no funcionan en algunas versiones de Windows y en otras versiones si.
Para obtener información básica del SO se deberá construir un perfil del sistema que será auditado. El
cual podría incluir el tipo de Sistema Operativo, versión del SO, versión del Kernel, número del último
Service Pack instalado, etc. Además es recomendable obtener información sobre el hardware como la
velocidad del CPU, memoria, discos duros, tipo de partición , FAT, FAT32, NTFS.
Existen herramientas que pueden usarse para obtener información básica sobre qué versión del SO se
está corriendo. El uso de una herramienta u otra depende de las preferencias personales y el nivel de
acceso al sistema (local vs remoto, acceso a nivel de usuario vs acceso a nivel de administrador). Es
necesario tener en mente que la mayoría de las herramientas fueron diseñadas para los
administradores, no para los auditores. Por lo tanto la mayoría de las utilerías descritas necesitan
permisos de administrador en el sistema que será auditado.
Las dos herramientas más básicas se encuentran dentro del sistema operativo Windows, las cuales son
los comandos ver y winver, ambos pueden ejecutarse desde la línea de comandos a pesar de que el
comando winver muestra el resultado en una ventana GUI.
La información proporcionada por estas herramientas es limitada si se desea mayor información se
tienen herramientas alternativas como systeminfo.exe, el cual es posible ejecutarlo desde línea de
Dirección General de Servicios de Cómputo Académico Subdirección de Seguridad de la Información / UNAM - CERT
Auditorías de Seguridad Informática
comandos y da información extensiva sobre el SO, como versión ,host, usuario registrado, memoria e
incluso los hotfix instalados.
C:\>systeminfo
Nombre de host: MEZTLI
Nombre del sistema operativo: Microsoft Windows 7 Enterprise
Versión del sistema operativo: 6.1.7600 N/D Compilación 7600
Fabricante del sistema operativo: Microsoft Corporation
Configuración del sistema operativo: Estación de trabajo independiente
Tipo de compilación del sistema operativo: Multiprocessor Free
Propiedad de:
Organización registrada:
Id. del producto: 55041-029-0023583-86430
Fecha de instalación original: 09/12/2009, 09:19:43 p.m.
Tiempo de arranque del sistema: 28/04/2010, 01:35:05 p.m.
Fabricante del sistema: Dell Inc.
Modelo el sistema: XPS M1530
Tipo de sistema: X86-based PC
Procesador(es): 1 Procesadores instalados.
[01]: x64 Family 6 Model 15 Stepping
13 GenuineIntel ~1000 Mhz
Versión del BIOS: Dell Inc. A09, 14/07/2008
Directorio de Windows: C:\Windows
Directorio de sistema: C:\Windows\system32
Dispositivo de arranque: \Device\HarddiskVolume3
Configuración regional del sistema: es-mx;Español (México)
Idioma de entrada: es-mx;Español (México)
Zona horaria: (UTC-06:00) Guadalajara, Ciudad de Mé
xico, Monterrey
Cantidad total de memoria física: 3,582 MB
Memoria física disponible: 2,372 MB
Memoria virtual: tamaño máximo: 7,162 MB
Memoria virtual: disponible: 5,028 MB
Memoria virtual: en uso: 2,134 MB
Ubicación(es) de archivo de paginación: C:\pagefile.sys
Dominio: WORKGROUP
Servidor de inicio de sesión: \\MEZTLI
Revisión(es): 19 revisión(es) instaladas.
[01]: KB971468
[02]: KB972270
[03]: KB973525
[04]: KB974332
[05]: KB974431
[06]: KB974571
[07]: KB975364
[08]: KB975467
Tarjeta(s) de red: 5 Tarjetas de interfaz de red instala
das.
[01]: Controladora Fast Ethernet PCI-
E 88E8040 Marvell Yukon
Nombre de conexión: Conexión de
área local
Estado: Medios desc
onectados
[02]: Conexión de red Intel(R) PRO/Wi
reless 3945ABG
Nombre de conexión: Conexión de
red inalámbrica
DHCP habilitado: Sí
Servidor DHCP: 10.4.250.25
4
Direcciones IP
[01]: 10.4.250.228
[02]: fe80::a052:59e1:3a2d:6e67
[03]: VMware Virtual Ethernet Adapter
for VMnet1
Nombre de conexión: VMware Netw
ork Adapter VMnet1
Dirección General de Servicios de Cómputo Académico Subdirección de Seguridad de la Información / UNAM - CERT
Auditorías de Seguridad Informática
DHCP habilitado: No
Direcciones IP
[01]: 192.168.30.1
[02]: fe80::8cad:c9b8:75f9:5ce0
[04]: VMware Virtual Ethernet Adapter
for VMnet8
Nombre de conexión: VMware Netw
ork Adapter VMnet8
DHCP habilitado: No
Direcciones IP
[01]: 192.168.31.1
[02]: fe80::9c3e:1bdc:cacc:173a
[05]: VirtualBox Host-Only Ethernet A
dapter
Nombre de conexión: VirtualBox
Host-Only Network
DHCP habilitado: No
Direcciones IP
[01]: 192.168.56.1
[02]: fe80::4510:5573:56d8:24fa
Windows también incluye la utilería System Information (msinfo32.exe), la cual muestra una ventana
GUI y muestra todo sobre el SO.
Esta
util
ería
es
más
que
sufi
cien
te
par
a
rec
ono
cer
el
sist
ema.
Con la información proporcionada por estas utilerías y preguntando al personal adecuando podremos
contestarnos las primeras preguntas:
¿El SO esta en uso actualmente?
¿El último Service Pack está instalado actualmente?
Dirección General de Servicios de Cómputo Académico Subdirección de Seguridad de la Información / UNAM - CERT
Auditorías de Seguridad Informática
¿El formato del disco se encuentra en NTFS? El formato NTFS es el único que soporta
controles de seguridad y cifrado así como el control de permisos. FAT32 no tienen estas
características
Estado de los parches, ¿cuándo fue el último parche del SO?
Aplicaciones instaladas, ¿alguna aplicación se ha instalado sin autorización?
Una de las mejores herramientas para realizar auditorías es psinfo, es una utilería freeware de
Sysinternals y puede ser descargada de http://technet.microsoft.com/en-
us/sysinternals/bb897550.aspx, el cual se incluye en la suite PSTools, es similar a la herramienta
systeminfo.exe, sin embargo esta herramienta al mostrar la información desde línea de comandos, es
posible ejecutarla local y remotamente.
C:\PsTools>psinfo
PsInfo v1.75 - Local and remote system information viewer
Copyright (C) 2001-2007 Mark Russinovich
Sysinternals - www.sysinternals.com
System information for \\MEZTLI:
Uptime: Error reading uptime
Kernel version: Windows 7 Enterprise, Multiprocessor Free
Product type: Professional
Product version: 6.1
Service pack: 0
Kernel build number: 7600
Registered organization:
Registered owner:
???, ???
Activation status: Error reading status
IE version: 8.0000
System root: C:\Windows
Processors: 2
Processor speed: 1.9 GHz
Processor type: Intel(R) Core(TM)2 Duo CPU T5750 @
Physical memory: 3582 MB
Video driver: Tarjeta grßfica VGA estßndar
PARCHES Y ACTUALIZACIONES
Uno de los principales objetivos en las auditorías de Sistemas Operativos Windows particularmente es el
asegurarse de que el sistema tenga los últimos parches y actualizaciones instaladas.
Instalando un sistema operativo de manera segura no es suficiente, los sistemas deben ser
monitoreados y mantenidos todo el tiempo y uno de los mantenimientos críticos de los administradores
es actualizar y parchar el sistema.
Algunos fabricantes liberan parches para reparar bugs del software, incluyendo vulnerabilidades de
seguridad. Por lo tanto es una muy buena práctica tener el sistema parchado y actualizado con los
últimos parches liberados por los fabricantes. Muchos de los más conocidos y más explotados ataques
toman ventaja de vulnerabilidades “desconocidas” sin embargo otros ataques explotan vulnerabilidades
“conocidas” sin embargo, siguen tomando a administradores por sorpresa ya que no parchan ni
actualizan su SO.
Dirección General de Servicios de Cómputo Académico Subdirección de Seguridad de la Información / UNAM - CERT
Auditorías de Seguridad Informática
La lista de ejemplos es asombrosa, numerosas vulnerabilidades de IIS, incluyendo Remote Data Services
(RDS), buffer overflows (Code Red), Transversal Directory Unicode (Nimda), etc.
Muchas herramientas se encuentran disponibles para revisar el estado (o en algunos casos el
mantenimiento) de los parches. Algunas herramientas son de empresas externas a Microsoft (escáneres
de vulnerabilidades, herramientas de auditoría, software de mantenimiento) las cuales también incluyen
revisiones al estado de parches del equipo.
Microsoft Baseline Security Analyzar (MBSA) es una herramienta gratuita y gráfica que Microsoft
proporciona para realizar la revisión de seguridad de sistemas operativos algunas aplicaciones Windows
como IIS, SQL Server, Internet Explorer. Puede ser descargado desde la página
http://technet.microsoft.com/en-us/security/cc184923.aspx.
Existen herramientas en las que participan Microsoft y otras empresas que proporcionan revisiones de
parches y actualizaciones para múltiples sistemas (HFNETChk Pro de Shavlik, Update Expert de St.
Bernard, etc.).
Tipo de Parches
Es necesario explicar las actualizaciones y parches que Microsoft lanza. Diferentes empresas tienen
políticas sobre la liberación de parches y actualizaciones, así como diferentes métodos para instalarlos.
Microsoft tiene tres diferentes tipos de parches.
Service Pack. Los Service Packs son liberados para los sistemas operativos y para algunas
aplicaciones de Microsoft como Microsoft Office, Exchange Server. Contienen la mayoría de las
actualizaciones liberadas hasta esa fecha. También pueden incluir mejoras o agregar
componentes al software original. Los Service Packs son liberados públicamente y pueden
contener cientos de reparaciones de seguridad y reparaciones menores. Generalmente son
liberados cada 6 o 12 meses. Los Service Packs son probados muchas veces antes de ser
liberados y además tienen una documentación muy extensiva respecto a las fallas reparadas.
Hotfixes (también conocidos como Critical Updates). Hotfixes son parches que reparan una sola
vulnerabilidad o pocas relacionadas. Hotfixes son liberados públicamente y reparan una sola
Dirección General de Servicios de Cómputo Académico Subdirección de Seguridad de la Información / UNAM - CERT
Auditorías de Seguridad Informática
vulnerabilidad de seguridad o pocos problemas del sistema. Son menos probadas que los
Service Packs antes de ser liberados.
QFE Fixes (Quick Fix Engineering). Los QFE reparan un problema especializado pero no tan
crítico, o que solo afecta a ciertos sistemas, por ejemplo, aplicaciones que interactúan con otras
aplicaciones, dispositivos y drivers. QFE Fixes no son tan probados por lo que son literalmente
“reparaciones rápidas” diseñadas para reparar algún problema específico. Generalmente son
liberados sin ser anunciados.
El verificador de parches de Microsoft contenido en la aplicación MBSA es un analizador de
vulnerabilidades limitado, pero puede ayudar para validar que en los hosts se encuentren los últimos
parches instalados.
Dependiendo del alcance de la auditoría o preferencias personales MBSA puede ser usado para
escanear un simple equipo o un rango de direcciones o redes o dominios de Windows.
Es necesario realizar algunas preguntas adicionales con respecto a la política de actualizaciones del
equipo y revisar si son seguidas por los administradores.
¿Existe un control de políticas? Es necesario tener en mente que los equipos deben estar
parchados para mitigar las vulnerabilidades conocidas pero también es necesario saber que
estos nuevos parches no introduzcan otras vulnerabilidades inesperadas o que no fallen con
otras aplicaciones instaladas en el equipo. Es necesario saber si existen políticas o
procedimientos relacionados con las pruebas a nuevos parches antes de ser instalados. ¿Cómo
es que la organización realiza ese balance entre la necesidad de instalar los parches y la
necesidad de probarlos?
¿Existe algún calendario para realizar el mantenimiento? Los parches son comunes
particularmente en productos de Microsoft. ¿Existen políticas o procedimientos relacionados
con calendarios de mantenimiento para los sistemas en la red? Estos incluyen equipos de “bajo
impacto” sistemas de usuarios como estaciones de trabajo y las de “misión crítica” sistemas
clave para el negocio.
Cumplimiento de políticas. ¿La organización requiere de una política, regulación o ley para el
mantenimiento del nivel de parches? Debe existir una política explicita para la instalación de un
parche explicito o deberá ser más general como una “mejor práctica” o deberá existir una
clausula relativa a la seguridad o privacidad de la información de los sistemas o redes.
Políticas exentas. ¿Existen políticas o procedimientos con excepciones relacionadas con
actualizaciones y parches? ¿Existen situaciones donde es mejor no parchar? ¿Quién es que toma
estas decisiones o asume el riesgo en cada caso?
Dirección General de Servicios de Cómputo Académico Subdirección de Seguridad de la Información / UNAM - CERT
Auditorías de Seguridad Informática
COMPONENTES Y SERVICIOS NO NECESARIOS
Otro objetivo de la auditoría es determinar si los servicios o componentes instalados en el equipo
Windows son necesarios y cuales son determinantes para la operación del sistema. Cualquiera que no
sea esencial deberá ser eliminado o deshabilitado. Pensando en el principio de “menos privilegios” para
el equipo de cómputo, si el equipo no aloja un servidor de páginas Web, entonces no es necesario estar
ejecutando un Web Server.
Cuando se examinan los componentes y servicios se revisará al equipo desde diferentes ángulos.
Primero es necesario identificar qué servicios están “escuchando” o esperando aceptar conexiones de
otros equipos en la red. Ya que si estos servicios están “externamente accesibles” (disponibles sobre la
red, pensando que los accesos a estos puertos pueden ser filtrados por el firewall o roteadores) puede
presentar un gran riesgo. Por lo tanto es necesario realizar una búsqueda para localizar esos servicios o
componentes instalados en el sistema. Microsoft, como muchos fabricantes de software, instala un sin
número de servicios, muchos los cuales no son necesarios e incluso pueden presentar un riesgo.
Identificando dichos servicios es posible eliminarlos o deshabilitarlos o tomar acciones para mitigar
dicho riesgo en el sistema.
Como se instalen los componentes en un sistema operativo depende mucho de la versión, Microsoft ha
modificado sus rutinas de instalación para mostrar opciones de instalar / no instalar, componentes, sin
embargo también se puede presentar que se decida realizar una instalación por default, en este caso
Microsoft instala los componentes sin preguntar al administrador del equipo.
En contraste con los componentes, los servicios, son procesos particulares que se ejecutan en
background en un equipo Windows. Generalmente los servicios son configurados para ejecutarse de
manera automática cuando el sistema inicia, sin embargo algunos servicios pueden encontrarse latentes
hasta que son necesitados iniciándose solo cuando es llamado o activado por otro proceso. Los servicios
pueden ser parte clave de varios componentes del sistema operativo por si mismo. Ejemplo de estos
servicios incluyen el servicio Internet Services Manager (parte del IIS) y el servicio de Messenger (parte
del SO Windows).
El estado del servicio puede encontrarse de tres maneras:
Automático. Es servicio es cargado e iniciado al iniciar el equipo y corre todo el tiempo que el SO
se encuentre funcionando
Manual. El servicio no es cargado al iniciar pero puede estar latente hasta que sea necesitado y
llamado por otro proceso que lo necesite. El servicio se ejecutará todo el tiempo que se necesite
y posteriormente se detendrá hasta que sea necesario nuevamente
Deshabilitado. El servicio no es cargado al iniciar y no puede ser iniciado automáticamente,
como cuando se encuentra en estado “manual”
Dirección General de Servicios de Cómputo Académico Subdirección de Seguridad de la Información / UNAM - CERT
Auditorías de Seguridad Informática
En las instalaciones por default y la mayoría de los sistemas operativos y aplicaciones incluyen
numerosos componentes (y servicios asociados) que no son necesarios excepto en ciertos ambientes. Lo
que significa que ciertos componentes, servicios, etc., pueden contener ciertas vulnerabilidades que son
instaladas por default incluso son el conocimiento del administrador.
Algunos componentes pueden contener ciertas vulnerabilidades por ejemplo, Simple Network
Management Protocol (SNMP), otros pueden contener campos que los hagan seguros, sin embargo, en
la instalación por default estos campos no se encuentran habilitados por default. Finalmente algunos
componentes pueden introducir vulnerabilidades descubiertas posteriormente, por ejemplo IIS. Si el
administrador no es consiente sobre los componentes instalados, entonces no sabrá que es necesario
parcharlos para mitigar las vulnerabilidades relacionadas a dichos componentes.
Cualquier servicio es un potencial agujero de seguridad en el sistema. Si el servicio es deshabilitado o
desinstalado es una puerta menos en el equipo. Deshabilitando servicios puede igualmente mejorar el
desempeño del SO ya que tendrá menos procesos en background corriendo. Como auditor es necesario
revisar los componentes y servicios corriendo en el equipo y asegurarse que son solamente los
necesarios para su fin.
Cuando se están auditando aplicaciones y servicios que están corriendo en el equipo, es importante
hacerles frente desde dos perspectivas. Primero, es necesario revisar los servicios que están
“escuchando” en el equipo, listos y en espera de una conexión de usuarios externos. Estos servicios
proporcionan un potencial peligro pues significa que alguien remotamente puede conectarse en el
equipo. Escáneres de puertos son usados para éste propósito, como nmap o SuperScan de Foundstone.
Una vez que se han reconocido los puertos, entonces hay que determinar qué servicios están asociados
a ellos. Por convención algunos servicios como Web, correo, telnet, ssh, etc., siempre se encuentran en
el mismo puerto conocido. Por lo tanto escuchando algunos puertos el auditor como el atacante puede
determinar los servicios disponibles en el sistema.
Herramientas para determinar los puertos abiertos:
Nmap, SuperScan
Netstat
Herramientas para listar todos los servicios
Servicios MMC (Microsoft Manager Console)
psservice, sc.exe de SysInternals
Además de realizar las revisiones técnicas es importante tener una lista de preguntas sobre los servicios
que se tienen ejecutando en un equipo así como su mantenimiento y verificaciones.
Dirección General de Servicios de Cómputo Académico Subdirección de Seguridad de la Información / UNAM - CERT
Auditorías de Seguridad Informática
¿Las instalaciones y configuraciones en los equipos Windows son estándares en toda la
organización?
¿Existe alguna política que describa el otorgar permisos para deshabilitar servicios?
¿Los administradores de los sistemas están familiarizados con los servicios y puertos estándares
que podrían presentarse en sus sistemas?
¿Existen revisiones periódicas para detectar cambios o nuevos puertos y servicios?
USUARIOS, GRUPOS Y CONTRASEÑAS
El siguiente paso de la auditoría es verificar que los usuarios y grupos en el sistema sean correctos y se
encuentren con los permisos correctos.
Solo se deben tener en el sistema usuarios válidos. Las cuentas de usuario deberán ser desplegadas y
revisadas para asegurarse que todas las cuentas sean para usuarios válidos. Esto incluye las cuentas de
“propósito especial” y las que pueden ser creadas por medio de una “plantilla” para el uso de un servicio
o aplicación.
Los grupos tienen los miembros apropiados. Los grupos de Windows coleccionan usuarios con
requerimientos similares de seguridad asignando permisos a recursos del sistema.
No tener contraseñas en blanco. Se podría pensar que después de toda la información y educación
sobre la importancia de las contraseñas fuertes, el cambio regular de dichas contraseñas, etc. sin
embargo, muchos administradores aún tienen cuentas con contraseñas en blanco por lo tanto es
importante revisar.
Política de contraseñas. No es suficiente que solamente solicite contraseñas. Es posible tener un control
para forzar a los usuarios a utilizar contraseñas fuertes, así como, el tiempo el cual los usuarios deberán
cambiar su contraseña.
Por lo tanto, es necesario asegurarse las cuentas de usuarios y grupos sean válidos, y si las cuentas que
aparecen como activas están en uso (si no están en uso probablemente no son necesarias)
Igualmente es necesario verificar algunos parámetros asociados a cada cuenta (si la cuenta expira, si la
cuenta tiene restricciones para firmarse en algunos horarios, etc.)
Algunos comandos en línea y gráficos pueden proporcionar información sobre los usuarios en equipos
locales y remotos.
DSQuery es una poderosa herramienta que puede proporcionar desde una interfaz de línea de
comandos para los equipos que se encuentran bajo una arquitectura de Active Directory en un dominio.
Lo que significa que puede usarse para buscar cualquier objeto del directorio activo y ser usada en
Dirección General de Servicios de Cómputo Académico Subdirección de Seguridad de la Información / UNAM - CERT
Auditorías de Seguridad Informática
conjunto con otras herramientas con lo que es posible extraer toda la información de cualquier objeto
fácilmente.
Sin embargo la información que arroja DSQuery no siempre es totalmente entendible, sin embargo, con
un poco de esfuerzo o tal vez algún script es posible obtener información mucho más entendible
Algunas precauciones adicionales deberán de ser tomadas en Windows para limitar a las cuentas de
usuarios hay que recordar el principio de menos privilegios, las cuentas pueden ser (deberían ser)
creadas con una fecha de expiración. Esto es especialmente importante cuando existen contratos
temporales sin embargo puede ser igualmente útil para empleados “regulares”.
Además es posible limitar los accesos a un horario específico. Esto podría no ser tan práctico para
“usuarios poderosos” quienes regularmente se conectan a la VPN para revisar su correo electrónico a las
2 AM, sin embargo, podría ser muy práctico para usuarios que generalmente trabajan en un horario
específico. Si las cuentas solamente van a ser usadas de las 8 AM a las 6 PM, entonces sería una buena
práctica configurarlas de esa manera.
Finalmente, hay que tomar en cuenta igualmente las “cuentas especiales” que existen en los sistemas
Windows. La cuenta Administrator o Guest son creadas por default y ninguna de las dos puede ser
borrada por medio del sistema operativo es necesario utilizar una herramienta de terceros llamada
“Delguest” para borrarlas, la herramienta puede ser descargada de la siguiente liga
http://ntsecurity.nu/toolbox/delguest/. Además la cuenta de administrador no puede ser deshabilitada
en Windows 2000 pero si en versiones posteriores.
Cuando se instala Internet Information Server (IIS). Windows crea dos cuentas IUSR_<nombre del
equipo> y IWAM_<nombre del equipo> estas cuentas se crean para proporcionar acceso “anónimo” a
los usuarios que visitan la página Web. IUSR e IWAM son agregadas dentro del grupo “Guests” por
default y tienen todos los privilegios y permisos asociados a ese grupo.
Windows XP y 2003 así como versiones posteriores, crean dos cuentas durante su instalación.
HelpAssistan y SUPPORT. HelpAssistan es una cuenta creada para permitir el acceso remoto y tomar el
control del equipo. SUPPORT puede ser usada por Microsoft Help and Support Center para proporcionar
asistencia remota a los usuarios. Si no son usados estos servicios estas cuentas deberían estas
deshabilitadas.
Igualmente hay que revisar las cuentas que usan los servicios corriendo en Windows. De acuerdo con el
principio de menos privilegios, los servicios deberían de correr con los mínimos privilegios necesarios
para operar. Desafortunadamente muchos servicios corren como LocalSystem (algunas veces referido a
la cuenta SYSTEM una cuenta con todos los privilegios equivalente a Administrator).
Windows XP y posteriores introdujo dos cuentas adicionales para servicios: Local Service y Network
Service. Local Service se ejecuta en el equipo con los privilegios del grupo Users y accede a los recursos
de la red como un usuario anónimo. Network Service igualmente corre en el equipo local con los
privilegios del grupo Users pero tiene acceso a la red usando las credenciales del equipo en el cual está
Dirección General de Servicios de Cómputo Académico Subdirección de Seguridad de la Información / UNAM - CERT
Auditorías de Seguridad Informática
corriendo. Estas cuentas pueden proporcionar servicios con permisos limitados, no comparados con los
permisos de cuentas como LocalSystem o Administrator.
Los servicios también pueden ser configurados para correr con una cuenta específica para su uso. Es
posible crear cuentas de usuarios con pocos privilegios para asignarlas a los servicios. Herramientas de
terceros pueden ser instalados en los equipos las cuales pueden crear servicios así como cuentas
asignadas a servicios. Desafortunadamente, muchas aplicaciones crean y usan servicios con niveles de
administrador o administrador de minio por default.
La siguiente parte cubrirá sistemas de la familia de Unix siguiendo la misma línea que se cubrió con
sistemas Windows.
SERVICIOS
Mientras existen bastantes servicios como pueden ser RPC, NFS y X – Windows son los más comunes.
Sin embargo pueden existir servicios dependiendo de la versión o sabor del Unix como servicios Web,
servicios de correo electrónico, etc.
Los RPC (Remote Procedure Calls) son extremadamente comunes en los ambientes Unix. Estos servicios
pretenden implementar la centralización del software o servicios en la red para que todos los demás
equipos puedan tener acceso.
Es posible verificar que servicios RPC están disponibles en el sistema usando la herramienta “rpcinfo”.
Esta herramienta se conecta al portmapper y regresa una lista de servicios RPC que se ejecutan en el
equipo. El portmapper es un servicio RPC en sí sin embargo siempre se encuentra escuchando en el
puerto 111 TCP y UDP. Dicho servicio actúa como un directorio de servicios permitiendo a las
aplicaciones registrar sus versiones y el número de puertos que estarán escuchando. Programas que
necesiten algún servicio pueden preguntarle al portmapper y encontrar algún servicio y el puerto en el
que está corriendo. Sin embargo el portmapper puede tener un sin número de nombres dependiendo
de la versión del Unix, los nombres pueden ser ‘portmap’, ‘rpc.bind’ y ‘portmapper’ entre otros.
Las preguntas al portmapper son una excelente herramienta para los atacantes para obtener
información, sin embargo, es también muy útil para los auditores para determinar y verificar los
servicios que se encuentran corriendo en el equipo.
Network File System (NFS) ha existido por más de una década y fue creado para proporcionar los
mecanismos estándares en los archivos o carpetas compartidas entre sistemas Unix. NFS por lo regular
se encuentra en escucha en el puerto 2049 y tienen la capacidad de funcionar sobre TCP y UDP. NFS
requiere de varios servicios más para funcionar apropiadamente, los cuales pueden incluirse “mountd”,
“nfsd”, “statd” y “lockd”.
X – Windows únicamente proporciona la interfaz gráfica en el sistema operativo, sin embargo existen
servicios X – Windows orientado a redes, no solamente es posible conectarse a un sistema por medio de
ventanas o enviar una ventana a un sistema remoto a través de la red, sino, que el sistema
Dirección General de Servicios de Cómputo Académico Subdirección de Seguridad de la Información / UNAM - CERT
Auditorías de Seguridad Informática
generalmente envía una interface de loopback al sistema local para generar una ventana. Esto lo
convierte en una herramienta muy poderosa ya que permite correr aplicaciones en un equipo mientras
que la salida gráfica la muestra en otra en cualquier parte del mundo.
El sistema X – Windows también proporciona una autenticación gráfica utilizando el programa X Display
Manager (XDM), existe una gran variedad de programas de terceros uno de los más comunes y mejor
programado el Gnome.
AUDITANDO SISTEMAS UNIX
¿Cómo?, esta es la pregunta fundamental que debe ser contestada con, ¿es posible confiar en la
información guardad en el sistema y es confiable ejecutar herramientas que residen en el sistema? Los
atacantes han llegado a ser cada vez mejores, una de las maneras que han perfeccionado es el instalar
herramientas llamadas rootkits. Las cuales sirven para dos propósitos. Primero, el rootkit generalmente
proporciona acceso a las herramientas del atacante y segundo el rootkit puede servir de máscara para
ocultar procesos, servicios o puertos cuando un sistema está comprometido.
Por lo tanto es preferible tener en un CD los binarios de las herramientas que se necesiten ya que
estaremos confiados que no se encuentran troyanizados. Herramientas que proporcionan una suite
bastante amplia se encuentran las siguientes:
Knoppix (www.knoppix.org). Es una distribución que corre desde el CD y fue diseñada para tener
todos los componentes de un sistema Linux pero puede ser fácilmente adaptado para
propósitos de auditoría.
Fire (fire.dmzs.com). Fire está especialmente diseñado para examinar sistemas potencialmente
comprometidos o desde un punto de forense. Esta distribución incluye herramientas como
SleuthKit, Autopsy y Graverobbber.
Local Area Security (localareasecurity.com).
Una vez que ya se cuentan con las herramientas, entonces es necesario identificar el sistema al cual se
estará realizando la auditoría, la herramienta “úname” revela información sobre el Kernel, el
procesador.
# uname -a
Linux malware 2.6.32-22-generic #36-Ubuntu SMP Thu Jun 3 22:02:19 UTC 2010 i686 GNU/Linux
Otra información importante que se debe considerar es el tipo de archives que tiene montado. Mientras
que el sistema de archivos por si mismo va cambiando con el tiempo, la configuración del sistema de
archivos no cambia a menos de que un nuevo dispositivo se instale o el sistema se vuelva a instalar. La
herramienta “mount” puede ser usada para obtener esta información.
root@malware:~# mount
/dev/sda1 on / type ext4 (rw,errors=remount-ro)
proc on /proc type proc (rw,noexec,nosuid,nodev)
none on /sys type sysfs (rw,noexec,nosuid,nodev)
none on /sys/fs/fuse/connections type fusectl (rw)
none on /sys/kernel/debug type debugfs (rw)
Dirección General de Servicios de Cómputo Académico Subdirección de Seguridad de la Información / UNAM - CERT
Auditorías de Seguridad Informática
none on /sys/kernel/security type securityfs (rw)
none on /dev type devtmpfs (rw,mode=0755)
none on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620)
none on /dev/shm type tmpfs (rw,nosuid,nodev)
none on /var/run type tmpfs (rw,nosuid,mode=0755)
none on /var/lock type tmpfs (rw,noexec,nosuid,nodev)
none on /lib/init/rw type tmpfs (rw,nosuid,mode=0755)
none on /var/lib/ureadahead/debugfs type debugfs (rw,relatime)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,noexec,nosuid,nodev)
gvfs-fuse-daemon on /home/ocelotzin/.gvfs type fuse.gvfs-fuse-daemon
(rw,nosuid,nodev,user=ocelotzin)
Mientras el comando “mount” puede ser usado para mostrar la información de particiones montadas,
pueden existir particiones que no estén montadas, de hecho, esta es un excelente camino para crear
espacio de disco “oculto”. El espacio no está en verdad oculto, sino que simplemente no está montado o
disponible así que la mayoría de los administradores o auditores pueden fácilmente pasarlo por alto. La
herramienta “fdisk” puede ser usada para mostrar las particiones no montadas.
root@malware:~# fdisk -l
Disk /dev/sda: 80.0 GB, 80026361856 bytes
255 heads, 63 sectors/track, 9729 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x0008611b
Device Boot Start End Blocks Id System
/dev/sda1 * 1 9362 75193344 83 Linux
/dev/sda2 9362 9730 2955265 5 Extended
/dev/sda5 9362 9730 2955264 82 Linux swap / Solaris
root@malware:~#
Otra herramienta que proporciona información es la herramienta “free”, lo que permite identificar
bastantes puntos para la auditoría. Primero, es posible ver la memoria física instalada en el sistema.
Segundo, es posible ver el tamaño de la partición Swap. Tercero, es posible ver también el espacio que
actualmente está en uso y cuanto espacio de Swap se está usando.
root@malware:~# free
total used free shared buffers cached
Mem: 1009492 959028 50464 0 43480 272332
-/+ buffers/cache: 643216 366276
Swap: 2955256 522276 2432980
PARCHES
Examinar los parches en sistemas Unix ha llegado a ser cada vez más fácil. Anteriormente era bastante
tedioso determinar que parches tenia instalados y cuáles no. Hoy en día cada fabricante de Unix ofrece
su propia solución para examinar el estado de los parches. Algunos ejemplos de estos sistemas son
“patchdiag” para Sun el cual reporta el estado de los parches para equipos basados en Solaris. Redhat
tiene su similar llamado “up2date”, de hecho muchos de los fabricantes de Linux están centralizando los
servicios de actualizaciones.
AUDITORÍA DE APLICACIONES
Dirección General de Servicios de Cómputo Académico Subdirección de Seguridad de la Información / UNAM - CERT
Auditorías de Seguridad Informática
Al preguntarle a cualquier investigador de seguridad cómo es que éste descubre vulnerabilidades o fallas
en las aplicaciones, se pueden obtener infinidad de respuestas. ¿Por qué? Porque existen una variedad
de enfoques, cada uno con sus propias ventajas y desventajas. Ninguna aproximación es correcta y no
hay un solo método con el que se pueda descubrir todas las posibles vulnerabilidades de un objetivo
determinado.
En un nivel alto, existen tres aproximaciones principales para descubrir las vulnerabilidades de
seguridad:
Pruebas de caja blanca
Pruebas de caja negra
Pruebas de Caja gris
Las diferencias entre estos tres enfoques pueden ser determinadas por los recursos a los cuales,
nosotros, como testers, tenemos acceso.
A continuación se verán más a detalle cada una de las pruebas susodichas.
PRUEBAS DE CAJA BLANCA
Las pruebas de caja blanca requieren acceso completo a todos los recursos. Esto incluye el acceso al
código fuente, las especificaciones de diseño y quizá a los propios programadores.
Pros y Contras
Como ya se hizo mención anteriormente, no hay un único enfoque correcto para descubrir las
vulnerabilidades de seguridad. Así que ¿cómo elegir una metodología
adecuada? Bueno, a veces la decisión es tomada por nosotros. Las
pruebas de caja blanca, por ejemplo, no son
posibles si no tenemos
acceso al código
fuente de la objetivo.
Este es el caso de la
mayoría de los
investigadores de
seguridad y
usuarios finales,
especialmente
aquellos que tratan
con software comercial
en el entorno de
Microsoft
Windows. ¿Cuáles
son las ventajas de las
Dirección General de Servicios de Cómputo Académico Subdirección de Seguridad de la Información / UNAM - CERT
Auditorías de Seguridad Informática
pruebas de caja blanca?
PRUEBAS DE CAJA NEGRA
Por otro lado, existe el enfoque de pruebas de caja negra, en la cual se requiere poco o ningún
conocimiento del funcionamiento interno del objetivo y se limita a pruebas a ciegas en su mayoría.
Realizar pruebas de penetración a una aplicación web remota de la cual no se tiene acceso al código
fuente es un buen ejemplo de las pruebas de caja negra.
Las pruebas de caja negra implican que solo se tiene el conocimiento de lo que se puede observar.
Nosotros como usuarios finales controlamos la salida que proviene de la caja negra y podemos observar
la salida que emerge del otro lado, pero no tenemos el conocimiento del funcionamiento interno de
nuestro objetivo. Esta situación es más comúnmente encontrada cuando se tiene acceso de manera
remota a las aplicaciones y servicios Web. Se pueden elaborar entradas o peticiones en forma de
Lenguaje de marcado de hipertexto, de sus siglas en inglés Hypertext Markup Language (HTML) o en
Lenguaje de marcado extensible (Extensible Markup Language - XML) y observar la página Web
generada o el valor que se regresa, respectivamente, pero no se tiene idea de lo que está sucediendo
por debajo.
Existe un modelado de pruebas propuesto por Microsoft al que se le denomina modelado de amenazas,
éste es un elemento fundamental de la seguridad de Microsoft para el Desarrollo del Ciclo de Vida (SDL),
dicho modelado como parte de la fase de diseño del SDL, permite a los desarrolladores de software
identificar y mitigar posibles problemas de seguridad a tiempo, cuando éstos son relativamente fáciles y
rentables para resolver. Por lo tanto, ayuda a reducir el coste total de desarrollo.
Dirección General de Servicios de Cómputo Académico Subdirección de Seguridad de la Información / UNAM - CERT
Auditorías de Seguridad Informática
Pros y Contras
Las pruebas de caja negra, aunque no siempre son el mejor enfoque, son siempre una opción. Las
ventajas de las pruebas de caja negra son las siguientes:
Disponibilidad: Las pruebas de caja negra son siempre aplicables incluso en situaciones
cuando el código fuente está disponible todavía pueden ser beneficiosas.
Reproducibilidad: Dado a que las pruebas de caja negra no asumen nada respecto al
objetivo, una prueba de este tipo sobre un Protocolo de transferencia de archivos (FTP),
por ejemplo, puede ser fácilmente reutilizada para probar cualquier otro servidor FTP.
Simplicidad: Aunque los enfoques tales como la ingeniería inversa del código (Reverse
Code Engineering- RCE) requieren conocimientos especializados, las pruebas puras de
caja negra en su nivel más básico pueden llevarse a cabo sin un buen conocimiento del
funcionamiento interno de la aplicación. Sin embargo, en realidad, mientras que la
vulnerabilidad básica de la negación de servicio se encuentra simplemente a través de la
utilización de herramientas de test, generalmente se necesita un conocimiento más
profundo para determinar si el descubrimiento de una sencilla aplicación se puede
expandir a algo más interesante, como la ejecución de código.
A pesar de la accesibilidad de las pruebas de caja negra, se tienen algunos defectos. Las desventajas de
las pruebas de caja negra son las siguientes:
Cobertura: Uno de los mayores retos con la prueba de caja negra es determinar cuándo
se debe dejar de realizar las pruebas y qué tan efectivas han sido las pruebas.
Inteligencia: Las pruebas de caja negra que mejor se adaptan a los escenarios en los
cuales una vulnerabilidad es provocada por un solo vector de entrada Ataques
complejos podrían, sin embargo, requerir múltiples vectores de ataque, algunos de los
cuales colocan la aplicación del objetivo en un estado vulnerable y otros lanzan la
explotación. Ataques como éstos requieren una sólida comprensión de la lógica de la
aplicación subyacente y por lo general, sólo son descubiertos con las auditorías de
código fuente y manuales ICE.
PRUEBAS DE CAJA GRIS
Situándose en medio de las pruebas de caja negra y blanca se encuentran las pruebas de caja gris. Para
nuestros fines, las pruebas de caja gris requieren, por ejemplo, que se tenga acceso a binarios
compilados y quizá alguna documentación básica.
Definimos a las pruebas de caja gris para incluir un plus en la auditoría de caja negra adicionando
elementos a través de la ingeniería inversa (RE), también conocida como la ingeniería inversa del código
(RCE). El código fuente es un recurso invaluable que es razonablemente fácil de leer y proporciona una
sólida comprensión del cómo específicas funcionalidades operan. Además, comunica las entradas cuya
funcionalidad específica se espera y las salidas cuya misma funcionalidad se espera generen. No todo
está perdido en la ausencia de éste gran recurso. El análisis de las instrucciones compiladas ensambladas
Dirección General de Servicios de Cómputo Académico Subdirección de Seguridad de la Información / UNAM - CERT
Auditorías de Seguridad Informática
puede ayudar a desplegar una historia similar, aunque con un mayor esfuerzo. La evaluación de la
seguridad en el ensamblado, en oposición a nivel de código fuente, normalmente se conoce como
auditoría de binarios.
AUDITORÍA DE BINARIOS
La ingeniería inversa del código se utiliza a menudo como sinónimo de la frase de auditoría de binarios,
pero para nuestros propósitos lo trataremos como una subcategoría para distinguirla de los métodos
totalmente automatizados. El objetivo final del RCE, es determinar la funcionalidad subyacente de una
aplicación de binario compilado. Aunque no es posible convertir un archivo binario de nuevo en su
representación original del código fuente, es posible aplicar ingeniería inversa a las secuencias de
instrucciones en un formato que se encuentra entre el código fuente original y el código de máquina
que hace el archivo binario. En general, éste término medio es una combinación de lenguaje
ensamblador y la representación gráfica del flujo de código dentro de la aplicación.
Una vez que el archivo binario se ha convertido en una forma legible para el usuario, el código se puede
revisar para obtener ubicaciones que podrían contener vulnerabilidades, casi de la misma manera que
una revisión del código fuente. Al igual que con una revisión del código fuente, la localización de
segmentos de código potencialmente vulnerables no es considerada como la revisión final. También es
necesario determinar si un usuario final puede influir en el segmento de código vulnerable. Siguiendo
esta lógica, la auditoría de binarios puede ser referida como una técnica de adentro hacia fuera: El
primer investigador identifica una línea profunda de interés dentro del desmontaje y traza hacia atrás
para determinar si la vulnerabilidad es explotable. La ingeniería inversa es una técnica quirúrgica que
emplea herramientas tales como desensambladores, descompiladores y depuradores. A continuación se
enuncian algunas características que identifican a cada una de ésta herramientas:
Dirección General de Servicios de Cómputo Académico Subdirección de Seguridad de la Información / UNAM - CERT
Auditorías de Seguridad Informática
Dirección General de Servicios de Cómputo Académico Subdirección de Seguridad de la Información / UNAM - CERT
Auditorías de Seguridad Informática
Existen varios depuradores para los sistemas operativos tipo UNIX, con el depurador del Proyecto GNU
(GDB) es el más popular y portátil. GDB es un depurador de línea de comandos que se incluye con
muchos sistemas UNIX / Linux.
Pros y Contras
Como se mencionó, las pruebas de caja gris son producto de una solución híbrida que incorpora las
pruebas tradicionales de caja negro con conocimientos adquiridos de los esfuerzos de RCE. Al igual que
con otros enfoques, las pruebas de caja gris tiene sus ventajas y desventajas. Las ventajas de las pruebas
de caja gris son los siguientes:
Disponibilidad: Con la excepción de los servicios Web remotos y aplicaciones, las
versiones binarias de los programas siempre están disponibles.
Cobertura: La información recogida a través del análisis de caja gris se puede utilizar
para ayudar y mejorar a las pruebas de caja negra, si no es así, se emplea para técnicas
de fuzzing.
Las desventajas de las pruebas de caja negra son las siguientes:
Complejidad: RCE es un conjunto de habilidades especializadas, y por lo tanto, los
recursos podrían no estar disponibles para aplicarse a este enfoque.
AUDITORÍA DE BASES DE DATOS
Dirección General de Servicios de Cómputo Académico Subdirección de Seguridad de la Información / UNAM - CERT
Auditorías de Seguridad Informática
Structure Query Languaje (SQL) es un estándar del ANSI el cual permite tener acceso y manipular
información en las bases de datos. Escribiendo sentencias SQL es posible recuperar o actualizar datos en
las bases de datos así como también modificar su estructura.
Hoy en día existen muchas versiones diferentes de SQL, de hecho, muchas bases de datos han creado su
propio lenguaje SQL “agregándole” más instrucciones al estándar propuesto por ANSI.
El SQL básico incluye un lenguaje de manipulación de datos (Data Manipulation Languaje DML) y uno de
definición de datos (Data Definition Languaje DDL). Cada lenguaje tiene una serio de instrucciones para
cumplir con su objetivo.
Data Manipulation Language
o Select
o Update
o Delete
o Insert into
Data Definition Language
o Create Table
o Alter Table
o Drop Table
o Create Index
o Drop Index
Existen términos clave que son necesarios revisar para entender mejor una base de datos.
Dirección General de Servicios de Cómputo Académico Subdirección de Seguridad de la Información / UNAM - CERT
Auditorías de Seguridad Informática
- Campo. Estructura de datos para una pieza de información simple, por ejemplo en la figura,
Cliente_Llave, Nombre, Apellido y Telefono son campos. En otras palabras cada columna es un
campo.
- Registro. Grupo de datos guardados en un campo.
- Tabla. Grupo organizado de campos usado para guardar información.
- Join. Tablas que pueden ser conectadas con otras tablas para agregar información adicional.
Generalmente las tablas están conectadas a través de una llave, puede ser primara o foránea.
- Tipo de dato. Cada campo tiene un tipo de dato. Por ejemplo, un campo el cual contiene el
nombre podría ser de tipo “String”, el campo para el teléfono podría ser de un tipo de dato
numérico, como Int o Integer, double Integer, decimal, etc.
- Llave primaria. La llave primaria es un campo único que identifica a cada registro.
- Stored Procedures. Son un grupo de sentencias en SQL que pueden ejecutarse conjuntamente.
Estas instrucciones son guardadas en la base de datos por lo que pueden ser invocadas por
cualquier programa.
La sentencia SELECT es usada para obtener información de las tablas de la base de datos. El resultado
del query escrito es guardado en un tipo de dato llamado “result Set”.
El formato para la sentencia select es:
SELECT <campo(s)> FROM <tabla> WHERE <condición>
La clausula WHERE es usada como condicional al seleccionar registros. Los siguientes caracteres son
ejemplos de cómo pueden ser utilizados.
= Muestra los registros que son iguales a la condición específica
<> Muestra los registros que no son iguales a la condición específica
¡= Muestra los registros que no son iguales a la condición específica
> Muestra los registros que son mayores a la condición especifica
< Muestra los registros que son menores a la condición especifica
>= Muestra los registros que son mayores o iguales a la condición especifica
>= Muestra los registros que son menores o iguales a la condición especifica
Dirección General de Servicios de Cómputo Académico Subdirección de Seguridad de la Información / UNAM - CERT
Auditorías de Seguridad Informática
IN Es similar a igual, con excepción de que se pueden incluir una lista de valores
BETWEEN Usa un rango exclusivo que muestra a la salida
LIKE Busca con un patrón específico
AND Requiere dos condiciones para ser verdadero
OR Requiere al menos una condición para ser verdadero
La sentencia UPDATE es usada para actualizar datos en una tabla. Es posible actualizar uno o muchos
registros a través de la sentencia UPDATE, dependiendo de las condiciones aplicadas dentro de la
sentencia WHERE. La sintaxis para la sentencia es:
UPDATE <tabla> SET <campo(s)> WHERE <condición>
La sentencia INSERT INTO permite agregar nuevos registros a la tabla. La sintaxis es la siguiente:
INSERT INTO <tabla> VALUES(<campo(s)>)
Como es posible agregar nuevos campos, también es posible eliminarlos, para ello se utiliza la sentencia
DELETE la sintaxis es la siguiente:
DELETE FROM <Tabla> WHERE <condición>
Además existen otros comandos que permiten otorgar permisos o quitar permisos a diferentes objetos
de la base de datos. Por ejemplo el comando GRANT permite conceder permisos a otro usuario. DENY
permite que un usuario niegue algún tipo de permiso a otro usuario. REVOKE quita los permisos
concedidos con GRANT.
Existen muchos más comandos de SQL sin embargo no es tema de este curso y con los vistos es más que
suficiente para realizar una auditoría para bases de datos.
AUDITANDO BASES DE DATOS
A continuación nos enfocaremos en Oracle, sin embargo, los mismos principios pueden ser aplicados a
otras bases de datos. El nombre de las tablas muy posiblemente cambiará pero los conceptos son los
mismos.
Lo primero es que el auditor se cerciore cerciorarnos que la estructura física de la base de datos se
encuentre segura en el Sistema Operativo, la estructura física es una colección de archivos los cuales
operan tienen la finalidad de ejecutar el sistema, en este caso el sistema es la base de datos. No es tema
de este curso como un sistema operativo guarda de manera segura la información pero en la
documentación de cada base de datos, por lo regular, existe un apartado muy amplio que describe este
punto.
Dirección General de Servicios de Cómputo Académico Subdirección de Seguridad de la Información / UNAM - CERT
Auditorías de Seguridad Informática
Los archivos incluidos en la estructura física de la base de datos son de control y de datos. Los archivos
de control guardan el código ejecutable necesario para el buen funcionamiento de la base de datos. El
query “SELECT * FROM v$controlfile” da información sobre la ruta de los archivos de control. Los
archivos de datos contienen la información actual en bloques de datos. El query “SELECT * FROM
v$datafile” da la ruta exacta de los archivos de datos.
Los archivos de bitácoras son un tipo especial de datos en Oracle para obtener la ruta exacta de donde
se encuentran dichos archivos es necesario buscar en el archivo init<SID>.ora.
Oracle ejecuta archivos que son guardados en el directorio $ORACLE_HOME y subdirectorios de éste
directorio. El $ORACLE_HOME es un directorio que como auditores de seguridad es necesario conocer,
en Unix basta con escribir en la consola “echo $ORACLE_HOME” para que el sistema nos muestre la ruta
exacta.
Solamente los administradores de bases de datos DBA o los administradores del sistema operativo
deberían tener acceso a los archivos que se mencionaron anteriormente.
LISTENERS DE ORACLE
Los listeners son demonios que inician por la utilería de control llamada lsnrctl. Estos demonios se
encuentran escuchando en varios puntos de salida por medio de diferentes protocolos como son IPC,
TCP, TCPS y otros más. Los demonios listeners generalmente corren como procesos del software de
Oracle. Pueden aceptar comandos dinámicos y configuraciones pero únicamente controlado por medio
del archivo de configuración de inicio llamado listener.ora. El cual por lo regular contiene tres secciones
para cada listener.
1) La sección del LISTENER, el cual define las direcciones que estarán escuchando en la entrada con
las direcciones de salida.
2) La sección SID_LIST, la cual describe el tipo de conexión.
3) La tercera sección específica un parámetro para cada listener, como una autenticación o
contraseñas.
El segundo archivo de configuración que nos interesa es sqlnet.ora, para 9i o superiores o protocol.ora
para versiones anteriores. Es posible usar este archivo para definir restricciones por IP así como
controles de acceso a la base de datos.
El listener es un punto de entrada a la base de datos, por lo tanto, es importante asegurarse que los
mismos se encuentren funcionando correctamente y de manera segura. Por ejemplo in listener en
Oracle deberían estar protegidos por contraseña, los accesos deberían tener las políticas de
restricciones ADMIN_RESTRICTIONS. En Oracle 10g, incorpora una arquitectura local de autenticación.
Sin embargo, una contraseña debería aplicar aún así a los listeners.
Dirección General de Servicios de Cómputo Académico Subdirección de Seguridad de la Información / UNAM - CERT
Auditorías de Seguridad Informática
Integrigy proporciona una herramienta para auditar listeners, es muy útil para listeners en versiones
anteriores a 10g. La herramienta revisa vulnerabilidades más comunes en los listeners. Además es una
herramienta didáctica para los auditores ya que proporciona información sobre las vulnerabilidades más
recientes encontradas en los listeners de Oracle.
AUTENTICACIÓN EN ORACLE
Existen múltiples métodos para autenticar una base de datos de Oracle. Autenticación del sistema
operativo, cuando se utiliza este tipo de autenticación es necesario poner especial interés en dos grupos
que son OSDBA y OSOPER, los nombres específicos para estos grupos varían dependiendo de la versión
del sistema operativo, en Windows, los grupos son generalmente ORA_DBA y ORA_OPER.
Los grupos son creados y asignan nombres determinados cuando la base de datos es instalada. Para
Windows es necesario obtener una lista de usuarios y grupos que son parte de los grupos ORA_DBA y
ORA_OPER, para ambientes Unix es necesario listar el /etc/passwd y el /etc/group para saber que
usuarios pertenecen a esos grupos. El parámetro REMOTE_OS_AUTHENT determina que usuarios
pueden conectarse a la base de datos remotamente.
AUTENTICACIÓN EN SQL SERVER
SQL Server tiene dos escenarios de autenticación, autenticación y permisos de validación. El escenario
de autenticación identifica a los usuarios y simplemente verifica sus capacidades para realizar una
conexión. En este sentido los usuarios necesitan los permisos apropiados para tener acceso a las bases
de datos del servidor. La cuenta en cada base de datos es mapeada en cada perfil de usuario.
A su vez existen dos métodos de autenticación para SQL Server:
Modo de autenticación de Windows NT
o Integrado con el SO
o Conexiones seguras
Modo Mixto
o SQL Server Autentication
Conexiones no seguras (¿Porqué?)
Compatibilidad con versiones anteriores
Dirección General de Servicios de Cómputo Académico Subdirección de Seguridad de la Información / UNAM - CERT
Auditorías de Seguridad Informática
Soporte para clientes Windows 95/98
o Modo de autenticación de Windows NT
Una vez que se realizada una conexión exitosa en SQL Server el mecanismo de seguridad para la
transferencia de datos es el mismo en ambos modos.
USUARIOS Y ROLES
Uno de los primeros pasos que se dan cuando se realiza una auditoría es solicitar una lista de usuarios.
Un control normal sería que solo los usuarios que hacen uso de la base de datos se encuentren con
permisos de acceso y los usuarios qua ya no la usan sean eliminados. Además si es posible obtener la
lista de hosts de donde es posible realizar una conexión podría ser un mejor inicio de la auditoría.
En Oracle la tabla dba_users proporciona una lista de usuarios, es necesario verificar los roles con la
ayuda de la tabla dba_roles. Los roles son usados en Oracle para facilitar la delegación de tareas así
como los permisos que los usuarios tienen sobre una lista de objetos.
Existe un rol especial llamado “PUBLIC” el cual aplica a todos los usuarios, por lo tanto, se deberá
realizar una investigación extra para verificar que los roles se den solamente para los accesos
necesarios. Las tablas dba_sys_privs, dba_tab_privs y dba_col_privs pueden proporcionar esta
información.
Roles públicos
o Privilegios del sistema
SELECT * FROM dba_sys_privs WHERE grantee = ‘PUBLIC’
o Privilegios sobre tablas
SELECT * FROM dba_tab_privs WHERE grantee = ‘PUBLIC’
o Privilegios en las columnas
SELECT * FROM dba_col_privs WHERE grantee = ‘PUBLIC’
En SQL Server el rol “PUBLIC” es como el grupo “Everyone” de Windows NT o el grupo “Autenticated
Users”
PERFILES
Los perfiles fueron introducidos en Oracle 7 para limitar la cantidad de recursos del sistema y los
usuarios. En Oracle 8, los perfiles de usuarios soportaban también controles para las contraseñas. Para
controlar el uso de los recursos existen límites de niveles de sesión (sesión level limits) y límites de
niveles de llamadas (call level limits). Los límites de niveles de sesión son impuestos en cada conexión
Dirección General de Servicios de Cómputo Académico Subdirección de Seguridad de la Información / UNAM - CERT
Auditorías de Seguridad Informática
que se realiza, mientras que los límites de niveles de llamadas imponen un límite en cada llamada
realizada. Existe un perfil por default que se crea cuando se instala la base de datos. A menos que el DBA
configure que *no* existan límites de recursos. La información sobre los perfiles se encuentra en la tabla
dba_profiles. Algunos ejemplos de perfiles incluyen:
SESSION_PER_USER
CPU_PER_SESSION
CPU_PER_CALL
CONNECT_TIME
IDLE_TIME
Por ejemplo, si un administrador desea restringir a solo 15 minutos por conexión, podría crear un perfil
para CONNECT_TIME a 15 minutos asignado algún usuario.
PRIVILEGIOS
El auditor necesita buscar que usuarios tienen privilegios de administrador o privilegios especiales.
Existen dos tipos de privilegios que son de especial interés para la auditoría. El primero, privilegios del
sistema; que permitan a algún usuario realizar acciones específicas en la base de datos. Y segundo,
privilegios en los objetos que le permitan acceder o manipular objetos en la base de datos. Hay que
recordar que la tabla dba_roles muestra la información de los roles que cada usuario tiene.
Es necesario poner especial atención en los roles y usuarios que tienen los siguientes privilegios:
SELECT ANY TABLE
CREATE ROLE
ALTER USER
DROP USER
DROP ANY ROLE
ALTER SYSTEM
CREATE PROCEDURE
CREATE LIBRARY
O cualquier privilegio que contenga la palabra “ANY”.
Dirección General de Servicios de Cómputo Académico Subdirección de Seguridad de la Información / UNAM - CERT
Auditorías de Seguridad Informática
Además, la tabla dba_role_privs deberá ser consultada y se tendrá que verificar los privilegios,
considerando usuarios o roles que se les ha concedido permisos como “with admin” o “with grant”.
Las tablas dba_sys_privs y dba_role_privs dan información sobre este tipo de privilegios, por default el
DBA y el rol IMPORT_FULL_DATABASE solamente deberían tienen estos privilegios. El rol DBA necesita
todos los privilegios para el mantenimiento de la base de datos. El rol IMPORT_FULL_DATABASE debe
tener la capacidad para crear o borrar (create/drop) roles y usuarios.
Una vez que se haya verificado la información anterior entonces es necesario continuar con la revisión
de privilegios de sentencias SQL como son; INSERT, UPDATE, DELETE, especialmente en tablas con datos
sensibles. Esta información es posible obtenerla de la tabla dba_tab_privs. Los usuarios normales no
deberían tener acceso a las tablas dba_users, sys.link$, sys.user$, sys.user_history$. Tampoco deberían
tener acceso a las siguientes tablas; dba_%views, v_$ views, v$ _synonyms, x$ o cualquier diccionario de
objetos. A continuación se muestran unas sentencias en SQL que podrían ayudar para obtener esta
información:
Privilegios en el sistema
o SELECT * FROM dba_sys_privs
Privilegios de los roles
o SELECT * FROM dba_role_privs
Privilegios en las tablas
o SELECT * FROM dba_tab_privs
Privilegios en las columnas
o SELECT * FROM dba_col_privs
SQL Server comenzó a utilizar roles a partir de la versión 7.0
PAQUETES
Oracle cuenta con un gran número de paquetes PL/SQL que son públicos, un atacante podría utilizar
estos paquetes si los tiene disponibles. Por lo tanto, es necesario revisar los permisos de esos paquetes y
verificar que el permiso de ejecución PUBLIC no se encuentre concedido. El parámetro utl_file_dir
(SELECT * FROM v$parameter WHERE name = ‘utl_file_dir') controla los directorios que pueden ser
accedidos por el paquete utl_file. Este paquete puede leer y escribir en cualquier directorio, siempre y
cuando tenga los permisos adecuados, si no se encuentra con los permisos correctos, cualquier usuario
podría tener acceso a archivos y directorios donde no debería tenerlo. No es posible borrar el archivo
utl_file, pero si es posible borrar su contenido, estando seguros de que los parámetros utl_file solo se
Dirección General de Servicios de Cómputo Académico Subdirección de Seguridad de la Información / UNAM - CERT
Auditorías de Seguridad Informática
encuentren en directorios donde se necesita y no tener ningún ‘*’, los directorios que comúnmente
deberían contener son “/tmp”, “/”, “.”, “..”.
Los siguientes paquetes también deberán de ser revisados por ejecutarse (EXECUTE) con privilegios
públicos (PUBLIC).
Paquete utl_tcp Permite escribir y leer sockets.
Paquete utl_http Puede escribir en un explorador web.
Paquete utl_smtp Puede enviar correos electrónicos del servidor de base de datos.
DBMS_SQL y DBMS_SYS_SQL Es usado para escribir SQL dinámico.
Cualquier paquete que tenga como dueño sys y privilegios de ejecución PUBLIC.
CUENTAS POR DEFAULT
Las bases de datos son instaladas con muchas cuentas por default, dichas cuentas en ocasiones son
necesarias cuando se está realizando la instalación y tienen nombres de usuario y contraseñas que
asigna automáticamente las cuales es necesario revisar. La mayoría de las cuentas se encuentran
deshabilitadas, sin embargo, los administradores pueden habilitarlas fácilmente. En Oracle existen
docenas y docenas de cuentas por default, el CIS Oracle Benchmark (cisecurity.org) muestra una larga
lista de usuarios y contraseñas por default. Entre los más populares se encuentran:
dbsnmp / dbsnmp
demo / demo
oracle / oracle
scott / tiger
sys / change_on_install
system / manager
En SQL Server la cuenta “sa” por lo regular viene con contraseña en blanco, lo cual es necesario
revisarla. En MySQL tiene la cuenta de root sin contraseña por default.
Además es necesario verificar las aplicaciones que se encuentren corriendo sobre la base de datos, por
ejemplo, si se encuentra ejecutándose la aplicación “SAP” existen muchas más cuentas y contraseñas
por default que son creados los cuales por dicha aplicación y las cuales deberían de ser revisados.
Obviamente, las cuentas y contraseñas por default son diferentes de aplicación a aplicación.
Dirección General de Servicios de Cómputo Académico Subdirección de Seguridad de la Información / UNAM - CERT
Auditorías de Seguridad Informática
CONTRASEÑAS
Una parte muy importante en la auditoría son los parámetros que se tienen en las contraseñas los
cuales deben ser revisados para entender su configuración en el sistema. Las contraseñas deberían de
tener una complejidad, por ejemplo, el historial guardado, la longitud de las contraseñas, el tiempo
mínimo y máximo que la contraseña estará activa. Además las contraseñas deberán estar guardadas
apropiadamente en un formato hash. Además es necesario asegurarse que las contraseñas no se están
enviando en texto claro o con un cifrado débil.
Cuando se estén revisando las políticas de contraseñas, es recomendable que los siguientes parámetros
se estén siguiendo:
FAILED_LOGIN_ATTEMPTS = 3
PASSWORD_GRACE_TIME = 3
PASSWORD_LIFE_TIME = 90
PASSWORD_LOCK_TIME = 1
PASSWORD_REUSE_MAX = 20
PASSWORD_REUSE_TIME = Unlimited
La tabla dba_users contiene una lista de perfiles para cada usuario los cuales han sido asignados. Por lo
tanto es posible obtener información de todos los perfiles usando dicha tabla.
RESPALDOS
Oracle permite a los administradores opcionalmente archivar todos los grupos y archivos de log, sin
embargo, la organización decide si los archiva o no, ya que depende de los recursos disponibles y la
rentabilidad. Si el administrador no puede darse el lujo de perder ningún dato es necesario entonces
usar el modo ARCHIVELOG. El comando “ARCHIVE LOG LIST” se puede ejecutar para verificar dicha
configuración.
Existen además datos importantes que se deberían respaldar como son; políticas, procedimientos, etc.
AUDITANDO LA BASE DE DATOS
Ninguna base de datos o sistema operativo puede guardar todos los registros generados para ser
auditados como resultados de sentencias SQL, privilegios u objetos. Sin embargo, es posible enfocarse
en las siguientes áreas para auditar:
1) DDL auditando sentencias como:
a. CREATE
Dirección General de Servicios de Cómputo Académico Subdirección de Seguridad de la Información / UNAM - CERT
Auditorías de Seguridad Informática
b. ALTER
c. DROP
2) DML auditando sentencias como:
a. INSERT
b. UPDATE
c. DELETE
d. SELECT
e. EXECUTE
3) Eventos del sistema como:
a. LOGON
b. LOGOFF
Algunos usuarios pueden auditar sentencias si tienen el privilegio “AUDIT SYSTEM”, es posible buscar
usuarios que tengan este privilegio en la tabla dba_sys_privs.
Para verificar si la base de datos se está auditando por sí misma, es posible ejecutar el comando “SHOW
PARAMETER” y revisar si el parámetro “AUDIT_TRAIL” se encuentra con el valor “DB” o “TRUE”, si tiene
dichos valores, entonces en la tabla dba_audit_trail es posible revisar el rango de datos que son
auditados.
HERRAMIENTAS
Nmap puede ser usado para verificar puertos abiertos en la base de datos. Nessus tiene igualmente un
gran número de plugins para revisar vulnerabilidades, entre los cuales se encuentran “Oracle tnslsnr
security” la cual revisa remotamente los tnslsnr que no tengan una contraseña asignada.
Igualmente existen herramientas gratis que son proporcionadas por los mismos fabricantes, por ejemplo
Microsoft ha liberado una herramienta llamada SQL Server Analyzer la cual muestra las mejores
prácticas para la base de datos.
OTRAS ASPECTOS A CONSIDERAR
Además de los temas mostrados en el capitulo, existen áreas generales de auditoría las cuales son
necesarias que forme parte de dicha auditoria, estas áreas pueden incluir.
Políticas y procedimientos
Dirección General de Servicios de Cómputo Académico Subdirección de Seguridad de la Información / UNAM - CERT
Auditorías de Seguridad Informática
Parches
Seguridad en el Sistema Operativo
Eliminación de archivos de configuración
Privilegios
Seguridad física
Control de Cambios
Recuperación de desastres
Separación y restricciones entre ambientes de producción y pruebas de desarrollo
Scripts, jobs o archivos batch restringidos y contraseñas en formato no cifrado
AUDITORÍA DE SISTEMAS DE GESTIÓN DE SEGURIDAD DE LA INFORMACIÓN (SEGÚN LA
SERIE ISO/IEC 27001:2005)
El SGSI, Sistema de Gestión de Seguridad de la Información, es el concepto central sobre el que se
construye la norma ISO 27001. Un estándar internacional que certifica y proporciona el aseguramiento
de la confidencialidad, integridad y disponibilidad de la información de las organizaciones. Para
garantizar que la seguridad de la información se gestione correctamente, se debe hacer uso de un
proceso sistemático, documentado y conocido por toda la organización. Este proceso es lo que
establece un SGSI como auditoría.
Una auditoría es una actividad formal, que se realiza utilizando los Sistemas de Gestión de Seguridad de
la Información documentados del auditado. Esto se utiliza como la base para que la auditoría verifique,
o de otra manera, cumpla con los requisitos.
Como parte de este sistema, se realizan las auditorías contra procedimientos escritos o formales con
reportes y registros formales. Se pueden llevar a cabo auditorías a través de todos los niveles de
dirección, pero el principio es la independencia de aquellos que tienen responsabilidad directa por la
AUDITORÍA DE UN SISTEMA DE GESTIÓN
Una investigación sistémica de la intención, la implementación y la efectividad de aspectos
seleccionados del sistema de gestión de una organización, división o departamento.
Dirección General de Servicios de Cómputo Académico Subdirección de Seguridad de la Información / UNAM - CERT
Auditorías de Seguridad Informática
actividad que se está auditando. Esta necesidad no impide que los departamentos lleven a cabo auto
auditorías, pero para fines de garantizas sin temor o favor, y de cumplir con la norma ISO, respecto de
que el Sistema de Gestión de Seguridad de la Información funciona de manera efectiva, la
independencia debe seguir siendo un requisito.
Mucha de la información está disponible durante una auditoría, pero el auditor puede usar sólo lo que
tiene como base los hechos. Si los auditores permiten opiniones como la base para sus conclusiones,
entonces puede haber poco progreso y surgir mucha confusión. Por tanto, sólo se debe utilizar aquello
que ofrece evidencia objetiva. Esta evidencia objetiva puede, por supuesto, ser de muchas formas, y son
datos que respaldan la existencia o verificación de algo. Además, se debe enfatizar que en auditoría, lo
que se audita es el Sistema de Gestión de Seguridad de la Información no la persona que trabaja para
ese sistema.
ETAPAS DE AUDITORÍA
Una auditoría pasa por tres etapas distintas, que el sistema de auditoría debe reconocer. Como ejemplo,
se requiere que una auditoría de un proveedor se lleve a cabo contra ISO 27001:2005.
Dirección General de Servicios de Cómputo Académico Subdirección de Seguridad de la Información / UNAM - CERT
Auditorías de Seguridad Informática
Sería imposible para cualquier auditoría examinar cada actividad individual, cada decisión individual,
cada documento individual, cada proceso, etc. que una organización genere durante una auditoría
simple. La auditoría, por tanto, sólo puede examinar aspectos seleccionados. La auditoría es un ejercicio
de muestro y se debe reconocer por aquellos que realizan la auditoría y por aquellos a quienes se les
aplicará la auditoría en cuestión. Las auditorías no pueden establecer que no hay áreas defectuosas en
AUDITORÍA DE INTENCIÓN O AUDITORÍA DE ADECUACIÓN.
Habiendo establecido esta intención con la dirección del proveedor, el auditor necesita información del proveedor que explique la forma en que cumplen con la norma. Esta evidencia puede presentarse en la forma de un manual SGSI que debe evaluar el auditor para ver si el sistema delineado en el documento cumple con la norma.
AUDITORÍA DE CUMPLIMIENTO O IMPLEMENTACIÓN
En segundo lugar, el auditor necesita visitar al proveedor y determinar el grado al cual la práctica real cumple con el manual.
EVALUACIÓN DE EFECTIVIDAD
Todos los hallazgos de la auditoría se registran y analizan para evaluar el grado al cual el Sistema de Gestión de Seguridad de la Información logra los objetivos declarados.
Dirección General de Servicios de Cómputo Académico Subdirección de Seguridad de la Información / UNAM - CERT
Auditorías de Seguridad Informática
Sistemas de Gestión de Seguridad de la Información. El auditor en las juntas de auditoría debe declarar
este aspecto del muestreo.
TIPOS DE AUDITORÍA
Las auditorías que se llevan a cabo para determinar si una organización cumple con una norma de
Seguridad de la Información se deben denominar como auditorías de Sistemas de Gestión de Seguridad
de la Información. Este tipo de auditorías requiere que el auditor utilice un grado justo de juicio para
establecer si los controles son o no adecuados. Muchas auditorías de segunda y tercera parte se realizan
como auditorías de Sistemas de Gestión de Seguridad de la Información, puesto que hay muchas
auditorías con el fin de consultoría.
Las auditorías que se realizan contra prácticas, procedimientos e instrucciones específicamente
definidos y que quizá estén (aunque no necesariamente), más limitadas en su alcance, se conocen como
auditoría de cumplimiento. Muchas auditorías internas y muchas auditorías relacionadas con contratos
entre dos partes se realizan como auditorías de cumplimiento.
Sin embargo, existen dos tipos básicos, subdivididos aun más de conformidad con los diferentes énfasis
y objetivos. Los dos tipos son auditorías externas y auditorías internas.
Dirección General de Servicios de Cómputo Académico Subdirección de Seguridad de la Información / UNAM - CERT
Auditorías de Seguridad Informática
Un SGSI es implementado principalmente para permitir a la propia organización tener una visión
sistémica de la seguridad de la información, basándose en uno o más estándares internacionales. La
certificación es, por tanto y ante todo, una necesidad interna. El aspecto comercial no es, sin embargo,
completamente irrelevante, más bien en la mayoría de los casos constituye el estímulo principal para
“invertir en seguridad”.
Obtener la certificación significa:
Adherirse a un estándar de referencia (ISO/IEC 27001:2005 O UNE-ISO/IEC 27001:2007).
Analizar, interpretar e implementar lo requerido por el estándar.
Demostrar la conformidad con el estándar por medio de evidencias objetivas.
Demostrar la eficacia del SGSI en alcanzar lo definido en materia de seguridad de la
información.
•Se llevan a cabo por organizaciones independientes externas. Tales organizaciones proporcionan la certificación o el registro de conformidad con la norma ISO 27001.
Auditoría de tercera parte
•Se llevan a cabo por partes que tienen un interés en la organización, tal como los clientes, o por otras personas en su nombre.
Auditoría de segunda parte
•Son aquellas que realiza una organización en sí misma para confirmar a la dirección que su sistema de gestión está funcionando de manera efectiva.
Auditoría de primera parte
Dirección General de Servicios de Cómputo Académico Subdirección de Seguridad de la Información / UNAM - CERT
Auditorías de Seguridad Informática
CERTIFICACIÓN DEL SGSI 27001
El proceso de certificación es el siguiente, una vez la organización ha implementado y operado un SGSI:
Acción Objetivo
Consulta/aplicación Determinar el costo y el número de días auditor requerido para realizar la certificación.
Visita preliminar (opcional) Determinar la situación actual de la implementación del SGSI dentro de la organización previa a las auditorías externas.
Revisión documental (etapa 1) Medir el cumplimiento del SGSI sobre la norma y aportar una retroalimentación de la organización.
Auditoría in-situ (etapa 2) Revisar y confirmar la correcta implantación del SGSI sobre ISO 27001. Auditoría técnica. Reunión de cierre, entrega informe. (No conformidades mayores/menores) (medidas correctoras por la empresa) Propuesta de certificación.
Certificación Evaluación por parte de la Comisión de Certificación. Decisión y notificación. Emisión del certificado.
Visitas de seguimiento (semestral o anual)
Asegurar el cumplimiento continuado del SGSI y ayudar a prevenir cualquier tipo de desviación significativa de la organización.
Auditoría de renovación Combinada con la tercera auditoría de seguimiento del sistema.
Tabla. Proceso de certificación del SGSI.
Dirección General de Servicios de Cómputo Académico Subdirección de Seguridad de la Información / UNAM - CERT
Auditorías de Seguridad Informática
Visita preliminar (opcional)
Revisión documental (etapa 1)
Auditoría de certificación (etapa 2)
Certificación
Visitas de seguimiento
Proceso de certificación de un SGSI
Subdirección de Seguridad de la Información / UNAM-CERT 31/07/2010
Auditorías de Seguridad Informática
65 de 91
ETAPA 1. Revisión documental
Durante esta fase son llevadas a cabo:
La valoración del sistema documental de la organización, según lo previsto por el requisito
4.3.1 del estándar, entre lo que podemos encontrar:
o Alcance de la certificación.
o Análisis y gestión de riesgos.
o Inventario activos.
o Declaración de aplicabilidad (SoA, Statement of Aplicability).
o Manual, políticas de seguridad.
o Procedimientos de seguridad que se consideren oportunos.
o Evaluar ubicaciones.
o Evaluar grado de comprensión del sistema de gestión, conocimiento del personal.
o Auditorías internas y revisión por parte de la dirección.
o Revisión de aspectos legales.
El resultado de estas valoraciones es integrado generalmente en un informe
correspondiente que contendrá los puntos fuertes y los puntos débiles del SGSI.
En caso de resultado negativo, se debe repetir la fase hasta la completa solución de las
situaciones que impiden la continuidad del proceso.
En caso de resultado positivo será redactado el plan para la aplicación de la fase 2 (plan de
la auditoría de certificación) que constituirá la agenda de los encuentros y de los temas
para la auditoría de certificación.
De especial importancia es el hecho de que el SGSI debe demostrar que es conforme y
eficaz en todos sus aspectos. Debe demostrar, por tanto, que ha completado un número
de ciclos suficientes para demostrar también su capacidad para mejorar. En todo caso la
auditoría de certificación de la fase 2 es posible si y solo si:
o Han sido realizadas todas las auditorías internas programadas y necesarias para
que la dirección tenga una correcta visión y conciencia del estado del SGSI en
términos de conformidad y eficacia.
o La dirección ha llevado a cabo la revisión del SGSI durante la cual la dirección se
hace efectivamente consciente de la situación, sobre todo en términos de niveles
de riesgo (residual y aceptable).
Subdirección de Seguridad de la Información / UNAM-CERT 31/07/2010
Auditorías de Seguridad Informática
66 de 91
ETAPA 2. Auditoría de certificación
La auditoría de certificación permite al equipo de auditoría del organismo de certificación valorar
la conformidad y la eficacia del SGSO de la organización. Es importante recordar que las auditorías
de los Organismos de Certificación se desarrollan “en muestra”, es decir, las valoraciones se
refieren solamente a las partes del SGSI verificadas directamente y que, por tanto, la valoración no
ha de considerarse exhaustiva o fiable.
Durante esta visita, el equipo auditor evaluará suficientes ejemplos de las actividades de la
organización para ser capaces de tomar decisiones sobre la aplicación y la eficacia del sistema de
gestión.
Se entrevistará al staff, incluyendo a la alta dirección y personal operativo, para asegurarse
de que el sistema es entendido y aplicado en toda la organización.
El equipo auditor analizará toda la información y las pruebas que se reunieron durante
ambas visitas, para decidir si todos los requisitos de certificación se han cumplido o si no
existen no conformidades. El equipo podría proponer oportunidades de mejora sobre la
base de su experiencia.
Al finalizar la auditoría, será redactado un informe de auditoría que contendrá el resultado
de la valoración realizada, los aspectos susceptibles de mejora y cualquier identificación
de no conformidades. En cualquier caso el informe de auditoría será sometido al Comité
de Certificación del organismo de certificación, órgano titular de la efectiva decisión
respecto a la certificación.
Es obvia, por tanto, la posición del equipo de auditoría, relegada únicamente a la
recopilación y verificación en campo de las evidencias objetivas que comprueban la
conformidad y la eficacia del SGSI. Será en cambio el Comité el que decida sobre el
resultado final.
o En caso de resultado negativo se deberá proceder a corregir las anomalías
encontradas (llamadas, en general, no conformidad y observaciones) antes de
poder repetir la auditoría.
o En caso de resultado positivo la organización recibirá el “certificado ISO/IEC
27001:2005” por el propio SGSI, para las actividades citadas por el campo de
aplicación y referido al perímetro descrito en el mismo. Solo desde ese momento
podrá la organización declarar que tiene un SGSI certificado en conformidad con el
estándar ISO/IEC 27001:2005. El tiempo que transcurre entre el término de la
auditoría de fase 2 y la expedición del certificado puede variar en función del
organismo de certificación. En general, los Comités se reúnen mensualmente,
Subdirección de Seguridad de la Información / UNAM-CERT 31/07/2010
Auditorías de Seguridad Informática
67 de 91
pero, sin embargo, es posible activar procedimientos de urgencia para acortar los
tiempos de emisión (obviamente previo pago de un suplemento de costo).
ETAPA 3. Visitas de seguimiento
Para garantizar que el sistema de gestión sigue siendo eficaz se programarán visitas cada
determinado tiempo, 6 meses o un año. El objetivo de las visitas de seguimiento es confirmar que
el sistema de gestión aprobado:
se mantenga
esté en funcionamiento
entregue mejoras continuas
PROCESO DE AUDITORÍA
Preparar las actividades de auditoría
DESARROLLO DEL PLAN
Está establecido que las razones para realizar auditorías pueden variar, pero el proceso de
preparación y de llevar a cabo las auditorías no varía en absoluto. Lo que difiere es la escala de
esfuerzo requerida. Puesto que las auditorías externas requieren más preparación, esto se debe a
que se debe tener una comprensión de los procesos de la compañía y de la interacción de estos
procesos.
Hay dos aspectos que se deben considerar al momento de planear una auditoría:
•Evaluar a la compañía en cuanto a su grado de cumplimiento con el Sistema de Gestión de Seguridad de la Información.
•Determinar donde está el mayor probelma.
•Determinar la capacidad de la compañía para hacer un producto en particular o entregar a tiempo.
•Hacer seguimiento de no conformidades informadas en una auditoría previa.
Objetivo de la auditoría
•Se determinan las áreas, procesos, productos, servicios, etc. que se quieran revisar más a detalle, o donde se reflejarán los esfuerzos requeridos. Para las auditorías de segunda parte, el alcance lo decide el cliente.
Alcance de la auditoría
Subdirección de Seguridad de la Información / UNAM-CERT 31/07/2010
Auditorías de Seguridad Informática
68 de 91
Habiendo resuelto los parámetros, se puede nominar a la persona que va a gestionar la auditoría.
Esa persona se llama líder del equipo de auditoría y tiene la responsabilidad total de la planeación,
realización y reporte de la auditoría. El líder del equipo debe recibir información sobre los
objetivos y alcance de la auditoría y entonces debe especificar los recursos necesarios para llevar a
cabo la auditoría, en términos de:
días de personal,
número de personal requerido, incluyendo alguno con experiencia técnica especial.
Habiendo aclarado el objetivo, el alcance y los recursos necesarios, el líder del equipo debe
comunicarse con el auditado. Con frecuencia los contactos iniciales se establecen mediante la
respuesta la respuesta a un cuestionario por parte del auditado. Esto puede proporcionar
información relacionada con el tamaño de la compañía, gama de productos, nombres, domicilios,
contactos, etc.
Es benéfico para ambas partes tener una junta preliminar en el sitio donde tendrá lugar la
auditoría. Las auditorías de tercera parte con frecuencia incluyen una visita preliminar, y los costos
se establecen en la propuesta inicial. El objetivo de la visita preliminar es:
Aclarar el alcance y el objetivo de la auditoría.
Convenir los procedimientos que deben adoptarse durante la auditoría.
Resolver los malos entendidos.
EL PROGRAMA DE AUDITORÍA
Después de haber estado en contacto con la organización a ser auditada, y quizá haber hecho una
visita preliminar, podría ser que el auditor hubiere recibido un ejemplar de su manual SGSI. Este
manual contiene el proceso dentro del Sistema de Gestión de la Información de la organización y
la interacción del proceso descrito. A partir de este documento el líder del equipo de auditores
deberá elaborar un programa de auditoría, detallando el departamento/proceso a ser auditado y
en qué día y a qué hora. El programa también identificará al auditor asignado a cada
departamento/proceso.
PREPARACIÓN DE LAS LISTAS DE VERIFICACIÓN
El principal objetivo de las listas de verificación es asegurar el nivel de detalle y continuidad de la
auditoría y ayudará a ahorrar tiempo durante la misma para poder llegar a una conclusión
informada. Sin embargo, la compañía que conduce la auditoría por lo general define el formato de
la lista de verificación.
Subdirección de Seguridad de la Información / UNAM-CERT 31/07/2010
Auditorías de Seguridad Informática
69 de 91
Para poder emitir ese juicio informado, los auditores deben de tomar muestras de las áreas
seleccionadas y verificar la implementación y eficacia en dichas áreas. Por lo tanto, las listas de
verificación deben ser lo más representativas posibles y tomar en cuenta los objetivos de la
auditoría.
Las listas de verificación no deben de ser un recordatorio y conjunto de respuestas de si/no. Debe
ser considerado como “ayuda de la memoria”.
Muchas de las preguntas más detalladas que se necesitan son las que se emplean en la lista de
verificación de auditoría. Se muestra su diagrama a continuación:
EJEMPLO:
Área auditada Ventas – Proceso de solicitudes de pedidos
Revisar: Elaboración de una solicitud de pedidos.
Buscar: Productos que se incluyan.
Buscar: Justificación de algún producto que no se incluya.
Buscar: Registros de revisión de los productos.
Buscar: Registros que autoricen la aceptación de los pedidos.
Resultados de la auditoría
Evaluación de conformidad
La evidencia objetiva de la auditoría
Preguntas de auditoría
Lista de verificación de los criterios (requisitos convertidos en preguntas) Lista de verificación de auditoría (ayuda a la memoria)
ISO/IEC 27001:2005
Subdirección de Seguridad de la Información / UNAM-CERT 31/07/2010
Auditorías de Seguridad Informática
70 de 91
Un buena guía para la preparación de las listas de verificación es pensar en términos de “qué
revisar” y “qué buscar”. Se podría revisar
Algunos de los pasos que se recomiendan para la preparación de las listas de verificación:
Claridad mental de los objetivos de la auditoría.
Hacer que la muestra sea representativa.
Determinar cuál es la actividad principal del área.
Los sistemas de cualquier organización funcionan bien cuando se encuentra personal clave
y no hay nadie ausente, enfermo o de vacaciones.
o ¿Qué ocurre cuando falla el sistema?
o ¿Qué medidas se toman para solucionar la falla?
Beneficios de las listas de verificación:
Es una muestra relevante a los objetivos de auditoría.
Formalidad, define el procedimiento de auditoría.
Requiere de investigación.
Ayuda a mantener el ritmo de la auditoría.
Mantiene claros los objetivos de la auditoría.
Referencia histórica como registro de auditoría (reporte).
Reduce la carga de trabajo del auditor durante la auditoría.
Le asegura al auditado el profesionalismo del auditor.
Asegura que los auditores tengan el proceso en mente.
Desventajas de las listas de verificación:
Puede convertirse en un recordatorio.
Llenas de preguntas que se contestan con un sí/no.
Si hay algo que no se haya incluido en la lista de verificación no se revisa
Trunca la iniciativa y el análisis del proceso
Métodos de identificación, aprobaciones, etc.
Documentos, registros, producto o equipo para determinar si se aprobaron, si la documentación está comlpleta y concluir sobre su condición.
Sistema de auditorías internas y buscar documentos de sus autoridad, capacitación de los auditores, medidas oportunas sobre los hallazgos, seguimiento, etc.
Subdirección de Seguridad de la Información / UNAM-CERT 31/07/2010
Auditorías de Seguridad Informática
71 de 91
RESUMEN
REALIZAR LAS ACTIVIDADES DE AUDITORÍA
La realización de auditoría se conforma de varios eventos diferentes y se tratará cada uno de ellos
por separado:
a) Junta de apertura.
b) Conducción de la auditoría.
c) Registro de los hallazgos positivos y negativos.
d) Planeación de la junta de cierre.
e) Junta de cierre.
Junta de apertura
La junta de apertura, que a veces se conoce como referencia previa a la auditoría o junta inicial,
por lo general se realiza en el lugar dónde se llevará a cabo la auditoría. Las buenas prácticas
exigen que todos los auditores dele quipo lleguen juntos, a tiempo, ni temprano ni tarde.
Esta junta como cualquier otra, requiere de la preparación del líder del equipo. Por lo general, se
realiza en la oficina del gerente o en la sala de conferencia de la organización. Es común que algún
miembro de la gerencia del auditado de inicio con unas palabras de bienvenida y la introducción.
Consideraciones de planeación:
Establecer el propósito de la auditoría
Definir el alcance de la auditoría
Identificar los procesos
Identificar la interacción de los procesos
Determinar la base/criterios de auditoría
Designar al líder del equipo
Determinar la escala de la auditoría y los recursos que se necesitan
Considerar los resultados pasados (si están disponibles)
Considerar los problemas actuales
Considerar inquietudes de la gerencia
Considerar las prioridades de la gerencia (en caso de ser conveniente)
Contactar al auditado y acordar la(s) fecha(s)
Visita (preliminar) al auditado
Preparar y acordar el programa
Reuniones informativas del equipo de auditoría
Preparar listas de verificación
Subdirección de Seguridad de la Información / UNAM-CERT 31/07/2010
Auditorías de Seguridad Informática
72 de 91
El equipo está preparado con la agenda, la que asegura que se cubran todos los puntos necesarios
de manera rápida y eficiente. Los puntos que se deben de tratar incluyen:
Figura X.X Junta de apertura.
•El líder debe presentar al equipo de auditoría y explicar cómo están organizados, si existe más de un grupo, los peritos del grupo, etc. Un requisito normal es que los asistentes a esta junta se registren.
•El programa se tiene que haber discutido, desarrollado y acordado con el auditado. Sin embargo, tal vez sea necesario modificar los planes ligeramente lo que se debe cubrir en ese momento.
•El líder del equipo necesita determinar, si no se lo han indicado previamente, quiénes son los guías que los acompañarán. La función del guía debe quedar bien clara.
•Con esto se cubren todos los otros preparativos como: el transporte, ropa especial, comida y oficina para los auditores. Se deben confirmar las comidas. Por lo general, se trata de comida en las mismas instalaciones o una comida externa de poca duración.
•Es posible que los auditados quieran hacer algunos comentarios y el líder del equipo debe escucharlos. Asimismo, el líder del equipo necesita confirmar el estatus actual de los documentos clave como los manuales, etc.
•El líder del equipo necesita explicar el método de registrar las no conformidades y presentar el reporte de auditoría, que entregarán los auditores al final de la misma.
•La auditoría tiene carácter confidencial para ambas partes. Lo mismo para cualquier información que pueda surgir antes, durante y después de la auditoría. Esta confidencialidad es obligatoria para los auditores de tercera parte.
•A pesar de que cualquier restricción mayor por lo general se les indica a los auditores en la etapa de planeación, tal vez sea necesario confirmarlas y aclararlas en este momento. Estas restricciones incluyen áreas limpias/peligrosas a donde se tiene que usar ropa especial de protección.
Subdirección de Seguridad de la Información / UNAM-CERT 31/07/2010
Auditorías de Seguridad Informática
73 de 91
Otros puntos que pueden surgir pueden poner nervioso a un líder de equipo sin experiencia. Los
auditores encuentran que cada auditoría es diferente y es esencial contar con cierto grado de
flexibilidad. Por ejemplo, una organización que está acostumbrada a que la auditen los clientes no
requerirá de muchas explicaciones sobre la auditoría, a pesar de que solicitarán ciertas garantías.
El líder del equipo debe de dejar en claro que la auditoría es una actividad de muestreo y está
sujeta a esas limitaciones. Un buen comentario es: “Esta evaluación se basa en las muestras
representativas y por lo tanto, es posible que existan no conformidades que no se hayan
identificado”.
Conducción de la auditoría
Entonces comienza la auditoría. En la conducción de la auditoría podemos encontrar la
intervención de las siguientes personas:
Para la realización de la auditoría se debe considerar lo siguiente:
El líder del equipo y el otro auditor
El guía
El/la representante de la gerencia
El personal de las áreas que se están auditando
Los observadores que acompañan al grupo de auditoría (tal vez auditores en capacitación de
la organización de los auditores o auditados o un auditor que audita al auditor)
El/la intérprete (si la auditoría es en un país del cual los auditores no hablan el idioma
•El líder del equipo es responsable en todo momento de mantener el control de la auditoría. La experiencia les ayuda a los auditores a desarrollar su propio estilo al trabajar en un área y adaptar las distintas técnicas conforme lo requiera cada situación.
•Al llegar a un área el líder del equipo debe repasar el plan de auditoría de esa área con el representante del departamento y el guía.
•La cantidad de tiempo que el auditor debe dedicar a hablar con la gerencia de cada área depende de cuánta información tuvo el auditor disponible originalmente.
•En el contexto de las auditorías, el concepto de la evidencia objetiva es muy similar al concepto de perito testigo en un tribunal. Una buena práctica de auditoría es buscar, en la medida de lo posible, el respaldo en la documentación para toda la evidencia obtenida verbalmente.
Control de la auditoría
Subdirección de Seguridad de la Información / UNAM-CERT 31/07/2010
Auditorías de Seguridad Informática
74 de 91
•Únicamente los auditores con más experiencia toman suficientes notas de los aspectos relevantes que han visto y oído durante la auditoría. Obviamente que se trata de una técnica de extrema importancia que se tiene que desarrollar. Los auditores debe registrar suficiente información para emitir un juicio informado con base en las notas adecuada que contengan hecho considerables.
•Se deben tomar notas de las referencias a los documentos, identificación de rubros, comentarios, quién los dijo, puestos, preguntas relevantes que se formularon. etc. Esta información debe ser legible y poder recuperarse.
•Las notas del auditor de una auditoría siempre será parte del sistema de registros y como tal, se debn conservar por un periodo determinado.
•Cada auditor debe decidir sobre el formato de las notas y el medio en que las tome.
Toma de notas
•Quizá el desafío más grande para el auditor es el hecho de que encontrar la información depende, entre otras cosas, de las habilidades de comunicación.
•El principal método de solicitar información es haciendo preguntas en una serie de entrevistas. Aunque no siempre se aprecia, los mejores entrevistadores son los que dicen poco y tienen la habilidad de escuchar u oír lo que se dice.
•Se ha observado que el auditor debe entrevistar a la gente correcta, esto es, la gente que tiene control sobre el aspecto del sistema que se audita.
•El entrevistador (el auditado) no debe sentirse amenazado por el auditor. Mucha gente se intimida fácilmente ante los auditores. El auditor puede evitar generar este tipo de sentiemiento siendo correcto, paciente, ligeramente informal y sin temor a sonreír. Demostrar interés en lo que dice la gente es esencial.
•Con frecuencia sucede que el auditado entiende incorrectamente una pregunta o está determinado a halarle al auditor sobre algún otro asunto. Puede incluso decir algo que el auditor sabe que no es cierto. Si el auditor interrumpe abrupta o contradice directamente al auditado, no continuará la comunicación fácil.
•Al final de la entrevista el auditor debe agradecer a todos los auditados por su ayuda y tiempo, no obstante si fue benéfico o no.
Entrevista de auditoría
Subdirección de Seguridad de la Información / UNAM-CERT 31/07/2010
Auditorías de Seguridad Informática
75 de 91
•Toda auditoría realizada en cualquier parte tiene un objetivo. Los auditores que pierden de vista esto no serán eficaces. Le va mejor si hacen dos preguntas a que se pierdan porque sólo hicieron una. La calidad de la auditoría se puede considerar en términos del logro de objetivos. La capacidad de descubrir información de relevancia depene de la capacidad de hacer las preguntas correctas.
•Existen diferentes tipos de preguntas:
•Preguntas con tema: establecen un tema muy claramente antes de hacer la pregunta, es decir, "Hablando de validación de software, ¿cómo hace usted...?"
•Preguntas expansivas: amplían la conversación y crean un alto nivel de empatía debido a que demumestran que el auditor está interesado en los puntos que el auditado ha planteado. Con frecuencia puede aclarar áreas vagas para el auditor así como aclarar la percepción del auditado, "¿Qué importancia tiene para usted que se notifique este tipo de procedimiento...?"
•Preguntas de opinión: existe el peligro en alejarse mucho de los hechos, pero este tipo de preguntas pueden ser de mucha ayuda para obtener la atención de alguien o para obtener nuevos enfoques a la resolución de problemas. Indican que el auditor considera el punto de vista del auditado algo importante, y por tanto aumento la auto imagen del auditado y tiende a decir más.
•Preguntas de investigación: son muy útiles cuando el auditor no estpa seguro si el auditado ha comprendido totalmente lo que se ha dicho, pero no necesariamente es obvio que el auditor se de cuenta.
•Preguntas no verbales: pueden parecer una contradicción de términos, pero existen preguntas en este formato. Por ejemplo, levantar las cejas mientras se mantiene contanto con la vista puede indicar una indicación para que el auditado continúe. También permanecer en silencio una vez dada la respuesta, continuar mirando al auditado con expectativa alienta a la gente a seguir hablando sin interrupción verbal y es otra señal de "transmisión recibida".
•Preguntas repetitivas: se utilizan para ganar tiempo, ya que mantienen la conversación. Por ejemplo un auditado podría decir, "no creo que sea necesario un procedimiento escrito" y el auditor pregunta "¿No cree que un procedimiento escrito sea necesario?". El auditado se ve obligado a responder la pregunta.
•Preguntas hipotéticas: es razonable preguntar a la gente qué haría si no se recibe una instrucción o si personal clave no está disponible, etc. No es razonable agregar un conjunto complicado de posibilidades sobre la remota oportunidad de que esto causaría un problema.
•Preguntas cerradas: Son las que pueden responderse "sí" o "no". Están basadas en supuestos y pueden ser muy poderosas. Deben ser utilizadas para verificar que el auditor ha comprendido claramente lo que se ha explicado.
•Preguntas dirigidas: se utiliza cuando se requiere una respuesta rápida y el auditor desea sugerir la respuesta correcta. Por ejemplo, "¿Entonces usted iniciará esta acción correctiva e informará en un plazo de dos semanas...?" Las preguntas dirigidas son comunes en malas auditorías y raras en las buenas.
•Sin duda, la capacidad de hacer las preguntas del tipo correcto es una de las herramientas más poderosas en la caja de herramientas del auditor.
Técnicas de cuestionamiento
Subdirección de Seguridad de la Información / UNAM-CERT 31/07/2010
Auditorías de Seguridad Informática
76 de 91
•Con el fin de obtener los hechos y suficientes para llegar a una conclusión, los auditores deben examinar la forma en que se controlan los procesos. Sólo los auditores pueden decirdir cuantas muestras deben tomarse.
•Por lo general las muestras deben ser representativas, deben elegirse aleatoriamente. Una forma de hacer es que el auditor haga la selección de muestras. En la medida en que se reciba permiso de la dirección, el auditor puede seleccionar muestras. En la medida en que se reciba permiso de la dirección, el auditor puede seleccionar las muestras. Las muestras pueden ser personas.
•Cuando el auditor solicite y reciba permiso, es un buena práctica auditar donde tiene lugar la acción y hablar con la gente que hace el trabajo.
•De manera natural, el tipo de evidencia que se produce con frecuencia es lo que muestra una falla del sistema o una falta de control de la dirección. Mientras el auditor permanezca objetivo, sea abierto con la gente con quien tenga contacto, e invariablemente diplomático en sus peticiones de información, no debe haber dificultad en convenir en esos aspectos con las personas responsables.
Verificación
•Una persona realiza muchas auditorías y las auditorías así realizadas se llevan a cabo de manera correcta y satisfactoria para todas las partes. En muy común en auditorías internas (primera parte) que la auditoría la realice una sola persona. También es común en la mayoría de las auditorías de tercera parte realizadas con fines de registro a ISO 27001:2005 que los auditores operen de manera individual. Teniendo en cuenta que el proceso de evaluación en este caso lo paga el auditado, entonces este enfoque será el más costeable.
•Algunas ventajas para incluir a una segunda persona al equipo de auditoría son las siguientes:
•imparcial
•agrega objetividad
•anota observa, escucha
•corrobora
•comparte liderazgo
•lleva control del tiempo
•experiencia personal
Equipos de una/dos personas
Subdirección de Seguridad de la Información / UNAM-CERT 31/07/2010
Auditorías de Seguridad Informática
77 de 91
Registro de los hallazgos positivos y negativos
A medida que procede la auditoría, pueden surgir situaciones donde los hechos indican que existe
una falla ya sea de todo o parte del sistema. Esto recibe muchos nombre en auditoría, pero se
conocerán como “no conformidad”.
Durante una auditoría surgen muchas situaciones que tienen el potencial de convertirse en no
conformidades. Tan pronto como los he hechos indican una no conformidad, los auditores de
inmediato externarán sus creencias al representante del departamento. Es esencial que ambas
partes comprendan cabalmente cual es el problema y su seriedad.
Una vez que los hechos sobre el asunto se establezcan, el auditor debe escribirlos y convenirlos
con el auditado para hacerlo.
La declaración de no conformidad debe estar en un formato que puedan entender tanto las
personas en la auditoría como aquellos que no están en ella. La gente que no estuvo presente en
la auditoría con frecuencia tomará la acción correctiva necesaria. Esta necesidad por sí sola define
algunas reglas para el registro de no conformidades.
¿Qué es una no conformidad?
Una condición adversa a la Seguridad de la Información
Un incumplimiento de un requisito o Condiciones de un contrato o Norma SGSI o Manual SGSI o Procedimientos o instrucciones de trabajo
Habrá una no conformidad por una de tres razones:
a) El procedimiento escrito no cumple con los requisitos de la norma; b) El procedimiento escrito no se ha puesto en práctica en la forma descrita por el
procedimiento; c) La práctica (lo que de hecho se hace) no es efectiva, es decir, no se produce el resultado
requerido.
Subdirección de Seguridad de la Información / UNAM-CERT 31/07/2010
Auditorías de Seguridad Informática
78 de 91
Ejemplo de una no conformidad:
o El procedimiento XXXX Control de documento versión 2.3.2 tenía como última
fecha de revisión el 25 de enero de 2010, pero en la lista maestra XXXX versión
1.1.5 se encontraba registrada con fecha 15 de enero de 2010.
En este ejemplo se está incumpliendo el requisito de la norma 4.3.2 c) asegurar que se
identifiquen los cambios y el estatus de la revisión actual de los documentos.
El número de no conformidades que pueden surgir en una auditoría puede ser copioso. Sin
embargo, es poco probable que éstas sean igualmente serias.
Observación exacta de los hechos – solo se necesitan hechos, y la información de los
mismos debe ser exacta.
Donde se encontró – la declaración debe identificar exactamente donde se encontró, de
otra manera no se podrá volver a encontrar.
Qué fue lo que se encontró – debe ser claro de manera que la gente comprenda cual es el
aspecto no conforme.
Por qué es una no conformidad – la declaración debe dejar claro cual requisito específico se
ha incumplido.
Quién estuvo ahí – la declaración con frecuencia no requiere implicar personas
específicamente, pero donde la evidencia objetiva tuvo como base una declaración,
entonces la declaración y su originador deben estar claros. Se deben utilizar los cargos, no
los nombres.
Usar la terminología local – la industria tiene sus propios nombres para ciertas actividades,
documentos, etc., los cuales deben utilizarse.
Hacerla recuperable – alguien debe regresar después de la auditoría y corregir las cosas,
posiblemente algún tiempo después.
Hacerla útil – es necesario prestar atención a este punto, pero la declaración debe señalar lo
que debe exigirse. No se recomiendan las sugerencias, especialmente en auditorías
externas, ni son obligación de los auditores.
Subdirección de Seguridad de la Información / UNAM-CERT 31/07/2010
Auditorías de Seguridad Informática
79 de 91
La mayoría de los organismos de certificación clasifican las no conformidades como NO
CONFORMIDAD MENOR o MAYOR, y tienen sus propios criterios definidos para cada una.
También es una práctica común que los auditores levanten OBSERVACIONES, las cuales son puntos
de inquietud, pero para los cuales existen insuficiente evidencia objetiva para levantar una no
conformidad. Las observaciones son una forma adicional mediante las cuales los auditores pueden
considerarse de ayuda.
Revisión con el auditado
Es una buena práctica y se está volviendo una costumbre asignar un tiempo final de cada día, o al
principio, en el cual actualizar a esa persona sobre los “problemas/no conformidades levantados”,
las dudas, el avance de la auditoría, cambios propuestos al plan, etc.
Estas juntas generan entendimiento entre los auditores y los representantes de la dirección y
pueden desarrollarse a una relación útil en virtud de la cual se puede intercambiar información
que sea de beneficio para ambas partes. Hay que recordar que las auditorías no están diseñadas
sólo para encontrar no conformidades. Donde se han presenciado conformidades, también deben
informarse.
Reacción de auditados
En cada auditoría que se realiza se pueden encontrar una gran variedad de reacciones por parte de
los auditados, desde una hostilidad abierta hasta la colaboración voluntaria. Aunque se debe decir
que a medida que las organizaciones se dan cuenta cada vez más de los beneficios de ISO
27001:2005, las reacciones negativas por parte de los auditados se están reduciendo, y
normalmente ocurren cuando se enfrentan a un auditor negativo.
Una selección de reacciones es la siguiente:
NO CONFORMIDAD MAYOR – Una interrupción en el sistema de gestión para controlar eficazmente
los procesos para los cuales se estableció, o una situación donde se entregaría el producto o servicio
no conforme una situación en la cual, sobre la base de evidencia objetiva, se presente una duda
importante respecto de la capacidad del sistema de gestión para lograr la política y objetivos de la
organización.
NO CONFORMIDAD MENOR – Un lapso simple identificado, que en sí no es conducente ya sea a
productos o servicios suministrados no conformes, o presenten duda importante respecto de la
capacidad del sistema de gestión para lograr la política y objetivos de la organización.
Subdirección de Seguridad de la Información / UNAM-CERT 31/07/2010
Auditorías de Seguridad Informática
80 de 91
Autoridad – Esto puede funcionar en ambos sentidos. Algunos auditados se vuelven
protectores de sus departamentos o compañía y tratan de “intimidar” al auditor. El auditor
debe insistir firme, pero diplomáticamente, si es necesario, en que se le muestre respeto. El
auditor debe ser paciente y educado y, cuando sea necesario, empático.
Antagonismo – Por cualquier razón, en ocasiones los auditados pueden volverse hostiles y
agresivos hacia los auditores. Naturalmente los auditores deben ignorar cualquier grosería
por parte del auditado, pero pueden tener que invertir un poco más de tiempo en el área,
con paciencia, firmeza y diplomacia como sus principales defensas.
Tácticas distractoras – Estas pueden ser muchas y variadas. Cualquier cosa que necesite un
tiempo que estaba planeado de otra forma para auditoría puede incluirse aquí. La gente en
ocasiones puede ser bien intencionada, pero si pasan mucho tiempo explicando cosas que
no les han preguntado, se les debe detener diplomáticamente. También deben evitarse
comidas largas ya que absorben tiempo y no benefician a la auditoría. De manera similar, se
puede perder mucho tiempo mientras el guía responde el teléfono.
Información que se presenta de manera voluntaria – Los auditores reciben muchos datos
durante una auditoría. Esperan obtener la información que desean en una forma eficaz. En
ocasiones la gente les da información que no han solicitado, quizá sobre una falla por parte
del Sistema de Gestión de Seguridad de la Información. Puede ser una “pista falsa” que
consuma mucho tiempo y no lleve a ninguna parte. Puede ser importante y relacionado con
el objetivo de la auditoría. Sólo los auditores con experiencia tenderán a tomar la decisión
correcta aquí.
Conflictos internos – Las auditorías pueden ser estresantes para todos los implicados y en
ocasiones los hallazgos durante una auditoría instigan una pelea entre los integrantes del
personal del auditado. La auditoría no es el lugar para esto, y el auditor debe usar un poco
de tacto para calmar la situación, para no involucrarse y continuar con la auditoría.
Desafío continuo – Los auditados tienen el derecho, y de hecho el deber, de impugnar a los
auditores si llegan a conclusiones sobre la base de información infundado. Esto puede
ocurrir donde no se explicó cabalmente a los auditores sobre las condiciones de contrato, los
requisitos de productos y si se apartan de la evidencia objetiva.
Enlistar ayuda – En algunas compañías, el personal SGSI con frecuencia guía a los auditores
externos por las instalaciones durante una auditoría, y con frecuencia se desarrollar una
relación cordial. Si la gente del SGSI está encontrando que es difícil que se toma la acción
correctiva, pueden conducir a los auditores a las áreas deficientes.
Subdirección de Seguridad de la Información / UNAM-CERT 31/07/2010
Auditorías de Seguridad Informática
81 de 91
Planeación de la junta de cierre
Antes de la junta de cierre, pero inmediatamente después de que se termina el proceso de
auditoría se debe realizar una junta del equipo de auditoría con el objetivo de que el líder del
equipo pueda planear en detalle la junta de cierre y se asegure de que el equipo sepa lo que se va
presentar a la compañía en forma de no conformidades y resumen. La junta del equipo debe tener
lugar por lo menos una hora antes de la junta de cierre, a menos que parte del trabajo ya se haya
terminado la noche anterior, por ejemplo.
El líder del equipo preside la junta del equipo de auditoría y tiene algunos puntos que se deben
cubrir.
No hay una regla establecida sobre quien presenta la información. El líder del equipo puede
presentar todo, todas las no conformidades y el reporte, o se puede solicitar a los integrantes del
equipo que presenten las no conformidades que encontraron.
Como resultado de los hallazgos del “equipo de revisión” el líder del equipo elabora un reporte de
auditoría. Este reporte refleja el grado al cual una compañía cumple con su propio sistema
documentado y la norma relevante.
Como sugerencia, un líder del equipo podría responder tres preguntas hechas sobre el sistema en
alguna auditoría:
a) ¿Existe un sistema documentado que aborde todas las cláusulas de la norma relevante?
¿En qué medida? (auditoría de intención)
b) ¿Se ha puesto en práctica este sistema documentado? ¿En qué medida? (auditoría de
implementación)
c) ¿El sistema está logrando objetivos? ¿En qué medida? (auditoría de efectividad)
El líder del equipo también elabora una agenda para la junta de cierre y hace los arreglos, ya sea
mediante un integrante del equipo o una guía, para que se entreguen copias de cada problema/no
conformidad para que se entreguen a la dirección de la compañía en el momento oportuno.
Junta del equipo de auditoría:
Controla el líder del equipo.
Solo está presente el equipo de auditoría.
El equipo llena reportes de problemas/no conformidades.
Revisión del equipo de todos los problemas/no conformidades.
El líder del equipo elabora el reporte de auditoría.
Subdirección de Seguridad de la Información / UNAM-CERT 31/07/2010
Auditorías de Seguridad Informática
82 de 91
A medida que la auditoría se acerca a las etapas de conclusión, los auditores pueden acumular
gradualmente una imagen de áreas o sistemas que exhiben la mayoría de las fallas. La información
para proporcionar esto procede de los hallazgos durante la auditoría, pero es necesario elegirla de
manera que pueda entonces buscarse una conclusión razonable:
Número de no conformidades levantadas;
Número de problemas/levantados durante la auditoría de intención;
Número de problemas/no conformidades levantados durante la auditoría de
implementación;
Número de problemas/no conformidades relacionados con la efectividad del sistema;
Número de problemas/no conformidades levantados contra cada cláusula de la norma;
Número de problemas/no conformidades en cada departamento o área de
responsabilidad
Con base en esto, surge una imagen de los tipos de fallas encontrados, su frecuencia relativa,
donde se encontraron en la compañía y el requisito de sistema de gestión más débil. Sin embargo,
esta no es la única información que el auditor debe considerar. Una imagen adicional puede surgir
a partir de un examen de lo siguiente:
Fallas internas – ¿Cuántas modificaciones a planos, especificaciones, órdenes de
compra se hacen que se deberían evitar?
Fallas externas – ¿Con qué frecuencia los clientes presentan quejas y/o
devuelven el producto? ¿Existe un departamento grande de devoluciones?
Auditoría – ¿Las auditorías internas y externas recientes establecieron muchos
problemas/no conformidades?
Tendencias e implementaciones – ¿Consideran algo o todo lo anterior en
revisiones para establecer la forma en que deben cambiarse sus sistemas para
evitar los mencionados eventos en el futuro?
Acción correctiva – ¿Ha habido alguna evidencia para demostrar que opera un
sistema sólido y eficaz para corregir las cosas que están mal o para garantizar
que así siguen?
Actitud de la dirección – ¿La alta dirección conoce los resultados de auditorías, o
el nivel de defectos de un producto, o el costo de violaciones a la seguridad?
Subdirección de Seguridad de la Información / UNAM-CERT 31/07/2010
Auditorías de Seguridad Informática
83 de 91
Una vez que el equipo de auditoría ha terminado su agenda el líder de equipo de auditoría debe
elaborar las recomendaciones del equipo.
A ningún líder de equipo le gusta ser el portador de malas noticias. Un auditado podría haber
asignado muchos recursos durante mucho tiempo para poder instalar el Sistema de Gestión de
Seguridad de la Información. Pero si se ha identificado una no conformidad, es probable que el
líder del equipo de auditoría pudiera no tener otra alternativa que recomendar una re-evaluación
completa.
Junta de cierre
La junta de cierre es la junta de conclusión de la auditoría y es la presentación formal por parte del
equipo de los hallazgos y conclusiones de la auditoría.
En la medida en que la dirección del auditado comprenda los hallazgos y esté de acuerdo con los
hechos que los rodean antes de que el equipo se retire, el líder del equipo y el equipo habrán
cumplido con su tarea.
a) Recomendar registro. Esta puede ser la recomendación del equipo cuando no se encuentran no conformidades, o se encuentra una cantidad mínima de problemas. En el último caso, se dará seguimiento a las acciones correctivas tomadas para abordar los problemas durante la primera visita de evaluación continua.
b) Recomendar, sujeto a la recepción de un plan de acción correctiva aceptable. Cuando se ha identificado un número de problemas, el líder del equipo de auditoría probablemente presente esta opción al auditado. Cuando lo haga, el líder del equipo establecerá el plazo en que se debe presentar el plan de acción correctiva al organismo de registro. Se pondrá mayor énfasis al tiempo que requiera el auditado para implementar la acción correctiva más que concentrarse en la acción correctiva planeado en sí. Después de todo, en algunos casos es posible que el auditor no conozca la mejor acción correctiva por tomarse, sino que se concentre en el tiempo que requiere un compromiso para que se logre la Seguridad de la Información.
c) Re-auditorías parciales. En situaciones en que el resultado de la auditoría sea de no conformidad, o bien una cantidad importante de problemas, entonces el líder del equipo de auditoría probablemente recomiende esto. Lo anterior entonces sólo se concentraría en las áreas en las cuales se encontraron las no conformidades.
Subdirección de Seguridad de la Información / UNAM-CERT 31/07/2010
Auditorías de Seguridad Informática
84 de 91
De inmediato en la hora previamente acordada el equipo debe estar disponible para la junta. El
líder del equipo encabeza la reunión. El líder del equipo debe tomar la iniciativa y seguir la agenda
elaborada durante la junta del equipo de auditoría.
Los siguientes se deben cubrir en cierta forma.
1. Lista de asistentes a la junta de cierre
El líder del equipo o el segundo auditor distribuye una lista con nombre y cargo que debe
firmar cada asistente.
2. Agradecimiento
El líder del equipo debe agradecer a la compañía a nombre del equipo por su ayuda a
tiempo, etc. Si la auditoría se realizó de manera abierta por parte de la compañía, el líder del
equipo debe decirlo y agradecerles por ello. Si no fue así, el silencio es el método preferido.
El líder del equipo debe también agradecer a los guías.
3. Objetivos y alcance
Como formalidad, y para garantizar que no exista duda sobre la base para la auditoría se
deben a indicar cuáles fueron los objetivos y el alcance.
4. Reporte
Se debe describir el esbozo de la forma en que se informará formalmente de la auditoría y
los resultados enviados al auditado.
5. Limitaciones
Se debe repetir que la auditoría fue una muestra de actividades y por tanto está sujeta a los
riesgos relacionados con los muestreos. No se vio cada área conforme o no conforme, sólo
una selección representativa. Por tanto, existe la posibilidad de que no existan no
conformidades en áreas no cubiertas por esta auditoría.
6. Presentación de problemas/no conformidades
Se recomienda que las no conformidades se lean una después de la otra hasta presentar
todas, aunque podría ser necesario dar un resumen.
7. Resumen
El líder del equipo es responsable de presentar la conclusión que el equipo ha alcanzado con
base en los resultados de la auditoría. Este es el juicio informado de los auditores y debe
tomar en consideración la seriedad de cualquier no conformidad, y si indica una interrupción
departamental o de toda la organización respecto a los sistemas.
8. Acuerdo
Subdirección de Seguridad de la Información / UNAM-CERT 31/07/2010
Auditorías de Seguridad Informática
85 de 91
9. Aclaración
El auditado debe tener una oportunidad para hacer preguntas sobre los problemas/no
conformidades o el resumen y normalmente sería en este punto. Los hechos declarados no
deben estar en disputa. La junta de cierre no es el lugar para hablar de la acción correctiva
necesaria en sí.
10. Partida
Habiendo presentado los hallazgos y después de comentarios a satisfacción del auditado, el
equipo de auditoría puede retirarse, una vez más, después de agradecer el auditado por su
tiempo, etc.
a) No se tiene la presencia de una persona de alto nivel de la compañía en la junta de
cierre.
En una junta de cierre es deseable que una persona de alto nivel los represente. Sin
embargo, los auditores no pueden exigir que el Director Ejecutivo esté presente, sino
preguntar la razón por la cual no puede asistir. Entonces, si el líder del equipo considera
que la representación del auditado no es de un nivel suficiente, se puede solicitar que
otra persona de alto nivel esté disponible. Si se hicieron arreglos para que los altos
ejecutivos estuvieren ahí y ellos no llegan, entonces es razonable que el líder del equipo
demore la junta durante un plazo corto para esperarlos.
b) Acción correctiva tomada desde que se registró el problema.
Puede suceder que un problema pueda corregirse bastante rápido y fácilmente. Si esto
es lo que ha ocurrido, y el líder del equipo se muestra satisfecho de que se ha tomado la
acción correctiva eficaz, entonces la no conformidad se anota como “cerrada”- El hecho
de que se encontró durante la auditoría permanece en las anotaciones del reporte.
Si se presenta la acción correctiva tomada para una no conformidad, el líder del equipo
de manera correcta señalará que la junta de cierre no es el foro para hablar de esos
problemas, y que la acción correctiva y toda acción preventiva se auditarán durante la
siguiente auditoría en cuanto a efectividad.
c) Evidencia voluminosa presentada que aparentemente demuestre que no existe
problema.
Esta evidencia debe ponerse disponible durante la auditoría al momento de levantarse
la no conformidad. El líder del equipo debe explicar que los auditores tomarían en
cuenta la evidencia producida pero no en la junta de cierre. Si la evidencia demuestra
que no hay problema, entonces la retirarán.
Subdirección de Seguridad de la Información / UNAM-CERT 31/07/2010
Auditorías de Seguridad Informática
86 de 91
PREPARAR, APROBAR Y DISTRIBUIR EL INFORME DE AUDITORÍA
El reporte de una auditoría externa debe ofrecer un registro claro de los objetivos, alcance,
hallazgos y conclusiones de la auditoría. Es el principal resultado del proceso de auditoría proceso
el cual leerán y utilizarán personas que no estuvieron en la auditoría y que no tienen otra
información sobre la misma. Por tanto es importante que el reporte de auditoría ofrezca una
imagen equilibrada de toda la auditoría, no sólo de las no conformidades encontradas.
Muchas organizaciones generalmente requieren que se elaboren reportes bastantes cortos.
Aunque cortos, cuesta menos elaborarlos y, se razona, ofrecen una cantidad adecuada de
información. La razón completa para elaborar un reporte es que diversas personas lo utilicen. Las
formas usadas varían y se adjunta algunos ejemplos. Los siguientes son esencialmente puntos que
deben abordarse en un reporte de auditoría:
d) Evidencia clara presentada que demuestre que no existe problema.
Si los auditores encuentran que se equivocaron sobre un problema y se convencen a
partir de la información presentada, entonces deben retirarla.
e) La compañía desea alterar el alcance de la auditoría.
Si se solicita a los auditores que alteren el alcance de la auditoría en la junta de cierre,
raramente podrán hacerlo. Pocos auditores tienen la autoridad para hacerlo. Deben
seguir sus propios procedimientos. Toda alteración al alcance será fuera de las
actividades de esta auditoría. Por tanto, el auditado debe comentarlo posteriormente
con los directores de los auditores.
f) El auditado desea extender la junta.
Una vez que se ha hablado de las no conformidades y se ha hecho algún compromiso
con un programa de acción correctiva, no tiene caso permitir que la junta continúe. La
mayoría de las juntas de cierre normalmente terminan dentro de un plazo de media
hora. Deben agradecer su valioso tiempo, etc.
Subdirección de Seguridad de la Información / UNAM-CERT 31/07/2010
Auditorías de Seguridad Informática
87 de 91
Identidad única.
Cada auditoría necesita su propia identidad (número/letra, etc.).
Nombre del auditado, domicilio completo y preciso, etc. y fecha o fechas de la auditoría.
Objetivos y alcance de la auditoría, incluyendo referencias a especificaciones, contratos.
Requisitos para los Sistemas de Gestión de Seguridad de la Información aplicados.
Nombres y cargos del líder del equipo y el equipo incluyendo, de ser necesario, certificaciones del auditor.
a) Nombres y cargos de los auditados
Sería imposible enumerar a todas las personas que se conocieron durante una auditoría,
pero se acostumbra registrar al personal presente en las juntas de apertura y cierre, y en
ocasiones los diversos gerentes de departamento con quienes se reunió.
g) Programa de auditoría
El programa de la auditoría se debe incluir en el reporte de la auditoría y debe también
existir una referencia a los Sistemas de Gestión de Seguridad de la Información
cubiertos. Las listas de verificación se incluyen en ocasiones, pero no es habitual.
h) No conformidades mayores y menores
Todo reporte de auditoría incluye los reportes de no conformidad (con frecuencia en un
apéndice) exactamente como se redactaron y se presentaron al auditado. Si existe un
sistema de clasificación, entonces se utiliza el mismo. Puede también hacerse referencia
a una cláusula en la norma.
i) Sugerencias
Esto se ha vuelto menos común a medida que las organizaciones reconocen su futilidad.
Sin embargo, ciertas organizaciones requieren que los auditores incluyan sugerencias
para corrección de no conformidades. Esto es difícil, consume tiempo y es arriesgado, y
con frecuencia incumple con la política y procedimientos de organismos certificadores
por las razones que ya se han mencionado.
j) Aprobación
El reporte debe estar firmado y con fecha por parte del líder del equipo de auditoría
como aprobado. Es importante elaborar y publicar un reporte de auditoría dentro de un
marco de tiempo razonable. Por lo general, esto debe ser dentro de un plazo de 2-3
semanas posteriores a la auditoría. La respuesta a la auditoría debe considerarse
confidencial.
Subdirección de Seguridad de la Información / UNAM-CERT 31/07/2010
Auditorías de Seguridad Informática
88 de 91
Las auditorías internas quizá no requieran la misma profundidad de documentación para la
presentación de reportes, pero los registros mantenidos incluirán por lo menos lo siguiente:
Referencia y fecha de la auditoría.
Trabajos/departamento/oficina/sección auditada.
Alcance y objetivo de la auditoría si existe alguno fuera de los objetivos declarados en el
SGSI.
Nombre de auditores, programa de auditoría y listas de verificación de auditoría.
Más no conformidades menores/mayores.
Notas de los auditores.
Resumen y conclusiones de los registros de auditoría y la acción correctiva tomada.
CONDUCIR EL SEGUIMIENTO DE LA AUDITORÍA
Como resultado de la auditoría recién vivida, el auditado puede tener una cantidad de áreas
menores en las cuales se encontró que no cumplía con los requisitos. Estas generalmente se
abordan mediante un plan de acción correctiva, que se somete a la aprobación del auditor. El
auditado debe garantizar que la acción correctiva sea efectiva y algún tipo de monitoreo (puede
ser mediante verificaciones adicionales o mediante las auditorías internas propias de la compañía)
para garantizar que las cosas continúen de esa forma. Algunas organizaciones pueden tener varias
no conformidades de auditorías externas, sus propias auditorías internas, revisiones de la
gerencia, y de sugerencias, etc. Se vuelve necesario que un sistema formal lleve un seguimiento
de cada problema/no conformidad a medida que se acerca el cierre. Si el organismo externo
regresa (generalmente por una no conformidad) para verificar la acción correctiva tomada,
entonces el auditado necesita un buen sistema para garantizar que la acción tomada ha sido
eficaz.
El auditor deberá revisar su plan contra los hallazgos de la auditoría y las no conformidades
escritas. Podría tardarse hasta 28 días después de la auditoría recibir el reporte.
Durante una visita de seguimiento sólo los problemas/no conformidades levantadas son los que se
deben volver a auditar. Si no fuera este caso, el proceso nunca terminaría y sería ilógico. Con
frecuencia se puede hacer el seguimiento sin una visita.
Para un pequeño número de problemas encontrados durante una auditoría interna el seguimiento
puede dejarse hasta la siguiente auditoría planeada dentro de esa área siempre que sea posible.
Para auditorías de segunda, y especialmente, de tercera parte, se requiere una respuesta por
escrito a los problemas. Entonces, en la siguiente visita de vigilancia, se revisarían y cerrarían.
Cuando es necesario una visita para eliminar una no conformidad puede ser no el líder del equipo,
o incluso un integrante del equipo, sino alguien adecuadamente calificado que se encuentre cerca
de la organización auditada quien la realice. Si el auditor debe usar la declaración de la no
Subdirección de Seguridad de la Información / UNAM-CERT 31/07/2010
Auditorías de Seguridad Informática
89 de 91
conformidad para hacer seguimiento de la acción correctiva entonces deben ser muy específicos y
deben poderse rastrear. Un resumen del proceso de seguimiento es el siguiente:
Todos los reportes deben leerlos diversas personas en la organización, gerentes de
departamentos, etc., de manera que una lista de distribución sería de utilidad, especialmente
considerando la confidencialidad.
Dentro de la certificación de sistemas de tercera parte, la auditoría no es el final de la historia.
Después de la entrega del certificado que da fe del cumplimiento de los Sistemas de Gestión de
Seguridad de la Información de una organización con la norma, la tercera parte llevará a cabo
alguna forma de supervisión regular mediante visitas a intervalos periódicos, y la verificación de
que el sistema continúa operando de manera eficaz. Después de que una serie de estas visitas
continuas de evaluación se lleva a cabo una auditoría posterior o revisión completa de los
resultados previos. Durante el periodo de vigilancia (normalmente 2-3 años) las visitas en sí, (cada
3-6 meses), normalmente cubrirían todo el sistema.
Acción correctiva
La responsabilidad del auditor es dejarle claro al auditado que es necesario tomar acción
correctiva. El auditor raramente especifica la acción correctiva; esa es tarea del auditado. El
auditado debe proponer la acción correctiva.
Una vez que se ha abordado una no conformidad, el auditado debe garantizar que se han tomado
las acciones correctivas y preventivas eficaces. La organización puede solicitar aclaración al auditor
para comprender más claramente la no conformidad. La mejor acción correctiva puede decidirla la
gente en el área donde se levantó la no conformidad.
El proceso de la acción que se toma, verifica y monitoreo, debe ser formal; es quizá la actividad de
seguridad más importante que se realiza en una organización. Es ciertamente donde el sistema de
auditoría asume un aspecto positivo, y no uno negativo. Sin embargo, el proceso de acción
Un resumen del proceso de seguimiento es el siguiente:
a) Identificación de no conformidades encontradas durante la auditoría; b) Elaboración de reporte resumido; c) Petición de acción correctiva emitida; d) El auditor evalúa la respuesta a la acción correctiva; e) Realización de la acción correctiva por parte del auditado; f) Evaluación de la efectividad por parte del auditado; g) Verificación de realización por parte del auditor; h) Escalamiento (en su caso); i) Registros de cada etapa en este proceso.
Subdirección de Seguridad de la Información / UNAM-CERT 31/07/2010
Auditorías de Seguridad Informática
90 de 91
correctiva no es fácil. El auditado debe llegar a la causa raíz del problema si desea corregirlo para
siempre. Es muy fácil corregir el efecto de la no conformidad y no abordar la causa raíz de la no
conformidad. En tal caso, los síntomas de la no conformidad reaparecerán con el tiempo. El
auditor tendrá que tomar en consideración también la acción correctiva y el impacto que tiene en
el resto del proceso hacia arriba. Puede tener un efecto en áreas no consideradas durante la
auditoría.
No necesariamente todas las acciones correctivas están involucradas. Se avanza en algunas de las
etapas anotadas sin darse cuenta de ello. No obstante es el caso de que todas las acciones
correctivas realizadas sigan este camino.
La compañía con visión al futuro determinará algunos criterios para el éxito. Si la organización va a
participar en estas actividades, las operaciones deben haber mejorada después de las auditorías y
de que se hubieren establecido acciones correctivas y preventivas.
Las características esenciales de la acción correctiva son las siguientes:
a) Identificación de la no conformidad; b) Establecer responsabilidad para controlar el proceso pertinente; c) Recopilar datos para establecer la causa raíz para la no conformidad; d) Analizar los datos y establecer acciones correctivas y preventivas; e) Monitorear la efectividad de esta acción, incluyendo auditoría interna; f) Revisar la acción si no es eficaz; g) Registrar todas las acciones tomadas; h) Enmendar según sea necesario la documentación del sistema.
Subdirección de Seguridad de la Información / UNAM-CERT 31/07/2010
Auditorías de Seguridad Informática
91 de 91
REFERENCIAS
- Manual del curso Auditor líder ISO 27001:2005. Seguridad de la información, BSI.
http://protegete.jccm.es/jccmportal/opencms/Administracion/Seguridad/Certificacion/general.html
http://www.lrqamexico.com/quien-es-lrqa/proceso-de-certificacion/etapa-3.aspx