Auditorías de Seguridad Informática

Transcripción

1 Todos los derechos reservados 2010 Dirección de Telecomunicaciones Subdirección de Seguridad de la Información/UNAM-CERT

2 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 Procedimientos El rol del equipo de auditoría Integrando un equipo de auditoría efectivo Mantenimiento de la experiencia Proceso de Auditoría Determinando qué auditar Análisis de riesgos... 12

3 Etapas de una auditoría Técnicas de auditoría Auditoría de planes de continuidad del negocio y de recuperación de desastres Auditoría de redes Auditoría de redes inalámbricas Bluetooth Wireless Auditoría de aplicaciones Pruebas de caja blanca Pruebas de caja negra Pruebas de caja gris Auditoría de binarios Auditoría de bases de datos Auditando Bases de DAtos Listeners de Oracle Autenticación en Oracle Autenticación en SQL Server Usuarios y Roles Perfiles Privilegios Paquetes Cuentas por default Contraseñas Respaldos Auditando la Base de Datos... 56

4 Herramientas Otras aspectos a considerar Auditoría de Sistemas de Gestión de Seguridad de la Información (Según la serie ISO/IEC 27001:2005) Etapas de auditoría Tipos de auditoría Certificación del SGSI Proceso de auditoría Realizar las actividades de auditoría Preparar, aprobar y distribuir el informe de auditoría Conducir el seguimiento de la auditoría... 88

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

6 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

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

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

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

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

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

12 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

13 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:

14 Figura 2. 1 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.

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

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

17 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 OCTAVE Metodología del NIST DESCRIPCIÓN 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 National Institute of Standards & Technology Publicación especial del NIST (SP) , 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

18 FRAP COBRA Risk Watch 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 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. Consultative, Objective and Bi-functional Risk Analysis El proceso fue creado originalmente por C & A Systems Security Ltd. en É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 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

19 ETAPAS DE UNA AUDITORÍA Dirección General de Servicios de Cómputo Académico 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 Sujeto de auditoría Objeto de auditoría Alcance de auditoría Planificación de preauditoría Procedimientos de auditoría y pasos para la recolección de datos Procedimientos para evaluar los resultados de la prueba o la revisión Procedimientos para las comunicaciones con la gerencia Preparación del reporte de auditoría Descripción Identificar el área que será auditada 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. Identificar los sistemas, funciones o unidades específicos de la organización que serán incluidos en la revisión. 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. 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. Especifico de la organización. Especifico de la organización. Identificar los procedimientos de seguimiento de la revisión.

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

21 Plan de recuperación de desastres Dirección General de Servicios de Cómputo Académico 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

22 An Introduction to Computer Security:The NIST Handbook Estándar ISO/IEC rohde.pdf?key1=78975&key2= &coll=guide&dl=guide&cfid= &cftoken= 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.

23 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 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

24 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 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 o o o OS Fingerprinting HTTP Fingerprinting FTP Fingerprinting 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.

25 4. Deshabilitar safe checks. Dirección General de Servicios de Cómputo Académico 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.

26 Kismet es otra herramienta que corre en Unix, puede encontrarse información y ser descargada desde 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?

27 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 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

28 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

29 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: 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: 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]: KB [02]: KB [03]: KB [04]: KB [05]: KB [06]: KB [07]: KB [08]: KB 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: Direcciones IP [01]: [02]: fe80::a052:59e1:3a2d:6e67 for VMnet1 ork Adapter VMnet1 [03]: VMware Virtual Ethernet Adapter Nombre de conexión: VMware Netw

30 DHCP habilitado: No Direcciones IP [01]: [02]: fe80::8cad:c9b8:75f9:5ce0 for VMnet8 ork Adapter VMnet8 dapter Host-Only Network [04]: VMware Virtual Ethernet Adapter Nombre de conexión: VMware Netw DHCP habilitado: No Direcciones IP [01]: [02]: fe80::9c3e:1bdc:cacc:173a [05]: VirtualBox Host-Only Ethernet A Nombre de conexión: VirtualBox DHCP habilitado: No Direcciones IP [01]: [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. ema. Esta util ería es más que sufi cien te par a rec ono cer el sist 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?

31 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 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 v Local and remote system information viewer Copyright (C) Mark Russinovich Sysinternals - 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: System root: C:\Windows Processors: 2 Processor speed: 1.9 GHz Processor type: Intel(R) Core(TM)2 Duo CPU 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.

32 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 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

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

34 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

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

36 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

37 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 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á

38 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

39 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 ( 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 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)

40 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, bytes 255 heads, 63 sectors/track, 9729 cylinders Units = cylinders of * 512 = bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x b Device Boot Start End Blocks Id System /dev/sda1 * Linux /dev/sda Extended /dev/sda 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: /+ buffers/cache: Swap: 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

41 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

42 pruebas de caja blanca? Dirección General de Servicios de Cómputo Académico 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.

43 Pros y Contras Dirección General de Servicios de Cómputo Académico 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

44 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:

45

46 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

47 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 o o o Select Update Delete Insert into Data Definition Language o o o o o Create Table Alter Table Drop Table Create Index Drop Index Existen términos clave que son necesarios revisar para entender mejor una base de datos.

48 - 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

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

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

51 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 o Integrado con el SO Conexiones seguras Modo Mixto o SQL Server Autentication Conexiones no seguras ( Porqué?) Compatibilidad con versiones anteriores

52 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

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

54 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

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

56 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

57 b. ALTER c. DROP Dirección General de Servicios de Cómputo Académico 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

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

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

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

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

62 Auditoría de tercera parte Se llevan a cabo por organizaciones independientes externas. Tales organizaciones proporcionan la certificación o el registro de conformidad con la norma ISO Auditoría de segunda 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 primera 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. 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.

63 CERTIFICACIÓN DEL SGSI Dirección General de Servicios de Cómputo Académico 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 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 Asegurar el cumplimiento continuado del SGSI y ayudar a prevenir (semestral o anual) 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.

64 Certificación Visitas de seguimiento Auditoría de certificación (etapa 2) Revisión documental (etapa 1) Visita preliminar (opcional) Proceso de certificación de un SGSI

65 Subdirección de Seguridad de la Información / UNAM-CERT 31/07/2010 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 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 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. 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). 65 de 91

66 Subdirección de Seguridad de la Información / UNAM-CERT 31/07/2010 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 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. 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, 66 de 91

67 Subdirección de Seguridad de la Información / UNAM-CERT 31/07/2010 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: Objetivo de la 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. Alcance 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. 67 de 91

68 Subdirección de Seguridad de la Información / UNAM-CERT 31/07/2010 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. 68 de 91

69 Subdirección de Seguridad de la Información / UNAM-CERT 31/07/2010 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. 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: ISO/IEC 27001:2005 Lista de verificación de los criterios (requisitos convertidos en preguntas) Lista de verificación de auditoría (ayuda a la memoria) Preguntas de auditoría La evidencia objetiva de la auditoría Evaluación de conformidad Resultados de la auditoría 69 de 91

70 Subdirección de Seguridad de la Información / UNAM-CERT 31/07/2010 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 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. 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 70 de 91

71 Subdirección de Seguridad de la Información / UNAM-CERT 31/07/2010 RESUMEN 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 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. 71 de 91

72 Subdirección de Seguridad de la Información / UNAM-CERT 31/07/2010 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: 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. Figura X.X Junta de apertura. 72 de 91

73 Subdirección de Seguridad de la Información / UNAM-CERT 31/07/2010 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: 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 Para la realización de la auditoría se debe considerar lo siguiente: Control de la auditoría 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. 73 de 91

74 Subdirección de Seguridad de la Información / UNAM-CERT 31/07/2010 Toma de notas Ú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. Entrevista de auditoría 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. 74 de 91

75 Subdirección de Seguridad de la Información / UNAM-CERT 31/07/2010 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. Técnicas de cuestionamiento 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. 75 de 91

76 Subdirección de Seguridad de la Información / UNAM-CERT 31/07/2010 Verificación 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. 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. Equipos de una/dos personas 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 76 de 91

77 Subdirección de Seguridad de la Información / UNAM-CERT 31/07/2010 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. 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. 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. 77 de 91

78 Subdirección de Seguridad de la Información / UNAM-CERT 31/07/2010 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. Ejemplo de una no conformidad: o El procedimiento XXXX Control de documento versión tenía como última fecha de revisión el 25 de enero de 2010, pero en la lista maestra XXXX versión se encontraba registrada con fecha 15 de enero de En este ejemplo se está incumpliendo el requisito de la norma 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. 78 de 91

79 Subdirección de Seguridad de la Información / UNAM-CERT 31/07/2010 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. 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. 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: 79 de 91

80 Subdirección de Seguridad de la Información / UNAM-CERT 31/07/2010 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. 80 de 91

81 Subdirección de Seguridad de la Información / UNAM-CERT 31/07/2010 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. 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. 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. 81 de 91

82 Subdirección de Seguridad de la Información / UNAM-CERT 31/07/2010 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? 82 de 91

83 Subdirección de Seguridad de la Información / UNAM-CERT 31/07/2010 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) 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. 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. 83 de 91

84 Subdirección de Seguridad de la Información / UNAM-CERT 31/07/2010 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 84 de 91

85 Subdirección de Seguridad de la Información / UNAM-CERT 31/07/ 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. 85 de 91

86 Subdirección de Seguridad de la Información / UNAM-CERT 31/07/2010 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. 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: 86 de 91

87 Subdirección de Seguridad de la Información / UNAM-CERT 31/07/2010 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. 87 de 91