Rfc2196 TXT en Es

Grupo de Trabajo de la Red B.
Fraser
Petición de Comentarios: 2196 Editor
Para su información: 8 SEI / CMU
Obsoletes: 1244 de septiembre de de 1997
Categoría: Informativo
Manual de seguridad del sitio
Estado de este documento
Este memorándum proporciona información para la comunidad de Internet. No especifica un estándar de Internet
de ningún tipo. La distribución de este memo es ilimitada.
Resumen
Este manual es una guía para el desarrollo de políticas y procedimientos de seguridad informática para los sitios que
tienen sistemas en Internet. El propósito de este manual es proporcionar orientación práctica a los administradores
tratan de asegurar su información y servicios. Los temas cubiertos incluyen contenido de las políticas y la formación,
una amplia gama de temas de seguridad de redes y sistemas técnicos, y la respuesta a incidentes de seguridad.
Tabla de contenido
1. Introducción............................................... 2 .....
1.1 Objetivo de este trabajo ............................................ 3
1,2 audiencia ................................................ ........ 3
1.3 Definiciones ................................................ 3 .....
1.4 Trabajo relacionado ............................................... ..... 4
1.5 Enfoque básico ............................................... ... 4
1.6 Evaluación de Riesgos ............................................... 5 ..
2. Políticas de Seguridad .............................................. . 6
2.1 ¿Qué es una Política de Seguridad y por qué tiene uno? ..................... 6
2.2 ¿Qué hace que una buena directiva de seguridad? .............................. 9
2.3 Mantenimiento de la Política flexible ..................................... 11
3. Arquitectura ............................................... ..... 11
3.1 Objetivos ................................................ ...... 11
3.2 Configuración de la red y el servicio ............................... 14
3.3 Los cortafuegos ................................................ ....... 20
4. Servicios de Seguridad y Procedimientos ................................ 24
4.1 Autenticación ................................................ 24 ..
4.2 Confidencialidad ................................................ . 28
4.3 Integridad ................................................ ....... 28
Fraser, Ed. informativo [Página 1]

RFC 2196 Manual de seguridad del sitio de septiembre de de 1997
4.4 Autorización ................................................ ... 29

4.5 Acceso ................................................ .......... 30
4.6 Auditoría ................................................ ........ 34
4.7 Las copias de seguridad Asegurando ............................................... . 37
5. Seguridad de Manejo de Incidentes ...................................... 37
5.1 Preparación y Planificación de Manejo de Incidentes .................... 39
5.2 Notificación y Puntos de Contacto .............................. 42
5.3 Identificación de un incidente ......................................... 50
5.4 Manipulación de un incidente ............................................ 52
5.5 Consecuencias de un incidente ........................................ 58
5.6 Responsabilidades ................................................ 59
6. Las actividades en curso .............................................. 60
7. Herramientas y ubicaciones ............................................. 60
8. Listas de correo y otros recursos ............................... 62
9. Referencias ............................................... ....... 64
1. Introducción
Este documento proporciona una guía a los administradores de sistemas y redes sobre la manera de abordar los
problemas de seguridad dentro de la comunidad de Internet. Se construye sobre la base proporcionada en el RFC
1244 y es el trabajo colectivo de una serie de autores que han contribuido. Esos autores incluyen: Jules P. Aronson
( aronson@nlm.nih.gov ), Nevil Brownlee ( n.brownlee@auckland.ac.nz ), Frank Byrum ( byrum@norfolk.infi.net ),
Joao Nuno Ferreira ( Ferreira @ rccn.net ), Barbara Fraser ( byf@cert.org ), Steve Glass ( glass@ftp.com ), Erik
Guttman ( erik.guttman@eng.sun.com ), Tom Killalea ( tomk@nwnet.net ), KlausPeter Kossakowski (
kossakowski@cert.dfn.de), Lorna Leona ( lorna@staff.singnet.com.sg ), Edward.P.Lewis
( Edward.P.Lewis.1@gsfc.nasa.gov ), Gary Malkin ( gmalkin@xylogics.com ), Russ Mundy ( mundy@tis.com ), Philip

J. Nesser ( pjnesser@martigny.ai.mit.edu ), y Michael S. Ramsey ( msr@interpath.net ).
Además de los autores principales, una serie de los colaboradores valiosos comentarios. Aquellos usuarios
incluyen: Eric Luiijf ( luiijf@fel.tno.nl ), Marijke Kaat ( marijke.kaat@sec.nl ), Ray Plzak ( plzak@nic.mil ) y Han
Pronk ( hmpronk@vka.nl ).
Un agradecimiento especial va a Joyce Reynolds, ISI, y Paul Holbrook, CICnet, por su visión, liderazgo y esfuerzo en
la creación de la primera versión de este manual. Es la esperanza sincera del grupo de trabajo que esta versión será
tan útil a la comunidad al igual que el anterior.

1.1 Objetivo de este trabajo
Este manual es una guía para el establecimiento de políticas y procedimientos de seguridad informática para los
sitios que tienen sistemas en Internet (sin embargo, la información proporcionada debe ser también útil para los sitios
aún no conectados a Internet). Esta guía enumera los problemas y factores que un sitio debe tener en cuenta al
establecer sus propias políticas. Se hace una serie de recomendaciones y proporciona discusiones de las áreas
pertinentes.
Esta guía es solamente un marco para el establecimiento de políticas y procedimientos de seguridad. Con el fin de
tener un conjunto eficaz de políticas y procedimientos, un sitio tendrá que tomar muchas decisiones, de acuerdo
ganancia, y luego comunicar e implementar estas políticas.
1.2 Audiencia
La audiencia de este documento son los administradores de sistemas y redes, y tomadores de decisiones (por lo
general "mandos medios") a los sitios. Por razones de brevedad, vamos a utilizar el término "administrador" en este
documento para referirse a los administradores del sistema y de red.
Este documento no está dirigido a programadores o los que tratan de crear programas o sistemas seguros. El
objetivo de este documento es sobre las políticas y procedimientos que deben estar en su lugar para apoyar la
seguridad técnica cuenta que un sitio puede ser implementado.
Los destinatarios principales de este trabajo son los sitios que son miembros de la comunidad de Internet. Sin
embargo, este documento debe ser útil a cualquier sitio que permite la comunicación con otros sitios. Como una
guía general de las políticas de seguridad, este documento también puede ser útil para los sitios con los sistemas
aislados.
1.3 Definiciones
A los efectos de esta guía, un "sitio" es cualquier organización que posee equipos o recursos relacionados con la
red. Estos recursos pueden incluir equipos host que utilizan los usuarios, enrutadores, servidores de terminales,
ordenadores u otros dispositivos que tienen acceso a Internet. Un sitio puede ser un usuario final de los servicios de
Internet o un proveedor de servicios tal como una red de nivel medio. Sin embargo, la mayor parte del objeto de esta
guía es de aquellos usuarios finales de servicios de Internet. Suponemos que el sitio tiene la capacidad de
establecer políticas y procedimientos para sí mismo con la concurrencia y el apoyo de los que realmente poseen los
recursos. Se supondrá que los sitios que forman parte de las organizaciones más grandes sabrán cuando necesitan
consultar, colaborar, o tomar las recomendaciones de la entidad más grande.

El "Internet" es una colección de miles de redes conectadas por un conjunto común de protocolos técnicos que
hacen posible que los usuarios de cualquiera de las redes para comunicarse con, o utilizar los servicios ubicados en
cualquiera de las otras redes (FYI4, RFC 1594).
El término "administrador" se utiliza para cubrir todas aquellas personas que son responsables de la operación
del día a día del sistema y los recursos de red. Esto puede ser un número de individuos o una organización.
El término "administrador de seguridad" se utiliza para cubrir todas aquellas personas que son responsables de la
seguridad de la información y tecnología de la información. En algunos sitios de esta función se puede combinar
con el administrador (por encima); por lo demás, esto va a ser una posición separada.
El término "tomador de decisiones" se refiere a aquellas personas en un sitio que establecer o aprobar la política.
Estos son a menudo (pero no siempre) las personas que poseen los recursos.
1.4 Trabajo relacionado
El Grupo de Trabajo Manual de seguridad del sitio está trabajando en una Guía del usuario de Internet Security.
Además, proporcionará una guía práctica a los usuarios finales para ayudar a proteger su información y los recursos
que utilizan.
1.5 Enfoque básico
Esta guía está escrita para proporcionar una orientación básica en el desarrollo de un plan de seguridad para su
sitio. Un enfoque generalmente aceptada de seguimiento es sugerido por Fites, et. Alabama. [Fites 1989] e
incluye los siguientes pasos:
(1) Identificar lo que está tratando de proteger. (2) Determinar lo que está tratando de
protegerlo de. (3) Determinar la probabilidad de que las amenazas son.
(4) Poner en práctica medidas que protejan sus activos en un costo

Manera efectiva.
(5) Revisar el proceso de forma continua y mejoras hacen cada vez
una debilidad se encuentra.
La mayor parte de este documento se centra en el punto 4 anterior, pero los otros pasos no se pueden evitar si un
plan eficaz se ha de establecer en su sitio. Una obviedad de edad en la seguridad es que el costo de protegerse
contra una amenaza debe ser menor que el costo de la recuperación si la amenaza fuera para herir. Costo en este
contexto debe recordarse para incluir las pérdidas expresadas en moneda real, la reputación, la honradez, y otras
medidas menos evidentes. Sin el conocimiento razonable de lo que está protegiendo y cuáles son las amenazas
probables son, siguiendo esta regla podría ser difícil.

1.6 Evaluación de Riesgos
1.6.1 Discusión General
Una de las razones más importantes para la creación de una política de seguridad informática es asegurar que los
esfuerzos invertidos en beneficios de costo efectivo de rendimiento de seguridad. Aunque esto puede parecer obvio,
es posible ser inducido a error acerca de dónde se necesita el esfuerzo. A modo de ejemplo, hay una gran cantidad
de publicidad sobre intrusos en los sistemas informáticos; sin embargo, la mayoría de las encuestas muestran de
seguridad informática que, para la mayoría de las organizaciones, la pérdida real de "información privilegiada" es
mucho mayor.
El análisis de riesgos consiste en determinar lo que hay que proteger, lo que necesita para protegerlo de, y cómo
protegerlo. Es el proceso de examinar todos sus riesgos, a continuación, la clasificación de los riesgos por el nivel de
gravedad. Este proceso implica tomar decisiones rentables en lo que quiere proteger. Como se mencionó
anteriormente, usted probablemente no debería pasar más a algo de protección contra de lo que es realmente vale
la pena.
Un tratamiento completo del análisis de riesgos se encuentra fuera del alcance de este documento. [Fites 1989] y
[1989 Pfleeger] proporcionan introducciones a este tema. Sin embargo, hay dos elementos de un análisis de
riesgos que será brevemente cubierto en las dos secciones siguientes:
(1) La identificación de los activos (2) La

identificación de las amenazas
Para cada activo, los objetivos básicos de la seguridad son la disponibilidad, confidencialidad e integridad. Cada
amenaza debe ser examinado con un ojo a la forma en que la amenaza podría afectar estas áreas.
1.6.2 Identificación de los Activos
Un paso en un análisis de riesgos es identificar todas las cosas que necesitan ser protegidos. Algunas cosas son
evidentes, como la valiosa información de propiedad, la propiedad intelectual, y todas las diferentes piezas de
hardware; pero, algunos se pasan por alto, como por ejemplo las personas que realmente utilizan los sistemas. El
punto esencial es hacer una lista de todas las cosas que podrían ser afectados por un problema de seguridad.
Una lista de categorías es sugerido por Pfleeger [Pfleeger 1989]; esta lista está adaptado de esa fuente:
(1) Hardware: CPU, tableros, teclados, terminales,

estaciones de trabajo, ordenadores personales, impresoras, unidades de disco, líneas de
comunicación, servidores, routers terminales.

(2) Software: programas de código, programas, objetos

servicios públicos, programas de diagnóstico, sistemas operativos, programas de
comunicación.
(3) Datos: durante la ejecución, almacenados en línea, archivados fuera de línea,

copias de seguridad, los registros de auditoría, bases de datos, en tránsito a través de medios de
comunicación.
(4) personas: usuarios, los administradores, los mantenedores de hardware.
(5) Documentación: sobre programas, hardware, sistemas locales

procedimientos administrativos.
(6) Materiales: papel, formularios, cintas, medios magnéticos.
1.6.3 Identificación de las amenazas
Una vez identificados los activos que requieren protección, es necesario identificar las amenazas a esos activos.
Las amenazas pueden examinarse para determinar que existe potencial de pérdida. Ayuda a tener en cuenta de
qué amenazas que están tratando de proteger sus activos. Las siguientes son las amenazas clásicas que deben
ser considerados. Dependiendo de su sitio, habrá más amenazas específicas que deben ser identificadas y
tratadas.
(1) El acceso no autorizado a los recursos y / o información (2) Unintented y / o divulgación no

autorizada de información (3) Denegación de servicio
2. Políticas de Seguridad
A lo largo de este documento habrá muchas referencias a las políticas. A menudo, estas referencias se incluyen
recomendaciones para políticas específicas. En vez de orientación de repetición en la forma de crear y comunicar
una política de este tipo, el lector debe solicitar el asesoramiento presentado en este capítulo en el desarrollo de
cualquier política recomienda más adelante en este libro.
2.1 ¿Qué es una Política de Seguridad y por qué tiene uno?
Las decisiones relacionadas con la seguridad que haga, o no puede hacer, como administrador determina en gran
medida el grado de seguridad o inseguridad de la red es, la cantidad de funcionalidad que ofrece su red, y lo fácil
de su red es de uso. Sin embargo, no se puede tomar buenas decisiones acerca de la seguridad sin antes
determinar cuáles son sus objetivos de seguridad son. Hasta que determine cuáles son sus objetivos de seguridad
son, no se puede hacer un uso eficaz de cualquier colección de herramientas de seguridad, ya que simplemente no
va a saber qué buscar y qué restricciones a imponer.

Por ejemplo, sus objetivos serán probablemente muy diferente de los objetivos de un proveedor del producto. Los
vendedores están tratando de hacer la configuración y el funcionamiento de sus productos lo más simple posible, lo
que implica que las configuraciones por defecto suelen ser lo más abierto (es decir, inseguro) como sea posible. Si
bien esto hace que sea más fácil de instalar nuevos productos, también deja el acceso a esos sistemas, y otros
sistemas a través de ellos, abiertos a cualquier usuario que se pasea por.
Sus objetivos serán determinados en gran medida por las siguientes ventajas y desventajas clave:
(1) servicios que se ofrecen en comparación con la seguridad proporcionada -

Cada servicio ofrecido a los usuarios conlleva sus propios riesgos de seguridad. Para algunos servicios el
riesgo mayor que el beneficio del servicio y el administrador puede optar por eliminar el servicio en lugar de
tratar de asegurarlo.
(2) la facilidad de uso en comparación con la seguridad -

El sistema más fácil de usar permitiría el acceso a cualquier usuario y no requieren contraseñas; es decir,
no habría seguridad. Que exige contraseñas hace que el sistema un poco menos conveniente, pero más
seguro. Que exige contraseñas de un solo uso generada por el dispositivo hace que el sistema sea aún
más difícil de usar, pero mucho más seguro.
(3) el costo de la seguridad frente al riesgo de pérdida -

Hay muchos costos diferentes a la seguridad: monetaria (es decir, el costo de adquisición de hardware y
software de seguridad como cortafuegos y de una sola vez generadores de contraseñas), rendimiento (es
decir, el cifrado y la toma de descifrado tiempo), y la facilidad de uso (como se mencionó anteriormente) .
También hay muchos niveles de riesgo: pérdida de privacidad (es decir, la lectura de la información por
personas no autorizadas), pérdida de datos (es decir, la corrupción o el borrado de la información), y la
pérdida de servicio (por ejemplo, el llenado de almacenamiento de datos el espacio, el uso de los recursos
computacionales, y la negación de acceso a la red). Cada tipo de costo debe sopesarse frente a cada tipo
de pérdida.
Sus objetivos deben ser comunicados a todo el personal de los usuarios, las operaciones y los gerentes a través de
un conjunto de reglas de seguridad, llamada "política de seguridad". Estamos utilizando este término, en lugar de la
"Política de seguridad" más estrecho ya que el ámbito de aplicación incluye todos los tipos de tecnología de la
información y de los datos almacenados y manipulados por la tecnología.
2.1.1 Definición de una Política de Seguridad
Una política de seguridad es una declaración formal de las reglas por las que las personas que tienen acceso a los
activos de tecnología y de información de una organización deben cumplir.

2.1.2 Propósitos de una Política de Seguridad
El objetivo principal de una política de seguridad es informar a los usuarios, el personal y los administradores de sus
requisitos obligatorios para la protección de los activos de tecnología e información. La política debe especificar los
mecanismos mediante los cuales se pueden cumplir estos requisitos. Otro propósito es proporcionar una línea de
base desde la cual los sistemas y redes de ordenadores adquirir, configurar y auditoría para el cumplimiento de la
política. Por lo tanto, un intento de utilizar un conjunto de herramientas de seguridad en ausencia de al menos una
política de seguridad implícita carece de sentido.
Una Política de Uso Apropiado (AUP) también puede ser parte de una política de seguridad. Debería explicar lo que
los usuarios deben y no deben hacer en los diversos componentes del sistema, incluyendo el tipo de tráfico
permitidos en las redes. El AUP debe ser lo más explícito posible para evitar la ambigüedad o malentendido. Por
ejemplo, un AUP podría enumerar cualquier grupos de noticias USENET prohibidas. (Nota: Adecuada política de uso
se conoce como política de uso aceptable por algunos sitios.)
2.1.3 ¿Quién debe participar cuando se forma la política?
Para que una política de seguridad que sea apropiado y efectivo, tiene que tener la aceptación y el apoyo de todos
los niveles de empleados dentro de la organización. Es especialmente importante que la gestión empresarial es
totalmente compatible con el proceso de la política de seguridad de lo contrario hay pocas posibilidades de que van
a tener el impacto deseado. La siguiente es una lista de las personas que deberían participar en la creación y
revisión de los documentos de política de seguridad:
administrador de seguridad (1) sitio

personal técnico (2) tecnología de la información (por ejemplo, el personal de
Computing Center)
(3) administración de grandes grupos de usuarios dentro de la organización
(Por ejemplo, áreas de negocio, departamento de ciencias de la computación dentro de una universidad,
etc.)
equipo de respuesta a incidentes (4) la seguridad
(5) los representantes de los grupos de usuarios afectados por la seguridad
política
(6) gestión responsable (7) asesor legal (en su caso)
La lista anterior es representativa de muchas organizaciones, pero no es necesariamente exhaustiva. La idea es

traer a la representación de las partes interesadas clave, gestión que tienen presupuesto y la política de la autoridad,
el personal técnico que sabe lo que puede y no puede ser soportada, y abogados que conocen las ramificaciones
legales de diversas políticas

opciones. En algunas organizaciones, puede ser conveniente incluir personal de auditoría EDP. La participación de
este grupo es importante si las declaraciones de política resultantes son para llegar a la más amplia aceptación
posible. También es relevante mencionar que el papel de un abogado también puede variar de un país a otro.
2.2 ¿Qué hace una buena directiva de seguridad?
Las características de una buena política de seguridad son:
(1) Debe ser implementable a través de la administración del sistema

procedimientos, la publicación de pautas de uso aceptable, u otros métodos apropiados.
(2) Debe ser enforcible con herramientas de seguridad, en su caso,

y con sanciones, donde la prevención real no es técnicamente factible.
(3) Se debe definir claramente los ámbitos de responsabilidad de la

usuarios, administradores y gestión.
Los componentes de una buena política de seguridad incluyen:
(1) tecnología de la computación de compra Directrices que especifique

se requiere, o preferida, elementos de seguridad. Estos deben complementar las políticas y
directrices de compra existentes.
(2) Una política de privacidad que define las expectativas razonables de

privacidad con respecto a cuestiones tales como la vigilancia del correo electrónico, el registro de pulsaciones de
teclas, y el acceso a los archivos de los usuarios.
(3) una política de acceso, que define los derechos y privilegios de acceso a
proteger los activos de la pérdida o de la divulgación mediante la especificación de pautas de uso
aceptable para los usuarios, el personal de operaciones y gestión. Debe proporcionar directrices para las
conexiones externas, comunicaciones de datos, dispositivos de conexión a una red, y la adición de un
nuevo software para sistemas. También debe especificar los mensajes de notificación requeridos (por
ejemplo, mensajes de conexión deben proporcionar advertencias sobre el uso autorizado y supervisión de
la línea, y no simplemente decir "Bienvenido").
(4) Política de Responsabilidad Una que define las responsabilidades de

usuarios, el personal de operaciones y gestión. Se debe especificar una capacidad de auditoría, y
proporcionar pautas de manejo de incidentes (es decir, qué hacer ya quién contactar si se detecta una
posible intrusión).

(5) una política de autenticación que establece la confianza a través de una

política de contraseñas efectiva, y mediante el establecimiento de directrices para la autenticación remota
ubicación y el uso de dispositivos de autenticación (por ejemplo, contraseñas de un solo uso y los
dispositivos que los generan).
(6) Una declaración de disponibilidad que establece expectativas de los usuarios para la
disponibilidad de recursos. Se debe abordar las cuestiones de redundancia y recuperación, así como
especificar las horas de operación y mantenimiento períodos de interrupción prolongada. También debe
incluir información de contacto para informar de los fallos del sistema y de red.
Política de Mantenimiento (7) Un Sistema y Red de Tecnología de la Información

que describe cómo se les permite tanto a las personas de mantenimiento interno y externo de manejar y
tecnología de acceso. Uno de los temas importantes que abordar es si se permite el mantenimiento remoto
y cómo ese acceso está controlado. Otra área a la consideración aquí es la externalización y cómo se
gestiona.
(8) Violaciónes A Reporting Política que indica qué tipos de

violaciónes (por ejemplo, la privacidad y la seguridad, interna y externa) se deben divulgar y al que se
efectúan los informes. Un ambiente no amenazante y la posibilidad de denuncia anónima se traducirá en
una mayor probabilidad de que se informó de una violación si se detecta.
(9) información de apoyo que proporciona a los usuarios, el personal y

gestión de la información de contacto para cada tipo de violación de la política; directrices sobre cómo
manejar fuera de duda acerca de un incidente de seguridad, o información que pueda ser considerada
confidencial o privada; y referencias cruzadas a los procedimientos de seguridad e información relacionada,
tales como políticas de la empresa y las leyes y reglamentos gubernamentales.
Puede haber requisitos reglamentarios que afectan a algunos aspectos de su política de seguridad (por ejemplo, el
seguimiento de la línea). Los creadores de la política de seguridad deben considerar buscar ayuda legal en la
creación de la política. Como mínimo, la política debe ser revisada por un asesor legal.
Una vez que se ha establecido su política de seguridad debería ser claramente comunicada a los usuarios, el
personal y la dirección. Tener todo el personal firmen una declaración que indica que ha leído, comprendido y
aceptado cumplir con la política es una parte importante del proceso. Por último, su política debe ser revisada de
forma periódica para ver si se está apoyando con éxito sus necesidades de seguridad.

2.3 Mantenimiento de la Política flexible
Para que una política de seguridad sea viable en el largo plazo, se requiere una gran flexibilidad en base a un
concepto de seguridad arquitectónico. Una política de seguridad debe ser independiente (en gran parte) a partir de
situaciones de hardware y software específicos (como los sistemas específicos tienden a ser reemplazado o se
mueven durante la noche). Los mecanismos para la actualización de la política deben estar claramente definidos.
Esto incluye el proceso, las personas involucradas, y las personas que deben sign-off en los cambios.
También es importante reconocer que hay excepciones a la regla. Siempre que sea posible, la política debe explicar
qué existen excepciones a la política general. Por ejemplo, en qué condiciones es un administrador del sistema les
permite ir a través de archivos de un usuario. Además, puede haber algunos casos cuando varios usuarios tendrán
acceso a la misma ID de usuario. Por ejemplo, en sistemas con un usuario "root", varios administradores del sistema
pueden conocer la contraseña y usar la cuenta de root.
Otra consideración es llamado el "Síndrome del camión de basura." Esto se refiere a lo que sucedería a un sitio si
una persona clave fue repentinamente inasequible para el / ella función de trabajo (por ejemplo, estaba enfermo de
repente o se deja la compañía de forma inesperada). Mientras que los mayores reside en la difusión de seguridad
mínimo de información, el riesgo de perder información crítica aumenta cuando esa información no es compartida.
Es importante determinar cuál es el equilibrio adecuado es para su sitio.
3. Arquitectura
3.1 Objetivos
3.1.1 Planes de Seguridad completamente definido
Todos los sitios deben definir un plan de seguridad integral. Este plan debe estar a un nivel más alto que las
políticas específicas discutidas en el capítulo 2, y debe ser elaborado como un marco de orientaciones generales
en las que caben políticas específicas.
Es importante tener este marco en su lugar para que las políticas individuales pueden ser compatibles con la
arquitectura global de seguridad del sitio. Por ejemplo, tener una política fuerte en materia de acceso a Internet
y tener restricciones débiles en el uso del módem es incompatible con la filosofía general de las fuertes
restricciones de seguridad en el acceso externo.
Un plan de seguridad debe definir: la lista de servicios de red que serán proporcionados; qué áreas de la
organización proporcionará los servicios; quién tendrá acceso a esos servicios; cómo se proporcionará acceso; quién
va a administrar esos servicios; etcétera

El plan también debe abordar cómo se manejará el incidente. Capítulo 5 proporciona una discusión a fondo de este
tema, pero es importante para cada sitio para definir clases de incidentes y las respuestas correspondientes. Por
ejemplo, los sitios con servidores de seguridad deben fijar un umbral en el número de intentos realizados para
frustrar el servidor de seguridad antes de desencadenar una respuesta? Escala personalizado niveles deben ser
definidos para ambos ataques y respuestas. Sitios sin cortafuegos tendrán que determinar si un solo intento de
conectarse a un host constituye un incidente? ¿Qué pasa con una exploración sistemática de los sistemas?
Para los sitios conectados a Internet, la ampliación de medios desenfrenada de los incidentes de seguridad
relacionados con Internet puede eclipsar un problema (potencialmente) más grave la seguridad interna. Asimismo,
las empresas que nunca han sido conectados a Internet pueden tener políticas internas, fuertes y bien definidos,
pero no abordan adecuadamente una política de conexión externa.
3.1.2 Separación de Servicios
Hay muchos servicios de los que un sitio tal vez desee proporcionar a sus usuarios, algunos de los cuales
pueden ser externos. Hay una variedad de razones de seguridad para intentar aislar los servicios en los equipos
host dedicado. También hay razones de rendimiento en la mayoría de los casos, pero una discusión detallada
está fuera de alcance de este documento.
Los servicios que un sitio puede proporcionar voluntad, en la mayoría de los casos, tienen diferentes niveles de
necesidades de acceso y modelos de confianza. Los servicios que son esenciales para la seguridad o el buen
funcionamiento de un sitio estaría mejor de ser colocado en una máquina dedicada con un acceso muy limitado
(véase la Sección 3.1.3 "negar todos" modelo), en lugar de en una máquina que proporciona un servicio ( o
servicios), que ha sido tradicionalmente menos seguro, o requiere una mayor accesibilidad por los usuarios que
pueden accidentalmente seguridad Suborn.
También es importante distinguir entre los hosts que operan dentro de los diferentes modelos de confianza
(por ejemplo, todos los hosts dentro de un servidor de seguridad y cualquier anfitrión en una red expuesta).
Algunos de los servicios que deben examinarse para la separación de potencial se describen en la sección 3.2.3. Es
importante recordar que la seguridad es sólo tan fuerte como el eslabón más débil de la cadena. Varias de las
penetraciones más publicitados en los últimos años han sido a través de la explotación de las vulnerabilidades de los
sistemas de correo electrónico. Los intrusos no estaban tratando de robar el correo electrónico, sino que utilizan la
vulnerabilidad en ese servicio para acceder a otros sistemas.
Fraser, Ed. informativo [Pagina 12]

Si es posible, cada servicio debe estar ejecutándose en una máquina diferente, cuyo único deber es
proporcionar un servicio específico. Esto ayuda a los intrusos aislar y daño potencial límite.
3.1.3 Denegar / Permitir todo
Hay dos filosofías subyacentes diametralmente opuestos que se pueden adoptar en la definición de un plan de
seguridad. Ambas alternativas son modelos legítimas para adoptar, y la elección entre ellas dependerán del sitio y
sus necesidades de seguridad.
La primera opción es apagar todos los servicios y luego habilitar selectivamente servicios sobre una base de caso
por caso, ya que se necesitan. Esto puede hacerse a nivel de host o de la red según el caso. Este modelo, que
aquí después de ser referido como el "denegar todo" modelo, generalmente es más seguro que el otro modelo se
describe en el párrafo siguiente. Se requiere más trabajo para implementar con éxito un "denegar todo" de
configuración, así como una mejor comprensión de los servicios. Permitir sólo servicios conocidos proporciona
para un mejor análisis de un servicio / protocolo particular y el diseño de un mecanismo de seguridad adecuado
para el nivel de seguridad del sitio.
El otro modelo, que aquí después de ser referido como el "permitir todo" del modelo, es mucho más fácil de
implementar, pero es generalmente menos seguro que el modelo de "negar todos". Basta con girar en todos los
servicios, por lo general el valor por defecto a nivel de host, y permitir que todos los protocolos de los viajes a través
de los límites de la red, por lo general el valor por defecto a nivel de router. Como los agujeros de seguridad se
hacen evidentes, están restringidos o parcheado, ya sea en el anfitrión o nivel de red.
Cada uno de estos modelos se pueden aplicar a diferentes partes del sitio, dependiendo de los requisitos de
funcionalidad, control administrativo, la política de sitio, etc. Por ejemplo, la política puede ser el uso de la "Permitir
todos" modelo cuando la configuración de las estaciones de trabajo para uso general, pero adoptar un "denegar
todo" modelo cuando la configuración de servidores de información, como un concentrador de correo electrónico. Del
mismo modo, un "Permitir todos" política puede ser adoptada para el tráfico entre la LAN interna al sitio, sino un
"denegar todo" la política pueden ser adoptados entre el sitio y el Internet.
Tenga cuidado al mezclar filosofías como en los ejemplos anteriores. Muchos sitios de adoptar la teoría de una
cáscara dura "crujiente" y un suave "blanda" del medio. Ellos están dispuestos a pagar el costo de la seguridad para
su tráfico externo y requieren fuertes medidas de seguridad, pero no están dispuestos o no pueden proporcionar
protecciones similares internamente. Esto funciona bien siempre y cuando las defensas exteriores no se violen y los
usuarios internos pueden ser de confianza. Una vez que se rompe la cubierta exterior (firewall), subvertir el red
interna es trivial.

3.1.4 Identificar las necesidades reales de Servicios
Hay una gran variedad de servicios que se pueden proporcionar, tanto a nivel interno y en Internet en general.
La gestión de la seguridad es, en muchos aspectos, la gestión del acceso a los servicios internos para el sitio y
la gestión de la información de acceso a los usuarios cómo interna en sitios remotos.
Los servicios tienden a precipitarse como ondas a través de Internet. A través de los años, muchos sitios han
establecido servidores FTP anónimo, servidores Gopher, WAIS servidores, servidores WWW, etc., ya que se hizo
popular, pero no es especialmente necesario, en todos los sitios. Evaluar todos los nuevos servicios que se
establecen con una actitud escéptica para determinar si son realmente necesarios o simplemente la moda actual
barriendo el Internet.
Tenga en cuenta que la complejidad de seguridad puede crecer de forma exponencial con el número de servicios
prestados. enrutadores de filtrado deben ser modificados para apoyar a los nuevos protocolos. Algunos protocolos
son inherentemente difíciles de filtrar de manera segura (por ejemplo, RPC y servicios UDP), proporcionando así
más aberturas a la red interna. Los servicios prestados en la misma máquina pueden interactuar de manera
catastrófica. Por ejemplo, permitir FTP anónimo en la misma máquina que el servidor WWW puede permitir que un
intruso para colocar un archivo en el área de FTP anónimo y hacer que el servidor HTTP para ejecutarlo.
3.2 Red y de configuración de servicios
3.2.1 Protección de la Infraestructura
Muchos administradores de red hacen todo lo posible para proteger a los anfitriones en sus redes. Pocos
administradores hacen ningún esfuerzo para proteger a las propias redes. Hay una cierta lógica a esto. Por ejemplo,
es mucho más fácil de proteger a un huésped que una red. Además, los intrusos son propensos a ser después de
los datos de los anfitriones; dañar la red no servirá a sus propósitos. Dicho esto, todavía hay razones para proteger
las redes. Por ejemplo, un desvío de tráfico de la red de intrusos por la acción de una máquina externa con el fin de
examinar los datos (es decir, a la búsqueda de contraseñas). Además, la infraestructura incluye más de las redes y
los routers que los interconectan. La infraestructura también incluye la gestión de la red (por ejemplo, SNMP), los
servicios (por ejemplo, DNS, NFS, NTP, WWW), y la seguridad (es decir, autenticación de usuarios y restricciones
de acceso).
La infraestructura también necesita protección contra el error humano. Cuando un administrador misconfigures un
equipo, este equipo puede ofrecer servicio degradado. Esto sólo afecta a los usuarios que requieren que el
anfitrión y, a menos

que anfitrión es un servidor principal, el número de usuarios afectados, por lo tanto estará limitada. Sin embargo, si
está mal configurado un router, todos los usuarios que requieren de la red se verá afectada. Obviamente, este es un
número mucho mayor de usuarios que las dependiendo de cualquier host uno.
3.2.2 La protección de la Red
Hay varios problemas a los que las redes son vulnerables. El problema clásico es un ataque de "denegación de
servicio". En este caso, la red se lleva a un estado en el que ya no puede transportar datos de los usuarios
legítimos. Hay dos formas comunes de esto se puede hacer: atacar por los routers y por inundar la red con tráfico
superfluo. Tenga en cuenta que el término "enrutador" en esta sección se usa como un ejemplo de una clase más
amplia de componentes de interconexión activa de la red, que también incluye componentes como cortafuegos,
proxyservers, etc.
Un ataque en el router está diseñado para hacer que se detenga el envío de paquetes, o que transmita de manera
incorrecta. El primer caso puede ser debido a una mala configuración, la inyección de una actualización de
enrutamiento espuria, o un "ataque de inundación" (es decir, el router es bombardeado con paquetes no enrutables,
causando su rendimiento para degradar). Un ataque de inundación en una red es similar a un ataque de inundación
en un router, excepto que los paquetes de inundación se transmiten normalmente. Un ataque de inundación ideal
sería la inyección de un solo paquete que explota alguna falla conocida en los nodos de red y hace que retransmitir
el paquete, o generar paquetes de error, cada uno de los cuales está recogido y repetido por otro host. Un paquete
de ataque bien elegido puede incluso generar una explosión exponencial de las transmisiones.
Otro problema clásico es "spoofing". En este caso, las actualizaciones de enrutamiento espurios se envían a uno o
más routers haciendo que los paquetes misroute. Esto difiere de una denegación de servicio atacan sólo en el
propósito detrás de la ruta espuria. En denegación de servicio, el objetivo es hacer que el router inservible; un estado
que será rápidamente detectado por los usuarios de la red. En spoofing, la ruta espuria hará que los paquetes se
encaminan a un host desde el que un intruso puede monitorizar los datos en los paquetes. Estos paquetes se
vuelven a enrutar a sus destinos correctos. Sin embargo, el intruso puede o no puede haber alterado el contenido de
los paquetes.
La solución a la mayoría de estos problemas es la de proteger los paquetes de actualización de encaminamiento

enviado por los protocolos de encaminamiento en uso (por ejemplo, RIP-2, OSPF). Hay tres niveles de protección:
contraseña de texto, suma de comprobación criptográfica, y el cifrado. Las contraseñas ofrecen una protección
mínima contra intrusos única que no tienen acceso directo a las redes físicas. Las contraseñas también ofrecen
cierta protección contra los enrutadores mal configurados (es decir, routers, que, fuera de la caja, intento de

enrutar paquetes). La ventaja de las contraseñas es que tienen una sobrecarga muy baja, tanto en el consumo de
ancho de banda y CPU. Sumas de comprobación proteger contra la inyección de paquetes falsos, incluso si el
intruso tiene acceso directo a la red física. En combinación con un número de secuencia, u otro identificador único,
una suma de control también puede proteger de nuevo los ataques de "repetición", en donde un viejo (pero válida
en el momento) actualización de enrutamiento es retransmitido por cualquiera de un intruso o un router mal
comportamiento. La mayoría de la seguridad es proporcionada por el cifrado completo de cambios secuenciales, o
una identificación única, enrutamiento. Esto evita que un intruso determinar la topología de la red. La desventaja de
cifrado es la sobrecarga implicada en el procesamiento de las actualizaciones.
RIP-2 (RFC 1723) y OSPF (RFC 1583) ambas de apoyo contraseñas en texto claro en sus especificaciones de
diseño base. Además, hay extensiones a cada protocolo de base para soportar el cifrado MD5.
Desafortunadamente, no existe una protección adecuada contra un ataque por inundación, o un host o router mal
comportamiento que está inundando la red. Afortunadamente, este tipo de ataque es obvio cuando se produce y
por lo general se puede terminar de manera relativamente sencilla.
3.2.3 Protección de los Servicios
Hay muchos tipos de servicios y cada uno tiene sus propios requisitos de seguridad. Estos requisitos varían en
función del uso previsto del servicio. Por ejemplo, un servicio que sólo debe ser utilizable dentro de un sitio (por
ejemplo, NFS) puede requerir diferentes mecanismos de protección que un servicio proporcionado para uso externo.
Puede que sea suficiente para proteger al servidor interno de acceso externo. Sin embargo, un servidor WWW, que
proporciona una página destinada a la visualización de los usuarios en cualquier lugar en Internet, requiere una
función de protección. Es decir, el / / protocolo de servidor de servicio deben proporcionar toda la seguridad pueden
resultar necesarias para evitar el acceso no autorizado y la modificación de la base de datos Web.
Servicios internos (es decir, servicios destinados a ser utilizados solamente por usuarios dentro de un sitio) y los
servicios externos (es decir, servicios de realizada deliberadamente disponible para los usuarios fuera de un sitio)
será, en general, tienen requisitos de protección que difieren como se describió previamente. Por tanto, es
aconsejable aislar a los servicios internos a un conjunto de equipos host de servidor y los servicios externos a otro
conjunto de equipos host de servidor. Es decir, los servidores internos y externos no deben estar ubicados en el
mismo equipo anfitrión. De hecho, muchos sitios van tan lejos

como para tener un conjunto de subredes (o incluso redes diferentes) que son accesibles desde el exterior y otro
conjunto que se puede acceder sólo dentro del sitio. Por supuesto, por lo general hay un cortafuegos que conecta
estas particiones. El gran cuidado se debe tomar para asegurarse de que tal un servidor de seguridad está
funcionando correctamente.
Cada vez hay más interés en el uso de intranets para conectar las diferentes partes de una organización (por
ejemplo, las divisiones de una empresa). Si bien este documento se diferencia generalmente entre interior y exterior
(pública y privada), sitios que utilizan intranets deben ser conscientes de que tendrán que considerar tres
separaciones y tomar las acciones apropiadas cuando los servicios de diseñar y ofrecer. Un servicio que se ofrece a
una intranet sería ni pública, ni tan completamente privada como un servicio a una sola subunidad organizativa. Por
lo tanto, el servicio tendría su propio sistema de apoyo, separados de ambos servicios y redes externas e internas.
Una forma de servicio externo merece cierta consideración especial, y que es anónima, o invitado, el acceso. Esto
puede ser o FTP anónimo o invitado de inicio de sesión (no autenticado). Es muy importante asegurarse de que los
servidores de FTP anónimo y los ID de usuario de inicio de sesión de invitados son cuidadosamente aislados de
cualquier hosts y sistemas de archivos desde el cual deben mantenerse los usuarios externos. Otra área a la que se
debe prestar una atención especial preocupación el acceso anónimo, puede escribir. Un sitio puede ser legalmente
responsable por el contenido de la información a disposición del público, por lo que se recomienda un control
cuidadoso de la información depositada por los usuarios anónimos.
Ahora vamos a considerar algunos de los servicios más populares: Nombre de servicio, servicio de contraseña /
clave de autenticación / servicios proxy, correo electrónico, WWW, transferencia de archivos, y NFS. Dado que
estos son los servicios más utilizados, que son los puntos más evidentes de ataque. Además, un ataque con éxito
en uno de estos servicios puede producir un desastre fuera de toda proporción a la inocencia del servicio básico.
3.2.3.1 servidores de nombres (DNS y NIS (+))
Internet utiliza el sistema de nombres de dominio (DNS) para llevar a cabo la resolución de direcciones de nombres
de host y de red. El Servicio de Información de Red (NIS) y NIS + no se utilizan en la Internet global, pero están
sujetos a los mismos riesgos que un servidor DNS. Nombre-a-dirección de resolución es crítica para la operación
segura de cualquier red. Un atacante que puede controlar con éxito o hacerse pasar por un servidor DNS tráfico
puede modificar el trazado de subvertir las protecciones de seguridad. Por ejemplo, el tráfico de rutina puede ser
desviada a un sistema comprometido a vigilar; o, los usuarios pueden ser engañados para proporcionar secretos de
autenticación. Una organización debe crear sitios protegidos, conocidos

para actuar como servidores de nombres secundarios y proteger a sus amos DNS de ataques de denegación de
servicio que utilizan los routers de filtrado.
Tradicionalmente, DNS no ha tenido capacidades de seguridad. En particular, la información de regresar de una

consulta no pudo comprobarse la modificación o verificó que había llegado desde el servidor de nombres en
cuestión. Se ha trabajado para incorporar las firmas digitales en el protocolo que, cuando se despliega, permitirá a
la integridad de la información que se debe verificar criptográficamente (ver RFC 2065).
3.2.3.2 Servidores contraseña / clave (NIS (+) y KDC)
Contraseña y servidores de claves generalmente a proteger su información vital (es decir, las contraseñas y claves
de cifrado) con algoritmos. Sin embargo, incluso una contraseña encriptada unidireccional puede ser determinada
por un ataque de diccionario (en el que las palabras comunes se cifran para ver si coinciden con el cifrado
almacenado). Por tanto, es necesario asegurarse de que estos servidores no son accesibles por los anfitriones que
no planean usarlos para el servicio, e incluso los anfitriones sólo debe ser capaz de acceder al servicio (es decir,
servicios generales, tales como Telnet y FTP, debe no se permitirá que por nadie más que los administradores).
3.2.3.3 servidores de autenticación / proxy (SOCKS, FWTK)
Un servidor proxy proporciona una serie de mejoras de seguridad. Permite a los sitios a los servicios de concentrado
a través de una máquina específica para permitir el monitoreo, ocultación de la estructura interna, etc. Esta
canalización de los servicios crea un objetivo atractivo para un posible intruso. El tipo de protección requerido para
un servidor proxy depende en gran medida del protocolo proxy en uso y los servicios que se aproxima. La regla
general de limitar el acceso sólo a aquellos huéspedes que necesitan los servicios, y limitar el acceso de los
anfitriones solamente a aquellos servicios, es un buen punto de partida.
3.2.3.4 correo electrónico
sistemas de correo electrónico (e-mail) han sido durante mucho tiempo una fuente de intrusos robos ya que los
protocolos de correo electrónico son algunos de los servicios más antiguos y más ampliamente desplegados.
Además, por su propia naturaleza, un servidor de correo electrónico requiere el acceso al mundo exterior; la mayoría
de los servidores de correo electrónico aceptan la entrada de cualquier fuente. Un servidor de correo electrónico
generalmente se compone de dos partes: a / envío de agente de recepción y un agente de procesamiento. Desde
correo electrónico se entrega a todos los usuarios, y por lo general es privada, el agente de transformación
normalmente requiere privilegios de sistema (root) para entregar el correo. La mayoría de las implementaciones de
correo electrónico realizan ambas porciones del servicio, que significa que el agente receptor también tiene
privilegios del sistema. Esto abre varios agujeros de seguridad que no se describen este documento. Hay algunas
implementaciones disponibles que permiten una separación de

los dos agentes. Tales implementaciones son generalmente considerados más seguros, pero aún requieren una
instalación cuidadosa para no crear un problema de seguridad.
3.2.3.5 World Wide Web (WWW)
La Web está creciendo en popularidad de manera exponencial debido a su facilidad de uso y la poderosa capacidad
de concentrar los servicios de información. La mayoría de los servidores WWW aceptan un cierto tipo de dirección y
de la acción de las personas que acceden a sus servicios. El ejemplo más común está tomando una solicitud de un
usuario remoto y pasa la información proporcionada a un programa en ejecución en el servidor para procesar la
solicitud. Algunos de estos programas no están escritos pensando en la seguridad y puede crear agujeros de
seguridad. Si el servidor Web está disponible para la comunidad de Internet, es especialmente importante que la
información confidencial no ser colocado en la misma máquina que el servidor. De hecho, se recomienda que el
servidor tiene un host dedicado que no es "de confianza" por parte de otros hosts internos.
Muchos sitios pueden querer co-localizar el servicio FTP con su servicio WWW. Pero esto sólo debe ocurrir por
servidores anon-ftp que sólo proporcionan información (FTP-get). pone anon-ftp, en combinación con WWW,
podría ser peligroso (por ejemplo, podrían dar lugar a modificaciones en la información de su sitio está publicando
en la web) y en sí mismos que las consideraciones de seguridad para cada servicio diferente.
3.2.3.6 Transferencia de Archivos (FTP, TFTP)
FTP y TFTP tanto permiten a los usuarios recibir y enviar archivos electrónicos de una manera punto a punto. Sin
embargo, FTP requiere autenticación, mientras que TFTP requiere ninguna. Por esta razón, TFTP se debe evitar
tanto como sea posible.
servidores FTP configurados incorrectamente pueden permitir a los intrusos para copiar, reemplazar y borrar
archivos a voluntad, en cualquier parte de una serie, por lo que es muy importante para configurar este servicio
correctamente. El acceso a las contraseñas cifradas y datos de propiedad, y la introducción de caballos de Troya son
sólo algunos de los agujeros de seguridad potenciales que pueden ocurrir cuando el servicio está configurado
incorrectamente. servidores FTP deben residir en su propio anfitrión. Algunos sitios eligen co-localizar FTP con un
servidor Web, ya que los dos protocolos comparten las consideraciones de seguridad común, sin embargo, no se
recomienda el la práctica, sobre todo cuando el servicio FTP permite el depósito de archivos (véase la sección sobre
WWW arriba). Como se mencionó en los párrafos iniciales de la sección 3.2.3, los servicios ofrecidos internamente a
su sitio no debe ser colocado con los servicios ofrecidos externamente. Cada uno debe tener su propio anfitrión.

TFTP no es compatible con la misma gama de funciones como FTP, y no tiene ningún tipo de seguridad. Este
servicio se debe considerar solamente para uso interno, y entonces debe ser configurado de manera restringida para
que el servidor sólo tiene acceso a un conjunto de archivos predeterminados (en lugar de cada archivo legible por
todos en el sistema). Probablemente el uso más común de TFTP es para la descarga de archivos de configuración
del router a un router. TFTP debe residir en su propio anfitrión, y no debe ser instalado en máquinas de soporte FTP
externo o acceso a la Web.
3.2.3.7 NFS
El Servicio de archivos de red permite a los hosts a los discos acción ordinaria. NFS es frecuentemente utilizada por
los ejércitos sin disco que dependen de un servidor de disco para todas sus necesidades de almacenamiento. Por
desgracia, NFS no se ha incorporado en la seguridad. Por tanto, es necesario que el servidor NFS sea accesible
solamente por los hospedadores que se están utilizando para el servicio. Esto se consigue mediante la
especificación de que alberga el sistema de archivos se exporta a y de qué manera (por ejemplo, de sólo lectura,
lectura-escritura, etc.). Los sistemas de archivos no debe ser exportado a cualquier host fuera de la red local, ya que
esto exige que el servicio NFS sea accesible externamente. Idealmente, el acceso externo al servicio NFS debe ser
detenido por un firewall.
3.2.4 La protección de la Protección
Es sorprendente la frecuencia con un sitio pasará por alto la debilidad más obvia en su seguridad al dejar el
servidor de seguridad en sí vulnerable a los ataques. Sobre la base de las consideraciones discutidas
anteriormente, debería quedar claro que: el servidor de seguridad no debe ser accesible desde fuera de las
instalaciones; debe ofrecer un acceso mínimo, a excepción de la función de autenticación de los usuarios en el
sitio; y no debe ser colocado junto con cualquier otro servidor. Además, todo el acceso al nodo, incluyendo el
acceso al servicio en sí, debe estar conectado para proporcionar un "rastro de papel" en el caso de un fallo de
seguridad.
3.3 Cortafuegos
Una de las medidas de seguridad más utilizados y difundidos en uso en Internet es un "firewall". Los cortafuegos se
les ha dado la reputación de una panacea general para muchos, si no todos, de los problemas de seguridad en
Internet. Ellos no son. Los cortafuegos son sólo una herramienta más en la búsqueda de la seguridad del sistema.
Ellos proporcionan un cierto nivel de protección y son, en general, una forma de implementar la política de seguridad
a nivel de red. El nivel de seguridad que proporciona un servidor de seguridad puede variar tanto como el nivel de
seguridad en una máquina en particular. Hay las tradicionales soluciones de compromiso entre la seguridad, facilidad
de uso, coste, complejidad, etc.

Un servidor de seguridad es uno cualquiera de los diversos mecanismos utilizados para controlar el acceso y el reloj
hacia y desde una red con el fin de protegerla. Un servidor de seguridad actúa como una puerta de enlace a través
del cual pasa todo el tráfico desde y hacia la red y / o los sistemas protegidos. Firewalls ayuda a lugar limitaciones en
la cantidad y el tipo de comunicación que tiene lugar entre la red protegida y la otra red (por ejemplo, la Internet, u
otra pieza de la red del sitio).
Un cortafuegos es generalmente una manera de construir una pared entre una parte de una red, la red interna de
una empresa, por ejemplo, y otra parte, la Internet global, por ejemplo. La característica única de esta pared es que
es necesario que haya formas de algo de tráfico con características particulares para pasar a través de puertas
cuidadosamente monitorizados ( "puertas de entrada"). La parte difícil es establecer los criterios por los que se
permite o deniega el acceso a través de las puertas de los paquetes. Los libros escritos en los firewalls utilizan
diferente terminología para describir las diversas formas de cortafuegos. Esto puede ser confuso para los
administradores de sistemas que no están familiarizados con los cortafuegos. Lo que hay que tener en cuenta es
que no se fija ninguna terminología para la descripción de los cortafuegos.
Los cortafuegos no son siempre, o incluso por lo general, una sola máquina. Más bien, los servidores de seguridad
son a menudo una combinación de routers, segmentos de red y equipos host. Por lo tanto, para los propósitos de
esta discusión, el término "firewall" puede consistir en más de un dispositivo físico. Los cortafuegos se construyen
típicamente usando dos componentes diferentes, el filtrado de los routers y servidores proxy.
enrutadores de filtrado son el componente más fácil de conceptualizar en un servidor de seguridad. Un router mueve
datos de ida y vuelta entre dos (o más) redes diferentes. Un "normal" enrutador toma un paquete de red A y "rutas" a
su destino en la red B. Un router de filtrado hace lo mismo pero decide no sólo cómo encaminar el paquete, pero si
debe encaminar el paquete. Esto se realiza mediante la instalación de una serie de filtros por los cuales el router
decide qué hacer con cualquier paquete de datos dado.
Una discusión relacionada con las capacidades de una determinada marca de router, que ejecuta una versión de
software en particular se encuentra fuera del alcance de este documento. Sin embargo, al evaluar un router que se
utilizará para el filtrado de paquetes, los siguientes criterios pueden ser importantes en la aplicación de una política
de filtrado: Los números de fuente y el destino de la dirección IP, puerto de origen y de destino TCP, estado de la
"ACK" bit, la fuente TCP y UDP números de puerto de destino, y la dirección de flujo de paquetes (es decir. A-
> B o B-> A). Otra información necesaria para construir un esquema de filtrado seguro de si se reordena las
instrucciones de filtro de router (diseñado para optimizar los filtros, esto a veces puede cambiar el significado y la
causa accesos no deseados), y si es posible aplicar

filtros para paquetes entrantes y salientes en cada interfaz (si el router filtra sólo paquetes de salida a continuación,
el router es "fuera" de sus filtros y puede ser más vulnerable a los ataques). Además de ser vulnerable al router, esta
distinción entre la aplicación de filtros de paquetes entrantes o salientes es especialmente relevante para los routers
con más de 2 interfaces. Otros aspectos importantes son la capacidad de crear filtros basados en opciones de la
cabecera IP y el estado fragmento de un paquete. La construcción de un buen filtro puede ser muy difícil y requiere
un buen conocimiento del tipo de servicios (protocolos) que se filtra.
Para mayor seguridad, los filtros suelen restringir el acceso entre las dos redes conectadas a un solo host, el host
bastión. Sólo es posible acceder a la otra red a través de este host de baluarte. Ya que sólo este host, en lugar de
unos pocos cientos de hosts, puede ser atacado, es más fácil de mantener un cierto nivel de seguridad, ya que sólo
este anfitrión tiene que ser protegido con mucho cuidado. Para hacer que los recursos disponibles para los usuarios
legítimos a través de este servidor de seguridad, los servicios tienen que ser enviado por el host bastión. Algunos
servidores de reenvío han incorporado (como DNS-servidores o servidores SMTP), para otros servicios (por ejemplo,
Telnet, FTP, etc.), servidores proxy se puede utilizar para permitir el acceso a los recursos a través del cortafuegos
de una manera segura.
Un servidor proxy es forma de servicios de aplicaciones concentrado a través de una sola máquina. Normalmente
hay una sola máquina (el anfitrión bastión) que actúa como un servidor proxy para una variedad de protocolos
(Telnet, SMTP, FTP, HTTP, etc.) pero no puede haber equipos host individuales para cada servicio. En lugar de
conectar directamente a un servidor externo, se conecta el cliente al servidor proxy que a su vez inicia una conexión
con el servidor externo solicitado. Dependiendo del tipo de servidor proxy utilizado, es posible configurar los clientes
internos para llevar a cabo esta redirección automática, sin el conocimiento del usuario, otros pueden requerir que el
usuario se conecta directamente al servidor proxy y luego iniciar la conexión a través de un formato especificado.
Hay ventajas significativas de seguridad que se pueden derivar del uso de servidores proxy. Es posible añadir listas
de control de acceso a los protocolos, obligando a los usuarios o sistemas para proporcionar un cierto nivel de
autenticación antes de conceder el acceso. Más inteligente servidores proxy, a veces llamada la capa de aplicación
Gateways (ALG), se puede escribir que entender protocolos específicos y puede ser configurado para bloquear sólo
subsecciones del protocolo. Por ejemplo, un ALG para FTP puede decir la diferencia entre el comando "put" y el
comando "get"; una organización puede desear permitir a los usuarios a "get" archivos de Internet, pero no ser capaz
de "poner" los archivos internos en un servidor remoto. Por el contrario, un router de filtrado o bien podría bloquear
todo el acceso FTP, o ninguno, pero no un subconjunto.

Los servidores proxy también se pueden configurar para cifrar los datos corrientes sobre la base de una variedad de
parámetros. Una organización puede utilizar esta función para permitir conexiones cifradas entre dos lugares cuyo
acceso exclusivo puntos están en Internet.
Los cortafuegos se suele considerar como una forma de mantener a los intrusos, pero también se utilizan a
menudo como una forma de permitir a los usuarios legítimos en un sitio. Hay muchos ejemplos en los que una
necesidad válida fuerzas usuario para acceder al sitio con regularidad "casa" durante un viaje a espectáculos y
conferencias de comercio, etc. El acceso a Internet es a menudo disponible, pero puede ser a través de una
máquina no es de confianza o de la red. Un servidor proxy configurado correctamente puede permitir a los usuarios
correctos en el sitio mientras sigue negando el acceso a otros usuarios.
El actual mejor esfuerzo en técnicas de firewall se encuentra el uso de una combinación de un par de cribado de
routers con uno o más servidores proxy en una red entre los dos routers. Esta configuración permite que el router
externo para bloquear cualquier intento de utilizar la capa IP subyacente para romper la seguridad (IP spoofing,
enrutamiento de origen, fragmentos de paquete), al tiempo que permite el servidor proxy para manejar los agujeros
de seguridad potenciales en los protocolos de capa superior. El propósito del enrutador interno es bloquear todo el
tráfico excepto al servidor proxy. Si esta configuración se lleva a cabo de manera rígida, un alto nivel de seguridad
se puede lograr.
La mayoría de los servidores de seguridad proporcionan el registro que puede ser sintonizado para que la
administración de seguridad de la red más conveniente. El registro puede estar centralizada y el sistema puede ser
configurado para enviar alertas para condiciones anormales. Es importante controlar regularmente estos registros
para detectar cualquier signo de intrusiones o ruptura en los intentos. Debido a que algunos intrusos intentarán cubrir
sus pistas mediante la edición de registros, es deseable proteger estos registros. Una variedad de métodos está
disponible, incluyendo: escribir una vez, leer muchas unidades (WORM); registros de papeles; y centralizada de
registro a través de la utilidad "syslog". Otra técnica es utilizar una impresora en serie "falsa", pero tienen el puerto
serie conectado a una máquina aislada o PC que mantiene los registros.
Los cortafuegos están disponibles en una amplia gama de calidad y puntos fuertes. paquetes comerciales
comienzan en aproximadamente $ 10,000US y llegan hasta más de $ 250,000US. cortafuegos "de cosecha propia"
se pueden construir de pequeñas cantidades de capital. Debe recordarse que la configuración correcta de un
servidor de seguridad (comercial o de cosecha propia) requiere una cantidad significativa de habilidad y
conocimiento de TCP / IP. Ambos tipos requieren un mantenimiento regular, instalación de parches de software y
actualizaciones, y la vigilancia periódica. Al preparar el presupuesto para un servidor de seguridad, estos costes
adicionales deben considerarse además del coste de los elementos físicos del firewall.

Aparte, la construcción de una "cosecha propia" firewall requiere una cantidad significativa de habilidad y
conocimiento de la TCP / IP. No se debería intentar trivial debido a una sensación percibida de seguridad es peor
en el largo plazo que saber que no hay seguridad. Al igual que con todas las medidas de seguridad, es importante
decidir sobre la amenaza, el valor de los bienes a proteger, y los costos de implementar la seguridad.
Una nota final sobre cortafuegos. Pueden ser de gran ayuda en la aplicación de seguridad para un sitio y
proteger contra una gran variedad de ataques. Pero es importante tener en cuenta que son sólo una parte de la
solución. Ellos no pueden proteger su sitio contra todo tipo de ataque.
4. Servicios de Seguridad y Procedimientos
En este capítulo se guía al lector a través de una serie de temas que se deben abordar cuando se asegura un sitio.
Cada sección trata sobre un servicio de seguridad o capacidad que pueda ser necesaria para proteger la información
y los sistemas en un sitio. Los temas se presentan a un nivel bastante alto para introducir al lector en los conceptos.
A lo largo del capítulo, se encuentra mención significativa de la criptografía. Está fuera del alcance de este
documento para ahondar en los detalles relativos a la criptografía, pero el lector interesado puede obtener más
información de los libros y artículos mencionados en la sección de referencia de este documento.
4.1 autenticación
Durante muchos años, el método prescrito para la autenticación de los usuarios ha sido a través del uso de
contraseñas estándar y reutilizables. Originalmente, estas contraseñas fueron utilizados por los usuarios en las
terminales para autenticar a sí mismos a un ordenador central. En ese momento, no había redes (interna o
externamente), por lo que el riesgo de divulgación de la contraseña en texto claro era mínima. Hoy, los sistemas
están conectados entre sí a través de redes locales, y estas redes locales están conectados juntos y aún más a
Internet. Los usuarios inician sesión en el de todo el mundo; sus contraseñas reutilizables a menudo se transmiten a
través de esas mismas redes en texto claro, maduro para cualquier persona en el medio de captura. Y, en efecto, el
Centro de Coordinación CERT * y otros equipos de respuesta están viendo un gran número de incidentes
relacionados con analizadores de paquetes que están capturando las contraseñas de texto.
Con el advenimiento de nuevas tecnologías como contraseñas de un solo uso (por ejemplo, S / Key), PGP y
dispositivos de autenticación basada en token, la gente está utilizando la contraseña como cadenas como tokens y
pasadores secretas. Si estas fichas y pasadores secretas no están adecuadamente seleccionados y protegidos, la
autenticación se subvertido fácilmente.

4.1.1 contraseñas de un solo
Como se mencionó anteriormente, teniendo en cuenta los entornos de red de hoy en día, se recomienda que los
sitios preocupados por la seguridad e integridad de sus sistemas y redes considerar moverse lejos de contraseñas
estándar y reutilizables. Ha habido muchos incidentes relacionados con programas de la red de Troya (por
ejemplo, telnet y rlogin) y de paquetes de red sniffing programas. Estos programas de captura de los tríos de texto
nombre de host / nombre de cuenta / contraseña claras. Los intrusos pueden utilizar la información capturada por
el acceso posterior a los anfitriones y cuentas. Esto es posible porque 1) la contraseña se utiliza una y otra vez (de
ahí el término "reutilizable"), y 2) la contraseña pasa a través de la red en texto claro.
Varias técnicas de autenticación han sido desarrollados para abordar este problema. Entre estas técnicas son las
tecnologías de desafío-respuesta que proporcionan las contraseñas que sólo se utilizan una vez (comúnmente
llamado contraseñas de un solo uso). Hay una serie de productos disponibles que los sitios deberían considerar el
uso. La decisión de utilizar un producto es responsabilidad de cada organización, y cada organización debe realizar
su propia evaluación y selección.
4.1.2 Kerberos
Kerberos es un sistema de seguridad de red distribuida que proporciona para la autenticación a través de redes no
seguras. Si es requerido por la aplicación, la integridad y cifrado también puede ser proporcionada. Kerberos se
desarrolló originalmente en el Instituto de Tecnología de Massachusetts (MIT) en la década de 1980 a mediados.
Hay dos versiones principales de Kerberos, versión 4 y 5, que son, a efectos prácticos, incompatibles.
Kerberos se basa en una base de datos de clave simétrica utilizando un centro de distribución de claves (KDC) que
se conoce como el servidor Kerberos. Un usuario o servicio (conocido como "principales") se conceden "entradas"
electrónicos después de comunicarse correctamente con el KDC. Estas entradas se utilizan para la autenticación
entre los directores. Todas las entradas incluyen una marca de tiempo que limita el período de tiempo durante el
que el billete es válido. Por lo tanto, los clientes de Kerberos y el servidor deben tener una fuente de tiempo
seguro, y ser capaz de mantener el tiempo con precisión.
El lado práctico de Kerberos es su integración con el nivel de aplicación. Las aplicaciones típicas como FTP,
Telnet, POP, y NFS se han integrado con el sistema Kerberos. Hay una variedad de implementaciones que tienen
diferentes niveles de integración. Por favor, vea el FAQ de Kerberos disponible en
http://www.ov.com/misc/krbfaq.html para la información más reciente.

4.1.3 escoger y proteger su secreto Fichas y PINs
Al seleccionar las fichas secretas, tenga cuidado de elegir con cuidado. Al igual que la selección de contraseñas, que
debe ser robusto frente a los esfuerzos de fuerza bruta para adivinar ellos. Es decir, no deben ser palabras sueltas
en cualquier idioma, cualquier común, la industria, o acrónimos culturales, etc. Lo ideal es que será más largo en vez
de más corta y se componen de frases clave que combinan superior e inferior personaje caso, dígitos, y otra
caracteres.
Una vez elegido, la protección de estas fichas secretas es muy importante. Algunos se utilizan como pasadores a los
dispositivos de hardware (como las tarjetas de testigo) y estos no deben ser escritos hacia abajo, o en la misma
ubicación que el dispositivo con el que están asociados. Otros, como una clave secreta Pretty Good Privacy (PGP),
deben ser protegidos contra el acceso no autorizado.
Una última palabra sobre este tema. Cuando se utilizan productos de criptografía, como PGP, encargarse de
determinar la longitud de la clave adecuada y asegurarse de que sus usuarios están capacitados para hacer lo
mismo. A medida que avanza la tecnología, la longitud de clave mínima de seguridad sigue creciendo. Asegúrese
de que su sitio mantiene al día con los últimos conocimientos sobre la tecnología para que pueda asegurarse de
que cualquier criptografía en uso está proporcionando la protección que usted cree que es.
4.1.4 Aseguramiento de la contraseña
Si bien la necesidad de eliminar el uso de contraseñas estándar reutilizables, no puede ser exagerada, se reconoce
que algunas organizaciones pueden seguir utilizando. Si bien se recomienda que estas organizaciones transición
hacia el uso de la mejor tecnología, en la media hora, tenemos los siguientes consejos para ayudar con la selección
y mantenimiento de las contraseñas tradicionales. Pero recuerde, ninguna de estas medidas proporciona protección
contra la divulgación debido a los programas rastreadores.
(1) La importancia de las contraseñas robustas - En muchos (si no la mayoría) de los casos
de penetración en el sistema, el intruso tiene que tener acceso a una cuenta en el sistema. Una forma de
ese objetivo se logra típicamente es a través de adivinar la contraseña de un usuario legítimo. Esto se logra
a menudo mediante la ejecución de un programa automatizado contraseña de craqueo, que utiliza un
diccionario muy grande, contra el archivo de la contraseña del sistema. La única manera de protegerse
contra las contraseñas que se dan a conocer en esta forma es a través de la cuidadosa selección de las
contraseñas que no se puede adivinar fácilmente (es decir, combinaciones de números, letras y caracteres
de puntuación). Las contraseñas también deben ser tan largos como los apoyos y los usuarios del sistema
pueden tolerar.

(2) Cambio de contraseñas por defecto - Muchos sistemas operativos y

programas de aplicación se instalan con cuentas y contraseñas por defecto. Estos se deben cambiar
inmediatamente a algo que no se puede adivinar o agrietado.
(3) La restricción del acceso al archivo de contraseñas - En particular, un sitio

quiere proteger la parte contraseña cifrada del archivo de modo que los posibles intrusos no los tienen
disponibles para el craqueo. Una técnica efectiva es usar contraseñas ocultas en el campo de contraseña
del archivo estándar contiene un maniquí o falsa contraseña. El archivo que contiene las contraseñas
legítimos están protegidos otro lugar del sistema.
(4) El envejecimiento de contraseñas - ¿Cuándo y cómo expirará contraseñas está siendo una
tema de controversia entre la comunidad de seguridad. En general se acepta que una contraseña no debe
mantenerse una vez que la cuenta ya no está en uso, pero se discute caliente si un usuario debe ser
obligado a cambiar una contraseña buena que está en uso activo. Los argumentos para el cambio de
contraseñas refieren a la prevención del uso continuado de cuentas penetrado. Sin embargo, las demandas
de la oposición que los cambios frecuentes de contraseña conducen a los usuarios escribir sus contraseñas
en áreas visibles (como pegándolas a un terminal), o a los usuarios seleccionar contraseñas muy simples
que sean fáciles de adivinar. También hay que señalar que un intruso probablemente utilizar una contraseña
capturados o adivinado más pronto que tarde, en cuyo caso la contraseña envejecimiento proporciona poca
o ninguna protección.
Aunque no existe una respuesta definitiva a este dilema, una política de contraseñas debe abordar
directamente la cuestión y proporcionar directrices para la frecuencia con la que un usuario debe cambiar la
contraseña. Sin duda, un cambio anual en su contraseña no suele ser difícil para la mayoría de los usuarios,
y se debe tener en cuenta que lo requieran. Se recomienda que se cambien las contraseñas al menos cada
vez que se ve comprometida una cuenta con privilegios, se produce un cambio fundamental en el personal
(especialmente si es un administrador!), O cuando una cuenta se ha visto comprometida. Además, si se
compromete una contraseña de cuenta privilegiada, todas las contraseñas en el sistema debe ser cambiado.
(5) Contraseña / bloqueo de cuenta - Algunos sitios les resulta útil para desactivar
cuentas después de un número predefinido de intentos fallidos para autenticar. Si su sitio decide emplear
este mecanismo, se recomienda que el mecanismo no "publicidad" en sí. Después

incapacita, aunque se presenta la contraseña correcta, aparece el mensaje debe seguir siendo el de un
intento fallido de inicio de sesión. La implementación de este mecanismo requerirá que los usuarios
legítimos en contacto con su administrador del sistema para solicitar que se reactive su cuenta.
(6) Una palabra sobre el demonio finger - Por defecto, el demonio finger
sistema muestra una considerable e información al usuario. Por ejemplo, se puede mostrar una lista de
todos los usuarios que actualmente utilizan un sistema, o todo el contenido del archivo .plan de un usuario
específico. Esta información puede ser utilizada por los posibles intrusos para identificar los nombres de
usuario y contraseñas de adivinar sus. Se recomienda que los sitios de considerar la modificación de los
dedos para restringir la información que se muestra.
4.2 Confidencialidad
Habrá activos de información que su sitio se desea proteger de la divulgación a entidades no autorizadas. Los
sistemas operativos a menudo han incorporado en los mecanismos de protección de archivos que permiten a un
administrador controlar que en el acceso al sistema de lata, o "ver" el contenido de un archivo dado. Una forma más
fuerte para proporcionar confidencialidad es a través de la encriptación. La encriptación se lleva a cabo mediante
codificación de datos de forma que es muy difícil y requiere mucho tiempo para cualquier persona que no sean los
destinatarios o propietarios autorizado para obtener el texto plano. Los destinatarios autorizados y el propietario de la
información, poseerán las claves de descifrado correspondientes que les permitan descifrar fácilmente el texto a un
formato legible (texto claro). Recomendamos que los sitios utilizan el cifrado para garantizar la confidencialidad y
proteger la información valiosa.
El uso de la encriptación a veces es controlado por las regulaciones gubernamentales y de sitio, por lo que
animamos a los administradores a ser informados de las leyes o políticas que regulan su uso antes de emplearlo.
Está fuera del alcance de este documento para discutir los diversos algoritmos y programas disponibles para este
propósito, pero sí advierten contra el uso ocasional del programa cripta UNIX, ya que se ha encontrado para ser
rotos fácilmente. También animamos a todos a tomar tiempo para entender la intensidad del cifrado en cualquier
algoritmo / determinado producto antes de usarlo. La mayoría de los productos conocidos están bien documentados
en la literatura, por lo que esta debe ser una tarea bastante fácil.
4.3 Integridad
Como administrador, tendrá que asegurarse de que la información (por ejemplo, archivos del sistema operativo,
datos de empresa, etc.) no han sido alterados de manera no autorizada. Esto significa que tendrá que proporcionar
una cierta seguridad en cuanto a la integridad de la información en su

Los sistemas. Una manera de proporcionar este es producir una suma de comprobación del archivo inalterada,
tienda que la suma de comprobación fuera de línea, y periódicamente (o cuando se desee) comprobar para
asegurarse de que la suma de comprobación del archivo en línea no ha cambiado (lo que indicaría que los
datos han sido modificados ).
Algunos sistemas operativos vienen con programas de suma de control, tales como el programa suma UNIX. Sin
embargo, éstos no pueden proporcionar la protección que realmente necesita. Los archivos pueden ser modificados
de manera tal que se preserve el resultado de la suma de UNIX programa! Por lo tanto, sugerimos que utilice un
programa criptográficamente fuerte, como el mensaje de digerir programa MD5 [ref], para producir las sumas de
control que va a utilizar para asegurar la integridad.
Hay otras aplicaciones donde se necesita estar seguro de la integridad, como cuando se transmite un mensaje de
correo electrónico entre dos partes. Hay productos disponibles que pueden proporcionar esta capacidad. Una vez
que identifique que esta es una capacidad que necesita, usted puede ir sobre la identificación de tecnologías que
proporcionarán la misma.
4.4 Autorización
La autorización se refiere al proceso de concesión de privilegios a los procesos y, en última instancia, los usuarios.
Esto difiere de la autenticación en el que la autenticación es el proceso utilizado para identificar a un usuario. Una
vez identificados (fiable), los privilegios, derechos, bienes y acciones autorizadas del usuario están determinados
por la autorización.
Explícitamente una lista de las actividades autorizadas de cada usuario (y proceso de usuario) con respecto a
todos los recursos (objetos) es imposible en un sistema razonable. En un sistema real ciertas técnicas se utilizan
para simplificar el proceso de concesión y la comprobación de autorización (s).
Un enfoque, popularizado en los sistemas UNIX, es asignar a cada objeto tres tipos de usuarios: propietario, grupo y
en el mundo. El propietario es o bien el creador del objeto o el usuario asignado como propietario por el
superusuario. Los permisos de propietario (lectura, escritura y ejecución) se aplican sólo al propietario. Un grupo es
un conjunto de usuarios que comparten los derechos de acceso a un objeto. Los permisos de grupo (lectura,
escritura y ejecución) se aplican a todos los usuarios en el grupo (excepto el propietario). El mundo se refiere a todo
el mundo con acceso al sistema. Los permisos mundo (lectura, escritura y ejecución) se aplican a todos los usuarios
(excepto el propietario y los miembros del grupo).
Otro enfoque es unir a un objeto que contiene una lista explícitamente la identidad de todos los usuarios permitidos
(o grupos). Esta es una lista de control de acceso (ACL). La ventaja de ACL es que son

de fácil mantenimiento (una lista central por objeto) y es muy fácil de comprobar visualmente quién tiene acceso a
qué. Las desventajas son los recursos adicionales necesarios para almacenar tales listas, así como el gran número
de tales listas requeridas para sistemas grandes.
4.5 Acceso
4.5.1 Acceso Físico
Restringir el acceso físico a los hosts, permitiendo el acceso sólo a aquellas personas que se supone utilizar los
anfitriones. Anfitriones incluyen la "confianza" terminales (es decir, terminales que permiten el uso no autenticado
como consolas de operador del sistema, terminales y terminales dedicadas a tareas especiales), y
microcomputadoras y estaciones de trabajo individuales, especialmente aquellos conectados a su red. Hacen malla
áreas de trabajo seguro de las personas bien con restricciones de acceso; de lo contrario van a encontrar la manera
de eludir su seguridad física (por ejemplo, puertas de interferencia abierta).
Guarde copias originales y copias de seguridad de datos y programas de seguridad. Además de mantener en buen
estado para fines de copia de seguridad, que deben ser protegidos contra el robo. Es importante mantener copias de
seguridad en un lugar separado de los originales, no sólo por consideraciones de daños, sino también para proteger
contra robos.
anfitriones portátiles son un riesgo particular. Asegúrese de que no causará problemas si una de ordenador
portátil de su personal es robado. Considere la elaboración de directrices para los tipos de datos que deben ser
autorizados a residir en los discos de los ordenadores portátiles, así como cómo deberán protegerse los datos
(por ejemplo, el cifrado) cuando se encuentra en un ordenador portátil.
Otras áreas donde el acceso físico debe ser restringida es los armarios de cableado y elementos de red importantes
como servidores de archivos, servidores de nombres, y los routers.
4.5.2 Conexiones de red walk-up
Por conexiones "walk-up", nosotros, los puntos de conexión de red medias situadas para proporcionar una
manera conveniente para los usuarios conectar un host portátil a la red.
Considere si necesita proporcionar este servicio, teniendo en cuenta que se permite a cualquier usuario conectar
un host no autorizado a la red. Esto aumenta el riesgo de ataques a través de técnicas como la

IP spoofing de direcciones, detección de paquetes, etc. Usuarios y administración de sitios debe apreciar los riesgos
involucrados. Si decide proporcionar conexiones walk-up, planificar el servicio de cuidado y definir con precisión
dónde va a proporcionar de manera que se puede asegurar la seguridad de acceso físico necesario.
Una gran cantidad walk-up debe ser autenticado antes de permitir a sus usuarios para acceder a los recursos de
la red. Como alternativa, puede ser posible controlar el acceso físico. Por ejemplo, si el servicio es para ser
utilizado por los estudiantes, es posible que sólo se proporciona tomas de conexión walk-up en los laboratorios
de los estudiantes.
Si va a proporcionar el acceso a pie a punto para los visitantes a volver a conectar sus redes domésticas (por
ejemplo, para leer el correo electrónico, etc.) en sus instalaciones, considerar el uso de una subred independiente
que no tiene conectividad a la red interna.
Mantenga un ojo en cualquier área que contiene acceso no controlado a la red, tales como oficinas vacantes.
Puede ser conveniente desconectar dichas áreas en el armario de cableado, y considerar el uso de
concentradores seguras y seguimiento de intentos de conexión anfitriones no autorizadas.
4.5.3 Otras Tecnologías de Redes
Tecnologías considerados aquí incluyen X.25, RDSI, SMDS, DDS y Frame Relay. Todos ellos se suministran a
través de enlaces físicos que van a través de centrales telefónicas, proporcionando el potencial para que puedan ser
desviados. Galletas son ciertamente interesados en el teléfono cambia, así como en las redes de datos!
Con las tecnologías conmutadas, utilizar circuitos virtuales permanentes o grupos cerrados de usuarios, siempre que
sea posible. Tecnologías que proporcionan autenticación y / o cifrado (tal como IPv6) están evolucionando
rápidamente; considerar el uso de ellos en los enlaces donde la seguridad es importante.
4.5.4 Módems
4.5.4.1 Líneas de módem debe gestionarse
A pesar de que proporcionan un cómodo acceso a un sitio para sus usuarios, sino que también puede proporcionar
un desvío eficaz en torno a los servidores de seguridad del sitio. Por esta razón, es esencial para mantener un
control adecuado de los módems.
No permitir a los usuarios instalar una línea de módem sin la debida autorización. Esto incluye instalaciones
temporales (por ejemplo, conectar un módem en una noche a la mañana facsímil o línea de teléfono).

Mantener un registro de todas sus líneas de módem y mantener su registro hasta la fecha. Realizar regulares
(idealmente automatizados) cheques de sitio para módems no autorizadas.
4.5.4.2 Dial-in los usuarios deben autenticarse
Una verificación de usuario y contraseña debe ser completado antes de que un usuario puede acceder a
cualquier cosa en la red. consideraciones normales de seguridad de contraseña son particularmente importantes
(véase la sección 4.1.1).
Recuerde que las líneas telefónicas se pueden tomar, y que es bastante fácil de interceptar mensajes a teléfonos
celulares. módems modernos de alta velocidad utilizan técnicas de modulación más sofisticados, lo que los hace un
poco más difícil de controlar, pero es prudente asumir que los hackers saben cómo espiar a sus líneas. Por esta
razón, se debe utilizar contraseñas de un solo uso, si es posible.
Es útil tener un único acceso telefónico en el punto (por ejemplo, un único conjunto de módems grande) para
que todos los usuarios se autentican de la misma manera.
Los usuarios de vez en cuando mis-escriba una contraseña. Establecer un breve retraso - por ejemplo dos segundos
- después de la primera y la segunda conexiones fallidas, y forzar una desconexión después de la tercera. Esto
ralentizará ataques de contraseña automatizados. No le diga al usuario si el nombre de usuario, la contraseña, o
ambos, no son correctos.
Capacidad 4.5.4.3 Call-back
Algunos de marcación de servidores ofrecen instalaciones de rellamada (es decir, el usuario marca en y se
autentica, el sistema desconecta la llamada y genera una llamada de un número determinado). Devolución de
llamada es útil ya que si alguien fuera a adivinar un nombre de usuario y contraseña, que están desconectados, y el
sistema devuelve la llamada al usuario real cuya contraseña estaba roto; llamadas al azar a partir de un servidor son
sospechosas, en el mejor. Esto hace a los usuarios medios sólo podrán conectarse desde una ubicación (en el que
el servidor está configurado para marcar de nuevo), y por supuesto no puede haber cargos de teléfono asociados a
la ubicación allí de devolución de llamada.
Esta característica se debe utilizar con precaución; que puede ser fácilmente pasado. Como mínimo, asegúrese de
que la llamada de retorno no se hace de la misma módem como el entrante. En general, aunque de devolución de
llamada puede mejorar la seguridad del módem, no debe depender de él solo.
4.5.4.4 Todos los inicios de sesión, debe haber iniciado
Todos los inicios de sesión, ya sea con éxito o sin éxito deben ser registrados. Sin embargo, no mantener las
contraseñas correctas en el registro. Más bien, ellos conectarse simplemente como un intento de inicio de sesión
correcto. Como la mayoría de las contraseñas son malas

escrito mal por los usuarios autorizados, que sólo varían por un solo carácter de la contraseña real. Por lo tanto,
si usted no puede mantener un registro de tal seguro, no inicie sesión en absoluto.
Si llamante está disponible, tomar ventaja de ella mediante el registro del número de llamada para cada intento de
inicio de sesión. Ser sensible a las cuestiones planteadas por la privacidad del número de teléfono. También tenga
en cuenta que la identificación de llamada no es de fiar (ya que los intrusos se han conocido para entrar en
conmutadores telefónicos y números de teléfono hacia adelante o hacer otros cambios); utilizar los datos con fines
informativos solamente, no para la autenticación.
4.5.4.5 Elija su apertura Banner con cuidado
Muchos sitios utilizan un defecto del sistema contenida en un mensaje del archivo de días para su bandera de
apertura. Por desgracia, esto a menudo incluye el tipo de hardware del host o el sistema operativo presente en el
anfitrión. Esto puede proporcionar información valiosa a un intruso a los posibles. En cambio, cada sitio debe crear
su propia bandera específica de inicio de sesión, cuidando sólo para incluir la información necesaria.
Mostrar una breve bandera, pero no ofrecen una "invitación" nombre (por ejemplo, Universidad de XYZ, Sistema de
Registros de Estudiantes). En su lugar, dar el nombre del sitio, una breve advertencia de que las sesiones pueden
ser monitoreados, y un nombre de usuario / contraseña del sistema. Verificar posibles cuestiones jurídicas
relacionadas con el texto que usted pone en el banner.
Para aplicaciones de alta seguridad, considerar el uso de una contraseña "a ciegas" (es decir, no dar respuesta a
una llamada entrante hasta que el usuario ha escrito una contraseña). Esto simula efectivamente un módem
muertos.
4.5.4.6 Acceso telefónico a cabo la autenticación
usuarios de marcación de salida también debe ser autenticado, sobre todo desde su sitio tendrá que pagar sus
gastos de teléfono.
Nunca permita que la marcación de salida de una marcación de entrada no autenticado llamada, y considerar si
va a permitir que a partir de uno autenticado. El objetivo aquí es para evitar que las personas que llaman
usando el conjunto de módems como parte de una cadena de inicios de sesión. Esto puede ser difícil de
detectar, sobre todo si un hacker establece un camino a través de varios hosts en su sitio.
Como mínimo, no permita que los mismos módems y líneas telefónicas para ser utilizados tanto para marcación y de marcación
de salida. Esto se puede implementar fácilmente si se ejecuta de marcación de entrada independiente y marcación de salida
grupos de módems.

4.5.4.7 Haga su programación módem como "a prueba de balas" como sea posible
Módems estar seguro de que no pueden ser reprogramadas mientras están en servicio. Como mínimo, asegúrese
de que tres más señales no pondrá su marcación de módems en el modo de mando!
Programar sus módems para restablecer a su configuración estándar al inicio de cada nueva llamada. De no ser así,
hacer que restablecen al final de cada llamada. Esta precaución le protegerá contra la reprogramación accidental de
sus módems. Restablecimiento tanto al final y al principio de cada llamada será asegurar un mayor nivel de
confianza de que una nueva persona que llama no heredará la sesión de un interlocutor anterior.
Compruebe que los módems terminar las llamadas limpiamente. Cuando un usuario cierra la sesión desde un
servidor de acceso, verificar que se bloquea el servidor hasta la línea de teléfono de manera adecuada. Es
igualmente importante que los cierres de sesión de servidor fuerzas de cualquier sesiones eran activos si se bloquea
el usuario de manera inesperada.
4.6 Auditoría
Esta sección cubre los procedimientos de recogida de datos generados por la actividad de la red, que puede ser
útil en el análisis de la seguridad de una red y responder a los incidentes de seguridad.
4.6.1 Qué Suma
Los datos de auditoría deben incluir cualquier intento de alcanzar un nivel de seguridad diferente por cualquier
persona, proceso, u otra entidad en la red. Esto incluye inicio de sesión y de cierre de sesión, el acceso de usuario
super (o el equivalente no UNIX), la generación de entradas (para Kerberos, por ejemplo), y cualquier otro cambio de
acceso o el estado. Es especialmente importante tener en cuenta "anónimo" o acceso "invitado" a los servidores
públicos.
Los datos reales para recoger serán diferentes en diferentes sitios y con diferentes tipos de cambios de acceso
dentro de un sitio. En general, la información que desea recopilar incluye: nombre de usuario y nombre de host,
para conectarse y desconectarse; anteriores y nuevos derechos de acceso, para un cambio de los derechos de
acceso; y una marca de tiempo. Por supuesto, hay mucho más información que pueda ser recogida, dependiendo
de lo que el sistema hace disponible y la cantidad de espacio disponible para almacenar esa información.
Una nota muy importante: no se reúnen las contraseñas. Esto crea una enorme brecha de seguridad potencial si
los registros de auditoría deben tener acceso de manera incorrecta. No recopilar contraseñas incorrectas tampoco,
ya que a menudo difieren de contraseñas válidas por un solo carácter o transposición.

4.6.2 Proceso de Cobro
El proceso de recogida debe ser promulgada por está accediendo el anfitrión o de recursos. En función de la
importancia de los datos y la necesidad de tener que local en los casos en que los servicios están siendo negados,
los datos podrían ser guardado local para el recurso hasta que se necesite o se transmita al almacenamiento
después de cada evento.
Hay básicamente tres formas de almacenar registros de auditoría: en un archivo de lectura / escritura en un host, en una
de una sola escritura / muchas dispositivo de lectura (por ejemplo, un CD-ROM o una unidad de cinta especialmente
configurado), o en una contra escritura único dispositivo (por ejemplo, una impresora de líneas). Cada método tiene
ventajas y desventajas.
el registro de sistema de archivos es el menos intensivo en recursos de los tres métodos y el más fácil de configurar.
Permite el acceso instantáneo a los registros para el análisis, que puede ser importante si un ataque está en curso.
el registro de sistema de archivos es también el método menos fiable. Si el host de registro ha sido comprometida, el
sistema de archivos suele ser el primero que hay que ir; un intruso podría fácilmente borrar las huellas de la
intrusión.
La recopilación de datos de auditoría en un dispositivo de una sola escritura es ligeramente más esfuerzo de
configurar que un simple archivo, pero tiene la ventaja significativa de gran aumento de la seguridad, ya que un
intruso no podría alterar los datos que muestran que se ha producido una intrusión. La desventaja de este método es
la necesidad de mantener un suministro de medios de almacenamiento y el coste de ese medio. Además, los datos
no pueden ser inmediatamente disponible.
el registro de impresión en línea es útil en el sistema donde se requieren registros permanentes e inmediatos. Un
sistema de tiempo real es un ejemplo de esto, donde se debe registrar el punto exacto de un fallo o ataque. Una
impresora láser, u otro dispositivo que los datos de tampones (por ejemplo, un servidor de impresión), pueden sufrir
de datos perdidos si tampones contienen los datos necesarios en un instante crítico. La desventaja de, literalmente,
"senderos de papel" es la necesidad de mantener la impresora alimentada y la necesidad de registros de escaneo
con la mano. También está la cuestión de dónde almacenar el, potencialmente, un enorme volumen de papel que
pueda generarse.
Para cada uno de los métodos de registro descritas, también existe el problema de asegurar el camino entre el
dispositivo de generar el registro y dispositivo de registro real (es decir, el servidor de archivos, cinta / unidad de
CD-ROM, una impresora). Si se compromete ese camino, el registro se puede detener o suplantada o ambos. En un
mundo ideal, el dispositivo de registro sería directamente

unida por un único, simple, cable punto a punto. Dado que por lo general es poco práctico, la ruta debe pasar a
través del número mínimo de redes y routers. Incluso si los registros pueden ser bloqueados, la suplantación de
identidad se puede prevenir con sumas de control criptográficas (probablemente no es necesario para cifrar los
registros porque no deben contener información sensible en el primer lugar).
4.6.3 Colección de carga
Recogida de datos de auditoría pueden dar lugar a una rápida acumulación de bytes de almacenamiento por lo que
la disponibilidad de esta información se debe considerar de antemano. Hay algunas maneras de reducir el espacio
de almacenamiento necesario. En primer lugar, los datos pueden ser comprimidos, utilizando uno de los muchos
métodos. O bien, el espacio requerido puede ser minimizado por conservar los datos durante un período de tiempo
más corto, con sólo resúmenes de que los datos conservados en los archivos a largo plazo. Un inconveniente
importante de este último método implica la respuesta a incidentes. A menudo, un incidente ha sido constante
durante un periodo de tiempo cuando un sitio se da cuenta de ello y comienza a investigar. En ese punto en el
tiempo, es muy útil contar con registros de auditoría detallada disponible. Si estos son sólo los resúmenes, puede
que no haya suficiente detalle como para manejar completamente el incidente.
4.6.4 Manejo y Conservación de los datos de auditoría
Los datos de auditoría deben ser algunos de los datos más detenidamente asegurados en el lugar y en las copias de
seguridad. Si un intruso tuviera acceso a los registros de auditoría, los propios sistemas, además de los datos,
estarían en riesgo.
Los datos de auditoría también pueden llegar a ser clave para la investigación, aprehensión y enjuiciamiento del
autor de un incidente. Por esta razón, es recomendable buscar el consejo de consejo legal al momento de decidir
qué datos de auditoría deben ser tratados. Esto debería ocurrir antes de que ocurra un incidente.
Si un plan de manejo de datos no está definido de manera adecuada antes de un incidente, puede significar que
no se puede recurrir a raíz de un evento, y puede representar una responsabilidad legal resultante de un
tratamiento inadecuado de los datos.
4.6.5 Consideraciones legales
Debido al contenido de los datos de auditoría, hay una serie de cuestiones legales que surgen que podría necesitar
ser tratado por su asesor legal. Si recoger y guardar los datos de auditoría, es necesario estar preparados para las
consecuencias derivadas tanto de su existencia y de su contenido.

Un área se refiere a la privacidad de las personas. En ciertos casos, los datos de auditoría pueden contener
información personal. Buscando a través de los datos, incluso para un control de rutina de la seguridad del
sistema, podría representar una invasión de la privacidad.
Una segunda área de preocupación consiste en el conocimiento del comportamiento intrusivo procedente de su
sitio. Si una organización mantiene los datos de auditoría, que es responsable del examen para buscar incidentes?
Si un host en una organización se utiliza como punto de partida para un ataque contra otra organización, puede
utilizar la segunda organización los datos de auditoría de la primera organización que probar la negligencia por
parte de esa organización?
Los ejemplos anteriores están destinados a ser exhaustiva, sino que debe motivar a su organización para examinar
las cuestiones legales involucradas con los datos de auditoría.
4.7 Fijación de copias de seguridad
El procedimiento de creación de copias de seguridad es una parte clásica del funcionamiento de un sistema
informático. En el contexto de este documento, las copias de seguridad se tratan como parte del plan general de
seguridad de un sitio. Hay varios aspectos a las copias de seguridad que son importantes en este contexto:
(1) Asegúrese de que su sitio está creando copias de seguridad

(2) Asegúrese de que su sitio está utilizando el almacenamiento externo para copias de seguridad. los
lugar de almacenamiento debe ser cuidadosamente seleccionados tanto por su seguridad y su
disponibilidad.
(3) Considerar el cifrado de las copias de seguridad para proporcionar protección adicional
de la información una vez que está fuera de las instalaciones. Sin embargo, tenga en cuenta que se
necesita un sistema de gestión de claves buena manera de que usted será capaz de recuperar los datos
en cualquier momento en el futuro. Además, asegúrese de que usted tendrá acceso a los programas de
descifrado necesarias en el momento en el futuro como sea necesario para realizar el descifrado.
(4) no siempre asumen que las copias de seguridad son buenas. Ha habido
muchos casos de incidentes de seguridad que han pasado por largos períodos de tiempo antes de que un
sitio se ha dado cuenta del incidente. En tales casos, también están contaminados copias de seguridad de los
sistemas afectados. (5) verificar periódicamente la exactitud e integridad de su
copias de seguridad.
Manipulación 5. Incidentes de Seguridad
Este capítulo del documento proporcionará orientación a utilizar antes, durante y después de un incidente de
seguridad informática se produce en un host, red, sitio o entorno multi-sitio. La filosofía operativa en el caso de una
violación de la seguridad informática es reaccionar de acuerdo

a un plan. Esto es cierto si el incumplimiento es el resultado de un ataque de intrusión externa, el daño no

intencionado, un estudiante probar algún nuevo programa para aprovechar una vulnerabilidad de software o un
empleado descontento. Cada uno de los posibles tipos de eventos, como las que acabamos de mencionar,
deberán dirigirse por adelantado por los planes de contingencia adecuados.
la seguridad informática tradicional, aunque muy importante en el plan de seguridad general del lugar, por lo
general presta poca atención a cómo manejar efectivamente el ataque después de que ocurran. El resultado es
que cuando un ataque está en curso, muchas decisiones se toman de prisa y puede ser perjudicial para rastrear el
origen del incidente, la recopilación de pruebas para ser utilizado en esfuerzos de procesamiento, la preparación
para la recuperación del sistema, y la protección de la valiosos datos contenidos en el sistema.
Uno de los más importantes, pero a menudo se pasa por alto, los beneficios para el manejo eficiente incidente es
de carácter económico. Habiendo tanto responden al personal técnico y de gestión a un incidente requiere
recursos considerables. Si capacitado para manejar eficientemente los incidentes, se requiere menos tiempo del
personal cuando se presenta una.
Debido a la red en todo el mundo la mayoría de los incidentes no se limitan a un solo sitio. vulnerabilidades del
sistema operativo se aplican (en algunos casos) a varios millones de sistemas, y muchas vulnerabilidades se
explotan dentro de la propia red. Por lo tanto, es vital que todos los sitios con las partes involucradas serán
informados tan pronto como sea posible.
Otra ventaja está relacionada con las relaciones públicas. Noticias sobre incidentes de seguridad informática tiende
a ser perjudicial para la estatura de una organización entre los clientes actuales o potenciales. manejo de
incidentes eficiente minimiza el potencial de exposición negativa.
Un beneficio final de un manejo eficiente incidente está relacionado con cuestiones legales. Es posible que en las
organizaciones futuro próximo puede ser responsable porque uno de sus nodos se utilizó para lanzar un ataque a
la red. En una línea similar, las personas que desarrollan parches o soluciones pueden ser demandados si los
parches o soluciones son ineficaces, lo que resulta en el compromiso de los sistemas, o, si los parches o
soluciones propias dañar los sistemas. Saber sobre el funcionamiento de las vulnerabilidades y los patrones de los
ataques del sistema, y luego tomar las medidas apropiadas para contrarrestar estas amenazas potenciales, es
fundamental para eludir posibles problemas legales.

Los apartados de este capítulo proporcionan un esquema y punto de partida para la creación de la política de su sitio
para el manejo de incidentes de seguridad. Las secciones son:
(1) Preparación y planificación (¿cuáles son las metas y objetivos en

el manejo de un incidente).
(2) La notificación (quién debe ser contactado en el caso de una
incidente).
- Los gerentes locales y personal
- la policía y los organismos de investigación
- manejo de equipos de incidentes de seguridad informática
- sitios afectados e involucrados
- Comunicaciones internas
- relaciones públicas y comunicados de prensa
(3) La identificación de un incidente (que es un incidente y la gravedad es
eso).
(4) Manipulación (lo que se debe hacer cuando se produce un incidente).
- Notificación (quién debe ser notificado sobre el incidente)
- La protección de pruebas y registros de actividad (lo que se debe mantener registros de antes, durante
y después del incidente)
- Contención (¿cómo puede el daño limitarse)
- Erradicación (la forma de eliminar las razones del incidente)
- Recuperación (la forma de servicio y sistemas de restablecerlo)
- Seguimiento (qué acciones se deben tomar después del incidente)
(5) Consecuencias (¿cuáles son las consecuencias de los incidentes del pasado). (6) respuesta
administrativa a los incidentes.
El resto de este capítulo se detalle los problemas involucrados en cada uno de los temas importantes mencionados
anteriormente, y proporcionan una cierta orientación en cuanto a lo que debe incluirse en una directiva de sitio para
el manejo de incidentes.
5.1 Preparación y Planificación para el Manejo de Incidentes
Parte de manejar un incidente está siendo preparado para responder a un incidente antes de que ocurra el incidente
en el primer lugar. Esto incluye el establecimiento de un nivel adecuado de protección tal como se explica en los
capítulos anteriores. Hacer esto debería ayudar a su sitio a prevenir incidentes, así como el daño potencial límite
resultante de ellos cuando se produzcan. La protección también incluye la preparación de pautas de manejo de
incidentes como parte de un plan de contingencia para su organización o en el sitio. Tener planes escritos elimina
gran parte de la ambigüedad que se produce durante un incidente, y dará lugar a un conjunto más apropiada y
completa de las respuestas. Es de vital importancia para poner a prueba el plan propuesto antes de que ocurra un
incidente mediante "en seco". Un equipo podría incluso considerar la contratación de un equipo de tigre para actuar
en paralelo con el funcionamiento en seco. (Nota:

Aprender a responder eficientemente a un incidente es importante por varias razones:
(1) La protección de los activos que podrían verse comprometidas (2) La protección de los
recursos que podrían ser utilizados más
rentable si un incidente no requería sus servicios (3) Cumplir con las regulaciones del gobierno (u
otros) (4) prevenir el uso de los sistemas de los ataques contra otra
sistemas (que podría provocar que se incurra en responsabilidad legal) (5) minimizar el
potencial de exposición negativa
Al igual que en cualquier conjunto de procedimientos planificados con anterioridad, se debe prestar atención a una
serie de objetivos para el manejo de un incidente. Estos objetivos serán priorizadas de manera diferente
dependiendo del sitio. Un conjunto específico de objetivos puede ser identificado para tratar los incidentes:
(1) La figura cómo sucedió.

(2) Busca la manera de evitar una mayor explotación de la misma
vulnerabilidad.
(3) evitar la escalada y otros incidentes. (4) Evaluar el impacto y el daño del
incidente. (5) se recuperan de la incidente.
(6) Las políticas y procedimientos de actualización, según sea necesario. (7) Para saber
quién lo hizo (si es apropiado y posible).
Debido a la naturaleza del incidente, que podría haber un conflicto entre el análisis de la fuente original de un
problema y sistemas y servicios de restauración. objetivos generales (como asegurar la integridad de los sistemas
críticos) podrían ser la razón para no analizar un incidente. Por supuesto, se trata de una decisión de gestión
importante; pero todas las partes implicadas deben ser conscientes de que sin un análisis del mismo incidente
puede ocurrir de nuevo.
También es importante dar prioridad a las medidas que deben tomarse durante un incidente con suficiente
antelación a la vez que se produce un incidente. A veces un incidente puede ser tan complejo que es imposible
hacer todo a la vez de responder a ella; prioridades son esenciales. Aunque las prioridades varían de una
institución a otra, la siguiente sugirió prioridades pueden servir como punto de partida para definir la respuesta de
su organización:
(1) Prioridad uno - la vida humana y la protección de las personas

la seguridad; la vida humana siempre tiene prioridad sobre cualquier otra
consideración.
(2) Prioridad de dos - protección clasificada y / o sensible

datos. Prevenir la explotación de los anuncios y / o sensibles sistemas, redes o sitios.
informar a los afectados

clasifican y / o sistemas sensibles, redes o sitios sobre el que ya se produjeron

penetraciones.
(Tenga en cuenta las regulaciones de su sitio o por el gobierno)
(3) Tercera prioridad - Otros datos de protección, incluyendo

propietarias, científicos, administrativos y otros datos, debido a la pérdida de datos es
costoso en términos de recursos. Evitar que las explotaciones de otros sistemas, redes o
sitios e informar a los afectados ya los sistemas, redes o sitios alrededor de penetraciones
exitosas.
(4) Prioridad de cuatro - evitar daños en sistemas (por ejemplo, pérdida de

o alteración de los archivos del sistema, daños a las unidades de disco, etc.). El daño a los
sistemas puede resultar en costosos tiempos de inactividad y recuperación.
(5) Quinta prioridad - minimizar la interrupción del cómputo

recursos (incluyendo procesos). Es mejor en muchos casos a cerrar un sistema de abajo o
desconectarse de una red de daños a los riesgos a los datos o sistemas. Sitios tendrán que
evaluar las compensaciones entre apagar y desconectar, y quedarse hasta. Puede haber
acuerdos de servicio en el lugar que puede requerir la actualización de los sistemas, incluso a
la luz de nuevos daños que se produzcan. Sin embargo, el daño y el alcance de un incidente
pueden ser tan extensa que los acuerdos de servicios pueden tener que ser montado sobre-.
Una implicación importante para la definición de las prioridades es que una vez que la vida humana y
consideraciones de seguridad nacional han sido abordados, es generalmente más importante para guardar los
datos que el software y el hardware del sistema. Aunque es deseable tener cualquier daño o pérdida durante un
incidente, los sistemas pueden ser reemplazados. Sin embargo, la pérdida o el compromiso de los datos (sobre
todo clasificado o datos de propiedad) no es por lo general un resultado aceptable bajo ninguna circunstancia.
Otra preocupación importante es el efecto sobre los demás, más allá de los sistemas y redes en las que se produce
el incidente. Dentro de los límites impuestos por las regulaciones gubernamentales siempre es importante informar a
las partes afectadas tan pronto como sea posible. Debido a las implicaciones legales de este tema, se debe incluir
en los procedimientos previstos para evitar más retrasos e incertidumbres para los administradores.
Cualquier plan de respuesta a incidentes de seguridad debe estar guiada por las políticas y las regulaciones
locales. Gobierno y sitios privados que tienen que ver con el material clasificado tienen reglas específicas que
deben seguir.

Las políticas elegidas por su sitio en la forma en que reacciona a los incidentes dará forma a su respuesta. Por
ejemplo, puede tener poco sentido para crear mecanismos de seguimiento e intrusos traza si su sitio no tiene la
intención de tomar medidas contra los intrusos si son atrapados. Otras organizaciones pueden tener políticas que
afectan a sus planes. compañías telefónicas suelen lanzar información sobre los rastros teléfono solamente para los
organismos policiales.
Manejo de incidentes pueden ser tedioso y requiere ningún número de tareas rutinarias que pueden ser manejados
por personal de apoyo. Para liberar el personal técnico puede ser útil para identificar personal de apoyo que le
ayudará con tareas como: fotocopias, fax'ing, etc.
5.2 Notificación y puntos de contacto
Es importante establecer contactos con diversos miembros del personal antes de que ocurra un incidente real.
Muchas veces, los incidentes no son emergencias reales. De hecho, a menudo usted será capaz de manejar las
actividades internamente. Sin embargo, también habrá muchos momentos en los que tendrán que ser incluidos en el
manejo de incidentes otras personas fuera de su departamento de inmediato. Estos contactos adicionales incluyen
gerentes y administradores de sistemas locales, contactos administrativos para otros sitios en Internet, y varias
organizaciones de investigación. Conocer a estos contactos, antes de los incidentes ocurre esto ayuda a que su
proceso de manejo de incidentes más eficiente.
Para cada tipo de contacto de comunicación, deben definirse "Puntos de contacto" específicos (POC). Estos pueden
ser de carácter técnico o administrativo en la naturaleza y pueden incluir agencias legales o de investigación, así
como los proveedores de servicios y proveedores. Al establecer estos contactos, es importante para decidir cuánta
información será compartida con cada clase de contacto. Es especialmente importante definir, antes de tiempo, la
información que se comparte con los usuarios en un sitio, con el público (incluida la prensa), y con otros sitios.
La solución de estos problemas son especialmente importantes para la persona local responsable de manejar el
incidente, ya que es la persona responsable de la notificación real de los demás. Una lista de contactos en cada una
de estas categorías es un ahorro de tiempo importante para esta persona durante un incidente. Puede ser muy difícil
encontrar una persona adecuada durante un incidente cuando muchos eventos urgentes están en curso. Se
recomienda encarecidamente que todos los números de teléfono correspondientes (números de fax también las
direcciones de correo electrónico y) se incluirán en la política de seguridad del sitio. El nombre y la información de
contacto de todas las personas que van a participar directamente en el manejo de un incidente debe ser colocado en
la parte superior de esta lista.

5.2.1 Los administradores locales y personal
Cuando un incidente está en marcha, un problema importante es decidir quién es el encargado de coordinar la
actividad de la multitud de jugadores. Un gran error que se puede hacer es tener un número de personas que están
trabajando cada uno de forma independiente, pero no están trabajando juntos. Esto sólo servirá para aumentar la
confusión del evento y probablemente conducirá a esfuerzo inútil o ineficaz.
La única POC puede o no ser la persona responsable de manejar el incidente. Hay dos funciones distintas para
llenar al momento de decidir quien será el POC y quién será el responsable del incidente. La persona a cargo del
incidente tomará decisiones en cuanto a la interpretación de la política aplicada al evento. Por el contrario, el POC
debe coordinar el esfuerzo de todas las partes involucradas con el manejo del evento.
El POC debe ser una persona con la experiencia técnica para coordinar con éxito los esfuerzos de los
administradores de sistemas y usuarios que participan en la vigilancia y reaccionar ante el ataque. Se debe tener
cuidado al identificar quién será esta persona. No debe ser necesariamente la misma persona que tiene la
responsabilidad administrativa de los sistemas comprometidos ya que muchas veces estos administradores tienen
conocimiento sólo es suficiente para el uso diario de los ordenadores, y carecen de experiencia técnica en
profundidad.
Otra función importante del POC es mantener el contacto con la policía y otras agencias externas para asegurar que
se produce la participación de varios organismos. El nivel de participación será determinado por las decisiones de
gestión, así como las restricciones legales.
Un solo POC debe ser también la única persona encargada de la recogida de pruebas, ya que como regla general,
mientras más personas que tocan una pieza de evidencia potencial, mayor será la posibilidad de que será
inadmisible en los tribunales. Para asegurar que las pruebas será aceptable para la comunidad legal, la recopilación
de pruebas debe hacerse siguiendo procedimientos predefinidos de acuerdo con las leyes locales y regulaciones
legales.
Una de las tareas más críticas para el POC es la coordinación de todos los procesos relevantes. Las
responsabilidades pueden estar distribuidas por todo el sitio, con la participación de múltiples departamentos o
grupos independientes. Esto requerirá un esfuerzo bien coordinado con el fin de lograr el éxito en general. La
situación se complica aún más si se trata de múltiples sitios. Cuando esto sucede, rara vez una sola POC en un sitio
de poder coordinar adecuadamente el manejo de todo el incidente. En su lugar, los equipos de respuesta a
incidentes apropiadas deben estar involucrados.

El proceso de manejo de incidentes debe proporcionar algunos mecanismos de escalamiento. Con el fin de definir
un mecanismo de este tipo, los sitios tendrán que crear un esquema de clasificación interna de incidentes.
Asociado a cada nivel de incidente será el POC y procedimientos apropiados. A medida que se escala un
incidente, puede haber un cambio en el POC, que tendrá que ser comunicada a todos los demás involucrados en
el manejo del incidente. Cuando se produce un cambio en el POC, viejo POC debe informar al nuevo POC en toda
la información de fondo.
Por último, los usuarios deben saber cómo reportar incidentes sospechosos. Los sitios deben establecer
procedimientos de información que trabajarán durante y fuera de las horas normales de trabajo. servicios de
asistencia a menudo se utilizan para recibir estos informes durante las horas normales de trabajo, mientras que
buscapersonas y teléfonos se pueden utilizar para fuera del horario de presentación de informes.
5.2.2 Aplicación de la Ley y de los organismos de investigación
En el caso de un incidente que tiene consecuencias legales, es importante establecer contacto con los organismos
de investigación (por ejemplo, el FBI y el Servicio Secreto de los EE.UU.) tan pronto como sea posible. la policía
local, oficinas locales de seguridad, y de la escuela los departamentos de policía también deben ser informados
según corresponda. En esta sección se describen muchos de los problemas que se enfrentan, pero se reconoce que
cada organización tiene sus propias leyes y regulaciones locales y gubernamentales que afectarán a la forma en que
interactúan con la policía y los organismos de investigación. El punto más importante a destacar es que cada sitio
tiene que trabajar a través de estas cuestiones.
Una razón principal para determinar estos puntos de contacto bien con antelación de un incidente es que una vez
que un gran ataque está en marcha, hay poco tiempo para llamar a estas agencias para determinar exactamente
quién es el punto de contacto es correcta. Otra razón es que es importante cooperar con estos organismos de una
manera que fomente una buena relación de trabajo, y que se hará de acuerdo con los procedimientos de trabajo de
estos organismos. El conocimiento de los procedimientos de trabajo de anticipación, y las expectativas de su punto
de contacto es un gran paso en esta dirección. Por ejemplo, es importante para reunir pruebas que será admisible
en cualesquiera procedimientos judiciales posteriores, y esto requerirá un conocimiento previo de cómo reunir esas
pruebas. Una última razón para el establecimiento de contactos lo más pronto posible es que es imposible conocer
la agencia en particular que va a asumir la competencia en cualquier incidente. Hacer contactos y encontrar los
canales adecuados desde el principio hará frente a un suceso ir mucho más suavemente.

Si su organización o sitio cuenta con un asesor legal, es necesario notificar a esta oficina poco después se entera de
que un incidente está en curso. Como mínimo, sus necesidades de asesoría legal a estar involucrados para proteger
los intereses legales y financieros de su sitio u organización. Hay muchas cuestiones legales y prácticas, algunas de
las cuales son:
(1) Si su sitio u organización está dispuesta a negativo riesgo

la publicidad o la exposición a cooperar con los esfuerzos judiciales legales.
(2) la responsabilidad de Downstream - si usted deja un sistema comprometido como es tan

se puede supervisar y otro equipo está dañado debido a que el ataque se originó a partir de su sistema, su
sitio u organización puede ser responsable de los daños ocasionados.
(3) Distribución de información - si su sitio u organización

distribuye información sobre un ataque en el que otro sitio u organización pueden estar implicados o la
vulnerabilidad en un producto que puede afectar la comercialización de ese producto, su sitio u organización
puede volver a ser responsable de ningún daño (incluyendo daños a la reputación).
(4) Pasivo debido a la vigilancia - su sitio u organización puede ser

demandados si los usuarios en su sitio o en otro lugar descubren que su sitio está monitoreando la
actividad de cuenta sin informar a los usuarios.
Desafortunadamente, no existen precedentes claros todavía sobre las responsabilidades o responsabilidades de las
organizaciones involucradas en un incidente de seguridad o que podrían estar involucrados en el apoyo a un
esfuerzo de investigación. Los investigadores suelen alentar a las organizaciones de rastrear ayuda y los intrusos
monitor. De hecho, la mayoría de los investigadores no pueden perseguir intrusiones en computadoras sin el apoyo
de las organizaciones involucradas. Sin embargo, los investigadores no pueden proporcionar protección frente a las
demandas de responsabilidad, y este tipo de esfuerzos pueden lastrar durante meses y puede tomar mucho
esfuerzo.
Por otra parte, el consejo legal de una organización puede aconsejar extrema precaución y sugieren que se
detengan las actividades de búsqueda y un intruso excluidos del sistema. Esto, en sí mismo, no puede proporcionar
protección contra la responsabilidad, y puede evitar que los investigadores de identificar al autor.
El equilibrio entre el apoyo a la actividad investigadora y la limitación de la responsabilidad es complicado. Tendrá

que tener en cuenta el consejo de su asesor legal y el daño al intruso está causando (si lo hay) al tomar su decisión
acerca de qué hacer durante cualquier incidente en particular.

Su asesor legal también debe estar involucrado en cualquier decisión de los organismos de investigación de
contacto cuando ocurre un incidente en su sitio. La decisión de coordinar esfuerzos con los organismos de
investigación es más adecuada que la de su sitio u organización. La participación de su asesor legal también
fomentará la coordinación de varios niveles entre su sitio y la agencia de investigación implicado en particular, que a
su vez se traduce en una división eficiente del trabajo. Otro resultado es que el usuario puede obtener una guía que
le ayudará a evitar futuros errores legales.
Por último, su abogado debe evaluar los procedimientos escritos de su sitio para responder a incidentes. Es
esencial para obtener un "certificado de buena salud" desde una perspectiva legal antes de que realmente llevar a
cabo estos procedimientos.
Es de vital importancia, cuando se trata de organismos de investigación, para verificar que la persona que las
llamadas pidiendo información es un representante legítimo de la agencia en cuestión. Por desgracia, muchas
personas bien intencionadas han filtrado detalles sensibles, sin saberlo, por los incidentes, permitió que personas no
autorizadas en sus sistemas, etc., debido a que una persona que llama ha hecho pasar como representante de una
agencia gubernamental. (Nota: esta palabra de precaución en realidad se aplica a todos los contactos externos.)
Una consideración similar se utiliza un medio seguro de comunicación. Debido a que muchos atacantes de red
pueden fácilmente modificar el trazado de correo electrónico, evite usar el correo electrónico para comunicarse con
otras agencias (así como otras tratar con el incidente que nos ocupa). líneas telefónicas seguras no (los teléfonos
utilizados normalmente en el mundo de los negocios) también son blancos frecuentes de roscar por intrusos de la
red, así que ten cuidado!
No hay nadie establecido conjunto de reglas para responder a un incidente cuando el gobierno local se involucra.
Normalmente (en los EE.UU.), salvo por orden judicial, ningún organismo puede forzar a que el monitor, a
desconectarse de la red, para evitar el contacto telefónico con los atacantes sospechosos, etc. Cada organización
tendrá un conjunto de leyes y reglamentos locales y nacionales que deben respetarse para el manejo de incidentes.
Se recomienda que cada sitio esté familiarizado con las leyes y reglamentos, e identificar y conseguir saber los
contactos para los organismos con competencia suficiente antelación de manejar un incidente.
5.2.3 Seguridad Informática Equipos de tratamiento de incidentes
En este momento hay una serie de equipos de seguridad informática de Respuesta de Incidentes (CSIRT), como
el Centro de Coordinación CERT, el alemán DFN-CERT, y otros equipos de todo el mundo. Existen equipos para
muchas de las principales agencias gubernamentales y grandes corporaciones. Si por ejemplo una

equipo está disponible, notificando que debería ser una consideración primordial durante las primeras etapas de un
incidente. Estos equipos son responsables de la coordinación de los incidentes de seguridad informática en un
rango de sitios y entidades de mayor tamaño. Incluso si se cree que el incidente se encierra en un solo sitio, es
posible que la información disponible a través de un equipo de respuesta podría ayudar a resolver totalmente el
incidente.
Si se determina que el incumplimiento se produjo debido a una falla en el hardware o el software del sistema, el
proveedor (o proveedores) y un equipo de manejo de incidentes de seguridad informática debe ser notificado tan
pronto como sea posible. Esto es especialmente importante porque muchos otros sistemas son vulnerables, y estas
organizaciones de proveedores de equipo y de respuesta puede ayudar a contribuir a la difusión a otros sitios
afectados.
En la creación de una política de sitio para la entrega incidente, puede ser deseable la creación de un subgrupo, al
igual que aquellos equipos que ya existen, que será responsable del manejo de incidentes de seguridad informática
para el sitio (u organización). Si se crea un equipo de este tipo, es esencial que se abran las líneas de comunicación
entre este equipo y otros equipos. Una vez que un incidente está en marcha, es difícil de abrir un diálogo de
confianza entre otros equipos si no ha existido antes.
5.2.4 sitios afectados e involucrados
Si un incidente tiene un impacto en otros sitios, es una buena práctica para informarles. Puede ser obvio desde el
principio que el incidente no se limita al sitio local, o puede surgir sólo después de un análisis más detallado.
Cada sitio puede optar por ponerse en contacto con otros sitios directamente o pueden pasar la información a un
equipo de respuesta a incidentes apropiado. A menudo es muy difícil encontrar el POC responsable en sitios
remotos y el equipo de respuesta a incidentes será capaz de facilitar el contacto al hacer uso de los canales ya
establecidos.
Las cuestiones legales y de responsabilidad derivados de un incidente de seguridad serán diferentes de un sitio a
otro. Es importante definir una política para el intercambio y registro de la información sobre otros sitios antes de que
ocurra un incidente.
Información sobre personas específicas es especialmente sensible, y puede estar sujeto a las leyes de privacidad.
Para evitar problemas en esta área, la información irrelevante debería suprimirse y una declaración de cómo manejar
la información restante debe ser incluido. Una declaración clara de cómo esta información se va a utilizar es
esencial. Nadie que informa a un sitio de un incidente de seguridad quiere leer sobre él en el público

prensa. equipos de respuesta a incidentes son valiosos en este sentido. Cuando pasan información a los
responsables POC, que son capaces de proteger el anonimato de la fuente original. Sin embargo, tenga en
cuenta que, en muchos casos, el análisis de los registros y la información en otros sitios revelará las direcciones
de su sitio.
Todos los problemas descritos anteriormente no deben ser tomadas como razones para no involucrar a otros sitios.
De hecho, las experiencias de los equipos existentes revelan que la mayoría de los sitios informados acerca de los
problemas de seguridad ni siquiera son conscientes de que su sitio había sido comprometida. Sin información
oportuna, otros sitios son a menudo incapaces de tomar medidas contra los intrusos.
5.2.5 Comunicación Interna
Es crucial durante un incidente importante para comunicar por qué se toman ciertas acciones, y cómo se espera que
los usuarios (o departamentos) a comportarse. En particular, debe quedar muy claro a los usuarios lo que se les
permite decir (y no digamos) con el mundo exterior (incluyendo otros departamentos). Por ejemplo, no sería bueno
para una organización si los usuarios respondieron a los clientes con algo como, "Lo siento los sistemas están abajo,
hemos tenido un intruso y que están tratando de limpiar las cosas arriba." Sería mucho mejor si se les instruyó para
responder con una declaración preparada como, "Lo siento nuestros sistemas no estén disponibles, que se
mantienen para un mejor servicio en el futuro."
Las comunicaciones con los clientes y contratantes deben ser manejados de una manera sensible, pero sensible.
Uno puede prepararse para los temas principales mediante la preparación de una lista de verificación. Cuando se
produce un incidente, la lista puede ser utilizada con la adición de una frase o dos de las circunstancias específicas
del incidente.
los departamentos de relaciones públicas pueden ser muy útiles durante los incidentes. Ellos deben participar en
toda la planificación y pueden proporcionar respuestas bien construidos para su uso cuando es necesario el
contacto con los departamentos y organizaciones externas.
5.2.6 Relaciones Públicas - Notas de prensa
Ha habido un enorme crecimiento en la cantidad de cobertura mediática dedicada a incidentes de seguridad

informática en los Estados Unidos. Dicha cobertura de prensa está obligado a extenderse a otros países a medida
que Internet continúa creciendo y expandiéndose a nivel internacional. Los lectores de países en los que aún no se
ha llevado a cabo esa atención de los medios, pueden aprender de las experiencias en los EE.UU. y debe ser
avisado y preparado.

Una de las cuestiones más importantes a tener en cuenta es cuándo, quién, y cuánto para liberar al público en
general a través de la prensa. Hay muchas cuestiones a considerar al decidir este tema en particular. En primer
lugar, si existe una oficina de relaciones públicas para el sitio, es importante la utilización de esta oficina de enlace
con la prensa. La oficina de relaciones públicas está entrenado en el tipo y la redacción de la información dada a
conocer, y ayudará a asegurar que la imagen del sitio está protegido durante y después del incidente (si es posible).
Una oficina de relaciones públicas tiene la ventaja de que se puede comunicar abiertamente con ellos, y
proporcionar un amortiguador entre la atención de la prensa y la necesidad constante de la POC para mantener el
control sobre el incidente.
Si una oficina de relaciones públicas no está disponible, la información difundida a la prensa debe ser
considerado cuidadosamente. Si la información es sensible, puede ser ventajoso proporcionar sólo información
mínima o vista general para la prensa. Es muy posible que cualquier información proporcionada a la prensa será
revisada rápidamente por el autor del incidente. También tenga en cuenta que puede engañar a la prensa a
menudo contraproducente y causar más daño que la divulgación de información sensible.
Si bien es difícil determinar con antelación qué nivel de detalle para ofrecer a la prensa, algunas pautas a tener en
cuenta son:
(1) Mantener el nivel técnico de detalles de baja. Detallado

información sobre el incidente puede proporcionar suficiente información para que
otros puedan lanzar ataques similares en otros sitios, o incluso dañar la capacidad del
sitio para procesar a los culpables una vez que el evento ha terminado.
(2) Mantener la especulación de las declaraciones de prensa.

La especulación de que está causando el incidente o los motivos son muy propensos a
estar en un error y puede causar una vista inflamada del incidente.
(3) El trabajo con profesionales de la ley para asegurar que

la evidencia está protegida. Si el procesamiento es complicado, asegurar que las pruebas
recogidas no se divulga a la prensa.
(4) No trate de ser forzados en una entrevista a la prensa antes de estar

preparado. La prensa popular es famoso por la entrevista "2 AM", donde la esperanza es coger
el entrevistado por sorpresa y obtener información que no está disponible.
(5) No permita que la atención de la prensa que en detrimento de la

el manejo del evento. Recuerde siempre que el cierre exitoso de un incidente es de primordial
importancia.

5.3 Identificación de un incidente
5.3.1 ¿Es real?
Esta etapa consiste en determinar si un problema existe realmente. Por supuesto, muchos, si no la mayoría de los
signos a menudo asociadas con la infección por virus, intrusiones en el sistema, los usuarios maliciosos, etc., son
simplemente anomalías tales como los fallos de hardware o sospechoso del sistema / comportamiento de los
usuarios. Para ayudar a identificar si existe realmente un incidente, por lo general es útil para obtener y utilizar
cualquier software de detección que puede estar disponible. La información de auditoría también es muy útil,
especialmente para determinar si hay un ataque a la red. Es extremadamente importante para obtener una
instantánea del sistema tan pronto como uno sospecha que algo anda mal. Muchos incidentes causan una cadena
dinámica de los acontecimientos que se produzca, y una instantánea inicial del sistema puede ser la herramienta
más valiosa para identificar el problema y cualquier fuente de ataque. Por último, es importante empezar un libro de
registro. Grabación de eventos del sistema,
Hay ciertas indicaciones o "síntomas" de un incidente que merecen especial atención:
(1) Sistema bloquea.

(2) Las nuevas cuentas de usuario (la cuenta se ha Rumplestiltskin
inesperadamente creado), o de alta actividad en una cuenta de uso previamente bajo.
(3) Los nuevos archivos (por lo general con nombres de archivos nuevos o extraña,
tales como data.xx o k o .xx).
(4) Contabilidad discrepancias (en un sistema UNIX que podría
notar la reducción de un archivo de contabilidad llamado / usr / admin / lastlog, algo que se
debe hacer muy sospechoso que puede haber un intruso). (5) Los cambios en las longitudes de
archivos o fechas (un usuario debe ser
sospechoso si los archivos .EXE en un ordenador MS DOS han crecido unexplainedly por
más de 1800 bytes). (6) intenta escribir en el sistema (un gestor de sistema de comunicaciones
que un usuario privilegiado en un sistema VMS está tratando de RIGHTSLIST.DAT alter).
(7) la modificación o supresión de datos (archivos comienzan a desaparecer). (8) denegación de servicio
(un administrador de sistema y todos los demás usuarios
convertido bloqueada fuera de un sistema UNIX, ahora en el modo de usuario único). (9) sin
explicación, pobre rendimiento del sistema
(10) Anomalías ( "GOTCHA" se visualiza en la consola o no
son frecuentes "bips" inexplicables).
(11) sondas sospechosas (hay numerosos entrada infructuosos
intentos de otro nodo).

(12) sospechoso de navegación (alguien se convierte en un usuario root en un UNIX

sistema y accesos de archivos después de archivo en varias cuentas de usuario.) (13) Incapacidad de
un usuario para iniciar sesión debido a las modificaciones de su / su
cuenta.
De ninguna manera es esta lista exhaustiva; que acabamos de lista de una serie de indicadores comunes. Es mejor
para colaborar con otro personal de seguridad técnica y equipo es para tomar una decisión como grupo acerca de si
se produce un incidente.
5.3.2 Tipos y alcance de los incidentes
Junto con la identificación del incidente es la evaluación del alcance y el impacto del problema. Es importante
identificar correctamente los límites del incidente con el fin de tratar eficazmente con ella y respuestas priorizar.
Con el fin de identificar el alcance y el impacto de un conjunto de criterios debe ser definido que es apropiado para el
sitio y al tipo de conexiones disponibles. Algunos de los temas incluyen:
(1) ¿Es este un incidente de múltiples sitios?

(2) ¿Son muchas computadoras en su sitio afectados por este incidente? (3) de tratarse de información
sensible?
(4) ¿Cuál es el punto de entrada del incidente (de red,
línea de teléfono, terminal local, etc.)? (5) Es la prensa
involucrados?
(6) ¿Cuál es el daño potencial del incidente? (7) ¿Cuál es el tiempo estimado para cerrar el incidente?
(8) ¿Qué recursos podría ser necesaria para manejar el incidente? (9) es hacer cumplir la ley
implicados?
5.3.3 La evaluación de los daños y Extensión
El análisis de los daños y el alcance del incidente puede ser bastante tiempo, pero debería conducir a una idea de
la naturaleza del incidente, y la investigación y el enjuiciamiento de ayuda. Tan pronto como se haya producido el
incumplimiento, todo el sistema y todos sus componentes deben ser considerados sospechosos. El software del
sistema es el objetivo más probable. La preparación es clave para ser capaz de detectar todos los cambios para un
sistema posiblemente contaminada. Esto incluye la suma de comprobación todos los medios de comunicación del
proveedor usando un algoritmo que es resistente a la manipulación indebida. (ver sección 4.3)
Suponiendo que los medios de distribución de los proveedores originales están disponibles, un análisis de todos
los archivos del sistema debe comenzar, y cualquier irregularidad deben tenerse en cuenta y que se refiere a todas
las partes involucradas en el manejo del incidente. Puede ser muy difícil, en algunos casos, para decidir qué

medios de copia de seguridad están mostrando un estado del sistema correcto. Consideremos, por ejemplo, que el
incidente pudo haber continuado durante meses o incluso años antes del descubrimiento, y que el sospechoso
puede ser un empleado del sitio, o de lo contrario tener conocimiento íntima o acceso al sistema. En todos los
casos, la preparación previa al incidente determinará lo que es posible recuperación.
Si los soportes sistema centralizado de registro (la mayoría lo hacen), volver sobre los troncos y buscar anomalías.
Si la contabilidad de procesos y gestión de tiempos de conexión está activada, busca patrones de uso del sistema.
En menor medida, el uso del disco puede arrojar luz sobre el incidente. Contabilidad puede proporcionar mucha
información útil para el análisis de un incidente y posterior procesamiento. Su capacidad para hacer frente a todos
los aspectos de un incidente específico depende en gran medida del éxito de este análisis.
5.4 Manipulación de un incidente
Ciertos pasos son necesarios para tomar durante el manejo de un incidente. En todas las actividades relacionadas
con la seguridad, el punto más importante que debe hacerse es que todos los sitios deben tener políticas. Sin
políticas y objetivos definidos, las actividades realizadas permanecerán sin foco. Los objetivos deben ser definidos
por la dirección y el asesor legal de antemano.
Uno de los objetivos más fundamentales es para restaurar el control de los sistemas afectados y limitar el impacto
y el daño. En el peor de los casos, se apaga el sistema, o desconectar el sistema de la red, puede la única solución
práctica.
A medida que las actividades involucradas son complejas, trate de obtener toda la ayuda necesaria. Al tratar de
resolver el problema por sí solo, un daño real podría ocurrir debido a retrasos o falta de información. La mayoría de
los administradores toman el descubrimiento de un intruso como un reto personal. Al proceder de esta manera,
otros objetivos como se indica en las políticas locales pueden no siempre ser considerados. Tratando de intrusos
de captura puede ser una prioridad muy baja, en comparación con la integridad del sistema, por ejemplo.
Supervisión de la actividad de un hacker es útil, pero no podría considerarse la pena el riesgo de permitir el acceso
continuado.
5.4.1 Tipos de Notificación e Intercambio de Información
Cuando haya confirmado que un incidente está ocurriendo, deben ser notificadas al personal apropiado. ¿Cómo
se logra esta notificación es muy importante para mantener el caso bajo control tanto desde el punto de vista
técnico y emocional. Las circunstancias deben describirse con el mayor detalle posible, con el fin de facilitar el
reconocimiento rápido y comprensión del problema. Es preciso prestar atención

deben tomarse para determinar a qué grupos detallada Información técnica se da durante la notificación. Por
ejemplo, es útil para pasar este tipo de información a un equipo de manejo de incidentes ya que le puede ayudar
proporcionando consejos útiles para la erradicación de las vulnerabilidades involucrados en un incidente. Por otro
lado, poner el conocimiento crítico en el dominio público (por ejemplo, a través de grupos de noticias USENET o
listas de correo) potencialmente pueden poner un gran número de sistemas en riesgo de intrusión. No es válido
suponer que todos los administradores de la lectura de un grupo de noticias en particular tengan acceso al código
fuente del sistema operativo, o incluso pueden entender lo suficientemente bien como un asesor para tomar las
medidas adecuadas.
En primer lugar, ninguna notificación a cualquiera de personal local o fuera de las instalaciones debe ser explícita.
Esto requiere que cualquier declaración (ya sea un mensaje electrónico electrónico, llamada telefónica, fax,
buscapersonas, o semaphone) proporcionar información sobre el incidente ser clara, concisa y completa. Cuando se
le notifica a los demás que le ayudará a controlar un evento, una "cortina de humo" sólo dividir el esfuerzo y crear
confusión. Si se sugiere una división del trabajo, es útil para proporcionar información a cada participante sobre lo
que se está logrando en otros esfuerzos. Esto no sólo reducirá la duplicación de esfuerzos, pero permitir a las
personas que trabajan en partes del problema para saber dónde obtener información relevante para su parte del
incidente.
Otra consideración importante cuando se comunica sobre el incidente es ser hechos. El intento de ocultar los
aspectos del incidente, proporcionando información falsa o incompleta puede no sólo prevenir una solución
satisfactoria al incidente, pero incluso puede empeorar la situación.
La elección del lenguaje utilizado al notificar a las personas sobre el incidente puede tener un profundo efecto en la
forma en que se recibe la información. Cuando se utiliza términos emocionales o inflamatorias, se eleva el potencial
de daño y negativos resultados del incidente. Es importante mantener la calma tanto en las comunicaciones escritas
y habladas.
Otra consideración es que no todas las personas hablan el mismo idioma. Debido a este hecho, los malos
entendidos y demoras pueden surgir, sobre todo si se trata de un incidente multinacional. Otras preocupaciones
internacionales incluyen diferentes implicaciones legales de un incidente de seguridad y las diferencias culturales.
Sin embargo, no sólo existen diferencias culturales entre los países. Incluso existen dentro de los países, entre los
diferentes grupos sociales o de usuario. Por ejemplo, un administrador de un sistema universitario podría ser muy
relajado sobre los intentos de conectarse al sistema a través de telnet, pero el administrador de un sistema militar es
probable que consideren la misma acción que un posible ataque.

Otro problema asociado con la elección del idioma es la notificación del personal no técnico o fuera de las
instalaciones. Es importante describir con precisión el incidente sin generar alarma o confusión indebida. Si bien es
más difícil de describir el incidente a una audiencia no técnica, a menudo es más importante. Una descripción no
técnica puede ser necesaria para la gestión de nivel superior, la prensa, o enlaces encargados de hacer cumplir la
ley. La importancia de estas comunicaciones no puede ser subestimada y puede hacer la diferencia entre la
resolución del incidente de manera adecuada y escalada a un nivel más alto de daños.
Si un equipo de respuesta a incidentes se ve envuelto, podría ser necesario rellenar una plantilla para el intercambio
de información. Aunque esto puede parecer una carga adicional y añade un cierto retraso, que ayuda al equipo para
actuar en este conjunto mínimo de información. El equipo de respuesta puede ser capaz de responder a los
aspectos del incidente de los cuales el administrador local no es consciente. Si la información se da a otra persona,
la siguiente información mínima debe proporcionar:
(1) zona horaria de troncos, ... en GMT u hora local

(2) información sobre el sistema remoto, incluyendo los nombres de host,
direcciones IP y (tal vez) ID de usuario (3) todas las entradas del registro relevante para el
sitio remoto (4) tipo de incidente (lo que pasó, por qué te importa)
Si la información local (es decir, ID de usuario local) está incluido en las entradas del registro, será necesario
desinfectar las entradas de antemano para evitar problemas de privacidad. En general, toda la información que
podría ayudar a un sitio remoto en la resolución de un incidente de darse por, a menos que las políticas locales
prohíben esto.
5.4.2 protección de pruebas y registros de actividad
Al responder a un incidente, documentar todos los detalles relacionados con el incidente. Esto proporcionará
información valiosa a sí mismo ya otros a medida que tratan de desentrañar el curso de los acontecimientos. La
documentación de todos los detalles en última instancia, ahorrar tiempo. Si no documenta cada llamada de teléfono
correspondiente, por ejemplo, es probable que se olvide de una parte significativa de la información que obtenga, lo
que requiere ponerse en contacto con la fuente de información de nuevo. Al mismo tiempo, detalles de la grabación
proporcionarán evidencia de esfuerzos de procesamiento, proporcionando los casos se mueve en esa dirección. La
documentación de un incidente también le ayudará a realizar una evaluación final de los daños (algo que su gestión,
así como agentes de la ley, van a querer saber), y servirá de base para las fases posteriores del proceso de
manipulación: la erradicación, recuperación y seguimiento -hasta "lecciones aprendidas".

Durante las etapas iniciales de un incidente, a menudo no es factible para determinar si el enjuiciamiento es viable,
por lo que debe documentar como si están reuniendo pruebas para un caso judicial. Como mínimo, se debe
registrar:
(1) todos los eventos del sistema (registros de auditoría) (2) todas
las acciones que toma (tiempo marcado)
(3) todas las conversaciones externas (incluyendo la persona con quien
que habló, la fecha y la hora, y el contenido de la conversación)
La forma más sencilla de mantener la documentación es mantener un libro de registro. Esto le permite ir a una fuente
centralizada, cronológico de la información cuando lo necesite, en lugar de exigir que a la página a través de las
hojas individuales de papel. Mucha de esta información es posible prueba en un tribunal de justicia. Por lo tanto,
cuando un seguimiento jurídico es una posibilidad, se deben seguir los procedimientos preparados y evitar poner en
peligro el seguimiento legal por el manejo inadecuado de las posibles pruebas. Si es apropiado, los pasos siguientes
pueden ser tomadas.
(1) regularmente (por ejemplo, todos los días) gire en fotocopiado, firmado
copias de su libro de registro (así como los medios que utiliza para los eventos del sistema de
registro) a un custodio documento.
(2) El depositario debe almacenar estas páginas copiadas en un lugar seguro
lugar (por ejemplo, una caja fuerte).
(3) Cuando se envía información para el almacenamiento, usted debe
recibir una firma, recibo con la fecha de la custodia de documentos.
El incumplimiento de estos procedimientos puede resultar en la invalidación de cualquier evidencia que obtenga en
un tribunal de justicia.
5.4.3 Contención
El propósito de contención es la de limitar el alcance de un ataque. Una parte esencial de contención es la toma
de decisiones (por ejemplo, determinar si para cerrar un sistema abajo, desconectarse de una red, sistema de
monitorización o actividad de la red, poner trampas, desactivar funciones tales como transferencia de archivos a
distancia, etc.).
A veces, esta decisión es trivial; apagar el sistema si la información es clasificada, sensible, o de propiedad.
Tenga en cuenta que la eliminación de todos los accesos, mientras que un incidente está en curso, obviamente,
notifica a todos los usuarios, incluyendo los usuarios con problemas alegados, que los administradores son
conscientes de un problema; Esto puede tener un nocivo

efecto en una investigación. En algunos casos, es prudente para eliminar todos los accesos o funcionalidad tan
pronto como sea posible, a continuación, restablecer el funcionamiento normal en etapas limitadas. En otros casos,
vale la pena correr el riesgo de algún daño al sistema si mantener el sistema que podría permitir identificar un
intruso.
Esta etapa debe implicar la realización de procedimientos predeterminados. Su organización o sitio deben, por
ejemplo, definir los riesgos aceptables en el tratamiento de un incidente, y deben prescribir acciones y estrategias
específicas en consecuencia. Esto es especialmente importante cuando es necesaria una decisión rápida y no es
posible que el primer contacto todas las partes involucradas para discutir la decisión. En ausencia de procedimientos
predefinidos, la persona a cargo del incidente, a menudo no tienen el poder de tomar decisiones de manejo difíciles
(como perder los resultados de un experimento costoso por el cierre de un sistema). Una actividad final que debe
ocurrir durante esta etapa de manejo de incidentes es la notificación a las autoridades apropiadas.
5.4.4 Erradicación
Una vez que el incidente ha sido contenida, es hora de erradicar la causa. Pero antes de que la erradicación de la
causa, el gran cuidado se debe tomar para recopilar toda la información necesaria sobre el sistema comprometido
(s) y la causa del incidente ya que probablemente se perderán cuando la limpieza del sistema.
El software puede estar disponible para ayudarle en el proceso de erradicación, como el software antivirus. Si se han
creado los archivos falsos, ellos archivar antes de eliminarlos. En el caso de las infecciones de virus, es importante
limpiar y volver a formatear cualquier medio que contenga los archivos infectados. Por último, asegúrese de que
todas las copias de seguridad están limpios. Muchos sistemas infectados con virus se vuelven periódicamente
re-infectarse simplemente porque la gente no erradican el virus sistemática de las copias de seguridad. Después de
la erradicación, una nueva copia de seguridad debe ser tomada.
La eliminación de todas las vulnerabilidades vez un incidente que ha ocurrido es difícil. La clave para la
eliminación de vulnerabilidades es el conocimiento y la comprensión de la brecha.
Puede que sea necesario volver a los medios de distribución originales y volver a personalizar el sistema. Para
facilitar este peor de los casos, un registro de la configuración del sistema original y cada cambio de personalización
deben mantenerse. En el caso de un ataque basado en la red, es importante instalar parches para cada
vulnerabilidad del sistema operativo que fue explotada.

Como se discutió en la sección 5.4.2, un registro de seguridad puede ser más valioso durante esta fase de
eliminación de vulnerabilidades. Los registros que muestra cómo se descubrió el incidente y contenía pueden ser
utilizados posteriormente para ayudar a determinar qué tan extensa el daño era de un suceso determinado. Las
medidas adoptadas se pueden utilizar en el futuro para asegurarse de que el problema no se resurgir. Idealmente,
se debe automatizar y aplicar regularmente la misma prueba que se utilizó para detectar el incidente de seguridad.
Si una vulnerabilidad particular, se aísla como habiendo sido explotada, el siguiente paso es encontrar un
mecanismo para proteger su sistema. Las listas de correo y boletines de seguridad sería un lugar bueno para
buscar esta información, y se puede obtener el asesoramiento de los equipos de respuesta a incidentes.
5.4.5 recuperación
Una vez que la causa de un incidente ha sido erradicada, la fase de recuperación define la siguiente etapa de la
acción. El objetivo de la recuperación es que el sistema vuelva a la normalidad. En general, la crianza de los
servicios en el orden de la demanda para permitir un mínimo de inconvenientes usuario es la mejor práctica.
Entienden que los procedimientos de recuperación adecuados para el sistema son muy importantes y deben ser
específicas para el sitio.
5.4.6 Seguimiento
Cuando usted cree que un sistema ha sido restaurado a un estado "seguro", todavía es posible que los agujeros y
trampas incluso, podrían estar al acecho en el sistema. Una de las más importantes etapas de responder a los
incidentes es también el, la etapa de seguimiento más a menudo se omite. En la fase de seguimiento, el sistema
debe ser monitoreado para los artículos que se podían haber omitido durante la etapa de limpieza. Sería prudente
utilizar algunas de las herramientas mencionadas en el capítulo 7 como punto de partida. Recuerde, estas
herramientas no reemplazan la supervisión continua del sistema y las buenas prácticas de administración de
sistemas.
El elemento más importante de la etapa de seguimiento se está realizando un análisis post mortem. Exactamente lo
que pasó, y en qué momento? ¿Qué tan bien el personal involucrado en el incidente de realizar? ¿Qué tipo de
información hizo la necesidad de personal rápidamente, y cómo podrían haber conseguido esa información tan
pronto como sea posible? ¿Cuáles serían las del personal diferente la próxima vez?
Después de un incidente, es prudente para escribir un informe que describe la secuencia exacta de acontecimientos:
el método de descubrimiento, procedimiento de corrección, procedimiento de control, y un resumen de las lecciones
aprendidas. Esto ayudará en la comprensión clara del problema. La creación de una cronología de los
acontecimientos formales (incluyendo las marcas de tiempo) también es importante por razones legales.

Un informe de seguimiento es valioso por muchas razones. Se proporciona una referencia para ser utilizado en caso
de otros incidentes similares. También es importante, lo más rápidamente posible obtener una estimación monetaria
de la cantidad de daño causado el incidente. Esta estimación debe incluir los costos asociados con la pérdida de
software y archivos (especialmente el valor de los datos de propiedad que pueden haber sido revelada), daños en el
hardware, y los costos de mano de obra para restaurar archivos alterados, sistemas reconfigure afectada, y así
sucesivamente. Esta estimación puede convertirse en la base para la actividad posterior procesamiento. El informe
también puede ayudar a justificar el esfuerzo de seguridad informática de una organización de gestión.
5.5 Consecuencias de un incidente
A raíz de un incidente, varias acciones deben llevarse a cabo. Estas acciones se pueden resumir de la siguiente
manera:
(1) Un inventario debe tomarse de los activos de los sistemas,

(Es decir, un examen cuidadoso debe determinar cómo el sistema se vio afectada por el
incidente).
(2) Las lecciones aprendidas como resultado del incidente

deben incluirse en el plan de seguridad revisado para evitar que el incidente
se vuelvan a presentar.
(3) Un nuevo análisis de riesgos se debe desarrollar a la luz de la

incidente.
(4) Una investigación y el enjuiciamiento de los individuos

que causó el incidente debe comenzar, si se considera conveniente.
Si un incidente se basa en una mala política, y menos que se cambie la política, entonces uno está condenado a
repetir el pasado. Una vez que un sitio se ha recuperado de e incidentes, política y procedimientos de sitio deben ser
revisados a los cambios Encompass para evitar incidentes similares. Incluso sin un incidente, sería prudente revisar
las políticas y procedimientos sobre una base regular. Los comentarios se deben imprescindible para entornos
informáticos cambian de hoy.
El propósito de este proceso post mortem es mejorar todas las medidas de seguridad para proteger el sitio contra
ataques futuros. Como resultado de un incidente, un sitio u organización deben adquirir conocimientos prácticos de
la experiencia. Un objetivo concreto de la autopsia es desarrollar nuevos métodos proactivos. Otra faceta importante
de las consecuencias puede ser la educación del usuario y administrador fin de impedir que se repita el problema de
seguridad.

5.6 Responsabilidades
5.6.1 No cruzar la línea
Es una cosa a la red propia de una protección, pero otra muy diferente es asumir que hay que proteger a otras
redes. Durante el manejo de un incidente, ciertas vulnerabilidades del sistema de los sistemas propios de uno y los
sistemas de otros se hacen evidentes. Es bastante fácil y puede incluso ser tentador para perseguir a los intrusos
con el fin de realizar un seguimiento de ellos. Tenga en cuenta que en un momento determinado es posible "cruzar
la línea", y, con la mejor de las intenciones, no es mejor que el intruso se convierta.
La mejor regla cuando se trata de la corrección es no utilizar cualquier instalación de sitios remotos que no es
pública. Esto claramente excluye cualquier entrada en un sistema (tales como un shell remoto o sesión de login) que
no está permitido expresamente. Esto puede ser muy tentador; después de que se detecte una infracción de
seguridad, un administrador del sistema puede tener los medios para "seguir arriba", para determinar qué tipo de
daño que se está haciendo en el sitio remoto. No lo haga! En su lugar, tratar de alcanzar el punto de contacto para el
sitio afectado apropiado.
5.6.2 Buena internet Ciudadanía
Durante un incidente de seguridad hay dos opciones que uno puede hacer. En primer lugar, un sitio puede optar por
ver al intruso con la esperanza de la captura de él; o, el sitio puede ir sobre la limpieza después del incidente y cerrar
el intruso fuera de los sistemas. Esta es una decisión que debe hacerse muy cuidadosamente, ya que puede haber
responsabilidades legales si decide salir de su sitio abierto, sabiendo que un intruso está utilizando su sitio como una
plataforma de lanzamiento para llegar a otros sitios. Al ser un buen medio de ciudadanos de Internet que usted debe
tratar para alertar a otros sitios que pueden haber sido afectados por el intruso. Estos sitios afectados pueden ser
fácilmente evidentes después de una revisión exhaustiva de los archivos de registro.
5.6.3 Respuesta Administrativa a incidentes
Cuando un incidente de seguridad implica un usuario, política de seguridad del sitio debe describir lo que se va a
tomar acción. La transgresión debe ser tomado en serio, pero es muy importante estar seguro del papel que juega el
usuario. Era ingenuo al usuario? ¿Puede haber un error en la atribución de la brecha de seguridad para el usuario?
La aplicación de las medidas administrativas que asume el usuario causado intencionadamente el incidente puede

no ser apropiado para un usuario que simplemente cometió un error. Puede ser conveniente incluir sanciones más
adecuadas para tal situación una de sus políticas (por ejemplo, la educación o amonestación de un usuario) además
de las medidas más severas para los actos intencionales de la intrusión y el mal uso del sistema.
6. Las actividades en curso
En este punto en el tiempo, su sitio se ha desarrollado es de esperar una política de seguridad completa y ha
desarrollado procedimientos para ayudar en la configuración y la gestión de la tecnología en apoyo de esas
políticas. Lo agradable que sería si usted podría sentarse y relajarse en este momento y saber que habían
terminado con el trabajo de seguridad. Por desgracia, eso no es posible. Sus sistemas y redes no son un entorno
estático, por lo que tendrá a las políticas y procedimientos de revisión sobre una base regular. Hay una serie de
medidas que puede tomar para ayudar a mantenerse al día con los cambios que le rodean, para que pueda iniciar
las acciones correspondientes para hacer frente a esos cambios. El siguiente es un conjunto de arranque y se
puede añadir otros según sea apropiado para su sitio.
(1) Suscribirse a los avisos emitidos por diversos incidentes de seguridad

Los equipos de respuesta, al igual que las del Centro de Coordinación CERT, y actualizar sus sistemas frente a
aquellas que se aplican a la tecnología de su sitio.
(2) los parches de seguridad del monitor que se producen por los proveedores de su
equipo y obtener e instalar todo lo que corresponda.
(3) vigilar activamente las configuraciones de sus sistemas para identificar cualquier
los cambios que se hayan producido, e investigar todas las anomalías.
(4) Revisar todas las políticas y procedimientos de seguridad al año (como mínimo).
(5) Leer las listas de correo y grupos de noticias relevantes para mantener hasta
actualizado con la información más reciente siendo compartida por sus compañeros
administradores.
(6) Compruebe regularmente el cumplimiento de políticas y procedimientos. Esta

auditoría debe ser realizada por alguien que no sea las personas que se definen o implementan las
políticas y procedimientos.
7. Herramientas y ubicaciones
En este capítulo se ofrece una lista breve de tecnología de seguridad a disposición del público que se puede
descargar desde Internet. Muchos de los elementos que se describen a continuación, sin duda, va a ser superado
o obsoleta antes de la publicación de este documento.

Algunas de las herramientas mencionadas son aplicaciones tales como programas de usuario final (clientes) y su
infraestructura del sistema de soporte (servidores). Otros son herramientas que un usuario general nunca verá o
necesidad de su uso, pero puede ser utilizado por aplicaciones o por los administradores a los problemas de
seguridad solucionar problemas o para protegerse contra los intrusos.
Una triste realidad es que hay aplicaciones muy pocos conscientes de seguridad disponibles en la actualidad.
Principalmente, esto se debe a la necesidad de una infraestructura de seguridad que primero hay que poner en su
lugar para la mayoría de aplicaciones para operar de forma segura. Existe un considerable esfuerzo, teniendo lugar
para construir esta infraestructura para que las aplicaciones pueden tomar ventaja de las comunicaciones seguras
actualmente.
La mayoría de las herramientas y aplicaciones que se describen a continuación se pueden encontrar en uno de los
siguientes sitios de archivos:
(1) Centro de Coordinación CERT

ftp://info.cert.org:/pub/tools (2) DFN-CERT
ftp://ftp.cert.dfn.de/pub/tools/
(3) Operaciones de la computadora, de auditoría y herramientas de seguridad (costa)
coast.cs.purdue.edu:/pub/tools
Es importante tener en cuenta que muchos sitios, entre ellos CERT y la costa se reflejan a través de Internet. Tenga
cuidado al usar un "conocido" sitio espejo para recuperar el software y utilizar herramientas de verificación (sumas
de verificación MD5, etc.) para validar que el software. Una galleta inteligente podría anunciar software de seguridad
que intencionadamente se ha diseñado para proporcionar acceso a datos o sistemas.
Herramientas
COPS
DES
Puente levadizo
identd (no es realmente una herramienta de seguridad) ISS
Kerberos
logdaemon lsof
MD5 PEM PGP
rpcbind / reemplazo portmapper SATAN sfingerd S

/ KEY smrsh

muestra de
ssh-TCP Wrapper
tigre Tripwire *
TROJAN.PL
8. Listas de correo y otros recursos
Sería imposible enumerar todas las listas de correo-y otros recursos relacionados con la seguridad del sitio. Sin
embargo, estos son algunos "jumppoints" a partir del cual puede comenzar el lector. Todas estas referencias son
para la circunscripción de "Internet". Más específico (vendedor y geográficas) los recursos se pueden encontrar a
través de estas referencias.
Listas de correo
(1) CERT (TM) Asesor

Envíe un correo a: cert-advisory-request@cert.org Cuerpo del mensaje: subscribe cert
<nombre> <apellido>
Un aviso CERT ofrece información sobre cómo obtener un parche o detalles de una solución para un
problema de seguridad informática conocida. El Centro de Coordinación CERT trabaja con los proveedores
para producir una solución o un parche para un problema, y no publica información sobre las
vulnerabilidades hasta que una solución o un parche está disponible. Un aviso CERT también puede ser una
advertencia para nuestra circunscripción sobre los ataques en curso (por ejemplo, "CA-91:
18.Active.Internet.tftp.Attacks").
avisos del CERT también se publican en el grupo de noticias de Usenet:

comp.security.announce
archivos de asesoramiento CERT están disponibles a través de FTP anónimo de info.cert.org en el

directorio / pub / cert_advisories.
(2) VIRUS-L Lista

Envíe un correo a: lista de distribución% lehiibm1.bitnet@mitvma.mit.edu Cuerpo del
mensaje: subscribe virus-L NOMBRE APELLIDO
VIRUS-L es una lista de correo moderada con especial atención a los problemas
de virus informáticos. Para obtener más información, incluyendo una copia de las
directrices de publicación, consulte el archivo "virus-l.README", disponible por
FTP anónimo de cs.ucr.edu.

(3) Los cortafuegos de Internet

Enviar correo a: majordomo@greatcircle.com Cuerpo del mensaje:
subscribe cortafuegos usuario @ host
La lista de correo cortafuegos es un foro de discusión para los administradores de

cortafuegos y ejecutores.
grupos de noticias Usenet
(1) comp.security.announce
El grupo de noticias comp.security.announce es moderado y se utiliza
exclusivamente para la distribución de los avisos del CERT.
(2) comp.security.misc
El comp.security.misc es un foro para la discusión de la seguridad informática,
especialmente en lo que se refiere al UNIX (R) del sistema operativo.
(3) alt.security
El grupo de noticias alt.security es también un foro para la discusión de la seguridad
informática, así como otras cuestiones tales como cerraduras de automóviles y
sistemas de alarma.
(4) comp.virus
El grupo de noticias comp.virus es un grupo de noticias moderado con un enfoque
en cuestiones de virus informáticos. Para obtener más información, incluyendo una
copia de las directrices de publicación, consulte el archivo "virus-l.README",
disponible vía FTP anónimo en info.cert.org en el directorio / pub / l de virus.
(5) comp.risks
El grupo de noticias comp.risks es un foro moderado sobre los riesgos para el
público en ordenadores y sistemas relacionados.
World-Wide Web Pages
(1) http://www.first.org/
Centro de recursos de seguridad de la computadora. La atención se centra en la información de respuesta a

crisis; información sobre las amenazas informáticas relacionadas con la seguridad, vulnerabilidades y
soluciones. Al mismo tiempo, el Centro se esfuerza por ser un índice general de información de la seguridad
informática en una amplia variedad de temas, incluyendo los riesgos generales, la privacidad, temas legales,
los virus, la garantía, la política y la formación.

(2) http://www.telstra.com.au/info/security.html
Este índice de referencia contiene una lista de enlaces a fuentes de información en la red y la seguridad
informática. No hay ninguna aptitud implícita a las herramientas, técnicas y documentos contenidos en este
archivo. Muchos, si no todos estos elementos funcionan bien, pero no garantizamos que esto va a ser así. Esta
información es para la educación y el uso legítimo de sólo técnicas de seguridad informática.
(3) http://www.alw.nih.gov/Security/security.html
Esta página ofrece información general acerca de la seguridad informática. La información está organizada
por la fuente y cada sección está organizada por temas. Recientes modificaciones se indican en la página
de Nuevo Lo.
(4) http://csrc.ncsl.nist.gov
Este archivo en el Instituto Nacional de Estándares y la página Centro de Información de Recursos de Seguridad
Informática de Tecnología contiene una serie de anuncios, programas y documentos relacionados con la seguridad
informática.
* CERT y Tripwire están registrados en la Oficina de Patentes y Marcas de EE.UU.
9. Referencias
Las siguientes referencias pueden no estar disponibles en todos los países.
[Appelman, et. al., 1995] Appelman, Heller, Ehrman, Blanco, y McAuliffe, "La Ley y el Internet", USENIX 1995
Conferencia Técnica sobre UNIX y Computación Avanzada, Nueva Orleans, LA, 16-20 de enero de 1995.
[ABA, 1989] Asociación Americana de bar, Sección de Ciencia y Tecnología, "Guía para el enjuiciamiento de
Fraude de las Telecomunicaciones por el uso de la computadora del crimen Estatutos", American Bar Asociación,
1989.
[Aucoin, 1989] R. Aucoin, "Los virus informáticos: Lista de verificación para la recuperación", computadoras en las
bibliotecas, vol. 9, No. 2, pág. 4, febrero de 1989.
[Barrett, 1996] D. Barrett, "Bandidos en la autopista de la información", O'Reilly & Associates,

Sebastopol, CA, 1996.
[Bates, 1992] R. Bates, "Desastres planeamiento de la recuperación: Redes, Telecomunicaciones y

Comunicaciones de Datos", McGraw-Hill, 1992.
[Bellovin, 1989] S. Bellovin, "Problemas de seguridad en el directorio / IP Conjunto de protocolos TCP", Computadora
Revisión Comunicación, Vol 19, 2, pp. 32-48, abril de 1989.

[Bellovin, 1990] S. Bellovin y M. Merritt, "Limitaciones del sistema de autenticación Kerberos", Revista de
Comunicaciones del ordenador, octubre de 1990.
[Bellovin, 1992] S. Bellovin, "There Be Dragón", USENIX: Actas del Tercer Simposio de Seguridad Usenix,
Baltimore, MD. Septiembre,
1992.
[Bender, 1894] D. Bender, "Derecho Informático: Procedimiento y Prueba", M. Bender, Nueva York, Nueva York,
1978-presente.
[Bloombecker, 1990] B. Bloombecker, "Ordenador crímenes espectacular", Dow Jones-Irwin, Homewood, IL.
1990.
[Marca, 1990] R. Brand, "Hacer frente a la amenaza de los incidentes de seguridad informática: Una Guía de
Prevención a través de la recuperación", R. Marca 8 de junio de 1990.
[Brock, 1989] J. Brock, "Noviembre de 1988 del virus del Internet del ordenador y de la vulnerabilidad de las redes
nacionales de telecomunicaciones a los virus informáticos", GAO / T-IMTEC-89-10, Washington, DC, 20 de Julio de
1989.
[BS 7799] norma británica BS Tech Cttee BSFD / 12, Info. Segundo. MGMT, "BS 7799: 1995 Código de prácticas
para la Gestión de Seguridad", British Standards Institution, Londres, 54, partir del 15 de febrero de 1995.
[Caelli, 1988] W. Caelli, Editor, "Seguridad informática en la era de la información", Actas de la Quinta Conferencia
Internacional sobre la IFIP seguridad informática, IFIP / Sec '88.
[Carroll, 1987] J. Carroll, "Seguridad Informática", 2ª edición, Butterworth Publishers, Stoneham, MA,
1987.
[Cavazos y Morin, 1995] E. Cavazos y G. Morin, "Cyber-Espacio y La Ley", MIT Press, Cambridge, MA, 1995.
[CCH, 1989] Comercio de Intercambio de Información, "Guía de las normas del equipo", (Law Reports
tópicos), Chicago, IL., 1989.
[Chapman, 1992] B. Chapman, "Red (In) Seguridad a través de filtrado de paquetes IP", USENIX: Actas del Tercer
Simposio de Seguridad de UNIX, Baltimore, MD, septiembre de 1992.
[Chapman y Zwicky, 1995] B. Chapman y E. Zwicky, "Building Internet Firewalls", O'Reilly y Asociados,
Sebastopol, CA, 1995.

[Cheswick, 1990] B. Cheswick, "El diseño de un Secure Internet Gateway", Actas de la Conferencia Usenix
verano, Anaheim, CA, junio de 1990.
[Cheswick1] W. Cheswick, "Una tarde con Berferd en el que un Cracker es atraído, soportar, y estudiado", AT & T
Bell Laboratories.
[Cheswick y Bellovin, 1994] W. Cheswick y S. Bellovin, "Cortafuegos y Seguridad de Internet: Rechazo de la Hacker
Wily", Addison-Wesley, Reading, MA, 1994.
[Conly, 1989] C. Conly, "Organizador de Informática de Investigación Criminal y la Fiscalía", Departamento de

Justicia, Oficina de Programas de Justicia, bajo contrato Número OJP-86-C-002, Instituto Nacional de Justicia,
Washington, DC, de julio de de 1989.
[Cooper, 1989] J. Cooper, "Equipo de Seguridad y Comunicaciones: Estrategias para la década de 1990",
McGraw-Hill, 1989.
[CPSR, 1989] informáticos para la responsabilidad social, "Declaración de CPSR en el virus informático", CPSR,
Communications of the ACM, vol. 32, No. 6, Pg. 699, junio de 1989.
[CSC-STD-002-85, 1985] Departamento de Defensa, "Gestión de contraseñas directriz", CSC-STD-002-85 12

de abril de 1985, 31 páginas.
[Curry, 1990] D. Curry, "Mejora de la seguridad de su sistema UNIX", Informe SRI International ITSTD-721-FR-90-21,
abril de 1990.
[Curry, 1992] D. Curry, "UNIX Sistema de seguridad: Una guía para los usuarios y los administradores de
sistemas", Addision-Wesley, Reading, MA, 1992.
[DDN88] Red de Datos de Defensa, "BSD 4.2 y 4.3 del software de Resolución de Problemas", DDN MGT Boletín #
43, DDN Network Information Center 3 de noviembre de 1988.
Sistema de Comunicaciones [DDN89] DCA DDN Defensa "DDN boletín de seguridad de 03", Centro de Coordinación
de Seguridad DDN, 17 de octubre de 1989.
[Denning, 1990] P. Denning, Editor, "Equipos bajo ataque: Intrusos, gusanos y virus", ACM Press,
1990.
[Eichin y Rochlis, 1989] M. Eichin, y J. Rochlis "con el microscopio y Pinzas: Análisis del Virus Internet noviembre de
1 988", Instituto de Tecnología de febrero de 1989 Massachusetts.

[Eisenberg, et. al., 89] T. Eisenberg, D. Gries, J. Hartmanis, D. Holcomb, M. Lynn, y T. Santoro, "The Worm
Computer", Universidad de Cornell, 6 febrero de 1989.
[Ermann, Willians, y Gutiérrez, 1990] D. Ermann, M. Williams, y

C. Gutiérrez, Editores, "Informática, Ética y Sociedad", Oxford University Press, Nueva York, 1990. (376
páginas, incluye referencias bibliográficas).
[Farmer y Spafford, 1990] D. Farmer y E. Spafford, "El sistema ortográfico COPS Seguridad", Actas de la
Conferencia de Verano 1990 USENIX, Anaheim, CA, Págs. 165-170, junio de 1990.
[Farrow, 1991] Rik Farrow, "UNIX Sistemas de Seguridad", Addison-Wesley, Reading, MA, 1991.
[Fenwick, 1985] W. Fenwick, Presidente, "Litigios Computer, 1985: tácticas y técnicas de prueba", litigios Curso
Manual Series No. 280, preparado para su distribución en el Litigio Computer, 1985: Tácticas de ensayos y
técnicas Programa, febrero-marzo 1985.
[Fites 1989] M. Fites, P. Kratz, y A. Brebner, "Control y Seguridad de Sistemas Informáticos", Computer Science
Press,
1989.
[Fites, Johnson y Kratz, 1992] Fites, Johnson y Kratz, "El virus informático crisis", Van Hostrand Reinhold, 2ª
edición, 1992.
[Forester y Morrison, 1990] T. Forester, y P. Morrison, "ética de la computación: Cuentos y dilemas éticos en
Informática", MIT Press, Cambridge, MA, 1990.
[Foster y Morrision, 1990] T. Forester, y P. Morrison, "ética de la computación: Cuentos y dilemas éticos en
Informática", MIT Press, Cambridge, MA, 1990. (. 192 páginas incluyendo índice)
[GAO / IMTEX-89-57, 1989] US General Accounting Office, "Computer Security - Lo más destacado de virus
necesidad de mejorar la gestión de Internet", la Oficina de Contabilidad General de Estados Unidos, Washington,
DC, 1989.
[Garfinkel y Spafford, 1991] S. Garfinkel, y E. Spafford, "Práctica de Seguridad de Unix", O'Reilly & Associates, ISBN
0-937175-72-2, mayo de 1991.
[Garfinkel, 1995] S. Garfinkel, "PGP: Pretty Good Privacy", O'Reilly & Associates, Sebastopol, CA, 1996.

[Garfinkel y Spafford, 1996] S. Garfinkel y Spafford E., "UNIX Práctico y Seguridad de Internet", O'Reilly
& Associates, Sebastopol, CA, 1996.
[Gemignani, 1989] M. Gemignani, "Ley de virus y Criminal", Comunicaciones de la ACM, Vol. 32, No. 6, págs.
669-671, junio de 1989.
[Goodell, 1996] J. Goodell, "El Cyberthief y los Samurai: La verdadera historia de Kevin Mitnick, y el hombre que él
abajo de Hunted", Dell Publishing, 1996.
[Gould, 1989] C. Gould, Editor, "La Información en la Web: implicaciones éticas y sociales de Redes", Westview
Press, Boulder, CO, 1989.
[Greenia, 1989] M. Greenia, "Información de Referencia Seguridad Informática", Lexikon

Servicios, Sacramento, CA, 1989.
[Hafner y Markoff, 1991] K. Hafner y J. Markoff, "Cyberpunk: Outlaws y piratas informáticos en la frontera
Computer", Touchstone, Simon & Schuster, 1991.
[Hess, Safford, y Pooch] D. Hess, D. Safford, y U. chucho, "Una red Unix Estudio de Seguridad del protocolo:
Servicio de Información de Red", de Texas A & M University.
[Hoffman, 1990] L. Hoffman, "programas maliciosos: virus, gusanos y caballos de Troya", Van Nostrand
Reinhold, Nueva York, 1990. (384 páginas, incluye referencias bibliográficas e índice).
[Howard, 1995] Howard G., "Introducción a la seguridad en Internet: de lo esencial a allá", Prima Publishing,
Rocklin, CA, 1995.
[Huband y Shelton, 1986] F. Huband, y R. Shelton, Editores, "Protección de los sistemas informáticos y software:
nuevos enfoques para combatir el robo de software y no autorizada de intrusos", los trabajos presentados en un
taller patrocinado por la Fundación Nacional de Ciencia,
1986.
[Hughes, 1995] L. Hughes Jr., "En realidad Consejos prácticos de seguridad en Internet", New Riders
Publishing, Indianapolis, IN, 1995.
[IAB-RFC1087, 1989] Junta de Actividades de Internet, "Ética e Internet", RFC 1087, IAB, de enero de
1989. También aparece en las Comunicaciones de la ACM, vol. 32, No. 6, Pg. 710, junio de 1989.

[Icove, Seger, y VonStorch, 1995] D. Icove, K. Seger, y W. VonStorch, "Computer Crime: Manual para
Crimefighter", O'Reilly & Associates, Sebastopol, CA, 1995.
[1996] IVPC, IVPC, "Conferencia Internacional de Prevención de Virus '96 Proceedings", NCSA, 1996.
[Johnson y Podesta] D. Johnson y J. Podestá, "la formulación de una política de la compañía sobre el acceso y uso y
divulgación de correo electrónico de la compañía Computer Systems".
[Kane, 1994] P. Kane, "seguridad de la PC y el Manual de Protección contra Virus: El curso de sabotaje contra la
Guerra de la Información", M & T Books, 1994.
[Kaufman, Perlman, y Speciner, 1995] C. Kaufman, R. Perlman, y M. Speciner, "Seguridad de red: PRIVADO
comunicación en un mundo público", Prentice Hall, Englewood Cliffs, NJ, 1995.
[Kent, 1990] S. Kent, "Privacidad de correo electrónico para Internet: nuevo software y procedimientos de registro
estrictos se llevarán a cabo este año", Business Communications Review, vol. 20, No. 1, pág. 55, 1º de enero
1990.
[Levy, 1984] S. Levy, "Hacker: Héroes de la revolución de la computadora", Delta, 1984.
[Lewis, 1996] S. Lewis, "Disaster Recovery Páginas Amarillas", la auditoría del grupo de Sistemas, 1996.
[Littleman, 1996] J. Littleman, "El fugitivo de juego: con Kevin Mitnick", Little, Brown, Boston, MA., 1996.
[Lu y Sundareshan, 1989] W. Lu y M. Sundareshan, "Comunicación segura en entornos de Internet: Esquema de

administración de claves Un jerárquica de extremo a extremo de cifrado", IEEE Transactions on Communications,
vol. 37, No. 10, Pg. 1014, 1 de octubre de 1989.
[Lu y Sundareshan, 1990] W. Lu y M. Sundareshan, "Un modelo para varios niveles de seguridad en las redes
informáticas", IEEE Transactions on Software Engineering, vol. 16, N ° 6, página 647, 1 de junio de 1990.
[Martin y Schinzinger, 1989] M. Martin, y R. Schinzinger, "Ética en la Ingeniería", McGraw Hill, 2ª edición, 1989.
[Merkle] R. Merkle, "A Fast Software Función Hash One Way", Revista de la criptología, vol. 3, No. 1.

[McEwen, 1989] J. McEwen, "Dedicado Unidades de Delitos Informáticos", Informe colaboradores: D. Fester y
H. Nugent, preparado para el Instituto Nacional de Justicia, Departamento de Justicia de Estados Unidos, por el
Instituto de Derecho y Justicia, Inc., bajo contrato número OJP-85-C-006, Washington, DC, 1989.
[MIT, 1989] Instituto de Tecnología de Massachusetts, "enseñar a los estudiantes el uso responsable de los
equipos", MIT, 1985-1986. También reimpreso en las Comunicaciones de la ACM, Vol. 32, No. 6, Pg. 704, Proyecto
Athena, MIT, junio de 1989.
[Mogel, 1989] Mogul, J., "Controles simple y flexible de Datagrama de acceso para puertas de enlace
basado en UNIX", Western Investigación Informe de Investigación de Laboratorio Digital 89/4, marzo de
1989.
[Muffett, 1992] A. Muffett, "crack Versión 4.1: Una contraseña Sensible inspector para Unix"
[NCSA1, 1995] NCSA, "Guía de políticas de firewall NCSA", 1995.
[NCSA2, 1995] NCSA, "Organización del virus de ordenador Modelo de Prevención de la Política de NCSA",
NCSA, 1995.
[1996] NCSA, NCSA, "Cortafuegos y Seguridad de Internet de la Conferencia '96 Proceedings", 1996.
[NCSC-89-660-P, 1990] Centro Nacional de Seguridad Informática, "Directrices para Formal sistemas de
verificación", la lista de envío No .: 89-660-P, el Centro, Fort George G. Meade, MD, 1 de abril de 1990.
[NCSC-89-254-P, 1988] Centro Nacional de Seguridad Informática, "Glosario de términos de seguridad informática",
la lista de envío No .: 89-254-P, El Centro, Fort George G. Meade, MD, el 21 de octubre de 1988.
[NCSC-C1-001-89, 1989] Tinto, M., "Los virus informáticos: prevención, detección y tratamiento", Centro de
Informes de Seguridad Nacional de Informática Técnica C1 C1-001-89, junio de 1989.
[Conferencia NCSC, 1989] Conferencia Nacional de Seguridad Informática "12ª Conferencia Nacional de
Seguridad Informática: Baltimore Convention Center, Baltimore, MD, 10-13 de octubre de 1989: Sistemas de
Información de Seguridad, Soluciones para hoy - Conceptos para el Mañana", Instituto Nacional de Estándares y
National Computer Security Center, 1989.
[NCSC-CSC-STD-003-85, 1985] Centro Nacional de Seguridad Informática, "Guía para la Aplicación del
Departamento de Defensa de confianza Criterios de Evaluación Sistema informático en entornos específicos",
CSC-STD-003-85, NCSC, 25 de Junio 1985.

[NCSC-STD-004-85, 1985] Centro Nacional de Seguridad Informática, "Fundamentos técnicos que hay detrás de
CSC-STD-003-85: Requisitos de seguridad informática", CSC-STD-004-85, NCSC, 25 de Junio 1985.
[NCSC-STD-005-85, 1985] National Computer Security Center, "magnético de remanencia de Seguridad Directriz",
CSC-STD-005-85, NCSC 15 de noviembre
1985.
[NCSC-TCSEC, 1985] National Computer Security Center, "Trusted Computer System Evaluation Criteria", DoD
5200.28-STD, CSC-STD-001-
83, NCSC, diciembre de 1985.
[NCSC-TG-003, 1987] NCSC, "Guía para control de acceso discrecional entendimiento en los sistemas de
confianza", NCSC-TG-003, Version-1, 30 septiembre de 1987, 29 páginas.
[NCSC-TG-001, 1988] NCSC, "Guía para AUDITORÍA entendimiento en los sistemas de confianza",
NCSC-TG-001, Versión-2, 1 de Junio 1988, 25 páginas.
[NCSC-TG-004, 1988] Nacional de Seguridad Centro de Cómputo, "Glosario de términos de seguridad

informática", NCSC-TG-004, NCSC 21 de octubre de 1988.
[NCSC-TG-005, 1987] Centro Nacional de Seguridad Informática, "Interpretación de confianza de la red",

NCSC-TG-005, NCSC 31 de julio de 1987.
[NCSC-TG-006, 1988] NCSC, "Una guía para la gestión de la configuración entendimiento en los sistemas de
confianza", NCSC-TG-006, Version-1, 28 de Marzo
1988, 31 páginas.
[NCSC-TRUSIX, 1990] National Computer Security Center, "Trusted grupo de trabajo UNIX (TRUSIX) justificación
de la selección lista de control de acceso a las características del sistema UNIX", enviando la lista no .: 90-076-P,
El Centro, Fort George G . Meade, MD, 1990.
[NRC, 1991] Consejo Superior de Investigaciones Científicas, "Equipos en riesgo: seguridad informática en
la era de la información", National Academy Press, 1991.
[Nemeth, et. al, 1995] E. Nemeth, G. Snyder, S. Seebass, y T. Hein, "Manual de Administración de UNIX Sistemas",
Prentice Hall PTR, Englewood Cliffs, NJ, segunda ed. 1995.
[NIST, 1989] Instituto Nacional de Estándares y Tecnología, "virus informáticos y amenazas relacionadas:
Una guía de gestión", Publicación Especial NIST 500-166, agosto de 1989.
[NSA] Agencia Nacional de Seguridad, "Sistemas de Información de Productos y Servicios de

Seguridad Catálogo", NSA, publicación trimestral.

[NSF, 1988] Fundación Nacional de Ciencias, "NSF Poses Código de Ética de redes", Communications of the
ACM, vol. 32, No. 6, Pg.
688, junio de 1989. También aparece en el acta de la sesión ordinaria del Grupo Asesor de la División de
Investigación Redes y Comunicaciones e Infraestructura, Dave Farber, Silla, Noviembre 29-30,
1988.
[NTISSAM, 1987] NTISS, "memorándum consultivo para la automatización de oficina de Seguridad

Directriz", NTISSAM CompuSec / 1-87, 16 de enero de 1987, 58 páginas.
[OTA-CIT-310, 1987] Congreso de Estados Unidos, Oficina de Evaluación Tecnológica, "Secretos de Defensa,
Compartimiento de datos: Nueva Bloqueos y claves de información electrónica", OTA-CIT-310, octubre de 1987.
[OTA-TCT-606] El Congreso de los Estados Unidos, Oficina de Evaluación Tecnológica, "Seguridad de la

información y privacidad en entornos de red", OTA-TCT-606, septiembre de 1994.
[Palmer y Potter, 1989] I. Palmer, y G. Potter, "Gestión de riesgos de seguridad informática", Van
Nostrand Reinhold, Nueva York, 1989.
[Parker, 1989] D. Parker, "Computer Crime: Recursos de Justicia Penal Manual", Departamento de Justicia, Instituto
Nacional de Justicia, Oficina de Programas de Justicia, bajo contrato Número OJP-86-C-002, Washington,
DC, Agosto de 1989.
[Parker, Swope, y Baker, 1990] D. Parker, S. Swope, y B. Baker, "conflictos éticos: Información y Ciencias de la
Computación, Tecnología y Negocios", Ciencias de la Información QED, Inc., Wellesley, MA. (245 páginas).
[Pfleeger, 1989] C. Pfleeger, "Seguridad en Computing", Prentice-Hall, Englewood Cliffs, NJ, 1989.
[Quaterman, 1990] J. Quaterman, J., "The Matrix: Redes de Ordenadores y Sistemas de conferencia en todo el
mundo", la prensa digital, Bedford, MA,
1990.
[Ranum1, 1992] M. Ranum, "Una Internet Firewall", Actas de la Conferencia Mundial sobre la Gestión de Sistemas y
Seguridad de 1992.
[Ranum2, 1992] M. Ranum, "Una Red Firewall", Centro de Recursos de Digital Equipment Corporation
Washington sistemas abiertos 12 de junio de 1992.
[Ranum, 1993] M. Ranum, "Pensando en servidores de seguridad", 1993.

[Ranum y Avolio, 1994] M. Ranum y F. Avolio, "un juego de herramientas y métodos para Internet Firewalls",
Sistemas de Información apoyas, 1994.
[Reinhardt, 1992] R. Reinhardt, "Una Introducción a la arquitectura de red UNIX Seguridad"
[Reinhardt, 1993] R. Reinhardt, "Una Introducción a la arquitectura de UNIX Red de Seguridad", ARINC
Research Corporation, 18 de Febrero de 1993.
[RFC1135-Reynolds, 1989] La helmintiasis de Internet, RFC 1135, Instituto USC / Ciencias, Marina del Rey, CA,
Diciembre
1989.
[Russell y Gangemi, 1991] D. Russell y G. Gangemi, "Conceptos básicos de seguridad informática" O'Reilly
& Associates, Sebastopol, CA, 1991.
[Schneier 1996] B. Schneier, Applied Cryptography ": Protocolos, algoritmos y código fuente en C", John
Wiley & Sons, Nueva York, segunda edición, 1996.
[Seeley, 1989] D. Seeley, "Un recorrido por el gusano", Actas de la Conferencia USENIX 1989 Winter, Usenix
Asociación, San Diego, CA febrero
1989.
[Shaw, 1986] E. Shaw Jr., "Ley de Fraude y Abuso de 1986", Actas del Congreso (3 junio 1986), Washington,
DC, 3 de junio 1986.
[Shimomura, 1996] T. Shimomura con J. Markoff, "Takedown: la búsqueda y captura de Kevin Mitnick, los más
buscados de Estados Unidos Outlawby ordenador del hombre que lo hizo", Hyperion, 1996.
[Shirey, 1990] R. Shirey, "Arquitectura de Seguridad de Defensa Red de Datos", Computer Communication
Review, vol. 20, No. 2, página
66, 1 de abril de 1990.
[Slatalla y Quittner, 1995] M. Slatalla y J. Quittner, "maestros del engaño: la banda que dominaban ciberespacio",
Harper Collins Publishers, 1995.
[Smith, 1989] M. Smith, "El sentido común de seguridad informática: Tu Guía Práctica de Prevención de la
pérdida accidental y deliberada de datos electrónicos", McGraw-Hill, Nueva York, Nueva York, 1989.
[Smith, 1995] D. Smith, "La formación de una gestión de crisis", sexta edición de incidentes de seguridad informática
seminario de tratamiento, Boston, MA, Julio 25-29, 1995.

[Spafford, 1988] E. Spafford, "El gusano de Internet del programa: Un Análisis", Computer Communication Review,
vol. 19, No. 1, ACM SIGCOM, de enero de 1989. También publicado como Purdue CS Informe Técnico CSD-TR-823
28 de noviembre de 1,988.
[Spafford, 1989] G. Spafford, "Análisis del gusano de Internet", Actas de la Conferencia Europea 1989 Ingeniería
de Software, Warwick Inglaterra, septiembre de 1989. Actas publicado por Springer como: Lecture Notes in
Computer Science # 387. También publicado como Informe Técnico # Purdue CDS-TR-933.
[Spafford, Keaphy, y Ferbrache, 1989] E. Spafford, K. Heaphy, y

D. Ferbrache, "Los virus informáticos: Tratar con electrónica de vandalismo y amenazas programadas de
manera" (. 109 páginas), ADAPSO, 1989.
[Stallings1, 1995] W. Stallings, "Manual de Seguridad de Internet", IDG Books, Foster City CA, 1995.
[Stallings2, 1995] W. Stallings, "Red y Red Virtual de Seguridad", Prentice Hall, 1995.
[Stallings3, 1995] W. Stallings, "Proteja su privacidad: una guía para los usuarios de PGP" PTR Prentice Hall,
1995.
[Stoll, 1988] C. Stoll, "acecho el Hacker Wily", Comunicaciones de la ACM, Vol. 31, No. 5, Pgs. 484-497, ACM,
Nueva York, Nueva York, mayo de 1988.
[Stoll, 1989] C. Stoll, "El huevo de la cuco", ISBN 00385-24946-2, Doubleday, 1989.
[Treese y Wolman, 1993] G. Treese y A. Wolman, "X a través del firewall, y otros relés Aplicaciones", Digital
Equipment Corporation, Cambridge Research Laboratory, CRL 93/10 3 de mayo de 1993.
[Trible, 1986] P. Trible, "La Ley de Fraude y Abuso de 1986",

Comité del Senado sobre el Poder Judicial, 1986.
[Venema] W. Venema, "TCP wrapper: supervisión de la red, control de acceso y armas trampa", Matemáticas y
Ciencias de la Computación de la Universidad de Tecnología de Eindhoven, Países Bajos.
[USENIX, 1988] USENIX, "USENIX Proceedings: UNIX Taller de Seguridad", Portland, OR, 29-30 de de agosto de,
1988.
[USENIX, 1990] USENIX, "Procedimientos de USENIX: seguridad UNIX II Taller", Portland, OR,
27-28 de de agosto de 1990.

[USENIX, 1992] USENIX, "Actas del Simposio USENIX: seguridad UNIX III", Baltimore, MD, 14-16 de de
septiembre de 1992.
[USENIX, 1993] USENIX, "Actas del Simposio USENIX: seguridad UNIX IV", de Santa Clara, CA, 4-6 de octubre
de 1993.
[USENIX, 1995] USENIX, "El Quinto Simposio USENIX UNIX Seguridad", Salt Lake City, UT, Junio 5-7, 1995.
[Madera, et al, 1987] C. Wood, W. Banks, S. Guarro, A. García, V. Hampel, y H. Sartorio, "Computer Security:
Una lista de control Controles exhaustivos", John Wiley and Sons, publicación Interscience,
1987.
[Wrobel, 1993] L. Wrobel, "planes de recuperación de desastres de escritura de las redes y de

telecomunicaciones" LANS, Artech House, 1993.
[Vallabhaneni, 1989] S. Vallabhaneni, "auditoría de seguridad del ordenador: un manual con estudios de casos",
Wiley, Nueva York, Nueva York, 1989.
Consideraciones de Seguridad
Todo este documento trata sobre los problemas de seguridad.
Información de editor
Barbara Y. Fraser
Software Engineering Institute de Carnegie Mellon
University 5000 Forbes Avenue Pittsburgh, PA
15213
Teléfono: (412) 268-5010 Fax:

(412) 268-6989 EMail: byf@cert.org

Rfc2196 TXT en Es

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Rfc2196 TXT en Es

Încărcat de

Drepturi de autor:

Formate disponibile

Grupo de Trabajo de la Red B.

Manual de seguridad del sitio

Estado de este documento

Fraser, Ed. informativo [Página 1]

4.4 Autorización ................................................ ... 29

( Edward.P.Lewis.1@gsfc.nasa.gov ), Gary Malkin ( gmalkin@xylogics.com ), Russ Mundy ( mundy@tis.com ), Philip

Fraser, Ed. informativo [Página 2]

1.1 Objetivo de este trabajo

Fraser, Ed. informativo [Página 3]

1.4 Trabajo relacionado

1.5 Enfoque básico

(4) Poner en práctica medidas que protejan sus activos en un costo

Fraser, Ed. informativo [Página 4]

1.6 Evaluación de Riesgos

1.6.1 Discusión General

(1) La identificación de los activos (2) La

1.6.2 Identificación de los Activos

(1) Hardware: CPU, tableros, teclados, terminales,

Fraser, Ed. informativo [Página 5]

(2) Software: programas de código, programas, objetos

(3) Datos: durante la ejecución, almacenados en línea, archivados fuera de línea,

(4) personas: usuarios, los administradores, los mantenedores de hardware.

(5) Documentación: sobre programas, hardware, sistemas locales

(6) Materiales: papel, formularios, cintas, medios magnéticos.

1.6.3 Identificación de las amenazas

(1) El acceso no autorizado a los recursos y / o información (2) Unintented y / o divulgación no

2.1 ¿Qué es una Política de Seguridad y por qué tiene uno?

Fraser, Ed. informativo [Página 6]

(1) servicios que se ofrecen en comparación con la seguridad proporcionada -

(2) la facilidad de uso en comparación con la seguridad -

(3) el costo de la seguridad frente al riesgo de pérdida -

2.1.1 Definición de una Política de Seguridad

Fraser, Ed. informativo [Página 7]

2.1.2 Propósitos de una Política de Seguridad

2.1.3 ¿Quién debe participar cuando se forma la política?

administrador de seguridad (1) sitio

La lista anterior es representativa de muchas organizaciones, pero no es necesariamente exhaustiva. La idea es

Fraser, Ed. informativo [Página 8]

2.2 ¿Qué hace una buena directiva de seguridad?

Las características de una buena política de seguridad son:

(1) Debe ser implementable a través de la administración del sistema

(2) Debe ser enforcible con herramientas de seguridad, en su caso,

(3) Se debe definir claramente los ámbitos de responsabilidad de la

Los componentes de una buena política de seguridad incluyen:

(1) tecnología de la computación de compra Directrices que especifique

(2) Una política de privacidad que define las expectativas razonables de

(4) Política de Responsabilidad Una que define las responsabilidades de

Fraser, Ed. informativo [Página 9]

(5) una política de autenticación que establece la confianza a través de una

Política de Mantenimiento (7) Un Sistema y Red de Tecnología de la Información

(8) Violaciónes A Reporting Política que indica qué tipos de

(9) información de apoyo que proporciona a los usuarios, el personal y

Fraser, Ed. informativo [Página 10]

2.3 Mantenimiento de la Política flexible

3.1.1 Planes de Seguridad completamente definido

Fraser, Ed. informativo [Página 11]

3.1.2 Separación de Servicios

Fraser, Ed. informativo [Pagina 12]

3.1.3 Denegar / Permitir todo

Fraser, Ed. informativo [Página 13]

3.1.4 Identificar las necesidades reales de Servicios

3.2 Red y de configuración de servicios

3.2.1 Protección de la Infraestructura