La seguridad en cómputo: ¿Con qué se come?

La evolución del rol que cumplen los sistemas en las organizaciones ha cambiado por completo -afortunadamente- el punto de vista que la mayor parte de los desarrolladores tiene con respecto a la seguridad.

Hace una o dos décadas, el tema de la seguridad en cómputo era frecuentemente evitado. Y hasta cierto punto, esto era muy justificable: ¿Intrusos? ¿Integridad? ¿Validaciones? En la década de los 80 había muy poco software diseñado para su operación en red, y mucho menos para la idea de red que tenemos hoy en día. Y si bien es cierto que la mayor parte de los ataques se origina -y siempre se ha originado- dentro del perímetro de confianza de nuestra organización, hace 20 años sencillamente había menos información sensible alojada en medios electrónicos, menos gente con el conocimiento necesario para manipularla, e incluso la manipulación tenía efectos más nocivos: Si bien hace años la infraestructura de cómputo era el soporte facilitador, la copia maestra estaba en papel - Hoy en día estamos transitando hacia la situación opuesta, en que la versión electrónica es la primaria. Hoy, una intrusión en nuestros sistemas puede poner en jaque la integridad de la información primaria.

Mantener la seguridad en los sistemas que desarrollamos implica un alto costo: Los programadores tienen que aprender a evitar errores comunes; tenemos que concientizarnos y acostumbrarnos a dedicar recursos a implementar baterías de pruebas; tienen que entrar en juego validaciones y conversiones sobre los datos que manipulamos, con costos en tiempos de procesamiento de cada solicitud… Pero, afortunadamente, ha crecido también la conciencia de la importancia de destinar a la seguridad la atención y recursos que requiere.

El problema sigue siendo, coloquialmente… /¿con qué se come?/ La seguridad en cómputo sigue siendo un campo dificil de entender, con muchas aristas ocultas. Es por esto que, en las siguientes ediciones de SoftwareGurú, iré abordando algunos temas fundamentales en esta columna.

Para iniciar con esta serie, ataquemos lo fundamental: ¿Qué debemos entender por seguridad en cómputo?

A riesgo de que parezca que me limito a perogrulladas, un /sistema seguro/ es sencillamente un sistema /que responde como debe/. Claro, a esta pregunta hay que verla a la luz de varios criterios para que en verdad signifique algo. Intentemos nuevamente. Un sistema seguro presenta:

Consistencia:: Ante las mismas circunstancias, debe presentar el mismo comportamiento. Ante un sistema /seguro/, el tradicional remedio "¿ya intentaste reniciarlo?" no surte efecto. Si nos hemos acostumbrado a que un reinicio resuelve las cosas, no es sino porque el ambiente de ejecución se ensucia con elementos que debería haber descartado.
Protección y separación:: Los datos, instrucciones y espacio de memoria de un programa, componente o usuario no deben interferir ni permitir interferencia de otros. Las condiciones anormales ocurridas en uno de los componentes -sean accidentales o expresas- deben tener un impacto mínimo en el sistema como un conjunto.
Autenticación:: El sistema debe poseer los mecanismos necesarios para asegurarse que un usuario es realmente quien dice ser
Control de acceso:: Nuestro sistema debe poder controlar con toda la granularidad necesaria los permisos de acceso a sus datos - Quién tiene acceso a qué recursos, y qué tipo de acceso tiene.
Auditoría:: El sistema debe ser capaz de registrar, así como de notificar a quien sea necesario de cualquier anomalía o evento importante.

Claro está, todos estos atributos deben ir matizados, priorizándolos al nivel /adecuado/ a nuestras necesidades. Ir demasiado lejos en uno de estos objetivos puede ser de hecho perjudicial para los fines de nuestro sistema - Por poner un ejemplo, es de todos bien conocido que el tradicional esquema de autenticación basado en usuario y contraseña es fácil de engañar; basta adivinar (o conseguir) un pedazo de información, típicamente de muy débil complejidad, para estar autenticado como determinado usuario. En México, los bancos -por poner un ejemplo- ahora exigen la identificación del cliente a través de dispositivos que presenten una mucho mayor complejidad, generando cadenas de números que cambian periódicamente. Pero, obviamente, poca gente requerirá un nivel de seguridad similar a éste, o basado en parámetros biométricos, para abrir su cuenta de correo.

Y otra anotación: Nos es natural aspirar a la perfección, al 100%. Sin embargo, dice el refrán que “lo perfecto es enemigo de lo bueno”. Es importante que, en toda etapa de la planeación, desarrollo, implantación y tiempo de vida de un sistema recordemos que un 100% de seguridad es una utopía, un objetivo que sólo puede servir para guiar nuestro trabajo diario.

Los programas son escritos por humanos, y son también humanos quienes administran los sistemas en que corren. Hay una gran cantidad de interacciones entre los elementos de un programa y el sistema, y un cambio en cualquiera de ellos puede tener consecuencias inesperadas si no se hace con cuidado y conciencia. Constantemente aparecen nuevas categorías de errores capaces de llevar a problemas de seguridad. Parte fundamental de nuestra actuación como profesionales en nuestro campo debe ser el mantenernos al día con los últimos desarrollos y las últimas amenazas.

Un par de días antes de la entrega de esta columna, dos de las organizaciones más influyentes en la investigación y respuesta a incidentes de seguridad informática, SANS y MITRE, publicaron su lista de los 25 errores de seguridad más importantes:

http://www.sans.org/top25errors/

Este listado incluye muchos temas de fundamental relevancia, algunos de los cuales abordaré en mis posteriores columnas. Vienen explicados con un buen nivel de detalle, detallando cómo evitar o mitigar sus efectos. Les recomiendo fuertemente familiarizarse con estos temas.

Attachments

200902_softwareguru.jpg (598 KB)