[MODELO DE SEGURIDAD INFORMÁTICA COLCIENCIAS]

2008

Universidad de Los Andes Artur Miller Jiménez Castro Isabella López Tello

[MODELO DE SEGURIDAD INFORMÁTICA COLCIENCIAS] La información en nuestros días es crítica para muchas organizaciones. Colciencias entidad estatal encargada del fomento a la investigación y desarrollo en Ciencia, Tecnología e Innovación en Colombia debe garantizar que la información se encuentre disponible, por ello se crea el plan de seguridad informática, que dará las bases a Colciencias para que inicie las mejores prácticas en la protección de la información.

2

Modelo de Seguridad Informática COLCIENCIAS

Proyecto de Grado 2008-1 Universidad de Los Andes

Isabella López Tello Artur Miller Jiménez

Departamento de Ingeniería de Sistemas y Computación 2008

3

1. Tabla de Contenido

1. TABLA DE CONTENIDO........................................................................................................ 3

2. PRESENTACIÓN .................................................................................................................. 9

3. JUSTIFICACIÓN ................................................................................................................. 10

4. OBJETIVOS ....................................................................................................................... 11

4.1. GENERAL ......................................................................................................................... 11 4.2. ESPECÍFICOS ..................................................................................................................... 11

5. ALCANCE .......................................................................................................................... 12

6. SUPOSICIONES Y LIMITACIONES AL PROYECTO.................................................................. 13

7. CONTEXTO ....................................................................................................................... 14

8. PROCESO ......................................................................................................................... 17

8.1. FASE 1: REUNIÓN Y CORRECCIÓN DE INFORMACIÓN ................................................................... 17 8.1.1. OBJETIVOS FASE I ............................................................................................................ 17 8.1.2. TAREAS FASE I ................................................................................................................ 17 8.1.3. ENTREGABLES FASE I ........................................................................................................ 17 8.1.4. TRABAJO REALIZADO ........................................................................................................ 17 8.1.4.1. Entrevistas ................................ ................................ ................................ ............... 18 8.1.4.1.1. Percepciones sobre el conocimiento de la seguridad en Colciencias.......................... 18 8.1.4.1.2. Validación servicios Colciencias .............................................................................. 19 8.1.4.1.2.1. Eldorado2pro – Encuestada María Clemencia Reyes.............................................. 19 8.1.4.1.2.2. WAIRA – Encuestada María Clemencia Reyes........................................................ 19 8.1.4.1.2.3. PORTAL – Encuestada Diana Patiño ...................................................................... 21 8.1.4.1.2.4. SIGP –Encuestada Marlén Pineda ......................................................................... 21 8.1.4.1.2.5. SCIENTI – Encuestado Omar Figueroa ................................................................... 22 8.1.4.2. Activos de la Institución ............................................................................................ 23 8.1.4.2.1. Mapa Red LAN Colciencias...................................................................................... 23 8.1.4.3. Corrección de Documento......................................................................................... 24 8.2. FASE 2: IMPLEMENTACIÓN DE ESCENARIO DE PRUEBAS Y MITIGACIÓN DE RIESGOS ENCONTRADOS ......... 25 8.2.1. OBJETIVOS FASE II ........................................................................................................... 25 8.2.2. TAREAS FASE II ................................ ................................ ................................ ............... 25

4

8.2.3. ENTREGABLES FASE II ................................ ................................ ................................ ....... 25 8.2.4. TRABAJO REALIZADO ........................................................................................................ 25 8.2.4.1. Investigación ............................................................................................................ 25 8.2.4.1.1. Servidores Colciencias ............................................................................................ 26 8.2.4.1.2. Entrenamiento ...................................................................................................... 28 8.2.4.2. Pruebas.................................................................................................................... 28 8.2.4.2.1. Pruebas Locales ..................................................................................................... 29 8.2.4.2.1.1. Servidor Zulia ...................................................................................................... 29 8.2.4.2.1.2. Servidor Huitaca.................................................................................................. 34 8.2.4.2.1.3. Servidor Scienti ................................................................................................... 36 8.2.4.2.1.4 Servidor Eldorado2pro ............................................................................................ 39 8.2.4.2.1.5 Servidor Quihicha ................................................................................................... 41 8.2.4.2.2. Pruebas Remotas ................................................................................................... 44 8.2.4.2.2.1. Zulia ................................................................................................................... 44 8.2.4.2.2.2. Huitaca ................................ ................................ ................................ ............... 44 8.2.4.2.2.3. Scienti ................................................................................................................ 44 8.2.4.2.2.4. Eldorado2pro...................................................................................................... 44 8.2.4.2.2.5. Quihicha ............................................................................................................. 45 8.2.4.2.3. Simulación............................................................................................................. 46 8.2.4.2.3.1. Servidor Windows ................................ ................................ ............................... 46 8.2.4.2.3.1.1. Guía para la corrección de vulnerabilidades en Windows ................................... 46 8.2.4.2.3.1.1.1. eldorado2pro. ................................ ................................ ............................... 46 8.2.4.2.3.2. Servidores Solaris ................................................................................................ 48 8.2.4.2.3.2.1. Guía para la corrección de vulnerabilidades en Servidores Solaris ....................... 50 8.2.4.2.3.2.1.1. Zulia ............................................................................................................. 50 8.2.4.2.3.2.1.2. Huitaca ......................................................................................................... 52 8.2.4.2.3.2.1.3. Scienti .......................................................................................................... 53 8.2.4.2.3.2.1.4. Quihicha ................................ ................................ ................................ ....... 55 8.3. FASE 3: CREACIÓN DE PLAN DE CONTINGENCIA Y POLÍTICAS DE SEGURIDAD DE LA INFORMACIÓN.......... 57 8.3.1. OBJETIVO FASE III............................................................................................................ 57 8.3.2. TAREAS FASE III .............................................................................................................. 57 8.3.3. ENTREGABLES FASE III ...................................................................................................... 57 8.3.4. POLÍTICAS DE SEGURIDAD .................................................................................................. 57 8.3.4.1. Implementación de Políticas de Seguridad ................................................................. 58 8.3.4.2. POLÍTICAS DE SEGURIDAD DE LA INFORMACIÓN EN COLCIENCIAS ................................ ............... 60 8.3.4.3. RESPONSABILIDADES...................................................................................................... 61 8.3.4.3.1. Obligaciones hacia el Personal ................................................................................ 62 8.3.4.3.2. Responsabilidades del Personal .............................................................................. 62 8.3.4.4. POLÍTICAS FORMALES DE SEGURIDAD.................................................................................. 62 8.3.4.4.1. Políti cas de Correo Electrónico ................................ ................................ ............... 62 8.3.4.4.1.1. Cuenta de Correo Electrónico .............................................................................. 62 8.3.4.4.1.2. Cuenta personal de correo electrónico ................................................................. 63

5

8.3.4.4.1.3. Creación de Cuentas............................................................................................ 63 8.3.4.4.1.4. Asignación de más de una cuenta de correo ......................................................... 63 8.3.4.4.1.5. Problemas con la cuenta de correo ...................................................................... 63 8.3.4.4.1.6. Uso de las cuentas de correo ................................ ................................ ............... 63 8.3.4.4.1.7. Despliegue de Correo .......................................................................................... 63 8.3.4.4.1.8. Tamaño de los mensajes de correo ...................................................................... 63 8.3.4.4.1.9. Listas de correo................................................................................................... 63 8.3.4.4.1.10. Número permitido de destinatarios de correo .................................................... 63 8.3.4.4.1.11. Monitoreo del correo ........................................................................................ 64 8.3.4.4.1.12. Usando la cuenta de correo electrónico asignada a otro usuario .......................... 64 8.3.4.4.1.13. Reenvío de correos a direcciones externas ......................................................... 64 8.3.4.4.1.14. Reenvío de correos externos recibidos ................................ ............................... 64 8.3.4.4.1.15. Retener correos para futuras referencias............................................................ 64 8.3.4.4.1.16. Uso de correo como base de datos..................................................................... 64 8.3.4.4.1.17. Expectativa de privacidad del correo .................................................................. 65 8.3.4.4.1.18. Correo electrónico como comunicación pública .................................................. 65 8.3.4.4.1.19. Reporte de correos ofensivos............................................................................. 65 8.3.4.4.1.20. Correo electrónico como parte de la Entidad ...................................................... 65 8.3.4.4.1.21. Uso personal del correo..................................................................................... 65 8.3.4.4.1.22. Uso de correo corporativo ................................................................................. 65 8.3.4.4.2. Políticas de Contraseña .......................................................................................... 66 8.3.4.4.2.1. Tamaño de la contraseña..................................................................................... 66 8.3.4.4.2.2. Requerimiento de contraseñas difíciles de adivinar ................................ ............... 66 8.3.4.4.2.3. Contraseñas Cíclicas ............................................................................................ 66 8.3.4.4.2.4. Reuso de contraseñas.......................................................................................... 66 8.3.4.4.2.5. Estructura de contraseñas ................................................................................... 66 8.3.4.4.2.6. Cambio de contraseña......................................................................................... 66 8.3.4.4.2.7. Contraseñas desplegadas e impresas.................................................................... 66 8.3.4.4.2.8. Asignación de contraseñas................................................................................... 67 8.3.4.4.2.9. Limite de intentos fallidos para el ingreso al sistema ............................................. 67 8.3.4.4.2.10. Ciframiento de contraseñas ................................ ................................ ............... 67 8.3.4.4.2.11. Contraseñas en diferentes sistemas ................................................................... 67 8.3.4.4.2.12. Compartir contraseña........................................................................................ 67 8.3.4.4.3. Políticas de Uso del Recurso Informático ................................................................. 67 8.3.4.4.3.1. Juegos en el computador ..................................................................................... 67 8.3.4.4.3.2. Música en el computador .................................................................................... 67 8.3.4.4.3.3. Programas en el computador ................................ ................................ ............... 68 8.3.4.4.3.4. Uso del computador y sistemas de comunicación ................................................. 68 8.3.4.4.3.5. Uso de Internet en el Sistema .............................................................................. 68 8.3.4.4.3.6. Privilegios de acceso al sistema ............................................................................ 68 8.3.4.4.3.7. Página de Internet................................ ................................ ............................... 68 8.3.4.4.3.8. Distribución de información del equipo ................................................................ 68

6

8.3.4.4.3.9. Notificaciones ante interrupción de trabajo .......................................................... 68 8.3.4.4.4. Políticas sobre los Datos ......................................................................................... 69 8.3.4.4.4.1. Seguridad de los Datos ........................................................................................ 69 8.3.4.4.4.1.1. Información como activo importante de la Entidad ............................................ 69 8.3.4.4.4.1.2. Asignación de Patentes, derechos de copia y derechos de propiedad intelectual . 69 8.3.4.4.4.1.3. Derechos de manejo para examinar información en los sistemas de la entidad.... 69 8.3.4.4.4.2. Confidencialidad de los Datos .............................................................................. 69 8.3.4.4.4.2.1. Requerimiento de confidencialidad para todos los usuarios de la entidad ........... 69 8.3.4.4.4.2.2. Restricciones en diseminación de información ................................................... 69 8.3.4.4.4.3. Criticidad de los Datos ......................................................................................... 69 8.3.4.4.4.3.1. Disponibilidad de los Sistemas de Información ................................................... 69 8.3.4.4.4.3.2. Limitación a usuarios para la interrupción de los servicios .................................. 70 8.3.4.4.4.3.3. Área de los Sistemas de información ................................................................. 70 8.3.4.4.4.4. Integridad de los Datos........................................................................................ 70 8.3.4.4.4.4.1. Cambiar información sensible, crítica o de valor................................................ 70 8.3.4.4.4.4.2. Alteración de la información ............................................................................. 70 8.3.4.4.4.4.3. Autorización en el cambio de datos ................................................................... 70 8.3.4.4.4.5. Disposición y almacenamiento de Datos – Copia de Seguridad (Back-Up) ............... 70 8.3.4.4.4.5.1. Recuperación de datos por usuarios finales ................................ ....................... 70 8.3.4.4.4.5.2. Copia de seguridad de los datos ........................................................................ 70 8.3.4.4.4.5.3. Copia de seguridad en Usuarios ........................................................................ 70 8.3.4.4.4.5.4. Copias de seguridad de los Datos de la Entidad .................................................. 71 8.3.4.4.4.5.5. Copias de seguridad en Usuarios finales ............................................................ 71 8.3.4.4.4.5.6. Uso de copias de seguridad .............................................................................. 71 8.3.4.4.5. Políticas de Seguridad en la red .............................................................................. 71 8.3.4.4.5.1. Red interna ......................................................................................................... 71 8.3.4.4.5.2. Control de acceso a la red Interna ........................................................................ 71 8.3.4.4.5.3. Configuración de la red interna ............................................................................ 71 8.3.4.4.5.4. Conexiones de acceso a la entidad ................................ ................................ ....... 71 8.3.4.4.5.5. Sistemas con información importante .................................................................. 72 8.3.4.4.5.6. Aprobación en modificaciones en la red ................................ ............................... 72 8.3.4.4.5.7. Aprobación para interconexiones de red .............................................................. 72 8.3.4.4.5.8. Aprobación para conexiones entre la red de la entidad y una red externa .............. 72 8.3.4.4.5.9. Requerimiento de seguridad para conexiones externas hacia la entidad................. 72 8.3.4.4.5.10. Aprobación para conexiones a internet .............................................................. 72 8.3.4.4.6. Políticas de Seguridad del Plan de Contingencia................................ ....................... 72 8.3.4.4.6.1. Procedimientos de segmentación de los recursos de información .......................... 72 8.3.4.4.6.2. Rata anual de criticidad en sistemas multi -usuarios................................ ............... 73 8.3.4.4.6.3. Esquema de clasificación para aplicaciones críticas .............................................. 73 8.3.4.4.6.4. Preparación y mantenimiento de planes ante incidentes informáticos ................... 73 8.3.4.4.6.5. Grupo ante incidentes de seguridad ..................................................................... 73 8.3.4.4.6.6. Preparación y mantenimiento de Planes de Recuperación ante Desastres .............. 73

7

8.3.4.4.6.7. Mantenimiento preventivo de los equipos y sistemas de información .................... 73 8.3.4.5. Otras políticas .......................................................................................................... 73 8.3.4.6. Creación de Políticas ................................................................................................. 74 8.3.4.6.1. Uso cuidadoso de plantillas genéricas ..................................................................... 75 8.3.4.6.2. Asegurarse de que las plantillas usadas sean las indicadas........................................ 75 8.3.4.6.3. Permiso legal de uso de plantillas ........................................................................... 76 8.3.4.6.4. Revisar el borrador final con la División de Personal................................................. 76 8.3.4.7. Pasos para creación de Políticas ................................................................................ 76 8.3.4.7.1. Justificación........................................................................................................... 76 8.3.4.7.2. Alcance ................................................................................................................. 76 8.3.4.7.3. Borrador ................................ ................................ ................................ ............... 76 8.3.4.7.4. Soporte administrativo........................................................................................... 77 8.3.4.7.5. Áreas de responsabilidad ................................ ................................ ....................... 77 8.3.4.7.6. Implementación y refuerzo..................................................................................... 78 8.3.4.7.7. Revisión y Auditoría ................................ ................................ ............................... 78 8.3.5. PLAN DE SEGURIDAD OPERACIONAL ..................................................................................... 78 8.3.5.1. Evaluación de Seguridad Operacional ........................................................................ 79 8.3.5.1.1. Respuesta a Incidentes........................................................................................... 80 8.3.5.1.1.1. Servicios del Equipo de Manejo de Incidentes ................................ ....................... 81 8.3.5.1.1.1.1. Servicios de Administración de Seguridad .......................................................... 82 8.3.5.1.1.1.2. Servicios Proactivos.......................................................................................... 82 8.3.5.1.1.1.3. Servicios Reactivos ........................................................................................... 83 8.3.5.1.1.2. Políticas de Seguridad ......................................................................................... 83 8.3.5.1.1.3. Recuperación de Desastres .................................................................................. 84 8.3.5.1.1.3.1. Planta Física ..................................................................................................... 85 8.3.5.1.1.3.2. Operaciones .................................................................................................... 86 8.3.5.1.1.3.3. Información y Comunicaciones ......................................................................... 86 8.3.5.1.1.3.4. Aseguramiento de la Institución ........................................................................ 87 8.3.5.1.1.4. Auditorías y Regulaciones Continuas .................................................................... 87 8.3.5.2. Alcance del plan de seguridad operacional ................................................................. 88 8.3.5.2.1. Respuesta a Incidentes........................................................................................... 88 8.3.5.2.2. Administración de Políticas..................................................................................... 88 8.3.5.2.3. Recuperación de Desastres..................................................................................... 88 8.3.5.2.4. Auditorías y Regulación .......................................................................................... 89 8.3.5.2.5. Costos ................................................................................................................... 89 8.3.5.3. Tiempo .................................................................................................................... 89 8.3.5.4. Requerimientos Funcionales y Técnicos ..................................................................... 90 8.3.5.4.1. Respuesta a Incidentes........................................................................................... 90 8.3.5.4.2. Administración de Políticas..................................................................................... 90 8.3.5.4.3. Respuesta a Desastres............................................................................................ 90 8.3.5.4.4. Auditorías y Regulaciones Continuas ................................ ................................ ....... 91 8.3.5.5. Personal Requerido ................................................................................................... 91

8

8.3.5.6. Pasos a Seguir para Implementar un Proyecto de Seguridad Operacional..................... 92 8.3.5.7. Lista de Chequeo para Revisiones .............................................................................. 93 8.3.5.7.1. EVALUACIÓN DE SEGURIDAD OPERACIONAL..................................................................... 93 8.3.5.7.2. Equipo de Trabajo .................................................................................................. 94 8.3.5.7.3. Institución ............................................................................................................. 94

9. CONTINUIDAD.................................................................................................................. 95

10. CONCLUSIONES .............................................................................................................. 96

11. GLOSARIO ...................................................................................................................... 98

11.1. CONFIDENCIALIDAD .......................................................................................................... 98 11.2. DISPONIBILIDAD .............................................................................................................. 98 11.3. ESTÁNDAR ..................................................................................................................... 98 11.4. INTEGRIDAD ................................................................................................................... 98 11.5. CONTROL....................................................................................................................... 99 11.6. POLÍTICA ....................................................................................................................... 99 11.7. PROCEDIMIENTO ............................................................................................................. 99

12. BIBLIOGRAFÍA................................................................................................................101

ANEXOS.................................................................................................................................102

ANEXO A .................................................................................................................................102 ANEXO B .................................................................................................................................102

9

2. Presentación

Nuestro proyecto de grado pretende dar un modelo de seguridad informática básico para Colciencias, que le permita a todos los funcionarios de la entidad empezar a tomar conciencia acerca de la importancia que tiene la información. Para esto hemos planteado nuestro trabajo en tres focos importantes: primero, análisis y control de vulnerabilidades; segundo, plan formal básico de políticas de seguridad y tercero, un plan de contingencia básico. Se han propuesto solamente estos tres temas ya que la institución hasta ahora está iniciando un plan de seguridad de la información, y vemos que estos son los focos más apropiados para iniciar. Además el tiempo asignado para la realización del proyecto es tan sólo de 4 meses, lo que impide hacer un trabajo con un mayor alcance.

Este documento está compuesto por: justificación, muestra porqué implementar el plan de seguridad para la entidad; objetivos de nuestro trabajo; el alcance, muestra hasta donde pretendemos llegar; suposiciones y limitaciones del proyecto, son ciertas reglas que se han hecho para garantizar que el proyecto de grado se realice completamente; contexto, pretende mostrar cómo está la situación de la seguridad informática en la actualidad.

Después continúa con Proceso realizado, muestra el trabajo hecho durante el primer semestre de 2008 en la implementación de un Modelo de Seguridad Informática básico para Colciencias. Está compuesto por:

• Fase I: Muestra las correcciones y actualizaciones respecto al trabajo de análisis de vulnerabilidades realizado en el segundo semestre del 2007. En esta parte se muestran algunas percepciones de cómo ven la seguridad en la entidad. Se obtienen de hablar con personal de diferentes niveles de la institución.

• Fase II: Muestra el análisis de vulnerabilidades hecho a algunos de los servidores de la entidad, así como el manual que debe ser aplicado en la institución para mitigar algunos de los problemas de seguridad que presentan estos.

• Fase III: Muestra el plan general de políticas de seguridad desarrollado, que puede ser utilizado e implementado al interior de la entidad con el fin de tener un estándar aplicable y funcional en políticas, que ayuden a mejorar seguridad de la información. Además muestra un plan básico de contingencia que debe ser implementado en Colciencias que garantice la protección de la información.

El documento contiene un ítem de continuidad, que muestra futuros trabajos que se pueden realizar en Colciencias que les ayude a mejorar la seguridad de la información; las conclusiones de nuestro trabajo; Glosario, muestra las definiciones de algunos términos usados en este documento que ayudarán a comprenderlo mejor; bibliografía y finalmente unos anexos al documento.

10

3. Justificación

Dada la naturaleza de la entidad, se deben tener implementados unos controles estrictos de seguridad en toda la plataforma informática, con el fin de estar en capacidad de mitigar los futuros ataques y posibles riesgos que pueden afectar la infraestructura tecnológica de Colciencias, ya que esta es una entidad muy importante para el desarrollo tecnológico y científico en el país.

Debido a esto, consideramos que es de suma importancia hacer un análisis y estudio detallado de la situación actual de la seguridad en la plataforma tecnológica de Colciencias, para comenzar a generar un modelo que sea aplicado por la entidad, ya que existen muchas falencias, la forma en que se maneja a nivel interno la información no es adecuada.

Creemos que este proyecto es de gran interés para toda la comunidad ya que se pretende asegurar la integridad y disponibilidad de la información y los servicios prestados por Colciencias a través de su plataforma operativa de misión critica; esto genera interés y una cultura de trabajo organizado al interior de la entidad, y a su vez genera confianza en toda la comunidad investigativa del país.

11

4. Objetivos

4.1. General Generar en Colciencias un ámbito de seguridad por la información, que garantice protección sobre los recursos que manejan diariamente, que estos aunque son públicos, deben asegurar la disponibilidad todo el tiempo para que no dañen la imagen corporativa de la entidad.

4.2. Específicos • Escalar el análisis de riesgos y vulnerabilidades que se realizó en el segundo semestre de 2007. • Realizar una reunión informativa con Directivos y funcionarios de la entidad, con el fin de

actualizarlos acerca de la situación de la seguridad de la información a nivel general que de una u otra manera puede afectar a Colciencias.

• Generar un manual de referencia interna para el análisis de riesgos (Manual de procedimiento de riesgos)

• Generar un esquema global de políticas formales de seguridad.

12

5. Alcance

Colciencias requiere de la actualización de los procesos de seguridad informática que se llevan a cabo dentro de la institución, pues, al tratarse de la entidad estatal encargada de fomentar la investigación y desarrollo en Ciencia, Tecnología e Innovación, debería estar a la vanguardia en los temas que abarcan estas áreas. Por esto Colciencias necesita implementar un modelo inicial de seguridad de la información lo suficientemente sólido y escalable, con el fin de que quede al nivel de las entidades nacionales.

Colciencias espera que con el proyecto realizado se dejen las bases para el Plan de Seguridad Informática exigido principalmente por el Departamento Nacional de Planeación DNP, de esta manera, se espera que la institución esté en capacidad de continuar implementando dicho plan, que los lleve a tomar liderazgo en ésta área y servir como ejemplo para las demás entidades estatales a las cuales se les exige llevar a cabo planes similares.

Inicialmente, para poder llevar a cabo la primera fase del proyecto, es necesario focalizar nuestros esfuerzos en las directivas de la institución, enterándolos de la situación actual a nivel de seguridad informática y la manera en que estos riesgos pueden afectar la imagen corporativa y los intereses de Colciencias.

Nuestro proyecto pretende llevar una metodología1, la cual va a ser utilizada en Colciencias a los tres niveles, para lograr una mejor comprensión de la situación de seguridad informática de la institución y de esta manera lograr que el trabajo entregado sea fácilmente escalable y que sirva como modelo para otras entidades.

Los entregables finales de este proyecto serán:

• Análisis y mitigación de riesgos actuales: Se creará un ambiente de pruebas que emule la situación actual de Colciencias para poder analizar más fácilmente las vulnerabilidades encontradas; de esta manera darles la solución más adecuada y que lleve a ser ejecutarlo en Colciencias. Inicialmente se mitigarán los riesgos más críticos y luego se proseguirá con los de importancia media.

• Plan de contingencia inicial de riesgos informáticos de Colciencias: Es un documento en el que se estipula un plan de acción eficiente y rápida que debe ser implementado por Colciencias en caso de que alguno de los riesgos de mayor importancia se materialice.

• Políticas de Seguridad Formales para Colciencias: Se hará un bosquejo inicial con las políticas más importantes en seguridad informática, las cuales deben ser aplicables a todo el personal de la institución.

• Manual de referencia interna para riesgos informáticos: Será un manual básico a modo de lista de chequeo para que el personal de la división de sistemas que no tenga completo conocimiento de los procesos y políticas de seguridad de la información, pueda rápidamente asimilarlos o ponerlos en práctica.

1 OCTAVE, metodología de la Universidad de Carnegie Mellon: http://www.cert.org/octave/

13

6. Suposiciones y Limitaciones al Proyecto

Las suposiciones y limitaciones que se presentan a continuación han sido establecidas por nosotros y aprobadas por nuestro asesor.

• Se mantendrán reuniones quincenales con el personal de la División Sistemas de Información Ciencia y Tecnología de Colciencias, para revisar los avances del proyecto.

• Se mantendrán reuniones semanales con el asesor del proyecto de grado con el fin de

hacer control y seguimiento del proyecto, y discutir acerca de posibles cambios que hayan sido comunicados por parte de Colciencias.

• Se realizarán entregas de documentos para revisión solamente a la finalización de cada una de las fases y a la finalización del proyecto.

• El seguimiento y comunicaciones del proyecto se realizará utilizando solamente la herramienta de manejo de proyectos BaseCamp (http://unicolsecurity.updatelog.com).

• La retroalimentación de los entregables se realizará dentro de las siguientes 48 horas luego de la entrega, esto con el fin de que la continuidad del proyecto no se vea afectada.

• El personal de Colciencias estará dispuesto a colaborar con el proyecto en todo lo que esté dentro de su alcance para la correcta realización de las tareas que los incluyan.

• Se contará con el laboratorio de redes de la Universidad de los Andes para hacer las respectivas simulaciones señaladas para la segunda fase del proyecto.

14

7. Contexto

Las entidades gubernamentales deben tener ciertos controles esenciales de seguridad desde el punto de vista legislativo:

• Protección de datos y garantizar integridad de la información: ü Confidencialidad: Quienes deben tener conocimiento de los datos y qué deben

conocer exactamente. ü Integridad: Quienes tienen derecho sobre la edición de los datos, y por qué. ü Disponibilidad: Garantizar que la información sea fácilmente encontrada por quien la

necesita en el momento en que la necesita. • Salvaguarda de registros organizacionales:

ü Mantenimiento de información histórica, la cantidad de años que esta información debe estar disponible cambia dependiendo de la entidad.

ü Garantizar que la información esté disponible junto con su integridad es crítico en la salvaguardia de datos.

• Garantizar propiedad intelectual: ü Reconocimiento debido de quien sea dueño de la información garantizando

igualmente su integridad.

De la misma manera, sobre estos aspectos se debe hacer auditoria constante para asegurar que todos los controles se establezcan de manera adecuada. Dada la proliferación del uso de las redes y de la misma manera del personal con conocimiento en sistemas tanto dentro como fuera de las entidades gubernamentales, es necesario que éstas se encuentren siempre un paso adelante de cualquier riesgo que pueda llegar a materializarse. Hasta el momento en Colombia esto no se ha visto como algo crítico que debe ser tenido en cuenta como lo es el cuidado de presupuestos, creación de planes de investigación, etc..

Se especula que son muy pocos los fraudes informáticos que logran ser detectados al interior de una organización y aún menor el porcentaje que son reportados2, esto hace que la cantidad de estadísticas disponibles para realizar un análisis detallado de la situación actual sea complicada y cualquier investigación realizada en ésta área arroja resultados aproximados.

Dentro de las razones por las cuales es complicado contar con estadísticas reales están:

• Las entidades usualmente prefieren manejar los incidentes (en caso de que sean detectados) directamente con el fin de evitar pérdidas de la buena imagen y publicidad adversa.

2 www.auditoria.gov.co/9_documentos/6_2_8_lucio_molina_focazzio.ppt. Molina F. Lucio Augusto. La seguridad en los sistemas de información de las entidades públicas y los desafíos para las entidades de control fiscal: Falta de Estadísticas de Fraudes .

15

• En los casos en los que se hacen encuestas al personal, éstas son ambiguas debido a la falta de información y claridad sobre los conceptos por parte de quienes las elaboran; esto resulta en una interpretación aún más confusa de los datos que arrojan las mismas.

• Los fraudes informáticos que llegan a “feliz término” para el atacante usualmente no son descubiertos.

Estudios realizados3 a nivel latinoamericano por parte de IBM y Cisco Systems a 203 directores de tecnología y jefes de seguridad de entidades de Argentina, Chile, Brasil, Colombia, Venezuela y México; arrojan resultados no muy alentadores de igual manera, pues se encontró que la falta de información acerca del tema muchas veces desemboca en que las acciones tomadas por muchas entidades para enfrentar las amenazas, no tienen mucho que ver con los riesgos que se perciben al momento en que se realizan auditorías. Por otra parte, en la mayoría de entidades tienen que lidiar con dos importantes factores al momento de desarrollar e implementar un plan de seguridad informática:

• Limitaciones en el presupuesto: Este problema usualmente se presenta cuando los directivos no cuentan con suficiente información acerca de la criticidad de la seguridad de la información al interior de la entidad, y se considera que las inversiones y presupuesto asignados para hardware son suficientes. En las empresas latinoamericanas solamente un promedio de 14.5%4 del presupuesto total de las divisiones de información y tecnología es destinado a seguridad, mientras que en empresas en Estados Unidos esta cifra usualmente sobrepasa un 25% del presupuesto.

• Contradicciones entre conciencia y acción: Usualmente las entidades crean planes de contingencia y políticas que no son debidamente probados y divulgados de manera que sean de conocimiento y participación de todo el personal. Esto ocasiona que dichos documentos queden como un “papel más” y no sean tenidos en cuenta de la manera en que se debería.

Asimismo, la encuesta reveló que los ataques informáticos han aumentado en forma alarmante en los últimos tres años, estos son algunos de los resultados obtenidos:

• El 38% de los entrevistados manifestó que sus empresas habían sido atacadas5

• Las compañías mexicanas y brasileñas fueron las más afectadas con el 46% y el 42%6, respectivamente.

• El 63% manifestó que los riesgos en seguridad informática habían experimentado un "aumento espectacular" o habían "aumentado de alguna manera" en los últimos tres años7.

3 http://www.clarin.com/diario/2005/12/13/um/m-01106938.htm. Preocupa la falta de seguridad informática en Latinoamérica: Una de las falencias es la falta de presupuesto. Los “hackers” son la principal amenaza. Diciembre de 2005. ESTUDIO DE IBM Y CISCO. (En línea) 5 de mayo de 2005. 4 Ídem. 5 Ídem. 6 Ídem 7 Ídem

16

• Para casi la mitad de los entrevistados (el 47%) los "hackers" o piratas informáticos son la principal amenaza a la Red8.

• El 63% de las compañías entrevistadas no cuentan con un gerente o jefe de división de Información y Tecnología, de éstas solamente un 33% tenían programado contratar uno en un futuro próximo9.

A continuación se muestran estadísticas del Instituto de Seguridad Informática (CSI10 por sus siglas en inglés), contemplando presupuestos y principales ataques en el 2007.

Porcentaje de Presupuesto de IT Invertido en Seguridad

0% 5% 10% 15% 20% 25% 30%

Más de 10%

8 a 10%

6% a 7%

3% a 5%

1% a 2%

Menos del 1%

No se sabe

Po

rcen

taje

Año 2006Año 2007

Tabla No. 1. Presupuesto de IT invertido en seguridad

Tabla No. 2. Tipos de ataques registrados en el año 2007

8 Ídem 9 Ídem 10 El CSI proporciona educación sobre el manejo de la información, informática y seguridad de la red

17

8. Proceso

Nuestra propuesta de grado estaba basada en tres aspectos. El primero relacionado a recolectar información por medio de entrevistas, así como de documentos, con el fin de hacer unas correcciones al documento presentado por Andrea Mojica Caicedo, como proyecto de grado, en el semestre de 2007-2. El segundo enfocado en montar un ambiente de pruebas de algunos de los servidores de Colciencias, para detectar vulnerabilidades y corregirlas. La última, basada en investigación acerca de políticas de seguridad, que permitiera presentar un documento inicial de políticas globales formales de seguridad de la información, para Colciencias, así como un plan de contingencia básico para la entidad.

8.1. Fase 1: Reunión y corrección de información La fase uno del proyecto se enfocó en recolectar información encaminada a la corrección de un trabajo previo hecho en Colciencias en el 2007-2. Este trabajo se enfocaba en dar un diagnostico de seguridad de la información para la entidad, que le permitiera tomar las medidas convenientes para resolver las vulnerabilidades que poseía con respecto a la información.

Para esta fase, lo mismo que para las otras, se trazaron unos objetivos, unas actividades a desarrollar para cumplir con estos, además de unos entregables correspondientes a la fase.

8.1.1. Objetivos Fase I • Actualizar la información del documento Diagnóstico de Seguridad en Colciencias11.

• Corregir parte del documento Diagnóstico de Seguridad en Colciencias.

• Recopilar información con el fin de actualizar el documento Diagnóstico de Seguridad en Colciencias, además que nos sirva como fuente para las siguientes fases.

8.1.2. Tareas Fase I 1. Reunir al personal directivo de Colciencias con el fin de concientizarlos en relación a la

situación actual de seguridad informática a nivel mundial y la importancia de implementarla en la institución y obtener apoyo para el desarrollo del proyecto.

2. Revisar, actualizar y corregir las encuestas hechas al personal de Colciencias en el 2007-2. 3. Actualizar la lista de activos y configuración de red de Colciencias.

8.1.3. Entregables Fase I i. Cronograma de realización de tareas de todas las fases del proyecto. ii. Documento de Análisis de Vulnerabilidades corregido.

8.1.4. Trabajo realizado Para esta fase, con el fin de lograr los objetivos propuestos se realizaron una serie de actividades. Las cuales se nombran a continuación.

11 Documento correspondiente al proyecto de grado realizado por Andrea Mojica en 2007-2.

18

8.1.4.1. Entrevistas Se realizaron una serie de entrevistas a varias personas de Colciencias con el fin de corroborar la información que se encontraba plasmada en el documento entregado por Andrea Mojica en su proyecto de grado, y de esta manera hacer las correcciones respecti vas. • Entrevistas al Jefe de la División de Sistemas de Información en Ciencia y Tecnología • Entrevistas al Técnico de Seguridad de la División de Sistemas de Información en Ciencia y

Tecnología • Entrevista12 a la Subdirectora encargada, Subdirección de Programas de Innovación y

Desarrolla Empresarial. • Entrevista13 a la Subdirectora de la Subdirección Financiera y Administrativa. • Entrevista14 al Jefe de Control Interno.

De este trabajo se obtuvo información, que nos permitieron hacer las correcciones respectivas al documento Diagnóstico de Seguridad en Colciencias. Se presentan a continuación

8.1.4.1.1. Percepciones sobre el conocimiento de la seguridad en Colciencias Con el trabajo desarrollado en las entrevistas a los distintos actores dentro de Colciencias, logramos obtener una serie de percepciones, tanto del personal como de los altos directivos acerca del manejo de la seguridad de la información. Se listan a continuación:

• En Colciencias no se trabaja mucho el tema relacionado con la seguridad de la información. Por eso es importante empezar a hacer un plan de seguridad de la información que le ayude a la entidad a proteger en gran medida este recurso tan valioso para la institución.

• El área de Sistemas es la responsable de garantizar la seguridad de la información. Son quienes se encargan de generar las reglas dentro de la institución para el manejo de la información y los sistemas de información. Se debe tener en cuenta que una sola división de la institución no se puede encargar sola del tema de la seguridad de la información, debe haber apoyo especialmente de la alta gerencia para que los temas de seguridad funcionen correctamente.

• Son pocas las personas que saben acerca del buen manejo de la información, más concretamente, la seguridad de la información. Esto se debe a que en la institución no se ha creado un ambiente de seguridad relacionado con los temas de la información, por eso se debe empezar a generar interés en los funcionarios por el trabajo que hacen y vean la importancia de éste y así mismo ayuden a prote gerlo.

12 Mónica Salazar Acosta, Subdirectora Encargada, Subdirección de Programas de Innovación y Desarrolla Empresarial. 21 de abril de 2008. 13 Paola Nieto, Subdirectora, Subdirección Financiera y Administrativa. 23 de abril de 2008. 14 Guillermo Alba Cárdenas, Jefe de Control Interno. 24 de abril de 2008.

19

8.1.4.1.2. Validación servicios Colciencias15 La información que se presenta a continuación, fue dada por las personas que se encargan de manejar los servidores donde se encuentran los sistemas misionales16 de Colciencias, que son la base fundamental de la en tidad. Se recogió esta información como parte de nuestro trabajo para este proyecto, porque esta no fue dada con certeza cuando se realizó un primer acercamiento a la institución por parte de Andrea Mojica en su Proyecto de Grado. La Jefe de la División de Sistemas de Información en Ciencia y Tecnología; lo mismo que la encargada de la seguridad de la Información en esta área, nos solicitó actualizar esta información ya que se estaba mostrando algo de la entidad que en parte no era correcto. Según lo plantea Liliana Buitrago Jefe de la División de Sistemas de Información Ciencia y Tecnología, muchas de las personas encuestadas estaban dando información que no era cierta, y esto se debía a que ellos no estaban involucrados directamente con todos los sistemas de la entidad y por ende no conocían la criticidad de estos.

8.1.4.1.2.1. Eldorado2pro – Encuestada María Clemencia Reyes17 • ¿Cuál es la función de eldorado2pro de Colciencias?

Las funciones principales del servidor eldorado2_pro son:

ü PDC (Controlador de dominio primario), ü Servidor de datos del aplicativo Discovery (Mesa de ayuda y gestión de recursos) ü Consola del Antivirus para los clientes de la LAN y servidores internos ü Servicio primario de impresión ü DNS interno primario ü DHCP primario ü Tarificador telefónico DALI, ü Servidor del software PCounter (manejo de impresión)

8.1.4.1.2.2. WAIRA – Encuestada María Clemencia Reyes • ¿Cuál es la función del servidor WAIRA de Colciencias?

Las funciones principales del servidor WAIRA son:

ü BDC (Backup Domain Controller) ü Servicio de almacenamiento, maneja un POWERVAULT RAID 5 con 11 discos con

capacidad de 1 TB, donde se guardan datos como: (carpetas compartidas institucionales, carpetas compartidas por oficina, carpetas de respaldo de datos de usuarios, base de datos de la División de Recursos Humanos)

ü Software Nbpin para manejo de proyectos, software institucional, carpeta publica ü Mirror del DNS interno ü Servidor alterno de impresión

15 Utilizamos en este punto encuestado(a) a la persona responsable de dar la información. No se recolectó directamente del personal que se nombra, María Clemencia Reyes, uno de nuestros contactos en la entidad, se la envió a las respectivas personas para que diera esa información. 16 Misionales se refiere a los programas que usa la entidad para desarrollar sus actividades, ejemplos de estos tenemos a CvLAC, programa para servicio de registro de Pares evaluadores; DocLAC, servicio de registro de Doctorados Nacionales Publindex, servicio de registro de revistas en CyT; entre muchos otros. 17 María Clemencia Reyes es el Administrador de administradores de los sistemas de información de Colciencias, así como la encargada del manejo de la seguridad de los mismos.

20

ü PCounter para manejo de impresión. ü Consola de Discovery (recepción, cliente, traslado de información) ü Software Retrospect para el manejo del respaldo de los datos institucionales de los

clientes.

1. Por tener estos servicios ambos servidores de apoyo son críticos para la operación del personal de Colciencias. Para los sistemas misionales el servidor más crítico es huitaca, por ser el servidor donde se guardan las bases de datos de los sistemas Scienti y SIGP. Para la plataforma Scienti le sigue el servidor Scienti donde están alojados los servidores de aplicación de la plataforma, y quihicha donde se encuentra instalado el servidor de aplicaciones de SIGP.

Para el Portal que sería también un servicio misional, los servidores críticos son Zulia donde se encuentra el servidor de aplicaciones y lapola donde se encuentra la base de datos del mismo.

2. La mayoría de las áreas no tienen claro los 3 conceptos de seguridad en la información, para ellos lo crítico es la disponibilidad de la misma. Siempre reiteran en el respaldo.

3. Algunos servicios, por lo críticos se encuentran duplicados para tener un plan de contingenci a de los mismos, tales como el LDAP, el DNS, el DHCP, el Active Directory de Windows, la impresión. Para la seguridad de los servicios internos y externos se cuenta con la última versión de Checkpoint R65 instalada sobre una plataforma Nokia IP 390, con servicios de bloqueo de amenazas y contenidos maliciosos. Además para las labores de administración se instaló SSL Network Extender, que permite túneles con características de cifrado y hashing. Adicionalmente se cuenta con una SAN, para el respaldo de todos los servidores, así como con software de recuperación en caso de desastres.

4. Las áreas que son misionales y por lo tanto más críticas pertenecen a: las Subdirecciones de Programas e Innovación, ya que ellas apoyan el fomento a la investigación; la Subdirección de Programas Estratégicos que apoya la creación de una base social de capital humano, el fortalecimiento de las capacidades para la generación y gestión del conocimiento en CT+I, generación de sistemas de Información en CT+I a apropiación social de CT+I.

5. De acuerdo con la pregunta anterior, las herramientas y sistemas de información que apoyan las áreas mencionadas como críticas, son las de mayor riesgo y por eso son las que más deben protegerse.

6. Debido al escaso personal de la División de Sistemas, muchas actividades se concentran sólo en una persona, lo cual genera que la falta de alguna de ellas genere muchas dificultades. Esto se da en todos los sistemas de información, en los servidores Windows y en los servidores Solaris. En algunos serv icios (como JES, FW, Ironport, SIGP) se cuenta con contratos de soporte y mantenimiento, lo cual facilita un poco la falta de personal.

21

8.1.4.1.2.3. PORTAL – Encuestada Diana Patiño • ¿Cuál es la función del portal de Colciencias?

La función es la puerta de acceso a todos los servicios de información y la mayoría de los servicios operativos de Colciencias.

• ¿Qué servicios dependen del portal Los servicios que presta el portal son: ü La publicación de información institucional: Noticias, eventos, publicaciones

institucionales ü Acceso a otros sitios web que tienen relación con Colciencias: Fimbatec ü Acceso a convocatorias ü Registro de Peticiones, Quejas y Reclamos ü Acceso a seguimiento de proyectos ü Participación en Foros y Chat

• ¿Cómo está protegido el portal Cuenta con un sistema de autenticación de usuarios y definición de perfiles a través de permisos.

• ¿Cuáles serían las pérdidas (monetarias, imagen) y consecuencias si el portal se cayera durante un tiempo considerable? ü Impacto grande pues el portal es el acceso público a todos los servicios institucionales

y sus contenidos son considerados de carácter oficial. ü Las pérdidas se cuantifican en institucionalidad, imagen corporativa, y

monetariamente no se ha cuantificado el costo de perder la información del portal o las pérdidas ocasionadas por la pérdida de los aplicativos que lo soportan. En desarrollo del portal se ha invertido alrededor de 200 millones de pesos. Es importante incluir los costos de administración y recurso humano asociado.

8.1.4.1.2.4. SIGP –Encuestada Marlén Pineda • ¿Cuál es la función de este servicio?

El Sistema Integral de Gestión de Proyectos es un aplicativo J2EE que permite registrar y hacer control y seguimiento a anteproyectos y/o proyectos mediante un esquema de gestión parametrizada, compuesto por etapas, procesos y tareas.

• ¿Qué servicios dependen de SIGP? Los servicios son: ü Formulario para registrar anteproyectos en línea ü Aval de anteproyectos en línea ü Evaluación de anteproyectos en línea por pares evaluadores y comités ü Formulario off-line (fuera de línea) para registrar proyectos ü Evaluación de proyectos en línea por pares evaluadores ü Ejecución y Seguimiento a proyectos ü Formulario off-line (fuera de línea) para registrar estímulos tributarios ü Evaluación en línea de solicitudes de estímulos tributarios ü Seguimiento al proceso de estímulos tributarios

• ¿Cómo está protegido los servidores dónde se encuentran estos servicios?

22

Cada usuario que accede a cualquier servicio del SIGP, tiene un usuario y contraseña que previamente ha sido creado en el sistema de seguridad que tiene el aplicativo, a este usuario cuando se crea se le asigna un perfil, que le permite realizar consultas y/o actualizaciones en el SIGP y visualizar las opciones según el servicio al que esté accediendo.

• ¿Cuáles serían las pérdidas (mone tarias, imagen) y consecuencias si estos servicios se cayeran durante un tiempo considerable? Como estos servicios son misionales, las consecuencias de la no disponibilidad por un lapso considerable es crítico y deteriora la imagen de Colciencias, pues la mayoría de estos servicios se abren mediante convocatorias y tienen fechas estipuladas que hay que cumplirle a la comunidad científica.

• En cuánto operación, ¿cuántos usuarios internos necesitan de estos servicios para realizar su trabajo? ¿Para alcanzar la misión? ¿A qué áreas afectan principalmente? Los usuarios internos son aproximadamente 80, las áreas que afecta principalmente son los once (11) programas de ciencia y tecnología de Colciencias, la Oficina de Registro y el área jurídica y financiera.

8.1.4.1.2.5. SCIENTI – Encuestado Omar Figueroa • ¿Cuál es la función de esta plataforma?

La plataforma de la red ScienTI se considera como un espacio común de integración e intercambio de información de los sistemas de ciencia y tecnología, disponible en Internet. Su función general es recolectar, mantener, actualizar y visualizar información de todos los actores del Sistema Nacional de Ciencia y Tecnología del país – SNCyT, producir estadísticas e indicadores en CyT, fomentar y difundir las capacidades en CyT del país, todo ello a través de diferentes módulos y/o aplicativos que mediante convocatorias públicas permiten a los diferentes actores su participación.

• ¿Qué servicios dependen de ScienTI? Los servicios que dependen del ScienTI son: ü Servicio de registro de investigadores, técnicos y personal de apoyo a la investigación

– Hojas de vida (CvLAC) ü Servicio de registro de grupos de investigación en CyT e Innovación (GrupLAC) ü Servicio de registro de Instituciones en CyT e Innovación (InstituLAC) ü Servicio de registro de Pares evaluadores (CvLAC) ü Servicio de registro de Doctorados Nacionales (DocLAC) ü Servicio de registro a Jóvenes Investigadores ü Servicio de registro de créditos condonables ü Servicio de registro de revistas en CyT (publindex) ü Servicio de registro de convocatorias de Recursos Humanos en CyT ü Servicio de selección de pares evaluadores – modulo de medición (CvLAC) ü Servicio de escalafonamiento de grupos de investigación en CyT e Innovación –modulo

de medición (GrupLAC) ü Servicio de aval institucional a grupos de investigación en CyT e Innovación ü Servicio de selección, evaluación y seguimiento de programas de Doctorados

Nacionales ü Servicio de selección, evaluación y seguimiento de Jóvenes investigadores

23

ü Servicio de selección, evaluación y seguimiento de créditos condonables ü Servicio de selección, evaluación y escalafonamiento de revistas en CyT ü Servicios de consulta de: Investigadores, grupos, instituciones, programas doctorales,

revistas

• ¿Cómo está protegido este servicio? Cada uno de los aplicativos tiene definido su esquema de seguridad, en donde se tiene opciones que son de uso público y opciones de uso restringido, para las opciones restringidas se requiere de un “login” y una “clave” que son en algunos casos definidas por el usuario y otras definidas por Colciencias. En el caso de las definidas por Colciencias se tienen definidos roles para diferentes tipos de usuarios (ej: usuario administrador, usuario del aplicativo)

• ¿Cuáles serían las pérdidas (monetarias, imagen) y consecuencias si estos servicios se cayeran durante un tiempo considerable? Las pérdidas monetarias son de difícil calculo, en ellas estaría involucrado mínimo 6 años de trabajo de personal interno, grupos de desarrollo externo, asesores etc.

Pérdida de imagen de la Entidad y pérdida en la confianza que los diferentes actores del Sistema Nacional de Ciencia y Tecnología e Innovación (investigadores, directores de grupos de investigación, universidades, empresarios etc.etc) tienen de la entidad, de sus procesos y de su información.

8.1.4.2. Activos de la Institución18 Para el desarrollo adecuado de la segunda fase de este proyecto, fue necesario hacer una recolección de los activos que son más críticos para la institución. Estos activos fueron obtenidos de diversas reuniones que se hicieron con los funcionarios de la División de Sistemas de Información en Ciencia y Tecnología. En la sesión 8.2.4.1., se muestran los activos19 que Colciencias posee para el manejo de la información, y de los cuales vamos a tomar algunos para hacer las respectivas simulaciones y dar la guía adecuada para solucionar los problemas que presentan en relación a la seguridad.

8.1.4.2.1. Mapa Red LAN Colciencias El mapa que se muestra continuación corresponde a la última actualización de la red LAN de Colciencias. Este fue obtenido de una reunión con María Clemencia Reyes, encargada de la seguridad en la entidad.

18 Los activos que se listan no son todos los de Colciencias, solamente se listan los que están directamente relacionados con nuestro proyecto. 19 No se describirán en detalle los activos de la institución por cuestiones de seguridad, se dará el nombre y una pequeña descripción de estos.

24

8.1.4.3. Corrección de Documento Con la información recolectada en la primera fase del proyecto, se hizo unas correcciones al documento Diagnóstico de Seguridad en Colciencias, presentado por Andrea Mojica en su trabajo de grado. La idea era recopilar información y validar otra que había sido expuesta en ese documento y no concordaba con lo que realmente había la institución a la realización de este documento. El documento de corrección no se presenta aquí, por lo extenso de su contenido. Sin embargo la versión preliminar de este, hecho por Andrea Mojica, la pueden consultar en los documentos de grado en la Biblioteca de la Universidad de Los Andes. Las correcciones hechas al documento fueron aprobadas por Liliana Buitrago y María Clemencia Reyes, jefe de la División de Sistemas de Información en Ciencia y Tecnología y el administrador de la Seguridad de la Información de la División, respectivamente.

25

8.2. Fase 2: Implementación de escenario de pruebas y mitigación de riesgos encontrados

El fin de este ambiente es determinar cuáles son las vulnerabilidades más críticas de la entidad, y hacer las respectivas listas de chequeo de cómo mitigar en cierta medida esos riesgos. A continuación se presenta los objetivos de esta parte del proyecto, así como las tareas esperadas, también los respectivos entregables y por último el trabajo desarrollado.

8.2.1. Objetivos Fase II • Generar un escenario de pruebas que emule la configuración de algunos de los servidores actuales de Colciencias.

• Mitigar las vulnerabilidades más críticas de Colciencias por medio de la simulación sin afectar el ambiente de producción de la institución.

• Realizar una lista de chequeo que ayude a minimizar los riesgos encontrados y que se trataron de corregir en el ambiente virtual realizado.

8.2.2. Tareas Fase II 1. Montar un ambiente que emule la configuración del bosque de servidores de Colciencias

utilizando máquinas virtuales en los laboratorios de la Universidad de los Andes o donde sea necesario.

2. Basándonos en las vulnerabilidades encontradas y las que ya están documentadas (Análisis de Vulnerabilidades del segundo semestre del año 2007), hacer las pruebas, actualizaciones e instalaciones de software, necesarias que aseguren en cierta medida una red segura.

8.2.3. Entregables Fase II i. Documento que muestra los pasos a seguir por el personal asignado de Colciencias para

mitigar los riesgos existentes, este documento se generará paralelamente a la realización de las pruebas.

ii. Revisión y confirmación del documento (personal de la División Sistemas de Información en Ciencia y Tecnología de Colciencias).

8.2.4. Trabajo realizado Para esta fase del proyecto se propusieron unas tareas a desarrollar para poder cumplir con los objetivos y entregables de la fase. Se menci onan a continuación.

8.2.4.1. Investigación Como parte del trabajo de grado, se montó un bosque virtual de algunos servidores de Colciencias para hacer los respectivos correctivos a los problemas de seguridad que tienen esos sistemas. Para ello se investigó sobre algunos de los sistemas de información de la

26

entidad, a los cuales se les realizó unas pruebas de seguridad, que nos arrojó las fallas que tenían.

8.2.4.1.1. Servidores Colciencias A continuación se muestra el listado de algunos de los servidores que tiene Colciencias , en los cuales se almacena información de la entidad, así como los programas que maneja la misma, para el trabajo que desarrolla a diario. Se aclara que la entidad tiene más servidores, no se mencionan aquí porque están fuera del alcance de nuestro trabajo.

• HUITACA:

ü Servidor marca SUN, modelo FIRE 280R, con dos (2) procesadores UltraSparc III de 900 Mhz,

ü Assembled 18 December 2001 ü Especificaciones de hardware:

o 4 discos duros: 2 de 36 GB, 1 de 72 GB y 1 de 300 GB o Unidad de DVD o Tarjeta de video o Unidad de cinta DDS4 o Arreglo de discos Storedge D2 con 4 discos duros de 36 GB cada uno y 1 de

300GB ü Servicios ofrecidos:

o Servidor de base de datos Oracle 9i y Oracle10g de la red ScienTI y Publindex (SILAC1), del Sistema Integral de gestión de proyectos SIGP, del CORDIS, y SAIB-Maxcal (aplicación del centro de documentación)

ü Aplicaciones: o SIGP WEB, puerto 1521 o SID: SIGP10G o CVLAC SIGP, puerto 1522/1525 o SID: SILAC1

• QUIHICHA:

ü Servidor marca SUN, modeloT2000, 4 core 1.0 Ghz UltraSparc T1 processor ü Sistema Operativo: Solaris 10 6/06 s10s_u2wos_09a SPARC ü Assembled 09 June 2006 ü Especificaciones de hardware:

o 2 discos duros internos de 73 GB o Unidad de DVD

ü Servicios ofrecidos: o Servidor de aplicaciones del Sistema Integral de SIGP o IAS de Oracle o Plataforma JES

ü Aplicaciones: o OAS 10g, puertos 7777 y 1156, Versión 10.1.2.0.2

27

• SCIENTI:

ü Servidor marca SUN, modelo FIRE 280R ü Sistema operativo: Solaris 10 6/06 s10s_u2wos_09a SPARC ü Assembled 09 June 2006 ü Especificaciones de hardware:

o 3 discos duros: 2 de 36 GB y uno de 300 GB o Unidad de DVD o Tarjeta de video

ü Aplicaciones: o jboss-3.2.5-search o jboss-4.0.1sp1-estadistico o jboss-4.0.1sp1-cvlac_colc o jboss-3.2.1_appl o jboss-4.0.1sp1-publindex

• ZULIA:

ü Servidor marca SUN, modelo FIRE 280R, con dos procesadores de 1.2GHz,

UltraSparcIII ü Sistema Operativo: Solaris 10 8/07 ü Especificaciones de hardware:

o 2 discos duros de 73GB o Unidad de DVD o 2 fuentes de potencia o Tarjeta de red FastEthernet 10/100 o Tarjeta de video SUN XVR-100 graphics

ü Servicios ofrecidos: o DNS secundario o LDAP secundario o Portal Web

ü Aplicaciones: o Apache 2 o Jboss_3.2.5

• ELDORADO2PRO:

ü Servidor marca DELL, modelo Poweredge 6400, con dos procesadores Intel Pentium III XEON de 700 MHz ü Sistema Operativo: Windows Server 2003 ü Especificaciones de hardware:

o 3 discos duros de 16 GB en Raid 5 o Unidad de CD-ROM o Tarjeta de red Intel PRO/100

ü Servicios ofrecidos: o Balaceo de carga de la conexión de red o Servidor DHCP

28

o Cliente Dial-Up o Administración de conexiones de acceso remoto o Manejo de archivos e impresoras compartidas para redes Microsoft o Clasificador genérico de paquetes o Gateway de capa de aplicación o Servidor de Dial -Up o Configuración Wireless o Controlador de Firewall Trend Micro Common

ü Aplicaciones: o Tarificador Dali o Antivirus para clientes de la LAN o Pcounter (manejo de impresiones)

8.2.4.1.2. Entrenamiento

El trabajo fundamental de esta parte, era aprender los conceptos básicos de Unix y Windows server 2003 para poder generar los respectivos ambientes virtuales. Con esto se busca aprender el dominio de estos sistemas operativos, que nos facilitara el trabajo que se realizaría posteriormente. Esto básicamente se enfocaba a configurar los servicios de los servidores, que fueran acordes a los que se manejan en Colciencias.

8.2.4.2. Pruebas Para poder implementar el bosque virtual de algunos de los servidores de Colciencias, simular el funcionamiento de estos, que nos lleve a dar solución a los problemas más críticos en relación al manejo de la información, se realizaron varias pruebas a los servidores de la entidad. Unas locales y otras remotas, estas pruebas se hicieron utilizando la herramienta Nessus20. La idea de hacer pruebas locales y remotas, surge porque en ciertas ocasiones las vulnerabilidades que presenta un sistema desde su red interna (LAN), varía en relación a las de la red externa (WAN). Queríamos comparar dicha información para encontrar diferentes vulnerabilidades y de esta manera corregirlas y hacer más seguros los servidores.

Para hacer estas pruebas se tomó la decisión con María Clemencia Reyes, encargada de la parte de seguridad en Colciencias, trabajar con los servidores21 más críticos de la entidad. Se listan a continuación.

• Zulia • Huitaca • Scienti • Eldorado2pro • Quihicha

20 Para mayor información sobre la herramienta, descargas e instalación, pueden consultar: http://www.nessus.org/nessus/ 21 Para ver descripción de los servidores, diríjase al numeral 8.2.4.1.1

29

8.2.4.2.1. Pruebas Locales22

Las pruebas en los servidores de Colciencias, se fundamentan en brindarnos la información necesaria con respecto a la seguridad de la información, con la cual montar el bosque virtual y generar las pruebas que ayuden a mitigar los riesgos y que lleve a mejorar la seguridad en Colciencias. De las pruebas locales se presenta la siguiente información. Fue obtenida de los servidores dentro de la misma red. Los colores representan el grado de criticidad del riesgo encontrado: Naranja nivel medio y rojo nivel alto. No se presentan los riesgos de nivel bajo porque estos no generan peligro para el servidor y por consecuente para la información que se encuentra almacenada en este.

8.2.4.2.1.1. Servidor Zulia Luego de realizar las pruebas respectivas estando en un equipo conectado directamente a la LAN de Colciencias, se descubrieron las siguientes vulnerabilidades:

v Enumeración de nombres en e l servidor remoto

• Es posible enumerar los nombres de usuarios válidos en el servidor remoto: El servidor SMTP remoto responde a los comandos EXPN y/o VRFY.

El comando EXPN puede ser usado para encontrar la dirección de entrega de alias de correo, e incluso el nombre completo de quienes reciben, y el comando VRFY puede ser usado para revisar la validez de una cuenta.

El servidor de correo no debería permitir a usuarios remotos el uso de estos comandos, pues les suministra demasiada información.

• Solución: En caso de estar utilizando Sendmail, agregar la opción:

O PrivacyOptions=goaway

En el archivo /etc/sendmail.cf

v Versión de PHP vulnerable a buffer overflows

• El servidor remoto utiliza una versión de PHP que está afectada por múltiples buffer overflows: La versión de PHP instalada en el servidor es menor a 5.2, dichas versiones son altamente vulnerables a buffer overflows.

Para explotar la vulnerabilidad, un atacante necesitaría tener habilidad para subir un script de PHP al servidor, o tener la capacidad de manejar múltiples variables procesadas por algunas funciones de PHP como htmlentities().

• Solución: Actualizar la versión de PHP a 5.2.5 o mayor.

22 Los resultados totales de las pruebas se encuentran en el Anexo A-2

30

v Métodos HTTP TRACE / TRACK

• Las funciones de depuración están habilitadas en el servidor Web remoto: El servidor remoto soporta los métodos TRACE y/o TRACK; ambos son métodos HTTP usados para depurar conexiones de servidores Web.

Adicionalmente, se ha demostrado que los servidores que soportan el método TRACE son vulnerables a ataques XSS (Cross Site Scripting) y XST (Cross Site Tracing) usados en conjunto con varias debilidades encontradas en los navegadores. Un atacante puede usar esta vulnerabilidad para engañar a los usuarios oficiales del sitio Web de la institución y obtener sus credenciales, por ejemplo.

• Solución: Deshabilitar ambos métodos mencionados.

v Vulnerabilidades del servidor LDAP

• El servidor LDAP está expuesto a múltiples vulnerabilidades: EL servidor remoto está corriendo el Servidor de Sistema de Directorios de Sun Java, un servidor LDAP de Sun Microsystems.

La versión remota de este servicio está afectada por múltiples vulnerabilidades. Las versiones 6.0 y 5.2 con parche 5 son vulnerables a:

o Divulgación de la información de listas de atributos

o Acceso no autorizado (restringido a súper-usuarios)

Las versiones anteriores a 5.2 con parche 5 son vulnerables a:

o Negación de servicio debido a manejador de decodificación BER

o Corrupción de memoria en el fallo del manejador de peticiones

• Solución: Actualizar el Servidor de Sistema de Directorios de Sun Java a la versión 5.2 parche 5 ó 6.1

v LDAP Permite conexiones anónimas

• El servidor LDAP permite acceso anónimo: La configuración actual permite hacer conexiones al servidor sin necesidad de autorización –utilizando ‘NULL BIND’- y pedir información. A pesar de que las consultas permitidas puede que sean restringidas, puede que un potencial atacante logre obtener información confidencial.

• Solución: Configurar el servidor LDAP de manera que no acepte NULL BINDS

31

v LDAP Permite NULL BASE

• Es posible revelar información LDAP: Los servidores LDAP que no están configurados correctamente permiten el directorio BASE configurado como NULL (nulo).

Esto permite que la información sea seleccionada sin ningún conocimiento previo de la estructura de la estructura del directorio. Junto con un NULL BIND, un usuario anónimo puede consultar el servidor LDAP usando alguna herramienta especializada como ‘LdapMiner’.

• Solución: Desactivar las consultas NULL BASE en el servidor LDAP.

v Detección de servidor RSH

• El servicio rsh está corriendo: El servidor remoto está corriendo el servicio ‘rsh’, este servicio es peligroso en el sentido en que no está cifrado – es decir, cualquier persona podría mirar el tráfico que pasa entre un cliente y el servidor rsh con una herramienta de sniffing. Esto incluye nombres de usuario y contraseñas.

Conjuntamente, esta vulnerabilidad también permite el uso de nombres de usuario pobremente autenticados incluso sin uso de contraseña.

Si el servidor es vulnerable a ataques de tipo TCP sequence number guessing (desde cualquier red) o IP Spoofing (incluyendo ARP hijacking en la red local), entonces puede ser posible incluso saltarse la autenticación.

Finalmente, rsh es una vía fácil para convertir permisos de escritura de archivos en inicios de sesión completos utilizando los archivos .rhosts o rhosts.equiv.

• Solución: Deshabilitar este servicio y utilizar ssh en su lugar. Comentar la línea ‘rsh’ en el archivo /etc/inetd.conf.

v Versión de Apache vulnerable a buffer overflow

• La versión de Apache instalada en el servidor es vulnerable a un ataque buffer overflow off-by-one: La versión de Apache que está corriendo en el servidor es menor a 2.0.59. Esta versión contiene un buffer overflow off-by-one en el módulo mod_rewrite.

• Solución: Actualizar la instalación actual de Apache a una versión mayor a 2.0.59.

v Numeración de usuarios con sesiones abiertas

• Es posible saber el número actual de usuarios con sesiones abiertas: El servicio rusersd RPC está corriendo, provee a un atacante información tal como qué tan

32

seguido está siendo utilizado un sistema, los nombres de usuarios que tienen sesión iniciada, etc..

• Solución: Deshabilitar este servicio si no se necesita para nada más.

v Transferencias de zonas DNS

• El servidor remoto permite realizar transferencias de zonas de DNS: Esto permite que un atacante obtenga instantáneamente una lista de posibles sitios para atacar. En adición a esto, las compañías tienden a poner a los servidores nombres que indican la aplicación primaria que estos corren (como proxy.company.com).

Esta información es muy útil para un atacante que quiera especular acerca de la topología de la red con el fin de buscar nuevos posibles ataques.

• Solución: Restringir la transferencia de zonas DNS solamente a aquellos servidores en que sea necesario.

v Obtención de información vía SNMP

• La información del sistema del servidor remoto puede ser obtenida vía SNMP: Es posible obtener información del servidor remoto envinando peticiones SNMP con el OID 1.3.6.1.2.1.1.1.

Un atacante puede utilizar esta información para ganar más conocimiento sobre el servidor que intenta atacar.

• La lista de tarjetas de interfaz de red del servidor remoto puede ser obtenido vía SNMP: Es posible obtener la lista de tarjetas de red instaladas en el servidor remoto enviando peticiones SNMP con el OID 1.3. 6.1.2.1.2.1.0.

Un atacante puede usar esta información para ganar más conocimiento sobre el servidor que intenta atacar.

• La lista de procesos que están corriendo el servidor remoto puede ser obtenida vía SNMP: Es posible obtener la lista de procesos que están corriendo actualmente en el servidor remoto enviando peticiones SNMP con OID 1.3.6.1.2.1.25.4.2.1.2.


• El nombre de la comunidad del servidor SNMP remoto puede ser adivinado: Es posible obtener los nombres por defecto de comunidad del servidor SNMP.

33

Un atacante puede utilizar esta información para ganar conocimiento sobre el servidor que intenta atacar, o cambiar la configuración del sistema remoto (si la comunidad por defecto permite este tipo de modificación).

• Solución: Deshabilitar el servicio SNMP de el servidor remoto en caso de no estar en uso, o filtrar los paquetes UDP entrantes que se dirijan hacia este puerto (161/udp). Cambiar la cadena de caracteres que viene por defecto como nombre de la comunidad.

v DNS Cache Snooping

• El servidor remoto es vulnerable a ataques de “fisgoneo” de cache: El servidor DNS remoto responde consultas a dominios de terceros que no tienen configurado el bit de recursión. Esto puede permitir que un atacante determinar cuáles dominios han sido resueltos últimamente, por lo tanto, puede saber que clientes han sido visitados recientemente.

Por ejemplo, si un atacante está interesado en saber qué servicio web de tipo financiero utiliza la compañía, podría utilizar este tipo de ataque para construir un modelo estadístico de que tanto se utiliza este servicio financiero.

Por supuesto, el ataque puede ser utilizado para encontrar quienes son los socios directos de la compañía, tener patrones de navegación, servidores de correo externos, etc.

• Solución: Restringir el acceso al cache del DNS para usuarios locales.

v Servidor de Nombres Remoto Usable

• El servidor de nombres remoto permite la ejecución de consultas recursivas realizadas por el cliente usando nessusd: Es posible consultar al servidor de nombres remoto acerca de nombres de terceros. Si este es el servidor de nombres internos, esta advertencia puede ser pasada por alto.

Por el contrario, si es un servidor de nombres remoto, puede permitir a cualquiera utilizarlo como servidor para resolver nombres de terceros (como www.google.com). Esto permite a hackers realizar envenenamiento del cache del servidor de nombres. Si el servidor permite hacer estas consultas vía UDP, el servidor puede ser utilizado como “rebote” para realizar un ataque de negación de servicio contra otras redes.

• Solución: Restringir las consultas recursivas a todos los clientes que utilicen este servidor de nombres (por ejemplo, los clientes de la LAN conectados a él). Si está utilizando bind 8, puede hacerse esto utilizando la instrucción “allow-recursion” en la sección “options” de el archivo named.conf. Si está usando bind 9, puede definir un grupo de direcciones internas utilizando el comando “acl”; dentro del bloque de

34

opciones, puede escribir este comando: ‘allow-recursion { hosts_defined_in_acl }’. Si está utilizando otro servidor de nombres, consulte la documentación del mismo.

8.2.4.2.1.2. Servidor Huitaca Luego de realizar las pruebas respectivas estando en un equipo conectado directamente a la LAN de Colciencias, se descubrieron las siguientes vulnerabilidades:

v Servidor FTP vulnerable a ‘glob heap corruption’

• El software manejador del servidor FTP es vulnerable a un ataque ‘glob heap corruption’: Un atacante puede utilizar esta vulnerabilidad para ejecutar comandos arbitrarios en el servidor.

• Solución: Actualizar el software del servidor FTP a una versión más reciente.

v Vulnerabilidad en el puerto de SSH

• Es posible ejecutar código arbitrario en el servidor remoto: De acuerdo a lo evaluado por Nessus, el servidor es vulnerable a cualquiera de estas vulnerabilidades específicas:

o CVE – 2002 – 1357 (longitud incorrecta)

o CVE – 2002 – 1358 (listas con elementos vacíos/cadenas de caracteres vacías)

o CVE – 2002 – 1359 (paquetes grandes y campos grandes)

o CVE – 2002 – 1360 (campos de cadenas de caracteres que contienen ceros)

o Estas vulnerabilidades permiten que un atacante ejecute código arbitrario con los privilegios del proceso SSH, los cuales usualmente son de súper usuario (root).

• Solución: Actualizar la versión de SSH a una que no esté afectada.

v Versión de SSH está desactualizada

• La versión de SSH que utiliza actualmente el servidor es actual a 3.1.5 o 3.2.2: Esta versión contiene una debilidad, permite a un usuario cualquiera obtener mayores privilegios debido a una falencia en el modo en que es utilizada la función setsid().

• Solución: Actualizar a la última versión de SSH.

35

v Vulnerabilidad de formato en cadenas de caracteres

• El servidor SSH remoto puede estar afectado por una vulnerabilidad de cadena de caracteres: El servidor remoto está corriendo SSH Tectia Server. De acuerdo al análisis de Nessus, la versión actual del servidor SSH contiene una vulnerabilidad en el formato de las cadenas de caracteres en su subsistema sftp.

Un atacante no autenticado puede ejecutar código arbitrario en el servidor dependiendo de los privilegios que pueda llegar a obtener o incluso bajar totalmente los servicios ofrecidos por el mismo.

• Solución: Una solución temporal es desactivar el subsistema sftp de la manera en que explican en este23 link. Sin embargo, una mejor solución es actualizar el servidor SSH Tectia a la versión 4.3.7, 4.4.2 o mayor.

v Enumeración de nombres de usuario válidos

• Es posible enumerar los nombres de usuario válidos en el servidor remoto: El servidor SMTP remoto responde a los comandos EXPN y/o VRFY. El comando EXPN puede ser usado para encontrar el alias de la dirección de destino, o incluso el nombre completo de quien va a recibir el correo, el comando VRFY puede ser usado para verificar la validez de una cuenta. El servidor de correo no debería permitir a los usuarios ejecutar estos comandos, pues les da demasiada información.

• Solución: En caso de estar usando Sendmail, agregar la opción: O PrivacyOptions=goaway en el archivo /etc/sendmail.cf.






23 http://www.ssh.com/company/news/article/715/

36

• Solución: Deshabilitar es te servicio y utilizar ssh en su lugar. Comentar la linea ‘rsh’ en el archivo /etc/inetd.conf.




• La lista de tarjetas de interfaz de red del servidor remoto puede ser obtenido vía SNMP: Es posible obtener la lista de tarjetas de red instaladas en el servidor remoto enviando peticiones SNMP con el OID 1.3.6.1.2.1.2.1.0.





8.2.4.2.1.3. Servidor Scienti

Luego de realizar las pruebas respectivas estando en un equipo conectado directamente a la LAN de Colciencias, se descubrieron las siguientes vulnerabilidades:

v Enumeración de nombres en el servidor remoto

• Es posible enumerar los nombres de usuarios válidos en el servidor remoto: El servidor SMTP remoto responde a los comandos EXPN y/o VRFY.



37

• Solución: En caso de estar utilizando Sendmail, agregar la opción:




• Las funciones de depuración están habilitadas en el servidor Web remoto: El servidor remoto soporta los métodos TRACE y/o TRACK; ambos son métodos HTTP usados para depurar conexiones de servidores Web.



v Consola de manejo de Sun vulnerable a Negación de Servicio

• El conector AJP del servidor remoto está afectado por una vulnerabilidad de negación de servicio: La versión de Apache Tomcat instalada en el servidor remoto sufre de una vulnerabilidad de negación de servicio debido a su falla para manejar entradas mal formsdas. Enviando una petición AJP12 especialmente formada, un atacante no autenticado, puede causar que Tomcat deje de responder. En el momento, los detalles de la naturaleza específica de dichas peticiones no son muy conocidas.

• Solución: Actualizar la versión de Apache Tomcat a 5.x o mayor.

v Acceso no autenticado es permitido en el servidor Web remoto

• El servidor Web remoto permite acceso no autorizado a un Java Servlet administrativo: El servidor remoto aparentemente tiene una versión de JBoss que permite acceso no autorizado al JMX y/o Web Console servlets usado para administrar JBoss y sus servicios. Un atacante remoto puede usar esta vulnerabilidad como palanca para obtener información sensible sobre la aplicación afectada e incluso tomar control de la misma.

• Solución: Asegurar el acceso al JMX/Web Console siguiendo las instrucciones de este WIKI24

24 http://wiki.jboss.org/wiki/SecureTheJmxConsole

38

v Utilización de un servicio de Java afectado por vulnerabilidad

• El servidor remoto contiene un servicio de Java que está afectado por una falla en los directorios: El servicio Web remoto parece tener una versión de JBoss que falla en la revisión de datos ingresados por el usuario al parámetro BaseDir utilizado por el servicio ‘DeploymentFileRepository’ de la consola JMX antes de utilizarlo para guardar o eliminar archivos. Un atacante no autenticado puede ser capaz de explotar esta vulnerabilidad para alterar archivos en el cliente remoto sujeto de los privilegios del uso de JBoss.

• Solución: Asegurar el acceso al JMX/Web Console siguiendo las instrucciones de este WIKI25

v Falla de revelación de información

• El servidor remoto está afectado por una falla de revelación de información: El servidor JBoss remoto es vulnerable a una falla de revelación de información que puede permitir a un atacante recuperar el camino de instalación del servidor, su política de seguridad, o adivinar su número de versión exacto. Un atacante puede utilizar esta vulnerabilidad para obtener más información acerca de la configuración del servidor remoto.

• Solución: Actualizar la versión de JBoss a 3.2.8 o 4.0.3. O editar el archivo de configuración de JBoss ‘jboss-service.xml’, poner ‘DownloadServerClasses’ en ‘false’ y reiniciar el servidor.


• Es posible saber el número actual de usuarios con sesiones abiertas: El servicio rusersd RPC está corriendo, provee a un atacante información tal como qué tan seguido está siendo utilizado un sistema, los nombres de usuarios que tienen sesión iniciada, etc..

• Solución: Deshabilitar este servicio si no se necesita para nada más.




25 http://wiki.jboss.org/wiki/SecureTheJmxConsole

39

• La lista de tarjetas de interfaz de red del servidor remoto puede ser obtenido vía SNMP: Es posible obtener la lista de tarjetas de red instaladas en el servidor remoto enviando peticiones SNMP con el OID 1.3.6.1.2.1.2.1.0.


• La lista de procesos que están corriendo el servidor remoto puede ser obtenida vía SNMP: Es posible obtener la lista de procesos que están corriendo actualmente en el servidor remoto enviando peticiones SNMP con OID 1.3.6.1.2.1.25.4.2.1.2.




• La lista de software instalado actualmente en el servidor puede ser obtenida vía SNMP: Es posible obtener la lista de software instalado en el servidor remoto enviando peticiones SNMP con OID 1.3.6.1.2.1.25.6.3.1.2.



8.2.4.2.1.4 Servidor Eldorado2pro Luego de realizar las pruebas respectivas estando en un equipo conectado directamente a la LAN de Colciencias, se descubrieron las siguientes vulnerabilidades:


• El servidor LDAP permite acceso anónimo: La configuración actual permite hacer conexiones al servidor sin necesidad de autorización –utilizando ‘NULL BIND’- y pedir información. A pesar de que las consultas permitidas puede que sean restringidas, puede que un potencial atacante logre obtener información confidencial.

• Solución: Configurar el servidor LDAP de manera que no acepte NULL BINDS

40


• Es posible revelar información LDAP: Los servidores LDAP que no están configurados correctamente permiten el directorio BASE configurado como NULL (nulo).



v Utilización de un protocolo SSL desaprobado

• El servicio remoto cifra la información utilizando un protocolo con vulnerabilidades conocidas: El servicio remoto acepta conexiones cifradas usando SSL 2.0, el cual es conocido que sufre de varias fallas criptográficas y ha sido desaprobado por varios años.

Un atacante potencial podría explotar cualquiera de las debilidades conocidas y ha sido desaprobado durante varios años. Igualmente, puede explotar esta vulnerabilidad para reproducir ataques de tipo man-in-the-middle o descifrar las comunicaciones entre el servicio afectado y los clientes.

• Solución: Consultar la documentación de la aplicación para deshabilitar el uso de SSL 2.0 y usar SSL 3.0 o TSL 1.0 en su lugar.

v Paquetes de cifrado SSL pobremente soportados

• El servicio remoto soporta el uso de cifradores SSL débiles: El cliente remoto soporta el uso de cifradores SSL que ofrecen cifrado débil de información o ningún cifrado en absoluto.

• Solución: Reconfigurar la aplicación afectada si es posible para evitar el uso de cifradores de información débiles.

v Microsoft Windows Remote Desktop Protocol Server Pri vate Key Disclosure Vulnerability

• Es posible tener acceso al cliente remoto: La versión remota del Remote Desktop Protocol Server (Terminal Service) es vulnerable a un ataque de tipo man-in-the-middle.

Un atacante puede explotar esta vulnerabilidad para descifrar comunicaciones entre cliente y servidor y obtener información sensitiva (contraseñas, etc..).

• Solución: Forzar el uso de SSL como capa de transporte para este servicio especifico.

41


• El servidor remoto es vulnerable a ataques de “fisgoneo” de cache: El servidor DNS remoto responde consultas a dominios de terceros que no tienen configurado el bit de recursión. Esto puede permitir que un atacante determinar cuáles dominios han sido resueltos últimamente, por lo tanto, puede saber que clientes han sido visitados recientemente.

Por ejemplo, si un atacante quisiera saber está interesado en saber qué servicio web de tipo financiero utiliza la compañía, podría utilizar este tipo de ataque para construir un modelo estadístico de que tanto se utiliza este servicio financiero.


• Solución: Restringir el acceso al cache del DNS para usuarios locales.


• El servidor de nombres remoto permite la ejecución de consultas recursivas realizadas por el cliente usando nessusd: Es posible consultar al servidor de nombres remoto acerca de nombres de terceros. Si este es el servidor de nombres internos, esta advertencia puede ser pasada por alto.


• Solución: Restringir las consultas recursivas a todos los clientes que utilicen este servidor de nombres (por ejemplo, los clientes de la LAN conectados a él). Si está utilizando bind 8, puede hacerse esto utilizando la instrucción “allow-recursion” en la sección “options” de el archivo named.conf. Si está usando bind 9, puede definir un grupo de direcciones internas utilizando el comando “acl”; dentro del bloque de opciones, puede escribir este comando: ‘allow-recursion { hosts_defined_in_acl }’. Si está utilizando otro servidor de nombres, consulte la documentación del mismo.

8.2.4.2.1.5 Servidor Quihicha

Luego de realizar las pruebas respectivas estando en un equipo conectado directamente a la LAN de Colciencias, se descubrieron las siguientes vulnerabilidades:

42






• Solución: Deshabilitar este servicio y utilizar ssh en su lugar. Comentar la línea ‘rsh’ en el archivo /etc/inetd.conf.


• Las funciones de depuración están habilitadas en el servidor Web remoto: El servidor remoto soporta los métod os TRACE y/o TRACK; ambos son métodos HTTP usados para depurar conexiones de servidores Web.



v Fast-CGI samples Cross Site Samples

• Dos muestras CGI suministradas con FastCGI son vulnerables a ataques XSS: FastCGI es una extensión abierta a CGI que suministra un alto desempeño sin las limitaciones de API’s específicos, está incluido en la instalación por defecto de ‘Unbreakable’ Oracle 9i Application Server.

Dos muestras de CGI vienen con FastCGI (echo y echo2). La salida de estos dos CGI’s es una lista de variables de entorno e información de PATH para varias aplicaciones. También muestran cualquier parámetro que les haya sido suministrado. Por esto, un ataque XSS puede ser hecho vía un link como este: http://www.someserver.com/fcgi -bin/echo2.exe?blah=<SCRIPT>alert(document.domain)</SCRIPT>

43

• Solución: Eliminar siempre las aplicaciones de muestra de servidores de producción.

v Dirección IP Privada filtrada dentro de encabezados HTTP

• Este servidor filtra una dirección IP privada a través de sus encabezados HTTP: Esto puede exponer direcciones IP internas que usualmente son escondidas o enmascaradas en un Firewall NAT (Network Address Translation) o un servidor Proxy.

• Solución: No hay solución aún.

v Finger

• Es posible obtener información del cliente remoto: El servidor remoto está corriendo el servicio ‘finger’.

El propósito de este servicio es mostrar quien tiene actualmente una sesión abierta en el sistema remoto, y dar información acerca de los usuarios en el cliente remoto.

Esto suministra información útil a los atacantes, pues les permite obtener nombres de usuario, determinar que tanto se utiliza la máquina, y ver cuándo fue la última vez que un usuario inicio sesión.

• Solución: Comentar la línea ‘finger’ en el archivo /etc/inetd.conf y reinicia el servicio inetd.

v Finger Redirection Check

• Es posible utilizar el servidor remoto para llevar a cabo escaneos de terceros: El servicio ‘finger’ del servidor remoto acepta redirigir peticiones. Esto significa que se pueden hacer peticiones de la manera:

finger user@host@victim

Esto permite a un atacante usar el servidor remoto como relevo para recolectar información de otra red.

• Solución: Deshabilitar el demonio de ‘finger’ remoto (commentar la línea ‘finger’ en el archivo /etc/inetd.conf y reiniciar el servicio inetd) o actualizarlo a un servicio más seguro.

v Rlogin Server Detection

• El servicio rlogin está escuchando en el puerto remoto: El servidor remoto está corriendo el servicio rlogin, este servicio es peligroso en el sentido en que no está cifrado – es decir, cualquier persona podría mirar el trafico que pasa entre un cliente y el servidor rsh con una herramienta de sniffing. Esto incluye nombres de usuario y contraseñas.

44



Finalmente, rlogin es una vía fácil para convertir permisos de escritura de archivos en inicios de sesión completos utilizando los archivos .rhosts o rhosts.equiv.

• Solución: Deshabilitar el servicio y utilizar ssh en su lugar. Comentar la línea ‘login’ en el archivo /etc/inetd.conf.

8.2.4.2.2. Pruebas Remotas El informe que se presentan a continuación, es un consenso de 5 pruebas hechas remotamente a los servidores de Colciencias, para ver cuál era el comportamiento de la seguridad de la información, ante ataques externos. Luego de realizar las pruebas respectivas estando en un equipo remoto, ubicado en el laboratorio de redes de la Universidad los de Andes, se descubrieron las siguientes vulnerabilidades26:

8.2.4.2.2.1. Zulia

v Versión de PHP vulnerable a buffer overflows v Métodos HTTP TRACE / TRACK v Transferencias de zonas DNS v Numeración de usuarios con sesiones abiertas v Vulnerabilidades del servidor LDAP v LDAP Permite conexiones anónimas v DNS Cache Snooping

8.2.4.2.2.2. Huitaca v Enumeración de nombres de usuario válidos v Servidor FTP vulnerable a ‘glob heap corruption’ v Vulnerabilidad en el puerto de SSH v Versión de SSH está desactualizada v Vulnerabilidad de formato en cadenas de caracteres

8.2.4.2.2.3. Scienti

v Acceso sin autenticación es permitido en el servidor remoto

8.2.4.2.2.4. Eldorado2pro v Paquetes de cifrado SSL pobremente soportados

26 Las vulnerabilidades que hayan sido previamente documentadas no se definirán de nuevo.

45

v Utilización de un protocolo SSL desaprobado v LDAP Permite conexiones anónimas v Microsoft Windows Remote Desktop Protocol Server Pri vate Key Disclosure Vulnerability v DNS Cache Snooping v Servidor de Nombres Remoto Usable

8.2.4.2.2.5. Quihicha

v Métodos HTTP TRACE / TRACK v Fast-CGI samples Cross Site Samples v LDAP Permite NULL BASE

• Es posible revelar informacion LDAP: Los servidores LDAP que no están configurados correctamente permiten el directorio BASE configurado como NULL (nulo).




• El servidor LDAP está expuesto a múltiples vulnerabilidades: EL servidor remoto está corriendo el Servidor de Sistema de Directorios de Sun Java, un servidor LDAP de Sun Microsystems.

La versión remota de este servicio está afectada por múltiples vulnerabilidades. Las versiones 6.0 y 5.2 con parche 5 son vulnerables a:

o Divulgación de la información de listas de atributos

o Acceso no autorizado (restringido a super-usuarios)

Las versiones anteriores a 5.2 con parche 5 son culnerables a:

o Negación de servicio debido a manejador de decodificación BER

o Corrupción de memoria en el fallo del manejador de peticiones

• Solución: Actualizar el Servidor de Sistema de Directorios de Sun Java a la versión 5.2 parche 5 ó 6.1

Se puede observar que se presentaron prácticamente las mismas vulnerabilidades en ambos casos, a excepción del NULL BASE del servidor LDAP, sin embargo, es un posible ataque que podría llevarse a cabo desde dentro, por lo tanto, durante las pruebas se mitigaran todas las vulnerabilidades documentadas anteriormente.

46

8.2.4.2.3. Simulación

Para montar el ambiente de servidores de Colciencias, se recurrió a TecnoParque, una entidad administrada por el SENA, la cual nos facilitó un servidor Sparc con las especificaciones que necesitábamos. En principio teníamos el supuesto de montar el bosque virtual en el laboratorio de Redes de la Universidad de Los Andes, pero no se pudo hacer por los requerimientos de la máquina que debíamos simular.

En el servidor, dado por TecnoParque, pudimos montar el bosque virtual de 4 maquinas para hacer las respectivas pruebas relacionadas con el sistema operativo Unix. Los cuatro servidores que se montaron en esta máquina fueron: Quihicha, Scienti, Huitaca y Zulia, por otro lado se montó una maquina virtual de Windows Server 2003, para hacer la respectiva simulación del servidor eldorado2pro.

Anteriormente se mostraron las vulnerabilidades encontradas, locales como remotas para los servidores de Colciencias. Para lograr tener exactamente las mismas, en los servidores virtuales que simulamos, tuvimos que montar algunos de los servicios que prestan las maquinas reales. No fue necesario montar todos los servicios porque la mayoría de las vulnerabilidades estaban relacionadas con problemas asociados al sistema operativo o programas no misionales de la entidad.

8.2.4.2.3.1. Servidor Windows

Para el servidor eldorado2pro se instaló en VMWare Server27 el sistema operativo Windows Server 2003, que tiene el servidor mencionado. Para lograr la réplica de vulnerabilidades se tuvo que montar en esta máquina el servidor DNS y DHCP, que son los servicios principales28 que presta este en la entidad. El análisis se realizó utilizando la herramienta Nessus, la misma utilizada para hacer las pruebas a los servidores de la institución, se hizo pruebas cuando se montaron los servicios respectivos al servidor, que nos arrojó las mismas vulnerabilidades. Después se actualizó el sistema operativo por medio de las actualizaciones de Windows. Para sorpresa de nosotros, al realizar dicha actualización, se observó que la mayoría de las vulnerabilidades en el servidor desaparecían, quedando unas pocas de las encontradas y apareciendo otras después de la actualización, que se corrigieron posteriormente, siguiendo una serie de pasos. Se muestran a continuación.

8.2.4.2.3.1.1. Guía para la corrección de vulnerabilidades en Windows

8.2.4.2.3.1.1.1. eldorado2pro. Para la corrección de las vulnerabilidades encontradas en eldorado2pro, debe hacer lo siguiente:

27 Para mayor información sobre virtualización, descargas e instalación, puede consultar: http://www.vmware.com 28 No hubo necesidad de instalar otros servicios en el servidor porque no presentaban vulnerabilidades a mitigar. La mayoría estaban relacionadas con el sistema operativo, el DNS y DHCP.

47

l Primero que todo, hacer la actualización del sistema operativo por Windows Update (http://www.update.microsoft.com/windowsupdate/v6/default.aspx?ln=es), ya que esto le ayudará a corregir la mayoría de las vulnerabilidades que posee el servidor.

l Continúe con las respectivas soluciones para estas vulnerabilidades.

v LDAP Permite conexiones anónimas29

Para corregir ésta vulnerabilidad debe modificar las restricciones de asociación.

No permitir asociación simple anónima. Impide que los usuarios entren en el servidor LDAP sin especificar un nombre de usuario y una contraseña. Esta opción es útil si desea evitar el acceso anónimo o público al Directorio a través de LDAP.

Pero no es recomendable desactivar el BIND NULL porque según [1] esto podría generar inconvenientes para los usuarios de la entidad. Se considera necesario deshabilitar este servicio si realmente la información que se maneja en el servidor es confidencial, de lo contrario no se aconseja hacerlo. Por otro lado es imposible cambiar esta propiedad, según [2], que viene por defecto en Windows Server 2003, ya que el acceso a las operaciones del Directorio Activo donde se realiza esto no está permitido.

v DNS Cache Snooping30

Esta realmente no es una vulnerabilidad del servidor hacia el exterior, por tal razón no se considera que deba ser corregida. Ya que las redes internas deben responder a solicitudes dentro de la misma LAN. Pero existen varias alternativas para solucionar este problema. Se listan a continuación:

1. Separar los DNS que son utilizados por los usuarios “internos” de la entidad y aquellos que son utilizados para que todo el mundo pueda resolver dominios para los cuales sean autoritarios.

29 https://vo.verwaltung.uni-muenchen.de/nps/portal/modules/ldap/help/es/ldap_server_connections.html. Conexiones con el servidor LDAP. (En línea) 2 de Mayo de 2008. [1] http://blogs.sun.com/DirectoryManager/entry/frequently_asked_questions_4_default . Frequently-Asked Questions #4: Default Access Controls: Q: I ran [security product X] against the Directory Server and it raised concerns about anonymous access to entries like cn=schema, cn=monitor and the root DSE (aka null DN). Is this something I should be worried about? Can I disable this anonymous access?. Enero de 2006. (En línea) 5 de Mayo de 2008. [2] Microsoft Ayuda y Soporte Técnico: Las operaciones LDAP anónimas en Active Directory están deshabilitadas en los controladores de dominio de Windows Server 2003. Diciembre de 2007. (En línea) 5 de mayo de 2008 30 http://www.seguridad0.com/index.php?ea75a6a5ac2b0e231b9d4e4ead9a1f73&tim=20-1-2006&ID=2359. SeguridadO.com: DNS Cache Snooping.(En línea) 5 de mayo de 2008.

48

2. Configurar a los DNS para que no respondan a consultas (queries) para los cuales no sean autoritativos. Si no se hace de esta manera es como estar diciendo que abusen de nuestro DNS.

3. En la medida de lo posible limitar con listas de control de acceso del propio DNS en cuestión (Bind, Windows) de las IPs que pueden resolver recursivamente.

v Fuga de paquetes de Red31

Para que esta vulnerabilidad se dé, el atacante debe estar y tener el objetivo en la misma subred. Por tal razón no presenta ningún riesgo al no realizar la respectiva corrección. La solución que se presenta a continuación, no es óptima, pero es la única ofrecida por Microsoft.

Para solucionar esta vulnerabilidad se debe ingresar al editor de registro de la siguiente manera:

• Ejecute windows + r • Escriba en la ventana que aparece: regedit, enter • En HKEY_LOCAL_MACHINE • SYSTEM • CurrentControlSet • Services • NDIS • Parameters àRuta [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NDIS \Parameters]

En la llave “PadShortPacket”, cambie el último cero por 1. Así: “PadShortPacket”=dword:00000001

8.2.4.2.3.2. Servidores Solaris

Los servidores Solaris que se consideraron críticos para hacer análisis y mitigación de vulnerabilidades fueron:

• Zulia • Huitaca • Scienti • Quihicha

Las vulnerabilidades encontradas en todos los servidores, al igual que en el servidor Windows, tenían que ver directamente con configuraciones de seguridad y falta de actualizaciones; por

31 http://www.514.es/2006/11/fuga_de_informacion_en_paquete_1.html . Fuga de información en paquetes de red con Windows. Noviembre de 2006. (En línea) 5 de mayo de 2008.

49

lo cual no fue necesario instalar software especializado, a excepción del servidor Zulia, el cual tenía versiones de PHP y Apache antiguas, debido a que eran vulnerabilidades conocidas, durante la emulación se instalaron las versiones recomendadas y se revisó que en el análisis de vulnerabilidades realizado con Nessus no salieran vulnerabilidades en ninguna de las dos aplicaciones. Los servidores que tienen actualmente Solaris 8 2/02 (Huitaca y Zulia), sistema operativo que cuenta no solamente con las vulnerabilidades encontradas por Nessus adjuntas a este reporte, sino muchas otras, en su mayoría de media y alta gravedad32; es aconsejable que tengan una actualización cuanto antes a la versión más reciente de Solaris (release 10 5/08), pues ésta ya tiene parches para muchas de las vulnerabilidades que tienen que ver con servicios como SSL entre otros.

Algunas de las mejoras incluidas en el release 10 5/08 incluyen33:

• Mejoras en administración del sistema

• Mejoras en la administración de recursos

• Mejoras en manejo de archivos

• MEJORAS EN SEGURIDAD: Nos enfocaremos especialmente en éste detalle, para revisión de las demás mejoras, es necesario referirse al enlace mencionado anteriormente.

o Soporte de extensiones confiables montando sistemas de archivos etiquetados con el protocolo NFSv334

o Soporte para Hardware-Accelerated Elliptical Curve Cryptography (ECC)

• Mejoras en manejo de la red

• Mejoras en herramientas de escritorio y administrador de ventanas

• Mejoras en desempeño del sistema

• Mejoras en soporte de idiomas

• Mejoras en funcione s del Kernel

• Mejoras en controladores de hardware

32 http://www.frsirt.com/english/product/3788 33 http://docs.sun.com/app/docs/doc/817-0547 34 http://en.wikipedia.org/wiki/Network_File_System_(protocol)

50

8.2.4.2.3.2.1. Guía para la corrección de vulnerabilidades en Servidores Solaris

A continuación se listarán las soluciones a las vulnerabilidades halladas en los servidores con la configuración indicada:

8.2.4.2.3.2.1.1. Zulia v Enumeraci ón de nombres en el servidor remoto

Esta vulnerabilidad no se presenta en el release 10 5/08 de Solaris. La solución más eficiente a la misma, es hacer actualización del sistema operativo.

En caso de no realizarlo, la solución aconsejada por Nessus también funciona para mitigar la vulnerabilidad.

v Versión de PHP vulnerable a buffer overflows

La versión de PHP que se instaló en el servidor para hacer pruebas fue la 5.2.4,REV=2007.10.29, la vulnerabilidad mencionada no se presentó con esta versión, la cual es la más reciente disponible.


Hay dos maneras de solucionar esta vulnerabilidad: utilizando el parche 121308-1235 para asegurar la administración de la consola o aplicar la solución aconsejada por Nessus (comentar las líneas de los servicios de TRACE y TRACK en el archivo de configuración de Apache).







35 http://sunsolve.sun.com/search/document.do?assetkey=1-21-121308-12-1

51





Para deshabilitar el servicio de rsh, como super-usuario, deshabilitar el servicio:

# svcadm disable rsh

Para asegurarse de que el servicio haya quedado deshabilitado correctamente, revisar que dentro de la lista de servicios que están actualmente corriendo, no se encuentre rsh habilitado, esto se puede hacer usando el comando:

#svcs -xv

v Versión de Apache vulnerable a buffer overflow

La versión de Apache que se instaló en el servidor para hacer pruebas fue la 11.10.0,REV=2005.01.08.01.09, la vulnerabilidad mencionada no se presentó con esta versión, la cual es la más reciente disponible.




v Transferencias de zonas DNS




Para deshabilitar el servicio de snmp, como super-usuario, deshabilitar el servicio:

# svcadm disable snmpdx

52

Para asegurarse de que el servicio haya quedado deshabilitado correctamente, revisar que dentro de la lista de servicios que están actualmente corriendo, no se encuentre snmpdx habilitado, esto se puede hacer usando el comando:

#svcs –xv





Zulia es uno de los servidores DNS internos, esto significa que ayuda a que los equipos se puedan comunicar entre sí por medio de un alias y no de las direcciones IP directamente. En el reporte de Nessus se especifica claramente que en este caso, la advertencia debería ser pasada por alto, sin embargo, es importante configurar de manera adecuada los permisos sobre el uso de este servidor.

8.2.4.2.3.2.1.2. Huitaca v Servidor FTP vulnerable a ‘glob heap corruption’



v Vulnerabilidad en el puerto de SSH


v Versión de SSH está desactualizada


v Vulnerabilidad de formato en cadenas de caracteres


53

v Enumeración de nombres de usuario válidos







#svcs -xv





#svcs -xv

8.2.4.2.3.2.1.3. Scienti v Enumeración de nombres en el servidor remoto



54



v Consola de manejo de Sun vulnerable a Negación de Servicio


v Acceso no autenticado es permitido en el servidor Web remoto

La versión de Tomcat instalada con el release 10 5/08 (11.10.0,REV=2005.01.08.01.09) no presenta esta vulnerabilidad. La solución más eficiente a la misma, es hacer actualización del sistema operativo.


v Utilización de un servicio de Java afectado por vulnerabilidad

La versión de Java instalada con el release 10 5/08 (8.2,REV=2006.08.16.08.46) no presenta esta vulnerabilidad. La solución más eficiente a la misma, es hacer actualización del sistema operativo.

En caso de no realizarlo, la solución aconsejada por Nessus también funcio na para mitigar la vulnerabilidad.

v Falla de revelación de información

La versión de Tomcat instalada con el release 10 5/08 (11.10.0,REV=2005.01.08.01.09) no presenta esta vulnerabilidad. La solución más eficiente a la misma, es hacer actualización del sistema operativo.






55


Para deshabilitar el servicio de rsh, como sup er-usuario, deshabilitar el servicio:



#svcs –xv

8.2.4.2.3.2.1.4. Quihicha





#svcs -xv



v Fast-CGI samples Cross Site Samples

La solución aconsejada por Nessus en este caso es la más viable, al momento de hacer análisis de vulnerabilidades, esta no fue mostrada por el reporte del ambiente de pruebas, pues no se instaló software adicional, por lo tanto no existían aplicaciones de muestra que pudieran ser detectadas como un hueco en la seguridad de la información.

v Dirección IP Privada filtrada dentro de encabezados http

Esta vulnerabilidad no fue detectada en el ambiente de pruebas, pues no existía ningun servicio web usable montado en el servidor. Es una vulnerabilidad que debe tenerse muy en cuenta, más aún porque aún no existe una solución eficiente para la misma.


56

v Finger

Para deshabilitar el servicio de finger, como super-usuario, deshabilitar el servicio:

# svcadm disable finger

Para asegurarse de que el servicio haya quedado deshabilitado correctamente, revisar que dentro de la lista de servicios que están actualmente corriendo, no se encuentre finger habilitado, esto se puede hacer usando el comando:

#svcs -xv

v Finger Redirection Check


# svcadm disable finger

Para asegurarse de que el servicio haya quedado deshabilitado correctamente, revisar que dentro de la lista de servicios que están actualmente corriendo, no se encuentre finger habilitado, esto se puede hacer usando el comando:

#svcs -xv

v Rlogin Server Detection


# svcadm disable rlogin

Para asegurarse de que el servicio haya quedado deshabilitado correctamente, revisar que dentro de la lista de servicios que están actualmente corriendo, no se encuentre rlogin habilitado, esto se puede hacer usando el comando:

#svcs -xv

57

8.3. Fase 3: Creación de Plan de Contingencia y Políticas de Seguridad de la Información38

8.3.1. Objetivo Fase III v Establecer un plan de contingencia de riesgos informáticos general para la entidad.

v Dejar un bosquejo inicial de las políticas establecidas por la División Sistemas de Información Ciencia y Tecnología de Colciencias para ser aplicadas a todo el personal de Colciencias.

8.3.2. Tareas Fase III 1. Investigar acerca de políticas de seguridad a nivel nacional e internacional y revisar cuál es

el conjunto que mejor se amolda a las necesidades de Colciencias. 2. A partir de las experiencias obtenidas en el ambiente de pruebas crear un plan de

contingencia para los riesgos más importantes y que afectan a la institución de una manera más delicada.

3. Documentar todos los hallazgos de la investigación relacionada con políticas de seguridad. 4. Hacer dos rondas de revisión, corrección y aprobación de los documentos generados con

el personal asignado de Colciencias.

8.3.3. Entregables Fase III i. Documento inicial de Políticas Formales de Seguridad. ii. Documento de Plan de Contin gencia de Riesgos Informáticos.

8.3.4. Políticas de Seguridad La seguridad de la información es fundamental en nuestros días, por ello las organizaciones se ven en la necesidad de adoptar medidas que permitan proteger dicha información, garantizando la permanencia en el mercado. Actualmente una forma de proteger la información y hacer uso adecuado de ella para garantizar su protección es generar políticas de seguridad formales que permitan que esto se dé.

Colciencias, una entidad del estado que se encarga de fomentar la investigación, innovación y desarrollo de la ciencia y tecnología en Colombia, debe estar a la vanguardia en temas de seguridad de la información. Por eso es indispensable mantener actualizadas, formalizadas y divulgadas las políticas de seguridad de la información. Por ello se está planteando en este documento unas políticas formales de seguridad de la información, para que Colciencias pueda garantizar en buena medida el uso correcto de las Tecnologías de Información, lo mismo que un buen manejo de la misma, con las características de integridad, disponibilidad y confiabilidad (Estas definiciones se encuentran en el glosario de este documento39).

38 Se tomará un plan de políticas global y se adaptará a la institución según sea necesario. 39 Numeral 11, Pág. 98

58

El numeral de políticas de seguridad está compuesto de cuatro partes que pretender mostrar la necesidad de las políticas de seguridad de la información en Colciencias. Se presenta el porqué de las políticas de seguridad y a quienes van dirigidas. Posteriormente el estado del arte en relación a políticas de seguridad en Colciencias. Seguido por un conjunto de responsabilidades, que creemos son necesarias para que Colciencias empiece a adoptar medidas en el manejo adecuado de la información. Se continúa con un conjunto de políticas de seguridad básicas para que sean estudiadas por Colciencias . Se enfocan en seis áreas principales, correo, contraseñas, uso de la estación de trabajo, red interna, manejo de la información y plan de contingencia.

8.3.4.1. Implementación de Políticas de Seguridad

¿Por qué la importancia de las políticas de seguridad?

Las políticas de seguridad tienen varios propósitos. Primero que todo establece qué se puede hacer y qué no se puede hacer, deben estar alineadas con el negocio de la institución. También sirven para proteger la información y los negocios de la compañía. Las políticas son fundamentales para que se maneje de la mejor manera la información y los recursos de una entidad.

Es importante saber que pueden y que no pueden hacer las personas en su área de trabajo dentro de la institución. Por ejemplo no es aceptable que una persona esté usando los equipos para sus propios intereses, bajar información pornográfica, enviar cadenas de información o leyendo archivos de otras personas, ya que el fin es trabajar para cumplir con las metas de la compañía. Proveen un marco de trabajo claro y delimitado para la utilización de los recursos informáticos de la entidad. A continuación se muestran unos ítems en los que las políticas de seguridad se enfocan:

• Ayudar en la eficiente protección de los activos del negocio. • Proveer un nivel uniforme de control y guías consistentes para el correcto manejo de los

recursos informáticos de la entidad.

Por otro lado se debe tener en cuenta que para que las políticas funcionen debe haber:

• Correcta comunicación y conocimiento de todo el personal de la entidad sobre la seguridad de la información y recursos informáticos.

• Responsabilidades y roles del personal dentro de la implementación de las políticas de seguridad.

• Aprobación y compromiso por parte de los directivos para la protección de la información y recursos más críticos para la entidad.

Las organizaciones están en un entorno tecnológico que cambia constantemente, por eso no solamente deben haber políticas, sino que deben estar actualizadas, deben asegurar que la entidad funcione constantemente sin importar dichos cambios, garanticen la seguridad, mantengan las comunicaciones con terceros y, por consiguiente, ayuden a tomar las medidas

59

necesarias para que todo funcione adecuadamente, incluyendo los activos principales de la institución:

• Gente • Infraestructura del negocio • Información y servicios ofrecidos

Los ataques que amenazan a los dos últimos crecen diariamente y es importante que los sistemas de información estén protegidos. El primer paso es leer con detenimiento los contenidos de las políticas descritas en este documento y configurarlas de acuerdo al comportamiento actual de la entidad. De esta manera, se asegura que la División Sistemas de información en Ciencia y Tecnología está haciendo todo lo que está dentro de su alcance, para proteger la entidad de posibles amenazas en ambos sentidos: desde el personal y desde los sistemas de información.

¿A quién van dirigidas las políticas de seguridad?

Las políticas de seguridad van dirigidas a todas las personas de la institución, a todos aquellos que manejen información y tecnologías de información. Esto significa que las políticas deben ser escritas teniendo en cuenta a los usuarios del sistema, gerencia, ejecutivos y administradores de los sistemas. Cubren a todos los tipos de personal dentro de la institución. En muchas ocasiones los documentos de políticas de seguridad son demasiado extensos y se corre el riesgo de que no sean leídos. Por ello es necesario saber que se quiere y que políticas realmente se necesitan para no generar este tipo de limitantes.

¿A qué contribuyen las políticas?

Las políticas contribuyen a implementar un ciclo de vida dinámico dentro de la institución que asegura que constantemente se estén haciendo revisiones y modificación de actividades, de manera que los controles y procedimientos implantados no se pierdan con el tiempo. Seguir los pasos expuestos en la siguiente gráfica nos asegurará que las vulnerabilidades del sistema sean descubiertas a tiempo, hacer seguimiento y constante revisión y personalización de las políticas de acuerdo a las necesidades de la institución, que el personal esté siempre al día y en conocimiento de la seguridad de la institución y lo que permitirá que las revisiones de conformidad sean más puntuales y exactas.

60

8.3.4.2. Políticas de Seguridad de la Información en Colciencias Actualmente Colciencias no cuenta con unas políticas formales de seguridad de la información. Lo que ha estado haciendo la entidad, más concretamente la División Sistemas de Información en Ciencia y Tecnología es garantizar que los funcionarios de la entidad se enteren de lo que se ha propuesto, vía mail, no haciendo entrega de un documento formal que les permita ver cuáles son las reglas dentro de la institución, que deben empezarse a cumplir. Se ve un problema serio con esto, las políticas de seguridad son fundamentales para hacer un uso adecuado de los recursos informáticos con los que cuenta la entidad que garantice en cierta medida la seguridad de la información. Por esa razón se han planteado unas políticas que darán las bases para que Colciencias pueda empezar a adoptarlas y posteriormente ajustar unas, eliminar otras y también, crear nuevas, basadas en lo que la entidad requiere.

Revisión De

Políticas

Monitorear Conformidad

Auditoría

Instruir Al

Personal

Implementar

Políticas

Documentar Procedimientos

61

8.3.4.3. Responsabilidades Es común encontrar en las organizaciones que la seguridad de la información es relevada a segundo plano. Esto en muchas ocasiones se debe a que las personas de las entidades ven que lo que manejan no tiene importancia. Por ejemplo una entidad que se encarga de manejar documentos que son públicos a toda la sociedad, no se ve en la necesidad de proteger la información, vemos que no tiene importancia la confidencialidad, pero ¿qué sucede con la integridad y la disponibilidad? Sencillamente no las toman en cuenta.

Por eso es muy importante empezar a tomar conciencia de la importancia que tiene la información, y el primer paso es empezar a generar políticas de seguridad que empiecen a asegurar en parte los recursos informáticos de la entidad. A continuación se listan una serie de responsabilidades que deben cumplir todos los funcionarios de la institución, que den paso al cumplimiento de las políticas de seguridad.

• Toda la organización y especialmente los altos directivos deben aplicar y hacer respetar las políticas de seguridad. En muchas ocasiones en la entidad, no se hace la debida presencia en temas relacionados con la seguridad, que permita ser transmitido a todos los niveles de la institución, que lleva a no tomar los mecanismos adecuados para proteger la información. Es muy importante que todos, y especialmente los altos directivos, hagan parte de esto ya que al ser quienes dirigen la institución darán ejemplo así como las órdenes para que se cumpla lo que se ha establecido.

• Las políticas de seguridad deben ser actualizadas anualmente. Es importante que esto se dé, ya que la tecnología, los sistemas de información, programas, etc., cambian rápidamente; cada año, en promedio se descubren entre 1000 y 2000 vulnerabilidades de software nuevas, de las cuales solamente entre el 18% y 25% son reportadas directamente por el personal afectado, entre Enero y Abril de 2008 por ejemplo, ya van descubiertas 1474 nuevas vulnerabilidades, de las cuales solamente se han reportado directamente 5240; por esto es necesario modificar las políticas existentes, eliminar otras y generar nuevas que estén de acuerdo con lo que la entidad tiene y maneja en ese momento.

• Siempre que un nuevo empleado entre a la institución, se le hará entrega del documento de políticas de seguridad. Es importante que todas las personas tengan un manual de las políticas de seguridad de la información, esto con el fin de que las tengan en cuenta y las cumplan a cabalidad. Esto se puede hacer entregando el documento físicamente o enviarlo por medio de la intranet, dejando un certificado o constancia de que el documento fue entregado. Esto se hace con el fin de que el personal no tenga excusas sobre lo que puede hacer o no.

• Hacer auditoria constante del cumplimiento de las políticas de seguridad. Es importante que se haga un seguimiento mensual del cumplimiento de las políticas de seguridad, esto hará que las personas vean la importancia de este tema y se comprometan a cumplir lo que se ha establecido.

40 Información obtenida de http://www.cert.org/stats/fullstats.html

62

8.3.4.3.1. Obligaciones hacia el Personal La División Sistemas de Información Ciencia y Tecnología como generadora de políticas de uso de información y recursos informáticos dentro de Colciencias, es responsable de educar y entrenar al personal en la implementación, puesta en marcha y continuo mejoramiento de las políticas propuestas; así como en la educación acerca de la razón por la cual el manejo de la información confidencial o sensible de la entidad, es un asunto importante que no puede ser pasado por alto, lo mismo que su disponibilidad e integridad.

8.3.4.3.2. Responsabilidades del Personal Asegurarse de leer, entender y cumplir con las políticas institucionales al momento de utilizar alguna de las estaciones de trabajo, información, redes y sistemas de comunicación de la entidad. Deben colaborar con el continuo uso de las políticas establecidas. Sin embargo, todo esto es posible solamente si las políticas están en un lugar de fácil acceso, disponibles en cualquier momento y son fáciles de entender e implementar por todo el personal.

8.3.4.4. Políticas formales de seguridad41 Las políticas de seguridad que hacen parte de este numeral se refieren exclusivamente a las relacionadas con correo, contraseñas, uso adecuado de la estación de trabajo, el manejo de la información de la entidad, la red y plan de contingencia42. Estas han sido adaptadas para que logren ser comprendidas por los funcionarios de la entidad.

8.3.4.4.1. Políticas de Correo Electrónico43

8.3.4.4.1.1. Cuenta de Correo Electrónico Política: Todo funcionario de Colciencias debe tener una cuenta de correo electrónico dentro de la entidad para el cumplimiento de sus funciones.

41 Algunas de las políticas que se listan aquí fueron dadas por la institución, ya que la idea es mirar que tiene la institución para no generar políticas que vayan en contra de lo que ya se ha establecido, según lo plantea Cresson en su libro sobre Políticas de seguridad [págs. 8,9]. Las políticas restantes son parte del libro de Cresson que él recomienda usar en una entidad cuando se está iniciando un proceso de diseño de políticas de seguridad. 42 Esto se acordó en una reunión con la encargada de la seguridad de la Información, María Clemencia Reyes y otra con Liliana Buitrago, jefe de la División. 43 CRESSON WOOD, Charles. Information Security Policies Made Easy: Electronic Mail Systems. Version 6. Sausalito California: Baseline Software, Inc. 1997. 290-298.

63

8.3.4.4.1.2. Cuenta personal de correo electrónico

Política: La cuenta de correo debe ser personal e intransferible, por lo que no debe darse a otro usuario la posibilidad de usarla.

8.3.4.4.1.3. Creación de Cuentas Política: Se debe solicitar por medio de un memorando ante la División de Personal o un visto bueno de ésta directamente, para la creación de una cuenta de correo a un usuario, y ésta área reporta la novedad a la División de Sistemas de Información.

8.3.4.4.1.4. Asignación de más de una cuenta de correo Política: Se debe asignar otra cuenta de correo a un usuario, si se ve en la necesidad de hacerlo. La cuenta debe ser exclusivamente para uso institucional. Se establece esta política porque en ciertas circunstancias se crean cuentas institucionales para manejo de convocatorias o eventos especiales.

8.3.4.4.1.5. Problemas con la cuenta de correo Política: El usuario que presente problemas con su cuenta de correo, debe colocar un servicio a través de la mesa de ayuda para que le sea solucionado éste.

8.3.4.4.1.6. Uso de las cuentas de correo

Política: No debe ser responsabilidad de la División de Sistemas de Información, asignar cuentas de correo alterno, cuentas de reenvío de correo, ni tampoco debe responder por cuentas personales en otros servidores. El usuario es el encargado de manejar sus cuentas y respetar la configuración realizada por el área de soporte.

8.3.4.4.1.7. Despliegue de Correo

Política: Los usuarios deben usar el medio que consideren conveniente para desplegar sus mensajes de correo. Sin embargo el cliente por defecto de la entidad es Microsoft Outlook y sobre éste se da soporte.

8.3.4.4.1.8. Tamaño de los mensajes de correo

Política: El tamaño de los correos no debe ser mayor a 30 MB incluyendo los respectivos anexos. Se aclara que varios servidores en internet no permiten esto.

8.3.4.4.1.9. Listas de correo Política: Las listas de correo que pertenezcan a los usuarios deben ser cerradas (Sólo esta puede recibir y enviar mensajes a usuarios autorizados), estarán almacenadas en el servidor de correo.

8.3.4.4.1.10. Número permitido de destinatarios de correo

Política: Los usuarios no deben enviar a más de 50 personas un correo porque éste será considerado como SPAM (Se considera correo no deseado y no será enviado por el servidor de correo a los destinatarios). El administrador será el encargado de verificar que esto se cumpla.

64

8.3.4.4.1.11. Monitoreo del correo

Política: La División de Sistemas de Información debe reservarse el derecho de monitorear las cuentas que presenten un comportamiento sospechoso44 para la seguridad de la entidad. Se considera un evento sospechoso cuando un usuario ha enviado muchos correos con información relevante para la entidad a una dirección desconocida, también si esta misma cuenta recibe correos extraños por parte de una externa a la cual se responde.

8.3.4.4.1.12. Usando la cuenta de correo electrónico asignada a otro usuario

Política: Los funcionarios no deben usar la cuenta de correo asignada a otro usuario para enviar o recibir mensajes. Si hay necesidad de leer el correo de otro, mientras no está o está en vacaciones, reenviar el mensaje o usar otras alternativas deben ser usadas.

8.3.4.4.1.13. Reenvío de correos a direcciones externas Política: A menos que el propietario/creador de la información esté de acuerdo, o a menos que la información sea de naturaleza pública, los usuarios no deben reenviar correos a ninguna dirección de red externa a Colciencias.

8.3.4.4.1.14. Reenvío de correos externos recibidos Política: Los usuarios no deben crear, o reenviar correos externos recibidos que son considerados ofensivos o que puedan contribuir a un ambiente hostil de trabajo. Un ambiente hostil se crea cuando se envían comentarios con insultos acerca del tipo de sexo, raza, religión o preferencias sexuales.

8.3.4.4.1.15. Retener correos para futuras referencias Política: Si un mensaje contiene información relevante para terminar un trabajo o negocio, contiene información muy importante o tiene datos de decisión de la entidad, debe ser mantenido en la cuenta de correo correspondiente para una futura referencia. Se aclara que la mayoría de los correos no caen en esta categoría y por eso pueden ser eliminados.

8.3.4.4.1.16. Uso de correo como base de datos Política: Los usuarios no deben emplear los sistemas electrónicos de correo como bases de datos. Regularmente los usuarios deben mover información importante de los mensajes a procesadores de texto, documentos, bases de datos y otros archivos. Los sistemas de correo no son creados para el almacenamiento de información importante. Estos correos se pierden cuando se hace mantenimiento a los sistemas por parte de los administradores, por el uso inadecuado de los mismos usuarios o por fallas del sistema.

44 Entiéndase como comportamiento sospechoso en el uso de una cuenta de correo: un tráfico exagerado de envío y recepción de archivos adjuntos, uso frecuente de receptores externos no corporativos (ejemplo: envíos a cuentas de Hotmail, Gmail, Yahoo, etc.), envío constante de copias invisibles (BCC) de correos con información corporativa sensible a receptores externos o internos que no deberían ver dicha información.

65

8.3.4.4.1.17. Expectativa de privacidad del correo

Política: Los usuarios deben tratar los mensajes y archivos de correo electrónico como información privada. Los correos deben ser tratados como privados, lo mismo que una comunicación directa entre el que lo envía y quien lo recibe. Se establece esta política teniendo en cuenta que la información que están manejando los usuarios se considera crítica.

8.3.4.4.1.18. Correo electrónico como comunicación pública Política: Los usuarios deben considerar el correo como un medio de comunicación público, por eso no deben enviar números de tarjetas de crédito, contraseñas, información de investigación y desarrollo u otra información sensitiva a menos que se use cifrado para la información que se envía.

8.3.4.4.1.19. Reporte de correos ofensivos Política: Los usuarios deben responder directamente a la persona encargada de generar el mensaje ofensivo, ya sea por medio electrónico, telefónico o personalmente para que cese este tipo de correos. Si esta persona no para de enviar este tipo de correos, el empleado debe reportar directamente a su jefe y a la División de Personal.

8.3.4.4.1.20. Correo electrónico como parte de la Entidad Política: El sistema de correo de Colciencias debe ser usado solamente para propósito institucional. Todos los mensajes enviados son parte de la entidad. Colciencias se reserva el derecho a acceder y encubrir los mensajes enviados por su sistema de correo, para cualquier propósito. Los supervisores pueden revisar el correo de los funcionarios para verificar que estén cumpliendo con las políticas de la entidad. La entidad además puede dar mensajes a las entidades oficiales sin dar noticia al(os) funcionario(s) quienes estén involucrados en envío y recepción de mensajes que atenten contra la entidad. Para garantizar que se puede cumplir la política, los funcionarios deben estar de acuerdo con lo que aquí se plantea, además la política está regida por las condiciones legales y penales que den al caso para la divulgación, destrucción o modificación de información a entidades estatales.

8.3.4.4.1.21. Uso personal del correo Política: Los usuarios deben usar el correo principalmente para propósitos institucionales. Cualquier uso personal, no debe interferir con las actividades misionales de la entidad, no debe involucrar solicitudes, no debe ser usado para actividades no relacionados con la misma y tampoco que generen algún tipo de humillación para esta. Deben utilizar cuentas personales para esto y no las institucionales.

8.3.4.4.1.22. Uso de correo corporativo Política: La cuenta de correo institucional es exclusivamente para fines institucionales y de gran importancia. Los usuarios no deben enviar ningún tipo de información por este medio como invitaciones, cadenas, etc., que no estén asociados con la misión de la entidad y que el uso de ésta no lo requiera.

66

8.3.4.4.2. Políticas de Contraseña45

8.3.4.4.2.1. Tamaño de la contraseña

Política: El tamaño de las contraseñas debe ser siempre probado automáticamente a la hora en la que un usuario la cree o la seleccione. Todas las contraseñas deben tener un mínimo de 8 caracteres incluyendo alfanuméricos y caracteres especiales.

8.3.4.4.2.2. Requerimiento de contraseñas difíciles de adivinar Política: Todos los usuarios deben escoger contraseñas para sus equipos y la red, difíciles de descifrar. Palabras en diccionarios, derivadas de identificaciones del usuario y secuencias de caracteres comunes, no deben ser empleadas. Por otro lado información relacionada con nombres de familiares, licencias, fechas de cumpleaños no deben ser usadas a menos que estén acompañadas de otros caracteres difíciles de averiguar. Además no deben ser usados nombres propios, ubicaciones geográficas, acrónimos comunes.

8.3.4.4.2.3. Contraseñas Cíclicas Política: Los usuarios no pueden usar contraseñas que sean hechas con caracteres que no cambian combinados con ciertos números que si lo hacen, pero que son fáciles de adivinar. En estas contraseñas lo típico es usar meses, nombres de proyectos, divisiones. Por ejemplo los usuarios no pueden usar contraseñas como “C1DIC” para diciembre, “C1ENE” para enero, etc.

8.3.4.4.2.4. Reuso de contraseñas Política: Los usuarios no deben construir contraseñas que sean idénticas o casi idénticas a contraseñas que hayan sido usadas anteriormente.

8.3.4.4.2.5. Estructura de contraseñas

Políticas: Los usuarios deben escoger o crear contraseñas que contengan al menos un carácter alfabético y no alfabético. Además la contraseña debe contener al menos una letra mayúscula y una minúscula. Esto dificulta descifrar la contraseña. El uso de caracteres de control no es recomendable usarlos porque puede generar conflictos en el sistema, por ejemplo END, FOR, AND, etc.

8.3.4.4.2.6. Cambio de contraseña Política: Los usuarios deben cambiar la contraseña una vez cada 45 días.

8.3.4.4.2.7. Contraseñas desplegadas e impresas Políticas: Los usuarios que desplieguen una contraseña en el sistema o que la impriman, deben asegurarse de que ésta sea ocultada o destruida, para que personas no autorizadas no la vean o recuperen después y hagan uso indebido de la información.

45 CRESSON WOOD, Charles. Information Security Policies Made Easy: Logical Security. Version 6. Sausalito California: Baseline Software, Inc. 1997. 33-54.

67

8.3.4.4.2.8. Asignación de contraseñas

Política: Los usuarios deben cambiar la contraseña que les fue dada por primera vez, una vez ingresen al sistema y realicen cualquier otra tarea, porque la contraseña es válida solo para la primera sesión.

8.3.4.4.2.9. Limite de intentos fallidos para el ingreso al sistema

Política: Para prevenir ataques que lleven a descubrir una contraseña, el núme ro consecutivo de intentos para el ingreso al sistema con una contraseña incorrecta debe ser estrictamente limitado. Se puede usar los siguientes mecanismos para esto: (a) Suspender el sistema hasta que sea reiniciado, (b) temporalmente deshabilitado por un periodo de tres minutos o (c) si está involucrada alguna red, desconectarla.

8.3.4.4.2.10. Ciframiento de contraseñas Política: Las contraseñas siempre deben ser cifradas cuando se almacenan por un periodo de tiempo o cuando son transmitidas por la red. Esto previene que sea descubierta por personas no autorizadas.

8.3.4.4.2.11. Contraseñas en diferentes sistemas Política: Los usuarios deben emplear diferentes contraseñas en cada uno de los sistemas que usen o tengan acceso. Se busca minimizar el daño a múltiples sistemas cuando la contraseña sea tomada por personas no autorizadas.

8.3.4.4.2.12. Compartir contraseña

Política: Los usuarios no deben compartir las contraseñas con otras personas a menos que tenga autorización de hacerlo por la persona encargada de la seguridad en la entidad. Si los usuarios necesitan compartir información, esta debe ser enviada por correo o usar carpetas compartidas para este fin, en vez de revelar su contraseña.

8.3.4.4.3. Políticas de Uso del Recurso Informático46

8.3.4.4.3.1. Juegos en el computador

Política: Los usuarios no deben guardar y usar juegos en los computadores de Colciencias.

8.3.4.4.3.2. Música en el computador

Política: Los usuarios no deben guardar ni escuchar música, ni tampoco por medio de la red en los computadores de Colciencias.

46 CRESSON WOOD, Charles. Information Security Policies Made Easy: Use of Systems. Version 6. Sausalito California: Baseline Software, Inc. 1997. 56-61.

68

8.3.4.4.3.3. Programas en el computador

Política: Los usuarios no deben guardar e instalar software en los computadores de Colciencias, y menos programas que no tengan una licencia original. Sólo podrán hacerlo con la debida autorización de la persona encargada de la División de Sistemas de Información.

8.3.4.4.3.4. Uso del computador y sistemas de comunicación

Política: Los usuarios no deben usar los computadores y los sistemas de comunicación para propósitos de negocios personales. El uso personal es permitido solamente con permiso especial de la persona encargada de estos asuntos.

8.3.4.4.3.5. Uso de Internet en el Sistema Política: Los usuarios no deben usar el Internet en los sistemas de información para propósitos personales. Este es sólo con fines de negocio de la entidad.

8.3.4.4.3.6. Privilegios de acceso al sistema

Política: Todos los privilegios en los sistemas de información de la entidad deben ser eliminados de un usuario cuando termine de prestar los servicios en ésta.

8.3.4.4.3.7. Página de Internet Política: Todos los usuarios deben tener como página de inicio, la página institucional. Por ello el administrador de la red debe encargarse de la configuración pertinente y la cual no pueda ser modificada por otros usuarios.

8.3.4.4.3.8. Distribución de información del equipo

Política: Los usuarios deben reportar ante el encargado de la seguridad de la información, alertas, vulnerabilidades, cosas maliciosas, etc., relacionados con el equipo de trabajo (PC).Por otro lado los usuarios no deben compartir esta información con personas de la entidad ni tampoco con personas externas a esta.

8.3.4.4.3.9. Notificaciones ante interrupción de trabajo

Política: Los usuarios deben informar al encargado de la seguridad cualquier anormalidad que se presente en su equipo de trabajo, que no le permita continuar realizando sus actividades normales.

69

8.3.4.4.4. Políticas sobre los Datos47

8.3.4.4.4.1. Seguridad de los Datos

8.3.4.4.4.1.1. Información como activo importante de la Entidad Política: La información de la entidad es un activo muy importante para esta, ya que es esencial para el trabajo que desarrolla esta. Los usuarios deben asegurar que la información es manejada, usada, procesada prop iamente, siguiendo lineamientos de la entidad como políticas y estándares.

8.3.4.4.4.1.2. Asignación de Patentes, derechos de copia y derechos de propiedad intelectual

Política: Mientras un funcionario esté trabajando en la entidad, debe dar los derechos exclusivos de patentes, derechos de copia, inventos y otros derechos intelectuales que hayan sido originados por éste, a la entidad.

8.3.4.4.4.1.3. Derechos de manejo para examinar información en los sistemas de la entidad

Política: Toda la información enviada por los funcionarios relacionada con la institución por medio de sistemas de información, son propiedad de la entidad. Para mantener esa propiedad, el encargado de administrar la información se reserva el derecho de examinarla ya sea que esté almacenada o sea transmitida por los sistemas de información. Por tal razón los equipos de trabajo y los sistemas de información deben ser usados sólo para fines institucionales.

8.3.4.4.4.2. Confidencialidad de los Datos

8.3.4.4.4.2.1. Requerimiento de confidencialidad para todos los usuarios de la entidad Política: Todos los empleados, consultores, contratistas y empleados temporales, deben firmar un acuerdo de confidencialidad de la información cuando ingresen a la entidad.

8.3.4.4.4.2.2. Restricciones en diseminación de información Política: Toda la información interna de la entidad que se considere como confidencial debe ser protegida para que no sea revelada a terceros. Esta información puede ver vista por terceros cuando se demuestre que exista y cuando haya sido dada una autorización por parte de la entidad.

8.3.4.4.4.3. Criticidad de los Datos

8.3.4.4.4.3.1. Disponibilidad de los Sistemas de Información

Política: Los sistemas de información deben estar disponibles la mayoría del tiempo, que garantice a los usuarios acceder a los sistemas compartidos al menos el 95% en horas de trabajo normal.

47 CRESSON WOOD, Charles. Information Security Policies Made Easy: Data Security. Version 6. Sausalito California: Baseline Software, Inc. 1997. 119-150.

70

8.3.4.4.4.3.2. Limitación a usuarios para la interrupción de los servicios

Política: Las actividades de los usuarios en el uso de los sistemas compartidos no deben causar pérdida o interrupción de esos sistemas a otros usuarios que también los usen. Los únicos con estos privilegios son los administradores de seguridad de estos sistemas.

8.3.4.4.4.3.3. Área de los Sistemas de información

Política: La entidad debe proveer y mantener detección de fuego, eliminación, condiciones de energía, aire acondicionado y otros sistemas de protección en el área de los sistemas críticos, que garantice la continuidad del servicio en los computadores críticos.

8.3.4.4.4.4. Integridad de los Datos

8.3.4.4.4.4.1. Cambiar información sensible, crítica o de valor Política: Las transacciones que afecten información sensible, crítica o de valor, solamente deben ser hechas si el usuario que la creó o el correspondiente sistema, muestran la autorización respectiva para hacerlo.

8.3.4.4.4.4.2. Alteración de la información

Política: Los directivos de la entidad debe establecer y mantener controles eficientes para asegurar que la información de la entidad está libre de ser alterada.

8.3.4.4.4.4.3. Autorización en el cambio de datos Política: Los datos sensibles críticos y de valor de la entidad solo pueden ser cambiados si se tiene una autorización correspondiente para hacerlo.

8.3.4.4.4.5. Disposición y almacenamiento de Datos – Copia de Seguridad (Back-Up)48

8.3.4.4.4.5.1. Recuperación de datos por usuarios finales

Política: Los usuarios finales tienen los privilegios de restaurar sus archivos, pero no deben tener los privilegios para restaurar los archivos de otros usuarios.

8.3.4.4.4.5.2. Copia de seguridad de los datos

Política: Toda la información sensitiva, de valor o crítica en los sistemas de información de la entidad, se les debe hacer copia de seguridad periódicamente. Este proceso debe hacerse semanalmente por el volumen de información que maneja la entidad. Por medio del esquema de back-up que tenga definido la entidad.

8.3.4.4.4.5.3. Copia de seguridad en Usuarios

Política: A menos que otra copia de seguridad esté por realizarse, los usuarios deben hacer al menos una copia de los datos sensibles, críticos, o de valor. Esta copia debe hacerse cada vez que

48 CRESSON WOOD, Charles. Information Security Policies Made Easy: Back-Up, Archival Storage and Disposal of Data. Version 6. Sausalito California: Baseline Software, Inc. 1997. 126-140.

71

se modifica información crítica o sensible. El responsable de realizar esta copia es el administrador encargado de la información.

8.3.4.4.4.5.4. Copias de seguridad de los Datos de la Entidad Política: Al menos dos copias completas recientes de la información de la entidad deben ser siempre guardadas, una en la entidad y otra fuera de ésta. El tiempo para realizar estas copias debe ser menor a 8 días por el volumen de información que maneja la entidad.

8.3.4.4.4.5.5. Copias de seguridad en Usuarios finales

Política: Los encargados de las divisiones deben asegurarse de que los usuarios de ésta, estén haciendo la correcta copia de seguridad relacionada con información sensible, crítica y de valor de la compañía en sus estaciones de trabajo. La información debe ser almacenada en el lugar del sistema que es especificado por los administradores para posteriormente realizar la respectiva copia.

8.3.4.4.4.5.6. Uso de copias de seguridad Política: La información que ha sido almacenada como copia de seguridad, no puede ser usada a menos que se tenga otra copia de seguridad en otro sistema. Se busca proteger la información si llega a sufrir alguna alteración que no puede ser restablecida en el momento de ser usada.

8.3.4.4.5. Políticas de Seguridad en la red49

8.3.4.4.5.1. Red interna

Política: Las direcciones, configuración y diseño del sistema interno de red de la entidad deben ser restringidos para sistemas y usuarios fuera de ésta. No se puede acceder a esta red sin la debida autorización.

8.3.4.4.5.2. Control de acceso a la red Interna

Política: Si los usuarios dejan los computadores encendidos durante horas no laborales y están conectados a la red, estos deben ser protegidos por un sistema de control de acceso.

8.3.4.4.5.3. Configuración de la red interna Política: Grandes redes locales que cruzan toda la entidad deben tener dominios lógicos separados y bien definidos. Deben estar protegidos con un sistema de seguridad.

8.3.4.4.5.4. Conexiones de acceso a la entidad

Política: Todas las conexiones externas de tiempo real de internet que se conecten a la red interna deben pasar a través de un acceso de control (Firewall, Gateway o Servidor de Acceso).

49 CRESSON WOOD, Charles. Information Security Policies Made Easy: Communications Security. Version 6. Sausalito California: Baseline Software, Inc. 1997. 253-264.

72

8.3.4.4.5.5. Sistemas con información importante

Política: Los sistemas de información de la entidad que contengan información importante no deben ser conectados a la red u otros equipos.

8.3.4.4.5.6. Aprobación en modificaciones en la red Política: Los usuarios y/o vendedores de servicios no deben hacer arreglos o completar la instalación de las líneas de datos, si no tienen aprobación del Jefe de la División de Sistemas Información.

8.3.4.4.5.7. Aprobación para interconexiones de red Política: Conexiones en tiempo real entre dos o más equipos no deben establecerse hasta que el encargado de la seguridad de la información, determine que la conexión no pondrá en peligro la seguridad de la información.

8.3.4.4.5.8. Aprobación para conexiones entre la red de la entidad y una red externa

Política: Los equipos de la red de la entidad no deben ser conectados a una red externa antes que el encargado de la seguridad de la información haya determinado que los dos siste mas interconectados cumplen con los requerimientos de seguridad para proteger la información.

8.3.4.4.5.9. Requerimiento de seguridad para conexiones externas hacia la entidad

Política: Como condición para tener acceso a la red de la entidad por parte de un tercero, debe asegurar su sistema como lo exigen los requerimientos de la institución. La entidad se reserva los derechos de hacer seguimiento y terminar la conexión si se observa que no se están cumpliendo los requerimientos exigidos.

8.3.4.4.5.10. Aprobación para conexiones a internet

Política: Hasta no haber una aprobación por parte del encargado de la seguridad de la información, los usuarios no deben establecer conexiones a internet u otra red externa que lleven a que terceros puedan obtener acceso a la entidad. Estas conexiones son básicamente: Sistemas de archivos entre equipos (Como NIS de SUN), páginas de internet, servidores FTP, etc.

8.3.4.4.6. Políticas de Seguridad del Plan de Contingencia50

8.3.4.4.6.1. Procedimientos de segmentación de los recursos de información

Política: El manejo de las operaciones en los sistemas de información deben establecer y usar procedimientos de segmentación de los recursos de información para recuperaciones prioritarias. Esto garantiza que la información más importante es la primera en ser recuperada. Todos los grupos de la entidad deben preparar estos procedimientos cuando se esté haciendo un plan de contingencia.

50 CRESSON WOOD, Charles. Information Security Policies Made Easy: Contingency Planning. Versión 6. Sausalito California: Baseline Software, Inc. 1997. 216-225.

73

8.3.4.4.6.2. Rata anual de criticidad en sistemas multi-usuarios

Política: En conjunto con responsables de datos importantes, la División de Sistemas de Información debe periódicamente preparar o revisar informes del grado de criticidad de la información que los usuarios han realizado. Esto ayudará a preparar apropiados planes de contingencia.

8.3.4.4.6.3. Esquema de clasificación para aplicaciones críticas Política: Todos los sistemas de información, así como los datos deben ser clasificados en cinco categorías: altamente crítico, critico, prioritario, requerido y preferible. Esta clasificación deberá ser usada por toda la entidad y debe ser parte integral de los planes de contingencia.

8.3.4.4.6.4. Preparación y mantenimiento de planes ante incidentes informáticos

Política: Para equipos y sistemas de comunicación, los directivos deben preparar, periódicamente hacer actualizaciones y regularmente pruebas de planes de respuesta a emergencias. Estos planes deben proveer continuidad en la operación de sistemas críticos, en caso de que se presente un incidente (ej. interrupción del servicio).

8.3.4.4.6.5. Grupo ante incidentes de seguridad Política: Los directivos deberían organizar y mantener un grupo de respuesta ante incidentes de seguridad (SCIRT – Siglas en inglés de Security Computer Incident Response Team), que de notificaciones oportunas de problemas, controles acerca de daños y servicio de corrección ante emergencias relacionada con los datos y los sistemas de información.

8.3.4.4.6.6. Preparación y mantenimiento de Planes de Recuperación ante Desastres Política: Los directivos deben preparar, actualizar periódicamente, y regularmente hacer pruebas de planes ante recuperación de desastres. Se hace con el fin de permitir la continuidad del negocio de la entidad cuando se llegue a presentar un evento de gran escala (ej. un terremoto).

8.3.4.4.6.7. Mantenimiento preventivo de los equipos y sistemas de información

Política: El mantenimiento preventivo debe ser mejorado regularmente para todos los equipos y sistemas de información, que garantice que la probabilidad sea baja para que suceda un riesgo.

8.3.4.5. Otras políticas Las políticas que se mostraron anteriormente creemos son las más apropiadas para Colciencias, que sirvan como base para que puedan ser creadas otras, que permitan el aseguramiento de la información y, en general el trabajo desarrollado por la entidad. Se muestra a continuación un listado que debe ser puesto en marcha por Colciencias para asegurar en gran parte la seguridad de la información.

• Políticas de aceptación de uso • Políticas de control de acceso • Políticas de Anti -Virus • Políticas de continuidad de negocio

74

• Políticas de equipos de comunicaciones • Políticas de uso de sistemas de cómputo y equipos • Políticas de manejo de incidentes y crímenes informáticos • Políticas de manejo de correo electrónico • Políticas de administración del Firewall • Políticas de administración de hardware (servidores, routers, switches, etc.) • Políticas de manejo de la información • Políticas de uso de Internet • Políticas de seguridad de equipos portátiles • Políticas de administración de la red • Políticas de conformidad legal • Políticas de contraseña y autenticación de usuarios • Políticas de administración del personal • Políticas de acceso remoto, acuerdo de acceso remoto y formulario de solicitud de acceso

remoto • Políticas de administración de software • Políticas de acceso especial (uso por parte de un usuario normal de herramientas y

equipos administrativos)

8.3.4.6. Creación de Políticas Para comenzar a crear políticas sólidas de seguridad, primero es necesario reunir información acerca de todas las políticas que estén definidas en la institución de manera formal y no formal. Existen dos tipos de políticas:

• Políticas escritas: Se realiza basándose en comportamientos que en general deberían tener los empleados, es replicada y publicada por toda la institución y es reforzada haciendo auditorías y revisiones continuas a los usuarios.

• Políticas computacionales: Es desarrollada con el fin de “forzar” la aplicación de ciertas políticas mediante el uso de herramientas computacionales. Igualmente es aplicada y distribui da a todos los usuarios de la institución.

La mayoría de las políticas usualmente necesitan algún tipo de apoyo tecnológico de todas maneras, con el fin de que el personal de la División de Sistemas de Información, Ciencia y Tecnología esté garantizando la aplicación de las políticas propuestas. Con el fin de mantener un equilibrio “saludable” entre la aplicación de políticas de ambos tipos, la NSA51 ha propuesto un modelo de cómo deberían ser creados y documentados los procedimientos y políticas:

51 http://www.nsa.gov/about/index.cfm

75

De esta manera nos damos cuenta de que las políticas escritas harían parte de la documentación de los usuarios y las computacionales hacen parte directamente del plan de seguridad del sistema de la institución ; una vez se haya reconocido el alcance que deberían tener las políticas que se desea plantear, se debe iniciar la documentación de las políticas, existen muchas plantillas disponibles, entre ellas las de SANS52, las cuales permiten hacer que el proceso de documentación sea rápido y apropiado para los usuarios finales.

Sin embargo, hay 4 cosas a tener en cuenta al momento de utilizar plantillas:

8.3.4.6.1. Uso cuidadoso de plantillas genéricas

Es bueno revisar que las plantillas genéricas se amolden a las necesidades de la institución, es muy probable que haya que editarlas y parafrasear muchas partes con el fin de que se amolden a la situación actual. No es suficiente simplemente cortar y pegar y esperar que pase lo que mejor, hay que revisar muy bien que el arreglo de las plantillas sea suficiente para lo que se espera que ocurra con la política.

8.3.4.6.2. Asegurarse de que las plantillas usadas sean las indicadas Al momento de usar plantillas hay que asegurarse de que cumplan con los requisitos que necesita la institución en un momento dado y que luego de los arreglos resulten en políticas claras, concisas y escritas en un lenguaje amigable a los usuarios finales.

52 http://www.sans.org/resources/policies/#template

Política de Seguridad de la Información Misión/Filosofía

Guías de construcción básicas

Planes de Seguridad del Sistema

Documentación de los Usuarios Procedimientos Operativos Estandarizados

Actualizaciones del Sistema

Configuraciones del Sistema

Refuerzo del Sistema

Monitoreo constante del Sistema

Operaciones diarias

Administración de la seguridad

Auditorías constantes

Revisión de presupuesto

Privilegios de usuario según su cargo

Responsabilidades de los usuarios

Entrenamiento y capacitación de los usuarios

Refuerzo de uso de contraseñas

Seguridad en las estaciones de

76

8.3.4.6.3. Permiso legal de uso de plantillas

Asegurarse de no usar sin permiso materiales que tengan derechos de autor es muy importante, muchas de las plantillas indican cuándo y de qué manera pueden ser utilizadas en términos legales, por ejemplo, muchas veces las restricciones especifican que son solamente para uso interno de una institución.

8.3.4.6.4. Revisar el borrador final con la División de Personal Es necesario que la División de Personal revise que la política sea apropiada y aplicable a todo el personal (o al personal al que va dirigida) antes de ser publicada e implementada. Hay que recordar que al usar una plantilla sin hacer buena revisión, no todo el personal puede entender la relación entre la definición de la política y la situación de la institución .

8.3.4.7. Pasos para creación de Políticas La creación de políticas comprende un proceso previo antes de la documentación directa de las mismas; contiene una serie de pasos que deben seguirse con el fin de que la política final documentada cumpla con el objetivo inicialmente pensado:

8.3.4.7.1. Justificación Es necesario formalizar una justificación de la necesidad de la política. Usualmente esto debe ser hecho en compañía de una junta directiva, hay que asegurarse de que entre ambas partes haya constante comunicación acerca del estado de desarrollo de la política con el fin de que todas las partes estén de acuerdo.

8.3.4.7.2. Alcance El alcance debe definir claramente a quiénes va dirigida la política y a quiénes no. Hacerse preguntas como:

R ¿Aplica a todos los usuarios que utilizan aplicaciones móviles?

R ¿Se necesita que haya personal de apoyo al momento de la aplicación e implementación?

R ¿Aplica a todos los centros de datos, oficinas y locales remotos?

R ¿Aplica no solamente al personal interno de la compañía, sino también a proveedores y personal externo?

Es usualmente bastante útil al momento de definir el alcance de una política.

8.3.4.7.3. Borrador Componer un borrador inicial de las áreas que cubrirá la política. Es necesario que al momento de realizar el borrador de la política se tenga muy bien definidas la siguiente lista de cosas, de no tenerlas, es necesario regresar a la etapa de definición de alcance y justificación:

R Nombre y resumen de la Política: Definir de qué se trata la política exactamente.

77

R Propósito: Qué es lo que se busca exactamente con la implementación de la política y los riesgos de seguridad que se mitigan con la implementación de la misma.

R Autoridad: Definir quién será la persona encargada de aprobar la política.

R Dueño de la Política: Quién cambia la política cuando es necesario, esta persona (o división) es la encargada de resolver las dudas de los usuarios respecto a la misma.

R Duración: ¿La política tiene un tiempo extraordinario de aplicación, o será aplicada durante tiempo indefinido?

R Documentos relacionados: Definir si existen documentos relacionados ya sea con la definición o implementación de la política.

R Definición de la política: Es el texto inicial que va a tener la política, lo que va a estar documentado formalmente y será publicado a los usuarios finales.

R Roles y responsabilidades: Qué roles estarán directamente relacionados con la política y qué debe hacer cada uno durante la implementación de la política.

R Requerimientos de cumplimiento: En qué manera se considera que la política está cumpliéndose y qué tipo de acciones son consideradas una violación.

R Excepciones de la política: Los casos en los que la política se sale completamente del alcance y no se hace aplicable.

R Refuerzo de la política: Dentro del ciclo de vida explicado en el documento, la manera en que la política va a tener constante auditoría en pro de su refuerzo y mejora.

R Historial de revisiones: En qué lugar se almacenarán todas las revisiones y versiones documentadas de la política.

8.3.4.7.4. Soporte administrativo

Se acerca a la justificación pero en la manera en que al momento de la justificación los directivos dirán “necesito una política aplicable para esto”, y dentro del soporte, los directivos dicen “¿de qué manera puedo contribuir para que se implemente y se ponga en marcha?”. Este esfuerzo no es solo necesario por parte de los directivos, sino por el departamento que es dueño de la política y los participantes implicados dentro de la misma. Tener el apoyo y soporte de los directivos usualmente hace que la implantación de políticas sea mucho más fácil para las organizaciones.

8.3.4.7.5. Áreas de responsabilidad En este paso se define mucho más a fondo lo que se definió inicialmente en el alcance. En este paso, la División de Sistemas de Información, Ciencia y Tecnología debe asegurarse de asignar responsabilidades específicas a cada participante de la política definido en el alcance, al igual que

78

asegurarse de que no hayan casos de responsabilidades redundantes debido a auditorías y controles externos, por ejemplo.

8.3.4.7.6. Implementación y refuerzo Una vez la política está escrita y documentada, la parte más fácil ya está hecha. Distribuir la política a los usuarios de la institución y asegurarse de su continua aplicación es el verdadero reto. Es acá en donde el trabajo culmina en la obtención de los resultados esperados, es por esta razón que es de suma importancia tener al personal directivo activo y participando dentro de la aplicación y definición de las políticas. Es muy importante tener en cuenta que dependiendo de qué tan bien documentadas y fáciles de leer sean las políticas depende que los usuarios las apliquen de manera consecuente y no opongan mayor resistencia a su aplicación.

8.3.4.7.7. Revisión y Auditoría No es suficiente con definir, implementar, distribuir y poner en marcha la política; usualmente los cambios en la estructura o procesos de la institución afectan directamente el comportamiento de éstas, dependiendo de la gravedad de los cambios, se puede agregar una excepción a la política o si es necesario replantearla.

De la misma manera es importante hacer audito rías constantes a las políticas que no cuentan con una política computacional de apoyo para asegurarse de que los participantes la estén cumpliendo a cabalidad.

8.3.5. Plan de Seguridad Operacional Actualmente, la seguridad informática dentro de una institución pasó de ser un problema que solo se manejaba dentro del departamento de Información y Tecnología a ser algo que debe ser manejado y entendido en todos los niveles.

Lo que es más importante dentro de esta evolución de la seguridad informática, es que actualmente dentro de las organizaciones se trata de abordar los problemas de manera preventiva y no reactiva, como era la costumbre; es por esto que las organizaciones actualmente deben asegurarse no solamente de garantizar simplemente los servicios ofrecidos por su departamento, sino de entrenar e involucrar a todo el personal de la institución dentro de su Plan de Seguridad Informática.

En este documento se van a abordar las áreas más críticas sobre las cuales es importante que existan planes de contingencia o peracional de información y tecnología en una institución:

• Respuesta a Incidentes

• Recuperación de Desastres (entiéndase desastre como un siniestro de cualquier tipo, desde un huracán o inundación, hasta un acceso no autorizado a la red interna)

• Asuntos regulatorios (auditorías continuas)

79

• Políticas de Seguridad

• Mejoramiento continuo

Muchas veces estos temas por no ser del completo interés del personal que está constantemente envuelto en el área tecnológica, son pasados por alto o simplemente son tenidos en cuenta sin tener documentación alguna o procesos debidamente definidos al respecto.

8.3.5.1. Evaluación de Seguridad Operacional Para construir un plan de seguridad operacional de la división de información y tecnología es necesario primero realizar una evaluación general concentrándose en los puntos sobre los cuales es necesario reforzar o empezar a establecer un procedimiento debidamente definido y documentado.

Para esto, se puede hacer una evaluación a fondo acerca de los mismos puntos mencionados en la introducción:

• Respuesta a Incidentes

• Recuperación de Desastres (entiéndase desastre como un siniestro de cualquier tipo, desde un huracán o inundación, hasta un acceso no autorizado a la red interna)

• Asuntos regulatorios (auditorías continuas)

• Políticas de Seguridad

• Mejoramiento continuo

La primer área especificada es evidente, ¿qué se debe hacer en caso de que haya un incidente de seguridad? En caso de no tener planeada una reacción inmediata, es posible que en la búsqueda rápida de una solución solamente se logre agrandar el problema inicial luego de un incidente. La capacidad de respuesta del equipo es crucial en estos momentos, pues puede marcar la diferencia entre que los servicios estén abajo unas cuantas horas o unos cuantos días.

Las políticas deben hacer parte de cualquier institución, es por esto que es muy importante definir políticas que soporten la seguridad sin necesidad de crear una cantidad considerable de reglas y regulaciones que posiblemente confundan a los usuarios; un usuario confundido generalmen te tiende a hacer lo que cree que puede solucionar temporalmente un problema, o lo que le parezca más fácil.

Usualmente se piensa que solamente es necesario tener planes de contingencia ante desastres de tipo natural como inundaciones, incendios, terremotos, etc... Sin embargo es igualmente importante tener planes de recuperación claros para otros incidentes como intrusiones de red e incluso modificación, corrupción y falsificación de datos.

80

Inteligencia de Negocio….

Herramientas de Evaluación de Riesgos

Operational Critical Threat, Analysis, and Vulnerability Evaluations (OCTAVE): Es un proceso documentado que provee un formato extenso de evaluación de riesgos (www.cert.org/octave)

GAO Information Security Risk Assesment: Casos de estudio de organizaciones que implementaron procesos de evaluación de riesgos (www.gao.gov/special.pubs/ai99139.pdf)

Software Riskwatch: Es una herramienta que ayuda a los administradores de área de Información & Tecnología a realizar evaluación de riesgos. Incluye módulos para hacer revisiones contra ISO 17799. (www.riskwatch.com)

Consultative, Objective and Bi-Functional Risk Analysis: Software de evaluación de riesgos que incluye preguntas que se mapean contra el estándar ISO 17799 (www.security-risk-analysis.com/index.htm)

8.3.5.1.1. Respuesta a Incidentes La mayoría de organizaciones no implementan planes de respuesta a incidentes sino hasta el momento en que ocurre un incidente real por materialización de algún riesgo. Esto deja a las organizaciones en completo desconocimiento de aspectos básicos del estado de su red interna, tales como:

• No saber si, o por cuánto tiempo, o en qué grado la red ha sido obstruida

• No saber qué información ha sido robada o modificada debido al incidente y en qué grado dicha información es sensible y/o crítica para la institución

• Desconocimiento de los métodos que el intruso pudo utilizar para acceder sin permiso a la red interna

• No saber cómo reaccionar a tiempo y detener un incidente en curso

• No tener conocimiento de quién debe responder al incidente y de qué manera

81

• No saber a quién contactar dependiendo de la gravedad del incidente (directivos, ayudas legales, etc.)

Al no tener un plan claro para atender a dudas de este tipo que se pueden presentar al momento de la ocurrencia de un incidente, indirectamente se está poniendo la información y la institución misma en riesgo. Muchas veces se tienen ideas pre -establecidas acerca del manejo de incidentes, los cuales de una manera u otra pueden involucrar a la entidad en problemas, tales como:

• Es un problema muy grande para manejar

• Es más fácil ocuparse de los problemas a medida que se presentan

• Nuestro firewall y DMZ nos mantienen seguros

• El presupuesto es muy grande para ser gastado en algo que no hace parte de la misión de la institución

• El administrador del centro de cómputo es bastante hábil, seguro podrá hacerse cargo de cualquier incidente

Claramente, estas suposiciones no arreglan el problema desde ningún punto de vista; por lo tanto, es labor de la División de Sistemas de Información, Cienci a y Tecnología crear y mantener un equipo de respuesta a incidentes.

8.3.5.1.1.1. Servicios del Equipo de Manejo de Incidentes

El equipo interno de manejo de incidentes debe estar conformado principalmente por personal de la División de Sistemas de Información en Ciencia y Tecnología; sin embargo, es conveniente que también hagan parte de éste personal directivo s y encargados de cada división de la institución con el fin de establecer niveles de criticidad y sensibilidad de las operaciones. En la siguiente tabla se muestra un listado de los servicios que pueden ser prestados por el equipo dentro de Colciencias.

Equipo de Respuesta a Incidentes

Administración de Seguridad

Servicios Proactivos Servicios Reactivos

Análisis de riesgos Alertas y advertencias al personal

Alertas y advertencias al personal

Análisis de tendencias Comunicaciones acerca de posibles amenazas

Manejo de vulnerabilidades: - Análisis - Respuesta - Coordinación

Planeación de respuesta a Manejo de configuraciones en Manejo de incidentes:

82

incidentes servidores y mantenimiento de soluciones de seguridad

- Análisis - Soporte - Coordinación

Educación y conocimiento organizacional

Evaluación continua de seguridad informática

Manejo de sistemas: - Análisis - Respuesta - Coordinación

Entrenamiento Documentación de políticas y procedimientos de seguridad informática

Auditoría y mejoramiento continuo del plan, evaluación de herramientas

Detección de intrusos

8.3.5.1.1.1.1. Servicios de Administración de Seguridad

Este paquete de servicios incluye realizar un análisis de riesgos periódicamente con el fin de encontrar fácilmente las vulnerabilidades a las que está continuamente expuesta la red interna de la institución. El análisis de tendencias se refiere a monitoreos hechos periódicamente a la red interna con el fin de analizar y buscar patrones comunes de comportamiento. Existe un recurso en el que se explica a fondo la manera en que se puede hacer eficientemente análisis de tendencias, escrito por Tim Shemeall, Ph.D. y Phil Williams, Ph.D. del Centro de Análisis CERT de la Universidad Carnigie Mellon53.

La educación y entrenamiento a los usuarios es un tema que debe ser recurrente dentro de la planeación y debe ser realizado cada determinado tiempo, pues finalmente es en gran parte de los usuarios de quienes depende que un riesgo se materialice o no; igualmente, de esta manera el equipo de respuesta a incidentes se mantiene al día con las formas recientes de mitigación de riesgos y cultura organizacional. Mantener a los usuarios alerta ante este tipo de situaciones es necesario y crítico para la seguridad de la red interna, proveer información consistente y útil a los usuarios ayuda a que éstos adquieran un mayor nivel de compromiso hacia las políticas y procedimientos que se establezcan.

El equipo de administración de seguridad también debe realizar auditoría y seguimiento continuos a las políticas y procedimientos establecidos junto con sus respectivos ciclos para asegurar el mejoramiento de los mismos, así como nivel de compromiso de los usuarios hacia éstos.

Finalmente, este equipo también tiene dentro de sus responsabilidades, asistir al resto del equipo en la evaluación y análisis de herramientas de software nuevas que puedan ayudar a mantener y/o mejorar la estrategia de seguridad de la institución.

8.3.5.1.1.1.2. Servicios Proactivos

Incluyen estar constantemente advirtiendo y levantando alertas a los usuarios acerca de los riesgos y vulnerabilidades que existen; esto obviamente debe hacerse bajo una estrategia concisa 53 El documento completo sobre este tema puede ser encontrado en: http://www.cert.org/archive/pdf/info-security.pdf.

83

con el fin de no dar información innecesaria o sensible a quien no la necesita. De esta manera, en el caso de que se descubra una estafa que se realiza a través de phishing54, esta información debe ser comunicada de manera extraordinaria a todos los usuarios para evitar incidentes.

Los comunicados sobre amenazas más sensibles por el contrario, pueden ser avisados dentro de los comités , en donde se dan detalles técnicos y detallados a los directivos y el personal de la División de Sistemas de Información, Ciencia y Tecnología. Dentro de estos comités debe igualmente brindarse información suficiente a los usuarios acerca de las posibles maneras en que ellos pueden colaborar a que el riesgo no se materialice mientras es debidamente mitigado.

El manejo de configuraciones es una tarea que debe ser asignada a los administradores de la División de Sistemas de Información en Ciencia y Tecnología; con el fin de asegurar que todos los componentes de la red estén en continuo funcionamiento y configurados de manera que la red esté segura en todo momento.

8.3.5.1.1.1.3. Servicios Reactivos

Este tipo de servicios son los que se espera que no sean necesitados en ningún momento o al menos que no sean necesarios muchas veces dentro de un lapso de tiempo considerable. Tener un equipo que sea capaz de responder a incidentes informáticos en el menor tiempo posible puede ser la diferencia entre tener un problema simple de intrusión y un gran incidente de pérdida de datos e información valiosa. Dentro de los servicios que puede prestar el equipo reactivo están generar alertas y advertencias acerca de posibles intrusiones que estén en curso (durante una evaluación inicial), manejo y mitigación de vulnerabilidades; en caso de detectar riesgos o los proveedores de software informen que hay riesgos de seguridad en alguna aplicación, es responsabilidad de este equipo proveer planes de acción, proveer monitoreo a las aplicaciones, aplicar parches si es necesario, reinstalar aplicaciones o establecer procedimientos con el fin de evitar que se materialice algún tipo de riesgo. En caso de que un incidente llegase a ocurrir, este equipo debe ser el primero en responder a la alerta generada y proveer soluciones rápidas con el fin de que las operaciones no se vean de ninguna manera afectadas.

8.3.5.1.1.2. Políticas de Seguridad

Para tener un plan de contingencia completo y que funcione de la manera esperada, es necesario tener en cuenta políticas y procedimientos que los usuarios deben seguir con el fin de garantizar la integridad de los datos y la disponibilidad de los servicios. Como es bien sabido, una buena infraestructura tecnológica ayuda a la institución a crear un ambiente seguro para los datos y servicios, sin embargo, el establecimiento de políticas ayuda a mantener este ambiente. 54 Se denomina phishing a la técnica de captación ilícita de datos personales (principalmente relacionados con claves para el acceso a servicios bancarios y financieros) a través de correos electrónicos o páginas web que imitan/copian la imagen o apariencia de una entidad bancaria/financiera (o cualquier otro tipo de empresa).

84

Las políticas son necesarias para que las personas de la entidad tengan un compromiso claro con el plan de seguridad, pues son los usuarios quienes en última instancia en la mayoría de los casos ponen en riesgo la seguridad de la red interna. Cada política define una acción que debe ser tomada en pro de tener una red interna segura, lo cual indirectamente protege a la institución de futuros ataques; sin embargo, es necesario que éstas al igual que el resto de ramas que hacen parte del plan de contingencia estén en continua auditoría y mejoramiento de manera que no se vuelvan obsoletas o no efectivas. Las políticas deben ser claras y concisas, deben estar escritas en un lenguaje que sea fácil y agradable de leer para los usuarios y tener solamente la información que sea relevante para ellos (algunas de ellas podrían llegar a tener términos legales dependiendo de lo que se esté hablando, sin embargo esto no es una regla general); dentro de lo posible se debe evitar utilizar palabras técnicas dentro de una política, pues esto puede confundir a los usuarios. A continuación se muestra un listado de buenas prácticas que deben ser tenidas en cuenta al momento de documentar políticas de seguridad:

• Considerar el tipo de lector al que va a ir dirigida la política • Utilizar convenciones de nombres consistentes (por ejemplo, no utilizar en parte del

documento la palabra “host”, “cliente”, “estación de trabajo” y similares para referirse a lo mismo)

• Redactar las políticas en un lenguaje amigable y fácil de leer • Mantener los documentos actualizados • Tener en cuenta que debe haber balance entre protección y productividad • Designar un dueño de las políticas que se encargue de las actualizaciones y ciclo de vida de

las políticas dentro de la institución

8.3.5.1.1.3. Recuperación de Desastres

El planteamiento de un plan de recuperación de desastres es ligeramente diferente a los que se han nombrado anteriormente, pues en la construcción de éste es necesario que participen diferentes interesados de las divisiones de la institución con el fin de establecer elementos críticos en el momento de un siniestro y la recuperación de un desastre se compone del esfuerzo combinado de varios grupos dentro de la entidad.

El equipo de respuesta a incidentes deben hacer algo de investigación con el fin de determinar exactamente qué elementos deben direccionarse y de qué manera con el fin de crear un plan que sea específico y enfocado a las necesidades de respuesta y servicios críticos a mantener dentro la institución con el fin de que la operación no se vea afectada en caso de un incidente grave.

Los elementos clave de dicho plan deben ser:

• Evaluar y analizar las posibles amenazas a la operación y misión de la institución

85

• Evaluar el impacto de éstas en caso de que haya una interrupción de algunos o todos los servicios

• Manejo alternativo del proceso normal de negocio

• Recuperación y respaldo de los servicios ofrecidos

• Administración, operaciones y comunicaciones críticas al interior y exterior de la División de Sistemas de Información en Ciencia y Tecnología

• Preparar información acerca de los sistemas y configuraciones existentes

• Evaluación inicial del posible impacto de un siniestro

• Movilización del equipo de respuesta a incidentes

• Notificaciones a empleados, usuarios externos y medios de comunicación (de ser necesario)

• Mantener informes y documentación de todo lo que ocurre en la red interna

La División de Sistemas de Información, Ciencia y Tecnología debe asegurarse de cubrir las siguientes áreas claves al momento de crear un plan de recuperación de desastres:

• Planta física

• Hardware y software (crítico para la entidad)

• Comunicaciones internas y externas

• Información crítica

• Servicios prestados externamente (en caso de Colciencias, esto sería el portal Web)

• Operaciones de usuarios internos

• Servicios de comunicaciones y red prestados por la División de Sistemas de Información en Ciencia y Tecnología

• Otras operaciones críticas

A grandes rasgos, los pasos que pueden seguirse para conformar un equipo de trabajo y un plan de contingencia serían:

8.3.5.1.1.3.1. Planta Física Desarrollar planes de contingencia que aseguren que la operación siga funcionando dentro de lo normal en caso de que algún sistema deje de funcionar correctamente. ¿Podría transportar los

86

elementos críticos tales como computadores, inventario y equipo a un lugar en donde pueda montarse un ambiente temporal?, ¿Podría guardar equipos de reemplazo y activarlos a tiempo en caso de que haya una emergencia?, ¿Podría tener alguna parte del inventario y equipo en un lugar que no sea interno? Estas son algunas de las opciones que deberían revisarse para hacer un plan y asegurarse de que sus empleados sepan que hacer en cada caso.

Guardar y tener a mano (en un lugar ajeno a la institución) “uno más” de cada una de las cosas que considere realmente irremplazables es importante en caso de un siniestro. Si no es posible hacer esto, es bueno asegurarse de que dichos equipos estén especialmente protegidos y de que los empleados tengan conocimiento de esto.

Asegurarse de tener actualizados los equipos, inventario y planta física, de manera que ayuden a prevenir daños futuros; como reforzar paredes, adecuar las zonas en las que se encuentran los equipos que sean críticos, etc.

8.3.5.1.1.3.2. Operaciones

Tener respaldo eléctrico suficiente es importante en caso de que se presente una falla, si la edificación no cuenta con una planta eléctrica es necesario adquirir una, al igual que un sistema de respaldo para las estaciones de trabajo y servidores (UPS), la capacidad de la misma debe ser adecuada para la cantidad de máquinas que operan a la vez.

En caso de que las fallas eléctricas sean prolongadas, será necesario ahorrar la energía disponible de la UPS, esto se puede lograr apagando las estaciones de trabajo y servidores que no sean de importancia misional para la entidad; tomar estas medidas es indispensable con el fin de mantener no solamente la red de comunicaciones interno, sino los sistemas de ventilación, seguridad, iluminación, etc.

8.3.5.1.1.3.3. Información y Comunicaciones Es necesario tener back-up de la información crítica y sensible de la institución, como información financiera, datos de nómina y recursos humanos, inventarios, información acerca de áreas de investigación críticas, etc. También es importante guardar una imagen de cada uno de los servidores, sistemas operativos y archivos de inicio y software crítico. Guardar esta información crítica es de vital importancia, debe estar en un lugar ajeno a la institución y hacer parte del procedimiento interno de almacenamiento de back-ups.

Hacer arreglos con sus proveedores de hardware para que éstos repongan fácilmente partes y hardware críticos que se hayan dañado durante un siniestro es importante, al igual que mantener facturas, inventarios y documentación al día de todo el hardware crítico es importante para saber exactamente qué ordenar en caso de que sea necesario reemplazar algo rápidamente. Esta documentación debe, dentro de lo posible, estar fuera de la entidad.

87

Mantener una copia actualizada de:

• Números telefónicos, de celular y extensiones de todos los trabajadores

• Nombres de usuario y dentro de lo posible contraseñas de los empleados que manejan información sensible

Esto puede ser de suma utilidad al momento en que se presente un siniestro y sea necesario contactar rápidamente a alguien o acceder a su estación de trabajo. También es bastante útil crear entre los empleados un “árbol telefónico” con el fin de que las noticias se expandan rápidamente al momento en que sea necesario tomar acción sobre alguna situación en particular.

8.3.5.1.1.3.4. Aseguramiento de la Institución En caso de tener un seguro para la institución, revisar en qué medida cubre los daños que pueda causar un siniestro grave y si brinda el apoyo suficiente para rápidamente recobrar la operación de la entidad. ¿Cubriría el reemplazo y reposición de las máquinas de vital importancia para la institución? Es necesario crear un plan de auditoría anual para revisar la actualización del contrato del seguro y las condiciones arriba mencionadas.

De la misma manera es importante saber exactamente qué es lo que no cubre el seguro que posee la institución, de esta manera se pueden pedir paquetes extra que cubran los incidentes que un seguro normal no cubran tales como inundaciones, tormentas, terremotos, etc..

No es saludable asumir que debi do a que hay ciertas cosas que no han pasado, nunca van a pasar, una inundación podría no generarse internamente pero si en lugares aledaños y afectar indirectamente a la institución; un terremoto es algo que no se sabe dónde ni cuándo ocurrirá, y algo tan simple como una grieta en la pared puede llegar a colapsar en cualquier momento y generar daños graves a la planta e infraestructura.

Hay que asegurarse de que todo lo estipulado en el plan de contingencia quede debidamente documentado y sea probado mediante simulacros internos controlados y posteriormente evaluados. Un plan de contingencia sin probar puede ser bastante deficiente y, aunque no se pueden simular exactamente todos los imprevistos que puedan presentarse, se está más preparado luego de haber hecho evaluaciones y mejoras sobre el plan inicial, simular escenarios de desastres permite encontrar huecos y falencias que serían cruciales en una situación real.

8.3.5.1.1.4. Auditorías y Regulaciones Continuas Luego de llevar a cabo las labores de descubrimiento de riesgos y vulnerabilidades, se muestra rápidamente la necesidad de un cambio mayor, el plan de contingencia adecuado se puede ejecutar en forma oportuna.

Los planes de contingencia pueden mejorar la capacidad del estratega para responder velozmente a los cambios clave operados en las bases internas y externas de la estrategia presente de la institución. Muchas organizaciones preparan planes de contingencia sólo para circunstancia

88

adversas, lo cual es un grave error, porque tanto reducir las amenazas como capitalizar las oportunidades puede mejorar la posición competitiva de las empresas.

Es por esto que es de vital importancia estar regulando y auditando constantemente los planes creados con el fin de mejorarlos, teniendo en cuenta que hacer comités con todo el personal involucrado dentro del plan puede ser de gran ayuda al momento de la evaluación de los planes que se hayan llevado a cabo de manera exitosa y no e xitosa, ya sea a manera de simulacro o por la materialización de un riesgo. Luego de cada ejecución de uno de los planes es conveniente hacer una reunión de evaluación y lecciones aprendidas.

8.3.5.2. Alcance del plan de seguridad operacional La definición de un al cance ayuda a especificar exactamente qué incluye el desarrollo e implementación del plan de contingencia, esto hace más fáciles las labores siguientes de monitoreo y evaluación, pues existen criterios claros que evaluar y revisar.

A continuación un pequeñ o listado de la institución que tendrían según el área de seguridad informática que quiera tratarse:

8.3.5.2.1. Respuesta a Incidentes

El plan de seguridad operacional debe tener un plan de respuesta a incidentes claro y conciso con procedimientos definidos de las acciones a seguir en caso de un incidente, ya sea este de tipo físico, de infraestructura, natural, de comunicación, etc..

Dentro de las mejores prácticas también está la creación de un grupo de respuesta a incidentes, el cual ayudará en la ejecución de las actividades planeadas tanto en el momento de la simulación como en el momento en que un riesgo se materialice.

8.3.5.2.2. Administración de Políticas La administración de políticas debe incluir la documentación, revisión y mantenimiento de las políticas institucional es relacionadas con la seguridad de la información al interior de Colciencias (ver 8.3.4 Políticas de Seguridad para más información al respecto).

La administración de políticas no necesariamente debe recaer en el equipo de respuesta a incidentes, incluso es aconsejable que sea un grupo interdisciplinario con el fin de que todas las áreas de la institución tengan la participación adecuada en la formulación, revisiones y mejoramiento de las políticas.

8.3.5.2.3. Recuperación de Desastres Esto hace parte del plan de continuidad de negocio, es recomendable crear pequeños grupos al interior de cada área que se responsabilicen de tareas pequeñas en caso de un desastre, de manera que toda la responsabilidad no recaiga sobre la División de Sistemas de Información en Ciencia y Tecnología. Hay que ser claro dentro de cada plan especializado para cada área,

89

especificar qué factores y actividades planeadas incluye y no incluye, y de qué manera esto funciona dentro de un gran plan de recuperación de desastres a nivel interno en la institución.

8.3.5.2.4. Auditorías y Regulación Deben ser realizadas cada vez que un plan de contingencia sea llevado a cabo por cualquier grupo interno o por la institución como un todo. Debe estar en búsqueda del continuo mejoramiento y renovación de los planes ya creados con el fin de que sin importar que siniestro pueda llegar a presentarse, se aseguren dentro de lo posible, las operaciones normales de la entidad.

8.3.5.2.5. Costos La implementación de planes de contingencia traen consigo una inversión grande para la institución, ya sea por compra de herramientas, software, hardware, arreglos de planta física y entrenamiento de los usuarios, este último puede verse a simple vista representado en tiempo invertido por cada persona en su entrenamiento, sin embargo, la búsqueda de tutores y el intercambio de actividades operacionales por entrenamiento, es igualmente una inversión que la entidad hace en cada trabajador con el fin de asegurarse y protegerse de posibles incidentes a futuro.

La mayoría de actividades que se desarrollarán antes, durante y después de la creación del plan de contingencia, incluyen reuniones constantes, revisiones, simulacros, administración y actualización de datos y documentos, entre otras; es por esto que se debe tener muy en cuenta el “precio” de cada trabajador por hora al momento de crear el presupuesto para la implementación del proyecto, no solamente teniendo en cuenta los costos que puedan generar compras de materiales de hardware y software.

8.3.5.3. Tiempo Tener un equipo de respuesta a incidentes bien entrenado es de suprema importancia al momento en que se materializa un incidente, es en estos momentos en los que usualmente no se ve en riesgo la operación de la institución, sino muchos más factores como dinero que pueden perderse por cada minuto que un servicio está caído, o pérdida de imagen ante los usuarios externos y demás entidades del mismo tipo.

En muchos casos se puede observar que el tiempo que lleva auditar y coordinar una parte del plan de contingencia exige menos tiempo por parte del equipo y que existirán casos contrarios en los que el equipo debe velar continuamente por que todo marche bien (este es el caso del equipo de planta física, hardware y software). Este tipo de situaciones deben ser organizadas de acuerdo al cargo de cada persona y su disponibilidad para participar de lleno o en actividades de apoyo del plan de contingencia con el fin de no interferir con las operaciones normales de la institución.

90

8.3.5.4. Requerimientos Funcionales y Técnicos Existe una clara diferencia entre los requerimientos funcionales y técnicos que nos permitirán implementar claramente el plan de contingencia, a continuación una breve explicación de cada uno de ellos:

• Requerimiento funcional: Describen el conjunto de características que debe tener el plan como tal, pero no la manera en que éstas serán implementadas y acopladas.

• Requerimiento técnico: Deben ser derivados directamente de las necesidades que crean los requerimientos funcionales de cada una de las áreas, al definirse deben incluir detalles de cómo se alcanzarán los objetivos funcionales a través del uso de instrumentos técnicos.

8.3.5.4.1. Respuesta a Incidentes

• Funcional

Debe describir exactamente qué acciones deben ser llevadas a cabo en caso de que se llegue a presentar un incidente. Todos los pasos a seguir deben estar debidamente documentados y en conocimiento de todo el personal que llevará a cabo las acciones descritas.

• Técnico Los requerimientos técnicos deben describir el uso que se dará a cada una de las herramientas de hardware, software, tiempo y demás elementos que se utilicen con el fin de cumplir el objetivo funcional. Los nombres y configuraciones de las herramientas deben estar claramente definidos en el documento técnico.

8.3.5.4.2. Administración de Políticas

• Funcional Las políticas deben ser categorizadas dependiendo del área de la información a la que se refieren específicamente. Se deben pedir acciones concretas por parte de los usuarios y/o la institución con el fin de que sean correctamente entendidas y aplicables.

• Técnico

La especificación técnica de las políticas establece la manera en que éstas serán implementadas al interior de la institución, de manera que puede incluir los métodos que se utilizarán por ejemplo para mantener un control ordenado y secuencial de las versiones de políticas publicadas.

8.3.5.4.3. Respuesta a Desastres

• Funcional Definir las actividades específicas para las cuales se debe crear un plan de recuperación de desastres, es importante así mismo definir si se creará un solo plan global de continuidad de negocio o si se crearán muchos planes pequeños que definen cada área, formando así un todo. Se

91

debe especificar muy claramente el alcance que tendrá dicho plan de respuesta a desastres de manera que sea fácilmente evaluado.

• Técnico Los requerimientos técnicos de recuperación de desastres pueden ser relativamente variados de acuerdo al alcance especificado en el plan y los requerimientos funcionales definidos que desean alcanzarse. Se pueden definir de manera muy específica los tipos de respaldos energéticos, de hardware y software que serán utilizados para este fin; las tareas que se deben llevar a cabo para que estos sistemas entren a trabajar al momento del desastre, se debe especificar si hay usuarios que deben ser trasladados a sedes externas, la cantidad de espacio que se necesitará para guardar datos temporales, la criticidad de los equipos que estarán conectados a una fuente de energía alterna, entre otros.

8.3.5.4.4. Auditorías y Regulaciones Continuas

• Funcional

Especificar si la institución además de auditorías y revisiones internas debe cumplir con ciertas regulaciones externas (Por ejemplo: Circulares de la Comisión Intersectorial de Políticas y Gestión de Información para la Administración Pública –COINFO, o Directivas Presidenciales, etc.). ¿En qué áreas exigen que la institución cumpla y con qué parámetros?. Tener este tipo de cosas en cuenta hace que se facilite mucho la definición y planes de mejoramiento para los planes.

• Técnico Estos pueden variar completamente dependiendo de lo que sea definido como requerimiento funcional principal. Las especificaciones generales comprenden la manera específica y detallada en que se cumplirán los lineamientos de las auditorías que se realicen, tales como especificaciones de software, ciclos de auditoría y herramientas que serían usadas para monitoreo de la red.

8.3.5.5. Personal Requerido El plan de seguridad operacional necesitará personal que esté dentro de la División de Sistemas de Información, Ciencia y Tecnología y fuera de ella. Se debe ser cuidadoso al escoger al personal, deben ser personas de absoluta confianza para la institución, que estén en completa capacidad de trabajar en condiciones de presión extrema, y dentro de lo posible deben ser personas de cargos medios, ya que mantienen comunicaciones directas con niveles por encima y debajo de ellos, haciendo más eficientes las comunicaciones de cualquier tipo.

Luego de identificar el personal a escoger, se debe hacer una evaluación y capacitación de manera que sea posible definir claramente cuáles son las habilidades que se necesitan desarrollar con el fin de crear un plan de contingencia sólido. Como se mencionó anteriormente, se deben escoger cuidadosamente las personas que harán parte del personal del plan en todos los departamentos que se considere deben involucrarse en el proceso, pues el tiempo de estas pe rsonas hará parte directa del presupuesto con el que se cuenta para la implementación del proyecto.

92

Es importante darse cuenta de que no solamente el personal de las áreas de Información y Tecnología debe hacer parte de, entre más organizado e integrado esté el personal con el proyecto, mucho más fácil será crear y mantener un plan de contingencia robusto y fácilmente renovable.

Hay que asegurarse de que las actividades del proyecto consuman el menor tiempo posible a cada uno de los participantes, sin olvidar la importancia de mantener todos los procesos derivados de la creación del plan debidamente documentados, actualizados y al alcance de cualquiera de los participantes. Esto hace que la velocidad de reacción en caso de un siniestro y el compromiso del personal hacia el proyecto sean mayor.

8.3.5.6. Pasos a Seguir para Implementar un Proyecto de Seguridad Operacional

• Desarrollar un plan de respuesta a incidentes

a. Evaluar la respuesta a incidentes actual

b. Desarrollar plan de respuesta a incidentes

c. Conformar un grupo de respuesta a incidentes

d. Desarrollar un sistema de notificación de incidentes

e. Desarrollar una metodología de pruebas para el plan de respuesta a incidentes

f. Crear un cronograma de revisiones de seguimiento del plan de respuesta a incidentes

g. Crear espacio para entrenamiento de equipo de respuesta a incidentes

• Desarrollar una metodología de administración de políticas

a. Revisar las políticas existentes

b. Crear una lista con las políticas existentes que están siendo usadas

c. Identificar las falencias en las políti cas existentes

d. Desarrollar, revisar y actualizar las políticas de acuerdo al documento de políticas entregado previamente

e. Llevar a cabo una reunión de revisión de las políticas antes de publicarlas

f. Publicar la políticas revisadas y actualizadas

g. Desarrollar planes de auditoría y mantenimiento de las políticas

• Planeación de Desastres

93

a. Examinar y analizar potenciales riesgos, vulnerabilidades y amenazas

b. Evaluar el impacto real a la institución en caso de una interrupción de los servicios

c. Revisar la necesidad de servicios de emergencia

d. Preparar una evaluación inicial de el potencial impacto de una emergencia

e. Definir procesos y procedimientos que permitan la fácil movilización de los equipos de respuesta a desastres

f. Definir procesos y procedimientos que permitan notificar rápidamente a empleados, familiares y medios acerca de un siniestro

• Auditoría y Regulaciones

a. Identificar las regulaciones que afectan directamente a la institución

b. Identificar los procedimientos y políticas necesarios para obtener y mantener la conformidad de parte de los auditores

c. Implementar los cambios requeridos para la conformidad

d. Identificar los requerimientos legales necesarios para hacer reportes y documentación

8.3.5.7. Lista de Chequeo para Revisiones

8.3.5.7.1. Evaluación de Seguridad Operacional R La planeación de seguridad operacional ayuda a soportar y reforzar la seguridad de la

red enfocándose en las necesidades de seguridad informática de la institución

R El plan de seguridad está dividido en áreas más pequeñas que se pueden implementar por equipos diferentes: respuesta a incidentes, políticas de seguridad, recuperación de desastres y, auditoría y regulación

R La respuesta a incidentes es manejada por un equipo de respuesta a incidentes

R La misión del equipo de respuesta a incidentes puede dividirse en 3 áreas: administración de servicios, servicios proactivos y servicios reactivos.

R Existen políticas y procedimientos que garantizan la seguridad de la información por parte de usuarios

R Las políticas están escritas en un lenguaje claro, conciso y fácil de entender para todos los usuarios a los que son aplicables

94

R Se hacen campañas constantes de advertencia y capacitación acerca de las políticas de seguridad con el fin de darlas a conocer a los usuarios

R La planeación de desastres hace parte importante de un proyecto más grande de continuidad de negocio

R La planeación de desastres incluye una visión sobre los equipos, operaciones de Información y Tecnología, y funciones de negocio

R Las auditorías tanto internas como externas se hacen en pro de la mejoría del plan planteado inicialmente

R Usar todos los lineamientos del plan con el fin de llenar las expectativas de las auditorías planeadas con el fin de mejorar continuamente el plan inicial

8.3.5.7.2. Equipo de Trabajo R Asegurarse de tener un equipo multidisciplinario con el fin de mantener la seguridad

informática vista desde puntos de vista diferentes siempre R Se realizan reuniones de seguimiento periódicamente con el fin de capacitar, auditar y

actualizar al personal R Las políticas, procedimientos y procesos son creados de manera consistente con el

personal representante de cada área

8.3.5.7.3. Institución

R Existe colaboración y entendimiento entre los diferentes departamentos con el fin de enfocar correctamente el alcance del proyecto completo

R La planeación e implementación de muchos de los pasos que componen el proyecto pueden hacerse en paralelo. Es necesario identificar éstos con el fin de no trabajar de manera cruzada dentro del equipo o con algún otro equipo

95

9. Continuidad

Las personas que deseen realizar proyecto de grado en Colciencias deben tener en cuenta que la entidad hasta ahora está empezando a implementar un plan de seguridad de la información, por eso hay varios temas en donde profundizar. Se listan a continuación.

• Documentación de Políticas de Seguridad. En este proyecto de grado se hizo un bosquejo inicial de políticas de seguridad de la información para Colciencias, que se espera siga siendo implementado. Con este se da un listado de las políticas que la entidad debe empezar a documentar para que asegure mejor los datos y los sistemas de información.

• Esquema de Copia de Seguridad (Back-Up). Colciencias ha venido trabajando en un sistema de copias de seguridad pero no está muy bien definido, por eso es necesario realizar un esquema completo que de los lineamientos para un óptimo almacenamiento de los datos que garanticen la seguridad de la información.

• Plan de Contingencia. Es fundamental que Colciencias tenga un plan de contingencia que

ante un desastre de grandes proporciones le ayude a continuar con las actividades que realiza. Por eso es necesario que se dé a la entidad los lineamientos que le ayuden a generar dicho plan para garantizar su permanencia en el país.

• Análisis de Riesgos. Aunque este análisis se hizo en el semestre 2007-2 y 2008-1, es

importante que se haga este tipo de análisis frecuentemente. Se hace esta recomendación porque si es bien sabido los sistemas de información cambian constantemente, lo que lleva a la entidad a actualizarlos, pero estas actualizaciones traen consigo nuevas vulnerabilidades que ponen en riesgo la información.

96

10. Conclusiones

Colciencias, entidad encargada de la investigación, desarrollo e innovación en ciencia y tecnología en Colombia; no cuenta con planes de seguridad de la información y contingencia que garanticen la protección de la información. Esta entidad debe cambiar el panorama que tiene acerca de este tema, pues la información de la entidad es el recurso más importante y actualmente no se está garantizando su seguridad y buen manejo. Con base en esto debe empezar a ge nerar planes que les permita proteger la información crítica que salvaguarda la entidad.

Es aconsejable que Colciencias comience a adaptar el modelo de seguridad propuesto en este documento, lo cual permitirá al personal profundizar y concientizarse sobre la importancia de la seguridad de la información. Para ello la entidad debe empezar a desarrollar estrategias que le permitan dar a conocer la importancia de la seguridad de la información a todo el personal involucrado.

En general se observó que existe falta de compromiso por parte de toda la entidad en temas relacionados con la seguridad de la información. Algunas charlas que se tuvieron con funcionarios de la institución dejaron ver que el tema de la seguridad de la información no es relevante y consideran que es responsabilidad exclusiva de la División Sistemas de Información en Ciencia y Tecnología. Es evidente que la institución debe empezar a tomar los correctivos necesarios y cambiar la visión de que solamente una división de la entidad se debe hace r cargo de la seguridad. Es bien sabido que para que un proyecto, plan, etc., funcione en una organización, todos las personas deben estar comprometidas con éste, en especial los altos directivos55.

Actualmente las entidades gubernamentales no cuentan con planes de seguridad y contingencia de incidentes informáticos claros, y Colciencias, como entidad que busca enfatizar en áreas académicas e investigativas en información y tecnología, debería estar a la vanguardia en este aspecto; razón por la cual se propuso un plan semi-integral que incluya no solamente la implementación de auditorías internas continuas para descubrir vulnerabilidades, sino políticas definidas que garanticen el buen uso de los recursos, una guía para la creación de un plan de contingencia que contemple la mayor cantidad de situaciones posible, las reacciones y medidas a tomar; y un manual en el que se muestra cuales deberían ser los pasos a seguir para mitigar las vulnerabilidades existentes actualmente en los servidores críticos de la enti dad. Los servidores donde se encuentra la información de la entidad y sus programas misionales, deben ser actualizados constantemente. Se observó que a estos sistemas no se les están haciendo los mantenimientos y revisiones adecuados, porque presentan fallas de seguridad que pueden generar problemas a toda la organización; la mayoría de problemas encontrados eran de configuraciones de seguridad que deben ser revisados cuidadosamente antes de poner el servidor en ambiente de producción, o tienen que ver directamente con falta de actualizaciones de seguridad al sistema operativo. Las observaciones mencionadas acerca de la configuración de los servidores se sustentan en los análisis de vulnerabilidades hechos a los servidores críticos de Colciencias desde el interior de la entidad y fuera de ella, luego del montaje del bosque virtual que pretendía emular los servidores de la entidad, la mayoría de vulnerabilidades se corrigieron simplemente al hacerle actualizaciones 55 Sistemas Empresariales. Olga Lucia Giraldo Vélez. Segundo semestre de 2007. Notas de clase.

97

al sistema operativo y deshabilitar servicios que no son necesarios y por el contrario si podrían llegar a brindar información de más a un posible atacante. Es importante que todos los procedimientos propuestos durante la realización de este trabajo de grado sean revisados, auditados y reforzados periódicamente por el personal de Colciencias con el fin de asegurar su continuidad y usabilidad para la entidad. De otra manera todo el trabajo se verá estancado y eventualmente se tendría que empezar desde ceros para poder implementar un plan de seguri dad que sea apropiado para las necesidades y configuraciones actuales de la entidad.

98

11. Glosario

El glosario presentado aquí intenta mostrar o aclarar varios términos de la seguridad de la información. En muchas ocasiones las personas confunden unos entre otros lo que los lleva a hacer caso omiso de estos porque les parece que eso ya lo han hecho, ejemplo de esto, la persona encargada de la seguridad de la entidad le dice a alguien que ese documento es confidencial, este no tiene claro el concepto y hace público el documento que le fue entregado. Por ello es importante tener estos conceptos claros que den un buen desempeño relacionado a la seguridad por parte de todas las personas.

11.1. Confidencialidad Aseguramiento de la información ya sea por medio de cifrado, para que sólo sea compartida con ciertas personas u organizaciones. Se da incumplimiento a esta norma cuando no se da un manejo adecuado de los datos que salvaguarde la información. Se incumple por medio de la comunicación verbal, i mpresiones, vía mail, etc.

11.2. Disponibilidad La garantía de que la entrega, almacenamiento y procesamiento de la información son accesibles cuando sea necesario, por las personas que los necesitan. Para garantizar esto, es necesario que se tenga un sistema alterno corriendo sobre el que se está protegiendo, por si se presenta un incidente en este, se pueda poner a correr el alterno, garantizando que el servicio este siempre disponible.

11.3. Estándar Los estándares a diferencia de las políticas, se refieren a cosas más específicas relacionadas con la tecnología, metodologías y procedimientos de implementación. Los estándares son válidos por unos pocos años, además deben ser cambiados constantemente porque los manuales de procedimientos, la estructura organizacional , los procesos de negocio y las tecnologías de los sistemas de información descritas en muchos estándares cambian rápidamente. Por ejemplo un estándar podría ser que todo sistema nuevo debe cumplir con las normas X.509 que garanticen una comunicación segura por medio de cifrado, este estándar debe ser revisado, expandido o reemplazado en pocos años por la evolución de la tecnología.

11.4. Integridad Es la garantía de que la información es auténtica, además de estar completa. Que la información sea confiable y lo suficientemente precisa para el fin que fue hecha. La integridad representa uno de los principales indicadores de la seguridad de la información. Para garantizar la integridad de la información se puede hacer por medio de firma electrónica o certificado di gital56.

56 Una firma digital es, en gestión de documentos electrónicos, un método criptográfico que asocia la identidad de una persona o de una entidad al mensaje o documento desplegado. Dependiendo del tipo de firma, puede también asegurar la integridad del documento o mensaje.

99

11.5. Control Conocido como medidas de seguridad y se define como el mecanismo usado para regular o guiar las operaciones de una máquina, aparato o sistema. Por ejemplo, un control sería cifrar información sensible que se guarda en un CD.

11.6. Política Son instrucciones indicando las intenciones de manejo acerca de las operaciones de la institución. Son sentencias de un alto nivel que provee a los empleados que deben tener presente en futuras decisiones. Las políticas son requerimientos generalizados que deben ser escritos y divulgados dentro de todos los funcionarios de la institución y, en ciertas ocasiones a personas externas a ésta. Están en un nivel superior que los estándares, sin embargo ambos requieren de cumplimiento en los manejos de instrucciones fre nte a la información.

11.7. Procedimiento Son pasos de operaciones específicas que los empleados deben seguir para cumplir con un objetivo. Por ejemplo en el manejo de datos existen distintos procedimientos para hacer copias de seguridad a los discos. Se anota que las políticas describen en forma general la forma de manejar la información, mientras el procedimiento dice exactamente qué hacer. A continuación se muestra una pirámide donde se muestra el nivel de algunas de las anteriores definiciones, esto permitirá ver que tiene mayor prioridad y por consecuencia, hacer mayor énfasis.

La firma electrónica, de la misma manera que la firma manuscrita, puede vincularse a un documento para identificar al autor, puede ser usada para señalar conformidad (o disconformidad) con el contenido, indicar que un documento se ha leído o, según el tipo de firma, garantizar que el contenido no puede ser modificado.

100

El establecimiento de estándares se logra mediante la correcta documentación de todos los procedimientos, guías y prácticas existentes que se aplican dentro del entorno de trabajo actual (operaciones diarias). Conformidad se refiere al continuo monitoreo y auditoría de todas los ítems descritos en los niveles superiores de la pirámide.

Entorno Actual

Conformidad

Procedimientos, Guías y Prácticas

Estándares

Política

101

12. Bibliografía

• Maiwald, E., Sieglein, W.: Establishing Policies and Procedures, Security Planning & Disaster Recovery (Libro Virtual), 2002. McGraw-Hill

• Cresson W. Charles. Information Security Policies Made Easy, 1997. Baseline Software, Inc. 1-881585-04-2

• http://www.yourwindow.to/information%2Dsecurity/, The Information Security Glossary. (En línea) 12 de abril de 2008

• http://www.kaonsecurity.co.nz/html_pages/policy_main_files/Policies.htm. INFORMATION SYSTEMS SECURITY POLICIES. Creating a Secure Environment. (En línea) 12 de abril de 2008.

• POLITICAS DE CORREO DE COLCIENCIAS, Políticas Generales. Documento entregado por María Clemencia Reyes el jueves 10 de abril de 2008.

• Uso de contraseñas. Documento entregado por María Clemencia Reyes el jueves 10 de abril de 2008.

• www.syngress.com/book_catalog/381_Sec_IT_PM/sample.PDF , IT Operational Security Plan. (En línea) 20 de abril de 2008

• http://www.tuobra.unam.mx/publicadas/040710174457.html, La auditoría interna y los planes de contingencia. (En línea) 25 de abril de 2008

• www.arcert.gov.ar/politica/PSI_Modelo-v1_200507.pdf, Modelo de Política de Seguridad de la Información para Organismos de la Administración Pública Nacional, (En línea) 27 de abril de 2008

• http://www.guinix.com/technote/dualdns.html. Computing Without Borders. (En línea) 2 de mayo de 2008.

• http://homepages.tesco.net/%7EJ.deBoynePollard/FGA/dns-split-horizon.html . Providing "split horizon" DNS service. 2003. (En línea) 2 de mayo de 2008.

• http://www.clarin.com/diario/2005/12/13/um/m-01106938.htm. Preocupa la falta de seguridad informática en Latinoamérica. Estudio de IBM y Cisco, (En línea) 5 de Mayo de 2008

• www.auditoria.gov.co/9_documentos/6_2_8_lucio_molina_focazzio.ppt. Molina F. Lucio Augusto. La seguridad en los sistemas de información de las entidades públicas y los desafíos para las entidades de control fiscal. (En línea) 5 de Mayo de 2008

• http://www.gocsi.com/. Richardson Robert. CSI Computer Crime and Security Survey, Computer Security Institute. (En línea) 5 de mayo de 2008

102

Anexos

Anexo A Se entrega en medio magnético los siguientes documentos:

1. Modelo_de_Seguridad_Informática_Colciencias.pdf. Este documento en pdf.

2. Pruebas.zip. Archivos correspondientes a las pruebas hechas a los servidores de Colciencias, así como las pruebas hechas a los ambientes virtuales montados.

3. Archivos.zip. Archivos de configuración inicial y final de los servidores virtuales.

Anexo B Se entrega como anexo a este documento un análisis hecho a cinco servidores que no eran parte de este trabajo de grado.

Análisis y Revisión de Vulnerabilidades a Servidores

COLCIENCIAS

1. Tabla de Contenidos

1. TABLA DE CONTENIDOS ...................................................................................................102

2. INTRODUCCIÓN...............................................................................................................103

3. SERVIDORES ANALIZADOS ...............................................................................................103

3.1. KALDASIA ....................................................................................................................103 3.2. LAPOLA ......................................................................................................................103 3.3. MIRTHAYU ..................................................................................................................104 3.4. PAMPLONITA ...............................................................................................................105 3.5. THIRINA ......................................................................................................................106 3.6. WAIRA .......................................................................................................................106

103

2. Introducción Como parte adicional del análisis hecho a los serv idores que están contemplados dentro del alcance general del proyecto, se hizo un análisis y revisión de vulnerabilidades existentes en los demás servidores de la entidad con el fin de que luego, sean los mismos funcionarios de Colciencias quienes se encarguen de la mitigación de los riesgos encontrados.

3. Servidores Analizados A continuación se presenta la lista de servidores analizados junto con las vulnerabilidades encontradas y sus posibles soluciones, el color amarillo se refiere a vulnerabilidades de nivel medio y las de color rojo a vulnerabilidades de nivel alto:

3.1. Kaldasia v Servidor telnet funcionando:

Un servidor telnet está escuchando en el servidor remoto: Usar telnet no es recomendable, pues los nombres de usuario, contraseñas y comandos viajan en texto plano.

Un atacante podría escuchar en el puerto durante una sesión telnet y obtener las credenciales de los usuarios que se encuentren autenticados.

Solución: Deshabilitar el servicio telnet y utilizar SSH en su lugar.

v Servidor FTP contiene directorios públicos:

El servidor remoto contiene directorios públicos con permisos de escritura: Recorriendo el servidor FTP remoto, se encontró que muchos directorios que fueron marcados como públicos y con permisos de escritura.

Un atacante podría usar este problema de configuración para guardar datos arbitrarios en el servidor, incluyendo datos ilegales como películas Divx, cracks, etc..

Solución: Configurar los directorios del servidor FTP de manera que no tengan permisos de escritura públicos.

3.2. LaPola v Transmisión de credenciales en texto plano:

El servidor remoto podría transmitir credenciales en texto plano: El servidor Web remoto contiene múltiples formatos HTML que contienen un campo de texto de tipo ‘password’ que transmite la información a un servidor Web remoto en texto plano.

Un atacante podría escuchar el tráfico y utilizar la configuración actual para obtener nombres de usuario y contraseñas de usuarios válidos.

104

Solución: Asegurarse de que todos los formularios transmitan la información utilizando el protocolo HTTPS.

v Enumeración de nombres en el servidor remoto:

Es posible enumerar los nombres de usuarios válidos en el servidor remoto: El servidor SMTP remoto responde a los comandos EXPN y/o VRFY.



Solución: En caso de estar utilizando Sendmail, agregar la opción:



3.3. Mirthayu v Métodos HTTP TRACE / TRACK

Las funciones de depuración están habilitadas en el servidor Web remoto: El servidor remoto soporta los métodos TRACE y/o TRACK; ambos son métodos HTTP usados para depurar conexiones de servidores Web.

Adicionalmente, se ha demostrado que los servidores que soportan el método TRACE son vulnerables a ataques XSS (Cross Site Scripting) y XST (Cross Site Tracing) usados en conjunto con varias debilidades encontradas en los navegadores. Un atacante puede usar esta vulnerabilidad para engañar a los usuarios oficiales del sitio Web de la organización y obtener sus credenciales, por ejemplo.

Solución: Deshabilitar ambos métodos mencionados.

v Enumeración de nombres en el servidor remoto:

Es posible enumerar los nombres de usuarios válidos en el servidor remoto: El servidor SMTP remoto responde a los comandos EXPN y/o VRFY.



105

Solución: En caso de estar utilizando Sendmail, agregar la opción:



v Telnet acepta inicio de sesión de usuarios anónimos:

Es posible iniciar sesión en el sistema remoto sin necesidad de autenticarse: La versión de telnet remota no limpia la variable de entorno ‘USER’ proporcionada por el usuario. Proporcionando una variable de entorno ‘USER’ especialmente malformada, un atacante podría forzar al servidor telnet remoto de tal manera que crea que el usuario ya está autenticado.

Solución: Instalar el parche 120068-02 para Sparc, disponible en el sitio de Sun57. Otra posible solución es deshabilitar el servicio de telnet y usar SSH en su lugar, o usar inetadm para mitigar el problema.

3.4. Pamplonita v Java servlet permite acceso sin autenticación:

El servidor Web remoto permite acceso sin autenticación a un Java servlet administrativo: El servidor Web remoto tiene una versión de JBoss que permite acceso sin autenticación a los servlets JMX y/o Consola Web utilizados para administrar JBoss y sus servicios. Un atacante remoto puede utilizar esta vulnerabilidad como palanca para descubrir información sensible acerca de la aplicación afectada e incluso tomar control total de la misma.

Solución: Asegurar el acceso a los servlets siguiendo los pasos descritos en este Wiki58.

v Microsoft Windows Remote Desktop Protocol Server Private Key Disclosure Vulnerability:

Es posible tener acceso al cliente remoto: La versión remota del Remote Desktop Protocol Server (Terminal Service) es vulnerable a un ataque de tipo man -in-the-middle.

Un atacante puede explotar esta vulnerabilidad para descifrar comunicaciones entre cliente y servidor y obtener informacion sensitiva (contraseñas, etc..).

Solución: Forzar el uso de SSL como capa de transporte para este servicio especifico.

57 http://sunsolve.sun.com/search/document.do?assetkey=1-21-120068-02-1 58 http://wiki.jboss.org/wiki/SecureTheJmxConsole

106

3.5. Thirina v Paquetes de cifrado SSL pobremente soportados:

El servicio remoto soporta el uso de cifradores SSL débiles: El cliente remoto soporta el uso de cifradores SSL que ofrecen cifrado débil de información o ningún cifrado en absoluto.

Solución: Reconfigurar la aplicación afectada si es posible para evitar el uso de cifradores de información débiles.

v Utilización de un protocolo SSL desaprobado:

El servicio remoto cifra la información utilizando un protocolo con vulnerabilidades conocidas: El servicio remoto acepta conexiones cifradas usando SSL 2.0, el cual es conocido que sufre de varias fallas criptográficas y ha sido desaprobado por varios años.

Un atacante potencial podría explotar cualquiera de las debilidades conocidas y ha sido desaprobado durante varios años. Igualmente, puede explotar esta vulnerabilidad para reproducir ataques de tipo man-in-the-middle o descifrar las comunicaciones entre el servicio afectado y los clientes.

Solución: Consultar la documentación de la aplicación para deshabilitar el uso de SSL 2.0 y usar SSL 3.0 o TSL 1.0 en su lugar.

v Vulnerabilidad Cross Site Scripting:

El servidor remoto es vulnerable a un ataque de XSS: EL servidor remoto no hace revisión de los datos que provee un usuario en los formularios al User-Agent header antes de usarlos para generar contenidos dinámicos en una página de error. Un atacante remoto no autenticado, puede usar esta vulnerabilidad como palanca para inyectar código HTML arbitrario o un scri pt en el navegador del usuario y ejecutarlo dentro del contexto seguro del sitio Web afectado.

Solución: Aplicar alguno de estos parches de seguridad:

Parche No. 159

Parche No. 260

v Vulnerabilidad de revelación de información:

El servidor remoto está afectado por una vulnerabilidad de revelación de información: El servidor remoto está corriendo Adobe Macromedia ColdFusion, un producto para desarrollar y liberar aplicaciones Web.

59 Disponible en: http://www.securityfocus.com/archive/1/459178/30/0/threaded 60 Disponible en: http://www.adobe.com/support/security/bulletins/apsb07-04.html

107

La versión de ColdFusion instalada en el servidor remoto permite a un atacante ver los contenidos de los archivos que no son interpretados por ColdFusion en sí y que siguen guardados en el sistema afectado. Este problema se debe al hecho de que con ColdFusion, los archivos codificados en una URL son decodificados primero pos IIS y luego por ColdFusion nuevamente. Pasando un nombre de archivo seguido de un byte nulo doblemente codificado con una extensión que ColdFusion pueda manejar, tal como ‘.cfm’, un atacante remoto puede descubrir información sensible, tal como credenciales y nombres de máquinas contenidos en scropts, archivos de configuración, etc..

Solución: Actualizar la versión de ColdFusion a ColdFusion MX 7.0.1 y aplicar los parches necesarios.





3.6. Waira v LDAP Permite conexiones anónimas

El servidor LDAP permite acceso anónimo: La configuración actual permite hacer conexiones al servidor sin necesidad de autorización –utilizando ‘NULL BIND’- y pedir información. A pesar de que las consultas permitidas puede que sean restringidas, puede que un potencial atacante logre obtener información confidencial.

Solución: Configurar el servidor LDAP de manera que no acepte NULL BINDS






El servidor remoto es vulnerable a ataques de “fisgoneo” de cache: El servidor DNS remoto responde consultas a dominios de terceros que no tienen configurado el bit de recursión.

108

Esto puede permitir que un atacante determinar cuáles dominios han sido resueltos últimamente, por lo tanto, puede saber que clientes han sido visitados recientemente.

Por ejemplo, si un atacante está interesado en saber qué servicio web de tipo financiero utiliza la compañía, podría utilizar este tipo de ataque para construir un modelo estadístico de que tanto se utiliza este servicio financiero.


Solución: Restringir el acceso al cache del DNS para usuarios locales.


El servidor de nombres remoto permite la ejecución de consultas recursivas realizadas por el cliente usando nessusd: Es posible consultar al servidor de nombres remoto acerca de nombres de terceros. Si este es el servidor de nombres internos, esta advertencia puede ser pasada por alto.


Solución: Restringir las consultas recursivas a todos los clientes que utilicen este servidor de nombres (por ejemplo, los clientes de la LAN conectados a él). Si está utilizando bind 8, puede hacerse esto utilizando la instrucción “allow-recursion” en la sección “options” de el archivo named.conf. Si está usando bind 9, puede definir un grupo de direcciones internas utilizando el comando “acl”; dentro del bloque de opciones, puede escribir este comando: ‘allow-recursion { hosts_defined_in_acl }’. Si está utilizando otro servidor de nombres, consulte la documentación del mismo.

[MODELO DE SEGURIDAD INFORMÁTICA COLCIENCIAS]

Documents

Transcript of [MODELO DE SEGURIDAD INFORMÁTICA COLCIENCIAS]