ÍNDICE PRINCIPALES ÁREAS DE LA AUDITORÍA INFORMÁTICA.......................................................................

4 OBJETIVOS ESPECÍFICOS ........................................................................................................................... 4

INTRODUCCIÓN...................................................................................................................................... 4 1.
DEFENSA EN PROFUNDIDAD....................................................................................................... 4 2.
AUDITORÍA DE REDES.................................................................................................................. 5 2.1.
DEFINICIÓN DE PERÍMETRO................................................................................................ 5 2.2.
FIREWALLS........................................................................................................................... 6 2.2.1.
ARQUITECTURA DEL FIREWALL ................................................................................... 6 2.2.2. VALIDACIÓN
DEL RULE BASE ....................................................................................... 7 2.2.3. REVISIÓN DEL REGISTRO
............................................................................................. 7 2.3. ROUTERS Y SWITCHS
........................................................................................................... 8 2.3.1. INTERFACES
................................................................................................................. 8 2.3.2.
SERVICIOS.................................................................................................................... 9 2.3.3.
ADMINISTRACIÓN ..................................................................................................... 10 3. AUDITORÍA DE
DATA CENTER.................................................................................................... 11 3.1.
RESPALDOS........................................................................................................................ 11 3.2.
SEGURIDAD FÍSICA............................................................................................................. 13 3.2.1. ÁREAS
SEGURAS ........................................................................................................ 14 3.2.2. CONTROLES FÍSICOS
DE ENTRADA Y SALIDA............................................................. 14 3.2.3. SEGURIDAD EN EL
EQUIPAMIENTO........................................................................... 15 4. AUDITORÍA DE
SEGURIDAD....................................................................................................... 15 4.1. SEGURIDAD LÓGICA
.......................................................................................................... 15 4.2. PLANES DE CONTINGENCIA
Y/O RECUPERACIÓN DE DESASTRES..................................... 16 COMENTARIO
FINAL.......................................................................................................................... 17
REFERENCIAS........................................................................................................................................ 18 4
ESTE DOCUMENTO CONTIENE LA SEMANA 8 PRINCIPALES ÁREAS DE LA AUDITORÍA INFORMÁTICA
OBJETIVOS ESPECÍFICOS  Analizar las características y objetivos de uso de los tipos de auditoría
informática.  Aplicar tipos de auditoría en el contexto de procesos de auditoría informática.
INTRODUCCIÓN En esta semana se revisarán las metodologías y técnicas relativas a la auditoría
informática de redes desde un punto de vista perimetral, abarcando los dispositivos y aplicaciones
comúnmente expuestas a internet como son los firewalls y routers. También se analizarán las auditorías
físicas y cómo estas se encuentran asociadas a los requerimientos de seguridad en los data center, así
como los planes de recuperación de desastres (DRP) y de continuidad de negocio (BCP). Lo anterior
permitirá abracar en su totalidad el concepto de defensa en profundidad que ha sido planteado por
SANS Institute como un modelo de seguridad por capas y que es ampliamente implementado para
establecer una red segura. No se debe olvidar que se han simplificado los aspectos que componen cada
capa y que son responsabilidad del alumno profundizar y complementar. 1. DEFENSA EN PROFUNDIDAD
De acuerdo a SANS Institute (2001.b) para proteger la red, se debe desplegar una metodología de
defensa en profundidad. En otras palabras, no se puede confiar en apenas un control, sino que por el
contrario múltiples controles deben estar presentes y ser evaluados y auditados en conjunto. Debe
haber “múltiples capas” de seguridad incorporadas a la red. Esto puede incluir los firewalls del
perímetro, los firewalls internos, los sistemas de detección de intrusión, los routers de borde, los routers
internos, etc. 5 ESTE DOCUMENTO CONTIENE LA SEMANA 8 El modelo propone lo siguiente: Fuente:
material elaborado para esta asignatura en base a lo expuesto en:
http://enredandoconredes.com/page/3/ Al llegar a esta semana ya se han revisado la auditoría de
datos, aplicaciones, host y políticas y estándares, por lo que a continuación se abarcará el perímetro que
incluye aspectos de la red interna y la seguridad física desde la perspectiva de un auditor. 2. AUDITORÍA
DE REDES 2.1. DEFINICIÓN DE PERÍMETRO Antes de seguir revisando la auditoría de los equipos o
dispositivos que componen la red, se debe aclara cuál es el perímetro de esta, es decir, hasta dónde
llega. Es bastante fácil identificar dónde termina el perímetro ya que básicamente se puede pensar
como el “borde externo” de la red. De esta forma el firewall externo y los routers tienden a identificar el
perímetro. Sin embargo, hoy existen dispositivos y tecnologías que lo amplían, por ejemplo, las
conexiones interempresariales (B2B) permiten a otras organizaciones tener acceso a la red, ampliando el
perímetro y por lo tanto 6 ESTE DOCUMENTO CONTIENE LA SEMANA 8 aumentando los riesgos que se
deben aceptar. Accesos por módems y VPN también amplían el perímetro y para asegurar la red se
deben abarcar todas las posibles opciones. 2.2. FIREWALLS Al referirse a los firewalls lo primero que se
debe considerar es que hay diferente tecnologías disponibles, aunque como auditores normalmente no
se requiere obtener todos los detalles y características técnicas de cada uno de ellos, lo relevante es
definir el propósito del firewall y si este se encuentra alineado con la política de seguridad. La mayoría
de los firewalls funcionan en un ambiente donde se niega todo y solamente lo que está específicamente
autorizado se permite. Es extremadamente difícil auditar un firewall si no se sabe lo que se supone debe
hacer. En un mundo perfecto, una copia de la política de seguridad podría producir inmediatamente una
definición bien documentada de qué exactamente el firewall debe hacer, sin embargo, la realidad no es
así. Si no hay una política de seguridad clara, se debe determinar cuáles son las expectativas para el
firewall, lo obvio es que realice un filtrado de los accesos de red ya sea nivel perimetral o interno,
aunque la organización puede tener otras adicionales que deben considerarse en el proceso de
auditoría. La auditoría no se limita a las herramientas técnicas, un auditor debe evaluar el ambiente en
su totalidad incluyendo por ejemplo, las expectativas de la gerencia, la tecnología disponible o la
interacción con los administradores. En particular se revisarán 3 aspectos técnicos de los que propone
Isaca (2014) y que deberían ser considerados en la auditoría. 2.2.1. ARQUITECTURA DEL FIREWALL La
arquitectura es la estructura global de cómo esta implementado un firewall y esta debe apoyar la
política de seguridad. Los firewalls hacen su trabajo controlando el flujo de información y la mejor forma
de entender cuál es flujo correcto es mediante diagramas lógicos de operación. La auditoría debe
determinar si la arquitectura hace cumplir el flujo de información. En vez de centrarse en el hardware
físico, un diagrama lógico se centra en “áreas” de información. Entonces determina qué información
puede fluir a qué áreas y en qué dirección. La política de seguridad debe apoyar este flujo de
información. 7 ESTE DOCUMENTO CONTIENE LA SEMANA 8 Durante el proceso de auditoría de la
arquitectura se debe considerar si los firewalls están dividiendo correctamente la información en
segmentos con reglas claras de acceso y un sentido bien definido. 2.2.2. VALIDACIÓN DEL RULE BASE Un
rule base de firewall es un conjunto de reglas de acceso que especifican cómo se pueden comunicar o
acceder diferentes redes o hosts. Cada conexión se identifica mediante la IP de origen, la IP de destino y
el puerto al que se desean conectar. Esta definición técnica debe ser consistente con la arquitectura y
políticas existentes. Normalmente la auditoría de un rule base consiste en validar que lo que se
encuentra permitido efectivamente sea lo que debe estar permitido. La mayoría de las excepciones de
auditoría ocurren debido a que los rule bases acumulan “basura” como reglas que se agregaron
temporalmente y luego no fueron removidas o que se van duplicando. Como objetivo base, son este
tipo de redundancias las que se deben eliminar en primera instancia ya que la idea es reducir el rule
base tanto como sea posible para simplificar la revisión e identificar cualquier regla que no esté
autorizada y eliminarla. Al revisar la política de reglas se deben intentar contestar a las siguientes
preguntas.  ¿Las reglas son consistentes con la política y/o la mejor práctica? Si no existe una política,
se debe confiar en lo que diga la mejor práctica.  ¿Se autorizan las reglas que se aplican? Puede haber
una razón de negocio para la existencia de una regla, pero eventualmente la regla puede no haber
seguido el proceso apropiado de control de cambio. Si es así, la regla se debe autorizar, en caso
contrario debe ser eliminada. Una vez que se ha revisado manualmente el rule base, es necesario
confirmarlo a un nivel de red utilizando alguna herramienta como por ejemplo NMAP (www.nmap.org) y
ejecutar algunas pruebas básicas.  Realizar una exploración TCP y UDP del firewall para los 65.535
puertos.  Realizar un barrido para determinar si existen respuestas ICMP.  Exploración SYN y UDP para
buscar puertos abiertos. 2.2.3. REVISIÓN DEL REGISTRO Una de las actividades a realizar en la auditoría
de firewalls es la revisión de los logs de conexiones y registros de auditoría. Existen algunas cosas críticas
que se pueden aprender revisando los 8 ESTE DOCUMENTO CONTIENE LA SEMANA 8 registros/logs: la
primera es determinar si las actividades y pruebas realizadas sobre el firewall fueron detectadas, la
segunda es si se registraron las validaciones y finalmente si los sistemas de alerta fueron activados, por
ejemplo el envío de notificaciones por correo electrónico o traps SNMP. 2.3. ROUTERS Y SWITCHS
Auditar un router o un switch puede ser un trabajo tedioso pero necesario, de acuerdo a SANS Institute
(2001.a) la siguiente es una lista de comprobación general de seguridad recomendada para un router o
switch que se encuentra clasificada de acuerdo al ámbito en que debería aplicarse cada evaluación y que
se resume en la siguiente lista:  Interfaces.  Servicios.  Administración. 2.3.1. INTERFACES A
continuación se entregan las líneas bases para la configuración más apropiada de las puertas de un
router o switch incluyendo VLAN, Trunking y configuraciones para la mitigación de ARP spoofing que
deben ser validadas en términos de existencia o valores de configuración durante un proceso de
auditoría. PUERTAS (PORTS) Una de las recomendaciones básicas y que deben aplicarse siempre
consiste en deshabilitar las puertas no usadas para reducir los riesgos de que estas sean utilizadas con
fines maliciosos o erróneos. Además, a menos que sea necesario de otra forma, los puertos activos
deben tener el trunking, spanning tree y los protocolos de descubrimiento (p. ej., CDP para Cisco)
deshabilitados explícitamente. De la misma manera, para evitar ataques de spanning tree, se deben
habilitar filtros de paquetes BPDU (si es configurable) en las puertas en que no se desea enviar o recibir
BPDU. Los ajustes pueden variar dependiendo de la plataforma y la versión del router o switch. VLAN A
menudo los administradores utilizan la VLAN por defecto (que regularmente se utiliza para contener
puertos no asignados) como de administración primaria. Sin e 9 ESTE DOCUMENTO CONTIENE LA
SEMANA 8 defecto. Los puertos no asignados e inactivos deben permanecer fuera de la VLAN de
administración para reducir el riesgo de acceso no autorizado. Para una seguridad adicional, los puertos
no activos se pueden asignar a una VLAN no utilizada. TRUNKING Cuando el trunking es necesario, una
VLAN dedicada con excepción de la VLAN por defecto se debe utilizar para evitar la posibilidad de
ataques como VLAN hopping y double tagged. El número nativo de VLAN seleccionado no se debe
utilizar para ningún otro propósito con excepción del trunking de VLAN. Las VLAN permitidas en el trunk
se debe restringir solamente a los trunks que sean necesarios por motivos de rendimiento y de
seguridad. ARP SPOOF Un método para reducir la posibilidad de MAC spoofing es limitar el número de
las direcciones que pueden ser recibidas en una puerta del router dejando solamente que una MAC
address pueda estar en un puerto al mismo tiempo. Adicionalmente, es recomendable que exista un
filtro específico para la MAC del equipo que se encuentra conectado directamente a la puerta. 2.3.2.
SERVICIOS Ciertos servicios de sistema no son necesarios y se deben deshabilitar por defecto. Los
servicios finger, TCP-small-servers, UDP-small-servers y domain-lookup caen dentro de esta categoría.
Los servicios utilizados por el sistema para la administración como el servicio HTTP y TELNET, que son
permitidos por defecto en los router y switch, deben ser deshabilitados para reducir los riesgos
potenciales de accesibilidad. En su lugar se debe utilizar HTTPS y SSH respectivamente. Adicionalmente,
se recomienda que solo esté disponible el puerto o VLAN de administración. En relación al servicio
SNMP se recomienda que esté deshabilitado si no es necesario, en caso contrario, considerar aplicar
medidas de control de acceso y filtrado a nivel perimetral. Otros configuraciones que no necesariamente
corresponden a servicios también se deben deshabilitar, ejemplo de esto es el ICMP redirects que
podría no ser necesario en una red bien diseñada, por lo tanto debe estar deshabilitado a menos que
sea una necesidad específica. En esos casos el auditor debe generar la excepción que quedará
documentada y justificada por la necesidad detectada. 10 ESTE DOCUMENTO CONTIENE LA SEMANA 8
2.3.3. ADMINISTRACIÓN LOGIN Y PASSWORD El auditor debe validar que se estableció una contraseña
para el usuario administrador de acuerdo a la política de seguridad que posea la empresa, asimismo es
aconsejable modificar el nombre de usuario (login) si el modelo y versión del router o switch lo permite.
Lo anterior es extensible a todos los dispositivos de la red incluyendo switches, routers, firewalls y hosts.
ACCESO DE CONSOLA El auditor debe validar que se asignó una contraseña al puerto de consola junto
con un timeout de la sesión. Los timeout de la sesión aseguran que las conexiones sean desconectadas
después de un período específico de inactividad para cerrar sesiones ociosas y para limitar
susceptibilidad de que a un intruso no le sea requerida autentificación. Un timeout de diez minutos es
adecuado para los propósitos de una conexión por consola. ACCESO REMOTO El auditor debe validar
que las sesiones remotas sean filtradas (una de las opciones es utilizar ACL o mediante dispositivos
externos como firewall) denegando el acceso a hosts no autorizados. Como se mencionó anteriormente
es preferible usar SSH (si está disponible) por sobre TELNET. Al igual que el acceso por consola debe
contar también con un timeout para la sesión. SNMP Las implementaciones de SNMP versión 1 y 2 son
vulnerables a diferentes tipos de ataques. Mensajes SNMP pueden ser utilizados para causar la caída del
sistema en dispositivos que utilicen estas versiones. Estas vulnerabilidades podrían permitir a un
atacante el comprometer un dispositivo remotamente. Se recomienda considerar implementaciones
seguras de SNMP, como la versión 3 que incluye mejoras en el control de acceso mediante el uso de una
autentificación robusta. La auditoría debe validar que los valores por defecto de las comunidades SNMP
se modificaron, con la finalidad de restringir el acceso de usuarios y que estos tengan privilegios de solo
lectura y únicamente de fuentes confiables. Se recomienda establecer a la comunidad SNMP un valor
que sea difícil de adivinar. Utilizar caracteres mayúsculos, minúsculos y numéricos. BANNER Se
recomienda que existan banners al intentar una conexión porque se utilizan para comunicar
notificaciones y advertencias de acceso por uso desautorizado. La fraseología del banner debe ser clara
y estar dentro de los límites legales de las políticas de la seguridad de una red dada. A continuación se
presenta un posible ejemplo de lo que podría incluir un banner.
***************************************************** * [ADVERTENCIA] router-01 * * Este
sistema pertenece a [NOMBRE]. * 11 ESTE DOCUMENTO CONTIENE LA SEMANA 8 * Accesos no
autorizados a este sistema están prohibidos * * Todas las actividades serán monitoreadas *
***************************************************** NTP Se recomienda la sincronización
del reloj mediante Network Time Protocol (NTP) ya que aumenta considerablemente el nivel de la
exactitud en la correlación de acontecimientos durante la investigación de problemas técnicos o
incidentes de seguridad. Los router y switch deben apuntar a un servidor NTP confiable y utilizar
autentificación MD5 si está disponible. LOGGING AND EXCEPTIONS Finalmente, una configuración no
estaría completa sin un adecuado registro de las actividades del sistema. Todos los registros se deben
enviar a un servidor remoto (syslog) para su almacenaje y revisión (auditoría). El auditor no solo debe
verificar que se encuentre configurado este parámetro sino que también debe revisar los registros
generados, buscando anormalidades como intentos de acceso no autorizados, conexiones en horarios
fuera del rango administrativo, etc. 3. AUDITORÍA DE DATA CENTER Según lo expuesto por Echeñique
(2001), los datos son los recursos más valiosos para cualquier organización y bajo esa perspectiva es
necesario protegerlos y auditarlos. La protección de estos se basa en mantener un proceso y
almacenamiento seguro. Para ello se debe aplicar controles que permitan lo anterior y que se
transforman en los elementos que se auditarán. Normalmente los procesos son cubiertos por políticas y
procedimientos (principalmente los de respaldo) y el almacenamiento es realizado en los centros de
cómputo o data center que proporcionan la seguridad física. Ambos tópicos se analizan a continuación
en mayor detalle. 3.1. RESPALDOS Para Echeñique (óp. cit.), en el proceso de auditoría de data center se
deben revisar algunos aspectos generales que deben estar presentes a la hora de realizar respaldos y
recuperación de servidores. A continuación se presenta el cuestionamiento base que debe realizar el
auditor con la finalidad de evaluar los puntos mencionados por Echeñique (óp. cit.). 1. ¿Existe un
procedimiento escrito para respaldos y recuperación de sistemas o bases de datos? 12 ESTE
DOCUMENTO CONTIENE LA SEMANA 8 Objetivo: verificar que exista un documento escrito donde se
especifique:  Frecuencia de respaldos.  Tipo de respaldo. 2. ¿Cuentan los respaldos con la información
necesaria para ser identificados? Objetivo: revisar los respaldos existentes y verificar que estos cuenten
con los siguientes atributos:  Identificación única e inconfundible del sistema o información a ser
respaldada.  Nombre del área funcional propietaria de la información.  Cargo y nombre del líder
funcional responsable de la información.  La información debe estar clasificada de acuerdo a su grado
de confidencialidad.  Requerimiento de disponibilidad de la información o sistema.  Periodo histórico
de retención de la información.  Tiempo de permanencia de los respaldos, para casos mayores a un
año. 3. ¿Qué tipo de acceso tiene el responsable de realizar acciones de recuperación de información?
Objetivo: verificar que el responsable de estas actividades solo tenga acceso a los procesos que son de
su responsabilidad. En ningún caso podrá acceder a datos o procesos sin previa autorización de los
usuarios responsables de estos datos. 4. ¿Existe un procedimiento para la eliminación de información
que ha cumplido con su período de permanencia? Objetivo: verificar la existencia de un procedimiento
escrito para la eliminación de información de los dispositivos en que se almacena, y que exista un
registro con la autorización previa del centro de competencia de infraestructura o quien este delegue
para la ejecución de esta acción. 5. ¿El tipo de rotulación usada para los respaldos permite identificar
claramente el respaldo? Objetivo: verificar la rotulación de los respaldos y que como mínimo existan los
siguientes datos:  Identificación única e inconfundible de la información o sistema de respaldo.  Fecha
de respaldo.  Nombre o identificación del servidor respaldado.  Tipo de respaldo (total, incremental o
diferencial).  Tipo de datos respaldados (sistema operativo, aplicación, base de datos, archivos de
usuarios).  Correlativo (p. ej. 1/3, 2/3, 3/3), si se usó más de un volumen o medio de respaldo. 13 ESTE
DOCUMENTO CONTIENE LA SEMANA 8  Retención en días y fecha de expiración.  Lugar de
almacenamiento. 6. ¿Son guardados los respaldos diarios y semanales en una caja cerrada y bajo llave?
Objetivo: verificar que el medio donde se almacena sea a prueba de fuego y esté en un lugar alejado de
los servidores. Las llaves deben estar numeradas y con un registro de quienes son sus depositarios. 7.
¿Son guardados los respaldos mensuales dentro de la sala de servidores? Objetivo: verificar que los
respaldos sean almacenados fuera de la sala de servidores y en un edificio distinto y seguro. 8. ¿Existe
una bitácora donde se registren las actividades realizadas de respaldo o recuperación? Objetivo: revisar
la existencia de por lo menos la siguiente información:  Identificación del
servidor/sistema/directorio/archivos.  Operador.  Fecha.  Hora de inicio.  Hora de término.  Tiempo
de duración.  Nombre de sesión para restauración.  Identificación del medio de almacenamiento. 
Observaciones del operador (errores, acciones correctivas tomadas, confirmación de la correcta
ejecución del proceso, otros).  Resultado del proceso (respaldo fallido o exitoso). 3.2. SEGURIDAD
FÍSICA De acuerdo a Echeñique (óp. cit.), la auditoría de la seguridad física está enfocada en los controles
que rodean la instalación y los sistemas de computadores usados para proveer el servicio. Los auditores
por lo tanto deben revisar los siguientes ítems: