El atacante interno

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.