.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), la Universidad de California en Berkeley (ver más arriba), y Apple Computer [5, CURRY]. .bp .ti 0 4. Tipos de Procedimientos de Seguridad .ti 0 4.1 Revisar los Sistemas de Seguridad .in 3 La mayoría de los negocios llevan algún tipo de revisión financiera anual como una parte regular de su vida comercial. Las revisiones de seguridad son una parte importante a llevar a cabo en cualquier entorno de computación. Parte de la revisión de la seguridad debería ser una revisión de algunas políticas que conciernan al sistema de seguridad, así como los mecanismos para llevarlos a cabo. .ti 3 4.1.1 Organizar Entrenamientos Programados .in 6 Aunque no es algo que se deba hacer cada día o semana, los entrenamientos programados se pueden realizar para determinar si los procedimientos definidos son adecuados para que la amenaza sea contrarrestada. Si su mayor amenaza es un desastre natural, entonces se llevaría a cabo un entrenamiento para verificar sus mecanismos de copia de seguridad y restauración. Por otra parte, si su mayor amenaza es de intrusos externos intentando introducirse en su sistema, se podría realizar un entrenamiento para intentar una penetración real y observar el efecto de las políticas. Los entrenamientos son una forma valiosa de probar si sus políticas y procedimientos son efectivos. Por otra parte, pueden requerir mucho tiempo e interrumpir el normal funcionamiento. Es importante sopesar los beneficios de los entrenamientos contra la posible pérdida de tiempo que pueden conllevar. .ti 3 4.1.2 Probar los Procedimientos .in 6 Si ha elegido no utilizar entrenamientos programados para examinar todos sus procedimientos de seguridad a la vez, es importante probar los procedimientos individualmente con frecuencia. Examine su procedimiento de copia de seguridad para asegurarse de que puede recuperar los datos de las cintas. Compruebe los archivos de registro para asegurarse de que la información que se supone que es registrada está siendo registrada en ellos, etc.. Cuando se manda probar la seguridad, se debería poner mucho cuidado en idear pruebas de la política de seguridad. Es importante identificar claramente qué se está probando, como se llevará a cabo la prueba, y qué resultados se esperan de la prueba. Todo esto debería estar documentado e incluido en la propia política de seguridad o en un documento adjunto. Es importante probar todos los aspectos de la política de seguridad, tanto de procedimental como automática, con un énfasis especial en los mecanismos automatizados usados para llevar a cabo la política. Las pruebas deberían estar definidas para asegurar un examen exhaustivo de las características de la política, esto es, si se ha definido una prueba para examinar el proceso de entrada al sistema del usuario, se debería declarar explicitamente que se pueden usar tanto nombres de usuario y contraseñas válidos con inválidos para demostrar el correcto funcionamiento del programa de entrada al sistema. Tenga en mente que hay un límite de pruebas razonables. El propósito de hacer una prueba es asegurarse de que la política de seguridad se lleva acabo correctamente, y no "probar" la perfección del sistema o la política. El objetivo debería ser obtener alguna seguridad de que los controles razonables y verosímiles impuestos por su política son adecuados. .ti 0 4.2 Procedimientos de Gestión de Cuentas .in 3 Los procedimientos de gestión de cuentas son importantes para prevenir el acceso no autorizado a su sistema. Es necesario decidir varias cosas: ¿Quien puede tener una cuenta en el sistema? ¿Cuanto tiempo puede alguien tener una cuenta sin renovar su petición? ¿Como se deberían eliminar las cuentas antiguas del sistema? Las respuestas a todas estas preguntas deberían estar ubicadas en la política. Además decidir quién puede usar un sistema puede ser importante para determinar para qué puede usar el sistema cada usuario (si está permitido el uso personal, por ejemplo). Si está conectado a una red exterior, la gestión de su sitio o red puede tener reglas sobre para qué puede ser usada la red. Por eso, es importante para cualquier política de seguridad definir un procedimiento de gestión de cuentas adecuado tanto para administradores como para usuarios. Normalmente, el administrador del sistema sería responsable de crear y borrar las cuentas de usuario y mantener un control sobre el uso de todo en general. En algún grado, la gestión de cuentas también es responsabilidad de cada usuario del sistema en el sentido de que cada usuario debería observar cualquier mensaje y suceso del sistema que pueda indicar una violación de la política. Por ejemplo, un mensaje al entrar al sistema que indique la fecha y hora de la última entrada al sistema, el usuario debería comprobar si indica una hora razonable de la última entrada al sistema. .ti 0 4.3 Procedimientos de Gestión de Contraseñas .in 3 Una política sobre gestión de contraseñas puede ser importante si su sitio desea el uso de contraseñas seguras. Estos procedimientos pueden variar de pedir o forzar a los usuarios a cambiar sus contraseñas ocasionalmente a intentar activamente romper las contraseñas de los usuarios e informar entonces a los usuarios de lo sencillo que es hacerlo. Otra parte de la política de gestión de contraseñas cubre quién puede distribuir contraseñas - ¿Pueden los usuarios dar sus contraseñas a otros usuarios? La sección 2.3 discute algunos de estos asuntos de la política que necesitan ser decididos para una gestión de contraseñas apropiada. Independientemente de las políticas, los procedimientos de gestión de contraseñas necesitan ser configurados cuidadosamente para evitar dejar al descubierto contraseñas. La elección de las contraseñas iniciales para las cuentas es crítica. En algunos casos, los usuarios pueden no entrar nunca al sistema para activar una cuenta; de esta manera, la elección de la contraseña inicial no debería ser estimada facilmente. No se deberían asignar nunca contraseñas por defecto a las cuentas: siempre cree una nueva contraseña para cada usuario. Si hay impresa alguna lista de contraseñas, deberían estar guardadas en un sitio sin conexión en lugares seguros; mejor todavía, no haga listas de contraseñas. .ti 3 4.3.1 Elección de Contraseña .in 6 La parte casi más vulnerable de un sistema informático es la contraseña de la cuenta. Cualquier sistema informático, no importa como se seguro sea contra ataques desde redes o por conexión telefónica, caballos de Troya y demás, puede ser totalmente explotado por un intruso si el o ella puede conseguir acceso a través de una contraseña pobremente elegida. Es importante elegir un buen conjunto de reglas para la elección de contraseñas, y distribuir estas reglas a todos los usuarios. Si es posible, el software que configura las contraseñas de los usuarios se debería modificar para levar a cabo cuantas reglas sea posible. Aquí se muestra un conjunto simple de directrices para elegir contraseñas: .in 11 .ti 9 - NO use su nombre usuario de ninguna manera (según está, invertido, en mayúsculas, poniéndolo dos veces, etc.). .in 11 .ti 9 - NO use su nombre o apellidos de ninguna manera. .in 11 .ti 9 - NO use el nombre de su cónyuge o de sus hijos. .in 11 .ti 9 - NO use otra información sobre usted que se pueda obtener facilmente. Esto incluye números de matrícula, números de teléfono, números de la seguridad social, la marca de su coche, el nombre de la calle donde vive, etc.. .in 11 .ti 9 - NO use una contraseña de todo dígitos, o todo la misma letra. .in 11 .ti 9 - NO use una palabra contenida en Inglés o diccionarios de lenguas extranjeras, listas ortográficas, u otras listas de palabras. .in 11 .ti 9 - NO use una contraseña con menos de seis caracteres. .in 11 .ti 9 - Use una contraseña con mayúsculas y minúsculas mezcladas. .in 11 .ti 9 - Use una contraseña con caracteres no alfabéticos (números o signos de puntuación). .in 11 .ti 9 - Use una contraseña que sea fácil de recordar, así no tendrá que anotarla. .in 11 .ti 9 - Use una contraseña que pueda escribir rapidamente, sin tener que mirar al teclado. .in 6 Unos métodos de elegir una contraseña que se acoja a estas directrices incluyen: .in 11 .ti 9 - Elegir una linea o dos de una canción o poesía, y usar la primera letra de cada palabra. .in 11 .ti 9 - Alternar entre una consonante y una o dos vocales, más de siete u ocho caracteres. Esto proporciona palabras sin sentido que normalmente son pronunciables, y así facilmente recordables. .in 11 .ti 9 - Elija dos palabras cortas y únalas con un signo de puntuación entre ellas. Se les debería decir a los usuarios que cambien su contraseña periodicamente, normalmente entre cada tres y seis meses. Esto asegura que un intruso que haya adivinado una contraseña perderá el acceso de forma eventual, así como invalidar cualquier lista de contraseñas que pueda haber obtenido. Algunos sistemas permiten al administrador del sistema forzar a los usuarios a cambiar sus contraseñas tras un período de tiempo; si su sistema tiene soporte para este software debería activarlo [5, CURRY]. Algunos sistemas proporcionan software que fuerza a los usuarios a cambiar sus contraseñas en base a unas reglas. Algunos de estos sistemas también incluyen generadores de contraseñas que proporcionan al usuario un conjunto entre las que elegir. No se le permite al usuario inventar su propia contraseña. Hay argumentos tanto a favor como en contra de sistemas como estos. Por una parte, usando un generador de contraseñas, se previene a los usuarios de elegir contraseñas inseguras. Por otro lado, a menos que el generador sea bueno haciendo contraseñas fáciles de recordar, los usuarios empezarán a anotarlas para recordarlas. .ti 3 4.3.2 Procedimientos para Cambiar Contraseñas .in 6 Como se manejen los cambios de contraseña es importante para mantener contraseñas seguras. Idealmente, los usuarios deberían poder cambiar sus contraseñas en linea. (Dese cuenta que los programas para cambiar contraseñas son uno de los objetivos favoritos de los intrusos. Mire la sección 4.4 sobre gestión de configuración para más información.) Sin embargo, hay casos excepcionales en los que debería ser tratado cuidadosamente. Los usuarios pueden olvidar sus contraseñas y no poder entrar al sistema. El procedimiento estándar es asignar al usuario una contraseña nueva. Se debería tener cuidado de asegurarse de que es la persona real la que está pidiendo el cambio y obtiene la nueva contraseña. Un truco muy usado por los intrusos es llamar o mandar un mensaje al administrador del sistema y pedirle una nueva contraseña. Se debería usar alguna forma de verificación externa antes de asignar la contraseña. En algunos sitios, se les pide a los usuarios presentarse en persona con identificación. También hay ocasiones en que se necesita cambiar las contraseñas. Si un sistema es comprometido por un intruso, el intruso tendría la capacidad de poder robar un archivo de contraseñas y llevárselo del sistema. Bajo estas circunstancias, un curso de acción es cambiar todas las contraseñas del sistema. Su sitio debería tener procedimientos de como hacer esto rápida y eficientemente. Qué curso elija puede depender de la urgencia del problema. En el caso de un ataque conocido con daños, puede elegir desactivar de forma forzosa todas las cuentas y asignar nuevas contraseñas a los usuarios antes de que vuelvan a introducirse en el sistema. En algunos sitios, a los usuarios se les envía un mensaje diciéndoles que deberían cambiar sus contraseñas, quizá dentro de un cierto período de tiempo. Si no se cambia la contraseña antes de que expire el período de tiempo, se bloquea la cuenta. Los usuarios deberían conocer cual es el procedimiento estándar cuando ha ocurrido un suceso de seguridad. Un engaño bien conocido informado por el Computer Emergency Response Team (CERT) conlleva enviar mensajes a los usuarios, supuestamente de los administradores del sistema local, pidiéndoles cambiar inmediatamente sus contraseñas a una nueva proporcionada en el mensaje [24]. Estos mensajes no eran de los administradores, sino de intrusos intentado robar cuentas. Los usuarios deberían estar alerta para avisar inmediatamente a los administradores del sitio de cualquier petición sospechosa como esta. .ti 0 4.4 Procedimientos de Gestión de Configuración .in 3 La gestión de configuración normalmente se aplica en el proceso de desarrollo de software. Sin embargo, también es aplicable naturalmente en un sentido operativo. Considere que ya que algunos de los programas del nivel de sistema pretenden llevar a cabo la política de seguridad, es importante que estos sean "considerados" como correctos. Eso es, uno no debería permitir que se cambien arbitrariamente programas del nivel de sistema (tales como el sistema operativo, etc.). Como mínimo, los procedimientos deberían declarar quien está autorizado a hacer cambios al sistema, bajo que circunstancias y como se deberían documentar los cambios. En algunos entornos, se desea que la administración de configuración también sea aplicada a la configuración física del equipo. Se le debería dar la debida consideración en su política de seguridad a mantener una configuración de hardware válida y autorizada. .ti 3 4.4.1 Configuraciones No Estándar .in 6 Ocasionalmente, puede ser beneficioso tener una configuración ligeramente no estándar a fin de frustrar los ataques "estándar" usados por algunos intrusos. Las partes no estándar de la configuración pueden incluir diferentes algoritmos de cifrado de contraseñas, diferentes localizaciones de los archivos de configuración y comandos del sistema de reescritura limitada o funcionalmente limitados. Las configuraciones no estándar, sin embargo, también tienen sus inconvenientes. Al cambiar el sistema "estándar", estas modificaciones pueden hacer más difícil el mantenimiento del software por requerir escribir documentación extra, modificar el software después de actualizar el sistema operativo y, normalmente, alguien con un conocimiento especial de los cambios. Debido a los inconvenientes de las configuraciones no estándar, a veces solo son usadas en un entorno con una máquina "cortafuegos" (ver sección 3.9.1). La máquina cortafuegos es modificada de manera no estándar dado que es susceptible de ataque, mientras que los sistemas internos tras el cortafuegos se dejan en sus configuraciones estándar. .ti 0 5. Tratar Incidentes .ti 0 5.1 Visión Global .in 3 Esta sección del documento proporcionará alguna guía para aplicarse cuando se está produciendo un suceso de seguridad informática en una máquina, red, sitio, o entorno multisitio. La filosofía de trabajo en el caso de una brecha de seguridad informática, ya sea un ataque externo de un intruso o un empleado descontento, es hacer un plan contra sucesos adversos en el futuro. No hay sustituto a crear planes de contingencia para los tipos de ataque descritos más arriba. La seguridad informática tradicional, mientras da bastante importancia en todo lo referente al plan de seguridad del sitio, normalmente falla excesivamente en proteger los sistemas de ataques, y posiblemente en monitorizar sistemas para detectar ataques. La poca atención se paga a menudo en como tratar en realidad el ataque cuando ocurre. El resultado es que cuando se está produciendo un ataque, se toman algunas decisiones deprisa y puede ser perjudicial para rastrear la fuente del incidente, recolectar pruebas para ser usadas en trabajos de persecución, preparar la restauración del sistema, y proteger los datos valiosos contenidos en el sistema. .ti 3 5.1.1 Tener un Plan a Seguir en Caso de Incidente .in 6 Parte de tratar un incidente se prepara antes de que ocurra. Esto incluye establecer un nivel de protecciones adecuado, de forma que si el incidente llegase a ser importante, el daño que pueda ocasionar sea limitado. La protección incluye preparar directivas de tratamiento de incidentes o un plan de contingencia de respuesta para su sitio u organización. Haber escrito planes elimina mucha de la ambigüedad que aparece durante un incidente, y llevará a un conjunto de acciones más apropiadas y meticulosas. Segundo, parte de la protección es preparar un método de notificación, de manera que sepa a quien llamar y los números de teléfono importantes. Es importante, por ejemplo, llevar a cabo "simulacros", en los que su personal de seguridad informática, administradores del sistema y gestores simulen tratar un incidente. Es importante aprender a responder eficientemente ante un incidente por numerosas razones. El beneficio más importante es directamente para seres humanos--prevenir la pérdida de vidas humanas. Algunos sistemas informáticos son sistemas vitales críticos, sistemas de los que dependen vidas humanas (p.ej., controlando algún aspecto de soporte vital en un hospital o ayudando a los controladores aéreos). Un beneficio importante, pero a veces pasado por alto es económico. Tener personal técnico y administrativo para que responda a un incidente requiere de considerables recursos, recursos que podrían ser utilizados más beneficiosamente si un incidente no requiere de sus servicios. Si este personal está entrenado para tratar un incidente eficientemente, necesitarán menos tiempo para tratar el incidente. Un tercer beneficio es proteger información clasificada, sensible o privada. Uno de los mayores peligros de un incidente de seguridad informática es que la información puede ser irrecuperable. El tratamiento eficiente del incidente minimiza este peligro. Cuando está involucrada información clasificada, se pueden aplicar otras regulaciones gubernamentales y deben ser introducidas en cualquier plan para tratar incidentes. Un cuarto beneficio está relacionado con las relaciones públicas. Las noticias sobre incidentes de seguridad informáticas tienden a ser dañinas para la categoría de una organización entre clientes actuales y potenciales. El tratamiento eficiente de incidentes minimiza el potencial de publicidad negativa. Un beneficio final del tratamiento eficiente de incidentes está relacionado con asuntos legales. Es posible que en un futuro cercano las organizaciones puedan ser demandadas porque uno de sus nodos fuese utilizado para lanzar un ataque a una red. De forma similar, la gente que desarrolla parches o trabajos similares puedan ser demandados si los parches o trabajos similares son inefectivos, resultan en perjuicio de los sistemas o si los parches o trabajos similares en sí mismos dañan los sistemas. Es crítico conocer las vulnerabilidades del sistema operativo y pautas de ataque y entonces tomar las medidas apropiadas,para evitar posibles problemas legales. .in 11 .ti 3 5.1.2 El Orden de Discusión en esta Sesión Sugiere la Ordenación de un Plan .in 6 Este capítulo está organizado de forma que se pueda hacer una lista de la Tabla de Contenidos para proporcionar un punto de partida y crear una política para el tratamiento de incidentes en adelante. Los puntos principales que se incluyen en una política para tratar incidentes son: .in 11 .ti 9 o Visión General (cuales son las metas y objetivos al tratar el incidente). .ti 9 o Evaluación (la importancia del incidente). .ti 9 o Notificación (a quién se le debería informar del incidente). .ti 9 o Respuesta (cual debería ser la respuesta ante el incidente). .ti 9 o Legal/Investigativo (cuales son las implicaciones legales y procesales del incidente). .ti 9 o Registros de documentación (qué registros se deberían guardar de antes, durante y después del incidente). .in 6 Cada uno de estos puntos es importante en un plan total para tratar incidentes. El resto de este capítulo detallará los asuntos que conllevan cada uno de estos temas, y proporciona alguna orientación como qué se debería incluir en una política de un sitio para tratar incidentes. .in 13 .ti 6 5.1.3 Posibles Metas e Incentivos para un Eficiente Tratamiento de Incidentes Como en cualquier conjunto de procedimientos preplaneados, se debe tomar un conjunto de metas a conseguir al tratar de un incidente. Estas metas tendrán distinto orden de importancia dependiendo del sitio, pero un conjunto de metas podría ser: .in 9 Asegurar la integridad de los sistemas críticos (vitales). Mantener y restaurar datos. Mantener y restaurar servicios. Entender como sucedió. Prevenir incidentes mayores y supletorios. Prevenir la publicidad negativa. Buscar quién lo hizo. Castigar a los atacantes. .in 6 Es importante priorizar bien las acciones que tendrán lugar durante un incidente antes del momento en que ocurra. A veces un incidente puede ser tan complejo que es imposible hacer todo a la vez para reaccionar; las prioridades son esenciales. Aunque las prioridades variarán de una institución a otra, las siguientes prioridades sugeridas sisen como punto de partida para definir la respuesta de una organización: .in 11 .ti 9 o Prioridad uno -- proteger las vidas humanas y la seguridad de la gente; la vida humana siempre tiene preferencia sobre todas las demás consideraciones. .in 11 .ti 9 o Prioridad dos -- proteger datos clasificados y/o sensibles (como regulados por su sitio o por regulaciones gubernamentales). .in 11 .ti 9 o Prioridad tres -- proteger otros datos, incluyendo privados, científicos, administrativos y otros datos, porque en términos de recursos la pérdida de datos es costosa. .in 11 .ti 9 o Prioridad cuatro -- prevenir daños a sistemas (p.ea., pérdida o alteración de archivos del sistema, daño a dispositivos de disco, etc.); el daño a sistemas puede resultar una costosa pérdida de tiempo y recuperación. .in 11 .ti 9 o Prioridad cinco -- minimizar el destrozo de recursos informáticos; es mejor apagar o desconectar de la red un sistema que arriesgarse a dañar datos o sistemas. .in 6 Una implicación importante para definir prioridades es que una vez se han manejado la seguridad nacional y de las vidas humanas, generalmente es más importante salvar datos que hardware y software del sistema. Aunque lo deseable sería no tener ninguna pérdida ni daño durante un incidente, los sistemas se pueden reemplazar; la pérdida o compromiso de datos (especialmente información clasificada), sin embargo, normalmente no es un resultado aceptable bajo ninguna circunstancia. Parte del tratamiento de un incidente es prepararse para responder antes de que ocurra. Esto incluye establecer un nivel de protecciones apropiado de forma que si el incidente llegase a ser importante, el daño que pueda ocasionar sea limitado. La protección incluye preparar directrices para tratar incidentes o planes de contingencia para su organización o sitio. Los planes escritos eliminan gran parte de la ambigüedad que tiene lugar durante un incidente, y llevará a un conjunto de respuestas más minuciosas y apropiadas. Segundo, parte de la protección es preparar un método de notificación de forma que sepa a quién llamar y como contactar con ellos. Por ejemplo, cada miembro del Equipo CIAC del Departamento de Energía lleva una tarjeta con los teléfonos de casa y del trabajo de cada uno de los otros miembros, así como números de buscapersonas. Tercero, su organización o sitio debería establecer procedimientos de copia de seguridad para cada máquina y sistema. Tener copias de seguridad elimina gran parte de la amenaza de incluso un incidente importante, ya que las copias de seguridad excluyen pérdidas importantes de datos. Cuarto, usted debería configurar la seguridad de los sistemas. Esto conlleva eliminar vulnerabilidades, establecer una política de contraseñas efectiva y otros procedimientos, que serán explicados más tarde en este documento. Finalmente, llevar a cabo actividades de entrenamiento es parte de la protección. Es importante, por ejemplo, llevar a cabo "simulacros", en los que su personal de seguridad informática, administradores del sistema y gestores simulen el tratamiento de un incidente. .ti 3 5.1.4 Proporcionar Guía de Políticas y Regulaciones Locales .in 6 Cualquier plan para responder a incidentes de seguridad debería seguir políticas y regulaciones locales. Los sitios gubernamentales y privados que tratan material clasificado tienen reglas específicas que deben seguir. Las políticas que haga su sitio sobre como responder a incidentes (como se ha discutido en las secciones 2.5 y 2.5) darán forma a su respuesta. Por ejemplo, puede tener poco sentido crear mecanismos para monitorizar y perseguir intrusos si no hay un plan a seguir en caso de que sean capturados. Otras organizaciones pueden tener políticas que afecten a sus planes. Las compañías telefónicas a veces liberan información sobre seguimientos telefónicos solo a agencias de seguridad gubernamentales. La sección 5.5 también denota que si se planea una acción legal, hay directrices específicas que se deben seguir para asegurarse de que cualquier información recogida puede ser usada como prueba. .ti 0 5.2 Evaluación .ti 3 5.2.1 ¿Es Real? .in 6 Este estado conlleva determinar el problema exacto. Por supuesto algunos, sino la mayoría, de los signos a veces asociados con infecciones de virus, intrusiones en el sistema, etc.., simplemente son anomalías tales como fallos del hardware. Para ayudar a identificar si de verdad hay un incidente, normalmente es útil obtener y usar algún software de detección que pueda estar disponible. Por ejemplo, hay paquetes de software que pueden ayudar mucho a cualquiera que crea que puede haber un virus en un ordenador Macintosh. La información de auditoría también es extremadamente útil, especialmente para determinar si hay un ataque en la red. Es extremadamente importante obtener una instantánea del sistema tan pronto como uno sospeche que algo va mal. Algunos incidentes producen una cadena de sucesos, y una instantánea inicial del sistema puede ayudar más a identificar el problema y cualquier fuente de ataque que la mayoría de las demás que se pueden llevar a cabo en esta fase. Finalmente, es importante iniciar un libro de registros. Registrar los sucesos del sistema, conversaciones telefónicas, registros de tiempo, etc., pueden llevar a una identificación del problema más rápida y sistemática, y es la base para los estados subsiguientes de tratamiento de incidentes. Hay ciertas indicaciones o "síntomas" de un incidente que merecen especial atención: .ti 9 o Caídas del sistema. .in 11 .ti 9 o Cuentas de usuario nuevas (p.ej, la cuenta RUMPLESTILTSKIN ha sido creada inexplicablemente), o mucha actividad en una cuenta que no ha tenido virtualmente ninguna actividad durante meses. .ti 9 o Archivos nuevos (normalmente con nombres nuevos o extraños, tales como data.xx o k). .ti 9 o Discrepancias de cuentas (p.ej., en un sistema UNIX usted puede darse cuenta de que el archivo de cuenta denominado /usr/admin/lastlog ha encogido, algo que debería hacerle sospechar mucho de que hay un intruso). .ti 9 o Cambios en la longitud o fechas de los archivos Changes (p.ej., un usuario debería sospechar si observa que los archivos .EXE en un ordenador MS DOS inexplicablemente son mayores de 1800 bytes). .ti 9 o Intentos de escribir en el sistema (p.ej., un administrador del sistema se da cuenta de que un usuario con privilegios en un sistema VMS está intentando alterar RIGHTSLIST.DAT). .ti 9 o Modificación o borrado de datos (p.ej., los archivos empiezan a desaparecer). .ti 9 o Denegación de servicio (p.ej., un administrador del sistema y todos los usuarios se llegan a quedar aislados fuera de un sistema UNIX, que ha sido cambiado a modo de un solo usuario). .ti 9 o Inexplicablemente, rendimiento pobre del sistema (p.ej., el tiempo de respuesta del sistema llega a ser inusualmente lento). .ti 9 o Anomalías (p.ej., se muestra "GOTCHA" en un terminal o hay frecuentes "beeps" sin explicación). .ti 9 o Intentos sospechosos (p.ej., hay numerosos intentos de entrada al sistema sin éxito desde otro nodo). .ti 9 o Ojeo sospechoso (p.ej., alguien llega a ser usuario root en un sistema UNIX y accede uno tras otro a los archivo de una cuenta de usuario, tras otra). .in 6 Ninguna de estas indicaciones es una "prueba" absoluta de que está teniendo lugar un incidente, ni normalmente se observan todas estas indicaciones cuando sucede un incidente. Si observa alguna de ellas, sin embargo, es importante sospechar que puede estar ocurriendo un incidente y actúe en consecuencia. No hay una formula para determinar con un 100 por cien de seguridad si está ocurriendo un incidente (una posible excepción: cuando un paquete de detección de virus indica que su máquina tiene el virus nVIR y usted confirma esto examinando los contenidos del recurso nVIR en su ordenador Macintosh, puede estar bastante seguro de que su máquina está infectada). Los mejor en este punto es colaborar con otro personal técnico y de seguridad informática para tomar una decisión en grupo sobre si está ocurriendo un incidente. .ti 3 5.2.2 Alcance .in 6 Junto con la identificación del incidente está la evaluación del alcance e impacto del problema. Es importante identificar correctamente los limites del incidente para tratarlo eficientemente. Además, el impacto de un incidente determinará su prioridad en la asignación de recursos para tratar el suceso. Sin una indicación del alcance e impacto del suceso, es difícil determinar una respuesta adecuada. Para identificar el alcance e impacto, se debería definir un conjunto de criterios adecuados al sitio y al tipo de conexiones disponibles. Algunos de los asuntos son: .in 11 .ti 9 o ¿Es un incidente multisitio? .ti 9 o ¿Algunos de los ordenadores de su sitio están afectados por este incidente? .ti 9 o ¿Está involucrada información sensible? .ti 9 o ¿Cual es el punto de entrada del incidente (red, linea telefónica, terminal local, etc.)? .ti 9 o ¿Está involucrada la prensa? .ti 9 o ¿Cual es el daño potencial del incidente? .ti 9 o ¿Cual es el tiempo estimado para terminar con el incidente? .ti 9 o ¿Qué recursos se podrían necesitar para tratar el incidente? .ti 0 5.3 Formas de Aviso Posibles .in 3 Cuando haya confirmado que está ocurriendo un incidente, se debe notificar al personal apropiado. Quién y cómo se lleva a cabo esta notificación es muy importante para mantener el suceso bajo control tanto desde un punto de vista emocional como técnico. .ti 3 5.3.1 Explicito .in 6 Antes de nada, cualquier notificación a cualquier personal local o externo debe ser explícito. Esto conlleva que cualquier informe (sea un mensaje de correo electrónico, llamada telefónica o fax) proporcione información sobre el incidente que sea clara, concisa y de gran calidad. Cuando usted pida a otros que le ayuden a tratar un suceso, una "cortina de humo" solo dividirá el esfuerzo y creará confusión. Si bien es aconsejable una división del trabajo, ayuda proporcionar información a cada sección sobre qué se está acometiendo en otros trabajos. Esto no solo reducirá la duplicación de esfuerzo, sino que permitirá a la gente que está trabajando en una parte del problema saber donde obtener otra información que les ayudaría a resolver una parte del incidente. .ti 3 5.3.2 Sinceridad .in 6 Otra consideración importante cuando comunique sobre el incidente es estar basado en la sinceridad. Intentar esconder aspectos del incidente proporcionando información falsa o incompleta no solo puede retrasar una solución satisfactoria del incidente, sino que puede empeorar aún más las situación. Esto es cierto especialmente cuando está involucrada la prensa. Cuando está ocurriendo un incidente lo suficientemente importante como para atraer la atención de la prensa, es probable que cualquier información falsa que usted proporcione no sea corroborada por otras fuentes. Esto repercutirá negativamente sobre el sitio y puede crear suficiente recelo entre el sitio y la prensa para dañar las relaciones publicas del sitio. .ti 3 5.3.3 Elección del Lenguaje .in 6 La elección del lenguaje usado cuando se notifique a la gente sobre el incidente puede tener un efecto profundo en la manera en que se recibe la información. Cuando use términos emocionales o inflamatorios, elevará las expectaciones de daño o resultados negativos del incidente. Es importante mantener la calma tanto en las notificaciones escritas como habladas. Otro asunto asociado con la elección del lenguaje es la notificación a personal no técnico o ajeno al sitio. Es importante describir detalladamente el incidente sin indebidos mensajes de alarma o confusión. Aunque es más difícil describir el incidente a un público no técnico, a veces es más importante. Se puede necesitar una descripción no técnica para la administración de un nivel más alto, la prensa o los enlaces de los cuerpos de seguridad. No se puede subestimar la importancia de estas notificaciones y pueden ser la diferencia entre tratar el incidente apropiadamente y escalar a algún nivel de daño superior. .ti 3 5.3.4 Notificación a Individuos .in 11 .ti 9 o Punto de Contacto (POC) (Técnico, Administrativo, Equipos de Respuesta, Investigativo, Legal, Vendedores, Proveedores de Servicio), y que POC es visible a quien. .ti 9 o Comunidad más amplia (usuarios). .ti 9 o Otros sitios que puedan ser afectados. .in 6 Finalmente, está la pregunta de a quien se debería avisar durante y después del incidente. Se necesitan considerar varias clases de individuos en cuestión de avisos. Están el personal técnico, de administración, equipos de respuesta apropiados (tales como CERT o CIAC), cuerpos de seguridad, vendedores, y otros proveedores de servicios. Estos asuntos son importantes para el punto de contacto central, ya que es la persona responsable de la notificación real a otros. (ver sección 5.3.6 para más información). Una lista de gente de cada una de estas categorías es una forma de ganar tiempo para el POC durante el incidente. Es mucho más difícil encontrar una persona apropiada durante un incidente cuando están ocurriendo algunos sucesos de urgencia. Además de la gente responsable de tratar parte del incidente, puede haber otros sitios afectados por el incidente (o quizás simplemente corriendo el riesgo de sufrirlo). Una comunidad de usuarios más amplia también se puede beneficiar de conocer el incidente. A veces, un informe del incidente una vez ha sido finalizado es apropiado para la publicación a la amplia comunidad de usuarios. .ti 3 5.3.5 Relaciones Públicas - Comunicados de Prensa .in 6 Uno de los asuntos más importantes a considerar es cuando, a quién y cuanta información liberar al publico en general a través de la prensa. Cuando se decide este singular asunto hay algunas cosas a tener en cuenta. Primero y antes de nada, si existe un funcionario en relaciones públicas del sitio, es importante usar este funcionario como enlace con la prensa. El funcionario en relaciones públicas está familiarizado con el tipo y vocabulario de la información liberada, y ayudará a asegurar que la imagen del sitio está protegida durante y después del incidente (si es posible). Un funcionario en relaciones publicas tiene la ventaja de que usted se puede comunicar candidamente con ellos, y proporcionar un tampón entre la constante atención de la prensa y la necesidad del POC de mantener el control sobre el incidente. Si no hay disponible un funcionario de relaciones públicas, la información comunicada a la prensa se debe considerar cuidadosamente. Si la información es sensible, puede ser beneficioso proporcionar solo una información mínima o general a la prensa. Es realmente posible que cualquier información proporcionada a la prensa será revisada rápidamente por el causante del incidente. En contra a esta consideración, se discutió más arriba que mentir a la prensa a veces puede volverse en su contra y causar más daño que liberar información sensible. Mientras sea difícil determinar en adelante que nivel de detalle proporcionar a la prensa, algunas directrices a tener en mente son: .in 11 .ti 9 o Mantener el nivel de detalle técnico bajo. Una información detallada sobre el incidente puede proporcionar suficiente información para sucesos copy-cat o incluso mermar la capacidad del sitio para procesar una vez el evento ha terminado. o No hacer especulaciones en declaraciones a la prensa. La especulación de quién está causando el incidente o los motivos es muy probable que sean erróneos y puede causar una visión inflamada del incidente. o Trabajar con profesionales de fuerzas de seguridad para asegurarse de que las pruebas están protegidas. Si se va a hacer un proceso judicial, asegúrese de que las pruebas recogidas no son divulgadas a la prensa. o Intentar no ser forzado a una entrevista con la prensa antes de estar preparado. La prensa popular es famosa por las entrevistas "2am", donde lo que se espera es pillar al entrevistado con la guardia baja y obtener información no disponible de otra manera. o No permitir a la prensa apartar la atención del tratamiento del suceso. Siempre recuerde que el término satisfactorio de un incidente es de primera importancia. .ti 3 5.3.6 ¿Quién Necesita Verse Involucrado? .in 6 Ahora existen un número de equipos de respuesta ante incidentes (IRTs) tales como el CERT y el CIAC. (ver secciones 3.9.7.3.1 y 3.9.7.3.4.) Los equipos existen para alguna agencia gubernamental importante y grandes corporaciones. Si un equipo así está disponible para su sitio, el aviso a este equipo debería ser de primera importancia durante las primeras fases de un incidente. Estos equipos son responsables de coordinar los incidentes de seguridad informática de una gama de sitios y grandes entidades. Incluso si se cree que el incidente está contenido en un solo sitio, es posible que la información disponible a través de un equipo de respuesta pueda ayudar a finalizar el incidente. Al desarrollar una política del sitio para el tratamiento de incidentes, se puede desear crear un equipo de tratamiento de incidentes (IHT), muy parecido a esos equipos que ya existen, que sea responsable de tratar los incidentes de seguridad informática del sitio (u organización). Si se crea un equipo así, es esencial que estén abiertas las lineas de comunicación entre este equipo y los otros IHTs. Una vez un incidente está en marcha, es difícil abrir un diálogo de confianza con otros IHTs si no ha existido antes. .ti 0 5.4 Respuesta Un tema importante todavía sin tocar aquí es como responder a un suceso en realidad. La respuesta a un suceso recaerá en las categorías generales de contención, erradicación, recuperación, y continuación. .ti 3 Contención .ti 6 El propósito de la contención es limitar la extensión de un ataque. Por ejemplo, es importante limitar la extensión del ataque de un gusano en una red tan pronto como sea posible. Una parte esencial de la contención es la toma de decisiones (esto es, determinar si apagar un sistema, desconectarlo de una red, monitorizar la actividad del sistema o de la red, poner trampas, desactivar funciones tales como la transferencia de archivos en un sistema UNIX, etc.). A veces esta decisión es trivial; apagar el sistema si es clasificado o sensible, o ¡si está en peligro información privada! En otros casos, vale la pena arriesgarse a tener algún daño en el sistema si mantener el sistema en pie puede permitirle identificar al intruso. La tercera fase, contención, debería conllevar realizar procedimientos predeterminados. Su organización o sitio debería, por ejemplo, definir los riesgos aceptables al tratar un incidente, y debería suministrar acciones específicas y estrategias acordes. Finalmente, el aviso a las autoridades pertinentes se debería producir durante este fase. .ti 3 Erradicación Una vez se ha detectado un incidente, es importante pensar primero en la contención del incidente. Una vez se ha contenido el incidente, es el momento de erradicar la causa. Puede haber software disponible que le ayude en este trabajo. Por ejemplo, hay disponible software de erradicación para eliminar la mayoría de los virus que infectan los sistemas pequeños. Si se ha creado algún archivo ficticio, el momento de borrarlo es ahora. En el caso de infecciones víricas, es importante borrar y reformatear cualquier disco que contuviese archivos infectados. Finalmente, asegúrese de que todas las copias de seguridad están limpias. Algunos sistemas infectados con virus llegan a ser reinfectados periodicamente simplemente porque la gente no erradica sistematicamente el virus de las copias de seguridad. .ti 3 Recuperación .in 6 Una vez la causa del incidente ha sido erradicada, la fase de de recuperación define la siguiente fase de acción. El objetivo de la recuperación es devolver el sistema a la normalidad. En el caso de un ataque basado en red, es importante instalar parches para cualquier vulnerabilidad del sistema operativo que fuese explotada. .ti 3 Continuación .in 6 Uno de las fases más importantes también es a veces el más omitido---la fase de continuación. Esta fase es importante porque ayuda a aquellos involucrados en el tratamiento del incidente a desarrollar un conjunto de "lecciones aprendidas" (ver sección 6.3) para mejorar futuros comportamientos en tales situaciones. Esta fase también proporciona información que justifica un esfuerzo en seguridad informática de la organización para la gestión, y producción de información que pueden ser esenciales en procedimientos legales. El elemento más importante de la fase siguiente es llevar a cabo un análisis forense. ¿Qué ha sucedido exactamente y en qué momento? ¿Cómo actuó el personal involucrado en tratar el incidente? ¿Qué tipo de información necesitaron rapidamente, y como podrían haberla obtenido tan pronto como fuese posible? ¿En qué debería actuar diferente el personal la próxima vez? Un informe de continuación es valioso porque es una referencia a usar en caso de otro incidente similar. Crear un cronología formal de sucesos (incluyendo registros horarios) también es importante por razones legales. De forma similar, también es importante obtener rapidamente una estimación financiera del daño causado por el incidente en términos de software y archivos, daños de hardware, y costes de mano de obra para restaurar los archivos alterados, reconfigurar los sistemas afectados y lo que eso conlleva. Esta estimación puede llegar a ser la base para la subsiguiente actividad procesal del FBI, la Oficina General de Abogacía de EEUU, etc.. .ti 3 5.4.1 ¿Qué Hará? .in 6 o Restaurar el control. o Relacionar con la política. o ¿Qué nivel de servicio se necesita? o Monitorear la actividad. o Restringir o apagar el sistema. .ti 3 5.4.2 Considerar Designar un "Unico Punto de contacto" .in 6 Cuando un incidente está en marcha, un asunto importante es decidir quién está al cargo de coordinar la actividad de la multitud de jugadores. Un gran error que se puede cometer es tener un número de "puntos de contacto" (POC) que no están llevando a cabo sus esfuerzos juntos. Esto solo añadirá confusión al suceso, y probablemente llevará a una confusión y esfuerzo baldío o inútil. El único punto de contacto puede ser o no la persona "encargada" del incidente. Hay dos papeles distintos a cubrir cuando se decide quién debería ser el punto de contacto y la persona encargada del incidente. La persona encargada tomará decisiones como la interpretación de la política aplicada al suceso. La responsabilidad del tratamiento del suceso recae en esta persona. Por el contrario, el punto de contacto debe coordinar el trabajo de todas las partes involucradas en el tratamiento del suceso. El punto de contacto debería ser una persona con la especialización técnica para coordinar satisfactoriamente el trabajo de los administradores del sistema y usuarios involucrados en monitorizar y reaccionar al ataque. A veces la estructura de administración de un sitio es tal que el administrador de un conjunto de recursos no es una persona tecnicamente competente en vista a tratar los detalles de las operaciones de los ordenadores, pero es el último responsable del uso de estos recursos. Otra función importante del POC es mantener contacto con las fuerzas de seguridad y otras agencias externas (tales como la CIA, DoD (Departamento de Defensa), Ejercito de EEUU, u otros) para asegurarse de que se lleva a cabo la involucración multi-agencia. Finalmente, si se involucra una acción legal en forma de procesamiento, el POC puede hablar por el sitio en la corte. La alternativa es tener múltiples testigos que será difícil coordinar en sentido legal, y debilitarán cualquier caso contra los atacantes. Un único POC también puede ser la única persona encargada de la recolección de pruebas, que mantendrá el número de gente recolectando pruebas al mínimo. Por regla general, cuanto mas gente toca una prueba potencial, lo más seguro es que sea inadmisible en un juicio. La sección siguiente (Legal/Investigativo) proporcionará más detalles a tener en cuenta en este tema. .ti 0 5.5 Legal/Investigativo .ti 3 5.5.1 Establecer Contactos con Agencias de Investigación .in 6 Es importante establecer contactos con agencias de investigación tales como el FBI y el Servicio Secreto tan pronto como sea posible, por varias razones. Al cuerpo de seguridad local y las oficinas de seguridad locales o las organizaciones políticas del campus también se les debería informar cuando sea apropiado. Un primera razón es que una vez se está produciendo un gran ataque, hay poco tiempo para llamar al distinto personal de estas agencias para determinar exactamente quien es el punto de contacto correcto. Otra razón es que es importante cooperar con estas agencias de manera que adopte una buena relación de trabajo, y que estará en concordancia con los procedimientos de trabajo de estas agencias. Conocer por adelantado los procedimientos de trabajo y las expectativas de su punto de contacto es un gran paso en esta dirección. Por ejemplo, es importante recoger pruebas que serán admisibles en un juicio. Si antes no sabe como recolectar pruebas admisibles, sus esfuerzos por recolectar pruebas durante un incidente probablemente sean inútiles para la agencia de investigación con la que trate. Una razón final para establecer contactos tan pronto como sea posible es que es imposible conocer la agencia en concreto que asumirá la jurisdicción de un incidente dado. Hacer contactos y encontrar los canales apropiados en seguida hará que responder a un incidente sea considerablemente más ameno. Si su organización o sitio tiene un consejero legal, usted necesita notificarle, en cuanto lo sepa, que está ocurriendo un incidente. Como mínimo, su consejero legal necesita estar involucrado para proteger los intereses legales y financieros de su sitio u organización. Hay algunos asuntos legales y prácticos, unos pocos de ellos son: .in 12 .ti 9 1. Si su sitio u organización está dispuesto a correr el riesgo de tener publicidad negativa o exponerse a cooperar en procesamientos legales. .ti 9 2. Cauce de Responsabilidades--Si deja un sistema comprometido de forma que esté para poder ser monitoreado y se daña otro ordenador por ataque originado desde su sistema, su sitio u organización puede ser responsable de los daños ocasionados. .ti 9 3. Distribución de información--Si su sitio u organización distribuye información sobre un ataque en el que pueda estar involucrado otro sitio u organización o la vulnerabilidad en un producto que puede afectar a la capacidad de vender ese producto, su sitio u organización puede ser otra vez responsable de algunos daños (incluyendo daños de reputación). .ti 9 4. Responsabilidades debido a monitorizar--Su sitio u organización puede ser demandado si los usuarios de su sitio o cualquier otro descubren que su sitio está monitorizando la actividad de las cuentas sin informar a los usuarios. .in 6 Desafortunadamente, todavía no hay precedentes claros sobre las obligaciones o responsabilidades de las organizaciones involucradas en un incidente de seguridad o que puedan estar involucradas en mantener una investigación. A veces los investigadores alentarán a organizaciones para ayudar a rastrear y monitorizar a los intrusos -- verdaderamente, la mayoría de los investigadores no pueden perseguir intrusiones informáticas sin un extenso apoyo de las organizaciones involucradas. Sin embargo, los investigadores no pueden proporcionar protección de reclamaciones de responsabilidades, y este tipo de trabajos puede alargarse durante meses y puede llevas un montón de trabajo. En la otra cara de la moneda, un consejero legal de la organización puede aconsejar extrema precaución y sugerir que se detengan las actividades de rastreo y se expulse a un intruso del sistema. Esto en sí mismo puede no proporcionar protección de responsabilidades, y puede no permitir a los investigadores identificar a nadie. El equilibrio entre apoyar actividades de investigación y limitar responsabilidades es delicado; usted necesitará considerar el consejo de su consejero y el daño que está causando el intruso (si lo hay) para tomar su decisión sobre qué hacer durante cualquier incidente en concreto. Cuando suceda un incidente en su sitio, su consejero legal también debería estar involucrado en cualquier decisión para contactar con las agencias de investigación. La decisión de coordinar sus esfuerzos con agencias de investigación es la más apropiada que puede tomar su sitio u organización. Involucrar a su consejero legal también adoptará la coordinación multinivel entre su sitio y las agencias de investigación particulares involucradas lo cual revierte en una división de trabajo eficiente. Otro resultado es que es probable que obtenga una guía que le ayudará a evitar futuros errores legales. Finalmente, su consejero legal debería evaluar los procedimientos escritos en su sitio para responder a incidentes. Es esencial obtener un "certificado de salud" desde una perspectiva legal antes de que realmente realice estos procedimientos. .ti 3 5.5.2 Procedimientos Legales Formales e Informales .in 6 Una de las consideraciones más importantes al tratar con agencias de investigación es verificar que la persona que llama pidiendo información es un representante legítimo de la agencia en cuestión. Desafortunadamente, alguna gente bien intencionada que ha filtrado desconocidamente información sensible sobre incidentes, permitió que gente no autorizada entrase en sus sistemas, etc., porque alguien que llamó se hizo pasar por un agente del FBI o del Servicio Secreto. Una consideración similar es usar medios de comunicación seguros. Puesto que cualquier atacante a la red puede facilmente reencaminar correos electrónicos, evite usar el correo electrónico para comunicarse con otras agencias (así como con otros que traten el incidente). Lineas telefónicas inseguras (p.ej., los teléfonos que se usan normalmente en el mundo de los negocios) también son objetivos frecuentes para intervenir por intrusos de redes,¡así que tenga cuidado! No hay establecido un conjunto de reglas para responder a un incidente cuando llega a estar involucrado el Gobierno Federal de EEUU. Excepto por orden judicial, ninguna agencia puede forzarle a monitorizar, desconectarse de la red, evitar contactos telefónicos con los supuestos atacantes, etc.. Como se ha discutido en la sección 5.5.1, debería consultar las cosas con su consejero legal, especialmente antes de llevar a cabo una acción que su organización nunca ha hecho. La agencia particular involucrada puede pedirle que deje una máquina atacada encendida y monitorizar la actividad en esta máquina, por ejemplo. Cumpliendo esta petición asegurará la continuada cooperación con la agencia --normalmente la mejor forma para encontrar la fuente de los ataques de red y, finalmente, terminar con estos ataques. Además, usted puede necesitar alguna información o algún favor de la agencia involucrada en el incidente. Probablemente usted obtendrá lo que necesite solo si ha cooperado. Es de particular importancia evitar la revelación de información sobre el incidente innecesaria o no autorizada, incluyendo cualquier información facilitada por la agencia involucrada. La confianza entre su sitio y la agencia flexibiliza su habilidad para evitar comprometer el caso que la agencia llevará a cabo; mantener "los labios sellados" es imperativo. A veces diferirán sus necesidades y las de una agencia de investigación. Su sitio puede querer volver a la normalidad en los negocios cerrando una ruta de ataque, pero la agencia de investigación puede querer que mantenga esta ruta abierta. De forma similar, su sitio puede querer apagar un sistema comprometido, pero de nuevo la agencia de investigación puede querer que lo continúe monitorizando. Cuando existe tal conflicto, puede haber un complejo conjunto de trueques (p.ej., intereses de gestión de su sitio, un montón de recursos que puede asignar al problema, límites jurisdiccionales, etc.). Una directriz importante es relativo a lo que se podría denominar "Ciudadanía de Internet" ("Internet citizenship") [22, IAB89, 23] y sus responsabilidades. Su sitio puede apagar un sistema, y esto le reducirá el estrés, demanda de recursos y peligro de exposición. El atacante, sin embargo, es probable que simplemente se mueva a otro sistema, dejando temporalmente ciegos a las acciones e intenciones del atacante hasta que pueda ser detectada otro vía de ataque. Asegurando que no hay daño a sus sistemas o a otros, el curso de acción más responsable es cooperar con la agencia participante dejando su sistema comprometido encendido. Esto permitirá monitorizar (y, en última estancia, la posibilidad de terminar con la fuente de amenazas a sistemas como los suyos). Por otra parte, si hay daños a ordenadores a los que se ha accedido ilegalmente a través de su sistema, la elección es más complicada: apagar al intruso puede prevenir un daño mayor a los sistemas, pero puede volver imposible rastrear al intruso. Si ha habido daño, la decisión sobre si es importante dejar los sistemas en pie para atrapar el intruso debería involucrar a todas las organizaciones afectadas. Más complicado que el asunto de la responsabilidad de la red es la consideración de que si no coopera con la agencia involucrada, será menos probable recibir ayuda de esa agencia en el futuro. .ti 0 5.6 Registros de Documentación .in 3 Cuando responda a un incidente, documente todos los detalles relativos al incidente. Esto proporcionará una valiosa información para usted mismo y para otros como intente desenmarañar el curso de los acontecimientos. Documentar todos los detalles al final le ahorrará tiempo. Si no documenta cada llamada de teléfono relevante, por ejemplo, es probable que olvide una buena parte de la información que obtuvo, teniendo que contactar con la fuente de información otra vez. Esto desperdiciará su tiempo y el de otros, algo que usted malamente puede permitirse. Al mismo tiempo, grabar detalles proporcionará pruebas para trabajos procesales, proporcionando que el caso se mueva en esta dirección. Documentar un incidente también le ayudará a llevar cabo una valoración de daños final (algo que tanto su administración como los funcionarios de las fuerzas de seguridad querrán conocer), y proporcionará la base para un análisis de continuación en el que usted puede darle lugar a un valioso ejercicio de lecciones aprendidas. Durante los estados iniciales del incidente, a veces es impracticable determinar si es viable un procesamiento, así que se debería documentar como si estuviese recolectando pruebas para un caso judicial. Como mínimo, debería registrar: .in 6 o Todos los acontecimientos del sistema (registros de auditoría). o Todas las acciones que lleve a cabo (marcando la hora). .in 8 .ti 6 o Todas las conversaciones telefónicas (incluyendo la persona con la que habló, la fecha y la hora, y el contenido de la conversación) .in 3 La manera más sencilla para mantener la documentación es guardar un libro de registros. Esto le permite ir a una fuente de información centralizada y cronológica cuando lo necesite, en vez de hacerle ojearlo a través de hojas de papel individuales. Mucha de esta información son pruebas potenciales en un tribunal. De esta manera, cuando sospeche inicialmente que un incidente terminará en procesamiento legal o cuando una agencia de investigación llegue a estar involucrada, usted necesita entregar fotocopiadas regularmente (p.ej., cada día), copias firmadas de su libro de registros (así como de los medios que use para grabar los acontecimientos del sistema) a un guardián de documentos que puede almacenar estas páginas copiadas en un lugar seguro (p.ej., una caja fuerte). Cuando usted remita información para almacenarla, debería recibir un recibo, con la fecha de recepción del guardián de documentos. Un fallo al observar estos procedimientos puede llevar a la invalidación que cualquier prueba obtenida ante un tribunal de justicia. .ti 0 6. Establecer Procedimientos Postincidente .ti 0 6.1 General Al comienzo de un incidente, deberían tener lugar varias acciones. Estas acciones se pueden resumir de la siguiente manera: .in 9 .ti 6 1. Se debería hacer un inventario de los bienes del sistema, esto es, un cuidadoso examen debería determinar como afectó el incidente al sistema, .in 9 .ti 6 2. Las lecciones aprendidas como resultado del incidente deberían ser incluidas en un plan de seguridad revisado para prevenir que vuelva a ocurrir el incidente, .in 9 .ti 3 3. Se debería desarrollar un nuevo análisis de riesgos a la luz del incidente, .in 9 .ti 3 4. Debería comenzar una investigación y proceso de los individuos que causaron el incidente, si se desea un juicio. .in 3 Cada uno de los cuatro pasos debería proporcionar retroalimentación al comité de la política de seguridad del sitio, llevando a incitar la reevaluación y enmienda de la política actual. .ti 0 6.2 Quitar Vulnerabilidades .in 3 Es difícil borrar todas las vulnerabilidades una vez ha ocurrido un incidente. La clave para quitar las vulnerabilidades es conocer y entender la brecha. En algunos casos, es prudente quitar todos los accesos o funcionalidad tan rápido como sea posible y entonces recuperar el normal funcionamiento en fases limitadas. Tenga en cuenta que quitar todos los accesos mientras está ocurriendo un incidente obviamente será notificado a todos los usuarios que los administradores son conscientes de un problema, incluyendo los supuestos usuarios problemáticos; esto puede tener un efecto nocivo en una investigación. Sin embargo, permitir que un incidente continúe también puede abrir la posibilidad de un daño mayor, pérdida, agravante o responsabilidad (civil o criminal). Si se determina que la brecha ocurrió debido a un fallo en el hardware o software del sistema, se debería avisar al vendedor (o suministrador) y al CERT tan pronto como fuese posible. Incluir números de teléfono relevantes (también direcciones de correo electrónico y números de fax) en la política de seguridad del sitio es altamente recomendable. Para ayudar al precoz conocimiento y entendimiento del problema, se debería describir el fallo con tanto detalle como sea posible, incluyendo detalles sobre como explotarlo. Tan pronto como se produzca la brecha, se debería considerar sospechoso todo el sistema y todos sus componentes. El software del sistema es el objetivo más probable. La preparación es clave para recuperarse de un posible sistema contaminado. Esto incluye hacer sumas de comprobación usando un algoritmo de suma de comprobación que (esperemos) sea resistente a ataques [10]. (Ver secciones 3.9.4.1, 3.9.4.2.) Asumiendo que están disponibles las cintas originales de distribución del vendedor, debería comenzar un análisis de todos los archivos del sistema, y se debería notar cualquier irregularidad e informar a todas las partes involucradas en el tratamiento del incidente. Decidir desde que copias de seguridad restaurar el sistema, en algunos casos, puede ser muy difícil; tenga en cuenta que el incidente puede haber durado meses o años antes de ser descubierto, y que el sospechoso puede ser un empleado del sitio, o en caso contrario tener un intimo conocimiento o acceso a los sistemas. En cualquier caso, la preparación pre-incidente determinará qué recuperación es posible . En el peor de los casos, las restauración desde los medios originales del vendedor y una reinstalación de los sistemas será la solución más prudente. Revise las lecciones aprendidas del incidente y siempre actualice la política y procedimientos para reflejar los cambios necesarios debidos al incidente. .ti 3 6.2.1 Evaluación de Daños Antes de que pueda empezar a limpiar, se debe analizar el daño real al sistema. Esto puede llevar mucho tiempo, pero debería llevar al entendimiento de cosas como la naturaleza del incidente, y ayudar a la investigación y procesamiento. Es mejor comparar copias de seguridad previas o cintas originales cuando sea posible; una preparación avanzada es la clave. Si el sistema soporta registro centralizado (la mayoría lo hace), recupere los registros y busque anormalidades. Si el proceso de cuentas y tiempo de conexión de cuentas está activado, busque pautas de uso del sistema. Para una menor extensión, el uso de disco puede arrojar luz al incidente. Las cuentas pueden proporcionar mucha información de ayuda en el análisis de un incidente y el posterior procesamiento. .ti 3 6.2.2 Limpieza Una vez se ha evaluado el daño, es necesario desarrollar un plan para limpiar el sistema. En general, habilitar servicios en orden de demanda para molestar mínimamente a los usuarios es la mejor práctica. Entienda que los procedimientos de recuperación apropiados para el sistema son extremadamente importantes y deberían ser específicos del sitio. Puede ser necesario volver a las cintas originales distribuidas y repersonalizar el sistema. Para facilitar este caso de peor escenario, un registro de la configuración inicial de los sistemas y cada adaptación debería estar al tanto de cada cambio en el sistema. .ti 3 6.2.3 Continuar .in 6 Una vez crea que un sistema ha sido restaurado desde un estado "seguro", todavía es posible que pueda haber agujeros e incluso trampas escondidos en el sistema. En la siguiente etapa, se debería buscar cosas del sistema que se puedan haber perdido durante la etapa de limpieza. Sería prudente utilizar algunas de las herramientas mencionadas en la sección 3.9.8.2 (p.ej., COPS) para empezar. Recuerde, estas herramientas no reemplazan el continuo monitoreo del sistema y los buenos procedimientos de administración del sistema. .ti 3 6.2.4 Guardar un Registro de Seguridad .in 6 Como se ha discutido en la sección 5.6, un registro de seguridad puede ser lo más valioso durante esta fase de quitar vulnerabilidades. Aquí hay dos consideraciones; la primera es guardar registros de los procedimientos que se han usado para hacer el sistema seguro de nuevo. Esto debería incluir procedimientos por comandos (p.ej., shell scripts) que se pueden ejecutar periodicamente para comprobar la seguridad. Segunda, guardar registros de los sucesos importantes del sistema. Estos se pueden tomar como referencia cuando intente determinar la extensión del daño de un incidente dado. .ti 0 6.3 Capturar las Lecciones Aprendidas .ti 3 6.3.1 Entender la Lección .in 6 Después de un incidente, es prudente escribir un informe describiendo el incidente, forma de descubrimiento, procedimiento de corrección, procedimiento de monitoreo y un resumen de la lección aprendida. Esto ayudará al claro entendimiento del problema. Recuerde, es difícil aprender de un incidente si no entiende la fuente de este. .ti 3 6.3.2 Recursos .ti 6 6.3.2.1 Otros Dispositivos de Seguridad, Métodos .in 9 La seguridad es un proceso dinámico, no estático. Los sitios dependen de la naturaleza de la seguridad disponible en cada sitio, y la serie de dispositivos y métodos que ayudarán a promover la seguridad. Estar al tanto del área de seguridad de la industria informática y sus métodos asegurará a un administrador de seguridad tener conciencia de la última tecnología. .ti 6 6.3.2.2 Repositorio de Libros, Listas, Fuentes de Información .in 9 Mantenga una colección de libros, listas, fuentes de información, etc. sobre sitios como guías y referencias para asegurar el sistema. Mantenga esta colección actualizada. Recuerde, así como cambian los sistemas, lo hacen los métodos y problemas de seguridad. .ti 6 6.3.2.3 Formar un Subgrupo .in 9 Forme un subgrupo de personal de administración del sistema que será el corazón de los responsables de seguridad. Esto permitirá discusiones sobre problemas de seguridad y múltiples puntos de vista sobre los asuntos de seguridad del sitio. Este subgrupo también puede actuar para desarrollar la política de seguridad del sitio y hacer los cambios que se crean necesarios para asegurar la seguridad del sitio. .ti 0 6.4 Mejorar Políticas y Procedimientos .in 10 .ti 3 6.4.1 Establecer Mecanismos para Actualizar Políticas, Procedimientos y Herramientas .in 6 Si un incidente está basado en una política pobre, a no ser que se cambie la política, uno está condenado a repetir el pasado. Una vez un sitio se ha recuperado de un incidente, se deberían revisar la política y procedimientos del sitio para incluir cambios y prevenir incidentes similares. Incluso si no ha ocurrido ningún incidente, sería prudente revisar las políticas y procedimientos regularmente. Las revisiones son obligadas debido a los cambios de los entornos informáticos hoy en día. .ti 3 6.4.2 Procedimientos para Informar de Problemas .ti 6 Se debería implementar un procedimiento de información de problemas para describir, detalladamente, el incidente y sus soluciones. Cada incidente debería ser revisado por el subgrupo de seguridad del sitio para permitir el entendimiento del incidente con posibles sugerencias a la política y procedimientos del sitio. .ti 0 7. Referencias .in 7 .ti 3 [1] J. Quarterman, "The Matrix: Computer Networks and Conferencing Systems Worldwide", Pg. 278, Digital Press, Bedford, MA, 1990. .ti 3 [2] R. Brand, "Coping with the Threat of Computer Security Incidents: A Primer from Prevention through Recovery", R. Brand, disponible en linea en: cert.sei.cmu.edu:/pub/info/primer, 8 de Junio de 1990. .ti 3 [3] Fites, M., Kratz, P. and A. Brebner, "Control and Security of Computer Information Systems", Computer Science Press, 1989. .ti 3 [4] Johnson, D., and J. Podesta, "Formulating a Company Policy on Access to and Use and Disclosure of Electronic Mail on Company Computer Systems", Disponible en: The Electronic Mail Association (EMA) 1555 Wilson Blvd, Suite 555, Arlington VA 22209, (703) 522-7111, 22 de Octubre de 1990. .ti 3 [5] Curry, D., "Improving the Security of Your UNIX System", SRI International Report ITSTD-721-FR-90-21, Abril de 1990. .ti 3 [6] Cheswick, B., "The Design of a Secure Internet Gateway", Proceedings of the Summer Usenix Conference, Anaheim, CA, Junio de 1990. .ti 3 [7] Linn, J., "Privacy Enhancement for Internet Electronic Mail: Part I -- Message Encipherment and Authentication Procedures", RFC 1113, IAB Privacy Task Force, Agosto de 1989. .ti 3 [8] Kent, S., and J. Linn, "Privacy Enhancement for Internet Electronic Mail: Part II -- Certificate-Based Key Management", RFC 1114, IAB Privacy Task Force, Agosto de 1989. .ti 3 [9] Linn, J., "Privacy Enhancement for Internet Electronic Mail: Part III -- Algorithms, Modes, and Identifiers", RFC 1115, IAB Privacy Task Force, Agosto de 1989. .ti 2 [10] Merkle, R., "A Fast Software One Way Hash Function", Journal of Cryptology, Vol. 3, No. 1. .ti 2 [11] Postel, J., "Internet Protocol - DARPA Internet Program Protocol Specification", RFC 791, DARPA, Septiembre de 1981. .ti 2 [12] Postel, J., "Internet Protocol - DARPA Internet Program Protocol Specification", RFC 791, DARPA, Septiembre de 1981. .ti 2 [13] Postel, J., "User Datagram Protocol", RFC 768, USC/Information Sciences Institute, 28 de Agosto de 1980. .ti 2 [14] Mogul, J., "Simple and Flexible Datagram Access Controls for UNIX-based Gateways", Digital Western Research Laboratory Research Report 89/4, Marzo de 1989. .ti 2 [15] Bellovin, S., and M. Merritt, "Limitations of the Kerberos Authentication System", Computer Communications Review, Octubre de 1990. .ti 2 [16] Pfleeger, C., "Security in Computing", Prentice-Hall, Englewood Cliffs, N.J., 1989. .ti 2 [17] Parker, D., Swope, S., and B. Baker, "Ethical Conflicts: Information and Computer Science, Technology and Business", QED Information Sciences, Inc., Wellesley, MA. .ti 2 [18] Forester, T., and P. Morrison, "Computer Ethics: Tales and Ethical Dilemmas in Computing", MIT Press, Cambridge, MA, 1990. .ti 2 [19] Postel, J., and J. Reynolds, "Telnet Protocol Specification", RFC 854, USC/Information Sciences Institute, Mayo de 1983. .ti 2 [20] Postel, J., and J. Reynolds, "File Transfer Protocol", RFC 959, USC/Information Sciences Institute, Octubre de 1985. .ti 2 [21] Postel, J., Editor, "IAB Official Protocol Standards", RFC 1200, IAB Abril de 1991. .ti 2 [22] Internet Activities Board, "Ethics and the Internet", RFC 1087, Internet Activities Board, Enero de 1989. .ti 2 [23] Pethia, R., Crocker, S., and B. Fraser, "Policy Guidelines for the Secure Operation of the Internet", CERT, TIS, CERT, RFC en preparación. .ti 2 [24] Computer Emergency Response Team (CERT/CC), "Unauthorized Password Change Requests", CERT Advisory CA-91:03, Abril de 1991. .ti 2 [25] Computer Emergency Response Team (CERT/CC), "TELNET Breakin Warning", CERT Advisory CA-89:03, Agosto de 1989. .ti 2 [26] CCITT, Recommendation X.509, "The Directory: Authentication Framework", Annex C. .ti 2 [27] Farmer, D., and E. Spafford, "The COPS Security Checker System", Proceedings of the Summer 1990 USENIX Conference, Anaheim, CA, Pgs. 165-170, Junio de 1990. .ti 0 8. Bibliografía Destacada .in 3 Lo que intenta esta bibliografía destacada es ofrecer una colección de recursos de información representativa que ayudará al usuario de este manual. Su intención es proporcionar un punto de partida para mayor investigación en el área de la seguridad. Se incluyen referencias a otras fuentes de información para aquellos que deseen buscar publicaciones del entorno de la seguridad informática. .ti 0 8.1 Legislación Informática .ti 3 [ABA89] .in 11 American Bar Association, Section of Science and Technology, "Guide to the Prosecution of Telecommunication Fraud by the Use of Computer Crime Statutes", American Bar Association, 1989. .ti 3 [BENDER] .in 11 Bender, D., "Computer Law: Evidence and Procedure",M. Bender, New York, NY, 1978-present. Mantenido actualizado con suplementos. Los años que cubren 1978-1984 tratan: Procedimientos, pruebas y legislación informática. Los años desde 1984 a la actualidad enfocan la legislación informática en general. Incluye índice y referencias bibliográficas. .ti 3 [BLOOMBECKER] .in 11 Bloombecker, B., "Spectacular Computer Crimes", Dow Jones-Irwin, Homewood, IL. 1990. .ti 3 [CCH] .in 11 Commerce Clearing House, "Guide to Computer Law", (Topical Law Reports), Chicago, IL., 1989. Casos judiciales y decisiones tomadas por cortes federales y estatales a través de todos los Estados Unidos sobre leyes informáticas federales y estatales. Incluye Indice de Casos e Indice Temático. .ti 3 [CONLY] .in 11 Conly, C., "Organizing for Computer Crime Investigation and Prosecution", U.S. Dept. of Justice, Office of Justice Programs, Under Contract Number OJP-86-C-002, National Institute of Justice, Washington, DC, Julio de 1989. .ti 3 [FENWICK] .in 11 Fenwick, W., Chair, "Computer Litigation, 1985: Trial Tactics and Techniques", Litigation Course Handbook Series No. 280, Prepared for distribution at the Computer Litigation, 1985: Trial Tactics and Techniques Program, Febrero-Marzo de 1985. .ti 3 [GEMIGNANI] .in 11 Gemignani, M., "Viruses and Criminal Law", Communications of the ACM, Vol. 32, No. 6, Pgs. 669-671, Junio de 1989. .ti 3 [HUBAND] .in 11 Huband, F., and R. Shelton, Editors, "Protection of Computer Systems and Software: New Approaches for Combating Theft of Software and Unauthorized Intrusion", Papers presented at a workshop sponsored by the National Science Foundation, 1986. .ti 3 [MCEWEN] .in 11 McEwen, J., "Dedicated Computer Crime Units", Report Contributors: D. Fester and H. Nugent, Prepared for the National Institute of Justice, U.S. Department of Justice, by Institute for Law and Justice, Inc., under contract number OJP-85-C-006, Washington, DC, 1989. .ti 3 [PARKER] .in 11 Parker, D., "Computer Crime: Criminal Justice Resource Manual", U.S. Dept. of Justice, National Institute of Justice, Office of Justice Programs, Under Contract Number OJP-86-C-002, Washington, D.C., Agosto de 1989. .ti 3 [SHAW] .in 11 Shaw, E., Jr., "Computer Fraud and Abuse Act of 1986, Congressional Record (3 June 1986), Washington, D.C., 3 de Junio de 1986. .ti 3 [TRIBLE] .in 11 Trible, P., "The Computer Fraud and Abuse Act of 1986", U.S. Senate Committee on the Judiciary, 1986. .ti 0 8.2 Seguridad Informática .ti 3 [CAELLI] .in 11 Caelli, W., Editor, "Computer Security in the Age of Information", Proceedings of the Fifth IFIP International Conference on Computer Security, IFIP/Sec '88. .ti 3 [CARROLL] .in 11 Carroll, J., "Computer Security", 2nd Edition, Butterworth Publishers, Stoneham, MA, 1987. .ti 3 [COOPER] .in 11 Cooper, J., "Computer and Communications Security: Strategies for the 1990s", McGraw-Hill, 1989. .ti 3 [BRAND] .in 11 Brand, R., "Coping with the Threat of Computer Security Incidents: A Primer from Prevention through Recovery", R. Brand, 8 de Junio de 1990. Como la seguridad informática está llegando a ser un asunto más importante en la sociedad moderna, empieza a ordenar un acercamiento sistemático. La inmensa mayoría de los problemas de seguridad informática y el coste asociado a ellos se puede prevenir con medidas simples y baratas. La medida más importante y rentable está disponible en las fases de prevención y planificación. Estos métodos se presentan en este documento, seguidos de una guía simplificada para al trato de incidentes y recuperación. Está disponible en linea en: cert.sei.cmu.edu:/pub/info/primer. .ti 3 [CHESWICK] Cheswick, B., "The Design of a Secure Internet Gateway", Proceedings of the Summer Usenix Conference, Anaheim, CA, Junio de 1990. Breve resumen (ligera paráfrasis del resumen original): AT&T mantiene una gran internet interna que necesita ser protegida de ataque externos, a la vez que proporcione servicios útiles entre las dos. Este documento describe la pasarela a Internet de AT&T. Esta pasarela trasporta correo y algunos de los servicios de Internet más utilizados entre las máquinas internas de AT&T e Internet. Esto se logra sin conectividad IP usando un par de máquinas: una máquina interna de confianza y una pasarela externa no confiable. Estas están conectadas a través de un enlace privado. La máquina interna proporciona unos pocos servicios cuidadosamente vigilados a la pasarela externa. Esta configuración ayuda a proteger la internet interna incluso si la máquina externa está totalmente comprometida. Este es un diseño muy útil e interesante. La mayoría de los sistemas que funcionan como pasarela y cortafuegos se basan en un sistema que, si se compromete, podría permitir el acceso a las máquinas que hay tras el cortafuegos. También, la mayoría de los cortafuegos requiere que los usuarios que quieran acceder a los servicios de Internet tengan una cuenta en la máquina cortafuegos. El diseño de AT&T permite a los usuarios de la internet interna AT&T a los servicios estándar TELNET y FTP desde sus propias estaciones de trabajo sin cuentas en el cortafuegos. Un documento muy útil que muestra como mantener algunos de los beneficios de la conectividad de Internet aún mientras se mantiene una fuerte seguridad. .ti 3 [CURRY] Curry, D., "Improving the Security of Your UNIX System", SRI International Report ITSTD-721-FR-90-21, Abril de 1990. Este documento describe medidas que usted, como administrador del sistema, puede tomar para hacer más seguros su(s) sistema(s) UNIX. Orientado principalmente a SunOS 4.x, la mayoría de la información que cubre se aplica igual de bien a cualquier sistema UNIX de Berkeley con o sin NFS y/o Páginas Amarillas (NIS). Parte de la información también puede ser aplicada a System V, aunque el documento no se centra principalmente en este. Una referencia muy útil, también está disponible en Internet en varias localizaciones, incluyendo el directorio cert.sei.cmu.edu:/pub/info. .ti 3 [FITES] Fites, M., Kratz, P. and A. Brebner, "Control and Security of Computer Information Systems", Computer Science Press, 1989. Este libro sirve como una buena guía a los asuntos encontrados al definir políticas y procedimientos de seguridad informática. Está diseñado como un libro de texto para un curso introductorio a la seguridad de sistemas de información. El libro está dividido en cinco secciones: Gestión de Riesgos (I), Protección: Medidas de Control y Seguridad, organizativas y administrativas (II), Salvaguardias: Medidas de Control y Seguridad, Técnicas (III), Entorno Legal y Profesionalismo (IV), y Directivas de Control Informático CICA (V). El libro es particularmente destacable por su sencillo enfoque de la seguridad, enfatizando que el sentido común es la primera cosa a tener en cuenta al diseñar un programa de seguridad. Los autores denotan que hay una tendencia a mirar a más soluciones técnicas a problemas de seguridad mientras se descuidan controles organizativos que a veces son más baratos y mucho más efectivos. 298 páginas, incluyendo referencias e índice. .ti 3 [GARFINKEL] Garfinkel, S, and E. Spafford, "Practical Unix Security", O'Reilly & Associates, ISBN 0-937175-72-2, Mayo de 1991. Aprox. 450 páginas, $29.95. Pedidos: 1-800-338-6887 (EEUU y Canadá), 1-707-829-0515 (Europa), correo electrónico: nuts@ora.com Este es uno de los libros disponibles más útiles sobre seguridad en Unix. La primera parte del libro cubre Unix estándar y seguridad Unix básica, con particular énfasis en las contraseñas. La segunda sección cubre imponer la seguridad en el sistema. Las secciones sobre seguridad de redes son de particular interés para los usuarios de Internet, la cual trata algunos de los problemas de seguridad más comunes que afectan a los usuarios de Internet de Unix. Cuatro capítulos abarcan el tratamiento de incidentes de seguridad, y el libro concluye con discusiones sobre cifrado, seguridad física y útiles listas de comprobación y de recursos. El libro hace honor a su nombre; está lleno de referencias específicas a posibles agujeros de seguridad, archivos a comprobar y cosas que hacer para mejorar la seguridad. Este libro es un complemento excelente a este manual. .ti 3 [GREENIA90] Greenia, M., "Computer Security Information Sourcebook", Lexikon Services, Sacramento, CA, 1989. Una guía de administración de seguridad informática. Contiene un libro de referencias de materiales de referencia claves incluidas bibliografías de crímenes informáticos y de control de acceso. .ti 3 [HOFFMAN] Hoffman, L., "Rogue Programs: Viruses, Worms, and Trojan Horses", Van Nostrand Reinhold, NY, 1990. (384 páginas, incluye referencias bibliográficas e índice.) .ti 3 [JOHNSON] Johnson, D., and J. Podesta, "Formulating A Company Policy on Access to and Use and Disclosure of Electronic Mail on Company Computer Systems" Un libro blanco preparado para el EMA, escrito por dos expertos en leyes sobre intimidad. Da un trasfondo sobre los asuntos, y presenta algunas opciones de políticas. Disponible en: (La Asociación del Correo Electrónico) The Electronic Mail Association (EMA) 1555 Wilson Blvd, Suite 555, Arlington, VA, 22209. (703) 522-7111. .ti 3 [KENT] Kent, Stephen, "E-Mail Privacy for the Internet: New Software and Strict Registration Procedures will be Implemented this Year", Business Communications Review, Vol. 20, No. 1, Pg. 55, 1 de Enero de 1990. .ti 3 [LU] Lu, W., and M. Sundareshan, "Secure Communication in Internet Environments: A Hierachical Key Management Scheme for End-to-End Encryption", IEEE Transactions on Communications, Vol. 37, No. 10, Pg. 1014, 1 de Octubre de 1989. .ti 3 [LU1] Lu, W., and M. Sundareshan, "A Model for Multilevel Security in Computer Networks", IEEE Transactions on Software Engineering, Vol. 16, No. 6, Page 647, 1 de Junio de 1990. .ti 3 [NSA] National Security Agency, "Information Systems Security Products and Services Catalog", NSA, Quarterly Publication. El catálogo de la NSA contiene capítulos sobre: Lista de Productos Criptográficos Aprobados; Lista de la NSA de Productos de Cifrado de Datos Estándar (DES) Aprobados; Lista de Servicios Protegidos; Lista de Productos Evaluados; Lista de Productos Preferentes; y Lista de Herramientas Aprobadas. El catálogo está disponible en el Directorio de Documentos, Oficina de Impresión de EE.UU. (U.S. Government Printing Office), Washington D.C. Puede hacer pedidos llamando a: (202) 783-3238. .ti 3 [OTA] United States Congress, Office of Technology Assessment, "Defending Secrets, Sharing Data: New Locks and Keys for Electronic Information", OTA-CIT-310, Octubre de 1987. Este informe, preparado para el comité del congreso considerando la política Federal sobre la protección de la información electrónica, es interesante porque de las publicaciones, esta aumenta la visión del impacto de la tecnología usada para proteger información. También sirve como introducción razonable a los variados mecanismos de cifrado y protección de información. 185 páginas. Disponible en la Oficina de Impresión Gubernamental de EE.UU. (U.S. Government Printing Office). .ti 3 [PALMER] Palmer, I., and G. Potter, "Computer Security Risk Management", Van Nostrand Reinhold, NY, 1989. .ti 3 [PFLEEGER] Pfleeger, C., "Security in Computing", Prentice-Hall, Englewood Cliffs, NJ, 1989. Un libro de texto general sobre seguridad informática, este libro proporciona una introducción excelente y muy legible a los clásicos problemas y soluciones sobre seguridad informática, con un particular énfasis en el cifrado. La cobertura del cifrado sirve como una buena introducción al asunto. Otros temas que se cubren incluyen la construcción de sistemas y programas seguros, seguridad de bases de datos, seguridad informática personal, seguridad en redes y comunicaciones, seguridad física, análisis de riesgos y planificación de la seguridad, y asuntos éticos y legales. 538 páginas incluyendo índice y bibliografía. .ti 3 [SHIREY] Shirey, R., "Defense Data Network Security Architecture", Computer Communication Review, Vol. 20, No. 2, Page 66, 1 de Abril de 1990. .ti 3 [SPAFFORD] Spafford, E., Heaphy, K., and D. Ferbrache, "Computer Viruses: Dealing with Electronic Vandalism and Programmed Threats", ADAPSO, 1989. (109 páginas.) Es una buena referencia general sobre virus informáticos y temas relacionados. Además de describir virus con algo de detalle, también cubre asuntos de seguridad más generales, recursos legales en caso de problemas de seguridad, e incluye listas de leyes, diarios sobre seguridad informática y otros recursos relacionados con la seguridad. .in 11 Disponible en: ADAPSO, 1300 N. 17th St, Suite 300, Arlington VA 22209. (703) 522-5055. .ti 3 [STOLL88] Stoll, C., "Stalking the Wily Hacker", Communications of the ACM, Vol. 31, No. 5, Pgs. 484-497, ACM, New York, NY, Mayo de 1988. El articulo describe algunos de los métodos técnicos usados para rastrear al intruso que más tarde fue relatado en "Cuckoo's Egg" (ver más abajo). .ti 3 [STOLL89] Stoll, C., "The Cuckoo's Egg", ISBN 00385-24946-2, Doubleday, 1989. Clifford Stoll, un astrónomo convertido en Administrador de Sistemas UNIX, narra una excitante historia real de como rastreó un intruso informático a través del laberinto de redes militares y de investigación americanas. Este libro es fácil de entender y puede servir como una interesante introducción al mundo de las redes. Jon Postel dice en una crítica del libro "[este libro] ... es una lectura absolutamente esencial para cualquiera que use u opere cualquier ordenador conectado a Internet o a cualquier otra red informática." .ti 3 [VALLA] Vallabhaneni, S., "Auditing Computer Security: A Manual with Case Studies", Wiley, New York, NY, 1989. 8.3 Etica .in 11 .ti 3 [CPSR89] Computer Professionals for Social Responsibility, "CPSR Statement on the Computer Virus", CPSR, Communications of the ACM, Vol. 32, No. 6, Pg. 699, Junio de 1989. Este documento es una declaración sobre los virus informáticos de Internet de Profesionales Informáticos para la Responsabilidad Social (CPSR). .ti 3 [DENNING] Denning, Peter J., Editor, "Computers Under Attack: Intruders, Worms, and Viruses", ACM Press, 1990. .in 11 Una colección de 40 capítulos dividida en seis secciones: la emergencia de redes informáticas mundiales, brechas electrónicas, gusanos, virus, contracultura (artículos examinando el mundo del "hacker"), y finalmente una sección de discusión de consideraciones sociales, legales y éticas. Una exhaustiva colección que trata el fenómeno de los ataques informáticos. Esto incluye un número de artículos previamente publicados y algunos nuevos. Los publicados anteriormente están bien elegidos, e incluyen algunas referencias que pueden ser difíciles de obtener de otra manera. Este libro es una referencia clave de amenazas de seguridad informática que han generado gran parte de los relativo a seguridad informática en los últimos años. .ti 3 [ERMANN] Ermann, D., Williams, M., and C. Gutierrez, Editors, "Computers, Ethics, and Society", Oxford University Press, NY, 1990. (376 páginas, incluyendo referencias bibliográficas). .in 11 .ti 3 [FORESTER] Forester, T., and P. Morrison, "Computer Ethics: Tales and Ethical Dilemmas in Computing", MIT Press, Cambridge, MA, 1990. (192 páginas incluyendo el índice) Sacado del prefacio: "El objeto de este libro es doble: (1) describir algunos de los problemas creados por la sociedad y los computadores, y (2) mostrar como estos problemas presentan dilemas éticos para profesionales y usuarios informáticos. Los problemas creados por ordenadores aparecen, en cambio, de dos fuentes principales: del mal funcionamiento de hardware y software y de un mal uso por seres humanos. Sostenemos que los sistemas informáticos por su propia naturaleza son inseguros, poco fiables e impredecibles -- y que la sociedad todavía tiene que aceptar las consecuencias. También buscamos mostrar como la sociedad desde hace poco ha llegado a ser vulnerable a un mal uso de ordenadores por parte de humanos en forma de crimen informático, robo de software, hacking, la creación de virus, invasiones de la intimidad, y demás." Los ocho capítulos incluyen "Crimen Informático", "Robo de Software", "Hacking y Virus", "Ordenadores poco fiables", "La Invasión de la Intimidad", "IA y Sistemas Expertos" y "Informatizar el Lugar de trabajo". Incluye gran cantidad de notas sobre fuentes y un índice. .ti 3 [GOULD] Gould, C., Editor, "The Information Web: Ethical and Social Implications of Computer Networking", Westview Press, Boulder, CO, 1989 .ti 3 [IAB89] Internet Activities Board, "Ethics and the Internet", RFC 1087, IAB, Enero de 1989. Tambien aparece en the Communications of the ACM, Vol. 32, No. 6, Pg. 710, Junio de 1989. .in 11 Este documento es una declaración de política de la Tabla de Actividades de Internet (Internet Activities Board) (IAB) respecto al uso apropiado de los recursos de Internet. Disponible en linea en el servidor ftp.nisc.sri.com, directorio rfc, archivo rfc1087.txt. También está disponible en el servidor nis.nsf.net, directorio RFC, archivo RFC1087.TXT-1. .ti 3 [MARTIN] Martin, M., and R. Schinzinger, "Ethics in Engineering", McGraw Hill, 2nd Edition, 1989. .ti 3 [MIT89] Massachusetts Institute of Technology, "Teaching Students About Responsible Use of Computers", MIT, 1985-1986. También reimpreso en the Communications of the ACM, Vol. 32, No. 6, Pg. 704, Athena Project, MIT, Junio de 1989. Este documento es una declaración de política del Instituto Tecnológico de Massachusetts (Massachusetts Institute of Technology) (MIT) sobre el uso responsable de computadoras. .ti 3 [NIST] National Institute of Standards and Technology, "Computer Viruses and Related Threats: A Management Guide", NIST Special Publication 500-166, Agosto de 1989. .ti 3 [NSF88] National Science Foundation, "NSF Poses Code of Networking Ethics", Communications of the ACM, Vol. 32, No. 6, Pg. 688, Junio de 1989. También aparece en the minutes of the regular meeting of the Division Advisory Panel for Networking and Communications Research and Infrastructure, Dave Farber, Chair, 29-30 de Noviembre de1988. Este documento es una declaración de política de la Fundación Científica Nacional (NSF) sobre el uso ético de Internet. .ti 3 [PARKER90] Parker, D., Swope, S., and B. Baker, "Ethical Conflicts: Information and Computer Science, Technology and Business", QED Information Sciences, Inc., Wellesley, MA. (245 páginas). .ti 3 Publicaciones adicionales sobre Etica: .ti 3 The University of New Mexico (UNM) .in 6 La UNM tiene una colección de documentos éticos. Está incluida la legislación de varios estados y políticas de algunas instituciones. .in 9 Acceso a través de FTP, dirección IP ariel.umn.edu. Busque en el directorio /ethics. .ti 0 8.4 El Gusano de Internet .ti 3 [BROCK] .in 11 Brock, J., "November 1988 Internet Computer Virus and the Vulnerability of National Telecommunications Networks to Computer Viruses", GAO/T-IMTEC-89-10, Washington, DC, 20 de Julio de 1989. Declaración testimonial de Jack L. Brock, Director de Información Gubernamental de EEUU (U. S. Government Information) ante el Subcomité sobre Telecomunicaciones y Finanzas, el Comité sobre Energía y Comercio, Casa de los Representantes (House of Representatives, N. del T.: Cámara baja estadounidense). .ti 3 [EICHIN89] Eichin, M., and J. Rochlis, "With Microscope and Tweezers: An Analysis of the Internet Virus of November 1988". Massachusetts Institute of Technology, Febrero de 1989. Proporciona una disección detallada del programa gusano. El documento discute los puntos más importantes del programa gusano y revisa estrategias, cronología, lecciones y publicaciones abiertas, Agradecimientos; también incluye un apéndice detallado sobre el programa gusano subrutina por subrutina, un apéndice sobre la distribución de caracteres, y una sección de referencia. .ti 3 [EISENBERG89] Eisenberg, T., D. Gries, J. Hartmanis, D. Holcomb, M. Lynn, and T. Santoro, "The Computer Worm", Cornell University, 6 de Febrero de 1989. Un Informe de la Universidad de Cornell presentado al Rector de la Universidad el 6 de Febrero de 1989 sobre el gusano de Internet. .ti 3 [GAO] U.S. General Accounting Office, "Computer Security - Virus Highlights Need for Improved Internet Management", United States General Accounting Office, Washington, DC, 1989. .in 11 La página 36 de este informe (GAO/IMTEC-89-57), de la Oficina General de Cuentas de EEUU, describe el gusano de Internet y sus efectos. Da una buena visión general de las variadas agencias estadounidenses involucradas en Internet hoy y sus implicaciones con respecto a seguridad informática y redes. Disponible en linea en el servidor nnsc.nsf.net, directorio pub, archivo GAO_RPT; y en nis.nsf.net, directorio nsfnet, archivo GAO_RPT.TXT. .in 11 .ti 3 [REYNOLDS89] The Helminthiasis of the Internet, RFC 1135, USC/Information Sciences Institute, Marina del Rey, CA, Diciembre de 1989. Este informe rememora a la helmintiasis (infestación, o enfermedad causada por gusanos parásitos) de Internet que fue liberada la tarde del 2 de Noviembre de 1988. Este documento proporciona una ojeada a la infección,su supuración y cura. Se discute el impacto del gusano en la comunidad de Internet,declaraciones éticas, el papel de los medios de noticias, el crimen en el mundo informático y la futura prevención. Una ojeada a la documentación presenta cuatro publicaciones que describen con detalle este particular programa parásito informático. También están incluidas las secciones de referencias y bibliografía. Está disponible en linea en el servidor ftp.nisc.sri.com directorio rfc, nombre de archivo rfc1135.txt. También está disponible en el servidor nis.nsf.net, directorio RFC, nombre de archivo RFC1135.TXT-1. .in 11 .ti 3 [SEELEY89] Seeley, D., "A Tour of the Worm", Proceedings of 1989 Winter USENIX Conference, Usenix Association, San Diego, CA, Febrero de 1989. Los detalles están presentados como un paseo a través de este singular programa gusano. El documento empieza con un resumen, introducción, cronología detallado de sucesos sobre el descubrimiento del gusano, una visión general, el interior del gusano, opiniones personales y conclusión. .ti 3 .in 11 [SPAFFORD88] Spafford, E., "The Internet Worm Program: An Analysis", Computer Communication Review, Vol. 19, No. 1, ACM SIGCOM, Enero de 1989. También publicado como Purdue CS Technical Report CSD-TR-823, 28 de Noviembre de 1988. Describe la infección de Internet como un programa gusano que explotaba fallos en programas de utilidad en programas basados en UNIX. El informe da una descripción detallada de los componentes del programa gusano: datos y funciones. Spafford enfoca su estudio en dos compilaciones inversas completamente independientes del gusano y una versión desensamblada al lenguaje ensamblador de VAX. .ti 3 .in 11 [SPAFFORD89] Spafford, G., "An Analysis of the Internet Worm", Proceedings of the European Software Engineering Conference 1989, Warwick England, Septiembre de 1989. Actas publicadas por Springer-Verlag como: Lecture Notes in Computer Science #387. También publicado como Purdue Technical Report #CSD-TR-933. .ti 0 8.5 Centro Nacional de Seguridad Informática (NCSC) .in 3 Todas las publicaciones del NCSC, aprobadas para liberación pública, están disponibles en el Dirección General de Documentos del NCSC. .in 11 NCSC = National Computer Security Center: 9800 Savage Road Ft Meade, MD 20755-6000 CSC = Computer Security Center: un antiguo nombre del NCSC NTISS = National Telecommunications and Information Systems Security NTISS Committee, National Security Agency Ft Meade, MD 20755-6000 .in 11 .ti 3 [CSC] Department of Defense, "Password Management Guideline", CSC-STD-002-85, 12 de Abril de 1985, 31 páginas. La seguridad proporcionada por un sistema de contraseñas depende de guardarlas en secreto en todo momento. Así, una contraseña es vulnerable a ser comprometida cuando quiera que se use, almacene o hasta que sea conocida. En un mecanismo de autenticación basado en contraseñas implementado en un sistema ADP, las contraseñas son vulnerables a ser comprometidas debido a cinco aspectos esenciales del sistema de contraseñas: 1) una contraseña se debe asignar inicialmente a un usuario cuando se alista en el sistema ADP; 2) una contraseña de usuario se debe cambiar periodicamente; 3) el sistema ADP debe mantener una 'base de datos de contraseñas'; 4) los usuarios deben recordar sus contraseñas; y 5) los usuarios deben introducir su contraseña en el sistema ADP en el momento de la autenticación. Esta directiva receta pasos a tomar para minimizar la vulnerabilidad de las contraseñas en cada una de estas circunstancias. .in 11 .ti 3 [NCSC1] NCSC, "A Guide to Understanding AUDIT in Trusted Systems", NCSC-TG-001, Version-2, 1 de Junio de 1988, 25 páginas. Las trazas de auditoría se usan para detectar y detener penetraciones de un sistema informático y para revelar usos que se identifican como malos usos. Dependiendo de la discreción del auditor, las trazas de auditoría pueden estar limitadas a sucesos específicos o puede englobar todas las actividades de un sistema. Aunque no es un requisito de los criterios , debería ser posible que el objetivo del mecanismo sea o un sujeto o un objeto. Es decir, el mecanismo de auditoría debería ser capaz de monitorizar cada vez que Juan accedió al sistema así como cada vez que se accedió al archivo del reactor nuclear; y de igual manera cada vez que Juan accedió al archivo del reactor nuclear. .in 11 .ti 3 [NCSC2] NCSC, "A Guide to Understanding DISCRETIONARY ACCESS CONTROL in Trusted Systems", NCSC-TG-003, Version-1, 30 de Septiembre de 1987, 29 páginas. El control discrecional es el tipo de mecanismo de control de acceso más comúnmente implementado hoy en día. Este tipo de seguridad se basa en que un usuario individual, o programa operando en nombre del usuario, se le permite especificar explicitamente el tipo de acceso que otros usuarios (o programas ejecutándose en su nombre) pueden tener a la información bajo el control del usuario. .in 12 .ti 0 [...] Los controles discrecionales no son una sustitución de controles obligatorios. En cualquier entorno en que se protege la información, la seguridad discrecional proporciona una sutil granularidad de control dentro de todas las condiciones de la política obligatoria. .in 11 .ti 3 [NCSC3] NCSC, "A Guide to Understanding CONFIGURATION MANAGEMENT in Trusted Systems", NCSC-TG-006, Version-1, 28 de Marzo de 1988, 31 páginas. La gestión de configuración consiste en cuatro tareas separadas: identificación, control, estado de las cuentas, y auditoría. Para cada cambio que se hace a un sistema de procesamiento de datos automático (ADP), se deberían identificar el diseño y los requerimientos de la versión del sistema cambiado. La tarea de control de gestión de la configuración se desarrolla sometiendo cada cambio a documentación, hardware, y software/firmware para revisar y aprobar por una autoridad pertinente. El seguimiento del estado de la configuración es responsable de registrar e informar sobre todos los cambios de la configuración del producto. Por último, aún con el proceso de una auditoría de configuración, se puede verificar el cambio completo para ser correcto funcionalmente, y para sistemas confiables, coherente con la política de seguridad del sistema. .in 11 .ti 3 [NTISS] NTISS, "Advisory Memorandum on Office Automation Security Guideline", NTISSAM CONPUSEC/1-87, 16 de Enero de 1987, 58 páginas. Este documento proporciona una guía a usuarios, administradores, funcionarios de seguridad, y funcionarios de adquisición de Sistemas de Automatización Ofimática. Las áreas a las que se dirige incluyen: seguridad física, personal de seguridad, procedimientos de seguridad, seguridad de hardware/software, seguridad de emanaciones (TEMPEST), y seguridad de comunicaciones en sistemas autónomos AO, Sistemas OA usados como terminales conectados a un sistema informático principal, y Sistemas OA usados como servidores en un Red de Area Local (LAN). Se hace diferenciación entre esos Sistemas de Automatización Ofimática equipados solo con medios de almacenamiento extraibles (p.ej., discos flexibles, cintas de casette, discos duros extraibles) y esos Sistemas de Automatización Ofimática equipados con medios fijos (p.ej., Discos Winchester). .ti 0 Publicaciones adicionales de NCSC: .in 11 .ti 3 [NCSC4] National Computer Security Center, "Glossary of Computer Security Terms", NCSC-TG-004, NCSC, 21 de Octubre de 1988. .in 11 .ti 3 [NCSC5] National Computer Security Center, "Trusted Computer System Evaluation Criteria", DoD 5200.28-STD, CSC-STD-001-83, NCSC, Diciembre de 1985. .in 11 .ti 3 [NCSC7] National Computer Security Center, "Guidance for Applying the Department of Defense Trusted Computer System Evaluation Criteria in Specific Environments", CSC-STD-003-85, NCSC, 25 de Junio de 1985. .in 11 .ti 3 [NCSC8] National Computer Security Center, "Technical Rationale Behind CSC-STD-003-85: Computer Security Requirements", CSC-STD-004-85, NCSC, 25 de Junio de 1985. .in 11 .ti 3 [NCSC9] National Computer Security Center, "Magnetic Remanence Security Guideline", CSC-STD-005-85, NCSC, 15 de Noviembre de 1985. Esta directiva está marcada como una exención "Solo Para Uso Oficial" ("For Official Use Only") bajo la Sección 6 de la Ley Pública 86-36 (50 U.S. Código 402). Distribución autorizada a Agencias gubernamentales de EEUU y sus contratistas para proteger datos técnicos, operativos, o administrativos desclasificados relativos a operaciones de la Agencia Nacional de Seguridad. .in 11 .ti 3 [NCSC10] National Computer Security Center, "Guidelines for Formal Verification Systems", Shipping list no.: 89-660-P, The Center, Fort George G. Meade, MD, 1 de Abril de 1990. .in 11 .ti 3 [NCSC11] National Computer Security Center, "Glossary of Computer Security Terms", Shipping list no.: 89-254-P, The Center, Fort George G. Meade, MD, 21 de Octubre de 1988. .in 11 .ti 3 [NCSC12] National Computer Security Center, "Trusted UNIX Working Group (TRUSIX) rationale for selecting access control list features for the UNIX system", Shipping list no.: 90-076-P, The Center, Fort George G. Meade, MD, 1990. .in 11 .ti 3 [NCSC13] National Computer Security Center, "Trusted Network Interpretation", NCSC-TG-005, NCSC, 31 de Julio de 1987. .in 11 .ti 3 [NCSC14] Tinto, M., "Computer Viruses: Prevention, Detection, and Treatment", National Computer Security Center C1 Technical Report C1-001-89, Junio de 1989. .in 11 .ti 3 [NCSC15] National Computer Security Conference, "12th National Computer Security Conference: Baltimore Convention Center, Baltimore, MD, 10-13 Octubre de 1989: Information Systems Security, Solutions for Today - Concepts for Tomorrow", National Institute of Standards and National Computer Security Center, 1989. .ti 0 8.6 Listas de Comprobación de Seguridad .in 11 .ti 3 [AUCOIN] Aucoin, R., "Computer Viruses: Checklist for Recovery", Computers in Libraries, Vol. 9, No. 2, Pg. 4, 1 de Febrero de 1989. .in 11 .ti 3 [WOOD] Wood, C., Banks, W., Guarro, S., Garcia, A., Hampel, V., and H. Sartorio, "Computer Security: A Comprehensive Controls Checklist", John Wiley and Sons, Interscience Publication, 1987. .ti 0 8.7 Publicaciones Adicionales .in 6 .ti 3 Centro de Información de Red de la Red de Datos de Defensa (DDN NIC) El DDN NIC mantiene los boletines de Seguridad de DDN y los boletines de administración de DDN en linea en la máquina: NIC.DDN.MIL. Están disponibles a través de FTP anónimo. Los boletines de Seguridad de DDN están en el directorio: SCC, y los boletines de Administración de DDN en el directorio: DDN-NEWS. Para más información, puede enviar un mensaje a: NIC@NIC.DDN.MIL, o llamar al DDN NIC al: 1-800-235-3155. .in 11 .ti 3 [DDN88] Defense Data Network, "BSD 4.2 and 4.3 Software Problem Resolution", DDN MGT Bulletin #43, DDN Network Information Center, 3 de Noviembre de 1988. Un Boletín de la Administración de la Red de datos de Defensa que anuncia los parches del software de 4.2bsd y 4.3bsd al gusano de Internet. .in 11 .ti 3 [DDN89] DCA DDN Defense Communications System, "DDN Security Bulletin 03", DDN Security Coordination Center, 17 de Octubre de 1989. .ti 3 Actas del IEEE .in 11 .ti 3 [IEEE] "Proceedings of the IEEE Symposium on Security and Privacy", publicado anualmente. .ti 6 Las actas del IEEE están disponibles en: .in 14 Computer Society of the IEEE P.O. Box 80452 Worldway Postal Center Los Angeles, CA 90080 .ti 3 Otras publicaciones: .in 6 Computer Law and Tax Report Computers and Security Security Management Magazine Journal of Information Systems Management Data Processing & Communications Security SIG Security, Audit & Control Review .ti 0 9. Agradecimientos .in 3 Gracias al ilustre "Escuadrón de Borradores" ("Outline Squad") de SSPHWG, que se reunieron en USC/Instituto de Ciencias de la Información el 12 de Junio del 90: Ray Bates (ISI), Frank Byrum (DEC), Michael A. Contino (PSU), Dave Dalva (Sistemas de Información Confiables (Trusted Information Systems), Inc.), Jim Duncan (Departamento de Matemáticas del Estado de Pensilvania (Penn State Math Department)),Bruce Hamilton (Xerox), Sean Kirkpatrick (Unisys), Tom Longstaff (CIAC/LLNL), Fred Ostapik (SRI/NIC), Keith Pilotti (SAIC), y Bjorn Satdeva (/sys/admin, inc.). Gracias a Rich Pethia y el Equipo de Respuesta de Emergencia Informática (CERT); gran parte del trabajo de Paul Holbrook lo hizo mientras estaba trabajando para el CERT. También por haber proporcionado una revisión muy minuciosa de este documento. Gracias también a Jon Postel y USC/Instituto de Ciencias de la Información por contribuir con soporte moral e instalaciones a este esfuerzo. Por último, pero NO menos importante, me gustaría agradecer a los miembros del SSPHWG y Amigos sus contribuciones adicionales: Vint Cerf (CNRI), Dave Grisham (UNM), Nancy Lee Kirkpatrick (transcritora extraordinaria), Chris McDonald (WSMR), H. Craig McKee (Mitre), Gene Spafford (Purdue), y Aileen Yuan (Mitre). .ti 0 10. Consideraciones de Seguridad .in 3 Si las consideraciones de seguridad no hubiesen sido ignoradas tan ampliamente en Internet, este documento no habría sido posible. .ti 0 11. Direcciones de los Autores .nf J. Paul Holbrook CICNet, Inc. 2901 Hubbard Ann Arbor, MI 48105 Teléfono: (313) 998-7680 EMail: holbrook@cic.net Joyce K. Reynolds University of Southern California Information Sciences Institute 4676 Admiralty Way Marina del Rey, CA 90292 Teléfono: (213) 822-1511 Correo Electrónico: JKREY@ISI.EDU Traducción al castellano: Fernando Cerezal López Correo Electrónico: nabla17@hotmail.com