Inseguridad Informática
Recientemente revisando dos artículos sobre el desarrollo de software seguro, es interesante ver cómo los dos coinciden en aspectos fundamentales acerca de la construcción de dicho software, pero igualmente los dos documentos no hacen explícitas las consideraciones sistémicas propias de la realidad de un software confiable, no seguro.
Mientras la Maestra en Ciencias de la Computación Julia Allen, establece que construir software sin consideraciones de seguridad, es como tratar de ir por la cuerda floja sin malla protectora, los autores del artículo “la inevitabilidad de la falla”, sostienen que la seguridad inicia con el aseguramiento de los sistemas operacionales, lugar donde muchas veces establecemos los elementos mínimos para asegurar una ejecución confiable de las aplicaciones.
Para Allen, el problema de la seguridad en el desarrollo de software está asociado por un lado con las amenazas durante el desarrollo, es decir, aplicación formal de las buenas prácticas de seguridad durante el ciclo de desarrollo de aplicaciones y por otro, con las amenazas en la operación del mismo, es decir, la toma de ventaja de las vulnerabilidades que se pueden explotar en el uso de la misma, lo cual puede llevar a corrupción de la memoria, buffer overflows y otras fallas propias de la exigencia del usuario del software en su uso.
Para los autores del artículo “la inevitabilidad de la falla”, la seguridad inicia en una sana y buena propuesta de aseguramiento del sistema operacional. Sin este requisito, sostienen los autores, las implicaciones y complejidades derivadas de las fallas de las aplicaciones, serán mayores y por tanto la identificación de la(s) causa(s) será más demandante y exigente en el tiempo y en el detalle técnico. Evitar una falla, sin bien no es posible todo el tiempo, el documento arguye, que si se toman las acciones requeridas de controles de acceso mandatarios, se valoran las fortalezas y limitaciones de los mecanismos de seguridad instalados, es posible mejorar las condiciones de seguridad de los sistemas operacionales.
Si bien los dos documentos, establecen referentes generales y conceptos específicos que apunta a una mejor ejecución y confiabilidad de las aplicaciones, no se advierte las relaciones emergentes propias de un ambiente computacional y cambiante como lo tenemos hoy.
Recientemente revisando dos artículos sobre el desarrollo de software seguro, es interesante ver cómo los dos coinciden en aspectos fundamentales acerca de la construcción de dicho software, pero igualmente los dos documentos no hacen explícitas las consideraciones sistémicas propias de la realidad de un software confiable, no seguro.
Mientras la Maestra en Ciencias de la Computación Julia Allen, establece que construir software sin consideraciones de seguridad, es como tratar de ir por la cuerda floja sin malla protectora, los autores del artículo “la inevitabilidad de la falla”, sostienen que la seguridad inicia con el aseguramiento de los sistemas operacionales, lugar donde muchas veces establecemos los elementos mínimos para asegurar una ejecución confiable de las aplicaciones.
Para Allen, el problema de la seguridad en el desarrollo de software está asociado por un lado con las amenazas durante el desarrollo, es decir, aplicación formal de las buenas prácticas de seguridad durante el ciclo de desarrollo de aplicaciones y por otro, con las amenazas en la operación del mismo, es decir, la toma de ventaja de las vulnerabilidades que se pueden explotar en el uso de la misma, lo cual puede llevar a corrupción de la memoria, buffer overflows y otras fallas propias de la exigencia del usuario del software en su uso.
Para los autores del artículo “la inevitabilidad de la falla”, la seguridad inicia en una sana y buena propuesta de aseguramiento del sistema operacional. Sin este requisito, sostienen los autores, las implicaciones y complejidades derivadas de las fallas de las aplicaciones, serán mayores y por tanto la identificación de la(s) causa(s) será más demandante y exigente en el tiempo y en el detalle técnico. Evitar una falla, sin bien no es posible todo el tiempo, el documento arguye, que si se toman las acciones requeridas de controles de acceso mandatarios, se valoran las fortalezas y limitaciones de los mecanismos de seguridad instalados, es posible mejorar las condiciones de seguridad de los sistemas operacionales.
Si bien los dos documentos, establecen referentes generales y conceptos específicos que apunta a una mejor ejecución y confiabilidad de las aplicaciones, no se advierte las relaciones emergentes propias de un ambiente computacional y cambiante como lo tenemos hoy.
La seguridad del software más allá de la amenazas en el desarrollo y en la operación, y considerando las prácticas propias de aseguramiento de los sistemas operativos, requiere el entendimiento de la inseguridad como propiedad inherente del contexto donde se requieren las medidas de seguridad.
En este contexto, no se puede hablar de seguridad de las aplicaciones, sino confiabilidad de las mismas.
Este nivel de confiabilidad, está dado por el nivel de riesgo aceptado que establece la organización para sus desarrollos, medido todo él en función de la administración de riesgos que hace frente a las prácticas de construcción de software, el estudio del perfil psicológico de los usuarios, las vulnerabilidades propias de los productos utilizados y la evolución de los procesos de negocio de la organización.
La confiabilidad es una propiedad emergente del sistema que se percibe como un incremento de la confianza de los usuarios y clientes en el uso de las tecnologías de información, como parte de la estrategia de la generación de valor de la empresa.
Las diferentes propuestas actuales que buscan disminuir las vulnerabilidades propias del software, basan sus propuestas en consideraciones específicas de uso de las tecnologías y lenguajes de programación, que si bien ayudan a regular el número de vulnerabilidades, frecuentemente conocidas, no avanzan en un estrategia más holística de construcción de software confiable.
Julia Allen sostiene que el software es vulnerado frecuentemente por la explotación de debilidades resultantes de:
1. Complejidades, imprecisiones y cambios en el modelo de procesamiento de software, es decir, en un inadecuado diseño de la arquitectura del software, relacionado con los modelos de procesos y datos lógicos requeridos para los requerimientos del negocio.
2. Supuestos incorrectos aceptados por los desarrolladores, como son entre otros, capacidades del producto, salidas y comportamientos (estados) de las aplicaciones en el ambiente de ejecución o entradas de entes externos.
3. Fallas en la especificación o el diseño que llevan a defectos en la implementación del software o sus componentes.
Considerando este escenario, se puede establecer que tenemos tres tipos de palabras para hablar de problemas que impacten la confiabilidad del desarrollo de las aplicaciones.
Un error, un error es una limitación operacional propia de la utilización del software; un evento causado por un usuario o interconexión con otro proceso. Una falla, es un problema inherente en el diseño mismo de la aplicación y está embebido en la manera como se plantea la solución que se construye y una vulnerabilidad, es la explotación de una falla identificada en el diseño, que bien puede ser producto de la configuración de la aplicación o de las funciones propias del lenguaje utilizado.
En consecuencia de lo anterior, las confiabilidad del software exige la exposición de la aplicación a los errores propios del uso, a la valoración y evaluación de los riesgos propios del diseño y a la explotación de las vulnerabilidades que se expuestas en el diseño. Es importante aclarar que siempre es posible un efecto de borde u operación inesperada que puede no estar documentada ni en la operación, ni en el diseño, por tanto, esta posibilidad es el riesgo residual aceptado por la organización cuando recibe una solución de software para su uso.
La confiabilidad del software requiere un alto grado de experiencia en el uso de buenas prácticas, un claro conocimiento de las posibilidades y oportunidades de los lenguajes de programación y el ojo crítico y analítico de aquel que busca esos lugares en el diseño (visibles y no visibles) donde podemos ir “más allá de lo especificado en la funcionalidad”.
El software seguro, si bien no es posible, por la sencilla razón que no existe riesgo cero, es una oportunidad tanto para los desarrolladores como para las empresas, para aprender de los efectos de borde, pues como decía Albert Einstein, “la imaginación es más poderosa que el conocimiento”. En este sentido, nuestras limitaciones humanas sobre lo que ocurre en los detalles de la implementación, así como nuestras percepciones y operaciones sobre el software, son alimento suficiente para que la inseguridad de la información busque nuevos caminos para sorprendernos y mantenernos “fuera de la zona de confort”.
Referencias
ALLEN, J. (2007) Why is security a software issue?. EDPACS 36:1, 1-13.
LOSCOCCO, SMALLEY et al.(1999) The inevitability of failure: The flawed assumption of security in modern computing environments. National Agent Security.
Visto en Eltiempo.com
No hay comentarios:
Publicar un comentario