En el punto anterior hemos presentado al personal de nuestra organización
como víctima de los ataques realizados por agentes externos a la misma;
sin embargo,
según [Cow92] el 80% de los fraudes, robos, sabotajes o accidentes
relacionados con los sistemas informáticos son causados por el propio personal
de la organización propietaria de dichos sistemas, lo que se suele denominar
el insider factor. >Qué significa esto?
Principalmente que la mayor amenaza a nuestros equipos viene de parte de
personas que han trabajado o trabajan con los mismos. Esto, que es realmente
preocupante, lo es mucho más si analizamos la situación con un mínimo
de detalle: una persona que trabaje codo a codo con el administrador, el
programador, o el responsable de seguridad de una máquina conoce perfectamente
el sistema, sus barreras, sus puntos débiles...de forma que un ataque
realizado por esa persona va a ser muchísimo más directo, difícil
de detectar, y sobre todo, efectivo, que el que un atacante externo (que
necesita recopilar información, intentar probar fallos de seguridad o
conseguir privilegios) pueda ejecutar.
Pero, >por qué va a querer alguien atacar a su propia organización? >Por
qué alguien va a arriesgarse a perder su trabajo, romper su carrera o incluso
a ir a la
cárcel? Como se acostumbra a decir, todos tenemos un precio; no importa lo
honestos que seamos o que queramos creer que somos: dinero, chantaje, factores
psicológicos...nos pueden arrastrar a vender información, a robar
ficheros o simplemente a proporcionar acceso a terceros que se encarguen del
trabajo sucio. En una empresa, un empleado puede considerarse mal pagado e
intentar conseguir un sueldo extra a base de vender información; en un banco,
alguien que a diario trabaje con los sistemas informáticos puede darse
cuenta de la facilidad para desviar fondos a una cuenta sin levantar sospechas;
en una base militar, un país enemigo puede secuestrar a la mujer de un
administrador para que éste les pase información confidencial. Existen
numerosos estudios ([SM70], [CC86], [HC83],
[Kat88], [Rei89]...) que tratan de explicar los motivos que
llevan a una persona a cometer delitos, informáticos o no, contra su propia
organización, pero sea cual sea el motivo la cuestión está en que tales
ataques existen, son numerosos, y hay que tomar medidas contra ellos.
>Cómo prevenir o defendernos de los atacantes internos? En una
empresa, una norma básica sería verificar el curriculum de
cualquier aspirante a nuevo miembro (no simplemente leerlo y darlo por bueno,
sino comprobar los datos y directamente descartar al aspirante si se detecta
una mentira); si buscamos algo más de seguridad - por ejemplo, sistemas
militares - también es recomendable investigar el pasado de cada aspirante
a pertenecer a la organización, buscando sobre todo espacios en blanco durante
los que no se sabe muy bien qué ha hecho o a qué se ha dedicado esa
persona (>quién nos asegura que ese paréntesis de tres años durante los
que el aspirante asegura que estuvo trabajando para una empresa extranjera no
los pasó realmente en la carcel por delitos informáticos?). Si siguiendo
ejemplos como estos podemos asegurar la integridad de todos los que entran
a formar parte del equipo, habremos dado un importante paso en la prevención
de ataques internos.
Tampoco debemos olvidar que el hecho de que alguien entre `limpio' a nuestra
organización no implica que vaya a seguir así durante el tiempo que
trabaje para nosotros, y mucho menos cuando abandone su trabajo. Para minimizar
el daño que un atacante interno nos puede causar se suelen seguir unos
principios fundamentales ([Smi92], [GS96],
[Pla83]...) que se aplican sobre el personal de la empresa:
- Necesidad de saber (Need to know) o mínimo privilegio
A cada usuario se le debe otorgar el mínimo privilegio que necesite para
desepeñar correctamente su función, es decir, se le debe permitir que
sepa sólamente lo que necesita para trabajar. De esta forma, un programador
no tiene por qué conocer las políticas de copia de seguridad de la
máquina, ni un alumno tiene que poseer privilegios en un sistema de
prácticas.
- Conocimiento parcial (Dual Control)
Las actividades más delicadas dentro de la organización en cuanto a
seguridad se refiere (por ejemplo, el conocimiento de la clave de root de
una máquina) deben ser realizadas por dos personas competentes, de forma que
si uno de ellos comete un error o intenta violar las políticas de
seguridad el otro pueda darse cuenta rápidamente y subsanarlo o evitarlo. De
la misma forma, aplicar este principio asegura que si uno de los responsables
abandona la organización o tiene un accidente el otro pueda seguir operando
los sistemas mientras una nueva persona sustituye a su compañero.
- Rotación de funciones
Quizás la mayor amenaza al conocimiento parcial es la potencial complicidad que
los dos responsables de cierta tarea puedan llegar a establecer, de forma que
entre los dos sean capaces de ocultar las violaciones de seguridad que nuestros
sistemas puedan sufrir; incluso puede
suceder lo contrario: que ambas personas sean enemigos y esto repercuta en
el buen funcionamiento de la política de seguridad establecida. Para evitar
ambos problemas, una norma común es rotar - siempre dentro de unos
límites - a las personas a lo largo de diferentes responsabilidades, de
forma que a la larga todos puedan vigilar a todos; esto también es muy
útil en caso de que alguno de los responsables abandone la organización, ya
que en este caso sus tareas serán cubiertas más rápidamente.
- Separación de funciones
No es en absoluto recomendable que una sola persona (o dos, si establecemos un
control dual) posea o posean demasiada
información sobre la seguridad de la organización; es necesario que se
definan y separen correctamente las funciones de cada persona, de forma que
alguien cuya tarea es velar por la seguridad de un sistema no posea él mismo
la capacidad para violar dicha seguridad sin que nadie se percate de ello.
Si aplicamos correctamente los principios anteriores en nuestra política
de personal vamos a evitar muchos problemas de seguridad, no sólo cuando
un usuario trabaja para nuestro entorno sino lo que es igual de importante,
cuando abandona la organización. Cuando esto sucede se debe cancelar inmediatamente el acceso de esa persona a todos nuestros recursos (cuentas de
usuario, servicio de acceso remoto, unidades de red...), y también
cambiar las claves que ese usuario conocía. Especialmente en los entornos
de I+D quizás
esto es algo complicado debido a la gran movilidad de usuarios (un profesor
invitado durante un mes a la universidad, un proyectando que sólo necesita
acceso a una máquina mientras que realiza su proyecto...), por lo que es
aquí donde se suelen ver mayores barbaridades en los sistemas: desde
cuentas que hace años que no se utilizan hasta direcciones de correo de gente
que dejó de trabajar para la organización hace años. Evidentemente, este
tipo de cosas son muy preocupantes para la seguridad, y es justo en estos
accesos no utilizados donde un atacante puede encontrar una de las mejores
puertas de entrada a los sistemas: simplemente hemos de pensar que si el usuario
de una cuenta hace años que no la utiliza, por lógica hace años que esa
clave no se cambia.
Hasta ahora hemos hablado principalmente de los problemas que nos pueden causar
las personas que trabajan para la organización; no obstante, las redes de I+D
son bastante peculiares a la hora de hablar de ataques internos. Se trata de
sistemas en los que un elevado número de usuarios - los alumnos - puede
considerar un reto personal o intelectual (?) saltarse las medidas de
protección impuestas en la red; además, y especialmente en universidades
técnicas, por la naturaleza de sus
estudios muchos alumnos llegan a poseer elevados conocimientos sobre sistemas
operativos y redes, lo que evidentemente es un riesgo añadido: no es lo mismo
proteger de ataques internos una máquina Unix en una Facultad de Derecho,
donde a priori muy pocos alumnos tendrán el interés o los
conocimientos suficientes para saltarse la seguridad del sistema, que en una
Facultad de Informática, donde el que más y el que menos tiene nociones de
seguridad o de Unix y a diario se trabaja en estos entornos.
Las normas vistas aquí seguramente se pueden aplicar sobre el
personal de la organización, pero no sobre los alumnos (que es justamente
de quienes provienen la mayoría de ataques): no podemos obligar a un
alumno de nuevo ingreso a que nos muestre un resumen de su vida, ni mucho menos
tenemos capacidad para verificar los datos de treinta o cincuenta mil alumnos.
Incluso si pudiéramos, >sería legal o ético denegar el acceso a la
universidad a alguien con antecedentes penales, por ejemplo? Seguramente
no...De esta forma, en organismos de I+D nos debemos ceñir a otros
mecanismos de prevención, por ejemplo en forma de sanciones ejemplares para
todos aquellos que utilicen los recursos del centro para cometer delitos
informáticos; sin llegar a los tribunales, las posibles penas
impuestas dentro de la universidad son a veces más efectivas que una denuncia
en el juzgado, donde los piratas incluso despiertan cierta simpatía entre
muchos abogados y jueces.
© 2002 Antonio Villalón Huerta