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


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



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



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.



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



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.



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.



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.



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.



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?.



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



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:



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.



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.



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.



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



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



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.



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.



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

http://csrc.nist.gov/publications/nistpubs/800-14/800-14.pdf



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.



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

http://www.betaversion.net/btdsd/



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.



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.



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?

http://www.kismetwireless.net/



¿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



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



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



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?



¿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.



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



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?



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”



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.



¿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



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á



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



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)



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



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



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.



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



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:



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



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.



- 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



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.



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.



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



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



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”.



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



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.



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



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



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.



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.



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.



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.



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



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.



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


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).



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,



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



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.



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



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.



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



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.



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



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



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



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



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.



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.



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.



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.



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.



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?



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.



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



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.



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.



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.



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



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.



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.



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



http://www.lrqamexico.com/quien-es-lrqa/proceso-de-certificacion/etapa-3.aspx

Auditorías de Seguridad Informática - sergiob.org³n General de Servicios de Cómputo Académico...

Documents

Transcript of Auditorías de Seguridad Informática - sergiob.org³n General de Servicios de Cómputo Académico...