La seguridad en la Ingeniería de Software

por Nick Feamster
Traducido por Patrick Royer

Introducción

La seguridad en la Ingeniería de Software es un tema amplio. En este articulo nos vamos a enfocar en la definición y la discusion de la seguridad de software, confiabilidad del software, la responsabilidad del desarrollador y de la responsabilidad del usuario.

Ingeniería de sistemas de Computación

La seguridad de software aplica los principios de la seguridad de información al desarrollo de software. Information security (La seguridad de información) se refiere a la seguridad de información comunmente como la protección de sistemas de información contra el acceso desautorizado o la modificación de información, si esta en una fase de almacenamiento, procesamiento o tránsito. Tambien la proteje contra la negación de servicios a usuarios desautorizados y la provisión de servicio a usuarios desautorizados, incluyendo las medidas necesarias para detectar, documentar, y contrarear tales amenazas.

Muchas preguntas con respecto a la seguridad, son relacionadas al ciclo vital de software. En particular, la seguridad del código y el processo de software; deben de ser considerados durante la fase del diseño y desarrollo. Además, la seguridad debe de ser preservada durante la operación y el mantenimiento para asegurar la integridad de una parte (pedazo) de software.

Una gran cantidad de seguridad usada en los Sistemas de Redes de hoy, nos pueden engañar en la creencia que nuestros trabajos como diseñadores de sistema de seguridad ya han sido realizados. Sin embargo, las cadenas y computadoras son increíblemente inseguras. La falta de seguridad se origina en dos problemas fundamentales: Los sistemas que son teóricamente seguros pueden ser inseguros en la práctica, Además los sistemas son cada vez más complejos. La complejidad proporciona más oportunidades para los ataques. Es mucho más fácil probar que un sistema es inseguro que demostrar que uno es seguro -- probar la inseguridad, simplemente una toma ventaja de ciertas vulnerabilidades del sistema. Por otra parte, probando un sistema seguro, requiere demostrar que todas las hazañas posibles puedan ser defendidas contra (muy desalentadora), si no imposible, la tarea

Actualmente, no hay ninguna solución singular para asegurar la ingenieria de software. Sin embargo, hay métodos específicos que mejoran la seguridad de los sistemas. En particular, podemos mejorar la confiabilidad de software. Tambien podemos mejorar nuestra comprensión de los requisitos de un pedazo de software.

Buena Práctica

La seguridad requiere más manejo y riesgo de mitigación, de la que requiere la tecnología. Como un desarrollador, uno primero debe de determinar los riesgos de una aplicación particular. Por ejemplo, el Web site típico de hoy puede ser sujeto de una variedad de riesgos; la desfiguración o la negación distribuida de ataques del servicio.

Una vez que se identifiquen los riesgos, identificar medidas de seguridad apropiadas llega a ser manejable. En particular, al definir los requisitos, es importante considerar cómo la aplicación será utilizada. Con ese conocimiento uno puede decidir, si o no, utilizar características complejas como contabilidad, auditoría etc.

Otro asunto potencialmente importante es como soportar el nombramiento del producto. El aumento de los sistemas distribuidos han hecho el nombramiento cada vez más importante. Típicamente, el nombramiento esta manejado por rendezvous: un principal exporta un nombre y lo anuncia en alguna parte, y alguien que desea utilizar el nombre lo busca en los libros y directorios de teléfono. Por ejemplo, en un sistema como el sistema del descubrimiento del recurso, los recursos y los individuos que usan esos recursos deben ser nombrados. A menudo hay cosas buenas y malas con respecto al nombramiento: mientras que el nombramiento puede proporcionar a un nivel de indirección, también puede crear problemas adicionales si los nombres no son estables. Los nombres pueden permitir que los directores desempeñen diversos papeles en un sistema determinado que pueda también ser útil

Confiabilidad de software

La confiabilidad de software significa que un programa particular debe de seguir funcionando en la precencia de errores. Los errores pueden ser relacionados al diseño, a la implementación, a la programacion, o el uso de errores. Asi como los sistemas llegan a ser cada vez mas complejos, aumenta la probabilidad de errores. Como mencionamos, es increiblemente difícil demonstrar que un sistema sea seguro. Ross Anderson dice que la seguridad de computación es como programar la computadora del Satan. Software seguro debe de funcionar abajo de un ataque. Aunque casi todos los software tengan errores, la mayoria de los errores nunca seran revelados debajo de circunstancias normales. Un atacante busca esta debilidad para atacar un sistema.

Muchos de los problemas de la seguridad de hoy son relacionados con el código defectuoso. Por ejemplo, el Morris Internet Worm (el gusano Internet de Morris) utilizó overflow en un programa de UNIX para ganar acceso a las computadoras que ejecutaron el programa. Los ataques de buffer overflow han sido el tipo de ataque más común en las últimos diez años e implican el sobregrabar instrucciones en el programa. Específicamente, una cantidad fija de memoria en la pila, puede ser reservado por el usuario; si la entrada de información del utilizador es más grande que este espacio reservado, el usuario puede sobregrabar los instrucciones de la programa. Si esto se hace cuidadosamente, el usuario puede insertar sus propias instrucciones en el código del programa, así haciendo la máquina receptora realizar operaciones arbitrarias dictados por el atacante. Mientras que tales ataques se pueden prevenir típicamente con bounds checking (revisando el tamaño de la entrada de información antes de copiarla), ésta es una cuestión de práctica de programación que confiamos en que el programador mismo seguirá. El aspecto difícil de buffer overflows es que pueden ocurrir en una gran cantidad de lugares en cualquier programa, y es difícil de prevenir el suceso por todas partes. Este ha sido el caso en el pasado, especialmente, en los últimos 10 años.

"Confiando en la Confianza"

En particular, la lectura de Ken Thompson "Reflections on Trusting Trust" (refleciones en confiar en confianza) nos da a pensar en la integridad de una parte de software. Específicamente, nos enseña un ejemplo donde un compilador de C puede ser hacked por un Trojan horse. Para el propósito de esta demonstración, Thompson inserta su propia versión de UNIX "login" código, cuando un usuario trataba de compilar el código de fuente. El valor de la lectura de Thompson es que no se puede confiar en el código de fuente que no hayas creado tu mismo. Este incluye el código del compilador, del ensamblador, y microcódigos de hardware. Thompson también nos dice que cuando el nivel de los "bugs" llega a un nivel bajo los " fallos de funcionamiento " serán más difíciles de detectar.

De hecho, no tenemos que compilar software para ser víctima del mensage de Thompson. Cada vez que bajamos un programa por internet o instalar software nuevo, confiamos en un número de cosas. Primero, confiamos que la máquina en la que estamos bajando el software es realmente la máquina que demanda ser. Proyectos como Self-Certifying File System han tratado de arreglar este problema. Aunque nos confiemos en que la máquina con la cual estamos hablando es la que pensamos que es, debemos de comprobar que los archivos fueron preparados apropiadamente. Asi como cuado bajamos un programa por internet confiamos en el proceso de desarollo del software.

Mientras que los sistemas de UNIX parece generar mas interés en las comunidades académicas. otros sistemas de operación no son inmunes. Los ataques de buffer overflow son extensos, desde los servidores ftpd de Windows a los procesos ocultados que capturan cada golpe de teclado del usuario. No importa cuánto énfasis ponemos en el diseño y la seguridad de la ingeniería del software, debe de ser una cierta cantidad básica de software y de hardware que no vamos a poder confiar totalmente.

La Negación Distribuida del servicio

Los ataques de la negación distribuida del servicio Distributed denial of service (DDoS) es a menudo la causa de la preocupación ética. Algunas medidas de seguridad se han tomado contra ataques de DDoS, tales como filtración, IP traceback mechanisms mecanismos del traceback del IP, dando el FBI mayores potencias para la búsqueda y el asimiento, a etc., pero más de éstos se usan para la negación estándar de los ataques del servicio, más bien que los ataques de DDoS.

Los ataques de la negación distribuida del servicio DDoS comienzan con un "maestro" que es responsable de comprometer un número de máquinas "esclavas". Estos esclavos son responsables del ataque. A menudo "deamons" están instalados en múltiples ordenadores principales. Un cliente identifica una blanco a los deamons y cada uno de los clientes mandan una negación del ataque del servicio. El problema de DDoS llega a ser mucho más serio mientras que aumente el número de usuarios conectado constantemente con los módems de cable directos Internet o las líneas del DSL. En general, hay menos probabilidad para detectar una intrusión al sistema, así aumentando la probabilidad para ser un esclavo en un ataque de DDoS.

Hasta con el desarollo sistemático del software "seguro", nosotros, como usuarios de computadoras en un mundo de Sistemas de Redes, no operamos en aislamiento -- somos dependientes de los otros, los cuales estan haciendo su parte en desarrollando, diseñando, y utilizando software "seguro".

Recursos


1. http://web2.deskbook.osd.mil/valhtml/2/26/264/264J19.htm
2. "Distributed Tools" http://phrack.infonexus.com/search.phtml?view&article=p56-12
3. http://securityportal.com/articles/webdev20001103.html
4. Practical Support for IP Traceback, SIGCOMM 2000.
5 "A Stealthy Windows Keylogger" http://phrack.infonexus.com/search.phtml?view&article=p56-9
6. Thompson, K , "Reflections on Trusting Trust", Communications of the ACM, Vol. 27, No. 8, August 1984, pp. 761-763.
7. Yahoo DDoS

Biografia Nick Feamster puede ser contactado a feamster@lcs.mit.edu. es un estudiante graduado en las redes y el grupo móvil de los sistemas en el laboratorio para la informática en la investigación actual de MIT.


Last Modified:
Location: www.acm.org/crossroads/espanol/xrds7-4/onpatrol74.html