Published 16 years ago
(updated 13 years ago)
¿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 era justificable: ¿Intrusos? ¿Integridad? ¿Validaciones? En ese entonces 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. 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 menos nocivos, ya que la información en medios electrónicos era el respaldo de la copia maestra que estaba en papel. Hoy en día estamos transitando hacia la situación opuesta, donde la versión electrónica es la primaria, por lo que 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 deben aprender a evitar errores comunes; hay que dedicar recursos para implementar baterías de pruebas; entran 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 que esto es algo necesario.
El problema sigue siendo, coloquialmente... “¿con qué se come?” La seguridad en cómputo sigue siendo un campo difícil de entender, con muchas aristas ocultas. Es por esto que, en las siguientes ediciones de SG, iré abordando en esta columna algunos temas fundamentales.
Para iniciar, 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, hay que ver esto 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 reiniciarlo?” 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 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 asegurar que un usuario es realmente quien dice ser.
• Control de acceso. Nuestro sistema debe ser capaz de controlar el acceso a sus datos, con el nivel de granularidad requerido –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.
Todos estos atributos deben ir matizados, priorizándolos al nivel adecuado a nuestras necesidades. Ir demasiado lejos en uno de estos objetivos puede incluso ser perjudicial para los fines de nuestro sistema. Por ejemplo, en México un usuario de banco por Internet se autentifica a través de usuario y password, en combinación con un dispositivo que genera cadenas de números que cambian periódicamente. Esto tiene sentido para el manejo de una cuenta de banco, pero podría ser demasiado para una simple cuenta de correo electrónico.
Una recomendación es no perderse tratando de lograr la perfección. Bien 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 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 sus elementos; 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 mantenernos al día con los últimos desarrollos y amenazas.
Dos de las organizaciones más influyentes en la investigación y respuesta a incidentes de seguridad informática, SANS y MITRE, acaban de publicar su lista de los 25 errores de seguridad más importantes: www.sans.org/top25errors.
Este listado incluye muchos temas de fundamental relevancia, algunos de los cuales abordaré en posteriores columnas. Vienen explicados con un buen nivel de detalle, puntualizando cómo evitar o mitigar sus efectos. Les recomiendo ampliamente familiarizarse con ellos.
Acerca del Autor
Gunnar Wolf es administrador de sistemas para el Instituto de Investigaciones Económicas de la UNAM; entusiasta y promotor del Software Libre, desarrollador del proyecto Debian GNU/Linux desde el 2003, miembro externo del Departamento de Seguridad en Cómputo de DGSCA-UNAM desde 1999.
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 era justificable: ¿Intrusos? ¿Integridad? ¿Validaciones? En ese entonces 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. 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 menos nocivos, ya que la información en medios electrónicos era el respaldo de la copia maestra que estaba en papel. Hoy en día estamos transitando hacia la situación opuesta, donde la versión electrónica es la primaria, por lo que 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 deben aprender a evitar errores comunes; hay que dedicar recursos para implementar baterías de pruebas; entran 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 que esto es algo necesario.
El problema sigue siendo, coloquialmente... “¿con qué se come?” La seguridad en cómputo sigue siendo un campo difícil de entender, con muchas aristas ocultas. Es por esto que, en las siguientes ediciones de SG, iré abordando en esta columna algunos temas fundamentales.
Para iniciar, 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, hay que ver esto 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 reiniciarlo?” 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 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 asegurar que un usuario es realmente quien dice ser.
• Control de acceso. Nuestro sistema debe ser capaz de controlar el acceso a sus datos, con el nivel de granularidad requerido –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.
Todos estos atributos deben ir matizados, priorizándolos al nivel adecuado a nuestras necesidades. Ir demasiado lejos en uno de estos objetivos puede incluso ser perjudicial para los fines de nuestro sistema. Por ejemplo, en México un usuario de banco por Internet se autentifica a través de usuario y password, en combinación con un dispositivo que genera cadenas de números que cambian periódicamente. Esto tiene sentido para el manejo de una cuenta de banco, pero podría ser demasiado para una simple cuenta de correo electrónico.
Una recomendación es no perderse tratando de lograr la perfección. Bien 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 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 sus elementos; 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 mantenernos al día con los últimos desarrollos y amenazas.
Dos de las organizaciones más influyentes en la investigación y respuesta a incidentes de seguridad informática, SANS y MITRE, acaban de publicar su lista de los 25 errores de seguridad más importantes: www.sans.org/top25errors.
Este listado incluye muchos temas de fundamental relevancia, algunos de los cuales abordaré en posteriores columnas. Vienen explicados con un buen nivel de detalle, puntualizando cómo evitar o mitigar sus efectos. Les recomiendo ampliamente familiarizarse con ellos.
Acerca del Autor
Gunnar Wolf es administrador de sistemas para el Instituto de Investigaciones Económicas de la UNAM; entusiasta y promotor del Software Libre, desarrollador del proyecto Debian GNU/Linux desde el 2003, miembro externo del Departamento de Seguridad en Cómputo de DGSCA-UNAM desde 1999.
- Log in to post comments