INTRODUCCION: El concepto de la seguridad en los sistemas de software es un rea de investigacin que ha pasado a ser vital dentro de la Ingeniera de Software.

Con el crecimiento de Internet, y otras aplicaciones sobre redes, como el comercio electrnico, correo electrnico, etc., la posibilidad de ataques se ha incrementado notablemente, como tambin lo han hecho las consecuencias negativas de estos ataques. La seguridad en la Ingeniera de Software es un tema amplio. En este artculo nos vamos a enfocar en la definicin y la discusin de la seguridad de software, confiabilidad del software, la responsabilidad del desarrollador y de la responsabilidad del usuario.

4.1 SEGURIDAD DE SOFTWARE La seguridad de software aplica los principios de la seguridad de informacin al desarrollo de software. Information security (La seguridad de informacin) se refiere a la seguridad de informacin comnmente como la proteccin de sistemas de informacin contra el acceso desautorizado o la modificacin de informacin, si est en una fase de almacenamiento, procesamiento o trnsito. Tambin la protege contra la negacin de servicios a usuarios desautorizados y la provisin 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 cdigo y el proceso de software; deben de ser considerados durante la fase del diseo y desarrollo. Adems, la seguridad debe de ser preservada durante la operacin 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 engaar en la creencia que nuestros trabajos como diseadores de sistema de seguridad ya han sido realizados. Sin embargo, las cadenas y computadoras son increblemente inseguras. La falta de seguridad se origina en dos problemas fundamentales: Los sistemas que son tericamente seguros pueden ser inseguros en la prctica, Adems los sistemas son cada vez ms complejos. La complejidad proporciona ms oportunidades para los ataques. Es mucho ms fcil 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 hazaas posibles puedan ser defendidas contra (muy desalentadora), si no imposible, la tarea Actualmente, no hay ninguna solucin singular para asegurar la ingeniera de software. Sin embargo, hay mtodos especficos que mejoran la seguridad de los sistemas. En particular, podemos mejorar la confiabilidad de software. Tambin podemos mejorar nuestra comprensin de los requisitos de un pedazo de software. Buena Prctica La seguridad requiere ms manejo y riesgo de mitigacin, de la que requiere la tecnologa. Como un desarrollador, uno primero debe de determinar los riesgos de una aplicacin particular. Por ejemplo, el Web site tpico de hoy puede ser sujeto de una variedad de riesgos; la desfiguracin o la negacin 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 cmo la aplicacin ser utilizada. Con ese conocimiento uno puede decidir, s o no, utilizar caractersticas complejas como contabilidad, auditora etc. Otro asunto potencialmente importante es como soportar el nombramiento del producto. El aumento de los sistemas distribuidos ha hecho el nombramiento cada vez ms importante. Tpicamente, 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 telfono. 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 indireccin, tambin puede crear problemas adicionales si los nombres no son estables. Los nombres pueden permitir que los directores desempeen diversos papeles en un sistema determinado que pueda tambin ser til

La Negacin Distribuida del servicio Los ataques de la negacin distribuida del servicio Distributed denial of service (DDoS) es a menudo la causa de la preocupacin tica. Algunas medidas de seguridad se han tomado contra ataques de DDoS, tales como filtracin, IP traceback mechanisms mecanismos del traceback del IP, dando el FBI mayores potencias para la bsqueda y el asimiento, a etc., pero ms de stos se usan para la negacin estndar de los ataques del servicio, ms bien que los ataques de DDoS. Los ataques de la negacin distribuida del servicio DDoS comienzan con un "maestro" que es responsable de comprometer un nmero de mquinas "esclavas". Estos esclavos son responsables del ataque. A menudo "deamons" estn instalados en mltiples ordenadores principales. Un cliente identifica una blanco a los deamons y cada uno de los clientes mandan una negacin del ataque del servicio. El problema de DDoS llega a ser mucho ms serio mientras que aumente el nmero de usuarios conectado constantemente con los mdems de cable directos Internet o las lneas del DSL. En general, hay menos probabilidad para detectar una intrusin al sistema, as aumentando la probabilidad para ser un esclavo en un ataque de DDoS. Hasta con el desarrollo sistemtico 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 estn haciendo su parte en desarrollando, diseando, y utilizando software "seguro". 4.2 SEGURIDAD EN EL CICLO DE DESARROLLO DE SOTFWARE. Generalmente, la seguridad en el desarrollo software no est enfocada desde una perspectiva holstica. La razn raz es que en la mayora de los casos la seguridad se establece al final del ciclo del proyecto como consecuencia de la aparicin de una nueva amenaza o de un nuevo riesgo. Por tanto, estas urgencias desembocan en la bsqueda de soluciones que no atienden al sistema en su conjunto (interaccin en entre sistemas). Si tenemos en cuenta que estudios realizados apuntan a que ms del 70% de las vulnerabilidades de seguridad existentes provienen de la capa de aplicaciones, es un motivo ms que suficiente para preocuparse y ponerse manos a la obra. Por este motivo, se oye cada ms de la integracin de la seguridad en el ciclo de desarrollo de software (SDLC). Existen varias metodologas y certificaciones (ASAP, ISECOM, CSSLP, etc.) e incluso hay quien desarrolla sus propios mtodos. Teniendo todos en comn, el tener en cuenta todo el ciclo de desarrollo, desde el anlisis hasta la puesta en servicio, pasando por los test y cerrando el ciclo con la fase de soporte y mejora del sistema. En cualquier caso, la caracterstica comn ms importante de todas ellas, es sin duda alguna, un enfoque sistmico que les permite analizar el sistema

en su conjunto. Podemos concluir que introduciendo criterios de seguridad desde las fases ms tempranas del desarrollo, nos ayudar a obtener aplicaciones ms seguras a un coste ms bajo. 4.3 CONFIABILIDAD DE SOFTWARE La confiabilidad de software significa que un programa particular debe de seguir funcionando en la presencia de errores. Los errores pueden ser relacionados al diseo, a la implementacin, a la programacin, o el uso de errores. As como los sistemas llegan a ser cada vez ms complejos, aumenta la probabilidad de errores. Como mencionamos, es increblemente difcil demonstrar que un sistema sea seguro. Ross Anderson dice que la seguridad de computacin es como programar la computadora del Satan. Software seguro debe de funcionar abajo de un ataque. Aunque casi todo el software tenga errores, la mayora de los errores nunca sern 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 cdigo 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 ms comn en los ltimos diez aos e implican el sobregrabar instrucciones en el programa. Especficamente, una cantidad fija de memoria en la pila, puede ser reservado por el usuario; si la entrada de informacin del utilizador es ms 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 cdigo del programa, as haciendo la mquina receptora realizar operaciones arbitrarias dictados por el atacante. Mientras que tales ataques se pueden prevenir tpicamente con bounds checking (revisando el tamao de la entrada de informacin antes de copiarla), sta es una cuestin de prctica de programacin que confiamos en que el programador mismo seguir. El aspecto difcil de buffer overflows es que pueden ocurrir en una gran cantidad de lugares en cualquier programa, y es difcil de prevenir el suceso por todas partes. Este ha sido el caso en el pasado, especialmente, en los ltimos 10 aos. "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. Especficamente, nos ensea un ejemplo donde un compilador de C puede ser hacked por un Trojan horse. Para el propsito de esta demonstracin, Thompson inserta su propia versin de UNIX "login" cdigo, cuando un usuario trataba de compilar el cdigo de fuente. El valor de la lectura de Thompson es que no se puede confiar en el cdigo de fuente que no hayas creado t mismo. Este incluye el cdigo del compilador, del ensamblador, y microcdigos de hardware. Thompson tambin nos dice que cuando el nivel de los "bugs" llega a un nivel bajo los " fallos de funcionamiento " sern ms difciles de detectar. De hecho, no tenemos que compilar software para ser vctima del mensage de Thompson. Cada vez que bajamos un programa por internet o instalar software nuevo, confiamos en un nmero de cosas. Primero, confiamos que la mquina en la que estamos

bajando el software es realmente la mquina que demanda ser. Proyectos como Self-Certifying File System han tratado de arreglar este problema. Aunque nos confiemos en que la mquina con la cual estamos hablando es la que pensamos que es, debemos de comprobar que los archivos fueron preparados apropiadamente. As como cundo bajamos un programa por internet confiamos en el proceso de desarrollo del software. Mientras que los sistemas de UNIX parece generar ms inters en las comunidades acadmicas. Otros sistemas de operacin 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 cunto nfasis ponemos en el diseo y la seguridad de la ingeniera del software, debe de ser una cierta cantidad bsica de software y de hardware que no vamos a poder confiar totalmente. 4.4 INGENIERIA DE SEGURIDAD Qu es Ingeniera de Seguridad? La historia anterior muestra cuan compleja y sofisticada se ha vuelto nuestra vida. En tan solo dos horas el personaje de nuestra historia a realizado al menos diez operaciones riesgosas. Veamos algunas de las cosas que pudieron haber sucedido: 1. Al usar el control remoto para desactivar la alarma un ladrn, oculto en el estacionamiento graba la seal electrnica enviada por el control para luego replicarla y poder abrir sin ningn problema el carro. 2. Una vez dentro del carro, la llave, al ser introducida en el switche de ignicin enva una seal electrnica, recibe otra a la cual responde y finalmente el motor acepta la llave como autentica ya autorizada para encender el motor. (Mala cosa para el ladrn si no fuera porque Juan Precavido es lo suficientemente descuidado como para haber perdido una de las llaves de su carro hace un mes, sin haberse percatado de ello). 3. Al salir del estacionamiento usa el otro control para abrir la puerta, por supuesto nuestro ladrn tambin graba esta seal para luego abrir la puerta del estacionamiento, cuando pretenda sacar el carro. 4. Cuando paga en el restaurante entrega su tarjeta de crdito. El mesonero lleva la tarjeta adentro y sin que Juan lo vea, pasa la cinta magntica por un dispositivo que le permite grabar la informacin de la cinta. Por otro lado toma nota de los nmeros y datos que aparecen en la misma. 5. Cuando ingresa en su oficina no se percata que al acercar la tarjeta magntica a la puerta un nuevo software instalado para controlar la productividad de sus empleados est grabando sus entradas y salidas de la oficina (este es ms un problema de privacidad que de seguridad).

6. Enciende su computadora y al dar el login y el password nota que extraamente la pantalla de login apareci dos veces, as que introduce la informacin dos veces. Raro, las computadoras nunca fallan. En este caso un hacker logro ingresar a su computadora y sustituyo el login original por un falso login para poder ingresar a los sistemas de la compaa. 7. Aun cuando se hubiera percatado de ello, desafortunadamente la empresa enva la informacin del password y el login a travs de la red sin encriptar. Nuestro hacker ya logr ingresar a otra cuenta e instal un sniffer que recolecta login y passwords de toda la gente que hace login en la red local. 8. Al ingresar a la pgina del banco no se percata que la informacin no est siendo encriptada. Definiciones. Un producto o componente, como es el caso de un protocolo criptogrfico, una smartcard o el hardware de un PC. Una coleccin de componentes como los antes mencionados ms un sistema operativo, de comunicaciones, y algunos otros componentes que constituyen la infraestructura de una organizacin. Lo antes descrito ms una o ms aplicaciones (contabilidad, cuentas por pagar, etc). Lo anterior ms el personal de IT. Lo anterior ms usuarios internos y gerentes. Lo anterior ms clientes y otros usuarios externos. Lo anterior ms el entorno incluyendo la media, competidores, reguladores y polticos. Por un sujeto entenderemos un persona fsica en cualquier rol, incluyendo el de operador, vctima, etc. Por una persona entenderemos tanto un sujeto como una persona legal (una compaa o un gobierno). Un principal es una entidad que participa en un sistema de seguridad. Esa entidad puede ser un sujeto, una persona, un rol o una pieza de equipo (PC, SmartCard, etc). Un grupo es un conjunto de principales. Un rol es una funcin asumida por diferentes personas.

CONCLUSION Nuestro anlisis nos permite concluir que la POA es una prometedora alternativa para solucionar los problemas actuales de la seguridad en el software. Como se ve en los casos de estudio analizados en este trabajo, la POA es til tanto para especificar cuestiones de seguridad de bajo nivel, solucionando las fallas para implementar software seguro, como tambin para definir cuestiones de seguridad de alto nivel, solucionando fallas para implementar seguridad en el software. Adems, por las caractersticas propias de la programacin orientada a aspectos, las aplicaciones desarrolladas bajo este paradigma satisfacen naturalmente los objetivos propuestos. REFERENCIAS. [1] Doshi Shreyas, Software Engineering for Security: Towards Architecting Secure Software, Information and Computer Science Dept., University of California, Irvine, CA 92697,USA., abril de 2001. [2] David Evans, Andrew Twyman, Flexible Policy-Directed Code Safety, in Proceedings of the 1999 IEEE Symposium on Security and Privacy. IEEE 1999. [3]http://web2.deskbook.osd.mil/valhtml/2/26/264/264J19.htm [4] "Distributed Tools" http://phrack.infonexus.com/search.phtml?view&article=p5612 [5] http://securityportal.com/articles/webdev20001103.html