Next: Apéndices
Up: Otros aspectos de la Previous: Algunas herramientas de seguridad
Índice General
Subsecciones
El término política de seguridad se suele definir como el
conjunto de requisitos definidos por los responsables directos o indirectos de
un sistema que indica en términos generales qué está y qué
no está permitido en el área de seguridad durante la operación
general de dicho sistema ([Org88]). Al tratarse de 'términos generales',
aplicables a situaciones o recursos muy diversos, suele ser necesario refinar
los requisitos de la política para convertirlos en indicaciones precisas
de qué es lo permitido y lo denegado en cierta parte de la operación
del sistema, lo que se denomina política de aplicación específica
([MPS$^$93]).
Una política de seguridad puede ser prohibitiva, si todo lo que
no está expresamente permitido está denegado, o permisiva,
si todo lo que no está expresamente prohibido está permitido. Evidentemente
la primera aproximación es mucho mejor que la segunda de cara a mantener
la seguridad de un sistema; en este caso la política contemplaría
todas las actividades que se pueden realizar en los sistemas, y el resto - las
no contempladas - serían consideradas ilegales.
Cualquier política ha de contemplar seis elementos claves en la seguridad
de un sistema informático ([Par94]):
- Disponibilidad
Es necesario garantizar que los recursos del sistema se encontrarán
disponibles cuando se necesitan, especialmente la información crítica.
- Utilidad
Los recursos del sistema y la información manejada en el mismo ha de
ser útil para alguna función.
- Integridad
La información del sistema ha de estar disponible tal y como se almacenó
por un agente autorizado.
- Autenticidad
El sistema ha de ser capaz de verificar la identidad de sus usuarios, y los
usuarios la del sistema.
- Confidencialidad
La información sólo ha de estar disponible para agentes autorizados,
especialmente su propietario.
- Posesión
Los propietarios de un sistema han de ser capaces de controlarlo en todo momento;
perder este control en favor de un usuario malicioso compromete la seguridad
del sistema hacia el resto de usuarios.
El término análisis de riesgos hace referencia al proceso
necesario para responder a tres cuestiones básicas sobre nuestra seguridad:
- ¿qué queremos proteger?
- ¿contra quién o qué lo queremos proteger?
- ¿cómo lo queremos proteger?
Tras conocer y evaluar los riesgos a los que nos enfrentamos podremos implementar
las soluciones prácticas - los mecanismos - para minimizar sus efectos.
Vamos a intentar de entrar con más detalle en cómo dar respuesta
a cada una de estas preguntas:
Debemos identificar todos los recursos cuya integridad pueda ser amenazada de
cualquier forma; por ejemplo, [C$^$91] define básicamente los siguientes:
- Hardware
Procesadores, tarjetas, teclados, terminales, estaciones de trabajo, ordenadores
personales, impresoras, unidades de disco, líneas de comunicación,
servidores, routers...
- Software
Códigos fuente y objeto, utilidades, programas de diagnóstico,
sistemas operativos, programas de comunicación...
- Información
En ejecución, almacenados en línea, almacenados fuera de línea,
en comunicación, bases de datos...
- Personas
Usuarios, operadores...
- Accesorios
Papel, cintas, tóners...
Aparte del recurso en sí (algo tangible, como un router) hemos
de considerar la visión intangible de cada uno de estos recursos (por ejemplo
la capacidad para seguir trabajando sin ese router). Es difícil
generar estos aspectos intangibles de los recursos, ya que es algo que va a depender
de cada organización, su funcionamiento, sus seguros, sus normas...No obstante,
siempre hemos de tener en cuenta algunos aspectos comunes: privacidad de los usuarios,
imagen pública de la organización, reputación, satisfacción
del personal y de los clientes - en el caso de una universidad, de los alumnos
-, capacidad de procesamiento ante un fallo...
Con los recursos correctamente identificados se ha de generar una lista final,
que ya incluirá todo lo que necesitamos proteger en nuestra organización.
Una vez conocemos los recursos que debemos proteger es la hora de identificar
las vulnerabilidades y amenazas que se ciernen contra ellos. Una vulnerabilidad
es cualquier situación que pueda desembocar en un problema de seguridad,
y una amenaza es la acción específica que aprovecha una vulnerabilidad
para crear un problema de seguridad; entre ambas existe una estrecha relación:
sin vulnerabilidades no hay amenazas, y sin amenazas no hay vulnerabilidades.
Se suelen dividir las amenazas que existen sobre los sistemas informáticos
en tres grandes grupos, en función del ámbito o la forma en que
se pueden producir:
- Desastres del entorno.
Dentro de este grupo se incluyen todos los posibles problemas relacionados
con la ubicación del entorno de trabajo informático o de la
propia organización, así como con las personas que de una u
otra forma están relacionadas con el mismo. Por ejemplo, se han de
tener en cuenta desastres naturales (terremotos, inundaciones...), desastres
producidos por elementos cercanos, como los cortes de fluido eléctrico,
y peligros relacionados con operadores, programadores o usuarios del sistema.
- Amenazas en el sistema.
Bajo esta denominación se contemplan todas las vulnerabilidades de
los equipos y su software que pueden acarrear amenazas a la seguridad,
como fallos en el sistema operativo, medidas de protección que éste
ofrece, fallos en los programas, copias de seguridad...
- Amenazas en la red.
Cada día es menos común que una máquina trabaje aislada
de todas las demás; se tiende a comunicar equipos mediante redes locales,
intranets o la propia Internet, y esta interconexión acarrea nuevas
- y peligrosas - amenazas a la seguridad de los equipos, peligros que hasta
el momento de la conexión no se suelen tener en cuenta. Por ejemplo,
es necesario analizar aspectos relativos al cifrado de los datos en tránsito
por la red, a proteger una red local del resto de internet, o a instalar sistemas
de autenticación de usuarios remotos que necesitan acceder a ciertos
recursos internos a la organización (como un investigador que conecta
desde su casa a través de un módem).
Algo importante a la hora de analizar las amenazas a las que se enfrentan nuestros
sistemas es analizar los potenciales tipos de atacantes que pueden intentar violar
nuestra seguridad. Es algo normal que a la hora de hablar de atacantes todo el
mundo piense en crackers, en piratas informáticos mal llamados
hackers. No obstante, esto no es más que el fruto de la repercusión
que en todos los medios tienen estos individuos y sus acciones; en realidad, la
inmensa mayoría de problemas de seguridad vienen dados por atacantes internos
a la organización afectada. En organismos de I+D estos atacantes suelen
ser los propios estudiantes (rara vez el personal), así como piratas externos
a la entidad que aprovechan la habitualmente mala protección de los sistemas
universitarios para acceder a ellos y conseguir así cierto status
social dentro de un grupo de piratas. Los conocimientos de estas personas en materias
de sistemas operativos, redes o seguridad informática suelen ser muy limitados,
y sus actividades no suelen entrañar muchos riesgos a no ser que se utilicen
nuestros equipos para atacar a otras organizaciones, en cuyo caso a los posibles
problemas legales hay que sumar la mala imagen que nuestras organizaciones adquieren.
No siempre hemos de contemplar a las amenazas como actos intencionados contra
nuestro sistema: muchos de los problemas pueden ser ocasionados por accidentes,
desde un operador que derrama una taza de café sobre una terminal hasta
un usuario que tropieza con el cable de alimentación de un servidor y lo
desconecta de la línea eléctrica, pasando por temas como el borrado
accidental de datos o los errores de programación; decir 'no lo hice
a propósito' no ayuda nada en estos casos. Por supuesto, tampoco tenemos
que reducirnos a los accesos no autorizados al sistema: un usuario de nuestras
máquinas puede intentar conseguir privilegios que no le corresponden, una
persona externa a la organización puede lanzar un ataque de negación
de servicio contra la misma sin necesidad de conocer ni siquiera un login
y una contraseña, etc.
Tras identificar todos los recursos que deseamos proteger, así como las
posibles vulnerabilidades y amenazas a que nos exponemos y los potenciales atacantes
que pueden intentar violar nuestra seguridad, hemos de estudiar cómo proteger
nuestros sistemas, sin ofrecer aún implementaciones concretas para protegerlos
(esto ya no serían políticas sino mecanismos). Esto implica en primer
lugar cuantificar los daños que cada posible vulnerabilidad puede causar
teniendo en cuenta las posibilidades de que una amenaza se pueda convertir en
realidad. Este cálculo puede realizarse partiendo de hechos sucedidos con
anterioridad en nuestra organización, aunque por desgracia en muchos lugares
no se suelen registrar los incidentes acaecidos. En este caso, y también
a la hora de evaluar los daños sobre recursos intangibles, existen diversas
aproximaciones como el método Delphi, que básicamente consiste en
preguntar a una serie de especialistas de la organización sobre el daño
y las pérdidas que cierto problema puede causar; no obstante, la experiencia
del administrador en materias de seguridad suele tener aquí la última
palabra a la hora de evaluar los impactos de cada amenaza.
La clasificación de riesgos de cara a estudiar medidas de protección
suele realizarse en base al nivel de importancia del daño causado y a la
probabilidad aproximada de que ese daño se convierta en realidad; se trata
principalmente de no gastar más dinero en una implementación para
proteger un recurso que lo que vale dicho recurso o lo que nos costaría
recuperarnos de un daño en él o de su pérdida total. Por
ejemplo, podemos seguir un análisis similar en algunos aspectos al problema
de la mochila. Llamamos 
al riesgo de perder un recurso i (a la probabilidad de que
se produzca un ataque), y le asignamos un valor de 0 a 10 (valores más
altos implican más probabilidad); de la misma forma, definimos también
de 0 a 10 la importancia de cada recurso, 
, siendo 10 la importancia
más alta. La evaluación del riesgo es entonces el producto de ambos
valores, llamado peso o riesgo evaluado de un recurso, 
, y medido en dinero perdido
por unidad de tiempo (generalmente, por año):
De esta forma podemos utilizar hojas de trabajo en las que, para cada recurso,
se muestre su nombre y el número asignado, así como los tres valores
anteriores. Evidentemente, los recursos que presenten un riesgo evaluado mayor
serán los que más medidas de protección deben poseer, ya
que esto significa que es probable que sean atacados, y que además el ataque
puede causar pérdidas importantes. Es especialmente importante un grupo
de riesgos denominados inaceptables, aquellos cuyo peso supera un cierto
umbral; se trata de problemas que no nos podemos permitir en nuestros sistemas,
por lo que su prevención es crucial para que todo funcione correctamente.
Una vez que conocemos el riesgo evaluado de cada recurso es necesario efectuar
lo que se llama el análisis de costes y beneficios. Básicamente
consiste en comparar el coste asociado a cada problema (calculado anteriormente,
) con el coste de prevenir dicho problema. El cálculo de este
último no suele ser complejo si conocemos las posibles medidas de prevención
que tenemos a nuestra disposición: por ejemplo, para saber lo que nos cuesta
prevenir los efectos de un incendio en la sala de operaciones, no tenemos más
que consultar los precios de sistemas de extinción de fuego, o para saber
lo que nos cuesta proteger nuestra red sólo hemos de ver los precios de
productos como routers que bloqueen paquetes o cortafuegos completos.
No sólo hemos de tener en cuenta el coste de cierta protección,
sino también lo que nos puede suponer su implementación y su mantenimiento;
en muchos casos existen soluciones gratuitas para prevenir ciertas amenazas, pero
estas soluciones tienen un coste asociado relativo a la dificultad de hacerlas
funcionar correctamente de una forma contínua en el tiempo, por ejemplo
dedicando a un empleado a su implementación y mantenimiento.
Cuando ya hemos realizado este análisis no tenemos más que presentar
nuestras cuentas a los responsables de la organización (o adecuarlas al
presupuesto que un departamento destina a materias de seguridad), siempre teniendo
en cuenta que el gasto de proteger un recurso ante una amenaza ha de ser inferior
al gasto que se produciría si la amenaza se convirtiera en realidad. Hemos
de tener siempre presente que los riesgos se pueden minimizar, pero nunca
eliminarlos completamente, por lo que será recomendable planificar no sólo
la prevención ante de un problema sino también la recuperación
si el mismo se produce; se suele hablar de medidas proactivas (aquellas
que se toman para prevenir un problema) y medidas reactivas (aquellas
que se toman cuando el daño se produce, para minimizar sus efectos).
¿Qué hacer cuando nuestra política de seguridad ha sido violada?
La respuesta a esta pregunta depende completamente del tipo de violación
que se haya producido, de su gravedad, de quién la haya provocado, de su
intención...Si se trata de accidentes o de problemas poco importantes suele
ser suficiente con una reprimenda verbal o una advertencia; si ha sido un hecho
provocado, quizás es conveniente emprender acciones algo más convincentes,
como la clausura de las cuentas de forma temporal o pequeñas sanciones
administrativas. En el caso de problemas graves que hayan sido intencionados interesará
emprender acciones más duras, como cargos legales o sanciones administrativas
firmes (por ejemplo, la expulsión de una universidad).
Una gran limitación que nos va a afectar mucho es la situación de
la persona o personas causantes de la violación con respecto a la organización
que la ha sufrido. En estos casos se suele diferenciar entre usuarios internos
o locales, que son aquellos pertenecientes a la propia organización, y
externos, los que no están relacionados directamente con la misma; las
diferencias entre ellos son los límites de red, los administrativos, los
legales o los políticos. Evidentemente es mucho más fácil
buscar responsabilidades ante una violación de la seguridad entre los usuarios
internos, ya sea contra la propia organización o contra otra, pero utilizando
los recursos de la nuestra; cuando estos casos se dan en redes de I+D, generalmente
ni siquiera es necesario llevar el caso ante la justicia, basta con la aplicación
de ciertas normas sobre el usuario problemático (desde una sanción
hasta la expulsión o despido de la organización).
Existen dos estrategias de respuesta ante un incidente de seguridad ([SH95]):
- Proteger y proceder.
- Perseguir y procesar.
La primera de estas estrategias, proteger y proceder, se suele aplicar cuando
la organización es muy vulnerable o el nivel de los atacantes es elevado;
la filosofía es proteger de manera inmediata la red y los sistemas y
restaurar su estado normal, de forma que los usuarios puedan seguir trabajando
normalmente. Seguramente será necesario interferir de forma activa las
acciones del intruso para evitar más accesos, y analizar el daño
causado. La principal desventaja de esta estrategia es que el atacante se da
cuenta rápidamente de que ha sido descubierto, y puede emprender acciones
para ser identificado, lo que incluso conduce al borrado de logs o de
sistemas de ficheros completos; incluso puede cambiar su estrategia de ataque
a un nuevo método, y seguir comprometiendo al sistema. Sin embargo, esta
estrategia también presenta una parte positiva: el bajo nivel de conocimientos
de los atacantes en sistemas habituales hace que en muchas ocasiones se limiten
a abandonar su ataque y dedicarse a probar suerte con otros sistemas menos protegidos
en otras organizaciones.
La segunda estrategia de respuesta, perseguir y procesar, adopta la filosofía
de permitir al atacante proseguir sus actividades, pero de forma controlada
y observada por los administradores, de la forma más discreta posible.
Con esto, se intentan guardar pruebas para ser utilizadas en la segunda parte
de la estrategia, la de acusación y procesamiento del atacante (ya sea
ante la justicia o ante los responsables de la organización, si se trata
de usuarios internos). Evidentemente corremos el peligro de que el intruso descubra
su monitorización y destruya completamente el sistema, así como
que nuestros resultados no se tengan en cuenta ante un tribunal debido a las
artimañas legales que algunos abogados aprovechan; la parte positiva
de esta estrategia es, aparte de la recolección de pruebas, que permite
a los responsables conocer las actividades del atacante, qué vulnerabilidades
de nuestra organización ha aprovechado para atacarla, cómo se
comporta una vez dentro, etc. De esta forma podemos aprovechar el ataque para
reforzar los puntos débiles de nuestros sistemas.
A nadie se le escapan los enormes peligros que entraña el permitir a
un atacante proseguir con sus actividades dentro de las máquinas; por
muy controladas que estén, en cualquier momento casi nada puede evitar
que la persona se sienta vigilada, se ponga nerviosa y destruya completamente
nuestros datos. Una forma de monitorizar sus actividades sin comprometer excesivamente
nuestra integridad es mediante un proceso denominado jailing o encarcelamiento:
la idea es construir un sistema que simule al real, pero donde no se encuentren
datos importantes, y que permita observar al atacante sin poner en peligro los
sistemas reales. Para ello se utiliza una máquina, denominada sistema
de sacrificio, que es donde el atacante realmente trabaja, y un segundo
sistema, denominado de observación, conectado al anterior y que
permite analizar todo lo que esa persona está llevando a cabo. De esta
forma conseguimos que el atacante piense que su intrusión ha tenido éxito
y continue con ella mientras lo monitorizamos y recopilamos pruebas para presentar
en una posible demanda o acusación. Si deseamos construir una cárcel
es necesario que dispongamos de unos conocimientos medios o elevados de programación
de sistemas; utilidades como chroot() nos pueden ser de gran ayuda,
así como software de simulación como Deception Tookit
(DTK), que simula el éxito de un ataque ante el pirata que lo lanza,
pero que realmente nos está informa del intento de violación producido.
Sin importar la estrategia adoptada ante un ataque, siempre es recomendable
ponerse en contacto con entidades externas a nuestra organización, incluyendo
por ejemplo fuerzas de seguridad (en España, Guardia Civil o Policía
Nacional), gabinetes jurídicos o equipos de expertos en seguridad informática,
como el CERT. En el caso de instituciones de I+D, en España existe IrisCERT
(http://www.rediris.es/cert/), el equipo
de respuesta ante emergencias de seguridad de RedIRIS, la red universitaria
española, o esCERT (http://escert.upc.es/), la rama española
del CERT.
Next: Apéndices
Up: Otros aspectos de la Previous: Algunas herramientas de seguridad
Índice General
