Recomendaciones de seguridad en Sistemas Distribuidos 1

1. Efectuar un análisis de riesgos

Esto se suele mencionar en la literatura como el primer paso a realizarse cuando se plantea la seguridad en un
sistema [4]. La idea es muy sencilla: trazar todos los elementos que conforman nuestro sistema (hardware y
software) y observar cuáles involucran más o menos riesgo. Esto desembocará en un plan de seguridad cuyo objetivo
es disminuir el riesgo total del sistema, que se puede modelar como la suma de los riesgos de sus componentes:
RIESGO TOTAL = RIESGO(componente 1) + RIESGO(componente 2) ...

El riesgo de cada componente está en función directa a las pérdidas que ocasionaría el que éste deje de operar, así
como en función de cuán vulnerable es dicho componente en este momento. Por ejemplo, una base de datos de
clientes involucra un gran riesgo debido al gran valor que la información representa para una organización; pero una
simple PC Windows de la misma organización conectada directamente al Internet (sin firewall/proxy de por medio)
también lo representa, debido a que puede ser objeto de un ataque desde el exterior, con el posible riesgo de fácil
propagación hacia otros computadores de nuestra red.

El riesgo no es fácil de cuantificar, siendo en general un estimador subjetivo. A modo de ejemplo podríamos plantear
una fórmula como la que sigue:

RIESGO(componente) = P * V

Donde P=pérdida, es la pérdida en dinero que implicaría la inoperatividad del componente hasta su reparación,
aunque se pueden agregar otros estimadores como el desprestigio ante nuestros clientes. A veces ayuda considerarlo
como "el valor" que representa para la organización. V=vulnerabilidad, es tanto o más subjetiva puesto que no hay
una manera segura de establecer para todos los casos si los supuestos mecanismos de protección (del componente)
son o no realmente confiables. Así por ejemplo, podríamos suponer que la vulnerabilidad de ciertos documentos
importantes es muy baja, puesto que están protegidos por cierto antivirus. Sin embargo, esto realmente estará en
función de diversas características del antivirus, como pueden ser: recientes actualizaciones, ejecución automática,
capacidad de eliminar virus locales, licencias no caducadas, configuración adecuada, etc. Pero por algo se debe
comenzar. Por ejemplo, se puede asignar números como 1, 2, 3, 4, para señalar una vulnerabilidad mínima, regular,
importante y peligrosa, respectivamente. Para una extensa (y compleja) explicación, ver [5].

Esto normalmente demanda el acopio de mucha información, la que muchas veces no está a cargo de una sola
persona. Esto implica que todo el staff encargado de las distintas partes del sistema debe colaborar en el análisis.

2. Lo más valioso debe alejarse de lo más vulnerable

En la fórmula del "riesgo" propuesta arriba, es evidente que los componentes de nuestro sistema con algo valor y alta
vulnerabilidad serán de lejos los que presenten mayor riesgo. Sin embargo, en muchos casos no es sencillo disminuir
el valor de cierto componente (y por tanto la pérdida en caso de problemas), y tampoco se puede eliminar completamente la vulnerabilidad del mismo (por ejemplo, si está de cara a Internet.) En este caso lo que conviene es separar o dividir este componente en dos partes suficientemente alejadas e independientes a fin de que el riesgo total disminuya. Por ejemplo, los portales de comercio electrónico deben dar cara a Internet (siendo vulnerables en principio) y a la vez manejar información muy costosa (como transacciones con tarjeta de crédito.) Esto los convierte en un sistema de alto riesgo. Sin embargo es casi universal la separación que se efectúa entre los componentes dedicados a dar cara a Internet (como los Web Servers) y los componentes que manipulan la información comercial (generalmente sistemas DBMS.) En términos prácticos, esto significa que el hacker no puede acceder directamente al DBMS (lo que sería catastrófico), y sólo podría atacar al Web Server, lo que en principio no acarrea mayores consecuencias.

Juguemos con los números siguiendo las ideas expuestas más arriba. Suponiendo que los datos relacionados al
negocio valen para nosotros $50000, y están en un computador donde corre un Web Server IIS que no ha sido
parchado adecuadamente. Entonces el riesgo sería:

R total = 50000 x 5 = 250000

Supongamos ahora que los datos están en otro computador "mínimamente vulnerable" (con V=1) adecuadamente
aislado del Web Server (que todavía no ha sido parchado). La pérdida por una interrupción del servicio del Web
Server, por día se ha estimado en $2000 (asumimos que ese es el tiempo que toma en restablecerse el servicio tras el
ataque.) Entonces el riesgo total se convierte en:

R total = R1 + R2 = 50000 x 1 + 2000 x 5 = 60000

3. Mantener las cosas simples

Un sistema complejo es más difícil de asegurar y potencialmente proporciona una mayor cantidad de puertas abiertas
a los atacantes. En general, es recomendable intentar dividir el problema mediante la simplificación de la
configuración, para así identificar los puntos o rutas de control vulnerables para incrementar la seguridad.

Un ejemplo frecuentemente citado es la seguridad de una red de estaciones Windows manipulada por usuarios
inexpertos. En muchos casos no resulta práctico efectuar un profundo trabajo de seguridad en las estaciones (más allá
de la instalación del antivirus, por ejemplo), puesto que por un lado, son muchas, y por otro, los usuarios suelen
modificar la configuración en tanto instalan y desinstalan su software sin dar aviso a nadie. En estos casos es
aconsejable centrarnos en un único punto que centralice la seguridad de todas las estaciones. Una configuración de
red que obligue a que todo su tráfico pase a través de un gateway permitiría crear un único punto de control para
todas las estaciones, con lo cual simplificamos la administración.

Todo esto generalmente conlleva a situaciones en las que hay que hacer un compromiso. Por ejemplo, en la
recomendación anterior, optamos por separar la base de datos del servidor Web con lo que la complejidad del sistema
se incrementó, aunque se redujo el riesgo total.

4. Asegurar la seguridad en todos los niveles

Esto se puede expresar más sencillamente como: no confiar el sistema a un único mecanismo de seguridad.
La información fluye a través de los distintos componentes y/o capas del sistema y son muchas las instancias en las
que se puede mejorar su seguridad. La recomendación estipula que utilicemos todas estas instancias a pesar de que
en principio puedan parecer redundantes. Por lo general los administradores tienden a preocuparse por un único
punto de acceso desde donde supuestamente hay una gran probabilidad de ser atacados (por ejemplo, la conexión a
Internet.) Por tanto se invierte esfuerzo y dinero en controlar este único punto bajo la asunción de que es la única
puerta de entrada a los maleantes y que por tanto, tras asegurarla, todo el sistema quedará seguro. Esto tiene dos
problemas:

• Muchos ataques o "vulnerabilidades" se originan (de forma inocente o intencional) desde dentro de la organización
• El sistema que controla la "puerta" siempre puede fallar

Esto obliga a implementar la seguridad no en un único punto evidentemente vulnerable, sino en todos los lugares por
donde fluye la información al interior de cada componente involucrado.

Un ejemplo típico lo constituye un filtro de paquetes TCP/IP, operando a nivel de capas 3 y 4 del modelo OSI. Estos
por lo general hacen un gran servicio restringiendo accesos a servicios de red internos y se suelen colocar en la
"puerta" o "gateway" que da cara a Internet o a una red insegura a modo de "firewall".

Tomando literalmente la idea de "niveles" o "capas", podríamos pensar qué hacer en este gateway para mejorar la
seguridad. Son 7 las capas OSI y podríamos intentar añadir instancias de control adicionales a las mencionadas. Por
ejemplo, en la capa 7 (aplicación) es frecuente y muy recomendable el empleo de proxys HTTP. Algunos firewalls
proporcionan control a nivel de la capa 2 (específicamente, del MAC Address.)

Sin embargo, esto se debe complementar con otras medidas que van más allá del gateway y que se implementan a lo
largo de todo el sistema (pudiéndose considerar como niveles o "capas" adicionales), tales como redes perimétricas,
el uso de encriptación, etc.

5. Encriptar tanto como sea posible

La encriptación es un tema complejo pero cuya implementación resulta cada vez más sencilla conforme aparecen más
productos. Los cambios del año pasado en la legislación norteamericana con respecto a la exportación de productos
que encriptan, son un incentivo claro para que los desarrolladores y vendedores se interesen más en el tema.

En general, los canales de comunicación más vulnerables o de mayor cercanía al público requieren una encriptación
"más fuerte", es decir, más difícil de descifrar por los curiosos o atacantes. Cierta información conlleva más riesgo
que otra, y por tanto requerirá un nivel de encriptación diferenciado.

Las herramientas capaces de hacer esto son muchas, dependiendo del contexto en que nos encontremos. Por ejemplo,
los sistemas DBMS más avanzados incorporan la encriptación como una opción normal para los datos almacenados,
generalmente bajo esquemas propietarios.

La tecnología de encriptación de información destinada a pasar a través de la red ha evolucionado bastante,
haciéndose popular el término VPN [6],[7] para hacer referencia a canales que encriptan la información de un modo
más o menos transparente. Hay soluciones propietarias así como estándares relativamente implementados como IP
Sec.

Ciertas aplicaciones estándar han recibido soluciones de encriptación también estándar. El caso del Web encriptado
bajo SSL (HTTPS) junto con la industria de certificados digitales es el caso más conspicuo. De igual modo los
estándares para correo electrónico PGP (o derivados) y S/MIME son integrados cada vez con mayor frecuencia en
las aplicaciones de los usuarios finales.

Retornemos al principio. En nuestra organización deberíamos encriptar todo lo que sea posible. La razón de esto es
evidente si de lo que se trata es de enviar un mensaje privado por Internet. Sin embargo, al interior de la organización
la encriptación puede ayudar también. Por ejemplo, es usual que cierta información sea manejada exclusivamente por
un número reducido de personas (los contratos salariales, por poner un caso.) Un caso más dramático se presenta
cuando un hacker ha logrado infiltrarse en la organización: si la información está encriptada, los datos que robe le
serán inútiles dado que no posee las claves correspondientes.

Naturalmente hay que sopesar los inconvenientes que trae la encriptación en términos de incomodidad de uso, costo
de licencias, ciclos de CPU, etcétera; con el hecho de que cierta información es definitivamente de carácter público y
por tanto no tiene sentido que esté encriptada. Por ejemplo, la información que se publica en Internet vía el Web
Server de la empresa. En [8] se puede obtener regularmente mucha información interesante y actualizada sobre la
encriptación.

6. No confiar en la autenticación estándar

Las redes locales, y por extensión, el Internet, NO fueron diseñados en principio para ser seguros. La mayoría del
software y hardware creados hasta incluso mediados de los años 90, no tuvieron la seguridad como objetivo de
primer orden. Esto implica que muchos de los sistemas que compramos y usamos en la actualidad tienen serias
deficiencias, pero que por mantener la compatibilidad no se han podido corregir.

Un caso crítico es lo concerniente a la autenticación de los accesos. En la gran mayoría de casos esto se limita a
proporcionar una contraseña por parte de quien pretende acceder al recurso correspondiente, cosa que funciona bien
en un ambiente seguro en el que todos estamos de acuerdo en no ir más allá de este mecanismo. Sin embargo esto no
siempre es cierto (y menos en Internet.) Son muchos los mecanismos que puede emplear un hacker para "capturar"
las contraseñas de usuarios reales, así como para "adivinar" las mismas. Otros esquemas pretenden ser más seguros
basándose en el análisis de la dirección de red de quien intenta conectarse, pero de igual modo los hackers pueden
"simular" una dirección de red sin mayores inconvenientes.

En tanto los ataques son cada vez más sofisticados, es de rigor que la autenticación también sea cada vez más
sofisticada, lo cual implica abandonar para siempre diversos mecanismos estándar muy arraigados. El ejemplo más
paradigmático tal vez sea el comando "telnet" de los sistemas Unix, utilizado para obtener una sesión en un sistema
remoto. Este comando se distribuye (y se seguirá distribuyendo sin duda) en prácticamente todas las encarnaciones
de los sistemas Unix y sus clones (como Linux.) Es tan popular y útil que incluso los sistemas Windows lo
proporcionan. Sin embargo, ningún administrador serio recomendaría su uso para una conexión remota, y quizá
tampoco al interior de la red. La razón estriba en que toda la información de autenticación (el nombre de usuario y su
contraseña) viaja sin encriptación tal cual es, y cualquier persona con acceso a un nodo intermedio o al canal de la
conexión puede extraer esta información con relativa facilidad.

Actualmente diversos productos y estándares promueven la seguridad en la autenticación. Como muestra podemos
mencionar a SSH [9], S/Key [10], Kerberos [11], Tcpwrappers, etc.

Fuente:

Recomendaciones de seguridad en sistemas distribuidos de cómputo
(V0.11)
Diego Bravo Estrada

Si quieres conocer otros artículos parecidos a Recomendaciones de seguridad en Sistemas Distribuidos 1 puedes visitar la categoría SEGURIDAD INFORMATICA.