Next: Seguridad del sistema
Up: Seguridad del entorno de Previous: Seguridad física de los
Índice General
Subsecciones
Con frecuencia se suele afirmar, y no es una exageración ([And94]),
que el punto más débil de cualquier sistema informático son
las personas relacionadas en mayor o menor medida con él; desde un administrador
sin una preparación adecuada o sin la suficiente experiencia, hasta un
guardia de seguridad que ni siquiera tiene acceso lógico al sistema, pero
que deja acceder a todo el mundo a la sala de operaciones, pasando por supuesto
por la gran mayoría de usuarios, que no suelen conscientes de que la seguridad
también les concierne a ellos. Frente a cada uno de estos grupos (administradores,
usuarios y personal externo al sistema) un potencial atacante va a comportarse
de una forma determinada para conseguir lograr sus objetivos, y sobre cada uno
de ellos ha de aplicarse una política de seguridad diferente: obviamente
podemos exigir a un administrador de sistemas unos conocimientos más o
menos profundos de temas relacionados con la seguridad informática, pero
esos conocimientos han de ser diferentes para el guardia de seguridad (sus conocimientos
serían referentes a la seguridad física del entorno), y se convierten
en simples nociones básicas si se trata de un usuario medio.
Hasta ahora hemos hablado de posibles ataques relacionados con el personal de
un sistema informático; sin embargo, existen otras amenazas a la seguridad
provenientes de ese personal que no son necesariamente ataques en un sentido estricto
de la palabra; en muchos casos no son intencionados, se podrían catalogar
como accidentes, pero el que la amenaza no sea intencionada no implica que no
se deba evitar: decir 'no lo hice a propósito' no va ayudar para
nada a recuperar unos datos perdidos. En una sala de operaciones, las personas
realizan acciones sobre los sistemas basándose - en muchos casos - únicamente
en su apreciación personal de lo que está sucediendo; en esas circunstancias,
dichas acciones pueden ser sorprendentes y devastadoras, incluso si provienen
de los mejores y más cuidadosos administradores ([CoIST99]).
La ingeniería social consiste en la manipulación de las personas
para que voluntariamente realicen actos que normalmente no harían ([Fen99]); aunque a nadie le gusta ser manipulado, en
algunos casos no es excesivamente perjudicial (por ejemplo un vendedor puede aplicar
ingeniería social para conocer las necesidades de un cliente y ofrecer
así mejor sus productos), si las intenciones de quien la pone en práctica
no son buenas se convierte quizás el método de ataque más
sencillo, menos peligroso para el atacante y por desgracia en uno de los más
efectivos. Ese atacante puede aprovechar el desconocimiento de unas mínimas
medidas de seguridad por parte de personas relacionadas de una u otra forma con
el sistema para poder engañarlas en beneficio propio. Por ejemplo, imaginemos
que un usuario de una máquina Unix recibe el siguiente correo electrónico:
From: Super-User <root@sistema.com>
To: Usuario <user@sistema.com>
Subject: Cambio de clave
Hola,
Para realizar una serie de pruebas orientadas a conseguir un optimo
funcionamiento de nuestro sistema, es necesario que cambie su clave mediante
la orden 'passwd'. Hasta que reciba un nuevo aviso (aproximadamente en una
semana), por favor, asigne a su contrasenya el valor 'PEPITO' (en
mayusculas).
Rogamos disculpe las molestias. Saludos,
Administrador
Si el usuario no sabe nada sobre seguridad, es muy probable que siga al pie de
la letra las indicaciones de este e-mail; pero nadie le asegura que el
correo no haya sido enviado por un atacante - es muy fácil camuflar el
origen real de un mensaje -, que consigue así un acceso al sistema: no
tiene más que enviar un simple correo, sin complicarse buscando fallos
en los sistemas operativos o la red, para poner en juego toda la seguridad. Sin
saberlo, y encima pensando que lo hace por el bien común, el usuario está
ayudando al pirata a romper todo el esquema de seguridad de nuestra máquina.
Pero no siempre el atacante se aprovecha de la buena fe de los usuarios para lograr
sus propósitos; tampoco es extraño que intente engañar al
propio administrador del sistema4.1. Por ejemplo, imaginemos que la máquina
tiene el puerto finger abierto, y el atacante detecta un nombre de usuario
que nunca ha conectado al sistema; en este caso, una simple llamada telefónica
puede bastarle para conseguir el acceso:
Administrador![$]$](img6.gif)
Buenos dias, aquí
área de sistemas, en qué podemos
ayudarle?
Atacante Hola, soy José Luis Pérez,
llamaba porque no consigo
recordar mi password en la máquina sistema.upv.es.
Administrador Un momento, me puede decir
su nombre de usuario?
Atacante Sí, claro, es jlperez.
Administrador Muy bien, la nueva contraseña
que acabo de asignarle
es rudolf. Por favor, nada más conectar, no olvide cambiarla.
Atacante Por supuesto. Muchas gracias, ha
sido muy amable.
Administrador De nada, un saludo.
Como podemos ver, estamos en la situación opuesta a la anterior: ahora
es el root quien facilita la entrada del atacante en la máquina;
lo único que este ha necesitado es un nombre de usuario válido.
Evidentemente, cualquier mensaje, llamada telefónica o similar que un usuario
reciba debe ser puesto inmediatamente en conocimiento del administrador del sistema;
hay que recordar a los usuarios que en ningún caso se necesita su contraseña
para realizar tareas administrativas en la máquina. De la misma forma,
si es el administrador quien directamente recibe algo parecido a lo que acabamos
de ver, quizás sea conveniente notificar el hecho a los responsables de
la organización, y por supuesto poner la máxima atención
en la seguridad de los sistemas involucrados, ya que en este caso se sabe a ciencia
cierta que alguien intenta comprometer nuestra seguridad; en [Rad97] y [WD95] se muestran algunas de las reglas básicas
que debemos seguir en nuestra organización para prevenir ataques de ingeniería
social y también para, en el caso de que se produzcan, reducir al mínimo
sus efectos.
Otro tipo de ataque relacionado con la ingenuidad de los usuarios del sistema
(pero también con el control de acceso físico) es el denominado
shoulder surfing. Consiste en 'espiar' físicamente a los usuarios,
para obtener generalmente claves de acceso al sistema. Por ejemplo, una medida
que lamentablemente utilizan muchos usuarios para recordar sus contraseñas
es apuntarlas en un papel pegado al monitor de su PC o escribirlas en la parte
de abajo del teclado; cualquiera que pase por delante del puesto de trabajo, sin
problemas puede leer el login, password e incluso el nombre de
máquina a la que pertenecen. Esto, que nos puede parecer una gran tontería,
por desgracia no lo es, y se utiliza más de lo que muchos administradores
o responsables de seguridad piensan; y no sólo en entornos 'privados' o
con un control de acceso restringido, como pueda ser una sala de operaciones de
un centro de cálculo, sino en lugares a los que cualquiera puede llegar
sin ninguna acreditación: personalmente, hace unos años pude leer
claramente 'post-it' pegados a los monitores de los PCs utilizados por
el personal de información de unos grandes almacenes de Valencia, en los
que aparecían el nombre de usuario, la clave y el teléfono de varios
sistemas de la empresa; cualquiera que se acercase al mostrador podía leer
y memorizar esta información sin problemas.
El shoulder surfing no siempre se ve beneficiado por la ingenuidad de
los simples usuarios de un equipo; en determinadas ocasiones son los propios programadores
(gente que teóricamente ha de saber algo más sobre seguridad que
el personal de administración o de atención al público) los
que diseñan aplicaciones muy susceptibles de sufrir ataques de este tipo.
Por ejemplo, en ciertas aplicaciones - especialmente algunas que se ejecutan sobre
MS Windows, y que son más o menos antiguas - muestran claramente en pantalla
las contraseñas al ser tecleadas. Cualquiera situado cerca de una persona
que las está utilizando puede leer claramente esa clave; un perfecto ejemplo
de lo que NO se debe hacer nunca.
El ataque denominado de masquerading o mascarada consiste simplemente
en suplantar la identidad de cierto usuario autorizado de un sistema informático
o su entorno; esta suplantación puede realizarse electrónicamente
- un usuario utiliza para acceder a una máquina un login y
password que no le pertenecen - o en persona. En este punto hablaremos brevemente
de este último caso, la suplantación en persona, un ataque relativo
tanto a la seguridad física del entorno de operaciones como a la seguridad
del personal.
La mascarada no es un ataque habitual en entornos normales; en estos, o bien existen
áreas de acceso semipúblico, donde un atacante no tiene que hacer
nada especial para conseguir acceso - y por tanto no cabe hablar de masquerading
- o bien áreas de acceso restringido pero controlado por el propio personal
de la organización, como despachos o laboratorios. En este caso un ataque
vía mascarada no suele ser efectivo, ya que es muy fácil detectar
al intruso (otro tema sería si realmente se toma alguna medida al detectarlo
o simplemente se le deja seguir, ahí ya entraría en juego la formación
de los usuarios) por tratarse de áreas dentro de las cuales todo el personal
'habitual' se conoce. El masquerading es más habitual en entornos
donde existen controles de acceso físico, y donde un intruso puede 'engañar'
al dispositivo - o persona - que realiza el control, por ejemplo con una tarjeta
de identificación robada que un lector acepta o con un carné falsificado
que un guardia de seguridad da por bueno.
Una variante del masquerading lo constituye el ataque denominado piggybacking,
que consiste simplemente en seguir a un usuario autorizado hasta un área
restringida y acceder a la misma gracias a la autorización otorgada a dicho
usuario. Contra esto se deben aplicar las mismas medidas que contra la mascarada
física: controles de acceso estrictos, y convenientemente verificados.
Los ejemplos de piggybacking son muy habituales: desde un atacante que
se viste con un mono de trabajo y que carga con un pesado equipo informático
en la puerta de una sala de operaciones, para que justo cuando un usuario autorizado
llegue le abra dicha puerta y le permita el acceso por delante del guardia de
seguridad, hasta la clásica anécdota que todos los auditores explican
como suya, sobre el reconocedor de tarjetas inteligentes que abre la puerta de
una sala pero que una vez abierta no se preocupa en contar cuantas personas la
atraviesan, podríamos estar durante días dando ejemplos de ataques
exitosos utilizando la técnica del piggybacking.
La técnica del basureo (en inglés, scavenging) está
relacionada tanto con los usuarios como con la seguridad física de los
sistemas, de la que hemos hablado en el anterior capítulo; consiste en
obtener información dejada en o alrededor de un sistema informático
tras la ejecución de un trabajo ([Par81]). El basureo puede ser físico, como
buscar en cubos de basura ( trashing, traducido también por
basureo) listados de impresión o copias de documentos, o lógico,
como analizar buffers de impresoras, memoria liberada por procesos, o
bloques de un disco que el sistema acaba de marcar como libres, en busca de información.
Aunque esta técnica no es muy utilizada en la mayoría de entornos,
hemos de pensar que si un usuario tira a la basura documentos que proporcionen
información sobre nuestro sistema, cualquier potencial atacante puede aprovechar
esa información para conseguir acceder al equipo; algo tan simple como
una factura en la que se especifiquen números de teléfono o nombres
(reales o de entrada al sistema) de usuarios puede convertirse en una valiosa
información para un atacante. Además, en ocasiones ni siquiera es
necesario andar revolviendo por los cubos de basura en busca de información
comprometedora: la carencia de nociones básicas sobre seguridad informática
hace posible que los usuarios dejen al alcance de cualquiera información
vital de cara a mantener un sistema seguro. Personalmente, en un aula de informática
de la Universidad Politécnica de Valencia encontré por casualidad
una hoja de papel que estaba siendo utilizada a modo de alfombrilla para el ratón;
esta hoja era una carta personalizada que el director de la Escuela Técnica
Superior de Ingenieros Industriales había enviado a cada alumno de esa
escuela para informarles de sus nuevas claves de acceso a ciertos recursos de
la universidad, ya que las anteriores habían tenido que ser cambiadas porque
un pirata las capturó. Con esa sencilla hoja de papel (en la figura 3.1
se muestra una copia - con los datos importantes ocultos, en el original no hay
nada 'censurado' -) cualquiera podría haber leído el correo de ese
usuario, utilizar su acceso remoto de la universidad, curiosear en su expediente
o participar en foros de asignaturas bajo la identidad del usuario atacado.
Figura 3.1: El resultado de un basureo
involuntario.
|
|
Como hemos dicho el basureo no es un ataque habitual en organizaciones 'normales',
simplemente porque los datos con los que estan trabajan no suelen ser de alta
confidencialidad. De cualquier forma, si deseamos evitar problemas lo más
inmediato es utilizar una máquina trituradora de papel (su precio no suele
ser prohibitivo, y la inversión quizás valga la pena) para destruir
toda la documentación antes de arrojarla a la basura; incluso nos puede
interesar contratar los servicios de compañías dedicadas exclusivamente
a la destrucción de estos soportes. En el caso de sistemas de almacenamiento
lógico (discos, CD-ROMs, cintas...) también es importante una correcta
inutilización de los mismos para que un potencial atacante no pueda extraer
información comprometedora; no suele ser suficiente el simple borrado del
medio o un leve daño físico (por ejemplo, partir un CD-ROM), ya
que como comentaremos al hablar de recuperación de datos existen empresas
capaces de extraer hasta el último bit de un medio borrado o dañado.
Lo más efectivo sería un borrado seguro, seguido de una destrucción
física importante que haga imposible la reconstrucción del medio.
Bajo este nombre englobamos actos tipificados claramente como delitos por las
leyes españolas, como el chantaje, el soborno o la amenaza. Esto no implica
que el resto de actividades no sean (o deban ser) delitos, sino simplemente que
en la práctica a nadie se le castiga 'legalmente' por pasear por una sala
de operaciones en busca de claves apuntadas en teclados, pero sí que se
le puede castigar por amenazar a un operador para que le permita el acceso al
sistema.
Por suerte, la naturaleza de la información con la que se trabaja en la
mayor parte de entornos hace poco probable que alguien amenaze o chantajee a un
operador para conseguir ciertos datos; al tratarse de información poco
sensible, en la mayoría de situaciones los atacantes no llegan a estos
extremos para acceder al sistema, sino que utilizan procedimientos menos arriesgados
como la ingeniería social o la captura de datos que viajan por la red.
No obstante, si en alguna ocasión nos encontramos en estas situaciones,
siempre es conveniente la denuncia; aunque en principio podamos ceder ante las
presiones de un delincuente, hemos de tener presente que si mostramos cierta debilidad,
una vez que éste consiga sus propósitos nada le va a impedir seguir
amenazándonos o chantajeándonos para obtener más información.
Si actuamos con la suficiente discrección, las autoridades pueden fácilmente
llevar al individuo ante la justicia sin necesidad de grandes escándalos
que pueden afectar gravemente a la imagen de nuestra organización.
La solución a problemas relacionados con el personal es con frecuencia
mucho más compleja que la de problemas de seguridad lógica o seguridad
de la red: mientras que un administrador puede aprovechar herramientas de seguridad,
capacidades del sistema operativo, o cifrado de datos para prevenir ciertos ataques,
es mucho más difícil para él concienciar a los usuarios de
unas mínimas medidas de prevención o convencer a un guardia de seguridad
de que sólo deje acceder a la sala de operaciones a un número restringido
de personas.
Generalmente los usuarios de máquinas Unix en entornos habituales son personas
muy poco formadas en el manejo del sistema operativo, y mucho menos en lo que
a seguridad informática se refiere; se suele tratar de usuarios que sólo
utilizan la máquina para ejecutar aplicaciones muy concretas (simulaciones,
compiladores, gestión del correo electrónico, aplicaciones científicas...relacionadas
con su área de trabajo), y cuya única preocupación es que
sus datos estén listos cuando los requieren, de la forma más fácil
y rápida posible. Incluso el administrador de ciertos sistemas es uno de
estos usuarios, elegido dentro del grupo (o mucho peor, son todos los usuarios).
Evidentemente, resulta muy difícil concienciar a estas personas de la necesidad
de seguridad en el entorno; posturas como 'no importa que mi clave sea débil,
sólo utilizo la cuenta para imprimir con la láser' son por desgracia
demasiado frecuentes. El responsable de seguridad ha de concienciar a todas estas
personas de la necesidad de la seguridad para que el entorno de trabajo funcione
como se espera de él; la seguridad informática se ha de ver como
una cadena que se rompe si falla uno de sus eslabones: no importa que tengamos
un sistema de cifrado resistente a cualquier ataque o una autenticación
fuerte de cualquier entidad del sistema si un intruso es capaz de obtener un nombre
de usuario con su correspondiente contraseña simplemente llamando por teléfono
a una secretaria.
Además de concienciación de los usuarios y administradores en cuanto
a seguridad se refiere (esto sería el QUÉ), para
conseguir un sistema fiable es necesaria la formación de los mismos
(el CÓMO). De la misma forma que a nadie se le ocurre conducir
sin tener unos conocimientos básicos sobre un automóvil, no debería
ser tan habitual que la gente utilice o administre Unix sin unos conocimientos
previos del sistema operativo. Evidentemente, a un químico que utiliza
el sistema para simular el comportamiento de determinada sustancia bajo ciertas
condiciones no se le puede exigir un curso intensivo o unos grandes conocimientos
de mecanismos de seguridad en Unix; pero sí que sería recomendable
que conozca unas ideas básicas (volviendo al ejemplo del automóvil,
para conducir un coche a nadie se le exige ser un as de la mecánica, pero
sí unas cualidades mínimas). Estas ideas básicas se pueden
incluso resumir en una hoja que se le entregue a cada usuario al darlos de alta
en el sistema. Si pasamos a hablar de administradores, sí que sería
recomendable exigirles un cierto nivel de conocimientos de seguridad, nivel que
se puede adquirir simplemente leyendo algún libro (especialmente recomendado
sería [GS96] o, para los que dispongan
de menos tiempo, [RCG96]).
Un grupo de personas más delicado si cabe es el conjunto formado por todos
aquellos que no son usuarios del sistema pero que en cierta forma pueden llegar
a comprometerlo. Por ejemplo, en este conjunto encontramos elementos tan diversos
como guardias de seguridad que controlen el acceso a las instalaciones informáticas
o personal de administración y servicios que no utilicen el sistema pero
que tengan acceso físico a él, como electricistas, bedeles o personal
de limpieza. Sin entrar en temas que seguramente no son aplicables a los sistemas
habituales, como el espionaje industrial o el terrorismo de alta magnitud4.2, simplemente hemos de concienciar y enseñar
a estos 'usuarios' unas medidas básicas a tomar para no poner en peligro
nuestra seguridad; estas medidas dependen por supuesto de la función de
cada unas personas realice.
Pero, ¿qué sucede cuando el personal de nuestra propia organización
produce ataques (y no accidentes) sobre nuestros sistemas? En este caso las consecuencias
pueden ser gravísimas, y por tanto las medidad de protección y detección
han de ser estrictas. Se ha de llevar a cabo un control estricto de las actividades
que se realizan en la organización, por ejemplo mediante políticas
que han de ser de obligado cumplimiento, así como un control de acceso
a todos los recursos de los que disponemos (mediante mecanismos de autenticación
de usuarios, alarmas, etc.). Además, las sanciones en caso de incumplimiento
de las normas han de ser efectivas y ejemplares: si un usuario viola intencionadamente
nuestra seguridad y no se le sanciona adecuadamente, estamos invitando al resto
de usuarios a que hagan lo mismo. En el punto siguiente vamos a hablar con más
profundidad de estos atacantes, denominados internos.
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.
Notas al pie
- ... sistema4.1
- Esto simplemente es para dar más credibilidad, pero no es necesario
que el usuario real no haya conectado en mucho tiempo.
- ... magnitud4.2
- Temas que habría que tener en cuenta en otro tipo de redes.
Next: Seguridad del sistema
Up: Seguridad del entorno de Previous: Seguridad física de los
Índice General
![\includegraphics [width=\textwidth]{scav.ps}](img7.gif)