INSTITUTO TECNOLOGICO Y DE ESTUDIOS SUPERIORES DE MONTERREY

METODOLOGIAS DE PENETRACION DE SISTEMAS, ANALISIS DE RESULTADOS Y MODELO DE PROTECCIÓN

TESIS QUE PARA OPTAR EL GRADO DE MAESTRO EN CIENCIAS COMPUTACIONALES, ESPECIALIDAD

EN REDES DE COMPUTADORAS PRESENTA

RICARDO CESAR LIRA PLAZA

Asesor: Dr. Roberto Gómez Cárdenas

Comité de tesis: Dr. José de Jesús Vázquez Gómez

M.S. Adolfo Grego Kribit

Atizapán de Zaragoza, Edo. Méx., Julio 2004.

2

INDICE

DEDICATORIA .............................................................................................................................. 5 AGRADECIMIENTO ..................................................................................................................... 6 INTRODUCCION ........................................................................................................................... 7 CAPITULO 1 ................................................................................................................................ 10 Introduccion a las Metodologías de Penetracion de Sistemas de lnformacion ............................. 10

1.1 Primer acercamiento, un documento historico: Wardoc ..................................................... 11 1.2 Guia para evaluar la Seguridad en Red (Publicacion Especial del NIST 800-42) .............. 12 1.3 Metodologia OSSTMM ("Open Source Security Testing Methodology Manual") ............ 16

1.3.1 El Proceso ..................................................................................................................... 19 1.3 .2 El Mapa de Seguridad ................................................................................................... 19 1.3.3 Evaluacion de Riesgos .................................................................................................. 23 1.3.4 Seguridad Perfecta ........................................................................................................ 23 1.3.5 Valores de la Evaluacion de Riesgos ............................................................................ 24 1.3.6 Tipos de riesgos ............................................................................................................ 24 1.3.7 Secciones y Modulos .................................................................................................... 25 1.3 .8 Metodología .................................................................................................................. 26 1.3.9 Plantillas o Modelos para documentacion .................................................................... 27 1. 3 .1 O Comentarios Finales ................................................................................................... 2 7

1.4 Metodología de RoelofTemmingh ...................................................................................... 28 1.4.1 Primer paso: "Fijando el escenario" ............................................................................. 28 1.4.2 Segundo paso: "Mapeando el objetivo" ....................................................................... 28 1.4.3 Tercer paso: ¿ Vivo y tocando? ..................................................................................... 29 1.4.4 Cuarto Paso: "Cargando las Armas" ............................................................................ 29 1.4.5 Quinto Paso: Fuego! ..................................................................................................... 30

1.5 Metodologia de Mixter ........................................................................................................ 31 1.6 Metodologia de Dan Farmer y Wietse Venema .................................................................. 32

1.6.1 Recopilacion de Informacion ....................................................................................... 34 1.6.2 Confianza ...................................................................................................................... 34 1.6.3 Proteccion de los sistemas ............................................................................................ 35

1.7 Metodologia de T. Peltier, J. Peltier y Blackley .................................................................. 36 1.7.1 Enfoque "De arriba hacia abajo" (Normativo/Administrativo) .................................... 37 1.7.2 Enfoque "De abajo hacia arriba" (Tecnico/Practico) ................................................... 37 1. 7 .3 Metodologia .................................................................................................................. 38

1.8 Metodologia de Klevinsk, Laliberte y Gupta ...................................................................... 39 1.9 Metodología de McClure, Scambray, Kurtz ........................................................................ 41 1.1 O Consideraciones finalES sobre Metodologías de Penetracion de sistemas ....................... 43

CAPITULO 2 ................................................................................................................................ 44 Planeacion Estrategica de la Administracion de la Seguridad de la lnformacion - Definicion de Controles ........................................................................................................................................ 44

2.1 Elementos de un Plan Estrategico de la Administracion de la Seguridad de la lnformacion ................................................................................................................................................... 47

2.1.1 Definicion de Seguridad de la lnformacion .................................................................. 47

3

2.1.2 Patrocinio de la Alta Gerencia y Alineacion con Objetivos de Negocio ...................... 48 2.1.3 Estructura Organica de Seguridad de la Informacion ................................................... 50 2.1.4 Analisis de Riesgos ....................................................................................................... 51 2.1.5 Normatividad de Seguridad de la Informacion ............................................................. 54 2.1.6 Requerimientos Tecnicos ............................................................................................. 56

2.2 Consideraciones Finales para el Plan Estrategico de la Administracion de la Seguridad de la Informacion ............................................................................................................................ 69

CAPITULO 3 ................................................................................................................................ 71 Analisis de resultados obtenidos en pruebas de penetracion a sistemas ........................................ 71

3.1 Escenario# 1 - Obtencion de cuentas validas (a traves de NetBIOS, finger, SMTP, SNMP) y contraseñas triviales ................................................................................................................ 72 3.2 Escenario# 2 - Uso de protocolos no cifrados .................................................................... 74 3.3 Escenario# 3 - Archivos de contraseñas con permisos de lectura publica (Caso HP-UX) 75 3 .4 Escenario # 4 - Aprovechamiento de relaciones de confianza (principalmente a traves de servicios R) ................................................................................................................................ 76 3.5 Escenario# 5 - Contraseñas dentro de codigo con permisos de lectura publica ................. 78 3.6 Escenario# 6 - Vulnerabilidades facilmente explotables de manera remota ...................... 79 3. 7 Escenario # 7- Redes inalambricas abiertas o semiabiertas ................................................ 81 3.8 Escenario# 8 -Tuneleo via ssl (evasion de NIDS) ............................................................. 82 3.9 Escenario# 9 - Herramientas de administracion remota (VNC, Citrix, Terminal Services, PC anywhere) ............................................................................................................................ 84 3 .1 O Escenario # 1 O - Otras puertas y tecnicas ......................................................................... 85 3.11 Conclusiones sobre los escenarios presentados ................................................................. 86

CAPITULO 4 ................................................................................................................................ 87 Modelo propuesto de proteccion en base a analisis de resultados en pruebas de penetracion a sistemas .......................................................................................................................................... 87

4.1 Enfoque Tecnico .................................................................................................................. 88 4.1. l Robustecimiento del Control de Acceso Local ............................................................ 88 4.1.2 Robustecimiento de la plataforma operativa y aplicaciones ........................................ 89 4.1.3 Proteccion de Integridad ............................................................................................... 90 4.1.4 Definicion de roles y responsabilidades ....................................................................... 92 4.1.5 Administracion remota ................................................................................................. 92 4.1.6 Control de acceso a nivel red ........................................................................................ 93 4.1.7 Deteccion de vulnerabilidades ...................................................................................... 95 4.1.8 Deteccion de intrusos ................................................................................................... 96 4.1.9 Analisis y Proteccion de Bitacoras ............................................................................... 98

4.2 Enfoque Normativo y Corporativo .................................................................................... 100 4.2.1 Normatividad - Politicas, Procedimientos y Estandares ............................................ 100 4.2.2 Analisis de riesgos ...................................................................................................... 101 4.2.3 Programa de conciencia de seguridad ........................................................................ 102 4.2.4 Continuidad del Negocio ............................................................................................ 102

CAPITULO 5 .............................................................................................................................. 105 CONCLUSIONES ....................................................................................................................... 105 REFERENCIAS BIBLIOGRAFICAS ......................................................................................... 108 BIBLIOGRAFIA ......................................................................................................................... 110

4

Indice de figuras .......................................................................................................................... 115

5

DEDICATORIA

A mi madre

6

AGRADECIMIENTO

Toda mi admiración, respeto y agradecimiento a Adolfo Grego, Roberto Gómez y Jesús Vázquez.

•

7

INTRODUCCION

"La guerra es de vital importancia para el Estado; es el dominio de la vida o de la muerte, el camino hacia la supervivencia o la pérdida del Imperio: es forzoso manejarla bien. No

reflexionar seriamente sobre todo lo que le concierne es dar prueba de culpable indiferencia en lo que respecta a la conservación o pérdida de lo que nos es más querido"

Sun - Tzu, El Arte de la Guerra

La seguridad de la información es cada día un mayor reto y tema de gran importancia para las organizaciones tanto públicas como privadas. Para la mayoría de ellas el activo llamado información se está convirtiendo en el más importante y pieza clave para lograr sus objetivos de negocio. Responder a la pregunta: ¿Cómo puede ser comprometida o puesta en riesgo la información o infraestructura que la soporta? No es tarea fácil, y menos ¿Cómo protegerla de las amenazas a las que pueda estar expuesta? La mayoría de los enfoques sobre este tema se basan en proteger a la información principalmente vía elementos tecnológicos sin entender primero el problema para poder así atacarlo de manera ordenada y estratégica.

Este documento toma como punto de partida el entendimiento de la seguridad de la información a través de un enfoque de administración de riesgos y como un conjunto de tres elementos básicos: tecnología, procesos y gente. Siendo los dos últimos vitales cuando la información deja la forma de "bits y bytes" y pasa a un estado distinto, por ejemplo: impresa, escrita u oral.

Los siguientes son sólo algunos números que justifican la complejidad del tema seguridad de la información y su importancia:

o De acuerdo con "Computer Economics" el impacto mundial de las amenazas combinadas Nimda, Código Rojo y Sircam fue de 4.4 mil millones de dólares. A su vez, los daños ocasionados por el gusano "I Love Y ou" fueron de 8 mil millones de dólares.

o De acuerdo con la encuesta del CSI (Computer Security Institute) y el FBI, en el 2003 el total de las pérdidas relacionadas con incidentes de seguridad de la información durante un año en 251 organizaciones fue de 201 mil millones de dólares. Esto nos da una pérdida promedio anual por organización de más de 800 mil dólares.

o De acuerdo con un estudio realizado por especialistas financieros y de riesgos de la Firma Emst & Y oung ( encabezados por Ph. D. Ashish Garg) un solo incidente de seguridad puede costar a una organización entre 17 y 28 millones de dólares. El estudio está basado en 1 a repercusión del valor de 1 a acción de u na organización debido a un incidente de

seguridad. o De acuerdo con la encuesta global de seguridad de la infom1ación 2003, también de la

Firma Ernst & Y oung, el 90 por ciento de la empresas consideran que el tema de la

•

8

seguridad de la información es muy importante para lograr los objetivos generales del negocio. S in embargo, más del 3 3 por ciento señalan que no cuentan con 1 a habilidad necesaria para responder ante incidentes de seguridad.

o Durante el 2003 el CERT/CC (Computer Emergency and Response Team / Coordination Center) recibió 3,784 reportes de vulnerabilidades y 137,529 reportes de incidentes.

o Durante el 2003 Zone-h.org (http://www.zone-h.org) recibió 37,248 reportes de "web defacements" (tomado en base a dirección IP y no a nombres de dominios).

El objetivo de este documento es presentar un análisis de resultados de pruebas de penetración a sistemas de información realizadas durante los últimos 3 años con el objetivo de identificar las principales debilidades de las tecnologías, procesos y gente que soportan el manejo, comunicación, almacenamiento y protección de este activo estratégico: la información. Con base en lo anterior se propone un modelo de protección que permita a las organizaciones empezar a resolver de manera estratégica el complejo problema de la seguridad de la información. Para aquellas que ya hayan empezado a resolverlo, el análisis de resultados puede servirles como base para evaluar en sus organizaciones las debilidades identificadas, y e 1 modelo puede aportarles ideas para mitigarlas.

La estructura del documento es la siguiente:

En el capítulo 1 se presenta una investigación de las principales metodologías de penetración de sistemas de información, algunas de ellas muy recientes como la descrita en OSSTMM ("Open Source Security Testing Methodology Manual") y en la guía del NIST (National Institute of Standards and Technology) 800-42 así como las propuestas por autores reconocidos como Temmingh; Peltier y Blackley; Klevinsky, Laliberte y Gupta; McClure, Scambray y Kurtz; y algunas no tan recientes pero trascendentales por su valor histórico como las de Dan Farmer y Wietse Venema; Rhino9 y "Neonsurge"; y "Mixter".

En el capítulo 2 se describen, en primera instancia, los elementos básicos de una "Planeación Estratégica" para tomarlos como punto de partida en la definición de un programa de "Administración de la Seguridad de la Información". Se propone una definición de seguridad de la inforrnación y se establece la importancia del patrocinio de la alta gerencia y la alineación de la seguridad de la información con los objetivos de negocio. Adicionalmente, se establecen los elementos básicos de una estructura orgánica de seguridad de la información, análisis de riesgos y normatividad de seguridad de la información. Finalmente, se analizan los elementos técnicos de seguridad de red y seguridad local ( o "en host").

En el capítulo 3 se presenta un "Análisis de resultados obtenidos en pruebas de penetración a sistemas" a través de la descripción de los 1 O escenarios más comunes. Estos son tomados como base para proponer en el capítulo 4 un "Modelo de Protección" que tiene como principal objetivo convertirse en una guía que permita mitigar los riesgos identificados en los escenarios. Este modelo se compone de dos enfoques, el primero "Técnico" y el segundo "Normativo y Corporativo".

Finalmente, el capítulo 5 presenta las conclusiones producto de este trabajo .

9

Es importante señalar que entender cómo es que se ataca para proponer defensas no es un enfoque nuevo, sin embargo, lo relevante e innovador de este trabajo es que todo el análisis es con base en pruebas de penetración en empresas mexicanas o con operaciones en México.

CAPITULO 1

INTRODUCCION A LAS METODOLOGIAS DE PENETRACION DE SISTEMAS DE INFORMACION

10

"Método y disciplina ha de ser comprendida como la organización del ejército, las graduaciones y rangos entre los oficiales, la regulación de las rutas de suministros, y la provisión de material

militar al ejército. " Sun - Tzu, El Arte de la Guerra.

Detrás de una técnica hoy tan utilizada como las pruebas de penetración a sistemas de información debe haber una metodología formalizada que permita identificar debilidades y vulnerabilidades de manera estratégica de tal forma que se puedan encontrar las mejores vías de ataque.

El riesgo que se corre al carecer de una metodología es invertir más tiempo y recursos en intentar acceder a un sistema o conjunto de sistemas ya que posiblemente no se logren identificar todas las posibles puertas de entrada o peor aún las más sencillas. Adicionalmente, cuando se realizan pruebas de Penetración de Sistemas se debe analizar todo el medio ambiente en el que se encuentra nuestro sistema o sistemas objetivos, ya que dificilmente un profesional de esta actividad solo se centrará en éste o estos. Lo anterior se basa en el hecho de que un atacante precisamente actuará de esta manera para lograr su fin.

Resulta importante señalar que un profesional dedicado a las Pruebas de Penetración de Sistemas de Información deberá tener un enfoque similar al utilizado por un atacante (que en muchas ocasiones es considerado un delincuente informático). Por esto es también indispensable que conozca sus técnicas, metodologías y herramientas así como las debilidades de los sistemas de cómputo a los cuales se enfrentará. Dicho profesional debe conocer con profundidad los elementos que se le presenten en su camino, como son sistemas operativos, firewalls, enrutadores, sistemas de detección de intrusos, aplicaciones en red corno servidores de web y bases de datos, protocolos telnet, secure shell, ftp, correo electrónico, netbios, nfs, http, https, dns, arp, etc. y sin lugar a dudas debe también tener un entendimiento pleno de TCP/IP. Lo

11

anterior como base, pero definitivamente requiere habilidades adicionales como programación, técnicas de persuasión, entre otras.

Las Pruebas de Penetración de sistemas, por lo general, manejan dos enfoques: externo o interno. Al hablar de un enfoque externo nos referimos a aquellas pruebas de Penetración realizadas desde un punto externo, comúnmente Internet, hacia la red objetivo (sistemas expuestos a Internet de una Compañía, por ejemplo: sus servidores de web, de correo electrónico, de dominio, etc). Es decir, este enfoque, por lo general, involucra el concepto de una zona de seguridad o DMZ ("demilitarized zone") creada la mayoría de las veces por un control de acceso a nivel red o firewall.

Cuando se habla de un enfoque interno se refiere a aquellas pruebas de Penetración que se llevan a cabo desde dentro de una Compañía o red objetivo, esto debido a que la mayoría de las ocasiones los sistemas de mayor criticidad se encuentran dentro de la Compañía y comúnmente no se encuentran expuestos a Internet. Es importante señalar que los ataques que ocasionan mayores pérdidas, de acuerdo a la encuesta de 2003 del Computer Security Institute y el FBI en los Estados Unidos, son aquellos cometidos por empleados de una Compañía hacia los sistemas críticos de la misma. Esto es congruente con el hecho que los que conocen mejor a una Compañía son sus propios empleados. Lo anterior se confirma con la Encuesta Global de Seguridad de la Información 2003 realizada por la firma Ernst & Y oung, en la cual se percibe a los empleados internos como la segunda mayor amenaza colocados solo después de los virus informáticos (y en general, código malicioso como gusanos).

Adicional al enfoque interno y externo también se puede utilizar en estos dos, los conceptos de caja gris o caja negra (en ocasiones también señalados como de equipo azul o de equipo rojo, respectivamente). Caja gris se refiere cuando ya contamos con cierta información de la red o sistemas objetivo y además también se utiliza este térn1ino cuando los administradores de dicha red o sistemas están enterados de las pruebas que se realizarán. En cambio, cuando nos referimos a un enfoque de caja negra se asume que no se tiene mayor información que posiblemente el nombre de la red o sistemas objetivos y que además los administradores de estos no están enterados de las pruebas.

A continuación se presentan algunas de las metodologías más reconocidas y utilizadas para realizar pruebas de penetración a sistemas de información.

1.1 PRIMER ACERCAMIENTO, UN DOCUMENTO HISTORICO: WARDOC

Debido a la complejidad de escenarios y tecnologías a las que un profesional dedicado a las pruebas de Penetración de Sistemas se puede llegar a enfrentar, dicha labor debe estar apoyada por una metodología. Rhino9 y Neonsurge en [1) establecen las siguientes fases como parte de una metodología de penetración específica para el sistema operativo Windows NT:

12

a) Recopilación de información y penetración vía NetBIOS b) Recopilación de información y penetración vía servidor de web

Lo trascendente de este documento es que nos presenta como primera etapa esencial la recopilación de información del sistema objetivo, en este caso, específicamente con el sistema operativo Windows NT. Adicionalmente, como segunda etapa sugiere la explotación de una debilidad o vulnerabilidad identificada producto de la primera fase.

1.2 GUIA PARA EVALUAR LA SEGURIDAD EN RED (PUBLICACION ESPECIAL DEL NIST 800-42)

El Departamento de Comercio de los Estados Unidos de América a través del Instituto Nacional de Estándares y Tecnología, emitió en octubre de 2003 la publicación especial número 800-42 titulada "Guideline on Network Security Testing" [2] (Guía para evaluar la seguridad en red). Las fases que señala esta publicación para la evaluación de la seguridad a nivel red son:

a) Pruebas de roles y responsabilidades b) Escaneo desde la red c) Escaneo de vulnerabilidades d) "Crack" de contraseñas e) Revisión de bitácoras f) Verificadores de integridad de archivos g) "Wardialing" h) "War Driving" i) Pruebas de Penetración j) Acciones post-pruebas k) Principios generales de la Seguridad de la Información

Como puede observarse esta guía incorpora una fase específicamente de Pruebas de Penetración. Asimismo, sobre este tema establece las siguientes cuatro fases:

a) Planeación b) Descubrimiento c) Ataque d) Reporte

Esta metodología hace énfasis en que después de la etapa de ataque se puede volver a dar una fase de descubrimiento y esto está basado en el hecho de que una vez que se ha logrado tener acceso a un sistema necesariamente se tendrá que volver a realizar una fase de descubrimiento para conocer a que nueva información se ha ganado acceso y también para intentar acceder a nuevas redes o a otros sistemas tomando ahora éste como punto de partida. También es

13

importante mencionar que esta metodología de cuatro fases hace hincapié en la documentación en todo momento de las acciones realizadas.

En la fase de planeación las reglas son identificadas, la aprobación por parte del dueño del sistema objetivo es finalizada y las metas de las pruebas de penetración son establecidas. Aunque durante esta fase no se realizan pruebas, parte del éxito o fracaso de las mismas puede deberse a una falta de atención de ésta ya que las expectativas de las pruebas pueden que no estén acordes a los requerimientos.

En la fase de descubrimiento las pruebas dan inicio principalmente con un reconocimiento inicial de los sistemas objetivo y sus puertos (TCP - UDP) abiertos. Adicional a la técnica de reconocimiento de puertos, se utilizan otras técnicas para recopilar información de los sistemas objetivo, las más comunes son:

a) Interrogación de DNS (Servidor de Nombres de Dominio), comúnmente a través del intento de una transferencia de zona.

b) Consultas o "queries" a bases de información como whois (comúnmente InterNIC o NIC México, para dominios con terminación com.mx, net.mx, edu.mx, org.mx, gob.mx o .mx).

c) Búsqueda con contactos e información relevante dentro del propio servidor de web de la Compañía objetivo.

d) Búsqueda de información a través de servidores LDAP (acrónimo de "Lightweight Directory Access Protocol" )

e) Captura de paquetes en su tránsito por la red, aunque esta técnica es utilizada solo cuando se realizan pruebas desde el interior de la Compañía objetivo.

f) Enumeración a través de NetBIOS, al igual que el punto anterior, esta técnica es utilizada la mayoría de las veces cuando se realizan pruebas desde el interior de la Compañía objetivo.

g) Obtención de "banners" o identificadores de aplicaciones en red, comúnmente utilizada para obtener versiones de servidores de web, telnet, ftp, secure shell, etc.

La segunda parte de la fase de descubrimiento es el análisis de vulnerabilidades. Durante esta fase, los servicios, aplicaciones y sistemas operativos identificados son comparados contra bases de datos sobre vulnerabilidades de los mismos. Es importante señalar que en la mayoría de las ocasiones los equipos de Penetración de Sistemas tienen sus propias bases de conocimiento en donde se guardan o recopilan las principales vulnerabilidades identificadas, las más comunes, las de mayor severidad y de las que se sabe de la existencia de un código público que puede aprovechar dicha vulnerabilidad. Las bases de datos sobre vulnerabilidades más comunes son: el CVE (acrónimo de "Common Vulnerabilities and Exposures" de Mitre, b ugtraq hospedada en SecurityFocus, ICAT dentro de NIST, CERT (del Instituto de Ingeniería de Software de Camegie Mellon, entre otras). En ocasiones ésta información es complementada o confirmada con herramientas automáticas de detección de vulnerabilidades (por ejemplo: Nessus de Renaud Deraison, Retina de eEye, Internet Scanner de ISS, Whisker/Libwhisker de RFP, Nikto de Sullo, Shadow Security Scanner de Safety Lab, entre otros).

14

La siguiente fase mencionada es la de ataque la cual se convierte en el centro de la mayoría de las pruebas de penetración, esto debido a que si las dos fases anteriores fueron realizadas de manera adecuada entonces seguramente se habrá identificado una o varias avenidas de ataque hacia los sistemas objetivo, por lo general, priorizadas por su nivel de complejidad y factibilidad. En caso de que se logre explotar una vulnerabilidad identificada, es importante que se establezcan las posibles contramedidas o controles que pueden mitigar la manera de explotar dicha vulnerabilidad. Es importante mencionar, que muchos de los ataques, principalmente en ambientes con sistema operativo UNIX (HP-UX, Solaris, AIX, Linux, FreeBSD, etc.) otorgan acceso a nivel de usuario sin privilegios en el sistema por lo que el siguiente paso será explotar alguna debilidad o vulnerabilidad que permita obtener privilegios de súper usuario (por ejemplo, "root"). De cualquier manera el obtener privilegios de usuario local en el sistema es relevante ya que se podrá obtener un mayor entendimiento del entorno objetivo. Resulta indispensable realizar un análisis profundo de esta situación para conocer de mejor manera el verdadero riesgo de dicho entorno.

En resumen, podemos decir que después de la fase de planeación y descubrimiento se presenta la fase de ataque la cual comprende las siguientes etapas:

a) Acceso local con o sin privilegios de súper usuario. b) Escalamiento de privilegios c) Recopilación de información desde y dentro del sistema al que se logró acceso d) Instalación de software adicional para ganar mayor información o accesos ( esto debe

establecerse, aclararse y autorizarse en la fase de planeación ya que la instalación de software puede ocasionar desconfianza en la integridad, disponibilidad y/o confidencialidad de los datos y programas contenidos en el mismo).

Resulta relevante mencionar que la mayoría de las herramientas de detección de vulnerabilidades solo verifican la existencia de éstas, solo en pocas ocasiones por si solas ejecutan el código que pe1mite confirmar al 100% su existencia. Esta excepción aplica a las vulnerabilidades que causan negaciones de servicios, ya que en la mayoría de las pruebas de la existencia de éstas si se ejecuta el código. Lo anterior da como resultado que las herramientas, como su nombre lo dice, son solo un elemento más dentro de las Pruebas de Penetración. Se tendrán que discriminar los falsos positivos de los resultados que nos entreguen las herramientas para así tener un escenario real del estado de los sistemas objetivo. Como consecuencia de esto, para garantizar que un sistema es vulnerable se debe ejecutar e 1 código que a provechad icha falla ya se a a través de un código disponible públicamente o a través de la programación del mismo. Dependiendo de los requerimientos y criticidad de la infraestructura se puede tomar alguno de estos dos enfoques, aunque la mayoría de las veces se prefiere invertir mayor tiempo en la contramedida o control que en la programación del código que explota una cierta vulnerabilidad. Un tercer enfoque es cuando a través de las Pruebas de Penetración se encuentra una nueva vulnerabilidad, es decir, una vulnerabilidad que nunca antes había sido reportada por el proveedor o desarrollador de dicha aplicación, sistema operativo, base de datos, etc. En este caso el líder del equipo de Pruebas de Penetración, se pone en contacto con el proveedor o desarrollador para reportarle el hallazgo con lo cual éste se compromete a solucionarlo en un tiempo determinado antes de que cualquiera de las dos partes haga público el código que aprovecha la vulnerabilidad identificada. Es

•

'

•

15

importante mencionar que hay quienes prefieren hacer pública cierta vulnerabilidad sin reportarla al proveedor o desarrollador. Lo anterior se conoce como "vulnerabilidades de día cero", las cuales se liberan en foros específicos (ej.: convenciones de "hackers") o a un reducido número de personas antes de hacerlas totalmente públicas.

La mayoría de las vulnerabilidades utilizadas para ganar acceso a los sistemas por parte del equipo de Pruebas de Penetración y por consiguiente de atacantes maliciosos ( que pueden ser script kiddies o delincuentes informáticos) entran en alguna de las siguientes categorías:

a) Falla en el Kernel o núcleo del sistema operativo. Es importante señalar que el modelo de seguridad del sistema operativo es controlado e implementado a través del Kernel.

b) Desbordamiento de memoria. Comúnmente encontrados por falta de validación de espacios de memoria como resultado de prácticas inadecuadas en la programación. Cuando esto ocurre, se puede ejecutar código arbitrario en el sistema con los privilegios del programa atacado .

c) Ligas simbólicas (o "simlink"), utilizadas para que un archivo apunte hacia otro archivo. Puede haber programas que cambien los permisos otorgados a estos archivos, si estos programas corren con privilegios e levados, un usuario podría crear ligas simbólicas de manera que engañe a estos programas para realizar tareas no autorizadas como modificación o listado de archivos críticos del sistema.

d) Ataques a los descriptores de archivos, estos descriptores son enteros no negativos que el sistema utiliza para llevar control de los archivos en lugar de utilizar los nombres de los mismos. Cuando un archivo privilegiado asigna descriptores de archivos inapropiados lo expone a ser comprometido.

e) Condiciones de ejecución (o "race conditions"), las cuales ocurren cuando un programa o proceso ha entrado en un modo privilegiado. Un atacante puede aprovechar esto si logra comprometer el programa o proceso en el tiempo que éste permanece en estado privilegiado.

f) Permisos en archivos y directorios, los cuales controlan el acceso a usuarios y procesos por lo que su definición es indispensable para preservar la seguridad del sistema. Permisos inadecuados pueden permitir la lectura de archivos críticos como el archivo de contraseñas o la modificación de otros en los que se puede agregar un sistema en el cual se confia (por ejemplo en Unix los archivos /etc/hosts.equiv o .rhosts)

g) Caballos de Troya, como BackOrifice, NetBus, SubSeven, Deep Throat. También son comunes a este respecto las puertas traseras (o "root kits") a nivel Kernel una vez que se ha logrado acceso al sistema con privilegios de súper usuario.

h) Ingeniería Social, definido por muchos como una de las mejores técnicas en donde el uso del engaño es esencial para obtener información sensitiva como nombres de equipos, claves de acceso y usuarios.

Finalmente, la cuarta fase comprende la elaboración del reporte o documentación de hallazgos y recomendaciones. Es muy importante señalar que esta etapa no es secuencial ni en tiempo ni en espacio, de hecho se realiza en paralelo con las primeras tres etapas. Mucho se dice que uno de los factores de éxito en cualquier Prueba de Penetración es una adecuada documentación de todas las acciones, tareas y actividades realizadas, esto hace sentido si tomamos en cuenta que solo a

•

16

través de evidencias podremos reproducir el ataque y demostrarlo. También es relevante señalar que la única manera que tendremos para deslindamos de responsabilidades sobre caídas o fallas de sistemas es a través de esta documentación, suele suceder que cualquier anomalía en el funcionamiento de los si stemas es asociada directamente a 1 equipo que realiza las Pruebas de Penetración, esto en los casos de que las dichas pruebas sean de conocimiento del grupo de administradores a cargo de los sistemas evaluados.

Comúnmente, el reporte de las Pruebas de Penetración contiene una descripción detallada de cada uno de los hallazgos identificados (tanto vulnerabilidades como debilidades de los sistemas evaluados) así corno u na descripción y evaluación del riesgo que representa y finalmente u na recomendación que mitigue dicho riesgo. Por lo general, se establece un plan de acción con el cual de manera estratégica y metódica se puedan resolver los hallazgos identificados, colocando como prioridad alta lo que ponen en mayor riesgo a la Compañía y dejando al final los que tienen poca probabilidad de ser atacados. Es importante que el equipo de Penetración identifique desde su óptica las causas raíz de los hallazgos encontrados ya que en la mayoría de los casos no funciona, por ejemplo, el actualizar una aplicación o sistema operativo, sino de fondo puede haber algo más grave como la falta de una política y procedimientos asociados a la actualización de versiones, la falta de conciencia de seguridad de los administradores o la falta de un ambiente de pruebas que permita evaluar el impacto que tiene la aplicación de actualizaciones en los sistemas.

Como resultado de la metodología presentada podemos concluir que las Pruebas de Penetración aportan a la Compañía una visión de que tan vulnerable es su infraestructura tecnológica evaluada, que generalmente es infraestructura crítica. Por esto este ejercicio de Penetración se recomienda realizar por lo menos de manera anual. Adicionalmente, para que las Pruebas de Penetración sean productivas en la Compañía deben presentarse los resultados a los niveles directivos y en el mejor de los casos a la Alta Gerencia de la Compañía.

1.3 METODOLOGIA OSSTMM ("OPEN SOURCE SECURITY TESTING METHODOLOGY MANUAL")

En [3] Pete Herzog expone una metodología que pretende convertirse en estándar para la realización de pruebas de penetración y, en general, pruebas de seguridad o análisis de seguridad. Básicamente es un guía que intenta establecer los lineamientos básicos para pruebas de penetración desde el exterior, es decir, desde una red no privilegiada, como podría ser Internet, hacia una red privilegiada (ej. DMZ de una Compañía). El primer señalamiento importante que realiza este documento es el establecer una terminología para cada uno de los tipos de pruebas que pueden llegar a presentarse en escenarios reales. Dicha terminología es la siguiente:

a) "Escaneo" o búsqueda de vulnerabilidades, se refiere generalmente a las comprobaciones automáticas de un sistema o sistemas dentro de una red, comúnmente a través de herramientas como nessus, etc .

lt

•

17

b) "Escaneo" de la Seguridad, se refiere en general a las búsquedas de vulnerabilidades que incluyen verificaciones manuales de falsos positivos, identificación de los puntos débiles de la red y análisis profesional individualizado.

c) "Test" o prueba de intrusión ( en inglés: "Penetration Testing"), se refiere en general a los proyectos orientados a objetivos en los cuales dicho objetivo es obtener un trofeo, que incluye ganar acceso privilegiado con medios y circunstancias preestablecidos.

d) Evaluación de Riesgos, se refiere a los análisis de seguridad a través de entrevistas e investigación de nivel medio que incluye la justificación de negocios, las justificaciones legales y las justificaciones específicas de la industria. Comúnmente, se hace una ponderación de la criticidad de cada uno de estas justificaciones en base a la importancia de éstas para cada Compañía, puede ser que, por ejemplo, los aspectos legales y de regulación sean vitales para un cierto sector.

e) Auditoria de Seguridad, hace referencia a la inspección manual con privilegios administrativos del sistema operativo y de los programas de aplicación del sistema o sistemas dentro de una red o redes.

f) Hacking ético, se refiere generalmente a las pruebas de intrusión en las cuales el objetivo es obtener trofeos en la red dentro del tiempo predeterminado de duración del proyecto.

g) "Test" o prueba de seguridad y su equivalente militar, Evaluación de Postura, es una evaluación del riesgo con orientación de proyecto de los sistemas y redes, a través de la aplicación de análisis profesional mediante "escaneas" o búsquedas de seguridad donde la intrusión se usa generalmente para confirmar los falsos positivos y los falsos negativos dentro del tiempo permitido de duración del proyecto.

Esta metodología tornó en consideración durante su diseño a las siguientes prácticas líder ( en ocasiones llamadas mejores prácticas):

a) Biblioteca de TI publicada por la "British Office" (http://www.ogc.gov.uk/) b) Manual de Protección para TI publicado por la Oficina Federal de Seguridad de la

Información (http://www.bsi.de/gshb/english/menue.htm) c) Sistemas Alemanes de TI d) ISO 17799-2000 (BS 7799 parte 1) e) Actividades de control descritas en GAO de Estados Unidos (acrónimo de "General

Accounting Office's", en español: Oficina General de Contaduría) y de FISCAM también de Estados Unidos (acrónimo de "Federal lnformation System Control Audit Manual", en español: Manual de Auditoria del Control de los Sistemas de Información Federales).

f) SET (acrónimo de "Secure Electronic Transaction", en español: Transacciones Electrónicas Seguras). Esto quiere decir que esta metodología incluye en sus pruebas a este protocolo conocido como SET.

g) NIST de los Estados Unidos, el cual ha emitido las siguientes publicaciones relevantes para el tema de Seguridad de la Información y Pruebas de Penetración:

a. "An Introduction to Computer Security: The NIST Handbook", 800-12 b. "Guidelines on Firewalls and Firewall Policy", 800-41 c. "lnformation Technology Security Training Requirements: A Role and

Performance-Based Model", 800-16 d. "Guideline on Network Security Testing", 800-42

18

e. "PBX V ulnerability A nalysis: F inding H oles in Your P BX B efore S omeone Else Does", 800-24.

f. "Risk Management Guide for lnformation Technology Systems", 800-30 g. "Intrusion Detection Systems", 800-31

h) MITRE ( centro de investigación y desarrollo de los Estados Unidos que da soporte a infraestructura de importancia nacional), ha establecido una base de información que concentra un número muy importante de vulnerabilidades reportadas de distintos sistemas operativos, aplicaciones, bases de datos, etc.

Como parte de esta metodología se establecen reglas que definen una guía ética de prácticas aceptables de mercadeo, comercialización y ventas de los compromisos o contratos de pruebas de penetración. Algunas de estas reglas son:

a) El miedo, incertidumbre o duda no podrán ser utilizados para vender pruebas de penetración, por ejemplo: crímenes, estadísticas, etc.

b) Ofrecer servicios gratuitos por no haber conseguido los trofeos en las pruebas de penetración está prohibido.

c) Eventos públicos de "hacking" o "cracking" para promover servicios de pruebas de penetración y en general cualquier tipo de pruebas o evaluaciones de seguridad está prohibido.

d) Realizar evaluaciones a cualquier red o sistema del cual no se tenga autorización del propietario está prohibido.

e) El nombre de clientes de compromisos o contratos anteriores está prohibido aún con el consentimiento del cliente.

f) Verificar servicios vulnerables sin la autorización escrita está prohibido. g) Probar sistemas que son evidentemente vulnerables sin que antes se le haya instalado,

configurado y acondicionado la seguridad está prohibido. h) Con un a cuerdo de confidencialidad o sin é 1 ( en inglés: "Non-Disclosure A greement")

quienes realicen las pruebas de penetración no podrán publicar los resultados. i) Quienes realicen las pruebas de penetración deberá establecer claramente los riesgos de

las mismas. j) Los que realicen las pruebas de penetración deberán conocer sus herramientas, su origen y

deberán haberlas probado primero antes de utilizarlas en las instalaciones de algún cliente. k) Las pruebas de negación de servicio solo podrán realizarse si existe autorización expresa

y por escrito del propietario del sistema. 1) Vulnerabilidades o debilidades que sean consideradas de alto riesgo deberán ser

notificadas al cliente de inmediato. m) Los reportes deberán incluir soluciones prácticas. n) Los reportes deberán contener todos los hallazgos y en general el estado real de la

seguridad, no solo las fallas o faltas de controles que se hayan identificado.

Estas son solo algunas de las reglas que establece esta metodología con el afán de crear un ambiente de certidumbre y ética en las pruebas de penetración y en general en las pruebas de seguridad a los sistemas de información y la infraestructura que los soporta.

•

19

1.3.1 EL PROCESO

El proceso de un análisis de seguridad se concentra en evaluar las siguientes áreas que reflejan los niveles de seguridad. Estos son conocidos como las Dimensiones de Seguridad:

a) Visibilidad. Es lo que puede verse, registrarse o monitorearse en el nivel de seguridad con o sin la ayuda de dispositivos electrónicos. Esto incluye, pero no se limita a, ondas de radio, luz por encima del espectro visible, dispositivos de comunicación como teléfonos, GSM, correo electrónico y paquetes de red como TCP/IP.

b) Acceso. Es el punto de entrada al nivel de seguridad. Un punto de acceso no requiere ser una barrera física. Esto puede incluir, pero no se limita a, un servidor de página web, una ventana, una conexión de red, ondas de radio o cualquier elemento cuya ubicación soporte la definición de cuasi público o donde un sistema interactúa con otro por medio de una red. Limitar el acceso significa negar todo excepto lo que esté expresamente permitido de acuerdo a la política de seguridad de la Compañía y prácticas líder.

c) Confianza. Es una ruta especializada en relación con el nivel de seguridad, incluye la clase y cantidad de autenticación, no repudio, control de acceso, contabilización, confidencialidad e integridad entre dos o más factores dentro del nivel de seguridad.

d) Autenticación. Es la medida por la cual cada interacción en el proceso está privilegiada. e) No-repudio. Provee garantía que ninguna persona o sistema responsable de la interacción

pueda negar ser parte de la misma. f) Confidencialidad. Es la certeza de que únicamente los sistemas o partes involucradas en

la comunicación de un proceso tengan acceso a la información privilegiada del mismo. g) Privacidad. Implica que el proceso es conocido únicamente por los sistemas o partes

involucradas. h) Autorización. Es la certeza que el proceso tiene una razón o justificación de negocios y

es administrado responsablemente dando acceso permitido a los sistemas. i) Integridad. Es la certeza que el proceso tiene finalidad y que no puede ser cambiado,

continuado o redirigido sin el conocimiento de los sistemas o partes involucradas. j) Seguridad. Son los medios por los cuales un proceso no puede dañar otros sistemas o

procesos incluso en caso de falla total del mismo. k) Alarma. Es la notificación apropiada y precisa de las actividades que violan o intentan

violar cualquiera de las dimensiones de seguridad. En la mayoría de las violaciones de seguridad, la alarma es el único proceso que genera reacción.

1.3.2 EL MAPA DE SEGURIDAD

Esta metodología establece un mapa de seguridad el cual es una representación visual de la presencia de la seguridad, definida ésta como el medio ambiente de una prueba de seguridad y está compuesta de seis secciones que se superponen entre sí:

•

•

Segundad de la Información

Seguridad de los Procesos

Fig.1.1. Mapa de Seguridad de acuerdo a OSSTMM

A continuación se presenta una breve descripción de cada una de estas seis secciones:

20

1. Seguridad de la Información, en esta evaluación se analizan los datos disponibles sobre la infraestructura objetivo, por ejemplo: servidores de web, sistemas operativos que soportan aplicaciones expuestas a Internet así como internas. Adicionalmente, se realiza una investigación de información que la Institución objetivo haya hecho pública como solicitud de profesionales de TI o seguridad. También se realiza una revisión de la privacidad desde el punto de vista legal y ético del almacenamiento, transmisión y control de información personal tanto de empleados como de clientes. Los puntos evaluados en esta sección se presentan a continuación:

a. Evaluación de la postura b. Revisión de la integridad de la información c. Encuesta de Inteligencia d. Búsqueda de documentación en Internet e. Revisión de recursos humanos f. Análisis de inteligencia competitiva g. Revisión de controles de privacidad h. Revisión de controles de información

2. Seguridad de los Procesos, en esta evaluación se buscan posibles fallas en los procesos que pudieran permitir ganar acceso privilegiado a un sistema de la infraestructura objetivo, por ejemplo, a través de preguntas por teléfono o correo electrónico en donde no exista una autenticación dentro del proceso de solicitud de información confidencial como contraseñas de cuentas (ingeniería social). Los puntos evaluados en esta sección son:

a. Revisión de la postura

'

'

21

b. Prueba de solicitud c. Prueba inversa de solicitud d. Prueba de sugerencias guiada e. Prueba de personas confiables

3. Seguridad de las tecnologías de Internet, en esta evaluación se realizan revisiones técnicas de la infraestructura objetivo. Se identifican puertos TCP y UDP, así como las aplicaciones que están disponibles a través de dichos puertos. Adicionalmente, en esta sección se realiza una investigación sobre las posibles vulnerabilidades de la infraestructura identificada. En caso de que se identifique algún tipo de control de acceso (por ejemplo: usuario y contraseña) se prueba a través de ataques de diccionario y fuerza bruta. También son evaluados los sistemas de detección de intrusos y firewalls. A continuación se presentan los puntos a evaluar esta sección:

a. b. c. d. e. f. g. h. l.

J. k. l. m. n. o.

Logística y controles Revisión de la postura Revisión de Detección de Intrusos Sondeo de la red Identificación de servicios en los sistemas Análisis de inteligencia competitiva Revisión de privacidad Exploración de documentación Pruebas a aplicaciones de Internet Investigación y verificación de "exploits" Ruteo Pruebas de sistemas confiables Pruebas de controles de acceso Evaluación de contraseñas ( en inglés: "Password Cracking") Prueba de medidas de contención

p. Pruebas de supervivencia q. Pruebas de negación de servicio r. Revisión de la política de seguridad s. Revisión de alertas y bitácoras

4. Seguridad de las Comunicaciones, durante esta sección se evalúan elementos de telecomunicaciones como conmutadores, faxes, módems, entre otros para conocer posibles vulnerabilidades en los mismos, que puedan permitir acceso a la infraestructura objetivo. Esta sección incluye las siguientes revisiones:

a. Revisión de la postura b. Revisión de PBX c. Revisión de correo de voz d. Revisión de FAX e. Exploración de módems f. Pruebas de control de acceso remoto

•

22

g. Pruebas de voz sobre ip h. Pruebas de redes X.25

5. Seguridad Inalámbrica, durante esta sección se evalúan las emisiones electromagnéticas de dispositivos como puntos de acceso inalámbricos, monitores, entre otros. Los puntos evaluados en esta sección son:

a. Revisión de la postura b. Pruebas de radiación electromagnética c. Pruebas de redes inalámbricas 802.11 d. Pruebas de redes "Bluetooth" e. Pruebas de entrada de dispositivos inalámbricos f. Pruebas de dispositivos de mano inalámbricos g. Pruebas de comunicaciones sin cables h. Pruebas de supervivencia de dispositivos inalámbricos 1. Pruebas de transacciones de dispositivos inalámbricos J. Pruebas RFID k. Pruebas de dispositivos infrarrojo l. Revisión de la privacidad

6. Seguridad Física, durante esta sección se evalúan los perímetros fisicos, los controles de acceso fisicos así como su monitoreo y custodia, también se evalúan los sistemas de alarma fisicos. Las revisiones realizadas en esta sección son:

a. Revisión de la postura b. Revisión de los controles de acceso c. Revisión del perímetro d. Revisión del monitoreo e. Revisión de la respuesta a las alertas f. Revisión de la ubicación g. Revisión del medio ambiente

Es importante mencionar que de acuerdo a la metodología, un análisis apropiado de cualquier sección debe incluir los elementos de todas las demás secciones en donde exista un traslape. Los incisos de cada sección corresponden a los módulos o elementos primarios de cada sección, cada módulo debe incluir las once Dimensiones de Seguridad. Para realizar un análisis de seguridad OSSTMM de una sección particular todos los módulos de la sección deben ser desarrollados y aquellos para los que no exista infraestructura y no pueda ser verificada, debe definirse como NO APLICABLE en el reporte o informe final.

Con la finalidad de clarificar lo anterior se presenta el siguiente ejemplo, la Sección de Seguridad Física está compuesta por siete módulos los cuales son: revisión de la postura, revisión de los controles de acceso, revisión del perímetro, revisión del monitoreo, revisión de la respuesta a las alertas, revisión de la ubicación y revisión del medio ambiente. Cada uno de estos siete módulos debe tomar en cuenta las once Dimensiones de Seguridad (visibilidad, acceso,

•

23

confianza, autenticación, no-repudio, confidencialidad, privacidad, autorización, integridad, seguridad, alarma).

1.3.3 EV ALUACION DE RIESGOS

La evaluación de riesgos es llevada a cabo por el analista o profesional de penetración (quien realiza las pruebas de penetración o análisis de seguridad), todos los datos que sean recopilados sirven de soporte para una evaluación válida por medio de pruebas no privilegiadas. Esto implica que si se recopila poca información o esta no es apropiada, puede ser posible proveer una evaluación de riesgos incorrecta, por lo que el analista debe basarse en las mejores prácticas, las regulaciones correspondientes a la industria del cliente, la justificación de negocios del cliente, la política de seguridad del mismo y las cuestiones legales y su ambiente de competitividad.

Limitar la presencia de la seguridad de la información en la Compañía puede provocar un efecto negativo o perjudicial en la gente, la cultura de información, procesos, negocio, imagen, propiedad intelectual, derechos legales o capital intelectual. Este manual mantiene cuatro dimensiones en la evaluación para un medio ambiente de riesgo mínimo:

a) Seguridad. Todas las pruebas deben ejecutarse con la precaución necesaria para evitar los peores escenarios posibles que impliquen grandes pérdidas. Esto implica que el analista mantenga por encima de cualquier cosa el respeto por la seguridad humana.

b) Privacidad. Todos los análisis deben ejecutarse manteniendo el derecho a la privacidad personal sin importar la ley regional. La ética y el entendimiento de la privacidad son a menudo más avanzados que la legislación actual.

c) Practicidad. Todas las pruebas deben ser diseñadas buscando la mínima complejidad, la máxima viabilidad y una profunda claridad.

d) Utilidad. Todas las pruebas deben permanecer dentro del marco de seguridad útil, es decir, lo más seguro es lo menos bienvenido. Las pruebas dentro de este manual son desarrolladas para encontrar un nivel de seguridad útil, también conocido como seguridad práctica.

1.3.4 SEGURIDAD PERFECTA

En la evaluación del riesgo, esta metodología utiliza el concepto de "La Seguridad Perfecta", bajo el cual quien realiza las pruebas de penetración analiza cual sería un estado de "seguridad perfecta" para la Compañía bajo evaluación. Esto se logra con la "Revisión de la Postura", lo cual involucra el análisis de las mejores prácticas, las regulaciones, justificaciones del negocio, la política de seguridad y los aspectos legales de la Compañía. El resultado es una "Seguridad Perfecta" para el cliente. El analista entonces puede proveer un análisis comparativo entre el estado actual de seguridad y la "Seguridad Perfecta". Es importante recalcar que el término "Seguridad Perfecta" puede sonar muy atrevido para cualquiera que viva día a día en el mundo de la Seguridad (Inseguridad) de la Información, sin embargo, el sentido que le da esta metodología

•

•

24

a este término es, de acuerdo a nuestro punto de vista, la "Seguridad Adecuada" o la "Seguridad a la Medida" de acuerdo a los riesgos que enfrenta en su entorno la Compañía.

Algunas de las mejores prácticas definidas de manera teórica hacia la "Seguridad Perfecta" son: accesos remotos cifrados y autenticados, políticas restrictivas (negar todo y habilitar por requerimiento), restricciones de relaciones de confianza, instalación de aplicaciones absolutamente necesarias, depuración y validación de accesos, cifrado de datos, asignación de roles y responsabilidades al personal, entrenamiento de aspectos legales y de las políticas de seguridad, accesos otorgados en base a la necesidad de saber, entre otras.

1.3.5 VALORES DE LA EV ALUACION DE RIESGOS

La metodología integra en cada uno de los módulos (recordar que los módulos son tareas de cada una de las secciones) el concepto de valores de la evaluación de riesgos (RA V s por sus siglas en inglés, Risk Assessment Values) que son definidos como la degradación de la seguridad o incremento en el riesgo sobre un ciclo de vida específico, basándose en las mejores prácticas para pruebas periódicas. La asociación de niveles de riesgo con ciclos de vida ha probado ser un procedimiento efectivo para las métricas de seguridad.

Los conceptos de métricas de seguridad en esta metodología se usan para establecer un ciclo de tiempo estándar para evaluaciones y reevaluaciones con el fin de mantener un nivel de riesgo cuantificable basado en la degradación de la seguridad, incremento de riesgo que ocurre naturalmente a través del tiempo y la habilidad de medir el riesgo de manera consistente y detallada, ambos antes y después del análisis.

Al contrario de lo que sucede con una administración de riesgos convencional, los RA V s operan solamente en la aplicación de la seguridad en la organización. Esto debido a que la primera, la administración de riesgos convencional, toma en cuenta los controles como políticas, procedimientos, procesos, mientras que la metodología de análisis examina estos controles, algunas veces de manera indirecta. Los controles actuales no le interesan al analista, debido a que es la aplicación de estos controles la que determina los resultados de un análisis de seguridad. Una política o procedimiento bien escrita que no sea seguida no tendrá efecto alguno en la seguridad actual. No significa que los controles no sean relevantes; lo que significa es que la aplicación de dichos controles es lo relevante para esta metodología. Resulta obvio debido a que es una metodología de pruebas en donde se comprueba la utilidad y buen funcionamiento de los controles para mitigar riesgos, no solo se analiza la solo existencia del control. Cabe aquí la frase de que un firewall no sirve, lo que sirve es un firewall bien configurado y con una política acorde a las necesidades de negocio de la Compañía.

1.3.6 TIPOS DE RIESGOS

A pesar deque 1 os tipos de riesgos parezcan ser subjetivos, 1 a clasificación de riesgos en 1 os siguientes tipos es bastante objetiva al seguir la metodología OSSTMM:

•

25

a) Vulnerabilidad. Falla inherente en el mecanismo de seguridad mismo o que pueda ser alcanzada por medio de protecciones de seguridad, permitiendo el acceso privilegiado a la ubicación, gente, procesos del negocio y personal o acceso remoto a los procesos, gente, infraestructura generando datos corruptos o eliminados.

b) Debilidad. Una falla inherente a la plataforma o ambiente en el que el mecanismo de seguridad reside, una mala configuración, falla de sobrevivencia, falla de utilidad o falla al cumplir los requerimientos de una política de seguridad.

c) Filtrado de información. Una falla inherente en el mecanismo de seguridad mismo o que puede ser alcanzada por medio de medidas de seguridad que permiten el acceso privilegiado a información sensitiva o privilegiada acerca de datos, procesos de negocio, personal o infraestructura.

d) Preocupación. Un evento de seguridad que puede resultar al no seguir las prácticas recomendadas de seguridad, y que por el momento no se presenta como un peligro actual.

e) Desconocidos. Un elemento desconocido o sin identificación en el mecanismo de seguridad o que pueda ser alcanzado a través de las medidas de seguridad y actualmente no tiene impacto conocido en la seguridad ya que tiende a no tener sentido.

1.3.7 SECCIONES Y MODULOS

La metodología está dividida en secciones, módulos y tareas. Estas secciones son puntos específicos en el mapa de seguridad que se sobreponen entre si y comienzan a descubrir un todo que es mucho mayor a la suma de sus partes. Los módulos son e 1 flujo de 1 a metodología desde un punto de presencia de seguridad, cada sección se compone de varios módulos y estos a su vez de tareas. Cada módulo tiene una entrada y una salida. La entrada es la información usada en el desarrollo de cada tarea. La salida es el resultado de las tareas completadas. La salida puede o no consistir de datos analizados para servir como entrada de otro módulo. Incluso puede ocurrir que la misma salida sirva como entrada para más de un módulo o sección.

Algunas tareas no brindan resultados, esto significa que existen módulos para los cuales no hay entradas. Los módulos que no tienen entrada pueden ser ignorados durante el análisis. Los módulos que no tienen salida como resultado pueden significar una de las cuatro implicaciones siguientes:

o Las tareas no fueron ejecutadas apropiadamente o Las tareas no se aplicaban o Las tareas revelaron niveles superiores de seguridad o Los datos resultantes de la tarea se analizaron de manera inapropiada

Es vital la imparcialidad en la ejecución de las tareas de cada módulo ya que puede ser que buscar algo que no se tenga como intención puede llevamos a encontrar exactamente lo que uno quiere. Identificar las tareas que pueden ser vistas como innecesarias y por lo tanto retiradas inmediatamente del análisis es vital, esto debe documentarse claramente .

•

De manera visual se presenta el siguiente ejemplo de un módulo:

Módulo: Escaneo 'Q, sondeo) -de,Red •· . . .· · :;- Jd' i; , ; ) ,· -,t.,. , 1%\, . , :, ·-··········-···---------······-·--------···-------··.\: __________ .. ____ .. -----------------------------·- ·----·-·-·-----------------Descripción del Módulo: El sondeo de red sirve como introducción a los sistemas a ser analizados. Combinación de recolección de datos, obtención de información y política de control. La clave es encontrar el número de sistemas alcanzables que deben ser analizados, sin exceder los límites legales de lo que se quiere analizar. No se realiza ningún tipo de intrusión en este módulo

. ·-·--··-·-··· .. ·-········-··········-··-·----··--·-·-········-----.. ·---... -....... __________________________________________________________________________________ , _______________ _

Tarea N. Buscar información sobre la or anización a analizar en los os de noticias

1.3.8 METODOLOGIA

26

La metodología fluye desde el módulo inicial hasta completar el módulo final. La metodología permite la separación entre recolección de datos y pruebas de verificación de y sobre los datos recolectados. Esto puede representarse de manera gráfica a través de la siguiente figura:

1

•

27

Pruebas de Verificación

ENTRAD¡.. SALIDA ...

Recolección de Datos

Fig. 1.1. Separación entre recolección de datos y pruebas de verificación.

El flujo también determina los puntos precisos de cuando extraer e insertar estos datos. Al definir la metodología de análisis, es importante no restringir la creatividad del analista introduciendo estándares excesivamente formales e inflexibles. Adicionalmente es importante dejar tareas abiertas a alguna interpretación donde la definición exacta causará problemas a la metodología cuando una nueva tecnología sea introducida.

Cada módulo tiene una relación con el anterior inmediato y con el posterior inmediato. Cada sección tiene aspectos interrelacionados con módulos de otras secciones. Normalmente, los análisis de seguridad o pruebas de penetración comienzan con una entrada que corresponde a las direcciones de los sistemas a ser analizados. La metodología no establece la manera como deberán analizarse los datos, esto es responsabilidad del analista de seguridad. Los resultados de las tareas pueden ser inmediatamente analizados para actuar como un resultado procesado o se pueden dejar sin analizar. El modelo de seguridad completo puede ser dividido en secciones administrables para las pruebas. Cada sección puede a su vez ser vista como una colección de módulos de pruebas con cada módulo dividido en un conjunto de tareas específicas.

1.3.9 PLANTILLAS O MODELOS PARA DOCUMENTACION

Finalmente, el manual que describe a la metodología OSSTMM propone algunas plantillas o modelos para documentación, como la plantilla para pruebas de sistemas de detección de intrusos, de correo de electrónico falseado, de Ingeniería Social, entre otras.

1.3.10 COMENTARIOS FINALES

Es importante mencionar que la metodología OSSTMM no propone herramientas específicas como lo podrían ser nessus, nmap, john de ripper, netstumbler, etc. para realizar algunas de las tareas y tampoco establece los sistemas que pueden analizarse, por ejemplo: Windows 2000, IOS 11.X, HP-UX 11.0, etc. Esto es relevante porque se convierte solo en un marco general y una guía para las pruebas de penetración o análisis de seguridad y para cuestiones específicas se

•

•

28

remite a la experiencia y conocimiento de quien realiza las pruebas y utiliza esta metodología. Es importante mencionar que se continúa trabajando en esta metodología y aún se tiene partes incompletas particularmente en lo referente a los Valores de la Evaluación de Riesgo (RA V s) y a los mapas de flujos de entrada y salida entre los módulos de cada sección.

1.4 METODOLOGIA DE ROELOF TEMMINGH

A continuación se presenta la metodología expuesta por Roelof Temmingh en [4]. Es importante mencionar que Roelof es coautor del libro "Nessus Network Auditing", así como miembro fundador de la Compañía Sensepost, líder en Sudáfrica en el campo de la seguridad de la información, ha sido ponente en las conferencias Black Hat, DEFCON y RSA Conference.

1.4.1 PRIMER PASO: "FIJANDO EL ESCENARIO"

El primer paso de esta metodología presenta las distintas formas que utiliza un atacante (intruso, hacker, cracker, script kiddie, etc.) para intentar ser anónimo y que su origen real sea dificil de rastrear. Propone técnicas como la utilización de proxies anónimos, remailers anónimos, shells gratis, conexión desde "cyber cafés" y routers con contraseñas débiles. Establece que no hay técnicas infalibles para ocultarse, sin embargo, señala que la combinación de varias de estas técnicas puede permitir dicho fin. Desde nuestro punto de vista, una mejor y cada día más utilizada técnica es 1 a conexión a redes inalámbricas abiertas ("wep" desactivado, o cualquier otro protocolo de autenticación), sin embargo, no se maneja así en este artículo, posiblemente porque la última actualización del mismo es de noviembre de 2001, fecha en la que todavía no eran tan comunes las redes 802.1 lb/ 802.1 la/ 802.1 lg. La gran ventaja de realizar ataques desde redes inalámbricas es que en éstas pocas veces se mantienen bitácoras de acceso y en la mayoría de 1 os casos están configuradas con asignación dinámica de direcciones ( dhcp ), por 1 o que se puede lograr una conexión de manera rápida y muy dificil de rastrear. Esto se vuelve más delicado cuando los sistemas objetivos a los cuales se quiere atacar son precisamente a los que la red inalámbrica abierta nos da acceso.

1.4.2 SEGUNDO PASO: "MAPEANDO EL OBJETIVO"

Como segundo paso propone la recolección de información de manera pasiva del sistema o sistemas objetivo. Sugiere enumerar todos los dominios asociados a la Compañía así como los "mail exchangers" (sistemas encargados del correo electrónico de dicho dominio) de las mismas y los servidores de web. Una vez enumerados los nombres se procede a la identificación de las direcciones IP asociadas a dichos nombres. Adicional a esto, se realizan consultas ("queries") a servidores WHOIS para encontrar bloques de direcciones IP asociadas a los nombres encontrados. Una vez enumeradas estas direcciones nos interesa conocer para cuales existe una ruta, esto 1 o podemos hacer teniendo acceso de manera 1 e gal a un ro u ter primario de Internet ("core router", ej. route-views.oregon-ix.net) que utiliza el protocolo BGP (Border Gateway

'

•

29

Protocol) para controlar las tablas de ruteo globales. Una vez discriminadas estas direcciones IP el siguiente paso es conocer en que lugar fisico (ej. Estados Unidos, México, Sudáfrica, etc.) se encuentran, esto lo podemos obtener de las etiquetas de los routers a través de un "traceroute". Después de conocer las direcciones IP a las cuales se tiene una ruta así como el lugar donde se encuentran, nos interesa conocer si están asociadas a un nombre de dominio (ej. la dirección IP 192.193.195.1 está asociada a globall.citicorp.com)

Es importante señalar que partiendo solo de pocos elementos como el nombre de la Compañía, su servidor de web y servidor de dns podemos enumerar una cantidad muy importante de información, por ejemplo: direcciones IP de subsidiarias las cuales podrían estar asociadas a sistemas con un menor control y por lo tanto ser utilizadas como puente hacia los objetivos

pnmanos.

1.4.3 TERCER PASO: ¿ VIVO Y TOCANDO?

Una vez obtenidas las direcciones IP asociadas a una Compañía es necesario conocer cuales de estas están vivas desde un punto de vista de Internet, es decir, que de alguna forma respondan a una petición desde nuestra máquina de prueba. Por lo general, esto se puede realizar utilizando el comando ping (ICMP echo request), sin embargo, en la actualidad es un práctica común el que los routers de frontera o los firewalls tiren estos paquetes. Un barrido de ping ("ping sep") puede ser realizado con la herramienta Nmap, esta misma herramienta permite enviar paquetes con direcciones IP distintas a la real, esto con el objetivo de dificultar la tarea de detección (decoy packets).

Debido a que los pings de ICMP comúnmente son bloqueados, se utiliza otra técnica conocida como ping de TCP, esto debido a que una computadora conectada a Internet y que está dando algún servicio, por ejemplo: servidor de web, servidor de nombres, servidor de correo electrónico, deberá tener algún puerto abierto (por ejemplo: puerto 80 comúnmente para servidores de web, puerto 25 comúnmente para correo electrónico a través del protocolo SMTP, puerto 53 comúnmente para servidor de nombres). Por esto esta técnica nos puede servir para identificar sistemas vivos conectados a Internet, aunque estén siendo "protegidos" por un control de acceso a nivel de red como lo puede ser un router o un firewall. Esta técnica se debe utilizar con cautela porque dependiendo del número de puertos que se prueben dentro de una cierta ventana de tiempo puede ser que un detector de intrusos (IDS, por sus siglas en inglés "Intrusion Detection System) identifique el escaneo y tome alguna acción como bloquear nuestra dirección IP o enviar un evento a una bitácora con información también de nuestra dirección IP.

1.4.4 CUARTO PASO: "CARGANDO LAS ARMAS"

Este paso, el autor lo titula "Loading the weapons" (en español: "Cargando las armas") y lo establece así por el hecho de que para una lucha con pistola es inútil llevar un cuchillo o para atrapar a una sola persona no se requiere destrozar a una ciudad (hoy en el 2004, pareciera esta frase sarcástica sobre la guerra de Estados Unidos contra Irak y Saddam Hussein) .

'

•

30

De acuerdo con lo anterior, el autor sugiere utilizar herramientas automáticas de detección de vulnerabilidades (ej. nessus) con la desventaja de que son altamente ruidosas, consumen mucho tiempo y generan un número importante de falsos positivos. Una alternativa es hacer uso de herramientas específicas hechas a la medida.

Este cuarto paso lo que sugiere es obtener los "banners" o identificadores de versión de los servicios activos en los equipos vivos identificados en el paso anterior. El autor sugiere que se encuentre el eslabón o eslabones más débiles por lo que se identifican las versiones de los servicios más comunes y vulnerables como lo son los de correo electrónico vía el puerto 25 donde en la mayoría de los casos podemos encontrar una aplicación conocida como sendmail la cual tiene una larga historia de vulnerabilidades reportadas. Asimismo, sugiere la identificación de los servicios y aplicaciones asociadas a los puertos 23 ( comúnmente el servicio telnet), 21 ( comúnmente ftp ), etc. Finalmente, se realiza un escaneo con los puertos más comunes ( aproximadamente 1400) utilizados por la herramienta Nmap.

1.4.5 QUINTO PASO: FUEGO!

Una vez identificados los servicios y aplicaciones asociadas a cada uno de los puertos identificados se seleccionan aquellos que permiten autenticación, el clásico es telnet. Esto debido a que el ataque de diccionario sobre usuarios validos del sistema es siempre bien visto, considerando la mala costumbre de los usuarios y administradores en la elección de contraseñas débiles.

Los siguientes elementos e valuados son los servidores de web, esto debido a su ubicuidad en Internet así como por la larga historia de vulnerabilidades de todos ellos. Una herramienta muy utilizada y específica para ellos es Whisker programada por RFP ("Rain Forest Puppy"). En caso de enfrentamos con un sitio que solo acepta conexiones tipo https (puerto 443) en lugar de http podemos utilizar una herramienta para tunelear http sobre ssl, por ejemplo SSLproxy (o stunnel). Para aquellos servidores de web que requieren una autenticación básica, también la herramienta Whisker nos puede ayudar a realizar un ataque de diccionario.

En caso de que nos enfrentemos a un sitio (servidor de web, por ejemplo: página de un banco que pide usuario y contraseña) que requiere autenticación en la propia página (distinto al caso de autenticación básica en el cual se lanza una ventana solicitando nombre de usuario y contraseña) se deberá analizar el código html de dicha página y buscar el método "http POST", una vez realizada la disección del mismo se podrá generar un script que inyecte paquetes con una combinación de nombre de usuario y contraseñas realizando así un ataque de diccionario. En ocasiones esto se puede complicar un poco más si el servidor de web está utilizando "cookies" ya que éstas deberán ser inyectadas junto con el paquete de autenticación. Un par de herramientas que pueden realizar esto son Elza y Brutus.

Una vez que se ha logrado acceso a algún equipo dentro de una red objetivo (por ejemplo: alguno dentro de una DMZ) el siguiente paso es continuar penetrando otros sistemas de dicha red o que

'

•

•

31

pertenezcan a la Compañía objetivo. lnforniación que es útil para conocer más acerca de nuestra

red objetivo es:

a) Direcciones IP, máscaras de subred, gateway, servidores DNS b) Tablas de ruteo c) Tablas de ARP (cache de ARP) d) Nombres de NetBIOS y recursos compartidos e) Recursos compartidos via NFS f) Relaciones de confianza, por ejemplo: .rhosts y /etc/hosts.allow g) Otros sistemas en la red, por ejemplo: /etc/hosts y LMHOSTS

Adicional a estos puntos, es buscar la existencia de otras interfases de red que podrían estar mostrándonos equipos que son gateway hacia otras redes o sistemas. Este esquema es muy utilizado por ejemplo en servidores que hacen consultas ("queries") a bases de datos.

Una vez logrado esto, el autor sugiere subir herramientas de uso específico al sistema penetrado con el afán de que ayuden a realizar un nuevo reconocimiento de los sistemas con los cuales se tiene una ruta o vía de acceso que antes, desde Internet, no se tenía. La manera más sencilla es a través de FTP y a sea de sistema de penetración a sistema penetrado ( en caso de que se tenga habilitado FTP en dicho servidor) o del sistema penetrado al sistema de penetración (sin embargo, dependiendo de la configuración del firewall puede ser que esto no sea permitido, este tipo de conexiones se conocen como "Phone-Home", más sobre este tema se puede encontrar en la presentación de Aaron Higbee y Chris Davis en Defcon X titulada "DC Phone-Home").

Una de las herramientas más utilizadas una vez que se ha penetrado un sistema es "netcat" desarrollada por Hobbit con lo cual se podrán crear puertas traseras. Una vez logrado el acceso al sistema privilegiado se tendrán que ejecutar de nuevo todos los pasos con el afán de ganar un mayor entendimiento de la nueva red así como de los eslabones más débiles de la misma. Por ejemplo, se podrá tener acceso a puertos que antes no se tenía y que entregan gran cantidad de información como lo son los puertos de NetBIOS (139 TCP/UDP, 138 UDP, 137 UDP).

1.5 METODOLOGIA DE MIXTER

Esta metodología fue expuesta por Mixter (mixter@hacktivismo.com) en su artículo "An approach to systematic network auditing" [5].

Mixter fue el programador de TFN (Tribe Flood Network) una herramienta de "prueba de concepto" ("proof of concept") para un Ataque de Negación de Servicio Distribuido. En algún momento se pensó que dicha herramienta y por lo tanto su creador había sido el causante del grave daño en febrero de 2000 a sitios como yahoo.com, amazon.com, ebay.com, producto de una negación de servicio distribuida. Con el tiempo se descubrió que la verdadera herramienta causante de dicho ataque había sido otra de nombre: stracheldraht, sin embargo, es importante señalar que esta herramienta si tomó como base el diseño de TFN esto de acuerdo con David

•

t

•

32

Dittrich de la Universidad de Washington en su reporte sobre la disección de ambas herramientas

[6J.

Una auditoria de red o prueba de penetración se entiende como el intento sistemático para ganar acceso a la red a través del descubrimiento todos sus puntos de acceso y el análisis de las vulnerabilidades conocidas de estos puntos, las cuales podrían ser aprovechadas por un atacante real para ganar acceso no autorizado. A pesar de que los administradores realicen un esfuerzo importante en la implantación y diseño de una red y aun cuando ellos tengan un nivel de conocimientos de seguridad adecuado puede suceder que sus sistemas sean comprometidos (penetrados) debido a la gran cantidad de ataques y vulnerabilidades presentes en los sistemas.

La metodología expuesta comprende solo dos pasos:

1. Recopilación de información 2. Evaluación de la información recopilada

El autor establece cinco grupos como las causas de problemas de seguridad los cuales serán aprovechados en el segundo paso:

a) Problemas debido a desbordamientos de memoria ("buffer overflow") b) Problemas debido a programas inseguros (generalmente, cgi's) c) Problemas debido a configuraciones inseguras (ej.: recursos compartidos por omisión) d) Problemas debido a la ausencia o debilidad de contraseñas e) Puertas traseras y caballos de troya

Una preocupación específica del autor es sobre las aplicaciones desarrolladas internamente o a la medida, por ejemplo, ciertos cgi's y dicha preocupación está fundamentada en que la aplicación, por ejemplo, un servidor de web (ej.: Apache ultima versión) puede ser no vulnerable hasta este momento, pero dicho cgi puede ser que si lo sea. Esta será una vía más de acceso para un atacante, es por esto que en una auditoria de seguridad o en pruebas exhaustivas de penetración se identifican estas vulnerabilidades y no solamente las obvias.

1.6 METODOLOGIA DE DAN FARMER Y WIETSE VENEMA

Esta metodología fue expuesta por Dan Farmer y Wietse Venema en su artículo titulado "Improving the security of your site by breaking into it" [7].

Wietse Venema y Dan Farmer son los creadores de herramientas clásicas de seguridad como "The Coroner's Toolkit", Postfix (alternativa a sendmail), SATAN, TCPWrappers.

Es importante resaltar que este artículo inicia señalando que la mayoría de las intrusiones ("break-ins") se dan a través de contraseñas débiles. Sin embargo, los autores también reconocen que un número importante de intrusiones es llevado a cabo utilizando técnicas avanzadas. El

•

33

CERT, la NASA, el MIT, solo por nombrar algunas organizaciones respetables, han sido atacadas con éxito.

Los autores introducen el término de "uebercracker" (tomado de la idea del superhombre o "uebermensch" de Nietzche) con el cual describen a un "cracker" (o delincuente cibernético) que va más allá de solo utilizar una receta de cocina para introducirse a los sistemas informáticos, además tiene un objetivo claro y preciso no como el "cracker" común que puede estar saltando de objetivo en objetivo buscando solo puertas de entrada fácil (ej.: contraseñas débiles).

La base del artículo es concientizar a los administradores de sistemas sobre los ataques más comunes esto con el objetivo de que tomen decisiones adecuadas para la protección de sus sistemas. Hacen un señalamiento claro sobre probar sistemas propios y no de otros. A su vez establecen que la mayoría de las técnicas presentadas dejarán algún tipo de rastro en las bitácoras de los sistemas atacados, por lo que será un buen ejercicio analizarlas con el afán de conocer como aparece un ataque en ellas.

La metodología presentada se divide en tres secciones:

a) Recopilación de información b) Confianza c) Protección de los sistemas

Durante la elaboración de este artículo los autores desarrollaron la herramienta SA TAN ("Security Analysis Tool for Auditing Networks"), la cual examina uno o varios sistemas remotos recopilando la mayor cantidad de información posible a través de pruebas a servicios en red como finger, NIS, NFS, ftp, tftp, rexd, entre otros. Esta información es útil para investigar debilidades o vulnerabilidades en los sistemas.

Como nota adicional, de acuerdo con Dorothy E. Denning en su libro "lnformation W arfare and Security" (8), Dan F armer y Wietse V enema anunciaron en 1995 la liberación de SATAN de manera gratuita a todo Internet, con tal noticia los dos expertos fueron ampliamente criticados y algunos hasta se atrevieron a decir que podría causar el colapso de Internet. Al final, poco sucedió. Una semana después de su liberación se le encontró una falla a la herramienta que al ser ejecutada utilizando algunos navegadores (entre ellos, Netscape Navigator) podía hacer vulnerable al propio sistema que ejecutaba SATAN. Farmer colocó una nueva versión con notas de cómo resolver dicha falla, sin embargo, esto demostraba que aún una herramienta de seguridad podía provocar un hueco de seguridad (nos atrevemos a decir que cualquier pieza de software puede provocar esto, por simple que sea, aún y cuando se tenga todo el cuidado en su programación y se sigan mejores prácticas, una prueba de esto es que al propio OpenBSD se le han encontrado fallas, cuando se sabe que utilizan controles muy robustos para validación de espacios de memoria y que su bandera es la seguridad).

Denning señala en el mismo libro que, en 1996, Farmer realizó un estudio a aproximadamente 1, 700 servidores web utilizando SATAN (algunos de los servidores pertenecían a agencia

•

34

federales de Estados Unidos, periódicos y negocios). El estudio arrojó que el 60% de los servidores podían ser atacados de manera exitosa.

1.6.1 RECOPILACION DE INFORMACION

El primer paso es recopilar la mayor cantidad de información del sistema o sistemas objetivos. Existen varios servicios en red por los cuales se puede iniciar: finger, rusers, showmount y rpcinfo. Esto son un buen inicio, sin embargo, existen otros que también son interesantes por la información que entregan: DNS, whois, sendmail (smtp), ftp, uucp, entre otros.

Lo relevante de los servicios en red como finger o rusers es que nos entregan usuarios válidos en el sistema. Esto se vuelve importante si consideramos que si ya tenemos un usuario válido en el sistema, posiblemente tengamos acceso al servicio telnet; entonces se abre la posibilidad de realizar un ataque de diccionario. Adicionalmente, el comando "showmount" nos revela los directorios exportados (compartidos) vía NFS, así como los equipos y usuarios que pueden tener acceso a dichos directorios y con que privilegios (lectura, escritura y/o ejecución). Si no existe un control de acceso adecuado puede darse el caso que se estén exportando directorios sensitivos como aquellos que contienen archivos de configuración (ej.: agregar "+" al archivo /etc/hosts.equiv) y binarios del sistema (ej.: sustitución del comando "Is" por un caballo de troya).

Adicionalmente, el comando "rpcinfo" es importante porque nos da información sobre los programas activos asociados a RPC que están activos en el sistema (ej.: comandos r como rsh, rexd, rlogin, etc.). También se sugiere la interrogación de puertos TCP para conocer cuales están activos y conocer que servicios en red están disponibles. Uno muy común y muy vulnerable es el servicio X Window, el cual permite lanzar terminales remotas (utilizando el comando xhost) iniciadas de manera local en el sistema objetivo o víctima. Los autores también señalan que la aplicación sendmail utilizada para correo electrónico a través del protocolo SMTP cuenta con una larga historia de brechas de seguridad debido a la complejidad del propio programa.

Es importante mencionar que aunque esta sección es titulada "Recopilación de Información" los autores señalan, explican y demuestran técnicas de explotación corno en e 1 caso del c ornando showmount, xhost, etc.

1.6.2 CONFIANZA

Se refiere confianza al hecho de que un servidor permita acceso a un cliente sin la necesidad de que éste se autentique, por ejemplo, vía usuario y contraseña. Existen diferentes formas en que un sistema puede confiar, por ejemplo: .rhosts y hosts.equiv, servidores X Window, directorios exportados vía NFS, entre otros. La mayoría de estos servicios se basan en la conversión de dirección IP a nombre de host (comúnmente, a través del archivo /etc/hosts o utilizando el servicio de DNS), sin embargo, esto puede ser enmascarado ("spoofing") o engañado, especialmente cuando la autoridad que entrega dichas credenciales (refiriéndose a la conversión de dirección IP a nombre de host) está fuera de la responsabilidad del administrador de dicho

•

sistema. Obviamente, si el servidor que contiene la base de datos de relaciones entre direcciones IP y nombres de host (DNS, NIS, etc.) ha sido comprometido, este método de autenticación no servirá más.

Es importante señalar que de acuerdo al estudio realizado por el SANS y el FBI (http://www.sans.org/top20/oct02.php) durante el 2002 la sexta forma más común de atacar sistemas UNIX fue a través de la explotación de relaciones de confianza utilizadas por comandos R (rsh, rcp, rlogin, rexec).

1.6.3 PROTECCION DE LOS SISTEMAS

Los autores ofrecen las siguientes sugerencias:

a) Deshabilitar el servicio finger b) No utilice NIS solo que sea absolutamente necesario. Procure utilizar lo menos posible

NFS. c) Nunca exporte directorios vía NFS a todo el mundo. Procure exportar directorios con

permiso de solo lectura. d) Fortifique y proteja sus servidores. Solo permita cuentas administrativas en ellos. e) Examine cuidadosamente los servicios brindados por inetd y portmapper. Elimine

cualquiera que no sea explícitamente requerido. Utilice TCPWrappers, por lo menos para enviar eventos a bitácora cada vez que se realice una conexión.

f) Elimine relaciones de confianza, solo utilícelas cuando sea absolutamente necesario g) Utilice archivos /etc/passwd en conjunto con /etc/shadow. Deshabilite cuentas que no son

utilizadas. Procure utilizar una herramienta que elimina la posibilidad de elegir contraseñas débiles o triviales.

h) Manténgase informado sobre nueva literatura y herramientas relacionadas al tema de seguridad. Por lo menos suscríbase a la lista de correo del CERT y a la revista phrack.

i) Instale parches de seguridad tan pronto como sea posible.

Como conclusión los autores señalan:

"Es interesante notar que soluciones comunes a problemas de seguridad como utilizar Kerberos o contraseñas de una sola vez o "tokens" no son efectivos contra la protección de la mayoría de los ataques presentados en este artículo. Recomendamos dichas soluciones, pero se debe tomar en cuenta que nq existe una solución total en el tema de seguridad".

Es importante señalar que este artículo tiene más de 1 O años de haber sido escrito y señala situaciones que hasta el día de hoy son una realidad, el ejemplo más claro es la utilización de contraseñas débiles para acceder de manera no autorizada a los sistemas así como la explotación de relaciones de confianza. Nuestro comentario a este respecto, que se retomará en las conclusiones de este documento es: Nos estamos olvidando de lo básico. Queremos herramientas de prevención de intrusos utilizando cómputo quántico y reconocimiento inteligente de paquetes cuando probablemente el administrador del sistema "protegido" guarda sus contraseñas

•

36

(probablemente compuesta por la fecha de nacimiento de su hijo concatenada con sus iniciales) en un papelito dentro de su cartera para evitar que se le pierda. O cuando esa fabulosa herramienta de varios miles de dólares tiene un usuario y contraseña por omisión (usuario: cisco, contraseña: cisco; [91), solo por mencionar un ejemplo, porque ejemplos de este tipo hay cientos y talvez miles.

1.7 METODOLOGIA DE T. PELTIER, J. PELTIER Y BLACKLEY

A continuación se presenta la metodología expuesta por T homas P eltier, Ju stin P eltier y Jo hn Blackley en su libro titulado "Managing a Network Vulnerability Assessment" [10].

El primer elemento importante que establecen los autores es la delimitación del alcance del proyecto o pruebas que se llevaran a cabo. Esto se vuelve relevante desde el punto de vista de aclarar expectativas sobre las tareas a realizar, los procedimientos a ejecutar, los canales de comunicación para reportar avances, los tiempos a invertir y los resultados esperados. Este punto es un gran acierto de la metodología ya que muchos proyectos fracasan debido a que desde un principio no se determinan sus alcances. De hecho, sugiere que estos alcances se establezcan en un documento y las tareas que se realizarán relacionadas con una línea de tiempo.

Es importante señalar que aunque esta no es propiamente una metodología de penetración de sistemas, si es una metodología para realizar el análisis de vulnerabilidades de una red, por lo que varios elementos pueden ser tomados para efectos de la primera.

Una vez que el alcance ha sido aceptado se sugiere determinar los elementos de mayor preocupación de la Compañía, por ejemplo: virus, hackers, ataques de negación de servicio, correo electrónico, empleados disgustados, espionaje industrial, competidores, escaneos a equipos expuestos a Internet y firewalls, ataques de ingeniería social, caballos de troya y en general código malicioso, amenazas a la privacidad, entre otros. Una vez identificados estos elementos es importante priorizarlos, todo esto con el afán de enfocar estratégicamente las pruebas hacia estos.

Los autores definen un NV A (por sus siglas en inglés: "Network Vulnerability Assessment", o Análisis de Vulnerabilidades en Red) como el proceso por el cual las organizaciones evalúan sus políticas, prácticas, redes y elementos de red, hardware, software, empleados y entrenamiento para determinar las vulnerabilidades que amenazan la integridad de sus redes y la infraestructura que las soporta. Una vez que las vulnerabilidades han sido identificadas en el NV A, será necesario determinar los mejores controles o medidas necesarios para mitigarlas basándose en la relación costo/beneficio.

Debido a que cada organización tiene requerimientos de seguridad de la información distintos, el NV A deberá ser implementado para cumplir con las necesidades específicas de cada una. El NV A es utilizado para evaluar los sistemas y los datos en el contexto de operación, prácticas de

•

•

37

negocio y metas estratégicas de cada organización. La meta es alcanzar un balance adecuado entre seguridad y utilización efectiva de los sistemas.

El NV A examina los sistemas de red desde dos puntos de vista, el primero tomando en cuenta políticas (y en general normatividad) y el segundo tomando en cuenta la práctica. Los denomina, al primero un enfoque "de arriba hacia abajo" ("top-down) y al segundo "de abajo hacia arriba" ("bottom-up"). Así, la evaluación tiene un equilibrio entre aspectos normativo/administrativo y técnico/práctico.

1.7.1 ENFOQUE "DE ARRIBA HACIA ABAJO" (NORMATIVO/ADMINISTRATIVO)

Este enfoque se concentra en la evaluación de las políticas y procedimientos que promueven un ambiente computacional seguro. Se examina el marco de procedimientos en el que descansa la seguridad corporativa así como la profundidad del entendimiento e implantación de dichas políticas y procedimientos. De este análisis se podrán identificar vulnerabilidades provocadas por la falta o deficiencia de alguna de ellas (políticas y/o procedimientos). Los resultados obtenidos en el enfoque "De arriba hacia abajo" son utilizados en el enfoque "De abajo hacia arriba".

Es importante señalar que si esta metodología es utilizada para realizar pruebas de penetración de sistemas dificilmente se podrá realizar como primera etapa el enfoque "De arriba hacia abajo" que involucra la evaluación de políticas y procedimientos ya que no se tiene acceso a esta información en dichas pruebas. Sin embargo, si se podrá utilizar el enfoque "De abajo hacia arriba", es decir, el Técnico/Práctico. Nada impide que una vez que se realicen las pruebas de penetración (utilizando el enfoque "de abajo hacia arriba" o Técnico/Práctico) se realice una evaluación "De arriba hacia abajo", esto podría ayudar a encontrar las causas raíz de las vulnerabilidades o debilidades encontradas .

1.7.2 ENFOQUE "DE ABAJO HACIA ARRIBA" (TECNICO/PRACTICO)

Este enfoque se concentra en las implementaciones de hardware y software de la seguridad de la red evaluando de manera discreta cada uno de los componentes de red.

Utiliza los siguientes seis pasos:

a) Recopilación de información sobre la red objetivo. Se identifican los protocolos, servicios en red y aplicaciones en red disponibles. Asimismo, se identifican los sistemas operativos contenidos en un rango de direcciones IP pertenecientes a la Compañía bajo análisis. Durante este paso también se toma en cuenta, cuando así se haya acordado con el cliente, la identificación de controles fisicos.

b) Desarrollo de un plan de evaluación. Una vez identificadas las aplicaciones en red disponibles en el paso anterior, se identifican las vulnerabilidades asociadas a las mismas, por ejemplo, a través de bases de información ( ej.: CERT, CVE, ICAT, bugtraq, entre

•

•

38

otros). Asimismo, se investigan guías que pueden ser de utilidad, como manuales de usuano.

c) Construcción de una caja de herramientas, de las cuales destacan aquellas de enumeración de red y sistema operativo e interrogación de puertos (ej.: nmap), interrogación de vulnerabilidades (ej.: nessus), análisis de servidores de web (ej.: whisker), análisis de firewalls (ej.: firewalk), detección de caballos de troya (ej.: nessus), interrogación de portadoras telefónicas (ej.: toneloc ), interrogación de redes inalámbricas (ej.: kismet), analizadores de protocolos (ej.: ethereal), "crack" de contraseñas (ej.: john the ripper). En ocasiones pueden utilizarse herramientas de exploración de vulnerabilidades a nivel local, es decir, requieren y a sea de que se ejecuten de manera local o de que se instale un agente local en el sistema bajo evaluación (ej.: Bindview bv­control).

d) Realizar la evaluación, a través de la cual se realizan las pruebas a los objetivos críticos identificados utilizando la información y herramientas de los pasos anteriores. Es indispensable guardar en una bitácora todas las acciones realizadas.

e) Análisis, utilizando la experiencia del evaluador. f) Documentación, posiblemente el paso más importante debido que aquí se plasman los

resultados, hallazgos y recomendaciones.

1.7.3 METODOLOGIA

La evaluación de una red corporativa incluye los siguientes pasos básicos, durante los cuales se utilizan ambos enfoques descritos con anterioridad:

a) Fase 1: Recolección de Datos. Incluye la identificación de objetivos, estrategias y misión del negocio, recolección y revisión de políticas, procedimientos, estándares, regulaciones aplicables, guías, comentarios de auditoria, análisis de brecha ("gap analysis") contra ISO 17799.

b) Fase 2: Entrevistas, Revisión de Información e Investigaciones Manuales a través de entrevistas con representantes de áreas y unidades de negocio claves y estratégicas, entrevistas con usuarios internos de la red y evaluación del desempeño de la seguridad de hardware, software y redes clave.

c) Fase 3: Análisis, a través de la identificación de preocupaciones y factores clave de éxito en el ámbito de la seguridad y la identificación de información y prácticas críticas y sensitivas. Asimismo, con la identificación de riesgos de seguridad y formulación de recomendaciones para la mitigación de dichos riesgos.

d) Fase 4: Reporte Borrador. Incluye la evaluación de las políticas y procedimientos existentes, así como la emisión de recomendaciones sobre ellas. También se realiza una evaluación de riesgos y controles en la arquitectura de la red y se emiten recomendaciones para mejorar prácticas de seguridad. Finalmente, se emite un reporte borrador al patrocinador del proyecto para sus comentarios.

e) Fase 5: Reporte Final. Incluye la presentación del reporte y presentación final de los resultados de la evaluación. Se recomienda que todo el equipo que participó en el proyecto esté en dicha presentación en caso de que se requiera aclarar dudas .

•

39

Como se mencionó, existen varios puntos que pueden ser reordenados de tal manera que se pueda utilizar como una metodología de penetración de sistemas, esto debido a que su alcance y consideraciones son mayores. Particularmente para una metodología de penetración sistemas, son importantes la Fase 1, Fase 3 y Fase 5 tomando como base el enfoque "de abajo hacia arriba" (Técnico/Práctico).

1.8 METODOLOGIA DE KLEVINSK, LALIBERTE Y GUPTA

La siguiente metodología fue expuesta por Klevinsky, Laliberte y Gupta en su libro titulado "Hack I.T., Security through penetration testing" [11].

Los tres son miembros del grupo de "Soluciones de Tecnología y Seguridad" de Emst & Y oung dedicados al servicio de Ataque y Penetración ("Penetration Testing"), en el cual han servido a numerosas empresas muchas de ellas "Fortune 500".

Los autores presentan de acuerdo a su experiencia las 26 vulnerabilidades más comunes a las que se han enfrentado y que les permitieron lograr su objetivo de comprometer los sistemas u obtener información relevante para dicho fin. Es importante señalar que un número importante de ellas fueron presentadas en octubre de 2001 por el SANS y el FBI sobre un consenso de las 20 vulnerabilidades más comunes en los sistemas de información.

Estas 26 vulnerabilidades están asociadas a:

1. Huecos a nivel aplicación 2. BIND (Berkeley Internet Name Domain) 3. Vulnerabilidades en CGI 4. Servicios en texto claro ("sniffing) 5. Cuentas por omisión 6. DNS (Domain Name Service) 7. Permisos de archivos 8. FTP y telnet 9. ICMP 1 O. Vulnerabilidades en IMAP y POP3 11. Módems 12. Falta de monitoreo y detección de intrusiones 13. Arquitectura de red 14. Vulnerabilidades en NFS (Network File System) 15. Puertos 135-139 en NT (NetBIOS, autenticación de NT y archivos compartidos) 16. Sesiones nulas en NT 1 7. Contraseñas débiles 18. Servicios de administración remota 19. Vulnerabilidades en RPC

•

•

40

20. Vulnerabilidades en sendmail 21. Servicios iniciados por omisión durante instalaciones (también por omisión) de

aplicaciones y sistemas operativos 22. SMTP (Simple Mail Transport Protocol) 23. Comunidades por omisión de SNMP (Simple Network Management Protocol) 24. Virus y código oculto 25. Archivos de ejemplo en servidores web 26. Vulnerabilidades en servidores de web

Los autores establecen la importancia y hacen énfasis en el uso de una metodología ya que ésta permite actuar de manera estratégica, sistemática y oportuna, tres factores vitales en las pruebas de penetración ya que siempre se trabaja contra reloj. A continuación se presenta la metodología de pruebas de penetración desde Internet hacia una red privilegiada (ej.: DMZ) sugerida por estos autores:

a) Descubrimiento/Enumeración de Red a. Consultas a whois (basadas en web, por ejemplo a tavés de www.arin.net ó

basadas en comandos propios del sistema operativo ó utilizando herramientas como Sam Spade ó W s PingProPack).

b. Transferencias de zona (técnica muy utilizada por obtener la lista de mapeos de direcciones IP y nombres de dominio - DNS)

c. Barridos de Ping d. "Traceroute"

b) Análisis de vulnerabilidades a. Identificación del sistema operativo b. Interrogación de puertos c. Enumeración de aplicaciones (identificadores o "banners") d. Investigación de vulnerabilidades

c) Explotación a. Métodos para el sistema operativo UNIX (servicios INETD, servicios R, RPC,

ataques de desbordamiento de memoria, permisos de archivos, servidores de correo electrónico, servidores de web, servidores X Window, DNS, entre otros)

b. Métodos para penetración de servidores web c. Métodos para el sistema operativo NT (principalmente asociados a NetBIOS,

puertos 135-139 y 445) d. Métodos para evadir detección de intrusos e. Métodos para evaluar firewalls f. Acceso local g. Escalamiento de privilegios h. Acceso privilegiado (ej. privilegios de administrador en Windows NT/2000, de

"root" en UNIX, etc.) 1. Obtención y "crack" del archivo de contraseñas cifradas (ej. SAM en Windows

NT/2000 y, /etc/passwd y /etc/shadow en la mayoría de los UNIX)

•

•

•

41

J. Alta de cuenta con privilegios para garantizar de nuevo la entrada, aún y cuando se haya resuelto la vulnerabilidad. (Al final del proyecto toda esta información es entregada a la Compañía como evidencia del acceso logrado y los sistemas son entregados con su configuración original, es decir, en este caso cuando se termina el proyecto se elimina dicha cuenta creada)

k. Transferencia de herramientas a equipo comprometido l. Volver a empezar desde la fase de descubrimiento/enumeración de red para

identificar nuevas puertas de entrada

Adicional a esta metodología de penetración, los autores presentan una metodología de penetración vía acceso telefónico a través de la técnica conocida como "Wardialing", la cual es utilizada para identificar portadoras de módems a través de las cuales se podría tener acceso adivinando usuarios y contraseñas, o utilizando algunos conocidos por omisión (ej. usuario: cisco, contraseña: cisco). En algunas ocasiones no se requiere el nombre de usuario ya que solo se solicita la contraseña. Algunas herramientas para esto son: ToneLoc, THC-Scan, TeleSweep y PhoneSweep. Las reglas sugeridas para este tipo de pruebas son:

1. Realizar las llamadas en horas no laborables 2. No marcar números de manera secuencial 3. Entre una llamada y otra dejar un espacio de tiempo

También sugieren a la Ingeniería Social como un elemento más dentro de las pruebas de penetración, durante las cuales se trata de aprovechar debilidades de los administradores y empleados de una Compañía producto de la falta de conciencia y entrenamiento de seguridad. Durante éstas los administradores o los encargados de soporte pueden entregar contraseñas de cuentas sensitivas poniendo así en riesgo a la Compañía. Algunos de los escenarios utilizados para estas pruebas son: hacerse pasar por soporte técnico y solicitar la contraseña de un empleado, hacerse pasar por un cliente descontento y solicitar un cambio de contraseña. No se descarta la posibilidad de utilizar técnicas y herramientas de negación de servicio, sin embargo, se establece la necesidad de autorización por parte del cliente.

1.9 METODOLOGIA DE MCCLURE, SCAMBRA Y, KURTZ

Esta metodología fue expuesta por M cClure, S cambray y Kurtz en su libro titulado "Hacking Exposed, Network Security Secrets and Solutions" [12].

Son más de cinco años desde que este libro salió al mercado en su primera edición. Todavía en aquellos años (1999) los autores eran parte del equipo eSecurity Solutions dentro de Ernst & Y oung, hoy en día Stuart McClure y George Kurtz son miembros fundadores de la Compañía Foundstone dedicada con gran éxito (por lo menos hasta el momento) a la consultoría en seguridad de la información. Joel Scambray es Director Senior de la Seguridad de MSN en Microsoft, también fue miembro fundador de F oundstone. Es importante reconocer que fue la primera publicación formal, comercial y a gran escala (editorial Osborne/McGraw-Hill) de

•

•

•

42

técnicas y metodologías de penetración de sistemas, en poco tiempo se convirtió en un "Best­Seller" Internacional (las primeras tres ediciones vendieron más de 300,000 copias). Alguien podda argumentar que fue primero "Maximum Security" (autor anónimo, y editorial SAMS) porque fue publicado en 1997, sin embargo, no tuvo la fuerza que "Hacking Exposed" posiblemente porque solo presentaba ataques y herramientas, sin embargo, no una metodología.

Es interesante mencionar que esta metodología, de acuerdo a los autores, fue madurando durante varios años realizando pruebas de penetración a sistemas de información de compañías la

mayoría "Fortune 500".

La metodología se compone de los siguientes pasos:

a) "Footprinting" o Huella (de los ambientes de Internet, intranet, acceso remoto, extranet de la Compañía objetivo). En este paso se obtienen nombres de dominio, bloques de red, direcciones IP específicas de los sistemas que pueden ser alcanzados desde Internet, mecanismos de control de acceso. Adicionalmente, se identifican IDS, protocolos de red, nombres de dominio internos, VPNs.

b) Interrogación, se identifican puertos TCP/UDP así como sistemas operativos. c) Enumeración, se identifican servicios ("banner grabbing") y prueban vulnerabilidades o

debilidades típicas de servicios identificados (ej. transferencias de zona - DNS, comandos expn y vrfy en SMTP, finger, interrogación vía NetBIOS, enumeración vía SNMP, enumeración de BGP, enumeración de RPCs, comandos r, enumeración de NFS).

d) Penetración. Esta metodología propone técnicas y debilidades específicas por plataformas, entre las cuales maneja: Windows 95/98/Me, Windows NT/2000, Novell NetWare, UNIX/Linux, así como debilidades en dispositivos de red como módems, PBX, correo de voz, VPN, routers, switches, redes inalámbricas, firewalls. Adicionalmente, propone un conjunto de técnicas avanzadas como secuestros de sesión, puertas traseras, caballos de Troya, rootkits. Finalmente, propone el uso de técnicas como ingeniería social, penetración a servidores y aplicaciones web y penetración a sistemas cliente.

Los tres primeros pasos ("footprinting", interrogación y enumeración) son los básicos y dependiendo de la información encontrada en éstos, se utilizan las técnicas específicas del cuarto paso. Los autores también presentan las 14 vulnerabilidades o debilidades más comunes a las que se han enfrentado y que han explotado para lograr penetrar los sistemas objetivo:

1. 2. 3.

4. 5. 6.

7.

8.

Control de acceso inadecuado en el router de frontera Accesos remotos no asegurados y no monitoreados Fuga de información que brinda al atacante datos como aplicaciones utilizadas, usuarios, recursos compartidos Sistemas con servicios innecesarios activos Contraseñas débiles o triviales Usuarios o cuentas de prueba con privilegios elevados Servidores expuestos a Internet mal configurados (CGls, ASP, FTP anónimos) Firewall mal configurado que permite acceso a la red interna una vez que se ha comprometido un servidor en la DMZ

•

43

9. Software no parchado (instalaciones por omisión) 1 O. Controles de acceso débiles en directorios compartidos 11. Relaciones de confianza mal configuradas y excesivas 12. Servicios que no requieren autenticación 13. Monitoreo y uso de bitácoras inadecuado y en ocasiones nulo 14. Falta de políticas y procedimientos adecuadas, publicadas e implantadas

Es importante señalar que para cada técnica de penetración expuesta en el cuarto paso (Penetración) se presentan recomendaciones para contrarrestarlas así como las herramientas disponibles tanto para ataque como para defensa.

1.10 CONSIDERACIONES FINALES SOBRE METODOLOGIAS DE PENETRACION DE SISTEMAS

Existen muchas más metodologías, de hecho, cualquier profesional dedicado a la Penetración de Sistemas puede tener la propia. Sin embargo, las aquí presentadas son algunas las más comunes, otras las más publicitadas, otras que pretenden convertirse en estándares y otras simplemente se presentaron por la importancia del autor o autores en el mundo de la Seguridad de la Información. No podemos dejar de lado que muchos de estos conceptos han surgido del "underground" por lo que es un hecho que ellos también tendrán sus propias metodologías, posiblemente más sofisticadas que las presentadas aquí.

•

•

•

CAPITUL02

PLANEACION ESTRATEGICA DE LA ADMINISTRACION DE LA SEGURIDAD DE LA INFORMACION - DEFINICION DE CONTROLES

44

"Los que anticipan, se preparan y llegan primero al campo de batalla y esperan al adversario están en posición descansada; los que llegan al último al campo de batalla, los que improvisan y

entablan la lucha quedan agotados " Sun-Tzu, El Arte de la Guerra

Una Planeación Estratégica es una herramienta administrativa que tiene como objetivo focalizar energías para realizar mejor las tareas o acciones asegurando que todos los miembros de la organización están trabajando para lograr las mismas metas. En pocas palabras, es un esfuerzo disciplinado para producir decisiones fundamentales y acciones que moldeen y guíen a una organización, lo que hace y por que lo hace. Involucra la preparación, de la mejor manera, de responder a las circunstancias del medio ambiente de una organización.

La palabra "estratégica" implica tener claros los objetivos de la organización y estar conciente de sus recursos e incorporar estos dos elementos para ser proactivo ante un medio ambiente dinámico. Involucra planeación, porque fija intencionalmente metas y un plan de acción para lograrlas. Requiere de disciplina debido a que establece cierto orden y secuencia para mantenerse enfocado y productivo. El plan es finalmente, ni más ni menos, un conjunto de decisiones sobre lo que se debe hacer, porque hacerlo y como hacerlo. Como es prácticamente imposible hacer todo lo que se necesita hacer, la planeación estratégica reconoce que hay decisiones y acciones que son más importantes que otras, de hecho, gran parte de lo estratégico descansa en tomar las decisiones adecuadas sobre que es lo más importante para lograr las metas organizacionales.

La planeación estratégica solo es útil si soporta un pensamiento estratégico, esto implica preguntarse "¿Estamos haciendo las cosas de manera adecuada?", lo cual involucra tres requerimientos clave:

•

•

45

1. Un propósito claro y definido 2. Entendimiento del entorno organizacional particularmente en las fuerzas que impiden el

cumplimiento de dicho propósito 3. Creatividad en el desarrollo efectivo de respuestas a dichas fuerzas

De a cuerdo con Ja gdish S heth, P h D, [ 13] u na autoridad respetable en el tema de p laneación estratégica, para atacar dicha pregunta ("¿estamos haciendo las cosas de manera adecuada?") sugiere tomar en cuenta los siguientes tres elementos:

1. Formulación de la misión futura de la organización a la luz de los factores externos cambiantes como regulación, competencia, tecnología y consumidores

2. Desarrollo de una estrategia competitiva para alcanzar la misión 3. Creación de una estructura organizacional que permita utilizar los recursos hacia una

estrategia competitiva

La planeación estratégica involucra anticiparse al medio ambiente futuro, sin embargo, las decisiones son tomadas en el presente. Esto significa que la organización deberá estar prevenida y preparada ante los cambios de manera que pueda realizar las mejores decisiones. Finalmente, es importante enfatizar que la planeación estratégica nos hace pensar en dos preguntas: ¿Cuáles son las situaciones o problemas más importantes a los que se tiene que enfrentar o responder? y ¿ Cómo los enfrentamos o respondemos?

Tomando como base lo anterior, se puede definir a la Planeación Estratégica como un concepto que puede adoptarse para la definición de un Programa de Administración de Seguridad de la Información en el que se tome como punto de partida los objetivos del negocio. A través de un Análisis de Riesgos se define la prioridad de las acciones a tomar, siguiendo con la definición de una Normatividad (que involucra la definición de una Política Directriz de Seguridad de la información, políticas, procedimientos, estándares, guías y lineamientos) que habilite la manera como deberán de realizarse las labores de protección de los activos de información de la cual se desprenderán los requerimientos técnicos adecuados y apropiados para cada organización como seguridad de la red, seguridad de host (en general, sistemas operativos), seguridad de accesos remotos, seguridad fisica. Para prever situaciones futuras (muchas veces adversas), parte integral de un Plan Estratégico, se deberá definir un plan de continuidad del negocio ( como su nombre lo dice que involucre a todas las áreas del negocio) que integre un plan de recuperación en caso de desastre (la mayoría de las ocasiones asociado a TI) y un plan de respuesta a incidentes. Finalmente se establece u na tarea de m onitoreo que permita garantizar que lo anterior se está cumpliendo.

Con lo anterior hemos cubierto los distintos elementos de un plan estratégico y también los elementos primarios de la administración de la seguridad de la información, habiendo fusionado estos dos conceptos con el afán de tomar lo más significativo de ambos. La siguiente tabla muestra un mapa relacionando ambos conceptos, planeación estratégica y administración de la seguridad de la información:

1

•

o Clarificar objetivos y metas del

negocio ( elemento básico de la

planeación estratégica)

o Establecer prioridades, algunas

acc10nes son más importantes que

otras.

D ¿Cuáles son las situaciones o

problemas más importantes a los

que se tiene que enfrentar o

responder?

o Establecer el cómo para cumplir

con los objetivos y metas del

negocio

o ¿Cómo hacerlo?

D Prever eventos o circunstancias

futuras

D ¿Estamos haciendo las cosas de

manera adecuada?

o Alineado con objetivos y metas del

negocio

o Patrocinado por la alta gerencia, ya que

son ellos quienes definen los objetivos y

metas del negocio

o Base de un programa exitoso de

seguridad de la información

O Definición de una Estructura Orgánica

de seguridad de la información

O Análisis de riesgos

o Normatividad (política directriz,

políticas, procedimientos, estándares,

guías y lineamientos) de seguridad de la

información

o Requerimientos técnicos para implantar

seguridad de red, host, accesos remotos,

programa de conciencia y entrenamiento

de seguridad

O Cumplimento con regulaciones y

legislaciones

D Seguridad fisica

o Plan de continuidad del negocio

O Plan de recuperación en caso de desastre

o Plan de respuesta a incidentes

o Monitoreo y auditoria

46

•

•

47

Las siguientes secciones de este capítulo describen elementos más significativos de cada uno de los puntos presentados en la columna: "Administración de la seguridad de la información" que formarán parte de un Plan Estratégico de la Administración de la seguridad de la información. Es importante señalar que para cada organización existirán consideraciones particulares, sin embargo, estos elementos forman la columna vertebral.

En caso de que ya existan algunos de estos elementos se recomienda hacer un análisis de brecha ("gap analysis") entre el estado actual y el estado requerido (nivel aceptable definido por la alta gerencia). Como ejemplo de lo anterior podemos decir que la sola existencia de una cierta política no basta, se requiere que dicha política esté acorde a las necesidades de lo que está normando y además que dicha política esté implantada, es decir, que sea conocida, utilizada y monitoreada.

Los elementos que se presentan a continuación pueden ser tomados aún y cuando ya exista una administración de la seguridad de la información dentro de una organización.

Como resultado de la ejecución e implantación de un plan estratégico de la administración de la seguridad de la información se tendrá certeza de que los activos de información ( digitales o no) críticos y relevantes de una organización están siendo protegidos de acuerdo a un nivel aceptable definido por la alta gerencia, las regulaciones y legislaciones aplicables. Lo anterior con un enfoque de identificación y mitigación de riesgos a través de la utilización de controles apropiados, seleccionados estos en base a un análisis costo/beneficio (factores no económicos o intangibles, como la pérdida de reputación, también deberán ser tomados en consideración).

Así como existe un Plan Estratégico de TI que soporta los objetivos del negocio tal y como se establecen en el Plan del Negocio, sugiero el que se realice un Plan Estratégico de la administración de la seguridad de la información que garantice también la alineación con los objetivos del negocio .

2.1 ELEMENTOS DE UN PLAN ESTRATEGICO DE LA ADMINISTRACION DE LA SEGURIDAD DE LA INFORMACION

2.1.1 DEFINICION DE SEGURIDAD DE LA INFORMACION

Existen diferentes definiciones de la seguridad de la información, sin embargo, una de las más aceptadas es la del estándar ISO 17799 [14]:

"La información es un activo el cual, como otros activos importantes del negocio, tiene valor para la organización y por lo cual debe ser protegida de manera adecuada. La seguridad de la información protege a la información de un amplio rango de amenazas de tal manera que se pueda garantizar la continuidad del negocio, minimizar daños al negocio y maximizar los retornos de inversión y las oportunidades de negocio" .

•

•

•

48

Adicionalmente establece:

"La información puede existir de muchas formas. Puede estar impresa o escrita en un papel, almacenada de manera electrónica, transmitida por correo postal o electrónico, mostrada en películas o hablada en una conversación. Cualquier forma que la información tome, o la manera como sea compartida o almacenada deberá ser siempre protegida de manera adecuada".

La razón de elegir el ténnino seguridad de la información en lugar de otros como seguridad informática o seguridad computacional, es que estos dos casi siempre están relacionados con cuestiones tecnológicas, talvez bits y bytes, cuando la realidad es que lo que nos interesa es proteger la información, en cualquiera de sus formas o estados (digital o no), no solo esos bits y bytes. Finalmente, el estándar establece que la seguridad de la información es caracterizada por la preservación de:

a) Confidencialidad, garantizar que la información es accesible solo a aquellos que están autorizados a tener acceso.

b) Integridad, salvaguardando la exactitud y lo completo de la información y los métodos de procesamiento.

c) Disponibilidad, asegurando que los usuarios autorizados tienen acceso a la información y activos asociados cuando lo requieren.

Lo anterior nos sirve como punto de partida para describir los demás elementos de una administración de la seguridad de la información.

2.1.2 PATROCINIO DE LA ALTA GERENCIA Y ALINEACION CON OBJETIVOS DE NEGOCIO

Necesitamos empezar con la siguiente frase (esperamos quede claro el por qué después de leer las líneas que siguen): La seguridad de la información es un asunto de negocio.

De acuerdo con Jan Killmeyer Tudor en [15], no es dificil establecer una Arquitectura de seguridad si existen tres elementos:

1. Apropiado énfasis por parte de la alta gerencia 2. Planeación 3. Habilidades organizaciones sólidas.

El mismo autor señala:

"El Comité Ejecutivo de seguridad compuesto por niveles directivos es la autoridad que aprueba todos los planes de seguridad relacionados con la protección de los sistemas y activos de información. Este Comité es responsable de garantizar que los objetivos de un ambiente seguro de operación son claramente definidos en el Plan Estratégico del Negocio. Este Comité es el

•

•

49

principal patrocinador de una arquitectura de seguridad de la información. Sin su soporte los recursos necesarios no estarán disponibles".

Pero ¿Por qué hacer énfasis en el patrocinio de la alta gerencia?, la respuesta es sencilla: ella es la encargada de definir las metas y estrategias del negocio, por lo tanto conoce cuales son las áreas críticas, la información clave, los planes a corto, mediano y largo plazo, conoce que tanta dependencia existe de cierta infraestructura, talvez no conozca todos los riesgos pero si conoce las pérdidas o impactos de no tener disponibles ciertos elementos, o de perder la integridad o confidencialidad de cierta información. Finalmente, la alta gerencia es en algunos casos dueña del negocio y en otros la encargada de su crecimiento, desarrollo y protección. La alta gerencia es responsable de cuidar los intereses y activos de la Compañía y la información es un activo más, sin embargo, cada día las compañías tienen mayor dependencia de su información y de la manera como ésta se procesa, transmite, almacena, comunica, destruye, etc.

Como se mencionó, en ocasiones la alta gerencia no conoce todos los riesgos a los que está expuesto el manejo y uso de su información, es aquí donde los especialistas en seguridad de la información deben aportar sus ideas para clarificar dichos riesgos, y convertirlos en ideas claras para transmitirlas de manera adecuada a la alta gerencia. En nuestra experiencia los niveles ejecutivos probablemente no entienden siempre de tecnología (aunque también nos hemos encontrado excepciones), sin embargo, si entienden de riesgos por lo que el reto es que los especialistas de seguridad de la información conviertan los riesgos de tecnología en riesgos de negocio, esta conversión dejará mas claro el panorama a la alta gerencia de la importancia de la inversión en cie1tos controles.

Así como existe un Plan Estratégico de TI que soporta los objetivos de negocio, se sugiere la elaboración de un Plan Estratégico de la administración de la seguridad de la información que al igual que el primero clarificará a la alta gerencia que las acciones en el tema de la seguridad de la información están encaminadas a soportar y habilitar las estrategias y metas del negocio. Esto debido a que una de las preocupaciones de los ejecutivos es que las inversiones en tecnología y seguridad de la información son elevadas por lo que quieren garantizar que realmente estén alineadas con las acciones del negocio. El caso típico a este respecto, es cuando se invierte (aunque aquí aplica mejor en término: gasta) una cantidad muy importante en software, hardware y asesoría técnica para crear una zona de servicios públicos a Internet (por ejemplo, una DMZ) cuando el único objetivo es tener un servidor de web que presente información de la Compañía. La inversión puede ser mayúscula y el beneficio pobre en su relación con el soporte a los objetivos del negocio.

En conclusión, las inversiones en seguridad de la información deben estar encaminadas a soportar las estrategias del negocio, solo así la alta gerencia podrá verlas efectivamente como inversiones y no como gastos.

También es importante tomar en cuenta las recientes regulaciones y legislaciones (ej.: Acto Sarbanes-Oxley en Estados Unidos), principalmente para empresas de Estados Unidos y sus filiales que tengan inversiones de terceros (ej.: que coticen en la Bolsa). Aunque éstas están

1

•

•

50

siendo adoptadas a nivel mundial, solicitan que el reporte financiero anual contenga un reporte de control interno en el cual se establezca:

1. La responsabilidad de la alta gerencia para establecer y mantener una adecuada estructura de control interno y procedimientos para la realización del reporte financiero y,

2. La realización de una evaluación por parte del auditor externo, al finalizar el año fiscal, sobre la efectividad de la estructura de control interno y procedimientos para la realización del reporte financiero.

Esto es de gran ayuda ya que la propia Ley hará responsable a la alta gerencia de irresponsabilidades en materia de control interno que va muy de la mano con la protección (principalmente de la integridad) de los activos informáticos que involucran al procesamiento de reportes financieros. Desafortunadamente, esta fue una acción reactiva por los sonados fraudes de empresas multinacionales y multimillonarias como Enron y WorldCom.

Finalmente, de acuerdo con José Granado, Mark Doll y Sajay Rai en [16] establecen que las diferencias entre un programa de seguridad y un programa de seguridad de clase mundial son:

1. Un programa efectivo implementa nueve elementos (Detección de virus e intrusos, respuesta a incidentes, privacidad, políticas, estándares y procedimientos, seguridad física, administración de activos, administración de privilegios, administración de vulnerabilidades, continuidad del negocio) en la agenda de seguridad totalmente alineados con la estrategia del negocio de manera continua, proactiva, validada y formal.

2. Un programa efectivo es patrocinado por el CEO ("Chief Executive Officer") y dirigido desde el nivel ejecutivo.

2.1.3 ESTRUCTURA ORGANICA DE SEGURIDAD DE LA INFORMACION

Existen dos figuras en una estructura orgánica de seguridad de la información:

1. Oficial de seguridad 2. Equipo de seguridad

Dependiendo del tamaño de la Compañía pueden requerirse gerencias al mando del oficial de seguridad. A su vez, el tamaño del equipo de seguridad dependerá de las necesidades de la Compañía.

El oficial de seguridad es parte del comité ejecutivo de seguridad que a su vez está integrado por miembros directivos de la Compañía y que como ya comenté es este comité el que avala, aprueba y patrocina el plan de seguridad de la información. Algunas de las responsabilidades del oficial de seguridad son:

1. Comunicar a la gerencia ejecutiva o alta gerencia los riesgos y controles relacionados con el negocio y operaciones de los sistemas .

'

•

51

2. Asegurar accesos de usuarios apropiados así como asegurar la existencia de controles de

autenticación. 3. Asegurar I a existencia de políticas, procedimientos y estándares, a sí como su revisión,

validación, actualización y mantenimiento periódico. 4. Evaluar amenazas a la seguridad así como la falta de cumplimiento con regulaciones

relacionadas con seguridad. 5. Asegurar que todas las unidades de negocio entienden y ejecutan sus responsabilidades en

materia de seguridad de acuerdo a las políticas, procedimientos y estándares. 6. Organizar y conducir reuniones periódicas con el equipo de seguridad. 7. Investigar publicaciones sobre nuevas actualizaciones de seguridad, actualizaciones de

versiones y nuevas amenazas. 8. Desarrollar e implementar el programa de conciencia de seguridad. 9. Desarrollar e implementar el programa de cumplimiento. 1 O. Encabezar los esfuerzos del equipo de seguridad.

En conclusión, el oficial de seguridad es el coordinador de todas las actividades relacionadas con la seguridad de la información. Es importante señalar que el oficial de seguridad no es quien hace todo, por ejemplo, él no es el encargado de escribir las políticas ( esta responsabilidad es del equipo de seguridad y las áreas afectadas) sin embargo, si es su responsabilidad el asegurar que dichas políticas se escriban, distribuyan y apliquen. No es quien realiza todas las tareas pero si es quien se asegura de que los esfuerzos de seguridad son coordinados. Es altamente deseable que el oficial de seguridad le reporte a algún nivel ejecutivo, por lo general al CFO (Chief Financia! Officer) ó al CIO (Chieflnformation Officer).

El equipo de seguridad estará encargado del desarrollo e implementación de políticas, procedimientos y estándares junto con las áreas involucradas. Adicionalmente, realizará las tareas del día a día en materia de seguridad como validación de accesos y privilegios de usuarios, instalación junto con parte operativa o técnica de sistemas operativos, aplicaciones, firewalls, routers, detección de intrusos, bases de datos, etc. configuración junto con parte operativa o técnica de parámetros de seguridad, revisión de bitácoras, monitoreo de eventos anómalos, entre otras.

2.1.4 ANALISIS DE RIESGOS

El análisis de riesgos debe ser considerado como un proceso continuo dentro de la Compañía, solo a sí se podrán i <lentificar amenazas y su probabilidad de ocurrencia de tal manera que se puedan proponer controles, acordes en costo/beneficio, que mitiguen riesgos.

Las preguntas más comunes en un análisis de riesgos son: ¿ Qué debo proteger?, ¿ Qué puedo proteger?, ¿Qué es lo primero que debo proteger?, ¿Cómo lo debo proteger?, ¿Cómo lo puedo proteger?, ¿Cuánto me cuesta protegerlo? Si no lo protejo, ¿Cuánto me puede costar?, ¿Hay alguna regulación o legislación que me obligue a proteger algo? .

•

52

Todas estas preguntas son clave en la definición de un Plan Estratégico de la seguridad de la información ya que las respuestas a estas preguntas nos estarán diciendo:

o Si se conocen los elementos críticos de la infraestructura que soportan los procesos más importantes del negocio

o Si dicha infraestructura tiene los controles apropiados para mitigar los riesgos a un nivel aceptable

o Si se conocen los objetivos del negocio y la infraestructura e información que ayudan a su cumplimiento

o Si las inversiones en seguridad de la información están alineadas con los objetivos del negoc10

o Si se conocen los riesgos, en el terreno de la seguridad de la información, a los cuales se enfrenta el negocio

o Si se tiene un equilibrio entre las inversiones de seguridad de la información y el valor de la información que se está protegiendo

o Si se conoce o ha estudiado la probabilidad de ocurrencia de que las distintas amenazas se materialicen en pérdidas (tangibles o intangibles)

o Si se están utilizando los controles más adecuados para proteger la infraestructura tecnológica y la información del negocio en términos de costo/beneficio

o Si se conocen los impactos que pueden llegar a causar ciertas amenazas o Si se conocen regulaciones y legislaciones que deben tomarse en cuenta en materia de

seguridad de la información o Si existen situaciones de riesgo que se han decido aceptar o Si existen situaciones de riesgo que se han decido transferir (seguros)

La forma de contestar estas preguntas clave y tener respuestas acorde a las necesidades, requerimientos, regulaciones y objetivos del negocio es a través de un análisis de riesgos.

De acuerdo con el estándar ISO 17799 "los requerimientos de seguridad son identificados a través de una evaluación/análisis de riesgos de seguridad de manera metódica. Las inversiones en controles necesitan estar balanceadas de acuerdo al daño al negocio que puedan ocasionar por una falla de seguridad. Las técnicas de análisis de riesgos pueden ser aplicadas a toda una organización o solo a ciertas partes, así como a sistemas de información individuales, componentes específicos de un sistema o a servicios cuando sean prácticos, reales y necesarios"

También el estándar establece que: "Una evaluación de riesgos es una consideración sistemática de:

1. El daño al negocio que puede ocurrir por una falla de seguridad, tomando en cuenta las consecuencias potenciales de la pérdida de confidencialidad, integridad o disponibilidad de la información u otros activos

2. La posibilidad real de que tal falla o curra a la luz de 1 as amenazas y vulnerabilidades prevalecientes y de los controles actuales implementados .

•

53

Los resultados de este análisis ayudarán a guiar y determinar las acciones administrativas adecuadas y las prioridades para manejar los riesgos de la seguridad de la información, y para implementar los controles seleccionados para protegerse contra dichos riesgos. El proceso de evaluación de riesgos y selección de controles talvez requiera ser realizado un cierto número de veces con la finalidad de cubrir diferentes partes de la organización o sistemas de información individuales".

Es importante mencionar que un análisis de riesgos debe realizarse de manera periódica esto debido a que las amenazas que enfrenta una organización pueden cambiar (no necesariamente aumentar o disminuir) talvez por cambios en el modelo de negocio, en las estrategias comerciales o específicas, en migraciones de plataformas, por implementación de nuevas tecnologías (ej.: inalámbrica) o en la implantación de un ERP, por nuevas legislaciones o reglamentaciones, solo por citar algunas. Lo anterior es la base de la administración de riesgos, es decir, un solo análisis de riesgos no es suficiente, dos tampoco, lo necesario es que e 1 negocio tenga una cultura. de administración de riesgos que permita mitigarlos o mantenerlos en un nivel aceptable.

Aunque existen dos técnicas principales para llevar a cabo un análisis de riesgos, cualitativo y cuantitativo, el más común es una mezcla de ambos (de hecho un análisis de riesgos 100% cuantitativo sería muy costoso y talvez imposible, ya que siempre habrá ciertas medidas cualitativas). En ocasiones el enfoque es solo tecnológico, nosotros sugerimos que se realice tecnológico y organizacional. La metodología OCTAVE (por sus siglas en inglés, "Operationally Critica! Threat, Asset, and Vulnerability Evaluation) desarrollada por el CERT/CC, Computer Emergency Response Team / Coordination Center, operado por la Universidad Carnegie Mellan) es un buen punto de partida a este respecto (http://www.cert.org/octave).

De acuerdo a un análisis de riesgos que practicamos a una institución financiera los factores críticos de éxito fueron:

o Patrocino de la dirección general o Entendimiento del entorno del negocio o Involucrar a las áreas estratégicas del negocio o Homogenizar la definición de riesgo entre las áreas estratégicas del negocio o Considerar no solo elementos tecnológicos sino también financieros, legales, operativos y

de imagen o Consenso sobre la infraestructura y elementos críticos del negocio que pudieran impactar

a cuestiones tecnológicas, financieros, legales, operativos y de imagen. o Centrar energía en áreas críticas sin descuidar áreas de riesgo medio e inferior

De acuerdo con Eric Greenberg en [17] "se requiere una ecuación de negocio que nos ayude a priorizar nuestros (usualmente escasos) dólares y recursos para seguridad de tal manera que los enfoquemos para que en caso de que nos hackeen se presente el menor impacto a nuestra organización"

Como resultado del análisis de riesgo se habrán encontrado los activos críticos del negocio, lo cual puede ser tomado para una clasificación de datos. Esta tarea es muy recomendable aunque

•

•

•

54

en ocasiones laboriosa dependiendo del tamaño de la organización y del manejo de información de la misma. La meta central de la clasificación de información es encontrar un punto de partida sobre lo que es considerado sensitivo o critico y por lo tanto protegerlo de acuerdo a esta característica. Es importante señalar que para ciertas organizaciones, por ejemplo gubernamentales o militares esta actividad puede ser indispensable y hasta mandatoria.

2.1.S NORMATIVIDAD DE SEGURIDAD DE LA INFORMACION

La normatividad de seguridad de la información pem1ite que todos los empleados, proveedores y clientes de una Compañía conozcan la manera como ésta espera que deben ser manejados todos sus activos de información y activos relacionados de información.

Algunas de las preguntas que puede resolver la definición de una normatividad de seguridad de la información son: ¿Cada quién protege los activos de información y la infraestructura de manera discrecional?, ¿Cambio mi contraseña cada vez que yo creo adecuado?, ¿Puedo colocar un punto de acceso inalámbrico en mi segmento operativo para evitar todos estos cables?, ¿Actualizo mi anti virus una vez al mes, cada semana o diario?, ¿Yo soy el desarrollador y yo mismo puedo realizar los traspasos a ambientes productivos?

La lista de preguntas puede volverse interminable. Las respuestas las podemos encontrar dentro de una: Normatividad. Esta involucra la definición de políticas (una general comúnmente denominada política de seguridad de la información o política directriz de seguridad de la información, y otras específicas, por ejemplo: política de correo electrónico), procedimientos y estándares.

Las políticas son diseñadas para informar a todos los individuos que de alguna forma interactúan ( empleados, socios de negocio, terceros, proveedores, etc.) con los activos de información y la infraestructura tecnológica de la Compañía:

1. La manera como deben actuar respecto a cierto tema en particular, 2. Cómo es que la Gerencia Ejecutiva (o alta gerencia) aborda y acepta dicho tema y, 3. Qué acciones específicas toma la organización respecto a ese tema.

Por lo general, la política de seguridad de la información o política directriz de seguridad de la información describe de manera formal lo que la gerencia ejecutiva trata de alcanzar, es decir, el objetivo de la normatividad en general, su alcance, definición de roles y responsabilidades, y su intención de implementarla. De la política de seguridad de la información se emanan otras políticas más específicas como (tomando como base el estándar ISO 17799):

o Política de Seguridad Organizacional o Política de Control y Clasificación de Activos o Política de Seguridad del Personal o Política de Seguridad Física o Política de Comunicaciones y Administración de Operaciones o Política de Control de Acceso

•

1

•

55

o Política de Desarrollo y Mantenimiento de Sistemas o Política de Administración de Continuidad del Negocio o Política de Cumplimiento

Adicionales a éstas podemos encontrar:

o Política de Uso Aceptable de los Sistemas de Información o Política de Correo Electrónico e Internet o Política de Protección contra Virus y Código Malicioso o Política de Despido de Empleados o Política de Protección de la Información de Clientes y su Privacidad o Política de Administración de Fraudes y controles Anti-Fraude o Política de Contraseñas o Política de Acuerdos de Niveles de Servicio o Política de Respuesta a Incidentes

Es importante señalar que en México existe un vacío en la legislación o en regulaciones particulares que obligue a cierto tipo de organizaciones a tener y cumplir con una normatividad de seguridad de la información, sin embargo, esto si existe para empresas transnacionales principalmente con sede en Estados Unidos y Europa. Las políticas son un elemento esencial de comunicación del deber ser entre la gerencia ejecutiva y sus empleados (y como ya mencionamos, a cualquiera que tenga contacto con su infraestructura tecnológica y activos de información). La normatividad provee credibilidad y soporte a todos los esfuerzos de seguridad de la información. También establece la base disciplinaria y la manera de proceder en el ámbito legal. Es altamente recomendable que sean escritas de manera concisa, clara y precisa para evitar cualquier controversia o mala interpretación. Deben ser vistas como una herramienta para educar a los usuarios y no como un medio de represión o miedo, ya que esto podría cohibirlos de reportar alguna violación a las mismas.

Muchas organizaciones tienden a tomar políticas ya elaboradas por otras similares, esto puede ser grave y solo podrán ser tomadas como punto de partida ya que cada una tiene riesgos y circunstancias distintas.

En conclusión, la finalidad de la políticas de seguridad de la información es establecer un marco normativo alineado con los objetivos del negocio y patrocinado por la gerencia ejecutiva que permita proteger los activos críticos de información, la infraestructura que los soporta y la gente que los opera a través de reglas claras que definen: ¿Quién es el responsable de ejecutarla?, ¿Qué debe ejecutar? y¿ Porqué debe ejecutarlo?. Por esto es indispensable que antes de realizarla normatividad de seguridad de la información uno se pregunte: ¿Qué es lo que quiero proteger? Esta pregunta, como ya mencionamos puede ser respondida con un Análisis de Riesgos. Es muy recomendable que las políticas sean elaboradas por un equipo que involucre a niveles gerenciales o directivos de áreas usuarias y personal técnico para que se logre un equilibrio adecuado de uso y aplicabilidad. Se recomienda que el hilo conductor de la Normatividad sean los conceptos de mínimo privilegio y segregación de funciones .

•

56

Los estándares son un conjunto específico de reglas, procedimientos o convenciones que son acordadas de tal modo que se pueda operar de manera uniforme y efectiva. Por ejemplo, si cada empleado pudiera elegir el sistema operativo de su agrado sería muy complicado el mantenerlos al día en cuestiones de actualizaciones de seguridad y en implantar software de productividad homogéneo. Así, los estándares especifican un nivel de expectativa que debe ser alcanzado o excedido de tal forma que puedan ser cubiertas las obligaciones o responsabilidades. Es importante mencionar que los estándares tienen un gran impacto en la implementación de la seguridad, por ejemplo, cuando los estándares no se toman en consideración en temas de implementaciones tecnológicas puede impactar de manera considerable en la energía y soporte requerida para alcanzar los objetivos de seguridad de la organización. Lo anterior se traducirá en un mayor costo y también en unpiayor nivel de riesgo. El sistema operativo es un ejemplo claro de un estándar que debe buscarse dentro de una organización, será más fácil el darle soporte y mantener al día a uno solo que a 4 o 5 diferentes.

Los procedimientos son planes, procesos u operaciones detalladas de cómo realizar acciones o tareas específicas. Permiten la transferencia de conocimiento para los que realizan las tareas de otros en su ausencia. Los procedimientos son dinámicos en el sentido que pueden evolucionar si se encuentra una mejor manera de realizar las actividades, finalmente, en el día a día se pueden ir depurando y actualizando. Comúnmente responden a las preguntas: ¿Cómo?, ¿Dónde?, ¿Cuándo?

2.1.6 REQUERIMIENTOS TECNICOS

Como resultado del análisis de riesgos y la normatividad se definen los controles necesarios para proteger la infraestructura tecnológica que soporta los procesos críticos del negocio así como los activos de infonnación. Algunos de dichos controles son administrativos como la propia normatividad, las prácticas de contratación de empleados, los acuerdos de confidencialidad, la terminación de contratos, el programa de conciencia y entrenamiento de seguridad de la información, entre otros, sin embargo, un número muy importante de controles requieren elementos técnicos. Comúnmente se dividen de la siguiente manera:

a) Seguridad de Red a. Firewalls b. Detección de Intrusos c. Gateway de antivirus d. Filtrado de contenido e. Controles específicos para sistemas expuestos a Internet f. Controles específicos para Redes Inalámbricas g. Segmentación de redes - zonas de seguridad h. Encripción- VPNs l. Servicios de Directorio

J. PKI k. Centralización de eventos

b) Seguridad de Host

•

•

•

57

a. Procedimientos para fortalecimiento de sistemas operativos(servidores, cliente y dispositivos de red)

b. Protección de Integridad - huellas digitales c. Protección de Confidencialidad - Encripción d. Protección de Bitácoras

c) Seguridad de Aplicaciones a. Control de Acceso b. Autorización c. Control de Cambios d. Uso de mecanismos de cifrado e. Separación de ambientes de desarrollo, pruebas y producción

A continuación se expone lo más significativos de cada uno de ellos, acompañados de una breve descripción .

2.1.6.1 Seguridad de Red

La seguridad en red busca establecer controles que mitiguen 1 os riesgos asociados a 1 a actual complejidad de ambientes distribuidos y la conectividad.

2.1.6.1.1 Firewalls

El objetivo principal de un Firewall es establecer un control de acceso al nivel de la red tomando como base principal direcciones IP fuente y destino así como puertos TCPIUDP fuente y destino que permita habilitar la política de seguridad que norma el tráfico entre dos o más redes . Comúnmente utilizados para segmentar redes privilegiadas de redes no privilegiadas, por ejemplo, para la creación de una red (comúnmente llamada DMZ) con los servicios públicos de una organización como lo podrían ser servidores de web, servidores de nombres, etc. con controles de acceso lógicos entre otras redes como lo son Internet y la red interna de la Compañía. Lo anterior es conocido como un Firewall de Internet. Es importante señalar que su uso más común es el descrito, sin embargo, también son útiles para crear zonas de seguridad en el interior de una organización en las cuales se puedan segmentar las redes de acuerdo a la criticidad de la información manejada en ellas, esto con el objetivo de mitigar el riesgo de ataques internos.

Los firewalls son comúnmente reconocidos como la primera línea de defensa contra amenazas externas, sin embargo, el solo hecho de tener un firewall no mitiga riesgos, es la posibilidad de reflejar la política de seguridad de la organización lo que protege y justifica su implementación. Es decir, un firewall mal configurado y sin una política adecuada que bloquee ciertos tráficos de poco o talvez de nada servirá.

De acuerdo con Julia Allen en [18] los pasos a seguir para implementar un esquema de firewall o firewalls es:

•

'

•

58

1. Preparación a. Diseño del sistema

2. Configuración a. Adquisición del hardware y software necesario b. Entrenamiento c. Instalación de hardware y software d. Configuración del ruteo IP e. Configuración del filtrado de paquetes f. Configuración del sistema de bitácoras y alerta

3. Prueba 4. Implantación

a. Instalación del sistema firewall b. Traspasar el sistema firewall a producción

Es importante señalar que el sistema operativo en el que se instale el firewall deberá estar fuertemente robustecido y no deberá tener ningún servicio en red disponible, es decir, ningún puerto TCP o UDP deberá estar activo. También es muy recomendable que no responda a tráfico de ICMP, entre más "invisible" sea el firewall será más complicado que lo ataquen directamente. Recordar que es un punto de control de acceso en la red que en ocasiones también se vuelve un punto único de falla por lo que podría volver blanco de ataque de una negación de servicio. Para implementaciones más robustas se sugiere evaluar la posibilidad de instalar el firewall en modo puente o "bridge" ( capa 2) de tal manera que no tenga una dirección IP y por lo tanto será más complicada atacarlo. Una de las manera de hacer esto es actualizando el kernel de Linux (2.4.X) con el "parche" desarrollado por "Lennert Buytenhek" y el paquete "ebtables", para mayor información se sugiere consultar el siguiente artículo: "Bridgewalling - Using Netfilter in Bridge Mode" de Ralf Spenneberg. Ambos, el "parche" y el paquete "ebtables" están contenidos en el kernel 2.6 de Linux. Una referencia interesante sobre este concepto para el sistema operativo OpenBSD es el artículo "Invisible Firewalling How -To".

Existen varios tipos de firewalls, sin embargo, los más recomendables son los proxies de aplicación y los de inspección de estado (otros son los de filtrado de paquetes, proxies de circuito). Los primeros se dice son más seguros debido a que tienen la capacidad de analizar hasta la capa de aplicación, siendo esto muy importante ya que la mayoría de los ataques se presentan precisamente en este nivel, sin embargo, se requiere que el proxy entienda el protocolo de aplicación que el cliente está hablando. A diferencia de los de inspección de estado que únicamente analizan a nivel de direcciones IP (capa 3, red) y protocolos TCP y UDP (capa 4, transporte), tomando en cuenta y manteniendo el estado de las conexiones de estos. Es importante mencionar que varios firewalls de Inspección de Estado están incorporando proxies de aplicación para ciertos protocolos como http, ftp, stmp, entre otros. La principal ventaja de los firewalls de inspección de estado es su desempeño, y también hay que decir que son los más comunes y utilizados, sin embargo, cuando se les habilitan a estos las capacidades de proxy de aplicación (ej. http) baja su desempeño alrededor de 7 veces. Algunos ejemplos de estos son: Netfiler/IPFilter, CheckPoing FW-1 y Cisco PIX. Algunos ejemplos de los proxies de aplicación son: Network Associates Gauntlet (comprado por Secure Computing), Symantec Enterprise Firewall (antes Axent/Raptor) y Sidewinder de Secure Computing .

•

59

Otra característica adicional de los proxies de aplicación es que parten las conexiones de tal modo que un cliente que inicia una conexión la envía al proxy y éste a su vez la envía al destino final. De igual manera, la respuesta de este destino final será hacia el proxy y este a su ve lo enviara al cliente inicial. Lo interesante de este modelo es que el cliente en ningún momento tiene contacto lógico ( conexión) con el destino final por lo que éste nunca se entera de su existencia, adicionalmente al partir la conexión se puede hacer una validación al nivel de la capa de aplicación en la que se podrá analizar si ésta lleva consigo ataques o código malicioso. Adicionalmente, la mayoría de los proxies requieren autenticación para aceptar el tráfico, con lo cual se puede limitar el uso de Internet solo a usuarios que así lo requieran. Es común que se utilice e I término P roxy ( en singular) aunque realmente a lo que nos estamos refiriendo es al sistema tipo firewall que aloja a un conjunto de proxies de aplicaciones ( es decir, un proxy par http, otro para ftp, otro para smtp, etc.)

De acuerdo con Northcutt en [19] las ventajas de los firewalls tipo proxy son:

a) Las direcciones IP internas son desconocidas para el mundo exterior b) Los administradores pueden monitorear violaciones de seguridad configuradas en el

firewall utilizando las capacidades de auditoria de los proxies c) Los proxies pueden establecer mecanismos de autenticación de tal manera que solo

tengan acceso a otras redes (comúnmente Internet) los usuarios que lo requieran o que se los permita la política de seguridad.

d) Los proxies no son vulnerables a ataques de spoofing (enmascaramiento) de IP debido a que su conectividad está basada en servicios en lugar de conexiones fisicas.

e) Los proxies tienen, comúnmente, una mayor capacidad de auditoria y bitácoras.

Sin embargo, el mismo autor también señala las siguientes desventajas:

a) Reducción en el desempeño debido a que analizan hasta la capa de aplicación. b) Se requiere un proxy para cada aplicación de red o protocolo que requiera pasar a través

del firewall. c) Problemas inherentes del sistema operativo que alberga al proxy pueden afectar la

seguridad del propio firewall. d) Dependiendo de la configuración puede convertirse en un punto único de falla.

Es importante mencionar que existen configuraciones de proxy tanto "hacia delante" (forward) como "hacia atrás" (reverse). El primero es cuando un sistema cliente en la red interna de una organización se quiere comunicar con un destino en Internet, el segundo es cuando un sistema cliente en Internet se quiere comunicar con un servidor destino dentro de una organización (posiblemente en una DMZ).

2.1.6.1.2 Detección de Intrusos

La definición de Detección de Intrusos o Intrusiones de acuerdo con Rebecca Bace en [20] es:

t

60

"El proceso de m onitoreo de eventos que o curren en 1 os sistemas informáticos o en 1 a red, y analizándolos por indicios de problemas de seguridad".

También es importante recalcar lo que establece en la introducción de dicho libro:

" ... Mi pasión (refiriendo a la de esta tecnología) ha sido interferida por la frustración. Veo productos comerciales que utilizan solo una fracción de los investigados durante los últimos 15 años. Veo desarrolladores que nunca le preguntan al usuario final que es lo que espera ... Veo desarrollos e iniciativas de investigación que demuestran un poco o nulo entendimiento de los problemas que enfrentan los usuarios ... Finalmente, veo una continua resistencia a la expresión libre y abierta en el tema de discusión de intrusiones y vulnerabilidades para aquellos que requieren de manera desesperada esta información para proteger sus sistemas .. Fuera de estos problemas, todavía creo en el valor y futuro de Detección de Intrusiones como un parte integral de la seguridad computacional".

Numerosas organizaciones e institutos de los Estados Unidos como el Departamento de Defensa, la Fuerza Aérea, la Naval, el Centro Nacional de Seguridad Computacional (NCSC), la División de Cómputo de los Laboratorios Nacionales en Los Alamas, el Laboratorio Nacional Lawrence Livermore, la Agencia de Seguridad Nacional, el Departamento de Energía, por mencionar algunos, han estado involucrados en la investigación del tema de Detección de Intrusos.

Comúnmente el tema de Detección de Intrusos es visto como la investigación de eventos en las bitácoras arrojados por sistemas operativos y aplicaciones. Sin embargo, desde hace varios años el tema se ha generalizado hacia las redes de computadoras debido al crecimiento exponencial de su uso. La primera fusión del análisis de eventos en ambos ambientes, locales y red, fue realizada por el proyecto denominado DIOS (por sus siglas en inglés, Distributed Intrusion Detection System), su arquitectura está expuesta en el artículo "DIOS - Motivation, Architecture and An Early Prototype" (1991) de Snapp, Brentano y Dias. Así, podemos decir que los dos enfoques elementales de Detección de Intrusos están basados en red o basados en "host".

A pesar de las investigaciones, la técnica más utilizada tanto de los basados en "host"como de los basados en red sigue siendo a través de la definición y búsqueda de eventos considerados anómalos ("pattem matching") con lo cual se crea una base de conocimiento de huellas contra las cuales se mapea la actividad tanto local como de red. Esta técnica tiene la grave falla de que tengo que conocer primero cual es ese patrón para después incorporarlo en la base de conocimiento y solo así podrá ser detectado, y digo que es su grave falla, porque solo detecta eventos conocidos (Si, muy similar a como funcionan los antivirus), por lo tanto habrá una gran cantidad de falsos negativos, es decir, verdaderas intrusiones que no se detecten. Son un elemento más dentro de nuestra arquitectura de seguridad de la información, y por tanto debemos conocer también sus debilidades (por cierto, el cifrado por lo menos a los basados en red los vuelve inútiles, excepto si se descifra la sesión antes de llegar a su destino, por ejemplo utilizando un proxy) sin embargo, son elementos que proveen de gran información al equipo de seguridad, principalmente cuando se colocan en segmentos conectados a Internet (ej.: DMZ) o en segmentos críticos de una organización. Para mayor información sobre la manera de atacarlos consultar [21).

•

61

Lo anterior nos debe sensibilizar a que el sistema operativo que alberga a un sistema de detección de intrusos basado en red debe estar robustecido y, que al igual que un firewall, ser lo más "invisible" posible. También se sugiere que no tenga una dirección IP. Una táctica de guerra muy conocida es atacar primero a los elementos de monitoreo y comunicación, también aplica a la seguridad de la información.

Técnicas más avanzadas de detección de intrusos son a través de análisis de llamadas al sistema de ciertos procesos como el modelo descrito en [22) de Warrender, Forrest y Pearlmutter. Otras técnicas sobre este tema se basan en la teoría del sistema inmunológico en donde el reto es poder identificar lo propio de lo no propio, es decir, lo legítimo y lo ilegítimo. Es importante señalar que esta técnica aplica tanto para detección de intrusos a nivel local como a nivel red. Más sobre este tema se puede encontrar en [23], [24) y [25).

Un sistema de detección de intrusos debería poder identificar, muy deseable en tiempo real, uso no autorizado, mal uso o abuso de un sistema informático. Estamos lejos de poder llegar a esta definición. Adicionalmente, su rol es de detección, no intenta detener la intrusión, solo alerta al equipo de seguridad que una violación potencial está sucediendo. De tal manera que es un elemento reactivo. Por esto hoy en el 2004, se habla de una nueva tendencia conocida como Prevención de Intrusos, por ejemplo, terminar una conexión en caso de que se identifique "un ataque", lo cual es delicado si se considera que un número muy elevado de eventos o alertas son falsos positivos ( en nuestra experiencia el 80 % de eventos son falsos positivos, y casi el 20% restante son solo intentos de intrusión, como interrogación de puertos, gusanos, pruebas a través de herramientas de identificación de vulnerabilidades, entre otros) ya que podemos caer en esquemas de negaciones de servicio de manera trivial. Otra tendencia actual es utilizar técnicas de engaño o "honeypots" que más que detectar ataques pueden servir para conocer como es que los sistemas pueden llegar a ser atacados.

En conclusión, los sistemas de detección de intrusos tanto basados en red como "host" son herramientas que, bien configuradas, pueden ser de gran utilidad para el equipo de seguridad ya que podrán detectar algunos (no todos) eventos que pueden ser abusos o ataques a los sistemas de información. Los más conocidos basados en red son Snort, Real Secure de ISS, Dragon de Enterasys, E -Trust de CA. A su vez, 1 os más conocidos basados en h ost son: N etlQ S ecurity Manager, S entryTools ( adquirido recientemente por Cisco) y S NARE de IntersectAlliance. Es importante comentar que los verificadores de integridad como el famoso "Tripwire", "AIDE" (Advanced Intrusion Detection Environmente) u Osiris son en muchas ocasiones reconocidos como detectores de intrusos basados en host.

2.1.6.1.3 Redes Privadas Virtuales y Accesos Remotos

En los últimos años el término "Red Privada Virtual" (más comúnmente llamada VPN, por sus siglas en inglés de "Virtual Prívate Network") se ha vuelto cotidiano debido principalmente a al crecimiento exponencial de la conectividad, los negocios electrónicos, los "telecommuters" y, en general, la globalización. El concepto básico de una VPN es utilizar la infraestructura de

•

62

conectividad pública (inherentemente insegura) pero asegurando la confidencialidad, integridad y autenticidad de la información que viaja por la misma utilizando técnicas criptográficas. Pero, ¿Por qué no utilizar una conexión o "enlace" privado o dedicado? (es decir, un cable de inicio a fin, únicamente para una organización), la respuesta sencilla es: COSTO. De acuerdo con varios estudios la disminución de costo puede llega a ser entre un 30 y 80 por ciento. Gartner Group realizó una investigación que lo llevó a estimar por lo menos un 50 por ciento de disminución de costo, asimismo, señaló que el 70 por ciento de las compañías "Fortune 500" utilizarían VPN para accesos remotos para el 2003. Esta cifra es similar a la del Forrester Research que señala una cifra mayor: 60 por ciento de disminución de costo. Finalmente, Infonetics Researh estimó entre un 60 y 80 por ciento.

De acuerdo con King, Dalton y Osmanoglu en [26] los principales usos de las VPN en las orgamzac10nes son:

1. Acceso remoto para la fuerza laboral remota ("telecommuters") 2. Conectividad tipo intranet de "sitio a sitio" ("site to site") 3. Conectividad tipo extranet ("business to business")

El componente principal de las VPN es la seguridad. Existen varios protocolos y tecnologías disponibles para obtener los requerimientos de seguridad deseados, sin embargo, los más utilizados son: IPSec (IP Security Protocol, parte integral de Ipv6), PPTP (Point to Point Tunneling Protocol), L2TP (Layer 2 Tunneling Protocol) y SSL (Secure Sockets Layer). IPSec, el de mayor uso, comúnmente se utiliza en modo túnel o modo transporte, en el primero todo el paquete es cifrado y encapsulado en un paquete IPSec ( este nuevo encabezado IPSec contiene comúnmente la dirección de un gateway de VPN, el encabezado IP -encapsulado- se encargará de rutear el paquete hasta el destino final), en el segundo solo el "payload" es cifrado dejando el encabezado IP visible. Existió una iniciativa para especificar un estándar de implementación de VPN utilizando IPSec conocido como Secure Wide Area Networks (S/W AN). Su objetivo era definir un conjunto común de algoritmos de IPSEC y modos de operación. Esta iniciativa estaba soportada también por el proyecto FreeS/Wan el cual también se declaró como inactivo a partir de primero de marzo de 2004.

Northcutt en [19) establece que detrás del concepto de VPN está asegurar un canal de comunicación con cifrado, dicho canal de comunicación puede ser salvaguardado a través de cifrado en varias de las capas, por ejemplo:

o Aplicación (ej.: PGP, SSH) o Transporte (ej.: SSL) o Red (ej.: IPSec) o Enlace de datos (ej.: L2TP, PPTP)

•

63

2.1.6.1.4 Segmentación de redes - zonas de seguridad

El concepto de segmentación de redes es de gran relevancia ya que permite crear zonas de seguridad de sistemas de acuerdo a su criticidad o sensitividad (muchas ocasiones por el tipo de infomrnción que procesan), esto permitirá, acorde con el análisis de riesgos y la normatividad, el definir controles más robustos para las zonas de mayor criticidad. Comúnmente, esta segmentación se puede realizar por firewalls ya que estos dispositivos permitirán, en base a su política, limitar y controlar el tráfico a nivel red autorizando explícitamente acceso a aplicaciones requeridas y negando todo lo demás. Es poco común encontrar este esquema dentro de las organizaciones, sin embargo, es altamente recomendable, ya que en las topologías de hoy en día hasta todos los usuarios conectados a la red pueden llegar a tener una ruta hacia los sistemas centrales críticos, violando así el mínimo privilegio (tener acceso solo a lo que se requiere para realizar sus funciones).

De acuerdo con Northcutt en [19), la segmentación de redes, es un elemento central en los principios de defensa de redes y es evidente en muchos diseños de red "con conciencia de seguridad" como elemento básico. Limita las vías de ataque y ayuda a enfocar recursos y controles.

2.1.6.1.5 Controles específicos para sistemas expuestos a Internet

Sobre los controles específicos para sistemas expuestos, es importante mencionar que para la mayoría de las organizaciones, estos sistemas pueden crear un gran riesgo, principalmente a la imagen. Por lo anterior, se sugiere tener controles severos, por ejemplo, actualizaciones lo más rápido posible (primero en un ambiente de pruebas para conocer el impacto que pueden llegar a tener dichas actualizaciones), políticas robustas de autenticación que obliguen a la utilización de contraseñas fuertes, verificación de políticas del firewall que los protege, basados en host "bastión", es decir, que su sistema operativo esté fortalecido y adecuado para que solo tenga disponible lo se requiere, controles específicos sobre la administración remota (que solo los usuarios autorizados tengan manera de llegar a ellos - tanto lógica como fisicamente - para administrarlos, obviamente utilizando protocolos de cifrado), control sobre cambios a contenidos y la propia aplicación, respaldos continuos, configuraciones restrictivas, monitoreo continuo, entre otros.

2.1.6.1.6 Controles específicos para redes inalámbricas

En el caso de redes inalámbricas, por su fácil uso, bajo costo y reducción de costos por la eliminación del cableado son una opción atractiva para muchas organizaciones, sin embargo, los riesgos existentes son numerosos. Principalmente porque los puntos de acceso inalámbrico no son configurados de manera adecuada, lo cual puede llegar a abrir un hueco de seguridad tremendo en una organización y los actuales mecanismos de cifrado son considerados débiles porque se ha demostrado que pueden romperse. Existe una tendencia fuerte hacia su investigación para lograr mejoras en la seguridad y privacidad que proveen, sin embargo, todavía hoy en día (abril 2004)

•

64

para lograr una implementación "segura" de una red inalámbrica se requiere de un alto esfuerzo humano y técnico.

2.1.6.1.7 Gateway de antivirus y filtrado de contenido

Los gateways de antivirus y filtrado de contenido permiten analizar todo el tráfico que entra y sale de una Compañía, principalmente a través de protocolos como smtp, pop3 y http, en búsqueda de patrones de código malicioso así como intentos de acceso a sitios de Internet no aceptados por la Compañía (ej.: pomografia, competencia, etc.). Son mecanismos cada día más utilizados y muy recomendables y a que aportan una línea de defensa adicional, en el caso del primero, al antivirus instalado en las máquinas cliente. Como ya se sabe el factor gente (principalmente, usuario final) es el más débil en la cadena de la seguridad de la información, por lo que entre menos se le delegue en esta materia, se podrá tener un ambiente de menor riesgo.

2.1.6.1.8 Servicios de directorio

Para el caso de los servicios de directorio, la integración del Directorio Activo ("Active Directory") de Windows 2000/2003 los ha promovido de manera importante, junto con la creciente utilización de esquemas y aplicaciones distribuidos. No podemos dejar de lado estos sistemas operativos que son de los más utilizados y difundidos. Además, la mayoría de los demás como Solaris, H P-UX, AIX, Linux, O S/400, entre otros, están incorporando protocolos a este respecto como LDAP. La cantidad de recursos disponibles en la red tanto LAN como W AN es cada día mayor, por lo que se debe garantizar su adecuado control de acceso, preferentemente en una administración centralizada a este respecto, los servicios de directorio pueden ayudar.

2.1.6.1.9 PKI

Para el caso de PKI, es un conjunto de componentes y procedimientos que habilitan una administración de llaves criptográficas a través del uso de certificados digitales. Desafortunadamente es una tecnología que ha sido considerada muy complicada por lo que es poco el uso en contraste con sus expectativas iniciales. Esto me hace señalar que la mayoría de las soluciones de seguridad (y me atrevo a decir, que no solo de seguridad sino en términos generales) deben ser lo menos complicadas posible para que puedan tener éxito, si no, en lugar de soluciones acarrean más problemas. Carl Ellison y Bruce Schneier escribieron, a este respecto, el artículo "Ten Risks of PKI: GAT You're not Being Told about Public Key Infrastructure" [27]. Algunos de los servicios comerciales de esta tecnología, de acuerdo con Christopher King, Curtís Dalton y Ertem Osmanoglu son:

o Autenticación web o Firma y cifrado de mensajería o Transacciones firmadas o Autenticación de sistemas operativos de red, host y mainframe

•

65

o Acceso Remoto o VPN o Encripción de archivos o Firma de software

2.1.6.1.10 Centralización de eventos

Cada día es de mayor relevancia el tener un repositorio central de eventos generados por todos los sistemas considerados críticos que permitan identificar patrones de ataques. Además de permitir correlacionar eventos, permite proteger la integridad de las bitácoras generadas en los sistemas. En ambientes UNIX se puede lograr a través del servicio syslog y en ambientes Microsoft Windows con aplicaciones de terceros.

2.1.6.2 Seguridad en Host

La seguridad en host busca establecer controles que mitiguen los nesgos asociados a la complejidad de los sistemas y aplicaciones actuales.

2.1.6.2.1 Procedimientos de fortalecimiento de sistemas operativos

El término "fortalecimiento" implica el tomar un sistema operativo con una instalación por omisión y hacerle las modificaciones necesarias para disminuir las posibilidades de amenaza así como para potenciar sus propias medidas de seguridad (política de contraseñas, de auditoria, entre otras). Es importante señalar que la mayoría de los sistemas operativos (Windows 2000/2003, Solaris, HP-UX, AIX, Linux) cuando se instalan, dejan abiertas una gran cantidad de huecos u oportunidades de mejora que pueden convertirse fácilmente en rutas de ataque para usuarios mal intencionados.

Los procedimientos de fortalecimiento de sistemas operativos involucran comúnmente las siguientes tareas:

1. Garantizar que todos los usuarios tengan asignada una contraseña y que ésta sea robusta 2. Validar y analizar las cuentas de usuarios del sistema y sus privilegios basándose en el

concepto de mínimo privilegio 3. Validar y analizar los grupos de usuarios del sistema y sus privilegios basándose en el

concepto de mínimo privilegio 4. Eliminar las cuentas y grupos de usuarios innecesarios, corno aquellas creados durante

una instalación por omisión. 5. Limitar el acceso de cuentas privilegiadas y establecer controles específicos sobre las

mismas (ej.: renombrándolas, limitándolas a acceder solo desde consola, registrando en bitácoras todas sus acciones

6. Restringir el uso de utilerías o programas administrativos

•

7. V ali dar y analizar permisos de acceso a los archivos 8. Borrar compiladores 9. Garantizar que las facilidades de auditoria (bitácoras) estén activas 1 O. Analizar los eventos que deben ser registrados en bitácoras 11. Deshabilitar servicios en red innecesarios

66

12. Restringir y evaluar la conveniencia del uso de protocolos que permiten compartir archivos

13. Restringir por un mecanismo local o de red el acceso a los servicios en red, hacer énfasis en aquellos que permiten acceder al sistema de manera remota vía una autenticación

14. Restringir el número de usuarios que deban tener acceso a la línea de comandos o a servicios de autenticación remota

15. Restringir y evaluar la conveniencia del uso de protocolos que permiten acceder a los equipos vía autenticación débil como dirección IP o nombre del sistema

16. Garantizar a través de políticas y procedimientos que se tienen las versiones más recientes tanto del sistema operativo como de las aplicaciones soportadas así como las actualizaciones de seguridad necesarias.

17. Evaluar la conveniencia de utilizar firewalls locales o controles de acceso similares con el afán de promover el concepto de "Defense in Depth" (Defensa en varias capas).

18. Evaluar la conveniencia de utilizar detectores de intrusos locales también con el afán de promover el concepto de "Defense in Depth".

19. Verificar la configuración del software antivirus de tal manera que se actualice de manera automática, realice inspecciones en tiempo real y que tenga habilitado el análisis heurístico.

20. Una vez realizadas las tareas anteriores se recomienda validar que efectivamente se han minimizado las puertas de entrada y debilidades del sistema utilizando herramientas de detección de vulnerabilidades e interrogación de puertos. Dependiendo del ambiente puede ser que éstas se ejecuten de manera local o remota. Es importante señalar que las herramientas locales siempre entregarán mayor información.

Es indispensable que todas estas tareas se realicen en sistemas recién instalados y en un ambiente de pruebas ya que de lo contrario (es decir, si se realizan en sistemas productivos) pueden ocasionar graves daños (aunque no lo queramos creer, hay aplicaciones que se diseñan para trabajar con el usuario root y contraseña root).

Las tareas mencionadas pueden aplicar tanto a plataformas de cómputo tipo servidor o cliente y para dispositivos de red (ej.: routers, switches, etc.), sin embargo, por la criticidad y cantidad de información manejada por los primeros es más el énfasis y controles que deben implantarse. Es importante señalar, que no por esto se deben descuidar las plataformas de cómputo tipo cliente ya que también contienen información muy sensible de las organizaciones. Un ejemplo claro de lo anterior es que 1 a mayoría de 1 os actuales directivos tienen en su computadora móvil ( laptop) información como planes estratégicos de la organización, objetivos económicos, sueldos de empleados, cartera de clientes, números de cuentas de bancos, contraseñas para acceder a sistemas centrales de la organización, estadísticas de ventas de productos, análisis financieros, entre otra información. Por esto se recomienda tener un estándar que permita proteger dicha información de manera adecuada mientras viva en los sistemas cliente .

•

•

67

La mayoría de los proveedores de sistemas operativos cuentan con "Checklist" o guías para su fortalecimiento (la pregunta obligada es: ¿ Y por qué entonces nos entregan los sistemas operativos completamente abiertos?), también son muy útiles las realizadas por terceros como el SANS, CERT, CIS, NSA, entre otras.

Existen algunas herramientas que permiten realizar la mayoría de las tareas presentadas, por ejemplo: Bastille Linux, Titan, JASS, YASSP, sin embargo, se sugiere utilizar estas herramientas solo en ambientes de prueba para analizar el impacto que pueden tener en las aplicaciones que soportan y una vez realizada esta validación podrían aplicarse a sistemas productivos.

2.1.6.2.2 Protección de Integridad - Huellas Digitales

El concepto de verificadores de integridad radica en el hecho de que una vez que un usuario no autorizado ha accedido al sistema (aunque también se da mucho el caso con usuarios autorizados del sistema), intentará borrar bitácoras, cambiar o modificar binarios por caballos de troya, cambiar configuraciones de archivos críticos que le permitan volver a tener acceso al sistema, crear cuentas de usuario, entre otras acciones. Es por esto, que nos vemos en la necesidad de tener una base de huellas digitales criptográficas o compendios (ej. utilizando MD5 o SHA-1) de todos los archivos y binarios críticos del sistema en su estado inmediato a ser fortalecido, esto con el afán de poder identificar lo que fue modificado.

Es muy deseable y hasta indispensable que una vez tomada la fotografia del sistema, es decir, haber obtenido la huella digital de cada uno de los archivos y binarios críticos, sea almacenada de manera segura fuera del sistema. La herramienta más común a este respecto es Tripwire, sin embargo, es realmente sencillo realizar esta tarea con un pequeño script. La ventaja de una herramienta como Tripwire son sus funciones adicionales, como por ejemplo, puede notificar en tiempo real sobre el cambio en la integridad de algún archivo o binario a través de varios medios como un evento en bitácora, correo electrónico, etc. Sin embargo, si el usuario logra acceder con privilegios de súper usuario probablemente ésta ya no sea una ventaja debido a que podrá desactivar este mecanismo. Aquí radica la importancia, y por eso el énfasis, en tener la fotografia del sistema fuera del mismo. Otras herramientas de este estilo y que están tomando importancia son: AIDE, Intact, Integrit, Osiris, Samhain, GFI LANguard System Integrity Monitor.

Es importante mencionar que la mayoría de las actualizaciones de seguridad modifican varios binarios y archivos de configuración por lo que será necesario el actualizar la fotografia del sistema para tener siempre la actualizada. La limitante principal de los verificadores de integridad es que solo nos notifican que ha habido un cambio en cierto archivo o binario pero no nos dicen cómo fue que se realizó dicho cambio. Sin embargo, en muchas ocasiones son la herramienta más fiel para detectar intrusiones. Como la mayoría de las herramientas aquí presentadas y cualquier otra, se sugiere que se instalen y prueben primero en ambientes y sistemas de prueba para que se analicen los impactos que podrían tener en el funcionamiento. Una vez realizada esta validación se podrán instalar en sistemas productivos .

•

68

2.1.6.2.3 Protección de Confidencialidad - Encripción

Una línea adicional de defensa es la utilización de mecanismos de cifrado que tienen el objetivo de proteger la confidencialidad y autenticidad de la información, no solo cuando se almacena sino también cuando se envía a través de la red. Por tanto la criptografia es muy útil pero también debe manejarse con el debido cuidado ya que se crea una dependencia importante de las llaves que se utilizan para encriptar, en caso de que éstas sean olvidadas o "perdidas" en teoría no se podrá recuperar la información. Y digo en teoría, porque son susceptibles a ataques de diccionario o de fuerza bruta. Un ejemplo claro es que podremos utilizar AES (Advance Encryption Standard) para cifrar un archivo, pero si utilizan1os una llave que es "rootroot" toda la seguridad de la infom1ación dependerá solo de dicha llave (recordar que los tres elementos clave de un mecanismo de cifrado son: la información, la llave y el algoritmo de cifrado) y por lo tanto será trivial aplicar el algoritmo utilizando dicha llave para recuperar la información de manera original y legible.

La herramienta más común para el cifrado local es PGP (Pretty Good Privacy) desarrollada por Phill Zimmermann (por cierto, debido a éste fue sujeto a una investigación criminal por 3 años en los Estados Unidos por su supuesta violación a restricciones de exportación de criptografia, después de su liberación pública y gratis en 1991 ). Nació más como una herramienta para cifrado de correo electrónico pero en la actualidad se utiliza ampliamente para cifrado local. Sobre soluciones criptográficas de red podemos mencionar SSH, SSL o IPSEC.

2.1.6.2.4 Protección de Bitácoras

Las bitácoras son vitales en la seguridad de los sistemas debido a que si están bien configuradas se pueden volver el mecanismo que permite conocer lo que están haciendo los usuarios, los intentos de leer o modificar archivos y programas de los cuales no tienen dichos privilegios, ejecutar o modificar programas de los cuales no tienen dichos privilegios, entre otras. También son elementos indispensables para un análisis forense. Se dice que cualquier sistema que se jacte de tener una seguridad razonable debe tener un nivel alto de capacidades al nivel de eventos o bitácoras. Aunque las bitácoras nacieron para identificar y resolver problemas ("troubleshooting") asociadas a funcionamientos inadecuados o erráticos, rápidamente se adoptaron en esquemas de seguridad. La mayoría de los sistemas de detección de intrusos se basaban en el análisis de bitácoras.

La clave es configurar los eventos que me dan más información sobre lo que está sucediendo en el sistema, por ejemplo, los más importantes son:

l. Intentos de acceso fallido (ftp, telnet, ssh, etc.) 2. Accesos positivos, desde que dirección fuente y usuario. 3. Intentos de lectura, ejecución o modificación de binarios críticos del sistema 4. Intentos de ejecución de binarios que permiten pasar de usuario local a usuario con

privilegios

•

69

5. Intentos de borrado de bitácoras 6. Modificación de archivos críticos o sensitivos 7. Ejecución de binarios críticos o sensitivos 8. Ejecución de tareas programadas 9. Intentos de interrogación de puertos 1 O. Inicio, reinicio y detención de servicios del sistema

Es muy recomendable el enviar dichos eventos a las bitácoras del sistema y además a un servidor cuya función sea un repositorio de bitácoras de los sistemas críticos o sensitivos de una organización. La mayoría de los sistemas operativos incorporan esta funcionalidad y con otros se puede lograr con productos de terceros. Las dos grandes ventajas de este esquema son: primero, que al enviar las bitácoras a un sistema remoto en caso de que se intentaran borrar las bitácoras producto de una intrusión aún así se tendrá evidencia (protección de integridad, aunque si producto de la intrusión se logra acceso con privilegios de súper usuario se podrán deshabilitar las bitácoras) y segundo, permite correlacionar eventos. Un artículo relevante sobre la protección de bitácoras para que sean útiles en un Análisis Forense es "Secure Audit Logs to Support Computer Forensics" de Bruce Schneier y John Kelsey.

2.1.6.3 Seguridad de Aplicaciones

Las principales recomendaciones y consideraciones en el tema de seguridad de aplicaciones son comúnmente el establecimiento de políticas y procedimientos asociados a los mecanismos de control de acceso al nivel aplicativo (capacidades de control de acceso en la propia aplicación), políticas y procedimientos de autorización (capacidades de autorización y creación de perfiles en base a privilegios en la propia aplicación), control de cambios en nuevos desarrollos y en mantenimientos a las aplicaciones, uso de mecanismos de cifrado, separación de ambientes de desarrollo, pruebas, control de calidad y producción.

2.2 CONSIDERACIONES FINALES PARA EL PLAN ESTRATEGICO DE LA ADMINISTRACION DE LA SEGURIDAD DE LA INFORMACION

Además de los aspectos administrativos (definición de seguridad de la información, patrocinio corporativo, estructura orgánica de la seguridad de la información, análisis de riesgos, normatividad de seguridad de la información) y los aspectos técnicos (seguridad de red, seguridad de host, seguridad de aplicaciones), que se han mencionado, es importante considerar los siguientes elementos, también críticos e indispensables en un Plan Estratégico de la administración de la seguridad de la información:

a) Programa de Conciencia y Entrenamiento - El elemento GENTE b) Plan de Continuidad del Negocio

a. Plan de Recuperación en Caso de Desastres b. Plan de Respuesta a Incidentes

70

c. Procedimientos de Respaldos c) Monitoreo y Auditoria d) Seguridad Física e) Políticas y Procedimientos sobre Análisis Forense

11

•

•

71

CAPITUL03

ANALISIS DE RESULTADOS OBTENIDOS EN PRUEBAS DE PENETRACION A SISTEMAS

"No basta saber cómo atacar a los demás con el fuego, es necesario saber cómo impedir que los demás te ataquen a ti"

Sun-Tzu, El Arte de la Guerra

Todos a los que nos apasiona la Seguridad de la Información alguna vez nos hemos preguntado: ¿Cómo puedo atacar una vulnerabilidad o debilidad de un sistema? Algunos encuentran las respuestas en libros, conferencias, exposiciones, clases, Internet, etc. Otros, tal vez con un sentido de escepticismo, preferimos no solo escucharlo o leerlo sino probarlo, es decir, crear escenarios en donde se pueda simular un ataque real a un sistema, principalmente para aprovechar una vulnerabilidad o debilidad del mismo.

Lo anterior se vuelve un proceso adictivo producto de la adrenalina que comúnmente fluye cuando de manera exitosa se obtiene un "shell" de "root" remoto (sin menospreciar un "shell" de "usuario local" del sistema), se logra ejecutar código arbitrario de manera remota, se escalan privilegios, se encuentra un usuario y contraseña en lo más recóndito de una red corporativa y resulta ser que son 1 as credenciales del administrador del E RP, se entiende 1 a tecnología y se aprovechan sus debilidades, se inserta un caballo de troya o puerta trasera, se manipulan datos en un consulta a una base de datos ("SQL injection"), se evade un firewall o detector de intrusos, se demuestra que u na i nfraestructura es falible a pesar de fuertes controles, entre otros. Y como cualquier adición siempre se quiere más, por lo que el proceso de aprendizaje es intenso, permanente y desafiante.

Aunque lo anterior es muy gratificante, solo es de utilidad si se analizan las posibles soluciones o controles para mitigar su impacto. Es decir, ahora el reto es hacer cambios a las configuraciones, modificar parámetros, reconfigurar un mecanismo de control, incorporar un nuevo mecanismo de control, instalar una actualización por parte del proveedor, entre otros, y volver a simular el ataque .

•

72

Como resultado de tres años de pruebas de penetración en ambientes reales, operativos y críticos en organizaciones de nivel medio y alto ( en sectores financiero, gubernamental, telecomunicaciones, farmacéutico y manufactura), podemos expresar las siguientes cifras que son el sustento del modelo propuesto en el siguiente capítulo y base de los resultados obtenidos en éste:

o Más de 600 sistemas evaluados o Más de 65,000 usuarios (total de usuarios que utilizan los sistemas evaluados) o Más de 25 proyectos o Más de 12 Sistemas Operativos evaluados (AIX, HP-UX, Solaris, Linux, SCO Unix,

FreeBSD, Windows NT 4.0, Windows 2000, CISCO IOS, OS/400, OS/390 y Open VMS) en varias versiones de la mayoría de ellos.

A continuación se presentan los 1 O escenarios más comunes encontrados en proyectos que conjugan tanto pruebas de penetración como análisis de vulnerabilidades. Es importante mencionar que de estos proyectos el 80 por ciento involucró pruebas externas (es decir, desde Internet hacia los sistemas expuestos) y el 100 por ciento pruebas internas.

3.1 ESCENARIO# 1 - OBTENCION DE CUENTAS VALIDAS (A TRA VES DE NETBIOS, FINGER, SMTP, SNMP) Y CONTRASEÑAS TRIVIALES

Uno de los primeros pasos en cualquier metodología de penetración de sistemas es identificar los servicios en red que pueden entregar información sensitiva del sistema como lo son las cuentas de usuario válidas. Algunos de estos servicios en red son N etBIOS (puerto 137-UDP, "NetBIOS Name Service"), finger (puerto 79 - TCP, simplemente con @dirección_IP), SMTP (puerto 25 -TCP, utilizando los comandos VRFY y EXPN), SNMP (puerto 161 - UDP, utilizando comunidades por omisión como "public" y "private").

Una vez obtenidas las cuentas válidas en un sistema pueden ser utilizadas para iniciar un ataque de diccionario o fuerza bruta, es decir, adivinar su contraseña utilizando un conjunto de las más utilizadas (método más común) o intentando cada una de las posibles contraseñas. Esto quiere decir que solamente necesitaremos adivinar la contraseña porque el nombre de usuario ya se obtuvo. Es importante señalar que esta técnica funciona aunque no se tengan servicios en red como los mencionados que nos entreguen las cuentas de usuario ya que comúnmente se encuentran activas cuentas con nombres genéricos como: soporte, http, apache, respaldo, nombre_de_la_compañía, oracle, crm, backup, soptec, sun, cisco, guest, setup, manager, mgr, pe, usuario, consola, console, user, admin., demo, test, tools, invitado, pub, grupo, util, system, sys, fwadmin, download, desarrollo, unlock, key, develop, auditor, tivoli, operacion, supervisor, monitor, emergencia, operador, nobody, anonymous, ibm, qsysopr, fax, mail, exchange, smtp, secofr, etc., y las que nunca fallan: "root", "qsecofr" y "administrator" (o en la versión en español de Windows NT y Windows 2000 "administrador") .

1

•

73

Es importante señalar que el método de identificación y autenticación más utilizado hoy en día es a través de nombre de usuario y contraseña. El nombre de usuario, por lo general, es asignado por el administrador de sistema de acuerdo a cierto estándar (si es que existe). Por ejemplo, la primera letra del nombre más el apellido paterno, con algunas reglas adicionales en caso de repeticiones. A su vez, la contraseña es elegida por el usuario, sin embargo, en esta elección pocas veces o nunca se establece un mecanismo para que las elija de manera robusta (por ejemplo: mínimo 8 posiciones, minúsculas y mayúsculas, 2 caracteres especiales). Por lo que basta encontrar un servicio en red como Telnet, SSH, SMB, FTP, etc. que solicite autenticación vía usuario y contraseña, para iniciar un ataque de diccionario utilizando una combinación de nombre de usuarios y contraseñas.

Es importante señalar que en una organización esta técnica permitió ganar acceso a más de 100 sistemas de criticidad media y alta. Se puede decir que es una técnica infalible porque en todos los proyectos ha funcionado por 1 o menos u na ocasión, probablemente no en sistemas de a Ita criticidad pero si de media y baja.

Este escenario es grave en ambientes Microsoft (Windows NT y Windows 2000) ya que es muy común que se asignen varias cuentas con privilegios de administración ( equivalentes a "administrator"), por lo que con solo una que tenga contraseña débil se podrá tomar control total del sistema.

Es frustrante reconocer que este método funcione y lo señalo porque el profesional en penetración de sistemas, por lo general, está buscando escenarios que logren retar su capacidad técnica e intelectual.

Lo anterior nos lleva a concluir que el usuario es el eslabón más débil en la cadena de la seguridad de la información y que las políticas y procedimientos sirven de poco o nada ( en caso de que existan) si no se implantan y se monitorea su cumplimiento. Asimismo, debemos reconocer que las políticas y procedimientos implantadas y monitoreadas son vitales e indispensables para la seguridad de la información y que el programa de conciencia de seguridad de la información debe tener un alcance corporativo, es decir, aplicable a todos los empleados de una organización. Finalmente, debemos aceptar que se nos está olvidando lo básico por pensar en las supuestas "técnicas avanzadas y modernas de protección", seguimos pensando en tecnología cuando se habla de seguridad de la información, cuando ésta también involucra los factores GENTE Y PROCESOS. Basta con señalar que gran parte de la información sensitiva de una organización puede estar o ponerse en riesgo con tan solo fallar en uno de los elementos más básicos de la seguridad de la información: Control de Acceso.

Adicionalmente, podemos señalar que las organizaciones carecen de un procedimiento de auditoria de contraseñas (por ejemplo, con herramientas como john the ripper y LC4) que permita monitorear el cumplimiento o violaciones de políticas sobre control de acceso. Poco se han preocupado las organizaciones en definir estándares mínimos de configuración que le de certeza que solo se tienen activos los servicios en red que son necesarios para la operación de los sistemas y que se tenga una configuración razonablemente protegida .

•

74

3.2 ESCENARIO# 2 - USO DE PROTOCOLOS NO CIFRADOS

Para este escenario se tuvo como meta el penetrar un equipo con sistema operativo AIX 4. 3, el cual solo tenía los puertos 21 (ftp) y 23 (telnet) abiertos, por cierto no vulnerables. Iniciamos por intentar acceder vía contraseñas triviales sin lograr ningún éxito.

Este es uno de los escenarios que cualquier profesional quisiera encontrarse (por el desafio) ya que aparentemente la única debilidad era el uso de protocolos no cifrados como telnet y FTP. Después de evaluar que ambos servicios en red efectivamente no son vulnerables continua el paso de plantear otras rutas de ataque. En el mismo segmento se encontraban dos servidores Linux Red Hat 7 .3 aparentemente con funciones de desarrollo (bingo!), también con los servicios de FTP y telnet activos, la contraseña de "root": desarrollo ( el desafio había concluido demasiado rápido). Una vez que se logró acceso a éste se instaló el sniffer sniffit configurado de tal manera que únicamente capturara contraseñas de los servicios en red telnet y ftp enviadas al sistema objetivo HP-UX. Se dejó dicho sniffer toda una noche. Al siguiente día se había capturado la contraseña del usuario "root" a través del servicio FTP, el cual era utilizado para iniciar una tarea de respaldo programada todos los días a las 3:00 a.m. Efectivamente la contraseña era robusta, esto lo señalo, porque hubiera sido prácticamente imposible adivinarla en el tiempo asignado al proyecto, era de 8 posiciones con caracteres especiales, minúsculas y mayúsculas. Los graves errores de este escenario fueron:

1. Utilizar protocolos no cifrados 2. Tener equipos de desarrollo en segmentos productivos y expuestos a Internet 3. Permitir que "root" se firmara de manera remota 4. Realizar respaldos con la cuenta "root" 5. Pensar que la seguridad de un sistema solo depende de ese sistema y no de toda una

infraestructura incluyendo tecnología, procesos y gente. 6. Abrir a todo Internet el acceso a telnet y FTP, en lugar, de solo a ciertas direcciones IP

que así lo requirieran.

Este es solo un ejemplo, sin embargo, es importante mencionar que en el 100 % de las organizaciones evaluadas se encontró el uso de protocolos no cifrados (incluyendo en la mayoría telnet y FTP), solo en se encontraban en proceso de migración hacia SSH pero continuaban manteniendo activos los tres (SSH, telnet, FTP).

Lo anterior nos lleva a concluir que la seguridad de la información debe analizarse de manera integral, las rutas de acceso a un sistema pueden ser muchas y variadas. Solo con un análisis de riesgos profundo se podrán identificar situaciones que pueden comprometer la seguridad de la información de una organización. Adicionalmente, podemos señalar que el uso de protocolos o servicios de red no cifrados sigue siendo el estándar en muchas organizaciones a pesar del grave riesgo que representan, esto aunado a la ausencia de segmentación de redes para ambientes productivos y de desarrollo como práctica común en las organizaciones ocasionando el riesgo de

75

que por las débiles medidas de control de los equipos de desarrollo sirvan de puente hacia los sistemas productivos. Finalmente, podemos establecer que no existen sistemas razonablemente seguros sino infraestructuras razonablemente seguras ya que la seguridad de la información es una cadena de factores y elementos de la cual el atacante siempre intentará encontrar la más débil.

3.3 ESCENARIO# 3 - ARCHIVOS DE CONTRASEÑAS CON PERMISOS DE LECTURA PUBLICA (CASO HP-UX)

Desde 1988 cuando AT &T y Sun Microsystems firmaron un acuerdo para desarrollar una nueva versión de UNIX denominada System V Release 4 (SRV4) basada tanto en el UNIX de Berkeley como el System V incorporaron el archivo /etc/shadow para proveer un línea de defensa adicional al archivo /etc/passwd cuya principal debilidad identificada era que debía tener permisos de lectura pública, siendo esto delicado porque ahí se encontraban las contraseñas cifradas de todos los usuarios. ¿ Y porqué es esto grave?, por que implicaba que todos 1 os usuarios del sistema podían leer dicho archivo (/etc/passwd) y someterlo a un ataque de diccionario y/o de fuerza bruta para intentar recuperar las contraseñas en texto claro. La nueva línea de defensa, el archivo /etc/shadow, ahora sería quien alojaría las contraseñas cifradas y solo "root" podría leerlo, limitando así su acceso.

Todo este preámbulo para señalar que 16 años después, es decir, en el 2004 todavía existe una gran cantidad de equipos con sistema operativo HP-UX 10.20 el cual no utiliza el archivo /etc/shadow, por lo que basta lograr acceso con una cuenta sin privilegios (talvez soporte, y contraseña soporte, por dar un ejemplo) para que en un porcentaje elevado se pueda obtener la contraseña de "root" a través de someter el archivo /etc/passwd a un ataque de diccionario y fuerza bruta con una herramienta como "john the ripper". Hemos dejado corriendo dicha herramienta en archivos /etc/passwd por más de 1 O días y ha logrado recuperar contraseñas del tipo: #4j_akt.

En más de una ocasión las contraseñas encontradas de las cuentas de usuario de estos sistemas (HP-UX 10.20) han servido para acceder a otros. Es decir, si la contraseña de "root" del equipo con HP-UX 10.20 es "#4j_akt", es altamente probable que también sea la contraseña de "root" de otros equipos UNIX y hasta la de "administrator" de otros sistemas con plataformas operativas Windows NT/2000.

Con lo anterior podemos concluir que no se ha entendido el riesgo de situaciones triviales como la ausencia del archivo /etc/shadow, sin embargo, nos siguen vendiendo "nuevas tecnologías" supuestamente infalibles. Asimismo, podemos señalar que las políticas de contraseñas brillan por su ausencia en la mayoría de las organizaciones, provocando que la primera línea de defensa que otorga el control de acceso sea prácticamente nula. Preferimos utilizar elementos externos y herramientas adicionales al sistema operativo cuando podríamos explotar gran cantidad de elementos y funcionalidades de seguridad del mismo. También podemos señalar que lo que empieza mal, mal acaba y esto lo digo porque la justificación de muchos administradores ha sido

1

76

que cuando intentan llevar HP-UX 10.20 a trusted system las aplicaciones que soporta dicho sistema "truenan". La pregunta es: ¿Por qué decidir desde un principio desarrollar en una plataforma poco segura? Finalmente, la única manera de asegurar un sistema y una infraestructura es conociendo los riesgos de la tecnología utilizada, sus debilidades y fortalezas. Nuevamente el factor GENTE es vital y estratégico para la seguridad de la información.

Por cierto, alguna vez un administrador de HP-UX comentó que su contraseña era casi irrompible porque era de 14 posiciones, con minúsculas, mayúsculas y caracteres especial y además fácil de recordar por lo que jamás tendría la necesidad de escribir en "un papelito", algo del estilo: hpuxadmin&roOt. Lo que este administrador no sabía es que el sistema operativo solo tomaba los primeros 8 caracteres!!! Es decir su "supercontraseña" infalible se convertía en 1 a paupérrima contraseña hpuxadmi para el supersistema operativo. Esto de truncar a 8 caracteres no es exclusivo de HP-UX, sino de varios UNIX y otros sistemas operativos.

3.4 ESCENARIO# 4 - APROVECHAMIENTO DE RELACIONES DE CONFIANZA (PRINCIPALMENTE A TRA VES DE SERVICIOS R)

El comando rlogin (cliente) y rlogind (servidor) permiten terminales remotas similares al servicio telnet. A diferencia de éste, rlogin puede no solicitar una contraseña para permitir el acceso al sistema si es que se tiene establecida una relación de confianza. Un escenario típico es encontrar que existan relaciones de confianza entre varios equipos de una infraestructura, la mayoría de las ocasiones configurado de esta manera para facilitar el trabajo de administración y también para reducir el número de contraseñas utilizadas.

Lo anterior representa un grave riesgo para la infraestructura ya que con solo lograr acceso a uno de los sistemas que participan en el esquema de relaciones de confianza se podrá acceder a todos. Por ejemplo:

Sistema A con dirección IP 192.168.1.1 dentro de su hosts.equiv:

192.168.1.2 + 192.168.1.3 + 192.168.1.4 + 192.168.1.5 + 192.168.1.6 + 192.168.1.7 + 192.168.1.8 +

Lo anterior implica que desde las direcciones IP 192.168.1,2, 192.168.1,3, 192.168.1.4, 192.168.1.5, 192.168.1.6, 192.168.1.7, 192.168.1.8 cualquier usuario podrá acceder al sistema con dirección IP 192.168.1.1. Lo más común es que este archivo sea replicado de igual forma a todos los demás con lo cual el acceso entre ellos es transparente ( es decir, no se requiere ingresar

•

..

•

77

un nombre de usuario y contraseña). Desde el punto de vista de un atacante, con solo acceder a uno de estos 8 equipos se habrá comprometido la seguridad de todos.

Lo anterior aplica para todos los usuarios del sistema excepto "root", por lo que alguien podría decir cuestionar si verdaderamente se ha comprometido "completamente" la seguridad del sistema. Mi respuesta es que cuando se encuentra la configuración anterior en un porcentaje muy alto también se encuentra en el archivo -/.rhosts del usuario root la misma lista de direcciones IP acompañadas del símbolo + con lo cual inclusive el usuario "root" puede firmarse desde cualquiera de dichas direcciones. Si este no fuera el caso, existen gran cantidad de vulnerabilidades locales que pueden ser utilizadas para escalar privilegios y no solo vulnerabilidades sino también configuraciones inadecuadas como permisos públicos de lectura, escritura y ejecución en tareas programadas, por mencionar solo una.

La situación más grave presentada a este respecto, fue en una organización en la cual solo se requirió "adivinar" la contraseña de una cuenta genérica (soporte/soporte) para poder acceder a 14 equipos, en los cuales existía el archivo .rhosts en/ con la siguiente información:

++ 10.192.2.203 root 10.192.2.204 root 10.192.2.193 root 10.192.2.194 root 10.192.2.195 root 1O.192.2.196 root 10.192.2.198 root 10.192.2.199 root 10.192.2.200 root 10.192.2.201 root 10.192.7.129 root 10.192.7.130 root 10.192.7.131 root 10.192.7.132 root

El tema de las relaciones de confianza no es exclusivo de ambientes UNIX, también es ampliamente explotado en ambientes Windows NT/2000. De hecho, se podría decir que es todavía más grave en estos últimos ya que las relaciones de confianza se asignan a nivel dominio (es decir, un conjunto de recursos dentro de una infraestructura) y no solo a un cierto sistema. Finalmente, es importante señalar que también es una de las mejores puertas traseras que un atacante puede dejar (esta técnica también es muy utilizada por los ex administradores) ya que es fácil de configurar y dificil de detectar en ambientes complejos.

Lo anterior, nos permite concluir que facilitar el trabajo de los administradores poniendo en riesgo la seguridad de la información no es una buena estrategia, sin embargo, es muy utilizada. Asimismo, podemos señalar que las relaciones de confianza, si es que son requeridas por aplicativos críticos del negocio, tendrán que ser analizadas para entender todas las posibles rutas

•

•

78

de acceso que están abriendo y también tendrán que ser monitoreas de cerca. Un simple "+" dentro del u ni verso de información y configuraciones de un sistema puede poner en riesgo 1 a seguridad de la información de una organización. Adicionalmente, la falta de políticas y procedimientos que especifiquen lo que un usuario debe hacer y como lo debe hacer, así como el monitoreo de su cumplimiento es esencial para evitar que realicen configuraciones no autorizadas y riesgosas. Finalmente, podemos concluir que la seguridad de la información tiene un costo que en muchas ocasiones los administradores prefieren no pagar, por lo que la conciencia y entrenamiento de seguridad de la información debe ser uno más de los temas que los administradores deben dominar o por lo menos considerar y entender.

3.5 ESCENARIO# 5 - CONTRASEÑAS DENTRO DE CODIGO CON PERMISOS DE LECTURA PUBLICA

Un caso típico de debilidad perimetral es cuando las contraseñas de acceso con privilegios de administración se encuentran en texto plano dentro de un programa que puede ser accedido desde Internet. El caso más grave de este estilo fue cuando encontré vía http ( es decir, en un servidor de web) dentro de un archivo de nombre site.csc el texto:

yyyyyyyyyyyyyyyyyyyyyyyy yyyyyyyyyy yy UID=sa; PWD:dbwinnee yyyyyyyyyyyyyyyyy yyyyy

El siguiente paso fue intentar acceder al puerto 1433 de MS-SQL en un servidor también expuesto utilizando el nombre de usuario "sa" y contraseña "dbwinnee", el acceso a la base de datos se había logrado.

Este escenario es todavía más típico en ambientes internos en los cuales una práctica común de la mayoría de los desarrolladores (quienes, por cierto, no son los más concientes en materia de seguridad de la información, tal vez esta sola frase, sea la responsable de gran parte de los problemas actuales en esta m atería) es incorporar en e 1 código de sus aplicaciones usuarios y contraseñas, cuando con herramientas simples o decompiladores pueden encontrarse los caracteres ASCII o UNICODE dentro de un ejecutable.

Podemos concluir de acuerdo a lo presentado que los desarrolladores de software pueden convertirse en los mayores habilitadores para un negocio o pueden ser los primeros que pongan en riesgo toda una infraestructura. Si quisiéramos empezar a resolver parte del problema actual de la inseguridad de la información tendríamos que empezar por la raíz: prácticas inadecuadas de programación y desarrollo. Finalmente podemos señalar que la conciencia de seguridad de la información es muy importante para administradores y usuarios, pero esencial para desarrolladores .

•

79

La siguiente es una frase de William Cheswick y Steve Bellovin de su libro "Firewalls and Internet Security" [28] que resume lo anterior:

" ... any program, no matter how innocuous it seems, can harbor security holes ... We thus have a firm beliefthat everything is guilty until proven innocent."

Como complemento, John Viega y Gary McGraw en su libro "Building Secure Software. How to Avoid Security Problems the Right Way" [29] señalan:

"There are man y excellent software developers and architects ... The problem is that although these developers and architects are world class, they have not had the opportunity to leam much about security at all".

3.6 ESCENARIO# 6 - VULNERABILIDADES FACILMENTE EXPLOTABLES DE MANERA REMOTA

Existe una gran cantidad de aplicaciones en red ampliamente difundidas, principalmente para servicios de Internet como lo son correo electrónico, páginas web, servicio de nombres, transferencia de archivos, ejecución de comandos remotos, por mencionar algunas las cuales cuentan con una larga historia de vulnerabilidades reportadas. Es importante mencionar, que estas vulnerabilidades pueden estar presentes en toda clase de software, sin embargo, se vuelven de mayor riesgo cuando se presentan en software que pemüte comunicación vía la red, probablemente utilizando "sockets", y todavía es mayor el riesgo cuando dicha aplicación es ampliamente utilizada, como por ejemplo: Sendmail, Apache, IIS, bind, MS-SQL, Oracle, MS­Exchange, OpenSSH, Telnet, Qpopper, MS-Frontpage, Netscape Enterprise, Macromedia ColdFusion, iPlanet, Lotus Domino, Tomcat, PHP, por nombrar solo algunas.

Es este tema en donde mayor énfasis junto con los virus (mejor llamados código malicioso) pone la industria relacionada con seguridad de la información (¿será que producto de este énfasis poca atención se pone a los temas de fondo como políticas y procedimientos, análisis de riesgos, control de acceso, continuidad del negocio, cifrado, mecanismos de integridad, por mencionar algunos?) a sí corno 1 os propios medios de comunicación. De hecho hoy en día, 1 as amenazas combinadas, mejor conocidas como gusanos aprovechan vulnerabilidades en las aplicaciones en red para propagarse y continuar atacando otros sistemas conectados a la red.

A continuación presento algunas de las vulnerabilidades más comunes y más utilizadas para ganar acceso no autorizado a un sistema o para elevar privilegios:

o IIS 5.0 IPP ISAPI o IIS 4.0 y 5.0 UNICODE o IIS 4.0 MDAC 1.5, 2.0, 2.1 o Telnet en Solaris 7 y 8

..

80

o wu-ftpd 2.6.0 o sadmind en Solaris 2.6 y 7 o rpc.statd/automountd en Solaris 2.6 y 7 o rpc.ttdbserverd en Solaris 2.6, HP-UX 10.20 y AIX o rpc.cmsd en Solaris 2.6 y 7 o Apache chunked o Inyección de SQL en aplicaciones web o cu HP-UX 11.0 o ftpd en AIX 4.3 y 4.3.x o locale en Solaris 2.6 y 7

La lista puede ser interminable si incluimos todas aquellas vulnerabilidades que pueden ser aprovechadas de manera local ( es decir, contar con una cuenta local del sistema o aplicación), o si incluimos aquellas aplicaciones o sistemas operativos no tan comunes como los mencionados aquí.

Es importante señalar que este escenario, aunque uno de los más citados, es solo uno más de los que permiten comprometer la seguridad de una infraestructura. Comúnmente, se utilizan en combinación con otras debilidades para comprometer las partes más sensitivas de toda una infraestructura. Es importante señalar que muchos de estos códigos que explotan alguna vulnerabilidad pueden tener una edad considerable, talvez dos o tres años. También es esencial comentar que muchos de estos códigos deben analizarse línea por línea para entenderlos y garantizar que ellos mismos no están realizando operaciones que pueden comprometer nuestro propio sistema de prueba. Esto también sirve porque en muchas de las ocasiones se tienen que hacer adecuaciones al código para que funcione bajo nuestro ambiente de evaluación. Aún analizando el código es muy deseable el ejecutar dicho código en un ambiente de pruebas antes de hacerlo en cualquier ambiente productivo ya que es muy probable que este puede llegar a comportarse de manera errática. De hecho, la mayoría de las organizaciones prefieren que ese tipo de códigos se ejecuten solo en sus propios equipos de prueba que son espejo de los productivos.

Salvo los desarrollos internos, la mejor manera de resolver esta situación no es necesariamente a través de la ejecución de un código sino de la aplicación de una actualización de seguridad, y más que esto, de fondo lo que puede resolver más estratégicamente esta situación es una adecuada política y procedimiento de actualización de "parches" y versiones, donde se contemple el que una vez emitida la alerta por el proveedor o por el grupo que la descubrió se proceda a evaluar el impacto que puede llegar a tener utilizando un ambiente de pruebas, al mismo tiempo se sugiere tomar medidas preventivas como limitar accesos o instalar firmas de los posibles ataques en los detectores de intrusos, así como mantenerse alerta en caso de que cualquier incidente se presente. Complementando lo anterior con una adecuada política y procedimientos de respaldo y de respuesta a incidentes.

Como se mencionó anteriormente, salvo los desarrollos internos, porque la auditoria del código la tendrá que hacer la propia organización o con la ayuda de un tercero, que en este caso, puede ser un equipo de penetración de sistemas especializado en auditoria de código. En dicha auditoria,

t

81

similar a lo que se hace con inyecciones de SQL, se analizan posibles deficiencias en la programación como ausencia de validación de parámetros de entrada. Estas evaluaciones tienen un mayor grado de complejidad que aquellas de aplicaciones conocidas.

Con lo anterior podemos concluir que detrás de una vulnerabilidad hay una gran cantidad de factores relaciones con la seguridad de la información. Aprovechar vulnerabilidades ya sea remotas o locales es una de las técnicas más comunes para comprometer una infraestructura con controles débiles. Asimismo, salvo vulnerabilidades que quien las descubre no las hace públicas y los conocidos como "zero-day exploits", es un problema que solo puede solucionarse con políticas y procedimientos relacionadas con "parches" de seguridad emitidos por los proveedores así como actualización de versiones, análisis de riesgos, conciencia y entrenamiento de seguridad. A pesar del ruido mediático y el impacto provocado por ]_as recientes amenazas combinadas (gusanos), poca conciencia se ha hecho referente a la necesidad de "parchar" los sistemas, prueba de esto son los gusanos como Blaster, SoBig, Slammer, por citar solo algunos, que aprovechaban vulnerabilidades reportadas con varias semanas y en algunos casos con vario_s meses de anticipación. Adicionalmente, podemos establecer que deben tomarse medidas a este respecto porque cada día estos gusanos son "liberados" en fechas más cercanas a la emisión del "parche" por parte del proveedor. De hecho, sobre el comunicado MS04-11 emitido por Microsoft el 13 de abril de 2004, solo dos días después ya empezaban a circular algunos códigos que podían aprovechar las vulnerabilidades ahí descritas (por cierto, en total 14, aunque parezca broma no lo es). Finalmente, podemos señalar que en general, los sistemas expuestos a Internet de las organizaciones tienen un nivel razonable de seguridad, sin embargo, los sistemas internos que casi siempre son los verdaderamente críticos cuentan con pocas medidas de control y seguridad.

3.7 ESCENARIO# 7- REDES INALAMBRICAS ABIERTAS O SEMIABIERTAS

Cada día es más común, por razones de bajo costo, rapidez de instalación y comodidad, la instalación de redes inalámbricas dentro de las organizaciones. Desafortunadamente éstas, como la mayoría de los sistemas, con el afán de facilitar la instalación y permitir una conexión casi inmediata pueden estar poniendo en riesgo a toda una infraestructura. Lo anterior debido a que en una instalación por omisión de un "punto de acceso inalámbrico" ("access point") no se habilitan los mecanismos de seguridad corno W EP ( Wired E quivalent P rivacy), WP A ( Wi-Fi P rotected Access), filtrado de dirección MAC, inhabilitación de "broadcast" de SSID, entre otros, además de mecanismos adicionales como utilización de cifrado a través de VPN, SSH, SSL, etc. con lo cual las ondas electromagnéticas que se propagan y que contienen la inforn1ación de la organización están expuestas a que puedan ser interceptadas y por lo tanto poner en riesgo su seguridad. Adicional al riesgo de interceptar comunicaciones un punto de acceso inalámbrico mal configurado abre las puertas para que un atacante se conecte a esa red pudiendo ser mayor el grado de afectación. Por ejemplo, en lugar de tener que pensar como podrá comprometer la seguridad de un sistema expuesto a Internet y después desde este saltar hacia una red interna, el punto de acceso inalámbrico puede ahorrarle todas estas tareas y permitirle conectarse directamente a la red interna.

•

82

En un recorrido rápido por la Ciudad de México se encontraron más de 180 puntos de accesos con una tarjeta de red inalámbrica común y corriente (hago esta aclaración porque no utilicé ningún tipo de antena que permitiera una mayor ganancia y por tanto una mayor área de cobertura) de los cuales casi el 80 por ciento no tenían habilitado WEP o WP A.

Referente a este escenario, en alguna ocasión se solicitó realizar una evaluación de los sistemas expuestos a Internet de una organización. Siendo honesto, solo se habían identificado en ellos unas cuantas debilidades de riesgo bajo que no permitían más allá de la lectura de algunos archivos medianamente sensitivos lo cual nos hablaba de un perímetro razonablemente protegido. Sin embargo, algunos meses antes la organización había decidido probar las "ventajas" de la tecnología inalámbrica producto de un análisis que les había llevado a una reducción de costo del 75 por ciento en comparación con la tecnología alámbrica. Los puntos de acceso habían sido configurados con un SSID que no era el instalado por omisión (ej.: linksys, comcomcom, tsunami, intel, compaq, wlan, wireless, entre otros) ya que el administrador pensaba que éste era un tipo de llave con lo cual solo quien supiera el SSID podría conectarse a su red. Grav~ error porque tenía habilitado el "broadcast" de SSID con lo cual cualquiera podía conocer su supuesta "superclave". Adicional a esto, como pasa en un porcentaje muy alto, se tenía habilitada la asignación dinámica de direcciones IP (DCHP) por lo que una vez lograda la comunicación (asociación) con el punto de acceso (capa 2) también había logrado la obtención de una dirección IP (capa 3). La tarea posterior ya era sencilla porque los controles internos (a diferencia de aquellos de los sistemas expuestos) eran escasos.

Podemos concluir que la mejor manera de proteger una infraestructura es tener gente capacitada que conozca a fondo la tecnología utilizada así como sus riesgos. A su vez, la mejor manera de poner en riesgo una infraestructura es con la escasez de entrenamiento. No olvidar que la Seguridad de la Información involucra a tres universos: Tecnología, Procesos y Gente. Asimismo, podemos señalar que las políticas y procedimientos, utilización de protocolos cifrados y los controles de acceso robustos son solo algunos elementos indispensables con la evolución y difusión de la tecnología inalámbrica, ya sea que se utilice o no, esto debido a que será dificil detectar un punto de acceso inalámbrico que haya sido instalado de manera no autorizada ya sea por un empleado descuidado o mal intencionado o por un atacante exponiendo la infraestructura hacia el exterior. Con el abaratamiento y facilidad de uso de la tecnología inalámbrica en solo unos minutos una infraestructura puede ser comprometida, por lo que no siempre lo más fácil y sencillo es lo más seguro. Finalmente, es indispensable establecer que deben tenerse controles rígidos en el perímetro (exterior) e igualmente rígidos o superiores en el interior (depende de la organización, pero en la mayoría de los casos la verdadera información sensitiva está en el interior). No estamos de acuerdo con el viejo dicho: "crunchy exterior, chewy interior".

3.8 ESCENARIO # 8 - TUNELEO VIA SSL (EV ASION DE NIDS)

Una de las técnicas favoritas y ampliamente difundidas es el "tuneleo" de protocolos, por ejemplo, enviar datos de http, pop3 o smtp (por mencionar algunos) a través de un túnel de SSL.

•

83

Y digo que es de las favoritas porque es la manera más sencilla de evadir un detector de intrusos basado en red (NIDS). Es común que la información publicada en un servidor de web sea accesible tanto vía http como https, con lo cual a través de nuestro túnel de ssl podremos enviar nuestros ataques que al viajar encriptados no son identificados por el NIDS. Si el servidor de web fuera, por ejemplo, 1 IS vulnerable en MDAC (Microsoft Data Access C omponents), se podria enviar la siguiente petición:

http://192.168. l. l/ .. %c0%af . ./winnt/system32/tftp.exe+"-i"+ 192.168.2.1 +GET+nc8 l .exe+c:\winnt\system32\nc81.exe

La mayoría de los NIDS podrían identificar lo anterior. Sin embargo, al enviarlo por https, la identificación no sucederá. Comúnmente los "scripts" o herramientas para auditoria de web están programados para funcionar a través de http y no https, por lo que esta técnica de tuneleo puede ser de gran utilidad. Lo anterior se vuelve más critico cuando en lugar de atacar al propio servidor de web con alguna vulnerabilidad de este estilo, atacamos la aplicación web que es alojada en éste, ya que las transacciones y peticiones que hagamos no podrán ser identificadas por lo menos a nivel red, por ejemplo, un ataque de diccionario o fuerza bruta sobre un esquema de autenticación, inyecciones de SQL, modificaciones de "cookies", entre otros. Los programas más utilizados para esta técnica de tuneleo son stunnel y sslproxy.

Existen otras técnicas de evasión de NIDS, una de ellas también muy utilizada es a través de la codificación de caracteres ASCII en sus representaciones hexadecimales, por ejemplo:

GET /scripts/ .. %cl %1c . ./winnt/system32/cmd.exe?/c+dir HTTP/1.0

puede ser transformada en:

GET /% 73%63% 72%69% 70% 74% 73/%2E%2E%25%63%31 %25%31 %63%2E%2E/% 77%69%6E% 6E%74/%73%79%73%74%65%6D%33%32/%63%6D%64%2E%65%78%65%3F/%63%2B%6 4%69% 72 HTTP/1.0

donde:

scripts = %73%63%72%69%70%74%73 .. %c 1 % 1 c .. = %2E%2E%25%63%31 %25%31 %63%2E%2E winnt = %77%69%6E%6E%74 system32 = %73%79%73%74%65%6D%33%32 cmd.exe? = %63%6D%64%2E%65% 78%65%3F c+dir = %63%28%64%69% 72%20

Esto lleva a concluir que la criptografia, aunque es un excelente mecanismo de protección de la integridad, confidencialidad y autenticación de la información, puede provocar debilidades si no se analizan sus posibles riesgos. Adicionalmente, podemos señalar que los mecanismos de detección de intrusos en red son solo un elemento más dentro del esquema de seguridad de una infraestructura, no hacen excluyentes a los mecanismos de detección de intrusos locales o de

84

host. Los actuales mecanismos de detección de intrusos están basados en huellas o firmas, por lo que basta modificar en muchas ocasiones un solo bit para evadirlos. Nuevamente, con este escenario se confirma que la mejor manera de proteger una infraestructura es tener gente capacitada que conozca a fondo la tecnología utilizada así como sus riesgos.

3.9 ESCENARIO# 9 - HERRAMIENTAS DE ADMINISTRACION REMOTA (VNC, CITRIX, TERMINAL SERVICES, PC ANYWHERE)

Las herramientas de administración remota son elementos ampliamente utilizados en la mayoría de las infraestructuras medianas y de alto nivel debido mucho a las restricciones de seguridad fisica que se tiene en sus centros de cómputo. Sin embargo, el control de acceso a nivel red de éstas herramientas pocas veces (y me atrevo a decir que nunca) está restringido, es decir, cualquier usuario conectado a la red de la organización puede tener acceso por lo menos a la pantalla inicial que solicita nombre de usuario y contraseña. Por lo que adicional a los ya tradicionales servicios telnet y SSH se podrá acceder al sistema vía otras herramientas como lo son VNC (Virtual Network Computing), Citrix, PC Anywhere, Exceed (Xwindow) y Terminal Services, por nombrar algunos, abriendo así las posibilidades de entrada al o los sistemas.

En el caso particular de Terminal Services y Exceed, una vez obtenido un nombre de usuario y contraseña, por ejemplo, a través de lo descrito en el escenario # 1 se logrará tener acceso al sistema como si se estuviera en la propia consola, ocasionando así el que se puedan utilizar todas las herramientas administrativas locales. Lo menciono en particular de éstas dos (Terminal Services y Exceed), porque los usuarios que se pueden autenticar a través de ellas son usuarios del sistema operativo. En can1bio, con las demás posiblemente habrá que adivinar una nueva contraseña. De hecho VNC solicita únicamente contraseña, por lo que elimina la necesidad de adivinar el usuario (por cierto, VNC solo envía la contraseña de manera cifrado, todo lo demás lo envía en texto plano).

En varias ocasiones me ha sucedido que lograr acceso a un solo sistema a través de VNC o Terminal Services permite un entendimiento amplio de la red, por ejemplo: el número de dominios disponibles, que sistemas tienen el rol de controladores de dominio, cuales son las aplicaciones críticas (contabilidad, nómina, ventas, por nombrar algunas), además de poder utilizarlo como puente debido a las relaciones de confianza para acceder a otros sistemas.

Con lo anterior podemos concluir que las actividades de administración remota son necesarias pero deben ser estrictamente controladas tanto a nivel de red, permitiendo solo acceso a ciertas direcciones IP, y a nivel local, permitiendo acceso solo a ciertos usuarios, los cuales deberán utilizar y aplicar una política de contraseñas robusta. Adicionalmente, podemos señalar que las debilidades en el control de acceso son muy comunes y pocas veces identificadas. Finalmente, las políticas y procedimientos, su diseño, implantación y monitoreo nuevamente brillan por su importancia, aunque casi siempre no brillan debido a su ausencia.

•

85

3.10 ESCENARIO# 10 - OTRAS PUERTAS Y TECNICAS

Adicional a los escenarios presentados, algunas técnicas adicionales que han permitido conocer más acerca del ambiente evaluado (recordar el viejo adagio "la información es poder") y que por lo tanto han facilitado las vías de acceso son las siguientes:

o Transferencias de Zona en DNS. o Ingeniería social tanto fisica como utilizando correos electrónicos con remitentes

enmascarados. o Directorios compartidos a todo el mundo (everyone) a través de NFS y SMB/NetBIOS. o Accesos de lectura, escritura y ejecución a archivos de configuración de tareas

programadas como cron de UNIX y scheduler de Windows. o Acceso a interfases web de correo electrónico, principalmente OWA (Outlook Web

Access) y iNotes de Lotus Notes. o Comprometiendo sistemas dentro de una organización que pudieran parecer no críticos

utilizándolos como puente y para iniciar un mejor reconocimiento de la red interna. o Identificación de DNS a través de consultas de "whois". o Identificación de servidores de correo electrónico a través de consultas "MX" ("Mail

Exchange") de "whois". o Identificación de filtros ( como routers o firewalls) a través de trazados de ruta y

manipulación de paquetes ("packet crafting"). o Redirección de puertos para evasión de reglas en filtros ( como routers o firewalls ). o Clonación de direcciones MAC en ambientes D HCP para evadir monitoreo cuando las

pruebas se realizan desde el interior de la organización. o Acceder a recursos compartidos o al propio equipo de directores de primera y segunda

línea, en caso de que se realice la evaluación desde el interior de la organización. c:i "War dialing", si en pleno siglo XXI todavía funciona!

La mayoría de estas técnicas son útiles para complementar la información encontrada en las fases iniciales de las pruebas de penetración, las cuales comúnmente parten de un reconocimiento que involucra la identificación de sistemas objetivos, puertos abiertos y filtrados, así como las aplicaciones en red y sus versiones asociadas a dichos puertos.

Podemos concluir que son muchas y muy variadas las técnicas que pueden ser utilizadas para comprometer una infraestructura, ningún punto de acceso a la red puede dejarse sin controlar. Finalmente, podemos establecer que un atacante tiene que encontrar u na puerta de entrada, 1 a organización debe asegurarse de haber identificado todas y de haberlas controlado de manera adecuada para los fines del negocio .

•

86

3.11 CONCLUSIONES SOBRE LOS ESCENARIOS PRESENTADOS

Es importante enfatizar que los escenarios antes mencionados pueden llegar a presentarse de manera incluyente, es la habilidad, experiencia y conocimientos técnicos de quien realiza las pruebas de penetración lo que permite el ir identificando estos y otros que den la pauta para identificar las mejores avenidas o rutas de ataque. El elemento clave para esta identificación estratégica de debilidades es la metodología de penetración, solo a través de un trabajo metódico y estructurado se podrán aprovechar los tiempos asignados para cada proyecto y por lo tanto lograr comprometer la seguridad de la infraestructura asignada o identificar debilidades. La metodología de penetración propuesta es la siguiente:

o Planeación inicial. o Descubrimiento (identificación de sistemas objetivo - por lo menos, DNS, "Mail

Exchange" y www-, interrogación de puertos, identificación de aplicaciones asociadas a dichos puertos).

o Identificación de detectores de intrusos y filtros (ej. firewalls y routers) para aplicar técnicas de evasión.

o Identificación y prueba de las rutas de ataque más evidentes (principalmente debilidades en control de acceso y vulnerabilidades fácilmente explotables).

o Identificación y prueba de las rutas de ataque menos evidentes. o En caso de no lograr acceso utilizando los dos puntos anteriores, utilizar otras técnicas

como ingeniería social, reconocimiento de puntos de acceso inalámbricos o identificación de sistemas adicionales dentro del segmento asignado que puedan llegar a servir como salto ( explotando relaciones de confianza).

o Acceso local. o Escalamiento de privilegios. o Reconocimiento del sistema comprometido, identificando archivos sensitivos que puedan

brindar mayor información, relaciones de confianza, aplicaciones criticas, bases de datos. Obtención del archivo de contraseñas para intentar "obtenerlas" en texto claro vía ataques de diccionario y/o fuerza bruta.

o En caso de que se haya autorizado la instalación de puertas traseras, estas deben estar protegidas de tal manera que solo los integrantes del equipo de penetración puedan acceder a ellas.

o Utilizando el sistema comprometido volver a realizar un reconocimiento inicial en busca de más accesos o mayor información sensitiva.

o Análisis de riesgos y de causa raíz de los hallazgos identificados, es importante tomar en cuenta no solo el factor tecnología sino también los factores: procesos y gente.

o Análisis de contramedidas para mitigar las avenidas de acceso identificadas. o Documentación - no es la última fase, es una fase que está presente en todas desde el

pnnc1p10. o Muy deseable, pero pocas veces realizado, volver a realizar pruebas para tener certeza que

las causas raíz que originaron los accesos han sido mitigadas. Convirtiéndose con esto un ejercicio periódico dentro del programa de seguridad de la información de una organización - (comúnmente denominadas pruebas recurrentes) .

CAPITUL04

MODELO PROPUESTO DE PROTECCION EN BASE A ANALISIS DE RESULTADOS EN PRUEBAS DE PENETRACION A SISTEMAS

87

"La victoria completa se produce cuando el ejército no lucha, la ciudad no es asediada, la destrucción no se prolonga durante mucho tiempo,

y en cada caso el enemigo es vencido por el empleo de la estrategia ". Sun-Tzu, El Arte de la Guerra.

De poco o nada serviría la exposición y análisis de los 1 O escenarios citados en el capitulo anterior, así como las conclusiones de cada uno de ellos si no se propone un modelo que con base en las debilidades identificadas pueda servir como punto de partida para asegurar una infraestructura.

El modelo propuesto se divide en dos partes principales:

1. Enfoque Técnico 2. Enfoque Normativo y Corporativo

Se han separado de esta manera debido a que en nuestra experiencia el análisis, desarrollo, diseño, implantación y monitoreo de cumplimiento de la normatividad (Políticas y procedimientos) puede llevarse varios meses o inclusive años por lo que las organizaciones requieren también de soluciones técnicas de corto plazo que puedan ser implantadas con mayor rapidez. Es importante mencionar que esta separación no implica un proceso secuencial, es decir, se pueden realizar en paralelo asumiendo que las cuestiones técnicas tendrán que ser alineadas con los elementos normativos una vez que estos se hayan desarrollado y diseñado. De hecho, dichos elementos técnicos son los que comúnmente ayudan a habilitar las políticas definidas para proteger los activos de información de una organización. Pareciera doble trabajo el implantar los controles vía elementos técnicos y luego volverlos a configurar de acuerdo a la Normatividad. La

'

88

razón de hacer lo anterior es que lo primero puede realizarse más rápido que lo segundo. Sin embargo, en caso de que ya exista la normatividad solo tendrán que evaluarse (talvez también reconfigurarse) los elementos técnicos que la habilitan y monitorear su cumplimiento. La realidad es que, de acuerdo a nuestra experiencia, la causa raíz de la mayoría de las intrusiones es por falta de normatividad y/o falta de un monitoreo continuo de su cumplimiento.

4.1 ENFOQUE TECNICO

Debido a que 1 a principal debilidad i <lentificada en los escenarios fue el control de acceso, e 1 Modelo de Protección propuesto inicia por este elemento. Después toma en cuenta el robustecimiento de la plataforma operativa y aplicaciones, la protección de integridad, definición de roles y responsabilidades, administración remota, control de acceso a nivel red, detección de vulnerabilidades, detección de intrusos y análisis y protección de bitácoras.

4.1.1 ROBUSTECIMIENTO DEL CONTROL DE ACCESO LOCAL

El robustecimiento del control de acceso local se habilita principalmente, a través de la configuración de la política de cuentas, en particular, la referente a las contraseñas, existente en la mayoría de los sistemas operativos donde se deberá especificar una longitud mínima de contraseña de 8 posiciones, con un mecanismo que impida la elección de una contraseña débil (talvez comparándola con un diccionario previamente cargado y además que tenga la capacidad de identificar el que no se estén utilizando varias letras de la cuenta de usuario), guardando un historial de por lo menos 6 contraseñas, y con una vigencia de dicha contraseña de 90 días para usuarios sin privilegios y 45 días para usuarios con privilegios, adicional a esto las contraseñas no se podrán cambiar hasta después de 72 horas ( esto con la finalidad de evitar que los usuarios cambien al mismo tiempo de manera secuencial 6 veces la contraseña y por lo tanto pudieran utilizar la misma). Adicional a esta configuración de política de contraseñas, se deberá establecer el bloqueo de la cuenta después de 3 (máximo 5) intentos de acceso fallido, dicho bloqueo debe ser indefinido, es decir, se requiere la intervención del administrador para desbloquearla. Lo anterior deberá ir acompañado de una adecuada definición de eventos en bitácoras, esto implica que por lo menos los intentos de acceso fallidos, su origen y cuenta utilizada deberán ser enviados a tales bitácoras. Es importante mencionar que la configuración del parámetro de bloqueo de cuentas puede llegar a causar una negación de servicio a algunas o todas las cuentas del sistema ( excepto "root" en UNIX o "administrator" en Windows, quienes siempre desde consola podrán firmarse).

La manera de realizar lo anterior en ambientes Windows NT/2000 es a través del "Account Policy" y el "Password Policy". La opción para evitar el uso de contraseñas débiles se realiza activando el parámetro "Password must meet complexity requirements" dentro del "Password Policy" en el "Local Security Settings".

89

A su vez, en ambientes UNIX existe un archivo que permite la definición de tales parámetros. En el caso específico de Linux dicho archivo es /etc/login.defs ( en /etc/shadow se puede ver si se están cumpliendo dichos valores) y en Solaris /etc/default/passwd y /etc/default/login. Adicional a esto, la herramienta npasswd (http://www.utexas.edu/cc/unix/software/npasswd/) es un sustituto para el comando passwd que incorpora la capacidad de disminuir la posibilidad de la elección de una contraseña débil.

Adicional a la configuración de estos parámetros es altamente recomendable el auditar la fortaleza de las contraseñas elegidas por los usuarios y administradores del sistema, esto puede ser fácil utilizando herramientas como "John the Ripper" (http://www.openwall.com/john/) para UNIX y Windows, así como el software LC4 (http://www.atstake.com/products/lc/) para Windows.

La problemática del control de acceso débil es dificil de solucionar, por lo que deberá ser monitoreado el cumplimiento de las políticas asignadas.

4.1.2 ROBUSTECIMIENTO DE LA PLATAFORMA OPERATIVA Y APLICACIONES

La segunda actividad primordial es poder garantizar que nuestros equipos cuentan con las últimas actualizaciones de seguridad ( comúnmente llamados "parches"). En tan solo una frase parece que hemos cerrado una gran cantidad de puertas, sin embargo, la realidad es que esto no es cierto. Lo anterior se debe a que dichas actualizaciones de seguridad no pueden hacerse directamente en ambientes productivos porque podrían tener un grave impacto sobre las aplicaciones que alojan así como en el propio sistema operativo. Motivo por el cual, primero deben evaluarse dichos impactos en sistemas espejo o muy similares en ambientes de prueba. Esta sola situación complica de manera importante esta actividad tanto en costo como en tiempo de respuesta, más si tomamos en cuenta que cada vez en mejor tiempo se "liberan" los códigos (comúnmente conocidos como "exploits") para atacar una cierta vulnerabilidad.

Esta situación no exime de la aplicación de la actualización, sin embargo, si complica el proceso, el elemento indispensable es no darse por vencido a la primera ya que se será vulnerable, poniendo así en probable riesgo a la infraestructura. Se menciona lo anterior, porque es la "clásica" excusa de los administradores. El reto es encontrar una manera de resolver el problema, talvez modificando alguna configuración y logrando aplicar la actualización de seguridad o encontrando alguna medida compensatoria.

Lo anterior se refiere a equipos productivos, situación que por lo general sucede. Sin embargo, en el caso de que el equipo todavía no esté en producción y se le puedan hacer todas las adecuaciones de seguridad, una de ellas tendría que ser la actualización de las versiones más recientes del software o por lo menos las adecuadas y autorizadas para los fines de negocio así como las actualizaciones de seguridad tanto del sistema operativo como de las aplicaciones que aloja. De hecho, lo más recomendable es que en el proceso de entrega de un sistema por parte del proveedor, este sea fortalecido y actualizado antes de la instalación de los aplicativos y por tanto antes de que esté en el ambiente productivo.

•

90

Si el caso fuera el anterior, es decir, que podemos actualizar el equipo antes de pasarlo a producción, existen varias herramientas que nos pueden ayudar a identificar la falta de ciertas actualizaciones de seguridad. En el caso de Windows NT/2000 puede ser útil la herramienta MBSA (Microsoft Baseline Security Analyzer http://www.microsoft.com/technet/security/tools/mbsahome.mspx) la cual inclusive nos puede informar sobre vulnerabilidades de IIS, MS-SQL y MS-Exchange. Para plataformas UNIX, particularmente Solaris, se puede utilizar el comando showrev y directamente en la página de Sun (http://sunsolve.sun.com) se pueden obtener las actualizaciones faltantes recomendadas ("Recomended Solaris patch clusters"), en el caso de Linux se puede utilizar el servicio de Red Hat Network (comando "up2date") para obtener fácilmente todas las actualizaciones.

Existen algunas herramientas que además de instalar las ultimas actualizaciones de seguridad hacen o tras modificaciones a 1 sistema con e 1 afán de fortalecerlo y por tanta de cerrar ciertas puertas que pudieran convertirse ,en oportunidades de ataque. La más conocida es "Bastille­Linux" (http://www.bastille-linux.org/) la cual está disponible para Red Hat Linux, Mandrake Linux, Debian Linux, HP-UX y Mac OS X. Para Solaris existe la herramienta JASS ("JumpStart Architecture and Security Scripts" - http://wwws.sun.com/software/security/jass/ ) y Y ASSP (Yet Another Solaris Security Package - pttp://www.yassp.org/). En el caso de Windows NT/2000 esto se puede lograr a través de plantillas de seguridad ("security templates" http://www.microsoft.com/technet/Security/prodtech/win2000/win2khg/06tmplts.mspx) y ejecutando la herramienta mencionada MBSA.

Adicional a lo anterior, es importante señalar que esta tarea también involucra el cerrar puertos (TCP/UDP) asociados a servicios innecesarios corno daytime, c hargen, telnet, entre otros, que son iniciados por omisión, así como la identificación de las aplicaciones que están iniciando dichos puertos para evaluar la conveniencia de mantenerlos abiertos.

4.1.3 PROTECCION DE INTEGRIDAD

Una vez que se tiene certeza de que el sistema operativo y aplicaciones que residen en él son las más recientes y con las actualizaciones de seguridad necesarias, el siguiente paso es utilizar un mecanismo que nos pueda avisar cuando hay un cambio en la integridad de algún binario o archivo de configuración sensible dentro del sistema (incluyendo sistema operativo y aplicaciones). Lo anterior es vital ya que una de las primeras acciones que toma un intruso es modificar el sistema de tal manera que pueda garantizar su entrada posterior ( creación de "backdoor"), así como borrar sus rastros contenidos en bitácoras. La primera acción podrá ser identificada con un verificador de integridad (modificación del sistema) y más adelante se explicará como se puede resolver la segunda acción (borrado de bitácoras).

Es importante comentar que una vez que un intruso ha logrado penetrar un sistema podrá realizar cualquier acción: ejecutar, borrar y modificar cualquier archivo o binario del sistema. También con un verificador de integridad se podrán reconstruir las acciones por lo menos de borrado y modificación del intruso .

91

La herramienta más común a este respecto es Tripwire (para la versión comercial http://www.tripwire.com, y para la versión con licencia GPL http://www.tripwire.org/), la cual toma una "foto inicial" (así como "fotos" subsecuentes en caso de cambios autorizados) de los archivos y binarios del sistema que uno defina como sensitivos (por ejemplo /hin/login, ó /bin/ls en UNIX, y archivos con terminación .exe y .dll en Windows NT/2000, por citar algunos). Esta definición de archivos y binarios sensitivos se establece a través de una política, el resultado de la "foto" es almacenado en una base de datos, la cual contiene las huellas digitales de los archivos y binarios definidos en lapo lítica y contra las cuales se estará comparando la integridad de 1 os mismos.

Las plataformas soportadas por Tripwire son Windws NT/2000, Solaris (SPARC) 2.6, 7, 8 y 9, Linux kernel 2.2 y superior, AIX 4.3.3 y 5.1, HP-UX 10.20, 11.0 y 1 li, FreeBSD 4.5, 4.6 y 4.7, Tru64 UNIX 4 y 5.0A, 5.1 y 5.lA. En caso de tener alguna plataforma que no sea soportada, la realidad, es que hacer un programa que verifique la integridad es tan sencillo como sacar la huella digital (posiblemente a través de algoritmos como MD5 o SHA-1) de 1 os archivos y binarios definidos como sensitivos, almacenar las huellas en un medio de solo lectura y a través de una tarea programada estar verificándolas. La ventaja de Tripwire, es que dicha verificación puede ser en tiempo real. Como comentario final, es indispensable el guardar la base de datos con la "foto" (huellas digitales) de los binarios y archivos sensitivos del sistema fuera del mismo, ya que si un intruso sabe que se está utilizando este mecanismo de integridad, inmediatamente intentará deshabilitarlo, así como modificar la política y la base de datos. También es muy importante volver a sacar dicha foto cuando se realice un cambio autorizado, ya sea por una actualización de versión o por la instalación de una actualización de seguridad.

Adicional a la verificación en tiempo real, una de las ventajas de Tripwire es que se puede instalar una consola central de administración en la cual se reporten violaciones de integridad en todo un ambiente distribuido. Es decir, puede haber 50 servidores con distintos sistemas operativos y aplicaciones los cuales reportarán cualquier cambio en su integridad a una consola central. Esto puede hacerse todavía más ro busto si 1 as bases de datos con 1 as fotos de los 5 O sistemas residen en la consola central (y en un back-up para evitar que se vuelva un punto único de falla) y a través de un proceso automático se inicia la verificación de integridad, estableciendo comunicación entre el sistema y la consola de manera cifrada.

Algunos verificadores de integridad adicionales son AIDE (Advanced Intrusion Detection Environment http://www.cs.tut.fi/-rammer/aide.html), Osiris (http://osiris.shmoo.com/), Samhain (http://la-samhna.de/samhain/) y LANguard (http://www.gfi.com/).

Sobre el problema que se comentó en el punto anterior "Robustecimiento de la plataforma operativa y aplicaciones" respecto a que las aplicaciones y el sistema operativo pueden comportarse de manera errática una vez que han sido instaladas las actualizaciones de versiones y las actualizaciones de seguridad, también los verificadores de integridad pueden ayudar para identificar que binarios o archivos están modificando dichas actualizaciones, con lo cual se podrá acotar de mejor manera la solución.

92

4.1.4 DEFINICION DE ROLES Y RESPONSABILIDADES

Una de las debilidades de ambientes UNIX es la concentración de privilegios en una sola cuenta llamada "root", lo cual implica que debido a esa concentración de privilegios muchas tareas se tengan que realizar con dicha cuenta, como lo son tareas administrativas, de respaldo de información, de detener o iniciar servicios, entre otros. Debido a lo anterior, se requiere una herramienta que permita habilitar el principio de separación de funciones, en el cual, sin necesidad de conocer la contraseña del súper usuario pueda realizar sus tareas y solo éstas. Para esto, es ampliamente utilizada la herramienta "sudo" ("superuser do" http://www.courtesan.com/sudo/) a través del cual se pueden definir comandos específicos para usuarios los cuales antes solo podía ejecutar "root". Esta herramienta consta de un archivo de configuración /etc/sudoers y una utiliería para editar este archivo conocida como visudo. Por ejemplo, si colocamos dentro del archivo /etc/sudoers lo siguiente:

root ALL=( root) ALL rlira ALL=(root) /sbin/ifup rlira ALL=(root) /sbin/ifdown rlira ALL=(root) /sbin/ifconfig

Suponiendo que dichos binarios (ifup, ifdown, ifconfig) solo tienen permisos de ejecución para el usuario "root", a través de sudo ahora el usuario rlira podrá también ejecutarlos y por tanto dar de baja y de a Ita interfases de red a sí como conocer su estado, esto sin necesidad de conocer 1 a contraseña de "root". La tarea puede ser compleja, sin embargo, hay muchos binarios muy sensitivos en el sistema que podrían entrar en este esquema para evitar entregar la contraseña de "root" a todos los administradores o a todos los que por sus funciones requieren privilegios similares a "root". Es importante señalar que prácticamente sudo está disponible para todos los sabores de UNIX.

Esto también puede realizarse en ambientes Windows NT/2000, a través de la adecuada elección de privilegios y permisos en la utilería del sistema "User Manager" que pueden ser asignados a ciertos grupos como "Administrators", "Backup Operators" y "Users", entre otros.

4.1.5 ADMINISTRACION REMOTA

La administración remota de los sistemas es un tema indispensable en 1 as organizaciones, sin embargo, la falta de un control adecuado de la misma así como la falta de un estándar corporativo puede abrir las puertas a un intruso. La importancia del estándar corporativo de administración remota radica en que se tendrá que proteger, controlar y actualizar solo una herramienta (por ejemplo, SSH) en lugar de 5 o 6 (SSH, además de Terminal Services, VNC, PC Anywhere, Citrix, t elnet, por mencionar algunos, finalmente es el objetivo de todo estándar). Lo anterior implica además que solo se tendrá que controlar una puerta de acceso, simplificando así la tarea de seguridad, similar a lo que sucede en un edificio cuando los accesos fisicos pueden darse por 7 puntos en lugar de uno ya que se requerirá un guardia de seguridad, cámaras de video, arcos de

1

93

detección de metales, bitácora de entrada/salida, etc. para vigilar cada uno de los 7 puntos de acceso, complicando la tarea de vigilancia e incrementando los costos operativos. Lo mismo sucede en el caso de la administración remota.

Para ambientes UNIX lo más recomendable es SSH (por cierto, telnet ya es inaceptable por el riesgo que implica el que envíe la información, incluyendo usuario y contraseña, en texto claro). También existe una versión (comercial - http://www.ssh.com/) para ambientes Windows

NT/2000.

Las ventajas de SSH es que además de ser una herramienta ampliamente probada y utilizada a nivel mundial, el envío de toda la información (incluyendo autenticación) es de manera cifrada. Adicional a esto, también puede ser utilizada como un sustituto para FTP (quien también envía toda la información en texto claro, incluyendo autenticación). Otra característica importante es que puede ser configurado de tal manera que solo ciertos usuarios puedan acceder a este servicio, con lo cual se puede incorporar el principio de mínimo privilegio, en el cual solo los usuarios que requieren realizar tareas de administración remota podrán utilizarlo.

En el caso de ambientes Windows 2000 (aunque también es recomendable SSH) se puede utilizar Tenninal Services (http://www.microsoft.com/windows2000/technologies/tern1inal/default.asp), si y solo si éste es configurado de tal manera que solo los usuarios con necesidades específicas puedan accederlo ( complementando esto con los puntos anteriores de Robustecimiento de Control de Acceso y Robustecimiento de la Plataforma Operativa y Aplicaciones). La ventaja de Terminal Services es que también envía la información de forma cifrada y su ambiente operativo es transparente ya que es idéntico a estar enfrente a la consola. Es importante que si se elige esta herramienta como estándar, se mantenga informado sobre vulnerabilidades y actualizaciones de seguridad del proveedor (Microsoft) ya que tiene su historia de brechas de seguridad. Es importante complementar la elección de esta herramienta de administración remota con el tema siguiente de control de acceso a nivel red. Adicional a esto, Citrix (http://www.citrix.com/) es cada día más utilizado por lo que también puede ser considerado como un estándar corporativo, sin embargo, también debe estar sujeto a los temas de Robustecimiento de Control de Acceso y de Actualizaciones de seguridad así como con el tema siguiente de control de acceso a nivel red, entre otros.

4.1.6 CONTROL DE ACCESO A NIVEL RED

Una vez que hemos logrado robustecer el control de acceso a nivel local, también es muy importante hacerlo a nivel red. Cuando hablamos de control de acceso a nivel red nos referimos a que derivado del uso extendido de ambientes distribuidos, existen en las organizaciones un número significativo de sistemas operativos y aplicaciones, sin embargo, su sola existencia no implica que todos los usuarios puedan o deben tener acceso a ellos de manera remota ( es decir, que exista una ruta en la red que les permita llegar a dichos sistemas). Por lo tanto es indispensable hacer un análisis de quienes y desde donde pueden acceder a los servicios en red de los distintos sistemas de la organización (el ¿quién?, lo puede resolver un adecuado control de acceso a nivel local, el ¿desde dónde? lo puede resolver el control de acceso a nivel red).

94

Por ejemplo, si existen 40 sistemas con sistema operativo Windows 2000, 40 con sistema operativo Solaris y 30 con sistema operativo Linux, tendremos que analizar quienes y desde donde pueden administrarlos a través por ejemplo de SSH o de Terminal Services. El realizar este análisis tendrá como resultado el que no cualquier usuario pueda tener acceso a dichos servicios considerados como sensitivos. A hora, un intruso a demás de adivinar un usuario y contraseña, deberá estar desde una dirección IP o segmento (zona de seguridad, más adelante se abordará este tema) de confianza o autorizado. Adicional al análisis de servicios de administración remota, también se deberá hacer una análisis de las aplicaciones que pueden ser alcanzadas desde la red, para que solo los usuarios autorizados y desde ubicaciones autorizadas puedan acceder a las mismas. Lo anterior puede ser complejo si se utiliza asignación dinámica de direcciones IP (DHCP), por lo que es ampliamente recomendable que ciertos sistemas cliente utilicen direccionamiento estático ( así como un control y alertas, en caso de que alguien intente asignarse dicha dirección, talvez haya necesidad de bajarse hasta nivel de dirección MAC). Por ejemplo, si el sistema de nómina solo es modificado y consultado por 5 usuarios, es recomendable que los sistemas cliente desde donde acceden dichos usuarios tengan direcciones IP fijas con el afán de que solo desde esos 5 equipos se puedan realizar modificaciones y consultas a la nómina y así restringimos el acceso a los demás 10,000 usuarios de nuestra red. Es importante reconocer que para otras aplicaciones que tengan que ser ampliamente consultadas o modificadas será conveniente utilizar otros controles y no necesariamente éste. Lo anterior no sucede para las herramientas de administración remota, ya que los administradores por lo general siempre están en una misma ubicación y además es un grupo plenamente identificado ( es decir, no están dispersos por la red, con lo cual, caer en este esquema de control a nivel red también pudiera pensarse complicado).

El realizar este análisis puede ser desgastante, pero al final el resultado es un mejor control y seguridad de los sistemas, principalmente los críticos.

Lo anterior puede ser realizado a través de la creación de zonas de seguridad o redes virtuales (VLANs) que permitan una agrupación lógica de usuarios de acuerdo al nivel de criticidad de la información y sistemas a los que tienen acceso. Estas zonas de seguridad pueden ser creadas a través de filtros en la red (comúnmente, firewalls y acl's en routers), donde se puedan limitar los flujos de información entre redes de distintos niveles de seguridad. Por ejemplo, una red de usuarios de ventas, no tendría porque tener acceso a una red de administradores de sistemas, o de usuarios de nómina, o de finanzas y a su vez los usuarios de ventas no tienen porque acceder a los sistemas que alojan las aplicaciones de finanzas o contabilidad dentro del "site" de la organización. Es importante mencionar que estos controles a nivel de red son poco utilizados, sin embargo, su beneficio puede ser muy alto. Siempre me he preguntado ¿Por qué darle la oportunidad a cualquier usuario conectado a la red de una organización de que tenga una ruta de acceso al nivel de la red al Mainframe de facturación, o al AS/400 de contabilidad, o al Solaris que aloja a SAP? Por lo menos ya le estamos dando la oportunidad de que intente una o muchas combinaciones de nombre de usuario y contraseña. Más grave aún, es que esta oportunidad no solo se la damos a los usuarios de nuestra red, sino a todo el que esté conectado a nuestra red (léase, proveedores, terceros, outsourcers, e intrusos). Esta sola situación es la que permite que las pruebas de penetración sean exitosas.

•

95

Una buena opción para la creación de zonas de seguridad pueden ser los firewalls (CheckPoint, Cisco PIX, etc.) y las listas de control de acceso en routers.

En caso de que la creación de zonas de seguridad no sea viable por razones de costo o complejidad, por lo menos se sugiere que de manera local, se restringa el acceso a ciertos servicios en red, de tal manera que solo puedan ser accedidos desde ciertas direcciones IP. Esto puede lograrse en ambientes UNIX con la herramienta TCP Wrappers (http://www.porcupine.org/) o con firewalls locales (iptables, ipchains, ipfilter, etc.). En el caso de ambientes Windows NT/2000 puede configurarse en las opciones avanzadas de TCP, sin embargo, es poco funcional por lo que sugiere utilizar herramientas de terceros.

Sobre TCPWrappers, es fácil de instalar y de configurar, solo se tiene que especificar en dos archivos /etc/hosts.allow y /etc/hosts.deny las direcciones IP autorizadas y que servicio está autorizado. Un ejemplo de este puede ser:

En /etc/hosts.allow

sshd : 10.100.100.2 10.100.100.3 10.100.100.4

y en /etc/hosts.deny

ALL: ALL

Habremos cerrado del universo de direcciones I P dentro de nuestra organización a solo 3 que podrán hacer uso del servicio de red SSH. Adicional a este control de acceso a nivel red, TCP Wrappers provee mayor información en los eventos enviados a las bitácoras. Es importante mencionar que no todos los servicios pueden pasar o ser protegidos por este "Wrapper" o filtro, solo aquellos que cumplan con ciertas características como: servicios que puedan ser iniciados cada vez que una conexión es identificada (por ejemplo, el servicio httpd - talvez a través de Apache- sería complicado meterlo en este esquema, debido a que se tendría que estar reiniciando cada vez que se hiciera una petición, las cuales pueden ser cientos, miles o millones), servicios que utilicen solo TCP y UDP (existen servicios que además de TCP y UDP utilizan RPCs), por mencionar algunas.

Comúnmente el control de acceso a nivel red es ampliamente utilizado para la creación de un perímetro protegido expuesto a Internet y aislado de nuestra red interna, a través principalmente de firewalls. Sin embargo, la propuesta es utilizar un esquema de tal tipo pero de manera interna para evitar los riesgos que ya he comentado.

4.1.7 DETECCION DE VULNERABILIDADES

Los puntos anteriores abarcan las acciones más relevantes en materia de prevención ( aunque, la protección de integridad pueda tomarse como medida detectiva si es que ésta no se protege en

•

96

tiempo real, es un poco polémico, pero se tomará como medida preventiva para ser consistente con la presentación, primero de medidas preventivas y después de medidas detectivas) que ayudan a mitigar los riesgos asociados a las debilidades y vulnerabilidades identificadas en los 1 O escenarios presentados. Estas tareas de prevención son muy importantes, pero igual de importantes son las tareas de detección. Una de las más útiles es la detección de vulnerabilidades utilizando herramientas automáticas ( comúnmente conocidas como "escaners" de vulnerabilidades). A este respecto existen muchas y varias muy reconocidas como: Nessus, Internet Scanner de ISS y Retina de eEye.

Nuestra recomendación es Nessus debido a que es gratis, open source (está disponible el código fuente para su análisis) y actualizado ( en ocasiones diario). Estas características lo han hecho el preferido de la mayoría porque además compite mano a mano con las otras dos (Internet Scanner y Retina) las cuales pueden llegar a costar varios miles de dólares.

La gran ventaja de un detector de vulnerabilidades es que aún habiendo realizado las tareas preventivas (como control de acceso y actualizaciones de seguridad) puede haberse dejado algún hueco, como por ejemplo alguna aplicación en red que no es necesaria y que es iniciada por omisión, por lo que esta herramienta nos podrá dar información a este respecto. Estas herramientas se vuelven más útiles cuando los sistemas ya están en operación, ya que comúnmente no tienen las más recientes actualizaciones de seguridad y tampoco tienen aplicadas todas las medidas preventivas antes mencionadas, con lo cual a través de esta herramienta podrán ser identificadas dichas vulnerabilidades y debilidades. Es importante mencionar que estas herramientas (por lo menos las mencionadas) corren de manera remota, es decir, no se requiere la instalación de ningún agente en los sistemas que se analizarán y por tanto puede llegar a haber ciertos falsos positivos ( es decir, que la herramienta indique cierta vulnerabilidad en el servidor que en realidad no existe). Sobre falsos negativos (es decir, cuando si existe una vulnerabilidad en el servidor y la herramienta no la detecta), también puede haber varios y por esto la importancia de las medidas preventivas. Adicional a esto, es importante mencionar que la herramienta genera un reporte de las vulnerabilidades del sistema analizado, sin embargo, por si solo es poco útil, la verdadera utilidad está en el análisis y discriminación entre falsos positivos y vulnerabilidades reales.

4.1.8 DETECCION DE INTRUSOS

El tema de detección de intrusos es altamente controversial, sin embargo, de acuerdo a nuestra experiencia, puede darle a los administradores de seguridad suficiente información para conocer si se está siendo atacado y a través de que se está siendo atacado. Similar a lo que sucede con los firewalls, los detectores de intrusos son vistos solo como herramientas perimetrales cuando también son de gran utilidad en ambientes internos. En particular son muy útiles para detectar infecciones de gusanos, ataques de diccionario o fuerza bruta, interrogación de puertos ( escaneo de puertos) e interrogación de vulnerabilidades (escaneo de vulnerabilidades).

Es una tecnología polémica en gran parte por su alto costo, sin embargo, existen soluciones gratis ( además de "open so urce") que tienen un excelente desempeño y capacidad de detección. La

•

97

principal a este respecto es SNORT que puede ser configurado de tal manera que envíe todos los eventos detectados a una bitácora y a su vez a una base de datos (por ejemplo, MySQL, también gratis). Este último elemento permite un análisis de datos más profundo, a través de consultas de alertas en específico, de periodos de tiempo, de identificación de direcciones IP más atacadas, de puertos más a tacados, entre otros. Adicional a esto, se han creado pro gramas de consulta que pemüten realizar este tipo de análisis y ser presentados en una página web (ej. ACID - "Analysis Console for Intrusion Detection") principalmente programados en PHP. La combinación SNORT - MySQL - ACID y PHP puede convertirse en una herramienta potente de detección de intrusos. Una característica adicional es que se pueden tener sensores distribuidos también con estos 4 elementos de tal manera que los eventos se envíen a una base de datos central y puedan ser analizados también de manera central.

El configurar SNORT junto con MySQL, ACID y PHP puede llevarse un par de horas y los beneficios pueden ser importantes. La sugerencia es, no solo colocarlo en zonas p erimetrales, sino también en zonas internas que contienen sistemas críticos o que manejan información sensitiva. Otra utilidad de los detectores de intrusos es que en caso de que una vulnerabilidad haya sido explotada con éxito nos podrá dar evidencia de esto. Esto lo menciono porque el que se presente una alerta no quiere decir que se esté llevando a cabo el ataque o mejor dicho la penetración al sistema, simplemente puede ser que sea solo un intento de ataque.

A continuación presentamos una imagen de la consola de ACID de un sensor de SNORT expuesto a Internet reportando alertas sobre intentos de identificación de proxies, sobre la propagación de un gusano que ataca a MS-SQL y sobre intentos de ejecución de código en IIS.

-'.1 lCID: Mert l 1S"l1ne ~ Mc51 1 rcqucnl Alcrls M1crc~ofl lnlcrncl r ~plorcr .. 15 Ji -

i,J:,.,·.~ i&J" ~:l/192.168.1.2/llCJdf lCi:l_sur11:_aau.pq)1coler~J,~e.sort_CW'det-accu _'6A-P.iiESSIC.--ll:b1tlSS6d289c:IJ819'9d69edl355185 ¡"' ""'· -- - . ,, '";;;;e;;;; ; oi ·,a;;;;..---, -- ------ --~---

! (BacK]

! Addod O alcrt(s) to rho Alort cacho

Ouerled 08 on SatJune 19, 2004 23.23:16

any

Oisplaying 5 Most Frequenl Alerts

Total Sensor Src Dest S,gnature C[asslf1cat1on # # Addr Addr First Last

o o o []

o 1

1

L ____

(url] SCAr• SOCKS Pro-..y attempt attempled-recon n,;2

2 725 (54%)

(url] (bugtroq] (bu11troq) MS-SQL m1sc-attack

392 2 311 Worm propagaban anempr (18%) . 204 SC.AN Squid Pro:.y attempt an~mpted-recon

(10%) ·122

SCAN Pro:,y Po,t 8080 ettempt 168(9%) ·117

WEB-IIS cmd.exe access 65 (3%) 36

Acuon

Fig. 4.1. Snort, Acid, PHP, Apache, MySQL

2004-04-17 ·1~:56:37 2004--04-17 U:20:56 2004-04-20

07:19:4'.j 2004,)-1-1:?

11:24:56 2004-04-17

18:14:11

2004-06-'!9 :ti :32:40 ~004,:,.;.19 :3: 15:04 2004-06-19 ·12:39:09 2004-06-19 15:30:40 200~-06-ü4 17:03:40

•

98

Lo anterior, a demás nos da idea de lo que se está propagando por Internet y sobre el u so de ciertas herramientas automáticas de identificación de vulnerabilidades. Como toda herramienta de seguridad es falible por lo que es solo un elemento más dentro de toda nuestra infraestructura de seguridad.

Finalmente, es importante detectar la interrogación de puertos TCPIUDP en tiempo real para tomar medidas preventivas como bloquear el acceso a la dirección IP que está realizando dicha acción. Como todo en la seguridad, esto también se deberá evaluar ya que puede provocarse una negación de servicio, sin embargo, es una técnica muy útil ya que hay que recordar que una de las primeras etapas de un ataque es la identificación de los puertos abiertos. Para ambientes UNIX la herramienta portsentry (http://sourceforge.net/grojects/sentrytools/) puede ayudar a este respecto y para ambientes Windows NT/2000, la mayoría de los detectores de intrusos basados en red o host incorporan esta funcionalidad.

4.1.9 ANALISIS Y PROTECCION DE BITACORAS

Las bitácoras, bien configuradas, pueden damos información importante en materia de seguridad. Los eventos más importantes son intentos de acceso exitosos y fallidos (quien y desde donde), accesos de lectura, escritura o ejecución de archivos o binarios críticos del sistema, ejecución de tareas programadas con respaldos nocturnos, inicio, reinicio o detención de servicios, ejecución de herramientas administrativas, entre otros. Adicional al análisis de eventos, debe protegerse la integridad de las bitácoras. Lo primero puede resolverse con herramientas automáticas de detección de eventos como lo es Swatch y la segunda a través de varias técnicas, la más utilizada y recomendada es enviar los eventos no solo a la bitácora local del sistema, sino también a un repositorio externo de bitácoras. Esta técnica tiene la gran ventaja de que aunque el intruso borre sus rastros de manera local, estos ya estarán almacenados fuera del mismo, protegiendo así su integridad. Desafortunadamente, también es una técnica poco utilizada a pesar de que es muy sencillo configurar, principalmente a través del propio sistema operativo. Por ejemplo, en UNIX a través de syslog, también hay productos de terceros que permiten realizar esto en ambientes Windows NT/2000 (ej.: ntsyslog httg://ntsyslog.sourceforge.net/).

Una debilidad identificada de syslog es que envía los eventos al repositorio central a través de la red utilizando UDP y no TCP, con lo cual no se puede garantizar que efectivamente los paquetes hayan llegado, recordar que UDP es un protocolo orientado a mejor esfuerzo. Debido a esto, una nueva implementación de syslog que utiliza TCP es syslog-ng (http://www.balabit.com/products/syslog ng/), con lo cual se puede garantizar que todos los eventos generados de manera local estarán en el repositorio central. Ambas herramientas son fáciles de instalar y configurar. Para el caso de syslog-ng basta con establecer el tipo de eventos que se desea enviar y la dirección IP a donde se quieren enviar (seguramente la dirección IP del repositorio central).

Por ejemplo, en syslog para enviar todos los eventos generados localmente a una dirección IP externa (en esta caso llamada loghost) se realiza lo siguiente dentro de /etc/syslog.conf:

99

* * @loghost

y del lado del repositorio de bitácoras (loghost) se deberá configurar syslogd de tal manera que acepte eventos desde sistemas de la red, esto se hace agregando "-r" en el archivo /etc/sysconfig/syslog:

SYSLOGD OPTIONS=" ... -r..."

La ventaja de un repositorio central además de proteger la integridad de las bitácoras de toda la organización puede servir para realizar un análisis profundo sobre incidencias y correlación de eventos. La configuración de syslog-ng es similar pero a través del archivo /etc/syslog-ng/syslog­ng.conf. A diferencia de syslog, con syslog-ng se puede tunelear la información enviada a través de stunnel o sslproxy, esto con el objetivo de cuidar su confidencialidad mientras se transmite esta información por la red.

Para finalizar con el enfoque técnico, adicionalmente se sugiere tomar en cuenta los siguientes elementos:

o Antivirus y gateway de Antivirus, indispensables hoy en día con la fuerte propagación de código malicioso, principalmente gusanos.

o Protección de transacciones remotas vía VPN ( principalmente a través de SSL o IPSEC). o Kit de Herramientas para Respuesta a incidentes y análisis forense - principalmente: lsof,

sniffers, análisis de bitácoras del sistema, tripwire y snort, The Coroner' s Toolkit, Knoppix-STD, Sleuth Kit, Autopsy Forensic Browser, EnCase, HexDump, entre otros.

o Investigación de nuevos ataques y amenazas, de ser posible de primera mano. o Cifrado de información sensitiva ya sea con criptografia simétrica o asimétrica.

4.1.10 PUNTOS ADICIONALES

Adicional a los puntos mencionados con anterioridad también es muy recomendable realizar revisiones exhaustivas sobre los desarrollos internos de aplicaciones. Es muy común que los desarrolladores tengan en contra el factor tiempo por lo que aspectos de seguridad son dejados hasta el último y en ocasiones ni siquiera son incorporados. Hemos encontrado muchos casos con aplicaciones que dentro del propio código está el usuario y contraseña para comunicarse con otras aplicaciones y muchas veces esta contraseña es trivial.

También se recomienda realizar evaluaciones de la disponibilidad de los sistemas principalmente los que soportan aplicaciones críticas expuestas a Internet así como aquellas que residen en la red interna. Nos referimos tanto a sistemas como sistemas operativos y aplicaciones como ha elementos de conectividad como routers, switches y también mecanismos de seguridad como firewalls y detectores de intrusos.

•

•

100

4.2 ENFOQUE NORMATIVO Y CORPORATIVO

El enfoque normativo y corporativo incluye varias tareas principalmente encaminadas a la definición de políticas y procedimientos que permitan proteger los activos de información de las organizaciones a un nivel aceptable, siempre alineadas con la estrategia del negocio. Este enfoque se colocó después del enfoque técnico por que la mayoría de las organizaciones requieren "resolver rápidamente" sus problemas (aunque este resolver es más bien un apagar fuegos y no prevenirlos), y una vez medianamente resuelto aquello, toman conciencia de la importancia de la normatividad y es entonces cuando empiezan a actuar en este tema. Lo anterior es criticable pero real. Un adecuado Programa Estratégico de la Seguridad de la Información debiera iniciar por la definición e implementación del Enfoque Normativo y Corporativo y después, la implementación del Enfoque Técnico sería simplemente un habilitador de éste. Es importante señalar que si se empieza con el enfoque técnico, se tendrán que volver a hacer modificaciones a las configuraciones una vez que se haya analizado y diseñado el enfoque normativo y corporativo.

El enfoque normativo y corporativo abarca los siguientes puntos:

o Normatividad - Políticas, Procedimientos y Estándares o Análisis de Riesgos o Programa de Conciencia de Seguridad o Continuidad del Negocio

4.2.1 NORMATIVIDAD - POLITICAS, PROCEDIMIENTOS Y ESTANDARES

El punto de partida de una Normatividad sobre Seguridad de la Información es la definición de una Política Directriz en la cual la Gerencia Ejecutiva establece la importancia de la seguridad de la infomiación para los objetivos del negocio así como su compromiso hacia este tema, adicionalmente establece su compromiso para apoyar las acciones en esta materia y establece los roles y responsabilidad para su cumplimiento. Esta política es vital ya que es la muestra de que habrá apoyo por parte de la Gerencia Ejecutiva para las inversiones en seguridad de la información, que la mayoría de las ocasiones en lugar de verse como inversiones, son vistas como gastos. Una vez definida la Política Directriz se podrán realizar las demás políticas que complementan el marco normativo. Para la realización de dichas políticas la ISOI 7799 puede ser un buen punto de partida, así como "The Standard of Good Practice for Information Secuirty" del Information Security Forum.

Las principales políticas que se sugieren son

a) Política de control de acceso b) Política de clasificación de información c) Política de protección de información d) Política de monitoreo e) Política de respuesta a incidentes

•

101

f) Política de desarrollo de sistemas

Una vez diseñadas estas políticas, las cuales son sugeridas de acuerdo principalmente a los 1 O escenarios presentados, se deberán desarrollar los procedimientos requeridos para habilitar cada una de ellas. También de acuerdo a dichos escenarios, se identificó que los procedimientos más importantes son:

a) Procedimientos de administración de usuarios (altas, bajas y cambios) b) Procedimientos de administración remota c) Procedimientos para definición de matriz de perfiles (roles y responsabilidades) d) Procedimientos de análisis y clasificación de información e) Procedimientos para segmentación de redes con base en criterios de clasificación de

información - creación de zonas de seguridad. f) Procedimientos de control de cambios g) Procedimientos de administración de vulnerabilidades h) Procedimientos de actualización de versiones i) Procedimientos de instalación de parches (actualizaciones de seguridad) j) Procedimientos de revisión de bitácoras k) Procedimientos de monitoreo de eventos críticos 1) Procedimientos para la verificación de integridad de archivos y binarios críticos m) Procedimientos de respaldos n) Procedimiento de respuesta a incidentes o) Procedimientos de desarrollo de aplicaciones

Una vez realizados estos procedimientos que soportan a las políticas definidas, se podrá ajustar la tecnología para hacerla cumplir con éstas. Es decir, si en la Política de Control de Acceso se ha definido que después de 5 intentos fallidos se bloquearán las cuentas, se deberá configurar esto en la política de contraseñas de todos los sistemas. En ocasiones se prefiere eliminar cuestiones tan específicas como números, en este caso el 5, y ese número pasarlo al estándar de tal manera que la política sea lo más estático posible. Con esto, la política, específicamente sobre los intentos fallidos podría decir: "Se deberán bloquear indefinidamente las cuentas después de un cierto número de intentos fallidos, y solo el administrador del sistema podrá desbloquearlas" y en el estándar referente a este punto en particular se establecería que después de 5 intentos fallidos se bloquearan las cuentas.

Es muy importante señalar que debe establecerse un proceso continuo de mantenimiento de las políticas, estándares, procedimientos y guías, así como incorporar un adecuado control de cambios en las mismas.

4.2.2 ANALISIS DE RIESGOS

Existe controversia sobre el momento en que se debe llevar a cabo un análisis de riesgos. Hay quienes dicen que debe ser antes de realizar la Normatividad, lo cual hace sentido ya que es en ésta donde se define el qué, cómo y para qué proteger la información, pero solo podemos saber el

t

•

102

qué a través de un análisis de riesgos que como su nombre lo dice nos permita conocer las áreas más sensitivas de la organización. Algo similar sucede con la tarea de clasificación de información. De acuerdo a nuestra experiencia es muy útil realizar un análisis de riesgos antes de llevar a cabo e 1 esfuerzo de 1 a definición de 1 a N ormati vi dad ya q ue en e 1 análisis se podrán identificar elementos estratégicos para el negocio. Sin embargo, la realidad es que muchas de las organizaciones ya tienen una cierta Normatividad y lo que solicitan es un análisis de riesgos. La realidad es que de cualquier manera el análisis de riesgos no es de una vez, realmente se tiene que incorporar a un proceso continuo debido a que los riesgos de una organización pueden cambiar, casi siempre para aumentar. Por lo que habrá elementos de la Normatividad (Políticas o procedimientos o estándares, o una combinación de los tres) que posiblemente tengan que cambiar para proteger a la organización de estos nuevos riesgos identificados. Un ejemplo claro son las regulaciones o legislaciones, casi siempre traen como consecuencia nuevos riesgos para el negocio ya que por falta de cumplimiento de los elementos solicitados se pueden obtener sanciones, tanto económicas como corporativas y pueden llegar a provocar hasta la desaparición de la organización.

De acuerdo a lo anterior, es muy conveniente realizar un análisis de riesgos antes de diseñar la Normatividad, sin embargo, dicho análisis de riesgos debe realizarse de manera periódica.

4.2.3 PROGRAMA DE CONCIENCIA DE SEGURIDAD

Adicional al diseño e implementación de la Normatividad, se deberá realizar un esfuerzo corporativo importante de concientización de usuarios sobre los riesgos asociados al uso y mal uso de la tecnología. Esta concientización es un proceso continuo y está integrado principalmente por talleres, conferencias y envío de información relevante a través de correo electrónico. D e hecho este programa de concientización apoya de manera significativa la fase de implantación de la normatividad. Es prudente recalcar, que una normatividad solo es útil si está implantada y su cumplimiento es monitoreado y auditado, de lo contrario, de poco o nada sirve. Se sabe de muchas organizaciones que precisamente en esa fase de implantación han fallado y todo se ha quedado en varias carpetas.

4.2.4 CONTINUIDAD DEL NEGOCIO

Este esfuerzo de la normatividad, análisis de riesgos y programa de conciencia debe complementarse con otro esfuerzo corporativo como lo es la definición de un plan de continuidad del negocio, en el cual se definan las áreas estratégicas y en base a un análisis de impacto al negocio se identifiquen los requerimientos mínimos necesarios para que en caso de un incidente (ej.: daño en un disco duro de equipo Tandem o Mainframe) o desastre (ej. terremoto) el negocio pueda continuar.

Es vital para el éxito de un plan de continuidad del negocio el que sea una iniciativa patrocinada por la alta gerencia ya que requiere de la participación de toda la Compañía. El líder de proyecto debe tener tanto una formación técnica como de negocio para que pueda entender tanto los

•

103

riesgos de negocio como los riesgos asociados al uso. de tecnología. En caso de que no se cuente con una persona con ambos perfiles, se puede proponer la utilización de dos líderes de proyecto, uno con enfoque técnico u otro con enfoque de negocios.

Es importante mencionar que la mayoría de las veces se piensa que un plan de continuidad del negocio abarca solo las áreas de tecnología, por ejemplo: sistemas o informática. Lo anterior es un grave error de percepción ya que un verdadero plan de continuidad del negocio debe abarcar todas las áreas consideradas criticas de una Compafi.ía. Algo tan común como un accidente automovilístico que provoque que una persona clave de la Compañía tenga que ausentarse por un mes, debe ser previsto en el plan, no importando que dicha persona ejecute sus funciones con elementos tecnológicos o no.

La fase inicial de la definición de un plan de continuidad de negocio debe tomar como base los objetivos del negocio, su visión y misión, 1 as actividades consideradas criticas, 1 as entradas y salidas del negocio, dependencias o interacciones con terceros. Deben identificarse los procesos críticos del negocio, con base en el impacto financiero, operacional, legal o de imagen que un incidente o desastre pudiera significar.

El punto de partida para la definición de un plan de continuidad es el análisis de impacto al negocio con el cual se evaluarán los distintos eventos que pueden afectar la continuidad de las operaciones de una Compañía así como el tiempo que dicha afectación puede durar antes de que empiece a dañar de manera significativa al negocio. Como se mencionó, el daño puede ser tanto financiero como operacional, legal o de imagen. En la mayoría de los casos, todos se materializan en un daño financiero.

El análisis de impacto al negocio tiene, principalmente, tres objetivos: establecer la criticidad de todos los procesos del negocio, estimar el tiempo máximo tolerable que el negocio puede soportar por causad e un incidente ( evento adverso), y 1 a identificación de 1 os recursos tanto humanos como tecnológicos y operacionales requeridos por los procesos considerados más críticos. Comúnmente, el análisis de impacto se compone de cuatro fases: recopilación de la información necesaria, realización de un análisis de riesgos o vulnerabilidades (acotado a las áreas consideradas críticas), análisis de 1 a información obtenida y documentación y presentación de resultados. Todas aquellas áreas, unidades de negocio o funcionales, que se requieran para que el negocio pueda realizar sus operaciones son consideradas críticas. Es importante señalar que habrá algunas más criticas que otras, por lo que también deberán ser priorizadas. Lo anterior debe ser consensado con las distintas áreas directivas del negocio. De hecho, de acuerdo al método IAM (lnfoSec Assessment Method) propuesto por la NSA (National Security Agency) de los Estados Unidos, la identificación de las áreas críticas del negocio se obtiene a través de entrevistas con personal directivo de las distintas áreas de la Compañía.

Una vez realizado el análisis de impacto al negocio se podrán definir y documentar las estrategias de continuidad, lo cual es tarea ardua y demandante en tiempo y recursos. Los principales elementos que deben ser considerados en dicha estrategia son: infraestructura tecnológica ( cómputo y conectividad), instalaciones, gente, recursos materiales y equipo (papel, formatos, aire acondicionado, entre otros) .

•

104

Definido y documentado el plan de continuidad del negocio se deberá obtener aprobación de la alta gerencia, establecer una estrategia de comunicación y conciencia y finalmente, se deberá establecer un proceso de mantenimiento, pruebas y actualización del plan de continuidad.

Para el caso de eventos catastróficos (terremotos, incendios, inundaciones, entre otros) debe considerarse un plan de recuperación en caso de desastre, que bajo nuestro enfoque, es una o varias estrategias de continuidad consideradas dentro del plan de continuidad, pero tomando como punto de partida la ocurrencia de un evento catastrófico. Es importante señalar, que para compañías con operaciones centralizadas un plan de recuperación en caso de desastres no debe contener solo los elementos de TI, sino también se deben contemplar a los demás procesos críticos del negocio. Para los casos de compañías con operaciones distribuidas, puede suceder que el plan de recuperación en caso de desastres solo contemple TI y algunos elementos considerados críticos o que sean parte de procesos críticos soportados en la localidad donde se sufrió el desastre.

Debido a la gran dependencia de TI en los procesos de negocio de las compañías actuales, comúnmente se maneja el plan de recuperación en caso de desastres solo para elementos tecnológicos, aunque nuestra sugerencia es evaluar que elementos adicionales deben evaluarse en caso de un desastre que impacten de manera significativa a las operaciones de un negocio, ya que de nada o poco servirá el que se puedan recuperar los sistemas si los procesos de negocio no pueden ser recuperados.

Para finalizar y apoyar lo dicho en los párrafos anteriores, Jon William Toigo en su libro "Disaster Recovery Planning, preparing for the unthinkable" [30) establece que un plan de recuperación en caso de desastres, consiste en un conjunto de actividades que tienen como objetivo el minimizar el impacto en los procesos críticos de negocio producto de un desastre. Establece, que ejemplos de desastres son: inundaciones, huracanes y terremotos, en cambio, propone que los eventos o incidentes considerados dentro del plan de continuidad del negocio son: virus, fallas en sistemas o discos duros, ataques maliciosos, entre otros .

105

CAPITULOS

CONCLUSIONES

"Antiguamente, los guerreros expertos se hacían a sí mismos invencibles en primer lugar, y después aguardaban para descubrir la vulnerabilidad de sus adversarios. Hacerte invencible

significa conocerte a ti mismo; aguardar para descubrir la vulnerabilidad del adversario significa conocer a los demás. "

Sun - Tzu, El Arte de la Guerra.

A continuación presento las conclusiones de este trabajo, las cuales son principalmente las causas raíz de los diez escenarios presentados en el capítulo titulado "Análisis de resultados obtenidos en pruebas de penetración a sistemas":

La "inseguridad de la información" comienza a preocupar a la mayoría de las organizaciones en México, a pesar de que es un tema con una respetable historia. Lo anterior debido, principalmente, a que la información es uno de los activos clave de las organizaciones, para muchas el más crítico, principalmente para la toma de decisiones y como habilitador de las actuales estrategias de ERP y negocios electrónicos. La dependencia de elementos digitales es cada día mayor en los procesos de negocio de las organizaciones. Hoy en día es casi imposible pensar en un Compañía que no utilice recursos informáticos para apoyar o soportar sus procesos de negocio.

La protección de activos de información en las organizaciones requiere de un programa estratégico de administración de la seguridad de la información que tenga un enfoque de negocio, integral, basado en administración de riesgos y patrocinado por la alta gerencia. Sin embargo, la seguridad de la información es todavía un tema reactivo en lugar de preventivo, detectivo y estratégico. Es un tema complejo y dinámico por lo que requiere de un proceso continuo y permanente de evaluación y monitoreo. La mejor manera de evaluar la seguridad de la información de un entorno organizacional es conociéndolo, entendiendo sus objetivos de negocio y comprendiendo la tecnología, procesos y gente que lo soporta.

..

106

Las debilidades en el control de acceso, la falta de políticas y procedimientos, las prácticas inseguras de desarrollo y la falta de entrenamiento son las principales debilidades o vulnerabilidades identificadas durante las pruebas de penetración. Precisamente la normatividad (políticas, procedimientos, estándares y guías) junto con el programa de conciencia y entrenamiento de seguridad de la información son temas comúnmente subestimados en la mayoría de las organizaciones y en pocas ocasiones son tema en juntas o comités a nivel directivo. Podemos establecer que lo anterior es la principal consecuencia de controles inadecuados o inexistentes para proteger la información y la infraestructura que la soporta.

La tecnología no es suficiente. No basta con tener el firewall más sofisticado, si no está soportado por personal capacitado y entrenado y por políticas y procedimientos alineados con los objetivos del negocio, de poco servirá. Los factores gente y procesos son comúnmente ignorados a pesar de que son el verdadero soporte del tercer factor crítico de la seguridad de la información: tecnología. Como evidencia de lo anterior puedo mencionar que la epidemia del usuario root y contraseña root ( o administrator/administrator, administrador/administrador,) está ampliamente difundida en las organizaciones.

La complejidad de las actuales infraestructuras que soportan la información y procesos de las organizaciones, provoca la existencia de un gran número de rutas de acceso a la misma, por lo que es de vital importancia realizar un análisis de riesgos que permita identificarlas, evaluarlas y sugerir controles. Conocer las distintas vías de ataque de un entorno organizacional es un buen comienzo para diseñar, probar e implantar controles que las mitiguen siempre con un enfoque costo/beneficio. Las organizaciones están más preocupadas por incorporar nuevas herramientas que suponen un incremento en la seguridad de la información sin antes proteger y asegurar lo básico ( control de acceso por ejemplo), lo anterior producto de un desconocimiento de sus riesgos y falta de estrategias adecuadas de protección. Las supuestas nuevas tecnologías son solo una cortina de humo que no resuelven lo básico y elemental como las debilidades en el control de acceso, la falta de políticas y procedimientos, y la falta de entrenamiento. Entender las limitaciones y fortalezas de la tecnología es esencial para asegurarla y proteger los activos de información que soporta.

Las pruebas de penetración son una excelente herramienta que le permite a las organizaciones conocer las distintas rutas de ataque y por tanto identificar riesgos. Es muy importante señalar que dichas pruebas requieren de una metodología que permita identificar no solo vulnerabilidades y debilidades en los sistemas e infraestructura tecnológica, sino también sus causas raíz.

El "enemigo" conoce técnicas y ataques más sofisticados, solo necesita una puerta medio abierta para comprometer la seguridad de la información de una organización, por esto es indispensable definir, implantar, mantener y probar estrategias de continuidad del negocio y respuesta a incidentes así como de prevención y detección.

Una estrategia de administración de seguridad de la información requiere un enfoque bidimensional en el que se consideren aspectos técnicos y normativos-corporativos. La mayoría de las veces, solo considera el primer aspecto, por lo que se tiene una seguridad acotada, poco funcional y altamente costosa. Aunque cada entorno organizacional tiene sus propias

'

107

particularidades no se están tomando en cuenta las historias y lecciones aprendidas en materia de seguridad de la información de otras organizaciones.

Finalmente, podemos decir que "Inseguridad de la lnfonnación" en México no está alejada de los casos típicos globales.

108

REFERENCIAS BIBLIOGRAFICAS

[1] RIHN09, The Windows NTwardoc: A study in remate NT penetration.

[2] WACK, J. et al. Guideline on network security testing. NIST Publicación especial 800-42, 2003.

[3] HERZOG, P., Open-Source Security testing Methodology Manual. Edición 2.1, 2003.

[4] TEMMINGH, R., Breaking into computer networksfrom the Internet, 2001.

[5] MIXTER, An approach to systematic network auditing.

[6] http://staff.washington.edu/dittrich/misc/tfn.analysis

[7] FARMER, D.; WIETSE, V., Improving the security ofyour site by breaking into it, 1994.

[8] DENNING, D.E., Information warfare and security. Primera edición, EUA: Addison W esley, 2001.

[9] http://www.cisco.com/security

[10] PELTIER, T.R. et al. Managing a Network Vulnerability Assesment. Primera edición, EUA: Auerbach, 2003.

[ 11] KLEVINSKY, T.J. et al. Hack l. T. Security through Penetration Testing. Primera edición, EUA: Addison Wesley, 2002.

[12] McCLURE, S. et al. Hacking Exposed. Network Security Secrets & Solutions. Cuarta edición, EUA: McGraw Hill/Osbome, 2003.

[13] http://www.sps.org.uk

[14] ISO/IEC 17799, Information Technology-Code of practice far information security management. Primera edición, 2000.

[15] TUDOR, J.K., Information Security Arquitecture. Primera edición, EUA: CRC Press LLC, 2001.

[ 16] DOLL, M. et al. Defending the Digital Frontier. A Secutiry Agenda. Primera edición, EUA: Wiley Publishing, 2003.

109

[ 17] GREENBERG, E., Miss ion Critica! Security Planner. Primera edición, EUA: Wiley Publishing Inc, 2003.

[18] ALLEN, J., The CERT gu.ide to system and network security practices. Primera edición, EUA: Addison Wesley, 2001.

[ 19] NORTHCUTT, S. et al. Jnside Network Perimeter Security. Primera edición, EUA: New Riders Publishing, 2003.

[20] BACE, R.G., lntrusion Detection. Primera edición, EUA: McMillan Technical Publishing, 2000.

[21] PT ACK, T.H., lnsertion, evasion and denial of service: eluding network intrusion detection, 2002.

[22] FORREST, S. et al. Detecting intrusians using systems calls: alternative data madels, IEEE Symposium on security and privacy, 1999.

[23] KIM, J., An artificial immune system far netwark intrusian detectian. University College London.

[24] SP AFFORD, E., An architecture far intrusian detectian using autanamaus agents. Proceedings ofthe 14th annual computer security applications conference, 1998.

[25] SP AFFORD, E., Defending a computer system using autanamaus agents. Proceedings of the 18th National Information Systems Security Conference, 1995.

[26] KING, C. et al. Security Architecture. Design Deployment & Operatians. Primera edición, EUA: McGraw Hill/Osbome, 2001.

[27] SCHNEIER, B., Ten risks of PKI: what yau are nat being tald abaut Public Key lnfraestructure. Computer Security Joumal, v 16, n 1, 2000.

[28] CHESWICK, W., Firewalls and Internet Security. Segunda edición, EUA: Addison Wesley Professional, 2003.

[29] VIEGA, J.; McGRA W, G ., Building Secure Software. Primera edición, EUA: Addison Wesley, 2001.

[30] TOIGO, J.W., Disaster Recavery Planning. Tercera edición, EUA: Prentice Hall, PTR., 2003.

110

BIBLIOGRAFIA

[l] NORTHCUTT, S., /ntrusion Signatures and Analysis. Primera edición, EUA: New Riders Publishing , 2001.

[2] McCLURE, S. et al. WEB Hacking, Attacks and Defense. Tercera edición, EUA: Addison Wesley, 2003.

[3] SCAMBRA Y, J.; SHEMA, M., Hacking WEB Applications Exposed. Primera edición, EUA: Me Graw Hill, 2002.

[4] REHMAN, R., Intrusion Detection with SNORT. Primera edición, EUA: Prentice Hall, Inc., 2003.

[5] McNAB, C., Network Security Assesment. Primera edición, EUA: O'Reilly, 2004.

[6] YOUNG, S.; AITEL, D., The Hacker's Handbook. Primera edición, EUA: Auerbach, 2004.

[7] HORTON, M.; MUGGE, C., Hack Notes. Network Security. Primera edición, EUA: McGraw Hill/Osbome, 2003.

[8] O'Dea, M., Hack Notes. Windows Security. Primera edición, EUA: McGraw Hill/Osbome, 2003.

[9] DHANJANI, N., Hack Notes. Linux and UNIX Security. Primera edición, EUA: McGraw Hill/Osbome, 2003.

[10] BEALE, J. et al. SNORT 2.0. Intrusion Detection. Primera edición, EUA: Syngress Publishing, Inc., 2003.

[11] McCARTY, B., Red Hat Linux Firewalls. Primera edición, EUA: Wiley Publishing, Inc., 2003.

[12] SCHULTZ, E., Windows NT/2000. Network Secutity. Primera edición, EUA: Macmillan Technical Publishing, 2000.

[13] NORBERG, S., Securing Windows NT/2000 Servers. Primera edición, EUA: O'Reilly & Associates, Inc., 2001.

111

[ 14] DANIEL Y AN, E., Solaris 8 Security. Primera edición, EUA: New Riders Publishing,

2001.

[15] CHIRILLO, J., Hack Attacks Denied. Primera edición, EUA: John Wiley & Sons, Inc., 2001.

[16] TANENBAUM, A., Computer Networks. Tercera edición, EUA: Prentice Hall, Inc.,

1996.

[ 17] PEIKARI, C.; CHUV AKIN, A., Security Warrior. Primera edición, EUA: O'Reilly & Associates, Inc., 2004.

[18] HOGLUND, G.; McGRAW, G., Exploiting Software. Primera edición, EUA: Addison Wesley, 2004.

[ 19] RANUM, M., The myth of Homeland Security. Primera edición, EUA: Wiley Publishing, 2004.

[20] BAUER, M., Building Secure Servers with LINUX. Primera edición, EUA: O'Reilly & Associates, Inc., 2003.

[21] BARRETT, D. et al. LINUX Security Cookbook. Primera edición, EUA: O'Reilly & Associates, Inc., 2003.

[22] KABIR, M., Red Hat LINUX Security and Optimization. Primera edición, EUA: Hungry Minds, Inc., 2002.

[23] LUDWIG, M.A., Computer Viruses, Artificial life and Evolution. Primera edición, EUA: American Tagle Publications, Inc., 1993.

[24] KABIR, M.J., Red Hat Linux Survival Guide. Primera edición, EUA: Hungry Minds, Inc., 2002.

[25] DHIRILLO, J., Hak Attacks Revealed. Primera edición, EUA: John Wiley & Sons, Inc., 2001.

[26] RUSELL, R. et al. Hack Proofing Your e-commerce site. Primera edición, EUA: Syngress Publishing, Inc., 2001.

[27] THE HONEYNET PROJECT, Know your enemy. Primera edición, EUA: Addison Wesley, 2002.

[28] KABIR, M.J., Red Hat Linux Survival Guide. Primera edición, EUA: Hungry Minds, Inc., 2002.

112

[29] COLE, E., Hackers Beware. Primera edición, EUA: New Riders Publishing, 2001.

[30] SCHMIED, W. et al. DMZs far Enterprise Networks. Primera edición, EUA: Syngress Publishing, Inc., 2003.

[31] WYK, K.R.; FORNO, R., Inciden! Response. Primera edición, EUA: O'Reilly & Associates, Inc., 2001.

[32] KASPERSKY, KRIS., Hacker Disassembling Uncovered. Primera edición, EUA: A-List, LLC., 2003.

[33] SCHNEIER, B., Applied Cryptography. Segunda edición, EUA: John Wiley & Sons, Inc., 1996.

[34] TRIPTON, H.F.; KRAUSE, M., Information Security Management. Cuarta edición, EUA: Auerbach, 1999.

[35] LUDWIG, M., The Giant black book ok Computer Viruses. Segunda edición, EUA: Lexington & Concord Partners, Ltd., 2000.

[36] SLATALLA, M.; QUITTNER, J., Masters of Deception. Primera edición, EUA: HarperCollins Publishers, Inc., 1996.

[37] DR-K., A complete hacker 's handbook. Primera edición, Gran Bretaña: Carlton Books, 2000.

[38] MANDIA, K.; PROSISE, C., Incident Response: Investigatin Computer Crime. Primera edición, EUA: McGraw Hill / Osbome, 2001.

[39] HARRIS, S., Ali in one CISSP Certification. Primera edición, EUA: McGraw Hill / Osbome, 2002.

[ 40] GARFINKEL, S.; SPAFFORD, G., Practica/ UNIX & Internet Security. Segunda edición, EUA: O'Reilly & Associates, Inc., 1996.

[ 41] NICHOLS, R. et al. Defending your digital assets. Primera edición, EUA: McGraw Hill, 2000.

[ 42] STALLINGS, W., Cryptography and Network Security. Segunda edición, EUA: Prentice Hall, 1999.

[ 43] STOLL, C., The Cuckoo 's Egg. Primera edición, EUA: Pocket Books, 1990.

[44] VOLKERDING, P.; REICHARD, K., Linux System Commands. Primera edición, EUA: M&T Books, 2000.

113

[ 45] TATE, S. et al. Windows 2000 Essential Reference. Primera edición, EUA: New Riders Publishing, 2000.

[46] KOZIOL, J. et al. The Shellcoder's Handbook. Primera edición, EUA: Wiley Publishing,

Inc., 2004.

[ 47] ZIEGLER, R.L., Linux Firewalls. Primera edición, EUA: New Riders Publishing, 2000.

[ 48] SMITH, B.; KOMAR, B., Windows Security Resource Kit. Primera edición, EUA: Microsoft Press, 2003.

[ 49] MILES, W. et al. Hack Proofing SUN Solaris 8. Primera edición, EUA: Syngress Publishing, Inc., 2001.

[50] STANGER, J. et al. Hack Proofing LINUX Primera edición, EUA: Syngress Publishing, Inc .. 2001.

[ 51] STEVENS, W .R., UNIX Network Programming. Segunda edición, EUA: Prentice Hall, Inc., 1998.

[52] CASEY, E., Digital evidence and computer crime. Primera edición, Gran Bretaña: Academic Press, 2001.

[53] JONES, G.A.; JONES, J.M., Elementary Number Theory. Primera edición, Gran Bretaña: Springer Verlag, 1998.

[54] PEIKARI, C.; FOGIE, S., Wireless. Primera edición, EUA: Sams Publishing, 2002.

[55] WELCH-ABERNATHY, D.D., Essential Check Point Firewall-1. Primera edición, EUA: Addison Wesley, 2001.

[56] INTERNET SECURITY SYSTEMS, Windows 2000 Security Technical Reference. Primera edición, EUA: Microsoft Press, 2000.

[57] SONNENREICH, W.; YATES, T., Building LINUX and OpenBSD Firewalls. Primera edición, EUA: John Wiley & Sons, lnc., 2000.

[58) MILES, W. et al. Hack Proofing SUN Solaris 8. Primera edición, EUA: Syngress Publishing, Inc., 2001.

[59] DENNING, D.E.; DENNING, P.J., Internet Besieged. Primera edición, EUA: Addison Wesley, 2001.

1

114

[60] COLLINGS, T.; WALL, K., Red Hat Linux Networking and System Administration. Primera edición, EUA: Hungry Minds, Inc., 2002.

[61] Anonymous, Maximum Security. Segunda edición, EUA: Sams Publishing, 1998.

[62] GARFINKEL, S.; GENE, S., Web Security & Commerce. Primera edición, EUA: O'Reilly & Associates, Inc., 1997.

[63] HUNT, C., TCPIIP. Network Administration. Segunda edición, EUA: O'Reilly & Associates, Inc., 1998.

[64] HALL, E.A., Internet Core Protocols. Primera edición, EUA: O'Reilly & Associates, Inc., 2000.

[65] BARRETT, D.J.; SILVERMAN, R.E., SSH. The Secure Shell. Primera edición, EUA: O'Reilly & Associates, Inc., 2001.

[66] FRISCH, A., System Administration. Segunda edición, EUA: O'Reilly & Associates, Inc., 1995.

[67] RUSELL, D.; GANGEMI, G.T., Computer Security Basics. Primera edición, EUA: O'Reilly & Associates, Inc., 1992.

[68] ZWICKY, E.D. et al. Building Internet Firewalls. Segunda edición, EUA: O'Reilly & Associates, Inc., 2000.

INDICE DE FIGURAS

Fig.1.1. Mapa de Seguridad de acuerdo a OSSTMM Fig. 1.2. Separación entre recolección de datos y pmebas de verificación. Fig. 4.1. Snort, Acid, PHP, Apache, MySQL

115