.ds LF P. Holbrook .ds RF FORMFEED[Pág. %] .ds CF .ds LH RFC 1244 .ds RH Julio 1991 .ds CH Grupo de Trabajo del Manual de Políticas de Seguridad de Sitios .pl 10.0i .po 0 .ll 7.2i .lt 7.2i .nr LL 7.2i .nr LT 7.2i .hy 0 .ad l .nf Network Working Group P. Holbrook Request for Comments: 1244 CICNet FYI: 8 J. Reynolds ISI Editores Julio 1991 .ce Manual de Seguridad de Sitios .ti 0 Condición de este Memorándum .in 3 Este manual es el producto del Grupo de Trabajo del Manual sobre Política de Seguridad de Sitios (SSPHWG), un trabajo combinado del Area de Seguridad y el Area de Servicios de Usuario del Grupo Especializado de Ingeniería de Internet (IETF). Este RFC FYI proporciona información para la comunidad de Internet. No especifica ningún estándar de Internet. Su distribución es ilimitada. .ti 0 Autores Colaboradores .in 3 Los siguientes son los autores del Manual de Seguridad de Sitios. Sin su dedicación, este manual no habría sido posible. Dave Curry (Universidad Purdue), Sean Kirkpatrick (Unisys), Tom Longstaff (LLNL), Greg Hollingsworth (Universidad Johns Hopkins), Jeffrey Carpenter (Universidad de Pittsburgh), Barbara Fraser (CERT), Fred Ostapik (SRI NISC), Allen Sturtevant (LLNL), Dan Long (BBN), Jim Duncan (Universidad del Estado de Pennsylvania), y Frank Byrum (DEC). .ti 0 Nota del Editor .in 3 Este RFC FYI es una primera tentativa de proporcionar a los usuarios de Internet orientación sobre como ocuparse de los asuntos de seguridad en Internet. De esta manera este documento es necesariamente incompleto. Hay algunas deficiencias claras; por ejemplo, este documento se centra mayormente en recursos disponibles en los Estados Unidos. En el espíritu de la serie de documentos de Internet "Petición De Comentarios", animamos a los usuarios a colaborar en este manual. En especial, a aquellos que utilizan este documento para crear sus propias políticas y procedimientos. Este manual pretende ser un punto de partida para fomentar la investigación y se le debería ver como un recurso práctico, pero no la autoridad final. Diferentes organizaciones y jurisdicciones tendrán recursos y reglas diferentes. Hable con sus organizaciones locales, consulte un abogado bien informado, o consulte el cumplimiento de las leyes locales y nacionales. Estos grupos pueden ayudar a rellenar los huecos que este documento no puede esperar cubrir. Finalmente, pretendemos que este RFC FYI crezca y evolucione. Por favor envíe comentarios y sugerencias a: ssphwg@cert.sei.cmu.edu. .ti 0 Tabla de contenidos .nf 1. Introducción..................................................... 3 1.1 Objetivo de este Trabajo........................................ 3 1.2 Público......................................................... 3 1.3 Definiciones.................................................... 4 1.4 Trabajo Relacionado.............................................. 4 1.5 Alcance......................................................... 4 1.6 ¿Por Qué Necesitamos Políticas y Procedimientos de Seguridad?... 5 1.7 Metodología Básica.............................................. 7 1.8 Organización de este Documento.................................. 7 2. Establecer Políticas de Sitio Oficiales de Seguridad Informática. 9 2.1 Breve Introducción.............................................. 9 2.2 Valoración de Riesgos........................................... 10 2.3 Asuntos Políticos............................................... 13 2.4 Qué Sucede Cuando la Política de Seguridad es Violada........... 19 2.5 Bloquear Dentro o Fuera......................................... 21 2.6 Interpretación de la Política................................... 23 2.7 Publicación de la Política...................................... 23 3. Establecer Procedimientos para Prevenir Problemas de Seguridad... 24 3.1 La Política de Seguridad Define Qué se Necesita Proteger........ 24 3.2 Identificación de Posibles Problemas............................ 24 3.3 Elección de Controles para Proteger Bienes de Manera Rentable... 26 3.4 Usar Múltiples Estrategias para Proteger Bienes................. 26 3.5 Seguridad Física................................................ 27 3.6 Procedimientos para Reconocer Actividad No Autorizada........... 27 3.7 Definir Acciones a Tomar Cuando Se Sospeche de Actividad No Autorizada................................................... 29 3.8 Comunicar la política de seguridad.............................. 30 3.9 Recursos para Prevenir Agujeros de Seguridad.................... 34 4. Tipos de Procedimientos de Seguridad............................. 56 4.1 Revisar los Sistemas de Seguridad............................... 56 4.2 Procedimientos de Gestión de Cuentas............................ 57 4.3 Procedimientos de Gestión de Contraseñas........................ 57 4.4 Procedimientos de Gestión de Configuración...................... 60 5. Tratar Incidentes................................................ 61 5.1 Visión Global................................................... 61 5.2 Evaluación...................................................... 65 5.3 Formas de Aviso Posibles........................................ 67 5.4 Respuesta....................................................... 71 5.5 Legislación/Investigación....................................... 73 5.6 Registros de Documentación...................................... 77 6. Establecer Procedimientos Post-incidente.......................... 78 6.1 Visión Global................................................... 78 6.2 Quitar Vulnerabilidades......................................... 78 6.3 Capturar las Lecciones Aprendidas............................... 80 6.4 Mejorar Políticas y Procedimientos.............................. 81 7. Referencias...................................................... 81 8. Bibliografía Destacada........................................... 83 8.1 Legislación Informática......................................... 84 8.2 Seguridad Informática........................................... 85 8.3 Etica........................................................... 91 8.4 El Gusano de Internet........................................... 93 8.5 Centro Nacional de Seguridad Informática(NCSC).................. 95 8.6 Listas de Comprobación de Seguridad............................. 99 8.7 Publicaciones Adicionales....................................... 99 9. Agradecimientos..................................................101 10. Consideraciones de Seguridad....................................101 11. Direcciones de los Autores......................................101 .ni .ti 0 1. Introducción .ti 0 1.1 Objetivo de este Trabajo .in 3 Este manual es una guía para fijar políticas y procedimientos de seguridad informática para sitios que tienen sistemas en Internet. Esta guía lista asuntos y factores que un sitio debe tener en cuenta cuando fija sus propias políticas. Hace algunas recomendaciones y ofrece argumentos sobre áreas relevantes. Esta guía solo es un marco para fijar políticas y procedimientos de seguridad. Para tener un conjunto de políticas y procedimientos efectivos, un sitio tendrá que tomar algunas decisiones, ponerse de acuerdo, y después comunicar e implementar las políticas. 1.2 Público .in 3 El público de este trabajo son los administradores de sistemas y dirigentes (que son llamados más tradicionalmente "administradores" o "semigestores") de sitios. Este documento no está dirigido a programadores o aquellos que intentan crear programas o sistemas seguros. El centro de este documento es sobre las políticas y procedimientos que necesita tener en su lugar para soportar algunos aspectos de seguridad técnica que un sitio puede estar implementando. El público principal de este trabajo son los sitios miembros de la comunidad de Internet. Sin embargo, este documento debería ser útil a cualquier sitio que tenga comunicación con otros. Como guía general de políticas de seguridad, este documento además puede ser útil a sitios con sistemas aislados. .ti 0 1.3 Definiciones .in 3 Para el objetivo de esta guía, un "sitio" es una organización que posee ordenadores o recursos relacionados con redes. Estos recursos pueden incluir servidores de ordenadores que usan los usuarios, enrutadores, servidores de terminales, PC's u otros dispositivos que tienen acceso a Internet. Un sitio puede ser un usuario final de servicios de Internet o un proveedor de servicios como una red regional. Sin embargo, en lo que más está centrada esta guía son esos usuarios finales de servicios de Internet. Damos por sentado que el sitio tiene la capacidad de fijar políticas y procedimientos por si mismo con el consentimiento y respaldo de aquellos que son los propietarios reales de los recursos. "Internet" es aquel conjunto de redes y máquinas que usan el conjunto de protocolos TCP/IP, conectadas a través de pasarelas, y compartiendo unos espacios de nombre y dirección comunes [1]. El término "administrador del sistema" es usado para cubrir a todo aquel que es responsable del manejo de recursos día a día. Esto puede ser un conjunto de individuos o una organización. El término "dirigente" se refiere a aquellas personas que fijan o aprueban políticas en un sitio. A veces (pero no siempre) es la gente propietaria de los recursos. .ti 0 1.4 Trabajo Relacionado .in 3 El Grupo de Trabajo de Política de Seguridad de la IETF (SPWG) está trabajando en un conjunto de directivas recomendadas sobre políticas de seguridad para Internet [23]. Estas directivas pueden ser adoptadas como política por redes regionales o propietarios de otros recursos. Este manual debería ser una herramienta útil para ayudar a los sitios a implementar estas políticas como quieran o necesiten. Sin embargo, tan solo con implementar las políticas propuestas no es suficiente para asegurar un sitio. La políticas de Internet propuestas tratan solo de acceso seguro a redes. No dice nada sobre como los sitios deben tratar los asuntos de seguridad locales. .ti 0 1.5 Alcance Este documento abarca asuntos sobre qué debería contener una política de seguridad informática, qué tipo de procedimientos se necesitan para reforzar la seguridad, y algunas recomendaciones sobre cómo tratar el problema. Cuando se desarrolla una política de seguridad, se debería centrar la atención no solo en las necesidades y requerimientos de seguridad de la red local, sino también las necesidades y requerimientos de seguridad de las otras redes interconectadas. Esto no es un libro de recetas para seguridad informática. Cada sitio tiene necesidades diferentes; las necesidades de seguridad de una corporación pueden perfectamente ser diferentes de las necesidades de seguridad de una institución académica. Cualquier plan de seguridad tiene que adaptarse a las necesidades y cultura del sitio. Este manual no cubre detalles de cómo valorar riesgos, planes de contingencia, o seguridad física. Estas cosas son esenciales para regular e implementar políticas de seguridad efectivas, pero este documento deja el tratamiento de esos asuntos a otros documentos. Intentaremos proporcionar algunas referencias en esa dirección. Este documento tampoco habla sobre como diseñar e implementar programas o sistemas seguros. .ti 0 1.6 ¿Por qué necesitamos Políticas y Procedimientos de Seguridad? .in 3 Para la mayoría de los sitios, el interés en seguridad informática es proporcional a la percepción de riesgos y amenazas. El mundo de los ordenadores ha cambiado dramaticamente en los últimos veinticinco años. Hace veinticinco años, la mayoría de los ordenadores eran centralizados y estaban administrados por centros de datos. Los ordenadores estaban guardados en salas cerradas bajo llave y los responsables de personal se aseguraban de que estaban cuidadosamente administrados y asegurados fisicamente. Conectar un sitio con el exterior era inusual. Las amenazas a la seguridad informática eran raras, y basicamente eran de internos: usuarios autorizados abusando de cuentas, robo y vandalismo, y esas cosas. Estas amenazas estaban bien entendidas y tratadas usando técnicas estándar: ordenadores detrás de puertas bajo llave y llevar la cuenta de todos los recursos. La computación en los 1990's es radicalmente diferente. Algunos sistemas están en oficinas privadas y laboratorios, a veces administrados por individuos o empleados ajenos a un centro informático. Algunos sistemas están conectados a Internet, y desde ahí a todo el mundo: los Estados Unidos, Europa, Asia, y Australia están conectados todos juntos. Hoy en día las amenazas de seguridad son diferentes. El honrado antiguo consejo dice "no escribas tu contraseña y la pongas en tu escritorio" para que no la encuentre nadie. Con las conexiones de Internet por todo el mundo, alguien podía conseguir introducirse en su sistema desde la otra punta del mundo y robar su contraseña en medio de la noche cuando su edificio está cerrado. Los virus y gusanos pueden ser pasados de máquina a máquina. Internet permite el equivalente electrónico a el robo de quien busca puertas y ventanas abiertas; ahora una persona puede chequear cientos de máquinas buscando vulnerabilidades en pocas horas. Los administradores de sistemas y dirigentes tienen que entender que existen esas amenazas de seguridad, cual sería el riesgo y coste de un problema, y y que tipo de acción quieren tomar (si toman alguna) para prevenir y responder a las amenazas de seguridad. Como ejemplo de algunos de los asuntos que necesitan ser tratados entre los problemas de seguridad, suponga los siguientes escenarios (gracias a Russell Brand [2, BRAND] por estos): .in 8 .ti 6 - Un programador del sistema recibe una llamada diciendo que un importante boletín cracker clandestino está siendo distribuido desde la máquina administrativa de su centro a cinco mil sitios en EEUU y Europa Occidental. Ocho semanas más tarde, las autoridades llaman para informarte de que la información de uno de estos boletines fue usado para desactivar el "911" en una gran ciudad durante cinco horas. .in 8 .ti 6 - A las 3 en punto de un sábado por la mañana un usuario llama diciendo que no puede identificarse en su cuenta. El personal del sistema no puede entrar tampoco. Entonces reinicia a modo de un solo usuario, encuentra que el archivo de contraseñas está vacío. El Lunes por la mañana, su personal determina que un número de transferencias de archivos privilegiadas tuvo lugar entre esta máquina y una universidad local. El Martes por la mañana una copia del archivo de contraseñas borrado es encontrado en la máquina de la universidad junto con los archivos de contraseñas de una docena de máquinas. Una semana después encuentra que sus archivos de inicio del sistema han sido alterados de forma hostil. .in 8 .ti 6 - Recibe una llamada diciendo que una intrusión a un laboratorio gubernamental se hizo desde una de sus máquinas centrales. Se le pide proporcionar archivos de cuentas para ayudar a dar con el atacante. Una semana después le dan una lista de máquinas de su sitio que han sido penetradas. .in 8 .ti 6 - Un periodista llama preguntando sobre la intrusión en su centro. Usted no ha oído nada de tal intrusión. Tres días después, conoce que había una intrusión. El director del centro tenía el nombre de su esposa como contraseña. .in 8 .ti 6 - Se detecta un cambio en los binarios del sistema. El día que es corregido, son cambiados otra vez. Esto se repite durante algunas semanas. .in 8 .ti 6 - Si se encuentra un intruso en su sistema, ¿debería dejar el sistema abierto para seguir la situación o debería cerrar las entradas y abrirlas otra vez más tarde? .in 8 .ti 6 - Si un intruso está usando su sitio, ¿debería llamar a las fuerzas de la ley? ¿quien toma esa decisión? Si las fuerzas de la ley le piden dejar abierto su sitio, ¿quien toma esa decisión? .in 8 .ti 6 - ¿Qué pasos se deberían tomar si otro sitio le llama y le dice que han visto actividad llegando desde una cuenta de su sistema? ¿Qué pasa si la cuenta es de un administrador local? .ti 0 1.7 Metodología Básica .in 3 Fijar políticas y procedimientos de seguridad en realidad significa desarrollar un plan de como tratar la seguridad informática. Fites, et. al. sugieren una manera de abordar esta tarea [3, FITES]: .in 6 - Mire qué está intentando proteger. - Mire de qué necesita protegerlo. - Determine como son probablemente las amenazas. - Implemente las medidas que protegerán sus bienes de manera efectiva a buen coste. - Revise el proceso continuamente, y mejore cosas cada vez que encuentre un fallo. .in 3 Este manual se concentrará mayormente en los dos pasos últimos, pero los tres primeros son críticamente importantes para tomar decisiones de seguridad efectivas. Una vieja perogrullada en seguridad es que el coste de protegerse contra una amenaza debería ser menor que el coste de reponerse si la amenaza le atacara. Sin unos conocimientos razonables de qué está protegiendo y cuales son probablemente las amenazas, seguir esta regla podría ser difícil. .ti 0 1.8 Organización de este Documento .in 3 Este documento está organizado en siete partes además de esta introducción. La estructura básica de cada sección es discutir asuntos que un sitio podría querer considerar al crear una política de seguridad informática y fijar procedimientos para implementar esa política. En algunos casos, las opciones posibles son discutidas junto con algunas de las ramificaciones de estas elecciones. Hasta donde sea posible, este documento intenta no dictar las elecciones que un sitio haría, ya que dependen de las circunstancias locales. Algunos de estos asuntos estudiados pueden no aplicarse a todos los sitios. No obstante, todos los sitios deberían al menos considerar los asuntos estudiados aquí para asegurarse de que no se dejan algún área importante. La idea del documento en conjunto es discutir asuntos sobre políticas seguidos por los asuntos que surgen al crear procedimientos para implementar las políticas. La sección 2 discute fijar políticas de sitio oficiales para acceder a los recursos informáticos. También lleva el asunto de qué sucede cuando se viola la política. Las políticas llevarán a los procedimientos que se necesiten crear, así que los dirigentes necesitarán hacer algunas elecciones sobre políticas antes de que se puedan tratar algunos de los asuntos de los procedimientos. Una parte clave de crear políticas es hacer algún tipo de valoración de riesgos para decidir qué necesita ser protegido en realidad y el nivel de recursos que se debería aplicar para protegerlos. Una vez las políticas se han fijado, se deberían establecer los procedimientos para prevenir los futuros problemas de seguridad. La sección 3 define y sugiere acciones a llevar a cabo cuando se sospeche de actividad no autorizada. También se discuten los recursos para prevenir los agujeros de seguridad. La sección 4 discute tipos de procedimientos para prevenir problemas de seguridad. La prevención es clave para la seguridad; como ejemplo, el Equipo de Respuesta de Emergencia Informática/Centro de Coordinación (CERT/CC) en la Universidad Carnegie-Mellon (CMU) estima que en el 80% o más de los problemas ve que tienen que ver con contraseñas elegidas de forma pobre. La sección 5 discute el trato de incidentes: a qué tipo de asuntos hará cara un sitio cuando alguien viole la política de seguridad. Algunas decisiones tendrán que tomarse en el momento en que ocurra el incidente, pero algunas de las opciones y asuntos pueden ser discutidos de antemano. Al menos, las responsabilidades y métodos de comunicación se pueden establecer antes de un incidente. De nuevo, aquí las elecciones están influenciadas por las políticas discutidas en la sección 2. La sección 6 trata sobre qué sucede después de que se haya tratado una violación de seguridad. Un plan de seguridad es un ciclo continuo; justo después de que haya ocurrido un incidente es una excelente oportunidad para perfeccionar las políticas y procedimientos. El resto del documento proporciona referencias y una bibliografía destacada. .ti 0 2. Establecer Políticas de Sitio Oficiales sobre Seguridad Informática .ti 0 2.1 Breve Introducción .ti 3 2.1.1 Asuntos de Organización .in 6 El objetivo de desarrollar una política oficial de sitios sobre seguridad informática es definir las expectativas de la organización sobre un uso correcto de ordenadores y redes y definir procedimientos para prevenir y responder ante incidentes de seguridad. Con el propósito de hacer esto, se deben considerar aspectos de la organización en particular. Primero, se deberían considerar los objetivos y administración de a organización. Por ejemplo, una base militar puede tener preocupaciones de seguridad muy diferentes a las de una universidad. Segundo, la política de seguridad del sitio desarrollada debe amoldarse a las políticas, reglas, regulaciones y leyes existentes a las que la organización está sujeta. Por consiguiente será necesario identificarlas y tenerlas en consideración mientras se desarrolle la política. Tercero, a menos que la red local esté completamente aislada y funcione de forma independiente, es necesario considerar implicaciones de seguridad en un contexto más global. La política debería dirigir los asuntos cuando los problemas de seguridad local tengan lugar desde un sitio remoto, así como cuando los problemas ocurren en sistemas remotos desde de un servidor o usuario local. .ti 3 2.1.2 ¿Quien Hace la Política? .in 6 La creación de una política debe ser un esfuerzo conjunto de personal técnico, que entiende todas las ramificaciones de la política propuesta y la implementación de la política, y por dirigentes que tienen el poder de hacer cumplir la política. Una política que no es ni implementable ni se puede hacer cumplir es inútil. Ya que una política de seguridad informática puede afectar a todo en una organización, sería aconsejable tener algún cuidado de asegurarse de que se tiene el nivel de autoridad correcto en las decisiones de la política. Aunque un grupo particular (como un grupo de servicios de información de un campus) puede tener la responsabilidad de hacer cumplir una política, un grupo mayor puede tener que dar soporte y aprobar la política. .ti 3 2.1.3 ¿A Quien le Concierne? .in 6 Establecer una política de sitio tiene el potencial para involucrar a cada usuario informático del sitio de varias maneras. Los usuarios informáticos pueden ser responsables de la administración de contraseñas personales. Los administradores de sistemas están obligados a cerrar los agujeros de seguridad y vigilar el sistema. Es crítico tener al conjunto de gente correcto involucrado al principio del proceso. Puede haber grupos ya preparados interesados en seguridad a los que se podría considerar la política de seguridad informática como su área. Algunas de las clases de grupos que podían estar interesadas incluyen auditoría/control, organizaciones que trabajan con seguridad física, grupos de sistemas de información de un campus, y así sucesivamente. Pedir a este tipo de grupos que "acepten" la política desde el principio puede ayudar a facilitar la aceptación de la política. .in 3 2.1.4 Responsabilidades .in 6 Un elemento clave de una política de seguridad informática es asegurarse de que todos conocen sus propias responsabilidades para mantener la seguridad. Una política de seguridad informática no puede anticipar todas las posibilidades; sin embargo, puede asegurarse de que cada tipo de problemas tiene alguien asignado para arreglarlo. Puede haber niveles de responsabilidad asociados a una política sobre seguridad informática. En un nivel, cada usuario de un recurso informático puede tener la responsabilidad de proteger su cuenta. Un usuario que permite que su cuenta sea comprometida incrementa las posibilidades de comprometer otras cuentas o recursos. Los administradores de sistemas pueden establecer otros niveles de responsabilidad: deben ayudar a asegurar la seguridad del sistema informático. Los administradores de redes pueden residir así en otro nivel. .ti 0 2.2 Valoración de Riesgos .ti 3 2.2.1 Discusión General .in 6 Una de las razones más importantes para crear una política de seguridad informática es asegurarse de que los esfuerzos hechos en materia de seguridad den beneficios adecuados al coste. Aunque esto puede parecer obvio, es posible estar confundido sobre donde se necesita el esfuerzo. Como ejemplo, hay una gran publicidad sobre intrusos en sistemas informáticos; la mayoría de los estudios sobre seguridad informática muestran que, todavía, para la mayoría de las organizaciones, las perdidas actuales causadas por "miembros internos" es mucho mayor. Los análisis de riesgos incluyen determinar lo que necesita proteger, de qué lo necesita proteger, y como protegerlo. Es el proceso de examinar todos sus riesgos, y ordenar estos riesgos por niveles de severidad. Este proceso conlleva tomar decisiones rentables sobre qué quiere proteger. El antiguo proverbio de seguridad dice que no debería gastar más en proteger algo de lo que vale realmente. Un tratamiento completo del análisis de riesgos está fuera del alcance de este documento. [3, FITES] y [16, PFLEEGER] proporcionan introducciones sobre este tema. De todos modos, hay dos elementos de un análisis de riesgos que se cubrirán brevemente en las dos próximas secciones: .in 9 1. Identificar los bienes 2. Identificar las amenazas .in 6 Para cada bien, los objetivos de seguridad básicos son disponibilidad, confidencialidad, e integridad. Cada amenaza se debería examinar con la idea de cómo la amenaza podría afectar estas áreas. .ti 3 2.2.2 Identificar los Bienes .in 6 Un paso en un análisis de riesgos es identificar todas las cosas que necesitan ser protegidas. Algunas cosas son obvias, como toda la variedad de piezas de hardware, pero algunas son pasadas por alto, tales como la gente que usa en realidad los sistemas. Lo esencial es hacer una lista con todas las cosas que podrían ser afectadas por un problema de seguridad. Pfleeger [16, PFLEEGER, página 459] sugiere una lista de categorías; esta lista está adaptada de esa fuente: .in 12 .ti 9 1. Hardware: cpus, tablas, teclados, terminales, estaciones de trabajo, ordenadores personales, impresoras, dispositivos de disco, lineas de comunicaciones, servidores de terminales, enrutadores. .in 12 .ti 9 2. Software: fuentes de los programas, programas objeto, utilidades, programas de diagnóstico, sistemas operativos, programas de comunicaciones. .in 12 .ti 9 3. Datos: durante ejecución, guardados en linea, archivados fuera de linea, copias de seguridad, registros de auditoría, bases de datos, en tránsito a través de medios de comunicación. .in 12 .ti 9 4. Gente: usuarios, gente que necesita ejecutar sistemas. .in 12 .ti 9 5. Documentación: sobre programas, hardware, sistemas, procedimientos administrativos locales. .in 12 .ti 9 6. Consumibles: papel, formularios, cintas, medios magnéticos. .ti 3 2.2.3 Identificando las Amenazas .in 6 Una vez han sido identificados los bienes que requieren protección, es necesario identificar amenazas a esos bienes. Entonces la amenazas pueden ser examinadas para determinar qué potencial para pérdidas existe. Esto ayuda a considerar de qué amenazas está intentando proteger sus bienes. Las secciones siguientes describen unas pocas de las posibles amenazas. .ti 6 2.2.3.1 Acceso No Autorizado .in 9 Una amenaza común que concierne a algunos sitios es el acceso no autorizado a instalaciones informáticas. El acceso no autorizado toma varias formas. Un significado de acceso no autorizado es el uso de la cuenta de otro usuario para conseguir acceso al sistema. El uso de algún recurso informático sin permiso previo puede ser considerado acceso no autorizado a instalaciones informáticas. La gravedad de un acceso no autorizado variará en cada sitio. Para algunos sitios, el mero acto de conceder acceso a un usuario no autorizado puede causar daños irreparables por publicidad negativa. Para otros sitios, un acceso no autorizado abre la puerta a otras amenazas de seguridad. Además, algunos sitios pueden ser objetivos más frecuentes que otros; por lo tanto el riesgo de un acceso no autorizado variará en cada sitio. El Equipo de Respuesta de Emergencia Informática (CERT - ver sección 3.9.7.3.1) ha observado que los sitios de universidades, gubernamentales y militares bien conocidos parecen atraer a más intrusos. .ti 6 2.2.3.2 Divulgación de Información .in 9 Otra amenaza común es la divulgación de información. Determine el valor o sensibilidad de la información almacenada en su ordenador. La divulgación de un archivo de contraseñas podría permitir futuros accesos no autorizados. Una ojeada a una propuesta puede dar un competidor una ventaja inmerecida. Un documento técnico puede contener años de valiosa investigación. .ti 6 2.2.3.3 Denegación de Servicio .in 9 Redes y ordenadores proporcionan servicios valiosos a sus usuarios. Alguna gente depende de estos servicios para desarrollar su trabajo de forma eficiente. Cuando al ser solicitados estos servicios no están disponibles, se produce una pérdida de efectividad. La denegación de servicio llega de varias maneras y podría afectar a los usuarios de varias formas. Una red puede volverse inservible por un paquete pícaro, sobrecarga, o por un componente de la red desactivado. Un virus podría reducir el funcionamiento o dañar un sistema informático. Cada sitio debería determinar que servicios son esenciales, y para cada uno de estos servicios determinar el daño al sitio si ese servicio llegara a estar desactivado. .ti 0 2.3 Asuntos Políticos .in 3 Hay un número de asuntos que se deberían discutir cuando se desarrolla una política de seguridad. Estos son: .in 10 .ti 6 1. ¿Quién está autorizado a usar los recursos? .ti 6 2. ¿Cual es el uso apropiado de los recursos? .ti 6 3. ¿Quién está autorizado a conceder acceso y aprobar el uso? .ti 6 4. ¿Quién puede tener privilegios de administración del sistema? .ti 6 5. ¿Cuales son los derechos y responsabilidades del usuario? .ti 6 6. ¿Cuales son los derechos y responsabilidades del administrador del sistema en contraposición a los del usuario? .ti 6 7. ¿Como trata usted la información sensible? .in 3 Estos asuntos serán discutidos más abajo. Además puede desear incluir una sección en su política concerniente al uso ético de los recursos informáticos. Parker, Swope y Baker [17, PARKER90] y Forester y Morrison [18, FORESTER] son dos referencias útiles que tratan asuntos éticos. .ti 3 2.3.1 ¿Quién está Autorizado a Usar los Recursos? .in 6 Un paso que debe dar al desarrollar su política de seguridad es definir quien está autorizado a usar su sistema y sus servicios. La política debería declarar explicitamente quien está autorizado a usar qué recursos. .ti 3 2.3.2 ¿Cual es el Uso Apropiado de los Recursos? .in 6 Después de determinar quien está autorizado a acceder a los recursos del sistema es necesario proporcionar directivas para el uso aceptable de los recursos. Puede tener directivas diferentes para diferentes tipos de usuarios (p.e., estudiantes, facultades, usuarios externos). La política debería dejar claro qué uso es aceptable así como qué uso es inaceptable. También debería incluir los tipos de uso pueden estar restringidos. Definir límites de acceso y autoridad. Necesitará considerar el nivel de acceso que tendrán varios usuarios y qué recursos estarán disponibles o restringidos a distintos grupos de personas. Su política de uso aceptable debería declarar claramente que los usuarios individuales son responsables de sus actos. Su responsabilidad existe a pesar de los mecanismos de seguridad que están en el sitio. Se debería dejar claro que introducirse en cuentas o puentear la seguridad no está permitido. Los puntos siguientes deberían ser cubiertos cuando se desarrolla una política de uso aceptable: .in 11 .ti 9 o ¿Está permitido introducirse en cuentas? .ti 9 o ¿Está permitido romper contraseñas? .ti 9 o ¿Está permitido desestabilizar el servicio? .ti 9 o ¿Los usuarios asumen que un archivo estando legible a todo el mundo les proporciona la autorización de leerlo? .ti 9 o ¿Se les debería permitir a los usuarios modificar archivos que no son suyos aunque dé la casualidad de que tengan permisos de escritura? .ti 9 o ¿Los usuarios deberían compartir cuentas? .in 6 La respuesta a la mayoría de estas preguntas será "no". Puede querer incorporar un apartado en sus políticas concerniente a los derechos de copia y las licencias de software. La aceptación de licencias de los vendedores puede requerir algún tipo de trabajo por su parte para asegurarse de que la licencia no es violada. Además, puede desear informar a los usuarios que la copia de software registrado puede ser una violación de las leyes de derechos de copia y no está permitido. Especificamente concerniente al software registrado y/o bajo licencia, puede querer incluir la siguiente información: .in 11 .ti 9 o El software registrado y bajo licencia no puede ser duplicado a menos que sea declarado explicitamente que puede hacerlo. .ti 9 o Métodos de comunicar información sobre la condición del software registrado/bajo licencia. .ti 9 o Si duda, NO COPIE. .in 6 Su política de uso aceptable es muy importante. Una política que no define claramente lo que no está permitido puede dejarle incapaz de probar que un usuario ha violado la política. Hay casos excepcionales como tiger teams y usuarios o administradores deseando "licencias para hackear" -- puede encontrarse la situación donde habrá usuarios que querrán "hackear" sus servicios para propósitos de investigación de seguridad. Debería desarrollar una política que determinará si permite este tipo de investigación en sus servicios y, si es así, cuales serán sus directivas para tal investigación. [N. del T. Tiger Teams = Equipos especializados que comprueban la seguridad de los sistemas] Puntos que puede querer cubrir en este área: .in 11 .ti 9 o Si está permitido todo. .ti 9 o Qué tipo de actividad está permitida: intrusión, soltar gusanos, soltar virus, etc.. .ti 9 o Qué tipo de controles debe haber en el sitio para asegurarse de que no se pierde el control (p.e., separar una parte de su red para estas pruebas). .ti 9 o Cómo protegerá a otros usuarios que son víctimas de estas actividades, incluyendo usuarios y redes externas. .ti 9 o El proceso para obtener permiso para llevar a cabo estas pruebas. .in 6 En los casos donde permita estas actividades, debería aislar de su red principal las partes de la red que están siendo probadas. Los gusanos y los virus nunca deberían liberarse en una red en uso. También puede querer emplear, contratar, o solicitar de otra manera a una o más personas u organizaciones la evaluación de la seguridad de sus servicios, de los cuales puede incluir "hacking". Puede querer poner esto en su política. .in 3 2.3.3 ¿Quién está Autorizado a Conceder Acceso y Aprobar el Uso? .in 6 Su política debería hacer constar quién está autorizado a conceder acceso a sus servicios. Además, se puede determinar qué tipo de acceso se les permite dar. Si no tiene control sobre quién está autorizado a acceder a su sistema, no tendrá control sobre quién lo está usando. Controlar quién tiene la autorización de conceder acceso también le permitirá saber quien tenía o no tenía concedido el acceso si aparecen problemas más tarde. Se pueden desarrollar algunos esquemas para controlar la distribución de acceso a sus servicios. Lo siguiente son los factores que debe tener en cuenta cuando determine quién distribuirá acceso a sus servicios: .in 11 .ti 9 o ¿La distribución del acceso será desde un punto centralizado o varios puntos? .in 6 Puede tener un punto de distribución centralizado de un sistema distribuido donde autorizar acceso a varios sitios o departamentos independientemente. La diferencia está entre seguridad y comodidad. El más centralizado, el más fácil de asegurar. .in 11 .ti 9 o ¿Qué métodos usará para crear cuentas y, por tanto, acceso? .in 6 Desde un punto de vista de seguridad, necesita examinar el mecanismo que usará para crear cuentas. En el caso menos restrictivo, la gente que está autorizada a conceder acceso podría entrar en el sistema directamente y crear una cuenta a mano o a través de mecanismos suministrados por vendedores. Generalmente, estos mecanismos conceden una gran confianza a las personas que los ejecuta, y las personas que lo ejecutan a menudo tienen un montón de privilegios. Si esta es su elección, necesita elegir a alguien de confianza para realizar esta tarea. La solución opuesta es tener un sistema integrado y que sea ejecutado por la gente autorizada a crear cuentas, o por los mismos usuarios. Dese cuenta de que incluso en caso restrictivo de tener una facilidad mecanizada de crear cuentas no elimina la amenaza potencial por abuso. Debería tener procedimientos específicos desarrollados para la creación de cuentas. Estos procedimientos deberían estar bien documentados para prevenir las confusiones y reducir errores. Una vulnerabilidad de seguridad en el proceso de autorización de cuentas no solo es posible a través del abuso, sino también si se produce un error. Tener claros y bien documentados los procedimientos ayudará a asegurarse de que estos errores no ocurran. También debería estar seguro de que la gente que seguirá estos procedimientos los entiende. La concesión de acceso a los usuarios es vulnerable la mayoría de las veces. Debería asegurarse de la elección de una contraseña inicial que no se pueda adivinar facilmente. Debería evitar el uso de una contraseña inicial que sea el nombre de usuario, una parte del nombre de usuario, o alguna contraseña generada algoritmicamente que pueda ser descubierta facilmente. Además, no debería permitir a los usuarios continuar usando la contraseña inicial indefinidamente. Si fuese posible, debería forzar a los usuarios a cambiar la contraseña inicial la primera vez que entrasen al sistema. Considere que puede que incluso nunca entren algunos usuarios, dejando su contraseña vulnerable indefinidamente. Algunos sitios eligen desactivar las cuentas que no se han usado nunca, y forzar al propietario a reautorizar abrir la cuenta. .in 3 2.3.4 ¿Quién Puede Tener Privilegios de Administración del Sistema? .in 6 Una decisión de seguridad que se necesita hacer muy cuidadosamente es quien tendrá acceso a privilegios de administración del sistema y contraseñas para sus servicios. Obviamente, los administradores del sistema necesitarán acceso, pero inevitablemente otros usuarios pedirán privilegios especiales. La política debería dirigir este asunto. Restringir los privilegios es una manera de tratar las amenazas de los usuarios locales. El reto es mantener el equilibrio restringiendo el acceso a estos para proteger la seguridad dando a la gente que necesita estos privilegios de acceso de manera que puedan desarrollar sus tareas. Una estrategia que se puede tomar es conceder solo los privilegios suficientes para cumplir las tareas necesarias. De forma adicional, la gente que posee privilegios especiales debería ser monitorizable por alguna autoridad y esta también debería estar identificada en la política de seguridad del sitio. Si la gente a la que se le concede privilegios no es monitorizable, usted corre el riesgo de perder el control de su sistema y tendrá dificultad para manejar un compromiso de la seguridad. .ti 3 2.3.5 ¿Cuales Son Los Derechos y Responsabilidades de Los Usuarios? .in 6 La política debería incorporar una declaración de los derechos y responsabilidades de los usuarios respecto al uso de los servicios y sistemas informáticos del sitio. Se debería dejar claro que los usuarios son responsables de entender y respetar las reglas de seguridad de los sistemas que están usando. Lo que viene a continuación es una lista de temas que puede desear cubrir en esta parte de la política: .in 11 .ti 9 o Qué directivas tiene con respecto a al consumo de recursos (si los usuarios están restringidos, y si es así, cuales son las restricciones) .ti 9 o Qué puede constituir abuso en términos de actuación del sistema. .ti 9 o Si a los usuarios les está permitido compartir sus cuentas o dejar a otros usar sus cuentas. .ti 9 o Con qué "secreto" los usuarios deberían cuidar sus contraseñas. .ti 9 o Con qué frecuencia los usuarios deberían cambiar sus contraseñas y cualquier otra restricción o requerimiento de la contraseña. .ti 9 o Si proporciona copias de seguridad o espera que los usuarios creen la suya propia. .ti 9 o Divulgación de información que puede ser privada. .ti 9 o Declaración sobre la Intimidad en el Correo Electrónico (Acta de Intimidad en las Comunicaciones Electrónicas) .ti 9 o Su política sobre correo controvertido o enviado a listas de correo o grupos de discusión (obscenidad, hostigamiento,etc.). .ti 9 o Política sobre comunicaciones electrónicas: falsificación de correo, etc. .in 6 La Asociación de Correo Electrónico costeó un documento corto sobre la intimidad del correo electrónico en empresas [4]. Su recomendación básica es que cada sitio debería tener una política sobre la protección de la intimidad del empleado. También recomendaban que las organizaciones establecieran políticas de intimidad que se encargasen de todos los medios de comunicación, mejor que simplemente del correo electrónico. Sugerían cinco criterios para evaluar cualquier política: .in 12 .ti 9 1. ¿Cumple con la ley y con obligaciones a terceras partes? .ti 9 2. ¿Compromete innecesariamente los intereses del empleado, empresario o terceras partes? .ti 9 3. ¿Se puede utilizar en la práctica y se puede hacer que se cumpla? .ti 9 4. ¿Trata apropiadamente todas las formas diferentes de comunicaciones y registro cuidando de la oficina? .ti 9 5. ¿Ha sido promulgada por anticipado y aceptada por todos los concernidos? .in 9 .ti 3 2.3.6 Cuales Son Los Derechos y Responsabilidades de Los Administradores de Sistemas En Contraposición a Los Derechos de Los Usuarios .in 6 Hay un equilibrio entre los derechos de los usuarios a la intimidad absoluta y la necesidad de los administradores de sistemas a recoger suficiente información para diagnosticar problemas. También hay una distinción entre que un administrador del sistema necesite recolectar información para diagnosticar problemas y la investigación de violaciones de seguridad. La política debería especificar en qué grado las administradores de sistemas pueden examinar los archivos de usuario para diagnosticar problemas o para otros propósitos, y qué derechos concede a los usuarios. También puede desear hacer una declaración respecto a la obligación de los administradores del sistema a mantener la intimidad de la información visualizada bajo estas circunstancias. Algunas preguntas que deberían ser contestadas son: .in 11 .ti 9 o ¿Un administrador puede monitorizar o leer un archivo de usuario por alguna razón? .ti 9 o ¿Cuales son las obligaciones? .ti 9 o ¿Los administradores de red tienen el derecho de examinar el tráfico de la red o servidor? .in 3 2.3.7 Qué Hacer con la Información Sensible .in 6 Antes de conceder a los usuarios acceso a sus servicios, necesita determinar que nivel proporcionará para la seguridad de datos en sus sistemas. Al determinarlo, está determinando el nivel de sensibilidad de los datos que que los usuarios deberían guardar en sus sistemas. No quiera que los usuarios guarden información muy sensible en un sistema que no esté siendo muy bien asegurado. Necesita contar a los usuarios quien puede guardar información sensible y qué servicios, dado el caso, son apropiados para el almacenamiento de información sensible. Este apartado debería incluir almacenamiento de datos de diferentes formas (disco, cinta magnética, servidores de archivos,etc.). Su política en este área necesita ser coordinada con la política concerniente a los derechos de los administradores de sistemas contra los de los usuarios (ver sección 2.3.6). .ti 0 2.4 Qué Sucede Cuando la Política de Seguridad es Violada .in 3 Es obvio que cuando se define algún tipo de política oficial, sea relativa a seguridad informática o no, será rota eventualmente. La violación puede tener lugar debido a una negligencia individual, error accidental, no haber sido informado apropiadamente de la política actual, o no entender la política actual. Es igualmente posible que un individuo (o grupo de individuos) puede actuar conscientemente en un acto que es una violación directa de la política definida. Cuando se ha detectado una violación de la política, el curso inmediato de acción debería estar predefinido para asegurar una ejecución apropiada y preparada. Una Investigación debería ser puesta en marcha para determinar como y porqué ocurrió la violación. Entonces debería ser ejecutada la acción correctiva apropiada. El tipo y severidad de la acción tomada varía dependiendo del tipo de violación que ocurrió. .ti 3 2.4.1 Determinar la Respuesta a Violaciones de la Política .in 6 Las violaciones a la política pueden ser cometidas por una gran variedad de usuarios. Algunos pueden ser usuarios locales y algunos pueden ser externos al entorno local. Los sitios pueden encontrar útil definir cual se considera el límite entre "internos" y "externos" relativo a administración,legalidad o política. Estas diferenciaciones implican qué tipo de acción se debe tomar para reprender a la parte ofensiva; desde un escrito con una reprimenda a presentar cargos legales. De esta manera, no solo necesita definir acciones basadas en el tipo de violación, también necesita tener claramente definidas series de acciones basadas en el tipo de usuario que viola su política de seguridad. Todo esto parece bastante complicado, pero debería estar definido antes de que llegue a ser necesario como resultado de una violación. Un punto a recordar sobre su política es que una educación apropiada es su mejor defensa. Con respecto a los usuarios externos que estén usando su sistema legalmente, es su responsabilidad verificar que estos individuos son conscientes de las políticas que usted ha publicado. En lo referente a los usuarios que están usando su sistema ilegalmente, el problema es basicamente el mismo. ¿Qué tipo de usuario violó la política y cómo y porqué lo hicieron? Dependiendo de los resultados de su investigación, usted puede preferir simplemente "tapar" el agujero en su seguridad informática y tomar nota de la experiencia, o si hubo una gran cantidad de pérdidas, puede desear tomar acciones más drásticas. .in 10 .ti 3 2.4.2 Qué Hacer Cuando Usuarios Locales Violan la Política de un Sitio Remoto .in 6 En el caso de que usuarios locales violen la política de seguridad de un sitio remoto, el sitio local debería tener definido claramente un conjunto de acciones administrativas que tomar con respecto a ese usuario local. El sitio también debería estar preparado para protegerse a si mismo contra posibles acciones de sitios remotos. Estas situaciones conllevan asuntos legales que deberían estar estipulados cuando se redacte la política de seguridad. .in 10 .ti 3 2.4.3 Definir Contactos y Responsabilidades con Organizaciones Externas .in 6 La política local de seguridad debería incluir procedimientos para la interacción con organizaciones externas. Estas incluyen agencias de seguridad, otros sitios, organizaciones de equipos de respuesta externos (p.ej., el CERT, CIAR) y varias agencias de prensa. El procedimiento debería definir quien está autorizado a tomar tal contacto y como debería ser tratado. Algunas preguntas a ser contestadas incluyen: .in 9 o ¿Quién puede hablar con la prensa? o ¿Cuando contacta con cuerpos de seguridad y agencias de investigación? .in 11 .ti 9 o Si una conexión se hace desde un sitio remoto, ¿está el gestor del sistema autorizado a contactar con ese sitio? .in 9 o ¿Los datos pueden ser liberados? ¿Cuales? .in 6 Información detallada del contacto debería estar legible y disponible con los procedimientos a seguir claramente definidos. .in 10 .ti 3 2.4.4 ¿Cuales son las Responsabilidades de nuestros Vecinos y Otros Sitios de Internet? .in 6 El Grupo de Trabajo de Política de Seguridad en la IETF está trabajando en un documento titulado "Directivas de Seguridad para el Funcionamiento Seguro de Internet" [23]. Trata el asunto de que Internet es una aventura cooperativa y qué se espera que los sitios proporcionen asistencia de seguridad mutua. Esto debería estar tratado cuando se desarrolle una política del sitio. El mayor asunto a determinar es cuanta información debería ser liberada. Esto variará en cada sitio, dependiendo del tipo de sitio (p.ej. militar, educativo, comercial) así como el tipo de violación de seguridad que suceda. .in 3 2.4.5 Asuntos sobre los Procedimientos para Tratar Incidentes .in 6 Junto con las declaraciones de la política, el documento una vez preparado debería incluir procedimientos para tratar incidentes. Esto se cubre con detalles en el capitulo siguiente. Esos procedimientos deberían poder cubrir cualquier tipo de violación de la política. .ti 0 2.5 Bloquear Dentro o Fuera .in 6 Siempre que un sitio sufre un incidente que puede comprometer la seguridad informática, la estrategias para reaccionar pueden estar influenciadas por dos presiones opuestas. Si la administración teme que el sitio es suficientemente vulnerable, puede elegir una estrategia "Proteger y Proceder". Esta vía tendrá como primer objetivo la protección y preservación de las instalaciones del sitio y proporcionar normalidad a sus usuarios tan pronto como sea posible. Los ensayos estarán hechos para interferir activamente en los procesos del intruso, prevenir más accesos y empezar inmediatamente con valoración de daños y recuperación. Este proceso puede acarrear apagar las instalaciones, cerrar el acceso a la red, u otras medidas drásticas. El inconveniente es que a menos que los intrusos sean identificados directamente, podrían volver por otro camino, o pueden atacar otro sitio. La propuesta alternativa, "Perseguir y Procesar", adopta la filosofía y objetivos contrarios. El objetivo principal es alojar a los intrusos para que continúen sus actividades en el sitio hasta que el sitio pueda identificar a la personas responsables. Esta propuesta está avalada por agencias y fiscales de cuerpos de seguridad. El inconveniente es que las agencias no pueden eximir un sitio de posibles litigios con usuarios si el daño se hace a sus datos o sistemas. Procesarlo no es la única salida posible si el intruso es identificado. Si el delincuente es un empleado o estudiante, la organización puede elegir tomar acciones disciplinarias. La política de seguridad informática necesita aclarar las opciones y como serán elegidas si se coge a un intruso. Los administradores del sitio deben tener cuidadosa consideración en sus estrategias con respecto a este asunto antes de que ocurran los problemas. La estrategia que se adopte puede depender de cada circunstancia. O puede haber una política global que acuerde una propuesta en todas las circunstancias. Los pros y los contras deben ser examinados a fondo y los usuarios de las instalaciones deben estar al tanto de la política de forma que ellos entiendan sus vulnerabilidades en caso de que no sigan lo propuesto. Lo que viene a continuación son listas de comprobación para ayudar a un sitio a determinar qué estrategia adoptar: "Proteger y Proceder" o "Perseguir y Procesar". .ti 3 Proteger y Proceder .in 9 .ti 6 1. Si los bienes no están bien protegidos. .ti 6 2. Si la continuación de la intrusión podría resultar un gran riesgo financiero. .ti 6 3. Si la posibilidad o voluntad de procesar no está presente. .ti 6 4. Si el usuario intruso es desconocido. .ti 6 5. Si los usuarios son ingenuos y su trabajo es vulnerable. .ti 6 6. Si el sitio es vulnerable a litigios por parte de los usuarios, p.ej., si sus recursos son socavados. .in 3 Perseguir y Procesar .in 9 .ti 6 1. Si los bienes y sistemas están bien protegidos. .ti 6 2. Si están dispuestas buenas copias de seguridad. .ti 6 3. Si el riesgo a los bienes está por encima de la ruptura causada por las presentes y posiblemente futuras intrusiones. .ti 6 4. Si este es un ataque concentrado que ocurre con gran frecuencia e intensidad. .ti 6 5. Si el sitio tiene una atracción natural a los intrusos y, consecuentemente, atrae intrusos regularmente. .ti 6 6. Si el sitio tiene presente incurrir riesgos financieros (u otros) de bienes por seguir alojando al intruso. .ti 6 7. Si el acceso del intruso puede ser controlado. .ti 6 8. Si las herramientas de monitorizar están lo suficientemente bien desarrolladas para hacer una dura persecución. .ti 6 9. Si el personal de soporte es lo suficientemente inteligente y tiene los suficientes conocimientos sobre el sistema operativo, utilidades relativas, y sistemas para realizar la ardua caza. .ti 6 10. Si hay voluntad de procesar por parte de la administración. .ti 6 11. Si los administradores del sistema saben qué tipo de pruebas, en general, inducirían a procesarlo. .ti 6 12. Si hay contacto establecido con cuerpos de seguridad especializados. .ti 6 13. Si hay un representante del sitio versado en los asuntos legales relevantes. .ti 6 14. Si el sitio está preparado para posibles acciones legales de sus propios usuarios si sus datos o sistemas llegan a estar comprometidos durante la persecución. .ti 0 2.6 Interpretar la Política .in 3 Es importante definir quién interpretará la política. Podría ser un individuo o un comité. No importa lo bien que esté escrita, la política requerirá una interpretación cada vez y este texto serviría para repasar, interpretar y revisar la política cuando sea necesario. .ti 0 2.7 Publicar la Política .in 3 Una vez la política de seguridad del sitio ha sido escrita y establecida, se debería poner en marcha un gran proceso para asegurarse de que la declaración de la política sea amplia y concienzudamente diseminada y discutida. Un correo de la política no debería ser considerado suficiente. Se debería dejar un período para comentarios antes de que la política llegase a ser efectiva para asegurarse de que todos los usuarios afectados tienen una oportunidad de exponer sus reacciones y discutir algunas ramificaciones imprevistas. Lo ideal sería que la política hallase un equilibrio entre protección y productividad. Las reuniones deberían estar sujetas a aceptar estos comentarios, y a asegurarse de que la política es entendida correctamente. (Los promulgadores de la política no son conocidos precisamente por su destreza en el lenguaje.) En estas reuniones se deberían involucrar tanto altos ejecutivos como la linea de empleados. La seguridad es un esfuerzo colectivo. Además de los esfuerzos iniciales para publicar la política, es esencial para el sitio mantener una conocimiento continuo de su política de seguridad informática. Los usuarios actuales pueden necesitar recordatorios periódicos, los nuevos usuarios deberían tener la política incluida como parte de su paquete de introducción al sitio. Como condición para usar las instalaciones del sitio, puede ser aconsejable tener una declaración firmada de que ellos han leído y entendido la política. Si algunos de estos usuarios requiere acciones legales por violaciones serias de la política, esta declaración firmada puede demostrar ser una valiosa ayuda. .ti 0 3. Establecer Procedimientos para Prevenir Problemas de Seguridad .in 3 La política de seguridad define qué necesita ser protegido. Esta sección discute procedimientos de seguridad que especifican qué pasos se seguirán para seguir la política de seguridad. .ti 0 3.1 La Política se Seguridad Define Qué Necesita ser Protegido .in 3 La política de seguridad define los Qués y Cuales: qué necesita ser protegido, qué es lo más importante, cuales son las prioridades, y cual debería ser el procedimiento general para tratar los problemas de seguridad. La política de seguridad por si misma no dice CÓMO se protegen las cosas. Ese es el papel de los procedimientos de seguridad, que está sección discute. La política de seguridad debería ser un documento de alto nivel, dando una estrategia general. Los procedimientos de seguridad necesitan determinar, detalladamente, los pasos precisos que su sitio tomará para protegerse. La política de seguridad debería incluir una evaluación general de riesgos de los tipos de amenazas que un sitio tendría que afrontar más probablemente y las consecuencias de esas amenazas (ver sección 2.2). Parte de hacer una valoración de riesgos incluirá hacer una lista general de bienes que deberían ser protegidos (sección 2.2.2). Esta información es crítica para proyectar el coste-efectividad de los procedimientos. A veces es apetecible empezar creando los procedimientos de seguridad para decidir los diferentes mecanismos primero: "nuestro sitio debería tener un registro de todos los servidores, modems de entrada, y tarjetas inteligentes pata todos los usuarios." Este método podría llevar a que algunas áreas estén demasiado protegidas y otras no lo estén suficiente. Empezar con la política de seguridad y los riegos debería asegurar que se da un nivel de protección adecuado a todos los bienes. .ti 0 3.2 Identificar Posibles Problemas .in 3 Para determinar riesgos, las vulnerabilidades se deben identificar. Parte del propósito de la política es ayudar a apuntalar las vulnerabilidades y de esta manera disminuir el riesgo en tantas áreas como sea posible. Varias de las áreas problemáticas más populares son presentadas en secciones posteriores. Esta lista no está completa en absoluto. Además, es probable que cada sitio tenga unas pocas vulnerabilidades únicas. .ti 3 3.2.1 Puntos de Acceso .in 6 Los puntos de acceso normalmente los usan los usuarios no autorizados para entrar. Teniendo algunos puntos de acceso se incrementa el riesgo de acceso a una organización informática e instalaciones de red. La red que enlaza a redes exteriores a la organización permiten acceder a la organización a todos los usuarios conectado a esa red externa. Una red de enlace normalmente proporciona acceso a un gran número de servicios de red, y cada servicio tiene posibilidades de ser comprometido. Las lineas de acceso telefónico, dependiendo de su configuración, pueden proporcionar acceso simplemente a un puerto de login de un solo sistema. Si se conecta a un servidor de terminales, la linea de acceso telefónico puede dar acceso a toda la red. Los mismos servidores de terminales pueden ser una fuente de problemas. Algunos de ellos no piden ningún tipo de autenticación. Los intrusos los usan a veces para disfrazar sus acciones, conectándose telefonicamente a un teléfono local y usando entonces el servidor de los terminales para salir de la red local. Algunos servidores de terminales están configurados de forma que los intrusos pueden hacer TELNET [19] desde fuera de la red, y hacer TELNET hacia fuera otra vez, de nuevo sirviendo para dificultar su rastreo. .ti 3 3.2.2 Sistemas Mal Configurados .in 6 Los sistemas mal configurados son un gran porcentaje de los agujeros de seguridad. Los sistemas operativos actuales y su software asociado han llegado a ser tan complejos que entender como funciona el sistema se ha convertido en un trabajo a jornada completa. A veces, los administradores de sistemas serán gente no especializada buscada entre el personal actual de la organización. Los vendedores también son en parte culpables de los sistemas mal configurados. Para hacer el proceso de instalación más fácil, ocasionalmente eligen configuraciones iniciales que no son seguras en todos los entornos. .ti 3 3.2.3 Fallos del Software .in 6 El software nunca estará libre de fallos. Los métodos más utilizados para intrusiones no autorizadas son los fallos de seguridad conocidos publicamente. Parte de la solución a este problema es estar al tanto de los problemas de seguridad y actualizar el software cuando los problemas sean detectados. Cuando se encuentran fallos, se debería informar al vendedor de forma que se pueda implementar y distribuir una solución al problema. .ti 3 3.2.4 Amenazas "Internas" .in 6 Un miembro de la organización puede ser una amenaza a la seguridad de los sistemas informáticos considerable. Los miembros a veces tienen acceso directo a los componentes físicos de ordenadores y redes. La posibilidad de acceder a los componentes de un sistema hace a la mayoría de los sistemas más fáciles de comprometer. La mayoría de las estaciones de trabajo de escritorios pueden ser facilmente manipuladas de manera que consigan privilegios de acceso. Acceder a una red de área local proporciona la posibilidad de ver posibles datos sensibles a través de las red. .ti 0 3.3 Elección de Controles para Proteger Bienes de Manera Rentable .in 3 Después de establecer qué debe ser protegido, y evaluar los riesgos a que estos bienes son expuestos, es necesario decidir como implementar los controles que protegen estos bienes. Los controles y mecanismos de control deberían ser seleccionados de una manera que contrarreste adecuadamente las amenazas encontradas durante la evaluación de riesgos, e implementar estos controles de forma rentable. Tiene poco sentido gastar una exorbitante suma de dinero y restringir demasiado a los usuario si la amenaza de exposición es muy pequeña. .ti 3 3.3.1 Elegir el Conjunto de Controles Correcto .in 6 Los controles que son elegidos representan la encarnación física de su política de seguridad. Son la primera y principal linea de defensa en la protección de sus bienes. Lo más importante es, por consiguiente, asegurarse de que los controles que elija es el conjunto de controles correcto. Si la mayor amenaza para su sistema con los intrusos del exterior, probablemente no tenga mucho sentido usar dispositivos biométricos para autentificar a sus usuarios normales del sistema. Por otra parte, si la mayor amenaza es un uso desautorizado de los recursos informáticos por parte de los usuarios normales probablemente querrá establecer procedimientos de registro automatizados muy rigurosos. .ti 3 3.3.2 Usar el Sentido Común .in 6 El sentido común es la herramienta más apropiada que puede usar para establecer su política de seguridad. Elaborar esquemas y mecanismos de seguridad es impresionante, y han de tener su lugar, sin embargo, tiene poco sentido invertir tiempo y dinero en un esquema de implementación elaborado si los controles simples son olvidados. Por ejemplo, no importa como de elaborado esté un sistema que ponga lo último en controles de seguridad existentes, un simple usuario con una contraseña pobre todavía puede dejar su sistema abierto a ataques. .ti 0 3.4 Usar Múltiples Estrategias para Proteger Bienes .in 3 Otra forma de proteger los bienes es usar múltiples estrategias. De esta manera, si una estrategia falla o es evadida, otra estrategia se pone en marcha para continuar protegiendo el bien. Usando varias de las estrategias más simples, a veces un sistema puede ser más seguro que si se utilizase un método muy sofisticado en su lugar. Por ejemplo, los modems con retorno de llamada (dial-back) se pueden usar en conjunción con los mecanismos tradicionales entrada al sistema. Algunos métodos similares pueden ser ideados para proporcionar varios niveles de protección para los bienes. Sin embargo, es muy fácil pasarse con mecanismos extra. Uno debe tener en mente qué es lo que necesita proteger exactamente. .ti 0 3.5 Seguridad Física .in 3 Es algo dado en seguridad informática que si el sistema por sí mismo no es fisicamente seguro, nada en torno al sistema se puede considerar seguro. Con acceso físico a una máquina, un intruso puede detener el sistema, lo que posibilita volver en modo privilegiado, reemplazar o alterar el disco, instalar caballos de Troya (ver sección 2.13.9.2), o hacer cualquier número de otras acciones no deseables (y difíciles de prevenir). Los enlaces de comunicaciones críticos, servidores importantes, y otras máquinas clave deberían ser alojadas en áreas seguras. Algunos sistemas de seguridad (tales como kerberos) necesitan que la máquina sea fisicamente segura. Si no puede asegurar sus máquinas fisicamente, debería tener cuidado al confiar en esas máquinas. Los sitios deberían considerar limitar el acceso desde máquinas no seguras a máquinas más seguras. En concreto, permitir acceso seguro (p.ej., los comandos remotos de BSD Unix tales como rsh) desde este tipo de servidores es particularmente arriesgado. Para máquinas que parezcan o que pretendan ser fisicamente seguras, se debería tener cuidado sobre quien tiene acceso a las máquinas. Recuerde que el personal de custodia y mantenimiento a veces tiene llaves de las habitaciones. .ti 0 3.6 Procedimientos para Reconocer Actividad No Autorizada .in 3 Se pueden usar varios procedimientos simples para detectar la mayoría de los usos no autorizados de un sistema informático. Estos procedimientos usan herramientas proporcionadas con el sistema operativo por el vendedor, o herramientas publicamente disponibles de otras fuentes. .ti 3 3.6.1 Uso del Sistema de Monitoreo .in 6 El sistema de monitoreo se puede hacer por ambos: por un administrador del sistema, o por software escrito para el propósito. Monitorear un sistema conlleva mirar en varias partes del sistema y buscar cualquier cosa inusual. Algunas de las formas más sencillas de hacer esto están descritas en esta sección. Lo más importante en el uso de un sistema de monitoreo es que sea haga regularmente. Escoger un día del mes para monitorizar el sistema no tiene sentido, puesto que una brecha de seguridad puede ser aislada en cuestión de horas. Solo manteniendo una vigilia constante puede esperar detectar violaciones de seguridad a tiempo de reaccionar. .ti 3 3.6.2 Herramientas para Monitorizar el Sistema .in 6 Esta sección describe herramientas y métodos para monitorizar un sistema contra acceso y uso no autorizados. .ti 6 3.6.2.1 Entrada al Sistema .in 9 La mayoría de los sistemas operativos almacenan cuantiosos bits de información de forma regular que son a veces la primera linea de defensa para detectar un uso no autorizado del sistema. .in 10 .ti 12 - Comparar listas de los usuarios actualmente introducidos en el sistema con historiales registrados anteriormente. La mayoría de los usuarios normalmente entran y salen en aproximadamente el mismo tiempo cada día. Una cuenta usada fuera del horario "normal" para esa cuenta puede estar siendo usada por un intruso. .in 10 .ti 12 - Algunos sistemas mantienen registros de las cuentas para propósitos de facturación. Estos registros también se pueden usar para determinar patrones de uso del sistema; "registros de cuentas anormales" pueden indicar un uso desautorizado del sistema. .in 10 .ti 12 -Medios de Registro del Sistema, tales como la utilidad "syslog" de Unix, deberían ser examinados buscando mensajes de error extraños. Por ejemplo, un gran número de entradas al sistema fallidas en un periodo de tiempo corto puede indicar que alguien está intentando adivinar contraseñas. .in 10 .ti 12 - Los comandos del sistema operativo que listan los procesos que se están ejecutando realmente se pueden usar para detectar si los usuarios están ejecutando programas que no están autorizados a usar, así como detectar programas no autorizados que han sido iniciados por un intruso. .ti 6 3.6.2.2 Software de Monitoreo .in 9 Otras herramientas de monitoreo se pueden hacer usando software estándar de los sistemas operativos, usando varios, a menudo diversos, programas juntos. Por ejemplo, se pueden hacer listas de comprobación de configuraciones de permisos y propietarios (por ejemplo, con "ls" y "find" en Unix) y almacenarlas localmente. Mas tarde estas listas se pueden rehacer periodicamente y compararlas con la lista de comprobación maestra (en Unix, usando la utilidad "diff"). Las diferencias pueden indicar que se han producido modificaciones no autorizadas en el sistema. No obstante otras herramientas están disponibles a través de terceras partes y sitios públicos de distribución de software. La sección 3.9.9 muestra varias fuentes de las que puede aprender que herramientas están disponibles y como obtenerlas. .ti 6 3.6.2.3 Otras Herramientas .in 9 También se pueden usar otras herramientas para monitorizar violaciones de seguridad de sistemas, aunque este no sea su propósito principal. Por ejemplo, monitores de red se pueden usar para detectar y registrar conexiones de sitios desconocidos. .ti 3 3.6.3 Variar la Agenda de Monitoreo .in 6 La tarea de monitorizar un sistema no es tan intimidante como pueda parecer. Los administradores de sistemas pueden ejecutar algunos de los comandos usados para realizar periodicamente la monitorización a lo largo del día durante los momentos en que está en reposo (p.ej., mientras habla por teléfono), mejor que gastar períodos de cada día monitorizando el sistema. Ejecutando los comandos frecuentemente, rápidamente llegará a usarlos para ver la salida "normal", y detectará fácilmente cosas que estén fuera de lo ordinario. Además, ejecutando varios comandos de monitoreo en diferentes veces a lo largo del día, le hará difícil a un intruso predecir sus acciones. Por ejemplo, si un intruso sabe que cada día a las 5 p.m. el sistema es examinado para ver que todos han salido, él simplemente esperará hasta después de que el examen se haya completado antes de entrar. Pero el intruso no podrá adivinar cuando un administrador del sistema puede escribir un comando para ver todos los usuarios introducidos en el sistema, y de esta manera él corre un riesgo de detección mucho mayor. A pesar de las ventajas que el sistema de monitoreo regular proporciona, algunos intrusos serán conscientes de los mecanismos de registro estándar que usan los sistemas que están atacando. Perseguirán activamente e intentarán desactivar los mecanismos de monitoreo. El monitoreo regular por eso es útil en la detección de intrusos, pero no proporciona ninguna garantía de que su sistema sea seguro, ni monitorizar se debería considerar un método infalible para detectar el uso no autorizado. .ti 0 3.7 Definir Acciones a Tomar Cuando Se Sospecha de Actividad No Autorizada .in 6 Las secciones 2.4 y 2.5 discuten el curso de acción que un sitio debería tomar cuando sospecha que se está abusando de su sistema. La política de seguridad informática debería declarar el procedimiento general para tratar estos problemas. Los procedimientos para tratar este tipo de problemas se deberían anotar. ¿Quién está autorizado a decidir qué acciones se tomarán? ¿Se debería involucrar a los cuerpos de seguridad? ¿Debería su organización cooperar con otros sitios para intentar perseguir a un intruso? Las respuestas a todas las preguntas sobre la sección 2.4 deberían ser parte de los procedimimentos de tratamiento de incidentes. Tanto si decide bloquearlos fuera como perseguir intrusos, debería tener herramientas y procedimientos preparados para aplicarlos. Es mejor familiarizarse con estas herramientas y procedimientos antes de necesitarlos. NO espere hasta que un intruso está en su sistema para entender como seguir la pista a las acciones del intruso; estará bastante ocupado si ataca un intruso. .ti 0 3.8 Comunicar Política de Seguridad .in 3 Las políticas de seguridad, para ser efectivas, se deben comunicar tanto a los usuarios del sistema como al personal de mantenimiento. Esta sección describe qué se le debería contar a esta gente y como se le debería contar. .ti 3 3.8.1 Educar a los Usuarios .in 6 A los usuarios se les debería tener al tanto de como se espera que usen los sistemas informáticos, y como protegerse de usuarios no autorizados. .ti 6 3.8.1.1 Uso Apropiado de la Cuenta/Estación de Trabajo .in 9 Todos los usuarios deberían ser informados sobre qué es considerado un uso "apropiado" de su cuenta o estación de trabajo (el uso "apropiado" está discutido en la sección 2.3.2). La mayoría de las veces se puede hacer facilmente a la vez que un usuario recibe su cuenta, dándole una declaración de la política. Las políticas de uso apropiado normalmente dictan cosas tales como si la cuenta puede o no ser usada para actividades personales (como llevar el balance de pagos o escribir cartas), si están permitidas las actividades lucrativas, si está permitido utilizar juegos, y demás. Estas declaraciones de la política pueden ser usadas también para resumir como está autorizada la instalación informática y que licencias de software posee la institución; Por ejemplo, algunas universidades tienen licencias educativas que prohíben explicitamente el uso comercial del sistema. Una lista más completa de las cosas a considerar cuando escriba una declaración de la política se da en la sección 2.3. .ti 6 .in 15 3.8.1.2 Procedimientos de Mantenimiento de Cuentas/Estaciones de Trabajo .in 9 A cada usuario se le debería contar como administrar apropiadamente su cuenta y estación de trabajo. Esto incluye explicar como proteger archivos almacenados en el sistema, como bloquear o salir del terminal o estación de trabajo, y demás. Mucha de esta información normalmente está cubierta en la documentación del "usuario principiante" proporcionado por el vendedor del sistema operativo, aunque algunos sitios prefieren complementar este material con información local. Si su sitio ofrece acceso al sistema informático a través de módem por conexión telefónica, debe tener un cuidado especial en informar a los usuarios de los problemas de seguridad inherentes a proporcionar este acceso. Asuntos como salir de forma segura del sistema antes de desconectar el módem se deberían cubrir cuando al usuario se le da el acceso de forma telefónica inicialmente. Igualmente, el acceso a los sistemas a través de redes locales o de gran extensión presentan su propio conjunto de problemas de seguridad que los usuarios deberían conocer. Se deberían explicar cuidadosamente los archivos que garantizan la condición de "servidores confiables" o "usuarios confiables" a sistemas y usuarios remotos. .ti 6 3.8.1.3 Determinar el Mal Uso de las Cuentas .in 9 Se debería contar a los usuarios como detectar el acceso no autorizado a su cuenta. Si el sistema muestra la última vez que entró al sistema cuando un usuario entra, se le debería decir a él o ella que compruebe si la fecha y comentario se corresponden con la ultima vez que él o ella entró. Los interpretes de comandos en algunos sistemas (p.ej., la consola C de UNIX) mantienen historiales de los últimos comandos ejecutados. los usuarios deberían asegurarse de que nadie ha ejecutado otros comandos en su cuenta. .ti 6 3.8.1.4 Procedimientos de Información de Problemas .in 9 Se debería desarrollar un procedimiento para permitir a los usuarios informar sobre un mal uso sospechoso de sus cuentas u otro mal uso que hayan podido notar. Se puede hacer proporcionando el nombre y número de teléfono de un administrador del sistema que gestione la seguridad del sistema informático, o creando una dirección de correo electrónico (p.ej., "security") a la que los usuarios puedan dirigir sus problemas. .ti 3 3.8.2 Educar a Los Administradores de Servidores .in 6 En algunas organizaciones, los sistemas informáticos están administrados por gran variedad de gente. Estos administradores deben saber como proteger sus propios sistemas de ataques y usos no autorizados, de igual manera que deben saber cómo comunicar sobre una penetración que ha tenido éxito en su sistema a otro administrador como aviso de peligro. .ti 6 3.8.2.1 Procedimientos de Gestión de Cuentas .in 9 Se debe tener cuidado cuando instale cuentas en el sistema para hacerlas seguras. Cuando se instala un sistema de un medio de distribución, se debería examinar el archivo de contraseñas y mirar las cuentas "estándar" proporcionadas por el vendedor. Algunos vendedores proporcionan cuentas para ser usadas por los servicios del sistemas o personal de servicio. Normalmente algunas de estas cuentas no tienen contraseña o son muy conocidas. A estas cuentas se les debería dar contraseñas nuevas si se las necesita, o desactivarlas o borrarlas del sistema si no. La cuentas sin contraseña normalmente son muy peligrosas, ya que permiten a cualquiera acceder al sistema. Incluso las cuentas que no ejecutan un intérprete de comandos (p.ej., las cuentas que existen solo para ver quién ha entrado al sistema) pueden ser comprometidas si no están bien configuradas. Un concepto relacionado, eso de transferencia de archivos "anonymous" (FTP) [20], permite a los usuarios de toda la red acceder a su sistema para copiar archivos de (normalmente) un área de disco protegida. Usted debería evaluar cuidadosamente que una cuenta sin contraseña proporciona contra las amenazas de seguridad de proporcionar tal acceso a su sistema. Si el sistema operativo proporciona los medios para usar contraseñas "shadow" que almacena las contraseñas en un archivo separado accesible solo para usuarios privilegiados, se debería usar este método. El sistema UNIX System V, SunOS 4.0 y superior, y las versiones del UNIX de Berkeley posteriores a 4.3BSD Tahoe, así como otras, proporcionan esta característica. Esto protege las contraseñas ocultando sus valores cifrados a los usuarios sin privilegios. Esto previene que un atacante copie el archivos de contraseñas a su máquina y entonces intente adivinar las contraseñas en su tiempo libre. Cuide el seguimiento de quién ha accedido a cuentas de usuarios con privilegios (p.ej., "root" en UNIX o "MAINT" en VMS). Cuando quiera que un usuario con privilegios deje la organización o no necesite más la cuenta con privilegios, se deben cambiar las contraseñas de todas las cuentas con privilegios. .ti 6 3.8.2.2 Procedimientos de Administración de Configuración Cuando instale un sistema de un medio de distribución o instale software de terceros, es importante examinar la instalación cuidadosamente. Algunos procedimientos de instalación asumen sitios "confiados", así que instalará archivos con todos los permisos de escritura activados, o de lo contrario, de no vigilar la instalación, compromete la seguridad de los archivos. También se deberían examinar los servicios de red cuando se instale por primera vez. Algunos vendedores proporcionan permisos a archivos a través de la red, lo que implica que todos los servidores exteriores son tomados como "de confianza", lo cual raramente es el caso cuando se conecta con redes de área extensa tales como Internet. Algunos intrusos coleccionan información sobre las vulnerabilidades de versiones de sistemas en particular. Si hay un sistema muy antiguo, lo más probable es que haya problemas de seguridad en esa versión que han sido arregladas desde entonces por el vendedor en una liberación posterior. Por esta razón es importante evaluar los riesgos de no actualizarlo a una nueva versión del sistema operativo (dejando así sin tapar los agujeros de seguridad) contra el coste de actualizar al software nuevo (posiblemente abriendo brechas en el software de terceras partes, etc.). Los arreglos de fallos del vendedor se deberían examinar de manera similar, con el añadido destacable de que los arreglos de "seguridad" de un vendedor tratan normalmente de forma limpia los problemas de seguridad serios. Otros arreglos de fallos, recibidos a través de listas de correo y similares, normalmente se deberían instalar, pero no sin un cuidadoso examen. Nunca instale un parche a menos que esté seguro de que sabe las consecuencias del arreglo - siempre existe la posibilidad de que un intruso haya sugerido un "arreglo" que le da acceso a su sistema. .ti 6 3.8.2.3 Procedimientos de Recuperación - Copias de Seguridad .in 9 Es imposible dar demasiada importancia a la necesidad de una buena estrategia de copia de seguridad. Las copias de seguridad del sistema de archivos no solo le protege en el caso de fallo de hardware o borrados accidentales, sino que también le protegen contra cambios no autorizados hechos por un intruso. Sin una copia de sus datos como "se debe", puede ser difícil deshacer algo que haya hecho un atacante. Las copias de seguridad, especialmente si se hacen diariamente, también pueden ser útiles para proporcionar un historial de las actividades del intruso. Mirando en copias de seguridad antiguas puede establecer cuando su sistema fue penetrado por primera vez. Los intrusos pueden dejar archivos que, aunque sean borrados más tarde, son capturados por las cintas de copia de seguridad. Las copias de seguridad también se pueden usar para documentar las actividades de un intruso a las agencias de las fuerzas de seguridad si fuese necesario. Una buena estrategia de copia de seguridad copiará el sistema entero a una cinta al menos una vez al mes. Se deberían hacer copias parciales (o "incrementales") al menos una vez a la semana, e idealmente se deberían hacer diariamente. Se deberían usar comandos especificamente diseñados para desarrollar copias de seguridad del sistema de archivos (p.ej, el "dump" de UNIX o el "BACKUP" de VMS) en vez de otros comandos de copia, ya que estas herramientas están diseñadas con la intención expresa de restaurar un sistema a una situación conocida. .ti 6 3.8.2.4 Procedimientos de Informe de Problemas Al igual que los usuarios, los administradores del sistema deberían tener definido un procedimiento para informar de los problemas de seguridad. En grandes instalaciones, a veces se hace creando un alias de correo electrónico que contenga los nombres de todos los administradores del sistema de la organización. Otros métodos incluyen crear algún tipo de equipo de respuesta similar al CERT, o establecer una "linea caliente" atendida por un equipo de mantenimiento existente. .ti 0 3.9 Recursos para Prevenir Agujeros de Seguridad Esta sección discute software, hardware y recursos de procedimientos que se pueden usar para mantener su política de seguridad. .ti 3 3.9.1 Conexiones de Red y Cortafuegos .in 6 Un "Cortafuegos" se pone en una construcción para proporcionar un punto de resistencia a la entrada de llamas en otro área. De forma similar, un escritorio de secretario y área de recepción proporciona un punto de control de acceso a otros sitio de la oficina. Esta misma técnica se puede aplicar a un sitio informático, de forma particular en el caso de las conexiones de red. Algunos sitios solo estarán conectadas a otros sitios dentro de la misma organización y no tendrán la capacidad de conectarse a otras redes. Sitios como este son menos susceptibles a amenazas del exterior de su propia organización, aunque todavía pueden ocurrir intrusiones a través de vías tales como modems de conexión telefónica. Por otra parte, algunas otras organizaciones estarán conectadas a través de grandes redes, tales como Internet. Estos sitios son susceptibles de todo el rango de amenazas asociadas al entorno de red. Las amenazas de conectarse a redes exteriores se deben ponderar con los beneficios. Se puede desear limitar las conexiones al exterior a esos servidores que no almacenan material sensible, cuidando de que las máquinas "vitales" estén aisladas (tales como la que contiene la balanza de pagos de la compañía o sistemas de inventario). Si se necesita participar en una Red de Area Extensa (WAN), considere restringir todo los accesos a su red local a un solo sistema. Esto es, todo los accesos a o desde su propia red se deberán hacer a través de un solo servidor informático que actuará como un cortafuegos entre usted y el mundo exterior. Este sistema cortafuegos, deberá ser controlado rigurosamente y protegido con contraseña, y también se debería restringir a los usuarios externos que accedan a él restringiendo la funcionalidad disponible a usuarios remotos. Usando este método, su sitio podría relajarse un poco de los controles de seguridad interna en su red local, pero aún estaría a disposición de la protección de un servidor de cara al exterior rigurosamente controlado. Dese cuenta que aunque use un cortafuegos, el compromiso del cortafuegos podría dar como resultado el compromiso de toda la red que hay tras del cortafuegos. Se ha trabajado en algunas áreas para construir un cortafuegos que, aún cuando esté comprometido, todavía proteja la red local [6,CHESWICK]. .ti 3 3.9.2 Confidencialidad .in 6 Confidencialmente, el hecho de guardar cosas ocultas o secretas, es uno de las primeras metas de los practicantes de seguridad informática. Algunos sistemas operativos modernos proporcionan varios mecanismos para permitir a los usuarios controlar la diseminación de la información. Dependiendo de donde trabaje, usted puede tener un sitio donde todo está protegido o un sitio donde toda la información normalmente está estimada como pública, o algo a medias. La mayoría de los sitios se inclinan al medio, al menos hasta que se produzca una intrusión. Generalmente, hay tres casos en que la información es vulnerable a ser descubierta: cuando la información está almacenada en un sistema informático, cuando la información está siendo enviada a otro sistema (a través de la red), y cuando la información está almacenada en cintas de copias de seguridad. El primero de estos casos está controlado por los permisos del archivo, listas de control de acceso, y otros mecanismos similares. El último puede ser controlado restringiendo el acceso a las cintas de copia de seguridad ( guardándolas en una caja fuerte, por ejemplo). En los tres casos puede ayudar usar mecanismos de cifrado. .ti 6 3.9.2.1 Cifrado (hardware y software) .in 9 Cifrar es el proceso de tomar información que existe de forma legible y convertirlo a una forma no legible. hay varios tipos de paquetes de cifrado disponibles comercialmente en ambas formas, hardware y software. Los mecanismos de cifrado por hardware tienen la ventaja de que son mucho más rápidos que sus equivalentes en software, aunque y debido a que son más rápidos, son un beneficio potencial a un atacante que quiera ejecutar un ataque por fuerza bruta a su información cifrada. La ventaja de usar cifrado es que, aún cuando otros mecanismos de control de acceso (contraseñas, permisos de archivos, etc.) hayan sido comprometidos por un intruso, los datos todavía serán inservibles. Naturalmente, las contraseñas de cifrado y similares debería estar protegido al menos tan bien como las contraseñas de las cuentas. Al igual, la información en tránsito (a través de una red) puede ser vulnerable a ser interceptada. Existen varias soluciones a esto, desde simplemente cifrar los archivos antes de transferirlos (cifrado punta a punta) a hardware especial de red que lo cifra todo y lo envía sin intervención del usuario (enlaces seguros). En general en Internet no se usan enlaces seguros, por lo que se debe usar el cifrado punta-a-punta si se desea cifrado a través de Internet. .in 20 .ti 9 3.9.2.1.1 Estándar de Cifrado de Datos-DES (Data Encryption Standard-DES) .in 12 Hoy DES es practicamente el mecanismo de cifrado de datos más usado. Existen algunas implementaciones por software y hardware, y algunos ordenadores comerciales se proporcionan con una versión de software. DES transforma la información en texto plano en datos cifrados (o texto cifrado) a través de un algoritmo especial y un valor "semilla" llamado clave. Mientras la clave sea retenida (o recordada) por el usuario original, el texto cifrado podrá ser restaurado al texto plano original. Uno de los peligros de todos los sistemas de cifrado es la necesidad de recordar la clave bajo la que una cosa fue cifrada (este no es diferente del problema de las contraseñas discutido en alguna parte de este documento). Si se apunta la clave, se volverá menos segura. Si se olvida, hay una pequeña (si es que hay alguna) esperanza de recuperar los datos originales. La mayoría de los sistemas UNIX proporcionan un comando DES que posibilita al usuario cifrar los datos usando el algoritmo DES. .ti 9 3.9.2.1.2 Crypt .in 12 De forma similar al comando DES, el comando de UNIX "crypt" permite al usuario cifrar datos. desafortunadamente, el algoritmo usado por "crypt" es muy inseguro (basado en el dispositivo "Enigma" de la Segunda Guerra Mundial), y los archivos cifrados con este comando pueden ser descifrados facilmente en cuestión de pocas horas. Generalmente, el uso del comando "crypt" debería ser evitado excepto para las tareas de cifrado más triviales. .ti 6 3.9.2.2 Correo Electrónico con Intimidad Mejorada .in 9 El correo electrónico normalmente transita a través de la red en claro (esto es, cualquiera puede leerlo). Este no es el resultado final óptimo obviamente. El correo de intimidad mejorada (Privacy enhanced mail) proporciona una manera de cifrar los mensajes de correo electrónico automaticamente de forma que una persona que esté espiando en un nodo de distribución de correo no sea capaz de leerlo (facilmente). Actualmente en Internet se están desarrollando y desplegando varios paquetes de correo de intimidad mejorada. El Grupo Especial de Trabajo de la Tabla de Actividades de Intimidad de Internet ha definido un borrador de estándar, el protocolo elegido para usar en una implementación de correo de intimidad mejorada. Este protocolo está definido en los RFCs 1113, 1114, y 1115 [7,8,9]. Por favor dirijase a la edición actual del "IAB Protocolos Estándar Oficiales" (actualmente, RFC 1200 [21]) para ver el estado de estandarización y la condición de estos protocolos. .ti 3 3.9.3 Autenticación del Origen .in 6 Normalmente damos por sentado el hecho de que el encabezado de un mensaje de correo electrónico indica de verdad el remitente del mensaje. Sin embargo, es fácil "engañar", o falsificar el código fuente de un mensaje de correo. La autenticación del origen proporciona una manera de certificar el remitente de un mensaje u otro objeto de la misma manera que un notario público cerciora con una firma un documento legal. Esto se hace a través de un criptosistema de "llave pública". Un criptosistema de llave pública difiere de un criptosistema de llave privada en varias cosas. Primero, un sistema de llave pública usa dos llaves, una Llave Pública que puede ser usada por cualquiera (de ahí el nombre) y una Llave Privada que solo usa el remitente del mensaje. El remitente usa la llave privada para cifrar el mensaje (como en DES). El receptor, que ha obtenido la llave pública del remitente, puede entonces descifrar el mensaje. En este esquema, la llave pública es usada para autentificar el uso de la llave privada por parte del remitente, y de esta manera la identidad del remitente es comprobada más rigurosamente. La implementación más conocida de un criptosistema de llave pública es el sistema RSA [26]. El estándar de Internet para correo de intimidad mejorada hace uso del sistema RSA. .ti 3 3.9.4 Integridad de la Información .in 6 La integridad de la información se refiere al estado de la información en cuanto a que esté completa, correcta, y sin cambios desde la última vez que fue verificado que estaba en estado "íntegro". El valor de la integridad de la información en un sitio variará. Por ejemplo, es más importante para el ejército y las instalaciones gubernamentales prevenir la "divulgación" de información clasificada, sea bueno o malo. A un banco, por otra parte, le importa mucho más si la información mantenida de las cuentas de sus clientes es completa y certera. Numerosos mecanismos de sistemas informáticos, así como controles de proceso, tienen una influencia en la integridad de la información del sistema. Los mecanismos de control de acceso tradicionales mantienen controles sobre quien puede acceder a la información del sistema. En algunos casos solo estos mecanismos no son suficientes el grado de integridad requerida. Algunos otros mecanismos son brevemente comentados más abajo. Debería darse cuenta que hay otros aspectos para mantener la integridad del sistema además de estos mecanismos, tales como controles de dos personas, y procedimientos de validación de la integridad. Estos están más allá del alcance de este documento. .ti 6 3.9.4.1 Sumas de Control Sencillamente el mecanismo más simple, una simple rutina puede calcular el valor para un archivo del sistema y compararlo con el último valor conocido. Si los dos son iguales, probablemente el archivo no ha cambiado. Si no, el archivo ha sido cambiado de alguna manera desconocida. Aunque es lo más sencillo de implementar, el esquema de sumas de control sufre de un importante fallo, que no es muy sofisticado y un atacante determinado facilmente podría añadir suficientes caracteres al archivo para obtener el valor final correcto. Un tipo específico de suma de control, denominada suma de control CRC, es considerablemente más robusta que una suma de control simple. Solo es ligeramente más difícil de implementar, y proporciona un grado de control de errores mejor. También, sin embargo, sufre la posibilidad de ser comprometido por un atacante Las sumas de control pueden ser usadas para detectar la alteración de información. Sin embargo, no guardan activamente contra los cambios que se hagan. Para esto, se deberían usar otros mecanismos como el control de acceso y el cifrado. .ti 6 3.9.4.2 Sumas de Control Criptográficas .in 9 Las sumas de control criptográficas (también llamadas criptofirmas) conllevan descomponer un archivo en varios trozos más pequeños, calcular una suma de control (CRC) para cada trozo y añadir las CRCs juntas. dependiendo de cual sea exactamente el algoritmo usado, esto puede resultar un método casi infranqueable de determinar si un archivo ha cambiado. Este mecanismo sufre del hecho de que a veces es computacionalmente intensivo y puede ser prohibitivo excepto en los casos donde se desea la máxima integridad. Otro mecanismo relacionado, denominado función unilateral (one-way hash function) (o un Código de Detección de Manipulación (MDC)) también puede ser usado para identificar univocamente un archivo. La idea que hay detrás de estas funciones es que dos entradas no puedan producir la misma salida, y de esta manera que un archivo modificado no pueda tener el mismo valor de la función. Las funciones unilaterales se pueden implementar eficientemente en gran cantidad de sistemas, haciendo posible que sean irrompibles los controles de integridad. (Snefru, una función unilateral disponible a través de USENET así como de Internet es solo un ejemplo de una función unilateral eficiente.) [10] .ti 3 3.9.5 Limitar el Acceso a Redes .in 6 Los protocolos de red dominantes en uso en Internet, IP (RFC 791) [11], TCP (RFC 793) [12], y UDP (RFC 768) [13], llevan cierto control de la información que puede ser usado para restringir el acceso a ciertos servidores o redes dentro de una organización. Los encabezados de los paquetes IP contiene las direcciones de red tanto del remitente como del receptor del paquete. Además, los protocolos TCP y UDP proporcionan el concepto de "puerto", que identifica el final (normalmente un servidor de red) de una ruta de comunicaciones. En algunos casos, se puede desear denegar el acceso a unos puertos TCP o UDP específicos, o incluso a ciertos servidores y redes por completo. .TI 6 3.9.5.1 Tablas de Enrutamiento de Pasarela .IN 9 Uno de los métodos más simples para prevenir conexiones de red no deseadas es simplemente borrar ciertas redes de una tabla de enrutamiento de pasarela. Esto hace "imposible" a un servidor enviar paquetes a estas redes. (La mayoría de los protocolos requiere flujo bidireccional de paquetes aunque sea para un flujo de datos unidireccional, así que con romper un lado de la ruta es suficiente normalmente). Este método normalmente se lleva a cabo en sistemas "cortafuegos" avisando al cortafuegos de preservar ciertas rutas locales al mundo exterior. Este método falla en que a veces previene "demasiado" (p.ej., al impedir el acceso a un sistema en una red, se desactiva el acceso a todos los sistemas de la red). .ti 6 3.9.5.2 Filtrado de Paquetes de Enrutador .in 9 Algunos sistemas pasarela (más correctamente denominados enrutadores) disponibles comercialmente proporcionan la capacidad de filtrar paquetes basándose no solo en fuentes o destinatarios, sino también en combinaciones fuente-destino. Este mecanismo se puede utilizar para denegar el acceso a un servidor específico, una red, o una subred de algún otro servidor, red. o subred. Los sistemas pasarela de algunos vendedores (p.ej., Cisco Systems) soportan un esquema incluso más complicado, permitiendo afinar el control sobre direcciones fuente y destino. A través del uso de máscaras de direcciones, uno puede denegar el acceso a todos los servidores excepto uno en una red en particular. Los sistemas de Cisco Systems también permiten filtrado de paquetes basado en tipos de protocolo IP y número de puerto TCP o UDP [14]. Esto también se puede puentear mediante paquetes de "enrutación en la fuente" destinados a la red "secreta". Los paquetes enrutados en la fuente se pueden filtrar en pasarelas, pero esto puede restringir otras actividades legítimas, tales como diagnosis de problemas de enrutamiento. .ti 3 3.9.6 Sistemas de Autenticación .in 6 Autenticación se refiere al proceso de proporcionar una identidad solicitada a la satisfacción de alguna autoridad de concesión de permiso. Los sistemas de autenticación son hardware, software, o mecanismos procedimentales que permiten al usuario obtener acceso a recursos informáticos. Al nivel más simple, el administrador del sistema que añade nuevas cuentas de usuario es parte del mecanismo de autenticación del sistema. Al otro extremo del espectro, lecturas de huellas dactilares o escáneres de retina proporcionan una solución de de muy alta tecnología para establecer la identidad de un usuario potencial. Sin establecer y proporcionar una identidad de usuario antes de establecer una sesión, los ordenadores de su sitio son vulnerables a cualquier tipo de ataque. Normalmente, un usuario se identifica a sí mismo introduciendo una contraseña en respuesta a un símbolo del sistema. Mecanismos de solicitud/respuesta mejoran las contraseñas solicitando al usuario alguna información compartida por ambos, el ordenador y el usuario (tales como el nombre de soltera de su madre, etc.). .ti 6 3.9.6.1 Kerberos .in 9 Kerberos, fue el nombre que se le puso al perro que, según se contaba en la mitología, guardaba las puertas del Infierno. Es una colección de software usado en grandes redes para confirmar la identidad solicitada por un usuario. Desarrollado en el Instituto Tecnológico de Massachusetts(MIT), se usa en combinación con cifrado y bases de datos distribuidas de forma que un usuario en las instalaciones de un campus pueden identificarse e iniciar una sesión en cualquier ordenador alojado en el campus. Esto tiene claras ventajas en ciertos entornos donde hay un gran número de usuarios potenciales que pueden establecer una conexión desde cualquiera de un gran numero de estaciones de trabajo. Algunos vendedores están incorporando ahora Kerberos en sus sistemas. Se debería señalar que mientras Kerberos hace varios avances en el área de autenticación, algunas debilidades de seguridad en el protocolo persisten [15]. .ti 6 3.9.6.2 Tarjetas Inteligentes .in 9 Varios sistemas usan "tarjetas inteligentes" (un dispositivo parecido a una pequeña calculadora) para ayudar a autentificar a los usuarios. Estos sistemas dependen de que el usuario tenga un objeto en su poder. Un sistema así conlleva un procedimiento de contraseña nuevo que requiere que el usuario introduzca un valor obtenido de una "tarjeta inteligente" cuando el ordenador le pida una contraseña. Generalmente, el servidor dará al usuario alguna información que será introducida , a través del teclado de la tarjeta, en la tarjeta inteligente. La tarjeta inteligente mostrará un respuesta que deberá ser introducida entonces en el ordenador antes de que la sesión sea establecida. Otro sistema así utiliza una tarjeta inteligente que muestra un número que cambia con el tiempo, pero que está sincronizado con el software de autenticación del ordenador. Esta es una manera mucho mejor de tratar la autenticación que con el método de contraseña tradicional. Por otra parte, tiene el inconveniente de tener que cargar con la tarjeta inteligente. Además, los costes iniciales tienden a ser altos. .ti 3 3.9.7 Libros, Listas y Fuentes de Información .in 6 Hay algunas buenas fuentes de información sobre seguridad informática. La bibliografía destacada al final de este documento puede proporcionarle un buen comienzo. Además, se puede obtener información de otras fuentes, algunas de las cuales están descritas en esta sección. .ti 6 3.9.7.1 Listas de Correo sobre Seguridad .in 9 La lista de correo sobre seguridad de UNIX existe para avisar a los administradores de sistemas sobre problemas de seguridad antes de que lleguen a ser más conocidos, y proporcionar mejor información de seguridad. Es una lista de acceso restringido, abierta solo a gente que puede ser verificada como gente de dirección de sistemas de un sitio. Las peticiones de unirse a la lista deben ser enviadas por alguno de los sitios de contacto listados en las base de datos WHOIS del Centro de Información de la Red de Redes de Datos de Defensa (DDN NIC), o de la cuenta "root" de una de las máquinas de los grandes sitios. Usted debería incluir la dirección de destino que usted quiere en la lista, una indicación de si quiere estar en la lista del reflector de correo o recibir extractos semanales, la dirección de correo electrónico y número de teléfono de voz de contacto del sitio si no es usted, y el nombre, dirección y número de teléfono de su organización. Debería enviar esta información a SECURITY-REQUEST@CPD.COM. El extracto RISKS es un componente de el comité ACM sobre Computadoras y Política Pública, moderada por Peter G. Neumann. Es un foro de discusión sobre riesgos al público en ordenadores y sistemas relacionados, junto con asuntos sobre intimidad y seguridad informática, han discutido temas como el incidente Stark, la caída del avión Iraní en el Golfo Pérsico (está relacionado con los sistemas de armas computerizadas), problemas en sistemas de control de tráfico aéreo y férreo, software de ingeniería, y demás. Para unirse a la lista, envíe un mensaje a RISKS-REQUEST@CSL.SRI.COM. Esta lista también está disponible en el grupo de noticias de USENET "comp.risks". La lista VIRUS-L es un foro para discutir experimentos con virus informáticos, software de protección, y temas relacionados. La lista está abierta al público, y está implementada como un compendio moderado. La mayoría de la información es relativa a ordenadores personales, aunque algo puede ser aplicable a grandes sistemas. Para subscribirse, envíe la linea: .ti 12 SUB VIRUS-L su nombre completo .in 9 a la dirección LISTSERV%LEHIIBM1.BITNET@MITVMA.MIT.EDU. esta lista también está disponible a través del grupo de noticias de USENET "comp.virus". El Compendio Underground Informático "es un foro abierto dedicado a compartir información entre informáticos y a la presentación y debate de diversos puntos de vista." Aunque no es directamente una lista sobre seguridad, contiene discusiones sobre intimidad y otros temas de seguridad relacionados. La lista se puede leer en USENET como alt.society.cu-digest, o unirse a la lista de correo, enviando un correo a Gordon Myer (TK0JUT2%NIU.bitnet@mitvma.mit.edu). Se pueden solicitar subscripciones a: cud@chinacat.unicom.com. .ti 6 3.9.7.2 Listas de Correo de Redes .in 9 La lista de correo TCP-IP intenta actuar como un foro de discusión para desarrolladores y mantenedores de implementaciones del conjunto de protocolos TCP/IP. También discute problemas de seguridad relativos a redes cuando conllevan programas que proporcionan servicios de red, tales como "Sendmail". Para unirse a la lista TCP-IP, envíe un mensaje a TCP-IP-REQUEST@NISC.SRI.COM. Esta lista también está disponible en el grupo de noticias de USENET "comp.protocols.tcp-ip". SUN-NETS es una lista de discusión para cosas pertenecientes a redes sobre sistemas de Sun. Gran parte de la discusión es relativa a NFS, NIS (formalmente Páginas Amarillas), y nombres de servidores. Para subscribirse, envíe un mensaje a SUN-NETS-REQUEST@UMIACS.UMD.EDU. Los grupos de USENET misc.security y alt.security también discuten asuntos de seguridad. misc.security es un grupo moderado y también incluye discusiones de seguridad física y bloqueos. alt.security no está moderado. .ti 6 3.9.7.3 Equipos de Respuesta Varias organizaciones han formado grupos especiales de gente para tratar los problemas de seguridad informática. Estos equipos recogen información sobre posibles agujeros de seguridad y lo diseminan a la gente apropiada, persiguen intrusos, y ayudan a la recuperación de violaciones de seguridad. Normalmente estos equipos tienen tanto listas de distribución de correo electrónico como un número de teléfono especial al que se puede llamar para pedir información o para avisar de un problema. Algunos de estos equipos son miembros del sistema CERT, que está coordinado por el Instituto Nacional de Estándares y Tecnología (NIST), y existe para facilitar el intercambio de información entre los diversos grupos. .ti 9 3.9.7.3.1 Equipo de Respuesta de Emergencia Informática de DARPA .in 12 El Equipo de Respuesta de Emergencia Informática/Centro de Coordinación (CERT/CC) fue establecido en Diciembre de 1988 por la Agencia de Investigación de Proyectos Avanzados de Defensa (DARPA) para tratar lo relativo a seguridad informática de las inquisiciones de los usuarios de Internet. Es gestionado por el Instituto de Ingeniería del Software (SEI) en la Universidad Carnegie-Mellon (CMU). El CERT puede inmediatamente consultar con expertos para diagnosticar y resolver problemas de seguridad, y también establecer y mantener comunicaciones con los usuarios afectados y las autoridades gubernamentales apropiadamente. El CERT/CC sirve como casa de clarificación para la identificación y reparación de vulnerabilidades de seguridad, evaluaciones informales de sistemas existentes, mejora de la capacidad de respuesta de emergencia, y como conciencia de seguridad tanto de vendedores como de usuarios. Además, el equipo trabaja con vendedores de varios sistemas para coordinar los arreglos de los problemas seguridad. El CERT/CC envía avisos de seguridad a la lista de correo CERT-ADVISORY cuando cree apropiado. también operan en una linea 24 horas a la que se puede llamar para avisar de problemas de seguridad (p.ej., alguien introduciéndose en su sistema), así como obtener información actual (y precisa) sobre rumores de problemas de seguridad. Para unirse a lista de correo CERT-ADVISORY, envíe un mensaje a CERT@CERT.SEI.CMU.EDU y pida ser añadido a lista de correo. El material enviado a esta lista también aparece en el grupo de noticias de USENET "comp.security.announce". Los anuncios pasados están disponibles a través de FTP anónimo en el servidor CERT.SEI.CMU.EDU. El número de la linea 24 horas es (412) 268-7090. El CERT/CC también mantiene una lista CERT-TOOLS para estimular el intercambio de información sobre herramientas y técnicas que incrementan el funcionamiento seguro de los sistemas de Internet. El CERT/CC no repasa ni respalda las herramientas descritas en la lista. Para subscribirse, envía un mensaje a CERT-TOOLS-REQUEST@CERT.SEI.CMU.EDU y pida ser añadido a la lista de correo. El CERT/CC mantiene otra información sobre seguridad generalmente útil a través de FTP anónimo en CERT.SEI.CMU.EDU. Obtenga el archivo README para obtener una lista de lo que está disponible. .ti 12 Para más información, contacte con: .in 15 CERT Software Engineering Institute Carnegie Mellon University Pittsburgh, PA 15213-3890 (412) 268-7090 cert@cert.sei.cmu.edu. .ti 9 3.9.7.3.2 Centro de Coordinación de Seguridad de DDN Para los usuarios de DDN, el Centro de Coordinación de Seguridad (SCC) hace una función similar al CERT. El SCC es la casa de clarificación de DDN para los problemas de seguridad de servidores y usuarios, y trabaja con los funcionarios de la Seguridad de Red DDN. El SCC también distribuye el Boletín de seguridad DDN, que comunica información sobre riesgos de seguridad de redes y servidores, parches, y temas concernientes a seguridad y personal de administración en instalaciones DDN. Está disponible en linea, a través de kermit o FTP anónimo, en el servidor NIC.DDN.MIL, en SCC:DDN-SECURITY-yy-nn.TXT (donde "yy" es el año y "nn" es el número del boletín). El SCC proporciona asistencia inmediata en lo relativo a problemas de seguridad de servidores DDN; llame al (800) 235-3155 (de 6:00 a.m. a 5:00 p.m. Hora de la Costa Oeste) o envíe un correo electrónico a SCC@NIC.DDN.MIL. Para una cobertura 24 horas, llame al Escritorio de Problemas de MILNET (800) 451-7413 o AUTOVON 231-1713. 3.9.7.3.3 Recurso de Seguridad Informática de NIST y Centro de Respuesta El Instituto Nacional de Estándares y Tecnología (NIST) tiene responsabilidad en el Gobierno Federal de EEUU sobre actividades de ciencias informáticas y tecnología. El NIST ha jugado un papel importante en la organización del sistema CERT y ahora está sirviendo como Secretaría del sistema CERT. El NIST también gestiona un Centro de Respuesta y Recurso sobre Seguridad Informática (CSRC) para proporcionar ayuda e información sobre sucesos e incidentes de seguridad informática, así como a incrementar el conocimiento sobre vulnerabilidades de seguridad informática. El equipo del CSRC tiene una linea 24 horas, en el (301) 975-5200. Para personas con acceso a Internet, se pueden obtener publicaciones e información sobre seguridad informática a través de FTP anónimo del servidor CSRC.NCSL.NIST.GOV (129.6.48.87). El NIST también tiene un tablón de anuncios para ordenadores personales que contiene información sobre virus informáticos así como otros aspectos de seguridad informática. Para acceder a este tablón, configure su módem a 300/1200/2400 BPS, 1 bit de parada (1 stop bit), sin paridad (no parity), y caracteres de 8 bits (8-bit characters), y llame a (301) 948-5717. Todos los usuarios tienen acceso completo al tablón en cuanto se registran. El NIST ha producido varias publicaciones especiales relacionadas con la seguridad y los virus informáticos en particular; algunas de estas publicaciones se pueden obtener de internet. Para más información, contacte con el NIST en la siguiente dirección: .in 15 Computer Security Resource and Response Center A-216 Technology Gaithersburg, MD 20899 Teléfono: (301) 975-3359 Correo eletrónico: CSRC@nist.gov .ti 9 3.9.7.3.4 Capacidad de Asesoría ante Incidentes Informáticos de DOE (CIAC) .in 12 CIAC es el centro con Capacidad Asesora ante Incidentes Informáticos del Departamento de Energía (DOE). El CIAC es un equipo de cuatro personas, científicos informáticos del Laboratorio Nacional Lawrence Livermore (LLNL), encargadas con la principal responsabilidad de asistir a los sitios del DOE de cara a incidentes de seguridad informática (p.ej., ataques de intrusiones, infecciones de virus, ataques de gusanos, etc.). Este recurso está disponible a los sitios del DOE 24 horas al día. El CIAC se formó para proporcionar una capacidad de respuesta centralizada (incluyendo asistencia técnica), para mantener informados a los sitios de los sucesos actuales, tratar asuntos de seguridad informática más activamente, y mantener contactos con otros equipos de respuesta y agencias. El trabajo del CIAC es asistir a los sitios ( a través de asistencia técnica directa, proporcionar información, o mandando dudas a otros expertos técnicos), servir como centro de aclaración de información sobre amenazas/incidentes conocidos/vulnerabilidades, desarrollar directivas para tratar incidentes, desarrollar software para responder a sucesos/incidentes, analizar sucesos y tendencias, actividades de concienciación y adiestramiento de conductas, y alertar y avisar a los sitios sobre vulnerabilidades y ataques potenciales. El teléfono del CIAC en horario comercial es (415) 422-8193 o FTS 532-8193. La dirección de correo electrónico del CIAC es CIAC@TIGER.LLNL.GOV. .ti 9 3.9.7.3.5 Equipo de Respuesta de Seguridad de Redes Informáticas de NASA Ames .in 12 El Equipo de Respuesta de Seguridad de Redes Informáticas (CNSRT) es la versión local del CERT de DARPA del Centro de investigación de NASA Ames. Formado en Agosto de 1989, el equipo tiene como principal asignación los usuarios de Ames, pero también está implicado en asistir a otros centros de la NASA y agencias federales. El CNSRT mantiene enlaces con el equipo CIAC del DOE y el CERT de DARPA. También es un miembro bajo demanda del sistema CERT. El equipo puede ser localizado a través de un busca 24 horas en (415) 694-0571, o por correo electrónico en CNSRT@AMES.ARC.NASA.GOV. .in 6 3.9.7.4 Boletines de Administración de DDN .in 9 El Boletín de Administración de DDN es distribuido electronicamente por el DDN NIC bajo contrato con la Agencia de Comunicaciones Defensa (DCA). Es una forma de comunicar políticas oficiales, procedimientos y otra información que concierna al personal de administración de instalaciones del DDN. El Boletín de Seguridad de DDN es distribuido electrónicamente por el DDN SCC, también bajo contrato con DCA, como medio de comunicación de información sobre exposiciones de seguridad de servidores y redes, arreglos y lo concerniente al personal de seguridad y administración de las instalaciones del DDN. Cualquiera puede unirse a la lista de distribución de estos dos boletines enviando un mensaje a NIC@NIC.DDN.MIL y solicitando ser incorporado a las listas de correo. Estos mensajes también se envían al grupo de noticias de USENET "ddn.mgt-bulletin". Para más información, lea la sección 8.7. .ti 6 3.9.7.5 Lista de Administración del Sistemas .in 9 La SYSADM-LIST es una lista perteneciente exclusivamente a administración de sistemas UNIX. Los correos para ser agregado a la lista deben dirigirse a SYSADM-LIST-REQUEST@SYSADMIN.COM. .ti 6 3.9.7.6 Listas de Sistemas Específicos de Vendedores .in 9 Las listas SUN-SPOTS y SUN-MANAGERS son grupos de discusión para usuarios y administradores de sistemas suministrados por Sun Microsystems. SUN-SPOTS es una lista general, discute de todo desde configuraciones de hardware a simples preguntas de UNIX. Para subscribirse, envíe un mensaje a SUN-SPOTS-REQUEST@RICE.EDU. Esta lista también está disponible en el foro de noticias de USENET "comp.sys.sun". SUN-MANAGERS es una lista de discusión para administradores de sistemas de Sun y cubre todos los aspectos de administración de un sistema SUN. Para subscribirse, envíe un mensaje a SUN-MANAGERS-REQUEST@EECS.NWU.EDU. La lista APOLLO discute el sistema HP/Apollo y su software. Para subscribirse, envíe un mensaje a APOLLO-REQUEST@UMIX.CC.UMICH.EDU. APOLLO-L es una lista similar a la que se puede subscribir enviando .ti 12 SUB APOLLO-L su nombre completo .in 9 a LISTSERV%UMRVMB.BITNET@VM1.NODAK.EDU. HPMINI-L corresponde a las series 9000 de Hewlett-Packard y el sistema operativo HP/UX. Para subscribirse, envíe .ti 12 SUB HPMINI-L su nombre completo .in 9 a LISTSERV%UAFSYSB.BITNET@VM1.NODAK.EDU. INFO-IBMPC discute sobre PCs de IBM y compatibles, así como de MS-DOS. Para subscribirse, envíe una nota a INFO-IBMPC-REQUEST@WSMR-SIMTEL20.ARMY.MIL. Hay muchas otras listas de correo para, casi, cada ordenador o estación de trabajo popular. Para una lista completa, obtenga el archivo "netinfo/interest-groups" a través de FTP anónimo del servidor FTP.NISC.SRI.COM. .ti 6 3.9.7.7 Sociedades y Diarios Profesionales .in 9 La Comisión Técnica del IEEE sobre Seguridad e Intimidad publica una revista trimestral, "CIPHER". .in 12 IEEE Computer Society, 1730 Massachusetts Ave. N.W. Washington, DC 2036-1903 .in 9 El ACM SigSAC (Grupo con Interés Especial sobre Seguridad, Auditoría, y Controles) publica una revista trimestral, "SIGSAC Review". .in 12 Association for Computing Machinery 11 West 42nd St. New York, N.Y. 10036 .in 9 La Asociación de Seguridad de Sistemas de Información publica una revista trimestral llamada "ISSA Access". .in 12 Information Systems Security Association P.O. Box 9457 Newport Beach, CA 92658 .in 9 "Computers and Security" es una "publicación internacional para los profesionales involucrados en seguridad informática, auditoría y control, e integridad de datos." .in 12 $266/año, 8 publicaciones (1990) Elsevier Advanced Technology Journal Information Center 655 Avenue of the Americas New York, NY 10010 .in 9 La "Data Security Letter" se publica para "ayudar a los profesionales en seguridad de datos proporcionando información y análisis especialista en desarrollos en seguridad informática y de comunicaciones." .in 12 $690/año, 9 publicaciones (1990) Data Security Letter P.O. Box 1593 Palo Alto, CA 94302 .ti 3 3.9.8 Herramientas de Informe de Problemas .ti 6 3.9.8.1 Auditoría .in 9 La auditoría es una herramienta importante que se puede usar para reforzar la seguridad de su instalación. No solo le proporciona una forma de identificar quién ha accedido a su sistema (y puede haberle hecho algo) sino que también le da una indicación de como está siendo usado (o abusado) por usuarios autorizados y atacantes por igual. Además, el seguimiento de auditoría guardado normalmente por sistemas informáticos puede llegar a ser una inapreciable prueba si se penetrase en su sistema. .ti 9 3.9.8.1.1 Verificación de Seguridad .in 12 Una seguimiento de auditoría muestra como se usa el sistema día a día. Dependiendo de como esté configurado el registro de auditoría de su sitio, sus archivos de registro deberían mostrar un registro de acceso que puede mostrar lo que parece un uso normal del sistema. Una desviación del uso normal podría ser el resultado de una penetración de una fuente del exterior usando una cuenta de usuario antigua o dejada de usar. Observar una desviación en las entradas al sistema, por ejemplo, puede ser la primera indicación de que está sucediendo algo inusual. .ti 9 3.9.8.1.2 Verificar Configuraciones de Software .in 12 Una de los tretas usadas por atacantes para conseguir acceso a un sistema es la inserción de un programa denominado Caballo de Troya. Un Caballo de Troya puede ser un programa que hace algo útil, o simplemente algo interesante. Siempre hace algo inesperado, como robar contraseñas o copiar archivos sin su conocimiento [25]. Imagine un programa Troyano de entrada al sistema que solicite nombre de usuario y contraseña de manera normal, pero además escriba esa información en un archivo especial que el atacante puede recuperar y leer en el futuro. Imagine un programa Troyano editor que, a pesar de los permisos de archivo que ha dado a sus archivos, haga copias de todo en su espacio de directorio sin que usted lo sepa. Esto señala la necesidad de administrar la configuración del software que se ejecuta en un sistema, no como está siendo desarrollado, sino como funciona en realidad. Técnicas para realizar este alcance de testear cada comando cada vez que es ejecutado con algún criterio (tales como una firma cifrada, descrito más arriba) o meramente comprobar la fecha y la hora marcada del ejecutable. Otra técnica puede ser comprobar cada comando a modo de lotes a medianoche. .ti 6 3.9.8.2 Herramientas .in 9 COPS es una herramienta de seguridad para administradores del sistema que comprueba numerosos problemas de seguridad comunes en sistemas UNIX [27]. COPS es una colección de scripts de shell y programas en C que se pueden ejecutar facilmente en casi todas las variantes de UNIX. Entre otras cosas, comprueba lo siguiente y envía los resultados al administrador del sistema: .in 14 .ti 12 - Comprueba "/dev/kmem" y otros dispositivos legibles y escribibles por todo el mundo. .in 14 .ti 12 - Comprueba archivos y directorios importantes o especiales buscando modos "malos" (escribible por todo el mundo, etc.). .in 14 .ti 12 - Busca contraseñas que se adivinen facilmente. .in 14 .ti 12 - Busca identificaciones de usuarios duplicadas, campos inválidos en el archivo de contraseñas, etc.. .in 14 .ti 12 - Busca identificaciones de grupos duplicadas, campos inválidos en el archivo de grupo, etc.. .in 14 .ti 12 - Busca problemas de seguridad en los directorios home de todos los usuarios y sus archivos ".cshrc", ".login", ".profile", y ".rhosts". .in 14 .ti 12 - Comprueba todos los comandos en los archivos "/etc/rc" y en los archivos de "cron" escribibles por todo el mundo. .in 14 .ti 12 - Comprueba malas rutas "raíz", sistemas de archivos NFS exportados al mundo, etc.. .in 14 .ti 12 - Incluye un sistema experto que prueba a ver si un usuario dado (normalmente "root") puede ser comprometido, dado que ciertas reglas son ciertas. .in 14 .ti 12 - Busca cambios en la condición setuid de programas en el sistema. .in 9 El paquete COPS está disponible en los archivos de "comp.sources.unix" en "ftp.uu.net", y también del repositorio UNIX-SW en el servidor "wsmr-simtel20.army.mil" de MILNET. .ti 3 3.9.9 Comunicación Entre Administradores .ti 6 3.9.9.1 Sistemas Operativos Seguros .in 9 La siguiente lista de productos y vendedores está adaptada a la Lista de Productos Evaluados del Centro Nacional de Seguridad Informática (NCSC). Muestra esas compañías que han recibido alguna evaluación del NCSC o están en proceso de evaluación de un producto. Esta lista no está completa pero es representativa de esos sistemas operativos y componentes añadidos disponibles en comercios. Para un listado más detallado de los productos actuales que aparecen en la NCSC EPL, contacte con el NCSC en: .in 12 National Computer Security Center 9800 Savage Road Fort George G. Meade, MD 20755-6000 (301) 859-4458 .bp Versión Clase de Producto Evaluado Vendedor Evaluada Evaluación ----------------------------------------------------------------------- Secure Communications Honeywell Information 2.1 A1 Processor (SCOMP) Systems, Inc. Multics Honeywell Information MR11.0 B2 Systems, Inc. System V/MLS 1.1.2 on UNIX AT&T 1.1.2 B1 System V 3.1.1 on AT&T 3B2/500and 3B2/600 OS 1100 Unisys Corp. Security B1 Release 1 MPE V/E Hewlett-Packard Computer G.03.04 C2 Systems Division AOS/VS on MV/ECLIPSE series Data General Corp. 7.60 C2 VM/SP or VM/SP HPO with CMS, IBM Corp. 5 C2 RACF, DIRMAINT, VMTAPE-MS, ISPF MVS/XA with RACF IBM Corp. 2.2,2.3 C2 AX/VMS Digital Equipment Corp. 4.3 C2 NOS Control Data Corp. NOS Security C2 Eval Product TOP SECRET CGA Software Products 3.0/163 C2 Group, Inc. Access Control Facility 2 SKK, Inc. 3.1.3 C2 UTX/32S Gould, Inc. Computer 1.0 C2 Systems Division A Series MCP/AS with Unisys Corp. 3.7 C2 InfoGuard Security Enhancements Primos Prime Computer, Inc. 21.0.1DODC2A C2 Resource Access Control IBM Corp. 1.5 C1 Facility (RACF) .bp Versión Clase de Producto Evaluado Vendedor Evaluada Evaluación ----------------------------------------------------------------------- Boeing MLS LAN Boeing Aerospace A1 M1 Trusted XENIX Trusted Information Systems, Inc. B2 VSLAN VERDIX Corp. B2 System V/MLS AT&T B1 VM/SP with RACF IBM Corp. 5/1.8.2 C2 Wang SVS/OS with CAP Wang Laboratories, Inc. 1.0 C2 .ti 6 3.9.9.2 Obtener Arreglos a Problemas Conocidos .in 9 No se ha dicho que los sistemas informáticos tienen fallos. Incluso los sistemas operativos, de los cuales dependemos para proteger nuestros datos, tienen fallos. Y ya que hay fallos, se pueden romper cosas, tanto accidental como malintencionadamente. Es importante que cuando se descubra un fallo, se debería identificar un arreglo y ser implementado tan pronto como sea posible. Esto debería minimizar cualquier exposición causada por el fallo en primer lugar. Un corolario al problema del fallo es: ¿de quien obtengo los arreglos? La mayoría de los sistemas tienen algún soporte del fabricante o suministrador. Los arreglos que vienen de esas fuentes tienden a ser implementados rapidamente después de ser recibidos. Los arreglos para algunos problemas a veces son puestas en la red y se les deja a los administradores para incorporarlas como puedan. El problema es que uno quiere tener confianza en que el arreglo cerrará el agujero y no introducirá otros. Tenderemos a confiar en que los arreglos de los fabricantes son mejores que los puestos en las red. .ti 6 3.9.9.3 Sistema de Aviso al Cliente de Sun .in 9 Sun Microsystems ha establecido un Sistema de Aviso al Cliente (CWS) para tratar incidentes de seguridad. Este es un proceso formal que incluye: .in 14 .ti 12 - Tener un punto de contacto en Sun bien anunciado para informar de problemas de seguridad. .in 14 .ti 12 - Alertar pro-activamente a los clientes de gusanos, virus, u otros agujeros de seguridad que puedan afectar a sus sistemas. .in 14 .ti 12 - Distribuir el parche (o trabajos similares) tan rapidamente como sea posible. .in 9 Han creado una dirección de correo electrónico, SECURITY-ALERT@SUN.COM, que posibilitará a los clientes informar de problemas de seguridad. Una copia de seguridad de buzón de voz está disponible en el (415) 688-9081. Se puede designar un "Contacto de Seguridad" por cada sitio cliente; Sun contactará con esta persona en caso de algún nuevo problema de seguridad. Para más información contacte con su representante de Sun. .ti 6 3.9.9.4 Servidores de Archivos Confiables .in 9 Varios sitios en Internet mantienen un gran repositorio de software de dominio público y libremente distribuible, y hacen este material disponible a través de FTP anónimo. Esta sección describe algunos de los repositorios más grandes. Dese cuente de que ninguno de estos servidores implementa sumas de control de seguridad ni ninguna otra garantía de la integridad de sus datos. En consecuencia, la noción de "confianza" debería ser tomada como alguna definición limitada. .ti 9 3.9.9.4.1 Arreglos de Sun en UUNET .in 12 Sun Microsystems ha contratado a Servicios de Comunicaciones UUNET, Inc., para hacer disponibles arreglos a fallos en software de Sun a través de FTP anónimo. Puede acceder a estos arreglos usando el comando "ftp" para conectarse al servidor FTP.UU.NET. Entonces entre en el directorio "sun-dist/security", y obtenga un listado del directorio. El archivo "README" contiene una breve descripción de qué contiene cada archivo de este directorio, y qué se necesita para instalar el arreglo. .ti 9 3.9.9.4.2 Arreglos de Berkeley .in 12 La Universidad de California en Berkeley también tiene disponibles arreglos a través de FTP anónimo; estos arreglos pertenecen principalmente a la liberación actual de UNIX BSD (actualmente, liberación 4.3). Sin embargo, estos arreglos son importantes, incluso si no está ejecutando su software, ya que algunos vendedores (Sun, DEC, Sequent, etc.) basan su software en las liberaciones de Berkeley. Los arreglos de Berkeley están disponibles a través de FTP anónimo en el servidor UCBARPA.BERKELEY.EDU en el directorio "4.3/ucb-fixes". El archivo "INDEX" en este directorio describe qué contiene cada archivo. También están disponibles en UUNET (ver sección 3.9.9.4.3). Berkeley también distribuye versiones nuevas de "sendmail" y "named" desde esta máquina. Las versiones nuevas de estos comandos están almacenadas en el directorio "4.3", normalmente en los archivos "sendmail.tar.Z" y "bind.tar.Z", respectivamente. .ti 9 3.9.9.4.3 Simtel-20 y UUNET .in 12 Los dos grandes repositorios de propósito general en Internet son los servidores WSMR-SIMTEL20.ARMY.MIL y FTP.UU.NET. WSMR-SIMTEL20.ARMY.MIL es una máquina TOPS-20 operada por las Armada de EEUU en White Sands Missile Range (WSMR), Nuevo Mexico. El directorio "pd2:" contiene una gran cantidad de software UNIX, principalmente tomado de los grupos de noticias "comp.sources". Los directorios "pd1:" y "pd2:" contienen software para sistemas PC de IBM, y "pd3:" contiene software para el Macintosh de Apple. FTP.UU.NET está administrada por Servicios de Comunicaciones UUNET, Inc. en Falls Church, Virginia. Esta empresa vende acceso a Internet y USENET a sitios por todo el país (e internacionalmente). El software puesto en los siguientes grupos de noticias fuente de USENET está almacenado aquí, en directorios del mismo nombre: .in 15 comp.sources.games comp.sources.misc comp.sources.sun comp.sources.unix comp.sources.x otras numerosas distribuciones, tales como todo el código fuente libremente distribuible del UNIX de Berkeley, Petición de Comentarios de Internet (RFCs), y demás también están disponibles en este sistema. .ti 9 3.9.9.4.4 Vendedores Algunos vendedores hacen disponibles electrónicamente arreglos para fallos en su software, o a través de listas de correo o de FTP anónimo. Usted debería contactar con su vendedor para averiguar si ofrece este servicio, y si es así, cómo acceder a él. Algunos vendedores que ofrecen estos servicios son Sun Microsystems (ver más arriba), Digital Equipment Corporation (DEC