Intrusos en la nube Por Manuel Dávila Sguerra En otro artículo

Intrusos en la nube
Por Manuel Dávila Sguerra
En otro artículo habíamos hablado del software seguro y decíamos que cuando se habla de seguridad
informática, lo común es referirse a la protección centrada en el tráfico de la red es decir, seguridad perimetral.
Esta área es cada vez más robusta, aunque sabemos que lograr un 100% de seguridad es casi imposible.
Algún “hueco de seguridad” queda abierto por donde puede entrar un intruso.
El concepto del software seguro tiene otra orientación. Imaginémonos una aplicación en la nube a la cual
intentarán entrar muchos usuarios, autorizados unos y no autorizados otros. Los roles y permisos de los
usuarios autorizados seguramente han sido establecidos previamente y sin excepción hay un usuario que tiene
el rol de administrador con permisos especiales para controlar la configuración funcional del sistema, autorizar
el acceso y administrar el sistema. Claramente tendrá el control total del sistema.
Uno de los puntos de riesgo que trata el diseño de software seguro, está en la posibilidad de que alguien se
apodere de una o varias cuentas con sus respectivas contraseñas y entre al sistema en cuyo caso habría
vulnerado la seguridad perimetral. Sea o no la cuenta del administrador la vulnerada, la aplicación estaría en un
momento crítico. Es cuando cabe la pregunta:¿Como se va a defender el sistema?
En el artículo mencionado sobre software seguro hacíamos un esbozo de los planteamientos hechos por Gary
McGraw un experto en ciencia de los computadores y filósofo de profesión, que se ha convertido en uno de los
principales promotores de las propuestas del software seguro. En esta ocasión vamos a tratar solo uno de los
aspectos cruciales como es el caso de los intrusos en la nube bajo el contexto que hemos venido exponiendo.
El centro de nuestra propuesta de solución está en el sistema de autenticación, es decir en el instante en el cual
el sistema recibe los datos de cuenta y contraseña de un usuario que entre al sistema, momento en el cual se
establecen los permisos de navegación determinados por el rol que se le ha autorizado a dicho usuario. En el
libro de O'Reilly sobre “Crimen por computador”, en el cual se relatan las experiencias recopiladas por el FBI,
dicen que el caso más común de fraude o intrusión se debe al robo de las claves de acceso a un sistema. No
son, en general, intrusiones de altos niveles de conocimiento. Esto nos reafirma la idea de controlar el momento
de la autenticación y considerarlo un punto de alta vulnerabilidad.
Imaginémonos el caso en el cual un sistema financiero sufre un ataque de las características mencionadas y
entra al sistema un usuarios autorizado, pero otro u otros también lo hacen usando la misma cuenta; los demás
son intrusos. Usualmente los sistemas no se desarrollan incluyendo una fase de seguridad y la mayoría de las
veces el sistema ni siquiera se percata de que eso esté ocurriendo.
Narraré de manera muy resumida un mecanismo que hemos implementado para buscar seguridad en la
autenticación, de tal manera que el software “sepa” quienes están conectados y detecte y actúe cuando se
presente la situación que acabamos de describir. Estos prototipos los implementamos dentro de proyectos de
investigación los que,una vez se haya comprobado su eficiencia, los promovemos dentro de la comunidad
educativa de informática para proponer proyectos de grado, investigaciones y hacer consciencia dentro de los
estudiantes la importancia de incluir estas funcionalidades dentro de los desarrollos de software.
Asumamos entonces que las claves han sido “robadas” y que han logrado entrar, uno o varios usuarios,
simultáneamente con las mismas cuentas y claves. Lo primero que contempla el algoritmo es poder analizar las
lista de usuarios conectados de tal manera que al entrar un nuevo usuario, verifique si la cuenta con la cual se
registró el nuevo usuario ya existe dentro de los usuarios activos. En ese momento el programa no sabe cuál de
ellos es el verdadero usuario autorizado. No hay manera de saberlo y solo queda la alternativa que el mismo
sistema cancele la ejecución de ese usuario sin contemplaciones, pues es un momento de altísimo riesgo. Con
esa decisión se le ha cortado el acceso a todos los usuarios conectados con dicha cuenta, inclusive al usuario
propietario.
En este aspecto el diseño del software debe tener en cuenta los procesos de recuperación para que las bases
de datos no vayan a quedar polucionadas.
Probablemente el intruso o intrusos y el usuario autorizado querrán volver a entrar al sistema para reiniciar la
ejecución de la aplicación. En ese momento el algoritmo, que debe estar dentro del sistema de autenticación, ya
1
está anunciado de la anomalía y por lo tanto el proceso de autenticación ya no será el estándar pues debe
asegurarse que el usuario que entra es el que dice ser. La manera de asegurarse de esto es la formulación de
preguntas que aseguren que solo pueden ser respondidas por dicho usuario. La debilidad de este método
radica en que las respuestas también pudieron haber sido “robadas”. El nivel de fidelidad que tenga este
método es el que asegurará la autenticación segura. Estamos probando mecanismos más estrictos en donde la
meta es asegurar que quien entra al sistema sea en realidad la persona que dice ser, basados en la
comprobación del conocimiento de aspectos del mismo sistema que solo él podría saberlo. Estos algoritmos
son ricos en expresiones regulares y tienen visos de inteligencia artificial pero son factibles de implementar.
2