Reporte Seguridad en La Ingeniería de SW

PROFESORA
M.T.I. MONTSERRAT MASDEFIOL SUREZ
CARRERA
ING. EN SISTEMAS COMPUTACIONALES
MATERIA
INGENIERA DE SOFTWARE
TRABAJO
SEGURIDAD EN INGENIERA DE SOFTWARE
INTEGRANTES DE EQUIPO: ANTELE SIXTEGA IVAN ARRISON PARRA JAVIER DEL ANGEL ATAXCA MAZABA MARTN IXBA GONZALEZ CRUZ OMAR IXTEPAN CANSINO ANA MARIA MACHUCHO GOMEZ VICTOR MALAGA DOMINGUEZ MARIANELA MARTINEZ MARCIAL ABRAHAM ALEXIS MENDOZA RODRIGUEZ ARMANDO SERRANO BLAS EPIFANIO TOM ANTEMATE DAVID VALERIO GOMEZ SHEILA DE JESUS XALA BUSTAMANTE OCTAVIO ARTEMIO XOLO CHIGO ROCIO GRUPO
604 A SAN ANDRS TUXTLA, VER., 24 DE MAYO DEL 2013.
SEGURIDAD EN INGENIERA DE SOFTWARE NDICE
INTRODUCCIN .................................................................................................... 4 SEGURIDAD EN EL CICLO DE DESARROLLO DEL SOFTWARE ....................... 5 Seguridad en el anlisis de requerimientos .................................................. 5 Seguridad en el diseo ................................................................................. 6 Seguridad en la codificacin ......................................................................... 6 Testing / QA de seguridad ............................................................................ 7 Implementacin / puesta en produccin ....................................................... 9 Ventajas ............................................................................................. 9 Desventajas ....................................................................................... 9 Seguridad en el desarrollo de software....................................................... 10 Papel de seguridad en el desarrollo de software. ....................................... 11 CONFIABILIDAD DEL SOFTWARE...................................................................... 12 PRUEBAS DE CONFIABILIDAD ........................................................................... 16 Tipos de Pruebas de Confiabilidad ............................................................. 16 De Componentes ............................................................................. 17 Pruebas de Estrs ............................................................................ 17 De Integracin .................................................................................. 17 Pruebas de estrs de componentes ................................................. 17 Pruebas de estrs de integracin ..................................................... 17 Pruebas de Reales y Destruccin .................................................... 18 Pruebas de Integracin .................................................................... 19 Pruebas Estructurales ...................................................................... 19 INGENIERA DE SEGURIDAD ............................................................................. 20
M.T.I. MONTSERRAT MASDEFIOL SUREZ.
Pgina 2

ATAQUE DE SEGURIDAD ................................................................................... 24 Servicios de seguridad................................................................................ 26 Mecanismos de implementacin ................................................................. 27 Generales ......................................................................................... 27 Especficos ....................................................................................... 27 PROTECCIN ...................................................................................................... 28 Criptografa ................................................................................................. 32 Criptoanlisis .............................................................................................. 33 Trabajo relacionado .................................................................................... 35 Proceso software seguro ............................................................................ 36 Descripcin semntica de los elementos de seguridad.................... 36 Proceso de desarrollo de software para la seguridad ...................... 37 Extensin de uml con requisitos de seguridad ................................. 38 Integracin de requisitos de seguridad en modelos software ........... 39 CONCLUSIN ...................................................................................................... 40 BIBLIOGRAFA ..................................................................................................... 41
Pgina 3
SEGURIDAD EN INGENIERA DE SOFTWARE INTRODUCCIN

En la actualidad al llevar a cabo el desarrollo de un sistema, un punto esencial es la seguridad, ya que dentro de las etapas de desarrollo, se debern formular las posibles medidas de seguridad que se tomarn en cuenta para brindar una mayor efectividad del sistema, por otra parte dentro del desarrollo de software se requiere de la realizacin sistemtica de las actividades de planeacin, diseo, codificacin y pruebas, que permitan mejorar la calidad del producto desarrollado, as como poder tener una confiabilidad de ste. El manejo y administracin de la informacin tomando en cuenta la aparicin de las nuevas tecnologas de informacin y comunicacin se ha convertido en una de las tendencias abordadas por los sistemas de informacin, donde es imprescindible adentrarse en la parte de seguridad en ingeniera de software el cual se ha convertido en una problemtica ante la cual se enfrentan los desarrolladores, convirtindose en el componente generador de integridad en el manejo de la informacin. Por lo tanto la ingeniera de seguridad son los mtodos para disear y construir sistemas que permanezcan confiables a pesar de posibles actos maliciosos o a errores de diversos tipos. En la presente investigacin se abordarn los temas de seguridad en el ciclo de desarrollo del software que se refiere a la proteccin de sistemas de informacin contra el acceso desautorizado o la modificacin de informacin, la confiabilidad del software la cual se define a que todo sistema opere sin fallas bajo condiciones establecidas por un periodo de tiempo determinado, asimismo, la descripcin de cada uno de los componentes que posee la confiabilidad, y por ltimo en la Ingeniera de seguridad se tratar la seguridad, la proteccin contra los sistemas de informacin, definicin de ingeniera de seguridad, as mismo algunas herramientas que permiten la proteccin de los sistemas de software, adems de algunos ataques de seguridad que existen en los sistemas de informacin.
Pgina 4
SEGURIDAD EN INGENIERA DE SOFTWARE SEGURIDAD EN EL CICLO DE DESARROLLO DEL SOFTWARE

La mayor parte de las organizaciones desarrolla o contrata el desarrollo de aplicaciones propias para su gestin de negocio. Como todo software, estas aplicaciones pueden contener fallas de seguridad y a diferencia del software comercial, no se dispone de actualizaciones o parches liberados en forma peridica por el fabricante. El tratamiento de las vulnerabilidades en aplicaciones propias corre por parte de la organizacin que las desarrolla. Est comprobado que cunto ms temprano se encuentre una falla de seguridad en el ciclo de vida del desarrollo de software, ms rpida y econmica ser su mitigacin. Cul es el rumbo a seguir? Las buenas prcticas indican la conveniencia de incluir seguridad de la informacin desde el principio y a lo largo de todas las etapas del ciclo de vida de desarrollo, conocido como SDLC (Software Development Life Cicle). Estas etapas pueden variar segn la modalidad de cada organizacin, pero a grandes rasgos son las siguientes: anlisis de requerimientos, diseo funcional y detallado, codificacin, testing/QA, implementacin/puesta en produccin.
SEGURIDAD EN EL ANLISIS DE REQUERIMIENTOS
En esta etapa, se deben identificar aquellos requerimientos funcionales que tendrn impacto en los aspectos de seguridad de la aplicacin. Algunos de ellos son: requerimientos de conformidad con normativas locales o internacionales, tipo de informacin que se transmitir o procesar (por ejemplo: la Informacin pblica o confidencial, datos personales, datos financieros, contraseas, datos de pago electrnico, etc.) y requerimientos de registros de auditora (por ejemplo: qu debe registrar la aplicacin en sus Logs).
Pgina 5

SEGURIDAD EN EL DISEO
Antes de comenzar a escribir lneas de cdigo, hay numerosos aspectos de seguridad que se deben tener en cuenta durante el diseo de la aplicacin. Algunos de ellos son: diseo de autorizacin (como definir los roles, permisos y privilegios de la aplicacin), diseo de autenticacin (se deber disear el modo en el que los usuarios se van a autenticar, contemplando aspectos tales como los mecanismos o factores de autenticacin con contraseas, tokens, certificados, etc. posibilidades de integrar la autenticacin con servicios externos como LDAP, Radius o Active Directory) y los mecanismos que tendr la aplicacin para evitar ataques de diccionario o de fuerza bruta (algunos de ejemplos son bloqueo de cuentas, implementacin de captchas, etc.), diseo de los mensajes de error y advertencia, para evitar que los mismos brinden demasiada informacin y que sta sea utilizada por atacantes y diseo de los mecanismos de proteccin de datos (se debe contemplar el modo en el que se proteger la informacin sensible en trnsito o almacenada; segn el caso, se puede definir la implementacin de encripcin, hashes o truncamiento de la informacin).
Una vez que se cuenta con el diseo detallado de la aplicacin, una prctica interesante es la de realizar sobre el mismo un anlisis de riesgo orientado a software. Existen tcnicas documentadas al respecto, tales como Threat Modeling. Estas tcnicas permiten definir un marco para identificar debilidades de seguridad en el software, antes de la etapa de codificacin. Como valor agregado, del anlisis de riesgo orientado a software se pueden obtener casos de prueba para ser utilizados en la etapa de Testing/QA. SEGURIDAD EN LA CODIFICACIN
Una vez concluido el diseo, los desarrolladores tendrn que codificar los distintos componentes de la aplicacin. Es en este punto en donde suelen incorporarse, por error u omisin, distintos tipos de vulnerabilidades. Estas
M.T.I. MONTSERRAT MASDEFIOL SUREZ. Pgina 6

vulnerabilidades se pueden dividir en dos grandes grupos: vulnerabilidades clsicas y vulnerabilidades funcionales. Las primeras son bien conocidas y categorizadas. Ejemplo de estas vulnerabilidades son las presentes en el OWASP Top 10 (Vulnerabilidades de inyeccin, Cross Site Scripting, errores en manejo de sesiones, etc.), como as tambin otras vulnerabilidades no ligadas directamente con las aplicaciones WEB, como desbordamiento de buffer, denegacin de servicio, etc. Los Frameworks de desarrollo de aplicaciones son una buena ayuda en este punto, ya que ofician de intermediario entre el programador y el cdigo, y permiten prevenir la mayora de las vulnerabilidades conocidas. Ejemplos de estos frameworks son Struts, Ruby on Rails y Zope.
Las vulnerabilidades funcionales son aquellas ligadas especficamente a la funcionalidad de negocio que posee la aplicacin, por lo que no estn previamente categorizadas. Algunos ejemplos ilustrativos de este tipo de vulnerabilidad son los siguientes: una aplicacin de banca electrnica que permite realizar transferencias con valores negativos, un sistema de subastas que permite ver los valores de otros oferentes, un sistema de venta de entradas para espectculos que no impone lmites adecuados a la cantidad de reservas que un usuario puede hacer. En la etapa de codificacin, una de las reglas de oro es verificar todos los valores de entrada y de salida. Esto es, asumir siempre que el valor pudo haber sido manipulado o ingresado maliciosamente antes de ser procesado. TESTING / QA DE SEGURIDAD
Tradicionalmente, la labor del equipo de Testing/QA es la de encontrar y reportar errores funcionales de la aplicacin. Para esto, se desarrollan casos de test basados en la funcionalidad esperada.
A esto se le denomina testing funcional y bsicamente consiste en validar que la aplicacin haga lo que se esperaba que hiciera. Sucede que habitualmente hay un desfasaje entre el diseo original de la aplicacin (lo que se espera que
Pgina 7

haga) y la implementacin real (lo que realmente hace). Aqu surgen tres reas bien definidas: lo que fue definido y la aplicacin hace, lo que fue definido y la aplicacin no hace (errores funcionales) y lo que no fue definido pero la aplicacin hace.
Es en este ltimo grupo, en donde habitualmente estn las vulnerabilidades, y el testing funcional clsico no es capaz de encontrarlas. Por este motivo se necesitan nuevas tcnicas para explorar lo desconocido. El testing de seguridad se basa principalmente en probar la aplicacin con escenarios no planificados, incluyendo valores mutados, fuera de rango, de tipo incorrecto o malformados, acciones fuera de orden, etc.
Existen herramientas automticas que pueden ayudar al analista de QA en la bsqueda de errores. Las mismas son tiles por su velocidad y capacidad de automatizacin, pero pueden causar falsos positivos, y por lo general no son buenas detectando vulnerabilidades funcionales. Es por esto que los mejores resultados resultan de la combinacin de tcnicas automticas y manuales.
Pgina 8

IMPLEMENTACIN / PUESTA EN PRODUCCIN
Una mala configuracin al momento de implementar la aplicacin podra echar por tierra toda la seguridad de las capas anteriores. Tanto la aplicacin como el software de base deben configurarse de manera segura al momento de poner el software en produccin. En este punto se deben contemplar tareas tales como: cambio de usuarios y contraseas iniciales o por defecto, borrado de datos de prueba y cambio de permisos de acceso. Es tambin importante mantener una correcta separacin de los ambientes de desarrollo, testing y produccin y procedimientos de traspaso seguro de uno a otro de estos ambientes. VENTAJAS Consistencia. La herramienta ve lo que ve, sin ideas preconcebidas. Apuntan a la causa raz, no a los sntomas. Una prueba de penetracin puede establecer que hay un problema, pero no su causa final ni cmo corregirlo. Deteccin precoz. La aplicacin no tiene que estar integrada ni necesita ejecutarse. Su ejecucin es barata. Un sistema puede reanalizarse cuando se aplican cambios, o cuando se descubre una nueva vulnerabilidad de aplicacin. DESVENTAJAS Falsos positivos. Impacto (coste) crece al tener que evaluar cada positivo. Falsos negativos. Suelen ser incapaces de detectar vulnerabilidades de seguridad achacables al diseo, o especficas del contexto propio de la aplicacin (se centran en vulnerabilidades genricas, de codificacin). Qu es mejor? En seguridad, sin duda, baja tasa de falsos negativos sin una tasa desproporcionada de falsos positivos.
Pgina 9
SEGURIDAD EN EL DESARROLLO DE SOFTWARE Cuando el desarrollador realiza algn tipo de sistema software sin importar cul sea la finalidad que vaya a tener el mismo, es importante que se tomen algunos recaudos, ya que al tratarse de un sistema tan delicado, es importante que se tenga en cuenta que en cualquier momento puede sufrir alguna falla en su funcionamiento. Generalmente la seguridad en el desarrollo de software es tan importante como cuando se est ejecutando ya que lgicamente, para poder desarrollarlo, se requiere de un sistema operativo especial, el cual tambin est en riesgo. Se dice eso porque durante el desarrollo de programas, siempre se deben realizar diferentes tipos de pruebas, y son precisamente estas ejecuciones a prueba las que ponen el riesgo el sistema que se est utilizando en general. Pero es importante que se destaque el hecho de que existen sistemas de seguridad que se utilizan especialmente para proteger a los sistemas operativos sobre los cuales se realizan pruebas durante el desarrollo de software, y solo es cuestin de averiguar cul es el ms indicado en el caso de que se est trabajando en esta rea. Las tiendas de informtica suelen tener varios sistemas de seguridad para el desarrollo de software, los cuales son muy variados, y generalmente traen diferentes aplicaciones segn las necesidades y
requerimientos de la persona que est trabajando sobre un software. Tambin es importante tener en cuenta el asesoramiento de personas especializadas en los sistemas de seguridad ya que las aplicaciones son totalmente diferentes para cada uno de los casos. Por otro lado es muy importante
Pgina 10

hacer hincapi en el hecho de que es esencial que cuando se trata de la seguridad en el desarrollo de software nunca se busque en Internet, es decir que la descarga de este tipo de programas, ya sean antivirus o de cualquier otro tipo, sean descargados desde una pgina Web online. Esto es principalmente porque se tiene que tener en cuenta que el campo de desarrollo de software es bastante competitivo, y ms de una vez ha pasado que por haberse infiltrado algn tipo de virus para el espionaje o el robo de informacin, y justamente este tipo de virus suelen estar en archivos en Internet que prometen la seguridad en el desarrollo del software, por eso es suma importancia cuidarse de este tipo de problemas, sin importar cuan tentador pueda llegar a ser, adquirir la seguridad para el desarrollo de software de manera gratuita. PAPEL DE SEGURIDAD EN EL DESARROLLO DE SOFTWARE. Para que se pueda entender de qu manera trabaja un sistema de seguridad en el desarrollo de software se dice que generalmente evita que se produzcan errores generales en los sistemas operativos que se utilizan tanto para el desarrollo del mismo, como para las pruebas piloto del funcionamiento del software. Al tratarse de un prototipo de prueba, es muy comn que se produzcan fallas permanentemente, y que esto pueda afectar al sistema, adems, se debe decir que las fallas en el sistema de software que se est desarrollando necesitan ser ejecutadas para poder corregirlas, ya que de otro modo, no se podra desarrollar ningn tipo de programa que tenga fallas al ejecutarlo. Por eso, tomando en cuenta que las fallas deben existir aunque las mismas pongan en riesgo el funcionamiento del sistema en general, se debe siempre contar con algn programa de seguridad para evitar que las mismas produzcan un dao mayor. En el caso de que se est trabajando online, el programa de seguridad en el desarrollo de software que se est utilizando, debe tambin ser a prueba de virus informticos, especialmente de aquellos que roban la informacin o daan el sistema operativo imposibilitando a quien est trabajando que contine con su actividad.
Pgina 11
SEGURIDAD EN INGENIERA DE SOFTWARE CONFIABILIDAD DEL SOFTWARE

A veces los sistemas informticos caen y no consiguen realizar los servicios que se les ha requerido. Los programas que se ejecutan sobre dichos sistemas pueden no funcionar como se esperaba y, ocasionalmente, pueden corromper los datos que son gestionados por el sistema. Se ha aprendido a vivir con este tipo de fallos, y pocas personas confan plenamente en las computadoras personales que normalmente usan. La confiabilidad de un sistema informtico es una propiedad del sistema que es igual a su fidelidad. La fidelidad esencialmente significa el grado de confianza del usuario en que el sistema operar tal y cmo se espera de l y que no fallar al utilizarlo normalmente. Es la probabilidad de operacin libre de fallas de un programa de computadora en un entorno determinado y durante un tiempo especfico. El fallo es cualquier no concordancia con los requerimientos del software. Hay distintos grados de fallos, estos pueden ser simplemente desconcertantes o catastrficos. La confiabilidad del software se encuentra en una etapa de formacin de desarrollo y es la caracterstica de rendimiento ms costosa y difcil de conseguir y garantizar. La naturaleza del proyecto ayuda para la formulacin de estimaciones de costo y el esfuerzo que asegure la confiabilidad requerida. Los modelos de confiabilidad del software se usan para caracterizar y predecir el comportamiento importante para directores e ingenieros. La generacin de fallos depende del cdigo desarrollado, tales como tamao y las caractersticas del proceso de desarrollado como las tecnologas y herramientas de ingeniera de software usadas. La eliminacin de fallos depende del tiempo y del perfil operativo. Los modelos de confiabilidad del software son generalmente procesos aleatorios. Estos modelos se pueden dividir en dos grandes categoras:
Pgina 12

Modelos que predicen la confiabilidad como una funcin cronolgica del tiempo. Modelos que predicen la confiabilidad como una funcin del tiempo de procesamiento transcurrido. Esta propiedad no se puede expresar numricamente, sino que se utilizan trminos relativos como no confiables, muy confiables y ultraconfiables para reflejar los grados de confianza que se pueden tener en un sistema. Existen cuatro dimensiones principales de la confiabilidad: Disponibilidad. La disponibilidad de un sistema es la probabilidad de que este activo y en funcionamiento y sea capaz de proporcionar servicios en cualquier momento. Fiabilidad. La fiabilidad de un sistema es la probabilidad de que durante un determinado periodo de tiempo, el sistema funcione correctamente tal y como espera el usuario. Seguridad. La seguridad de un sistema es una valoracin de la probabilidad de que el sistema cause daos a las personas o a su entorno. Proteccin. La proteccin de un sistema es una valoracin de la probabilidad de que el sistema pueda resistir al mal uso o ataques de intrusos.
Figura 1.1
Pgina 13

Las propiedades anteriores, tambin expresadas de una manera grfica (ver Figura 1.1), pueden descomponerse a su vez en otras propiedades ms simples. Por ejemplo, la proteccin incluye la integridad (asegurar que el programa y los datos de los sistemas no resultan daados) y la confidencialidad (asegurar que solo las personas autorizadas puedan acceder a la informacin). La fiabilidad incluye la correccin (asegurar que los servicios que proporciona el sistema son los que se han especificado), precisin (asegurar que la informacin se proporciona al usuario con el nivel de detalle adecuado), y oportunidad (asegurar que la informacin que proporciona el sistema se hace cuando es requerida). Las propiedades de la confiabilidad ya mencionadas como son la disponibilidad, seguridad, fiabilidad y proteccin estn interrelacionadas. El funcionamiento de un sistema seguro depende normalmente de que el sistema est disponible y su funcionamiento sea fiable. Un sistema puede convertirse en no fiable debido a que sus datos han sido corrompidos por algn intruso. Los ataques de denegacin de servicio en un sistema tienen como propsito comprometer su disponibilidad. Si un sistema que ha demostrado ser seguro es infectado por un virus, ya no se le puede suponer un funcionamiento seguro. Estas interrelaciones entre las cuatro propiedades son la razn de introducir la nocin de confiablidad como una propiedad que las engloba. Adems de estas cuatro dimensiones principales, tambin se pueden considerar otras propiedades del sistema incluidas en el trmino confiabilidad: Reparabilidad: Los fallos de funcionamiento del sistema son inevitables, pero la interrupcin causada por estos fallos se puede minimizar si el sistema se puede reparar rpidamente. La reparabilidad del software se mejora cuando se tiene acceso al cdigo fuente y se tiene personal con destreza y capacidad para realizar cambios sobre l. Mantenibilidad: A medida que se usan los sistemas, surgen nuevos requerimientos. Es importante mantener la utilidad de un sistema cambindolo para adaptarlo a estos nuevos requerimientos. Un software

mantenible es un software que puede adaptarse para tener en cuenta los nuevos requerimientos con un coste razonable y con una baja probabilidad de introducir nuevos errores en el sistema al realizar los cambios correspondientes. Supervivencia: La supervivencia es la capacidad de un sistema para continuar ofreciendo su servicio mientras est siendo atacado y, potencialmente, mientras parte del sistema est inhabilitado. Las tareas de supervivencia se centran en la identificacin de componentes del sistema clave y en asegurar que estos pueden ofrecer un servicio de funcionamiento mnimo. Se utilizan tres estrategias para asegurar que el sistema pueda continuar funcionando con un servicio mnimo, a saber: resistencia al ataque, reconocimiento del ataque y recuperacin de daos ocasionados por un ataque. Tolerancia a errores: Esta propiedad refleja hasta qu punto el sistema ha sido diseado para evitar y tolerar un error en la entrada de datos del usuario al sistema. Cuando se producen errores por parte del usuario, el sistema deber, en la medida de lo posible, detectar estos errores y repararlos de forma automtica o pedir al usuario que vuelva a introducir sus datos. Los diseadores normalmente deben buscar un equilibrio entre el rendimiento del sistema y su confiabilidad. Por lo general, niveles altos de
confiabilidad solamente pueden alcanzarse a costa del rendimiento del sistema. Un software confiable incluye cdigo extra, a menudo redundante, para realizar las comprobaciones necesarias para estados excepcionales del sistema y para recuperar el sistema ante un fallo. Esto reduce la confiabilidad del sistema e incrementa la cantidad de memoria requerida por el software. Adems, tambin se incrementan de forma significativa los costos del desarrollo del sistema. Debido al diseo adicional, implementacin y costos de validacin, el incremento de la confiabilidad de un sistema puede hacer crecer
Pgina 15

significativamente los costos de desarrollo. En particular, los costos de validacin son elevados para los sistemas crticos. Adems de validar que el sistema cumple con sus requerimientos, el proceso de validacin tiene que comprobar que el sistema es confiable a travs de un sistema de regulacin externo. Cuanto mayor sea la confiablidad que se necesita, mas habr que gastar en probar y chequear que efectivamente se ha alcanzado dicho nivel de confiabilidad. Debido al carcter exponencial de la curva coste/confiabilidad, no es posible demostrar que un sistema es totalmente confiable, ya que los costes necesarios para asegurar esto podran ser infinitos.
PRUEBAS DE CONFIABILIDAD
La comprobacin de la confiabilidad consiste en probar una aplicacin para descubrir y eliminar errores antes de que se implemente el sistema. Puesto que hay infinidad de combinaciones distintas de recorridos alternativos a lo largo de una aplicacin, no es muy probable que encuentre todos los errores posibles de una aplicacin compleja. No obstante, puede probar las situaciones ms probables bajo condiciones normales de uso y confirmar que la aplicacin proporciona el servicio previsto. Si dispone de tiempo suficiente, puede realizar pruebas ms complicadas para detectar defectos menos evidentes. TIPOS DE PRUEBAS DE CONFIABILIDAD De Componentes. Pruebas de Estrs. De Integracin. Pruebas Reales. Pruebas de Confiabilidad. Pruebas de Destruccin Aleatoria. Pruebas de Integracin. Pruebas Estructurales.
Pgina 16

DE COMPONENTES La idea es forzar cada componente de forma aislada ms de lo que la aplicacin podra experimentar en condiciones normales. Por ejemplo: usar un bucle de 1 a 10.000.000 lo ms rpidamente posible y observar si hay problemas evidentes. PRUEBAS DE ESTRS Consisten en la simulacin de grandes cargas de trabajo para observar de qu forma se comporta la aplicacin ante situaciones de uso intenso. DE INTEGRACIN Estn relacionadas con las interacciones con otras estructuras de datos, procesos y servicios tanto de los componentes internos y externos de la
aplicacin. Es necesario conocer los recorridos codificados y las situaciones a las que se enfrenta el usuario y que se identifiquen todas las maneras en las que el usuario se mueve por la aplicacin. PRUEBAS DE ESTRS DE COMPONENTES Con las pruebas de estrs de los componentes, se aslan los servicios y componentes que conforman el sistema, se infieren los mtodos de navegacin, de funcionamiento y de interfaz de estos servicios y componentes y se crea un cliente de prueba que llame a dichos mtodos. Para aquellos mtodos que tienen acceso a un servidor de base de datos o a cualquier otro componente, puede crear un cliente que proporcione datos simulados en el formato previsto. El equipo de prueba inserta datos simulados una y otra vez mientras observa los resultados. PRUEBAS DE ESTRS DE INTEGRACIN Despus de forzar cada componente individual, deber someter a una situacin de estrs a toda la aplicacin con todos sus componentes y servicios. Las pruebas de estrs de integracin estn ntimamente relacionadas con las interacciones con otras estructuras de datos, procesos y servicios tanto de los componentes internos como de otros servicios externos de la aplicacin. Las

pruebas de integracin comienzan con una comprobacin bsica del
funcionamiento. Es necesario que conozca los recorridos codificados y las situaciones a las que se enfrentan los usuarios, que comprenda lo que intentan hacer estos y que identifique todas las maneras en las que el usuario se mueve por la aplicacin. Las secuencias de comandos de prueba debern probar la aplicacin de acuerdo con el uso previsto. PRUEBAS DE REALES Y DESTRUCCIN Pruebas Reales: El software que es confiable de forma aislada en un entorno de prueba protegido puede no serlo en la implementacin real. Un entorno de prueba real garantiza que las aplicaciones simultneas no interfieren entre s. Debe asegurarse de que la nueva aplicacin puede ejecutarse con la configuracin final. Pruebas de destruccin aleatorias Una de las formas ms sencillas de probar la confiabilidad es utilizar datos de entrada aleatorios. Este tipo de pruebas intenta por todos los medios bloquear la aplicacin o que sta produzca errores; para ello, se proporcionan datos ilgicos y falsos. Los datos de entrada pueden ser eventos del mouse (ratn) o del teclado, secuencias de mensajes del programa, pginas Web, cachs de datos o cualquier otra condicin de entrada que pueda introducirse en la aplicacin. Deber utilizar pruebas de destruccin aleatorias para comprobar las rutas de errores importantes y poner de manifiesto errores de
programacin del software. Este tipo de pruebas mejora la calidad del cdigo ya que da lugar a errores que permiten examinar el control de los errores devueltos. Las pruebas aleatorias pasan por alto de forma intencionada cualquier especificacin del comportamiento del programa. Si se interrumpe la aplicacin, no se ha superado la prueba. Si no se interrumpe la aplicacin, la prueba se ha superado. La cuestin es que las pruebas aleatorias pueden tener un alto nivel
Pgina 18

de automatizacin porque nada tienen que ver con el modo en que se supone que funciona la aplicacin subyacente. PRUEBAS DE INTEGRACIN Identificar errores introducidos por la combinacin de programas probados unitariamente. Verificar que las especificaciones de diseo sean alcanzadas. Los componentes no estn implementados en el ambiente operativo. La fase de integracin requiere mayor planificacin y un conjunto de datos de prueba. Los sistemas grandes requieren varios pasos para realizar la integracin. Existen tres tipos bsicos de pruebas: Todo de una vez: provee una solucin til para realizar la integracin de problemas simples. Down-Top: Se empieza con los mdulos de nivel inferior, y se verifica que los mdulos de nivel inferior llaman a los de nivel superior de manera correcta, con los parmetros correctos. Top-Down: se empieza con los mdulos de nivel superior, y se verifica que los mdulos de nivel superior llaman a los de nivel inferior de manera correcta, con los parmetros correctos. PRUEBAS ESTRUCTURALES Son tambin conocidas como "pruebas de caja blanca" o "pruebas basadas en cdigo", donde se enfocan en probar cada una de las estructuras de cdigo, para que su comportamiento sea el esperado. Son las pruebas donde se conoce la estructura interna del componente a probar, y se efecta una prueba sobre dicha estructura. En el caso de una aplicacin web tambin se revisa la estructura interna de los links y otros elementos.
Pgina 19
SEGURIDAD EN INGENIERA DE SOFTWARE INGENIERA DE SEGURIDAD
En un mundo actual globalizado y sin fronteras de movilidad con respecto al uso total de Sistemas de Informacin y de las Comunicaciones es imprescindible dejar de evaluar el papel tan importante al cual se enfrentan los Ingenieros de Software en el campo de la seguridad. Se puede pensar en la definicin de seguridad como el grado de confianza que exige un individuo o empresa para que su informacin no sea mostrada ni divulgada a todo el mundo, entonces es donde se requiere un compromiso consiente por parte de los profesionales involucrados en la creacin del software encargado de dicha funcin. Los sistemas de seguridad crticos son sistemas en los que es esencial que el funcionamiento del sistema sea siempre seguro. Esto es, el sistema nunca debera provocar daos en las personas o en el entorno del sistema incluso si ste falla. Ejemplos de sistemas de seguridad crticos son el control y monitorizacin de sistemas de un avin, sistemas de control de procesos en plantas qumicas y farmacuticas y sistemas de control de automviles. El control mediante hardware de los sistemas de seguridad crticos es ms sencillo de implementar y analizar que el control mediante software. Sin embargo, actualmente se estn construyendo sistemas de tal complejidad que no se pueden controlar nicamente mediante hardware. Es esencial realizar algn control mediante software debido a la necesidad de gestionar un nmero muy grande de sensores y actuadores con leyes de control complejas.
El software de seguridad crtico se divide en dos clases:
Software de seguridad crtico primario: Es el software que est embebido como un controlador en un sistema. El mal funcionamiento de dicho software puede ocasionar un mal funcionamiento del hardware, lo que
Pgina 20

puede provocar lesiones personales o da un mal funcionamiento del hardware, lo que puede provocar lesiones personales o daos en el enlomo. Software de seguridad crtico secundario: Es el software que indirectamente puede provocar lesiones. Ejemplos de dichos sistemas son los sistemas de diseo asistido por computadora, cuyo mal funcionamiento podra provocar un defecto de diseo en el objeto que se est diseando. Este defecto puede causar lesiones personales si el sistema diseado no funciona bien. Otro ejemplo de un sistema de seguridad crtico secundario es una base de datos mdica que contiene los detalles de los medicamentos administrados a los pacientes. Los errores en este sistema podran dar lugar a que se administrara una dosis de medicamentos incorrecta.
La fiabilidad y la seguridad del sistema estn relacionadas, pero son distintos atributos de confiabilidad. Desde luego, un sistema de seguridad crtico es fiable si est de acuerdo con su especificacin y funciona sin fallos. Dicho sistema puede incorporar caractersticas de tolerancia a defectos para que pueda proporcionar un servicio continuo incluso si se producen defectos. Sin embargo, los sistemas tolerantes a defectos no son necesariamente seguros. El software an puede funcionar mal y ocasionar un comportamiento del sistema que provoque un accidente.
Adems del hecho de que nunca se pueda tener la certeza absoluta de que un sistema est libre de defectos y es tolerante a fallos, hay muchas otras razones por las que un sistema software que es fiable no necesariamente es seguro:
La especificacin puede estar incompleta en el sentido de que no describe el comportamiento requerido del sistema en algunas situaciones crticas. Un alto porcentaje de sistemas que funcionan mal (Natajo y Kume, 1991; Lutz, 1993) se debe a errores de especificacin ms que a errores de diseo. En
Pgina 21

un estudio de errores en sistemas empotrados, Lutz concluye que: Las dificultades con los requerimientos son la causa clave de los errores de software relacionados con la seguridad que persistieron hasta la integracin y la prueba del sistema.
El mal funcionamiento del hardware hace que el sistema se comporte de forma impredecible y enfrente al software con un entorno inesperado. Cuando los componentes estn prximos a fallar, pueden comportarse de forma errtica y generar seales que estn fuera de los rangos que puede manejar el software.
Los operadores del sistema pueden generar entradas que no son individualmente incorrectas, pero que, en situaciones particulares, pueden dar lugar a un mal funcionamiento del sistema. Como ejemplo anecdtico se puede citar el caso en que un mecnico dio instrucciones al software de utilidades de gestin de un avin para que levantara el tren de aterrizaje. El software ejecut las instrucciones perfectamente. Por desgracia, el avin permaneci en tierra todo el tiempo; claramente, el sistema debera haber inhabilitado el comando a menos que el avin estuviese en el aire.
Se ha creado un vocabulario especializado para tratar los sistemas de seguridad crticos y es importante comprender los trminos especficos utilizados.
La clave para garantizar la seguridad es asegurar que los accidentes no ocurran o que las consecuencias de stos sean mnimas. Esto puede conseguirse de tres formas complementarias:
Evitacin de contingencias: El sistema se disea para que las contingencias se eviten. Por ejemplo, un sistema de corte que requiere que el operador presione dos botones distintos al mismo tiempo para utilizar la
Pgina 22

mquina evita la contingencia de que los dedos del operador estn cerca de las cuchillas. Deteccin y eliminacin de contingencias: El sistema se disea para que las contingencias se detecten y eliminen antes de que provoquen un accidente. Por ejemplo, un sistema de una planta qumica puede detectar una presin excesiva y abrir una vlvula de escape para reducir la presin antes de que ocurra una explosin. Limitacin de daos: El sistema incluye caractersticas de proteccin que minimizan el dao que puede resultar de un accidente. Por ejemplo, el motor de un avin normalmente incluye extintores de incendios
automticos. Si se produce un fuego, a menudo ste se puede controlar antes de que suponga una amenaza para el avin.
Los accidentes ocurren generalmente cuando varias cosas van mal al mismo tiempo. Un anlisis de accidentes serios (Perrow, 1984) sugiere que casi todos ellos se debieron a una combinacin de malos funcionamientos ms que a fallos aislados. La combinacin no anticipada condujo a interacciones que provocaron fallos de funcionamiento del sistema. Perrow sugiere tambin que es imposible anticiparse a todas las posibles combinaciones de mal funcionamiento de un sistema, y que los accidentes son una parte inevitable del uso de sistemas complejos. El software tiende a incrementar la complejidad del sistema, de tal forma que al realizar el control mediante software puede incrementar la probabilidad de accidentes del sistema. Sin embargo, el software de control y monitorizacin puede mejorar tambin la seguridad de los sistemas. Los sistemas controlados por software pueden monitorizar un rango de condiciones ms amplio que los sistemas
electromecnicos. Los primeros se pueden adaptar con relativa facilidad. Adems implican el uso del hardware de la computadora, el cual tiene una fiabilidad inherente muy alta y es fsicamente pequeo y ligero. Los sistemas controlados por software pueden proporcionar mecanismos de seguridad sofisticados. Pueden soportar estrategias de control que reducen la cantidad de tiempo que las

personas necesitan consumir en entornos con contingencias. En consecuencia, si bien el software de control puede introducir ms formas en las que un sistema puede funcionar mal, tambin permite una mejor monitorizacin y proteccin, por lo tanto, puede mejorar la seguridad del sistema.
En todos los casos, es importante mantener un sentido de la proporcin sobre la seguridad del sistema. Es imposible conseguir que un sistema sea totalmente seguro, y la sociedad debe decidir si los beneficios del uso de tecnologas avanzadas compensan o no las consecuencias de un accidente ocasional. Tambin es una decisin social y poltica cmo utilizar unos recursos nacionales limitados a fin de reducir el riesgo para la poblacin en su conjunto.
ATAQUE DE SEGURIDAD
Hasta la aparicin de la informtica la valoracin de los activos de una empresa se haca segn los objetos fsicos tiles, las producciones propias, las infraestructuras, la tesorera y el capital humano. Desde los ltimos aos se ha aadido un nuevo capital tan importante como los anteriores, el valor de la informacin. No es que antes no existiera la informacin en las empresas, el espionaje industrial es tan antiguo como la revolucin industrial, pero se mantena con el sistema de papel y archivadores y formaba parte de los activos de oficina. Hoy en da, la informacin se maneja en grandes cantidades y de procedencias muy diversas, el valor aadido de una empresa puede ser la informacin que maneja.
Como capital de la empresa cada vez es ms importante mantener la seguridad de la informacin, pero tambin los riesgos cada vez son mayores. Estos riesgos se pueden clasificar por su procedencia en tres categoras: Errores involuntarios de personas y/o mquinas. Desastres naturales.
Pgina 24

Ataques voluntarios.
Dentro de los ataques voluntarios, los problemas creados por stos se pueden clasificar en tres familias: Denegacin de servicio: disponibilidad. Prohibir el acceso a la informacin. Observacin no autorizada: confidencialidad. Acceso a informacin por personas que pueden utilizarla para daar la empresa, o sea, personas no autorizadas. Modificacin no autorizada: integridad. Acceso a la informacin y modificacin, ya sea borrando, cambiando, aadiendo o sustituyendo datos. La proteccin de la informacin es ms grave desde la aparicin de las redes telemticas. Estas redes y especialmente Internet, hacen que la informacin sea un problema global y no aislado a las mquinas internas de la empresa. Las tecnologas aplicadas a la seguridad en redes estn en su fase de desarrollo inicial, especialmente por dos motivos: La mayora de sistemas operativos estn pensados para arquitecturas mainframe/terminal y no para arquitecturas cliente/servidor o
Internet/Intranet que se utilizan actualmente. No existen estndares ni organizaciones mundiales aceptadas por todas las empresas proveedoras de seguridad.
Al disear un sistema de seguridad para la empresa la pregunta es existe un sistema completamente seguro? La respuesta es clara, no. En la prctica siempre existe un compromiso entre el nivel de seguridad y los parmetros: Costes. La seguridad es proporcional al coste de las medidas de proteccin. Entorno de usuario. La seguridad es opuesta a los sistemas abiertos que pretenden facilitar el acceso a cualquier usuario con o sin preparacin.
Pgina 25

Por lo tanto, la instalacin de la seguridad es un problema de ingeniera, un compromiso entre gastos y facilidad de uso frente a proteccin. Se debe planificar y seguir los pasos siguientes: Anlisis de riesgos. Estudiar los riesgos posibles, cuantificar el valor las consecuencias de estos riesgos sobre la informacin y valorar los costes totales. Analizar las medidas de proteccin. Valorar las diferentes medidas de proteccin, tanto cuantitativamente como de facilidad de uso y velocidad de acceso. Decidir las medidas adecuadas. Comparar los dos anlisis y decidir la solucin que amortiza los riesgos. Poltica de seguridad. Adaptar la forma de trabajo de la empresa a las nuevas medidas de seguridad. Mantenimiento. Mantener continuamente las medidas de seguridad as como actualizar el diseo a las nuevas realidades del capital de informacin. Planes de contingencia. Planificar las actuaciones para cuando se producen ataques con o sin xito. SERVICIOS DE SEGURIDAD Para proteger la informacin se utilizan los servicios de seguridad. Se pueden clasificar segn su utilidad en: Autenticacin. Asegura que el usuario y la informacin son autnticos. Control de accesos. Protege la informacin contra accesos no deseados, tanto fsicos como lgicos. Confidencialidad. Oculta los datos a observaciones no deseadas. Integridad. Comprueba que la informacin no ha sido modificada. No repudio. Evita que una persona autorizada sea rechazada al acceder a la informacin. Disponibilidad. Asegura la disponibilidad de todos los recursos.
Pgina 26

La Tabla 1.1 indica que ataques protegen los servicios anteriores:
MECANISMOS DE IMPLEMENTACIN Por el mbito de su aplicacin se pueden dividir en dos grandes familias: Especficos. Se aplican a una capa OSI del sistema para implementar un servicio. Generales. Se aplican al sistema para cumplir la poltica general.
GENERALES Funcionalidad de confianza. El sistema de seguridad est libre de ataques. Etiquetas. Clasifica la informacin por niveles de seguridad: secreta, confidencial, no clasificada, etc. Auditorias. Almacena las acciones realizadas sobre el sistema. Deteccin de eventos. Detecta movimientos peligrosos dentro del sistema. Recuperacin de desastres. Todas las polticas para recuperar la informacin despus de un ataque con xito: Backups, mirrors, etc. Polticas de personal. Normativas sobre las actuaciones del personal. ESPECFICOS Cifrado. Se transforman los datos para que slo sean inteligibles a los usuarios autorizados. Firma digital. A la informacin se le aaden unos datos que nicamente puede generar un usuario concreto, adems no permiten la modificacin de la informacin por otros usuarios.
Pgina 27

Control de accesos. No permiten el acceso fsico o lgico a la informacin a usuarios no autorizados. Integridad de datos. Aaden datos a la informacin que detectan si sta ha sido modificada. Trfico de relleno. Inyectan trfico sin informacin en las redes para confundir a los observadores de la red. Control de encaminamiento. Se utilizan los sistemas de encaminamiento para proteger la informacin. Notorizacin. Una tercera persona fsica o jurdica confirma la seguridad de procedencia e integridad de los datos. La tabla 1.2 muestra los servicios que brindan los mecanismos.
Los mecanismos: cifrado, firma digital, control de accesos e integridad utilizan criptologa para su implementacin.
PROTECCIN
La proteccin es un atributo del sistema que refleja su capacidad para protegerse de ataques externos que pueden ser accidentales o provocados. La proteccin ha adquirido cada vez ms importancia en tanto que ms y ms sistemas se han conectado a Internet. Las conexiones a Internet proporcionan funcionalidades del sistema adicionales (por ejemplo, los clientes pueden acceder directamente a sus cuentas bancarias), pero la conexin a Internet tambin significa que el sistema puede ser atacado por personas con intenciones hostiles. La conexin a Internet tambin conlleva que los detalles sobre vulnerabilidades particulares del sistema pueden difundirse fcilmente para que ms personas sean
Pgina 28

capaces de atacar al sistema. Del mismo modo, sin embargo, la conexin puede acelerar la distribucin de parches del sistema para reparar estas vulnerabilidades.
Ejemplos de ataques podran ser los virus, el uso no autorizado de servicios del sistema y la modificacin no autorizada del sistema o sus datos. La proteccin es importante para todos los sistemas crticos. Sin un nivel razonable de proteccin, la disponibilidad, fiabilidad y seguridad del sistema pueden verse comprometidas si ataques externos que provocan daos al mismo. La razn de esto es que todos los mtodos para asegurar la disponibilidad, fiabilidad y seguridad se valen del hecho de que el sistema operacional es el mismo que se instal originalmente. Si dicho sistema instalado se ha visto comprometido de alguna forma (por ejemplo, si el software se ha modificado para aceptar un virus), entonces los argumentos para la fiabilidad y la seguridad originalmente establecidos dejan de ser ciertos. El sistema de software puede entonces corromperse y comportarse de forma impredecible.
Por el contrario, los errores en el desarrollo de un sistema pueden provocar agujeros de proteccin. Si un sistema no responde a entradas inesperadas o si los lmites de un vector no se verifican, entonces los atacantes pueden explotar estas debilidades para tener acceso al sistema. Los incidentes de proteccin ms importantes tales como el gusano de Internet original (Spafford, 1989) y el gusano Code Red ms de diez aos despus (Berghel, 2001) se aprovecharon del hecho de que los programas en C no incluyen verificacin de los lmites de los vectores. Los gusanos sobrescribieron parte de la memoria con cdigo que permiti el acceso no autorizado al sistema. Por supuesto, en algunos sistemas crticos, la proteccin es la dimensin ms importante de la confiabilidad del sistema. Los sistemas militares, los sistemas de comercio electrnico y los sistemas que implican el procesamiento e intercambio de informacin confidencial, se deben disear de tal forma que alcancen altos niveles de proteccin. Por ejemplo, si un sistema de reservas de
Pgina 29

billetes de avin no est disponible, esto provoca inconvenientes y algunos retrasos en la emisin de los billetes. Sin embargo, si el sistema no est protegido y puede aceptar reservas falsas, entonces la lnea area propietaria del sistema puede perder una gran cantidad de dinero.
Existen tres tipos de daos que pueden ser causados por ataques externos:
Denegacin de servicio. El sistema puede verse forzado a entrar en un estado en que sus servicios normales no estn disponibles. Esto, obviamente, afecta a la disponibilidad del sistema.
Corrupcin de programas o datos. Los componentes software del sistema pueden ser alterados de forma no autorizada. Esto puede afectar al comportamiento del sistema y, por lo tanto, a su fiabilidad y a su seguridad. Si el dao es grave, la disponibilidad del sistema puede verse afectada.
Revelacin de informacin confidencial. La informacin gestionada por el sistema puede ser confidencial y los ataques externos pueden exponerla a personas no autorizadas. Dependiendo del tipo de datos, esto podra afectar a la seguridad del sistema y puede permitir ataques posteriores que afecten a la disponibilidad o fiabilidad del sistema.
Como con otros aspectos de la confiabilidad, existe una terminologa especializada asociada con la proteccin. Algunos trminos importantes, como los tratados por Pfleeger (1977), se definen de la siguiente manera:
Exposicin: posible prdida o dao en un sistema informtico. Un ejemplo puede ser la prdida o dao de los datos o la prdida de tiempo y esfuerzo si es necesaria una recuperacin del sistema despus de una violacin de proteccin. Vulnerabilidad: debilidad en un sistema informtico que se puede aprovechar para provocar prdidas o daos.
Pgina 30

Ataque: aprovechamiento de la vulnerabilidad de un sistema.
Generalmente, se produce desde fuera del sistema y con una intencin deliberada de causar algn dao. Amenaza: circunstancias que potencialmente pueden provocar prdidas o daos. Se pueden entender como una vulnerabilidad del sistema que est expuesto a un ataque. Control: medida de produccin que reduce la vulnerabilidad del sistema. La encriptacin podra ser un ejemplo de un control que reduce una vulnerabilidad de un sistema de control de acceso deficiente.
Existe una clara analoga con cierta terminologa de la seguridad en el sentido de que una exposicin es anloga a un accidente y una vulnerabilidad es anloga a una contingencia. Por tanto, existen aproximaciones comparables que se utilizan para garantizar la proteccin de un sistema:
Evitar la vulnerabilidad. El sistema se disea para que las vulnerabilidades no ocurran. Por ejemplo, si un sistema no est conectado a una red pblica externa, entonces no existe la posibilidad de un ataque por parte de otras personas conectadas a la red.
Defeccin y neutralizacin de ataques. El sistema se disea para detectar vulnerabilidades y eliminarlas antes de que provoquen una exposicin del sistema. Un ejemplo de deteccin y eliminacin de la vulnerabilidad es la utilizacin de un verificador de virus que analiza los ficheros entrantes y los modifica para eliminar el virus. Limitacin de la exposicin. Las consecuencias de un ataque exitoso se minimizan. Ejemplos de limitacin de la exposicin son los sistemas de copias de seguridad peridicas y una poltica de gestin de configuraciones que permite que el software daado pueda reconstruirse.
La gran mayora de las vulnerabilidades en los sistemas informticos se originan en fallos humanos en lugar de en problemas tcnicos. Las personas

eligen palabras clave fciles de recordar o las escriben en lugares en donde resulta fcil encontrarlas. Los administradores del sistema cometen errores en la actualizacin del control de acceso o de ficheros de configuracin y los usuarios olvidan instalar o usar software de proteccin. Para mejorar la proteccin, por lo tanto, se necesita adoptar una perspectiva sociotcnica y pensar en cmo se usan realmente los sistemas y no solamente en sus caractersticas tcnicas.
Dentro de las herramientas de proteccin para los sistemas de informacin se encuentra la criptologa. La criptologa est formada por dos tcnicas complementarias:
criptoanlisis y criptografa. La criptografa es la tcnica de convertir un texto inteligible, texto en claro (plaintext), en otro, llamado criptograma (ciphertext), cuyo contenido de
informacin es igual al anterior pero slo lo pueden entender las personas autorizadas. El criptoanlisis es la tcnica de descifrar un criptograma sin tener la autorizacin. CRIPTOGRAFA Para encriptar se debe transformar un texto mediante un mtodo cuya funcin inversa nicamente conocen las personas autorizadas. As se puede utilizar un algoritmo secreto o un algoritmo pblico que utiliza una palabra, llamada clave, slo conocida por las personas autorizadas, esta clave debe ser imprescindible para la encriptacin y desencriptacin.
Pgina 32

Los sistemas actuales utilizan algoritmo pblico y claves secretas, debido a los siguientes motivos: El nivel de seguridad es el mismo. Los algoritmos pblicos se pueden fabricar en cadena, tanto chips de hardware como aplicaciones software. De esta manera el desarrollo es ms barato. Los algoritmos pblicos estn ms probados, ya que toda la comunidad cientfica puede trabajar sobre ellos buscando fallos o agujeros. Un algoritmo secreto puede tener agujeros detectables sin necesidad de conocer su funcionamiento completo, por lo tanto, un criptoanalista puede encontrar fallos aunque no conozca el secreto del algoritmo. Es ms fcil y ms seguro transmitir una clave que todo el funcionamiento de un algoritmo. As un sistema de comunicaciones con criptografa utiliza un algoritmo pblico para encriptar y otro para desencriptar, pero son completamente inservibles para el criptoanalista sin el conocimiento de la clave.
CRIPTOANLISIS El criptoanlisis abarca muchas tcnicas diversas, muchas veces no dependen del conocimiento del algoritmo sino que mediante sistemas de aproximacin matemtica se puede descubrir el texto en claro o la clave. La dificultad del anlisis depende de la informacin disponible, as el criptoanalista puede tener acceso a:

Un criptograma Un criptograma y su texto en claro. Un texto claro elegido y su criptograma. Un criptograma elegido y su texto en claro. Un texto en claro y su criptograma que estn los dos elegidos. Aumenta la dificultad cuanta menos informacin se tiene. En todos se busca la clave que proporciona la solucin para todo el sistema de seguridad. En el criptoanlisis cientfico se utilizan las siguientes definiciones: Distancia unvoca. Cantidad mnima del mensaje para poder descifrar la clave. Un sistema ideal tiene una distancia unvoca infinito. Sistema incondicionalmente seguro. El criptograma generado es menor que la distancia unvoca. Romper un sistema. Conseguir un mtodo prctico para descifrar la clave de un sistema criptogrfico. Sistema probablemente seguro. No se ha probado como romperlo. Sistema condicionalmente seguro. Los analistas potenciales no disponen de medios para romperlo. No existen los sistemas completamente seguros, siempre se pueden violar probando todas las claves posibles. Por lo tanto, en criptografa se buscan sistemas que cumplan una de siguientes condiciones: El precio para romperlo es ms caro que el valor de la informacin. El tiempo necesario para romperlo es ms largo que el tiempo de vida de la informacin. Algunas de las aplicaciones, tales como sistemas de objetos distribuidos, servicios web o computacin grid, pueden representar pasos fundamentales en el uso extensivo de Internet. Sin embargo, la ausencia de seguridad y de mecanismos de colaboracin fiables est obstaculizando su desarrollo. La falta de soluciones adecuadas que permitan garantizar que los sistemas y aplicaciones

puedan resolver los problemas de seguridad asociados, representa en la prctica una barrera impracticable para el desarrollo extendido de esas aplicaciones. Se podra decir que, al contrario que la ingeniera del software, la ingeniera de seguridad est an en la fase experimental. Es poco frecuente que los problemas relacionados con la seguridad se consideren en las fases iniciales de desarrollo de software. La seguridad y la eficiencia son aspectos no funcionales muy importantes en cualquier sistema en red o distribuido, y su consecucin debe afrontarse a lo largo de todo el ciclo de vida software. TRABAJO RELACIONADO Hay muy poco trabajo concerniente a la integracin de aspectos de seguridad desde las primeras fases del desarrollo de software. Aunque se han propuesto ciertas alternativas para la integracin de la seguridad, actualmente no hay una metodologa completamente definida para ayudar a los desarrolladores de sistemas que requieran seguridad. La falta de soporte para la ingeniera de la seguridad en esas propuestas para el desarrollo de sistemas software puede verse como una consecuencia de que: Los requisitos de seguridad son muy difciles de analizar y modelar. De la falta de experiencia en el desarrollo de software seguro por parte de los desarrolladores. Las propuestas existentes no son lo suficientemente completas ni extensas, en el sentido de que se centran bien en alguna fase especial del desarrollo, por ejemplo en el diseo o la implementacin, o bien en un aspecto de seguridad particular tal como el control del acceso. Se introduce un enfoque de la ingeniera de la seguridad respecto a una arquitectura dirigida por modelo, llamada Model Driven Security. Este
acercamiento, llamado SecureUML, integra las polticas de control de acceso basadas en roles en un proceso de desarrollo de software basado en UML y dirigido por el modelo.

UMLsec ha sido propuesto como una extensin del Lenguaje Unificado de Modelado para modelar propiedades de seguridad de sistemas informticos. UMLsec usa mecanismos de extensin estndares para introducir nueva semntica dentro de los modelos UML. PROCESO SOFTWARE SEGURO Para solventar los problemas previamente mencionados, el trabajo se ha centrado en definir un proceso de desarrollo de software que integra prcticas de ingeniera de la seguridad en el propio ciclo de desarrollo software. Durante el transcurso, se defini mecanismos que aseguren la coherencia entre los modelos correspondientes a los diferentes niveles de abstraccin. El enfoque se basa en: Descripcin semntica de los requisitos de seguridad. Extensin de UML con requisitos de seguridad. Desarrollo de una librera de patrones de seguridad. Integracin de los componentes anteriores dentro de una herramienta. software para ofrecer un proceso de ingeniera enfocado a la seguridad. DESCRIPCIN SEMNTICA DE LOS ELEMENTOS DE SEGURIDAD Automatizar el procesamiento de la informacin semntica es un gran reto para la resolucin de muchos problemas relevantes, tal como puede ser la clasificacin de la web, o en nuestro caso, la integracin de soluciones genricas a problemas recurrentes en el campo de la ingeniera de seguridad. Las herramientas automticas para la clasificacin, seleccin y composicin de patrones estn en desarrollo, y permiten la integracin automtica de los patrones que implementan los requisitos de seguridad especificados. Las descripciones semnticas no slo ayudan en la seleccin del patrn correcto sino que adems son esenciales para la composicin de patrones y para
Pgina 36

el anlisis del sistema. Ms an, las descripciones semnticas son la base para la reutilizacin de esos patrones. La creacin de una metodologa y herramientas automticas para la clasificacin, seleccin y composicin de patrones de seguridad. El procesamiento automtico consta de dos componentes principales: Catalogacin y bsqueda basada en los metamodelos semnticos. La informacin semntica acerca de los patrones y de los servicios de seguridad que ofrecen es esencial para conseguir unas bsquedas eficientes y una seleccin automtica de patrones capaces de plasmar en el sistema requisitos de seguridad especficos a partir de informacin del modelo. Composicin Inteligente. Ser tiene que tener la capacidad de seleccionar automticamente los patrones apropiados y componerlos para completar esos requisitos de seguridad. PROCESO DE DESARROLLO DE SOFTWARE PARA LA SEGURIDAD El proceso de desarrollo de software integra tcnicas de ingeniera de la seguridad basadas en la nocin de patrn de seguridad. Un patrn describe un problema recurrente que surge en un contexto especfico y que presenta un esquema de solucin genrico y bien probado para su solucin. Tambin se usa el concepto de patrones de seguridad para representar soluciones de seguridad existentes. A partir de unos requisitos de seguridad definidos en el modelo, se busca automticamente los patrones que mejor los representen. Entonces, los patrones seleccionados deben adaptarse e integrarse en el modelo de usuario. Hay que resaltar que cuando el cliente expresa requisitos de seguridad complejos puede ser necesaria la composicin de diferentes patrones antes de integrarlos en el modelo.
Pgina 37

EXTENSIN DE UML CON REQUISITOS DE SEGURIDAD Estas transformaciones ayudan a la creacin de modelos usando puntos de vista especficos, por ejemplo llegar a la creacin de un modelo de requisitos de seguridad de nivel de diseo a partir de un modelo de requisitos de seguridad a nivel de especificacin, y/o ayudan a la configuracin e instalacin de modelos de infraestructura comenzando desde un modelo de requisitos de seguridad de negocio. La caracterizacin de los requisitos de seguridad como base, del trabajo est enfocada en las siguientes reas: La definicin de un perfil UML para los requisitos de seguridad. La extensin de las herramientas UML para que gestionen esos perfiles UML. Las transformaciones de Arquitectura Dirigidas por Modelos (MDA) y las extensiones de las herramientas UML asociadas. La especificacin de los requisitos de seguridad est integrada dentro de los modelos UML de tal forma que estos requisitos pueden procesarse fcilmente de forma automtica. Los requisitos de seguridad se representan habitualmente por expresiones complejas con modificadores y parmetros que los estereotipos no son capaces de capturar. Por ejemplo, si se considera el caso del requisito de confidencialidad; sera necesario especificar para quin es esa confidencialidad. Cuando se consideran estos requisitos en profundidad, se descubren otros aspectos que pueden y en ocasiones deben ser especificados. Pese a todo, se usan estereotipos durante las primeras etapas del desarrollo, especialmente en el modelo de negocio.
Pgina 38

INTEGRACIN DE REQUISITOS DE SEGURIDAD EN MODELOS SOFTWARE El proceso gestionar el desarrollo de sistemas seguros de forma sistemtica y guiada desde la especificacin hasta la implementacin. El objetivo es usar el marco de trabajo para la especificacin de los requisitos y la librera de patrones de seguridad para ayudar al desarrollador en el diseo de soluciones seguras. Las herramientas automatizadas bajo desarrollo estn diseadas para ofrecer un proceso de ingeniera de la seguridad basada en componentes a travs de todo el ciclo de desarrollo completo, desde la especificacin a la implementacin y desarrollo. El proceso de desarrollo tiene en cuenta condiciones del entorno para conseguir implementaciones seguras.
Pgina 39
SEGURIDAD EN INGENIERA DE SOFTWARE CONCLUSIN
La seguridad en las aplicaciones de software debe abordarse desde el primer da del proceso de desarrollo y a lo largo de todas las etapas del mismo. En cada una de estas etapas, se pueden realizar diversas actividades que en su conjunto ayudarn a aumentar la seguridad de la aplicacin de software que se est desarrollando. Es importante que en cada organizacin, el sector de seguridad de la informacin sea invitado a participar a lo largo de todo el proceso de desarrollo como supervisor de las tareas y verificaciones de seguridad. La integracin de seguridad a lo largo del SDLC ayuda a reducir las fallas de seguridad como as tambin los costos de la aplicacin, tanto tangibles (tiempo/dinero) como intangibles (imagen de la organizacin). Por lo tanto la complejidad de un programa de computacin o software es una medida de la dificultad para llevar a cabo esa computacin y est muy relacionada con su confiabilidad. Por otra parte, se dice que un software es confiable si realiza lo que el usuario desea, cuando as lo requiera. Se podr aumentar la Confiabilidad de un Software haciendo hincapi en las dos primeras etapas de su desarrollo, el traslado de los requerimientos del usuario y en el diseo lgico. En el desarrollo de software el ingeniero en sistemas debe de tener en cuenta un punto fundamental y este es la seguridad ya que juega un papel fundamental del sistema, esto conlleva a que el sistema sea fiable en la seguridad. Tambin en los sistemas de seguridad crticos es esencial que el funcionamiento del sistema sea siempre seguro. El sistema nunca debera provocar daos en las personas o en el entorno del sistema incluso si ste falla. En el control mediante hardware de los sistemas de seguridad crticos es ms sencillo de implementar y analizar que el control mediante software. Es importante tener en cuenta los aspectos esenciales de la seguridad al desarrollar un sistema, y tambin ver la manera ms viable para procurar la confiabilidad del sistema.
Pgina 40
SEGURIDAD EN INGENIERA DE SOFTWARE BIBLIOGRAFA
Ingeniera de software, sptima edicin, Iam Sommerville, Pearson Educacin, S.A., Madrid, 2005. ANNIMO, Software de seguridad Obtenido en: http://www.softwareseguridad.com/seguridadeneldesarrollodesoftware.html Fecha: MAYO 2013
PABLO MILANO, CONSULTOR CYBSEC, Seguridad en el ciclo de vida Del desarrollo de software Obtenido en: http://www.prensariotila.com/pdf/TutorialCybsec_0710.pdf Fecha: MAYO DE 2013
CASANOVA VALENCIA, SALVADOR ANTELMO, Apuntes de ingeniera de software Obtenido en: http://www.fcca.umich.mx/descargas/apuntes/Academia%20de%20Informatica/Ing enier%C3%ADa%20del%20Software%20%20S.C.V/Ingenier%C3%ADa%20de%2 0Software.pdf Fecha: MAYO DE 2013
PONS MARTORELL, MANUEL, Criptologa Obtenido en: http://www.tierradelazaro.com/public/libros/cripto.pdf Fecha: MAYO DE 2013
MAA ANTONIO, RAY DIEGO, SNCHEZ FRANCISCO, Integrando la Ingeniera de seguridad en un proceso de ingeniera software.

Obtenido en: http://web.iti.upv.es/~fsanchez/publications/RECSI04ManaSanchezRayYague.pdf Fecha: MAYO 2013
Pgina 42

Reporte Seguridad en La Ingeniería de SW

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Reporte Seguridad en La Ingeniería de SW

Hochgeladen von

Copyright:

Verfügbare Formate

PROFESORA

M.T.I. MONTSERRAT MASDEFIOL SUREZ

SEGURIDAD EN INGENIERA DE SOFTWARE NDICE

M.T.I. MONTSERRAT MASDEFIOL SUREZ.

SEGURIDAD EN INGENIERA DE SOFTWARE

M.T.I. MONTSERRAT MASDEFIOL SUREZ.

SEGURIDAD EN INGENIERA DE SOFTWARE INTRODUCCIN

M.T.I. MONTSERRAT MASDEFIOL SUREZ.

SEGURIDAD EN INGENIERA DE SOFTWARE SEGURIDAD EN EL CICLO DE DESARROLLO DEL SOFTWARE

SEGURIDAD EN EL ANLISIS DE REQUERIMIENTOS

M.T.I. MONTSERRAT MASDEFIOL SUREZ.

SEGURIDAD EN INGENIERA DE SOFTWARE

SEGURIDAD EN INGENIERA DE SOFTWARE

M.T.I. MONTSERRAT MASDEFIOL SUREZ.

SEGURIDAD EN INGENIERA DE SOFTWARE

M.T.I. MONTSERRAT MASDEFIOL SUREZ.

SEGURIDAD EN INGENIERA DE SOFTWARE

M.T.I. MONTSERRAT MASDEFIOL SUREZ.

SEGURIDAD EN INGENIERA DE SOFTWARE

M.T.I. MONTSERRAT MASDEFIOL SUREZ.

SEGURIDAD EN INGENIERA DE SOFTWARE

M.T.I. MONTSERRAT MASDEFIOL SUREZ.

SEGURIDAD EN INGENIERA DE SOFTWARE CONFIABILIDAD DEL SOFTWARE

M.T.I. MONTSERRAT MASDEFIOL SUREZ.

SEGURIDAD EN INGENIERA DE SOFTWARE

M.T.I. MONTSERRAT MASDEFIOL SUREZ.

SEGURIDAD EN INGENIERA DE SOFTWARE

SEGURIDAD EN INGENIERA DE SOFTWARE

M.T.I. MONTSERRAT MASDEFIOL SUREZ.

SEGURIDAD EN INGENIERA DE SOFTWARE

M.T.I. MONTSERRAT MASDEFIOL SUREZ.

SEGURIDAD EN INGENIERA DE SOFTWARE

SEGURIDAD EN INGENIERA DE SOFTWARE

M.T.I. MONTSERRAT MASDEFIOL SUREZ.

SEGURIDAD EN INGENIERA DE SOFTWARE

M.T.I. MONTSERRAT MASDEFIOL SUREZ.

SEGURIDAD EN INGENIERA DE SOFTWARE INGENIERA DE SEGURIDAD

El software de seguridad crtico se divide en dos clases:

M.T.I. MONTSERRAT MASDEFIOL SUREZ.

SEGURIDAD EN INGENIERA DE SOFTWARE

M.T.I. MONTSERRAT MASDEFIOL SUREZ.

SEGURIDAD EN INGENIERA DE SOFTWARE

M.T.I. MONTSERRAT MASDEFIOL SUREZ.

SEGURIDAD EN INGENIERA DE SOFTWARE

SEGURIDAD EN INGENIERA DE SOFTWARE

M.T.I. MONTSERRAT MASDEFIOL SUREZ.

SEGURIDAD EN INGENIERA DE SOFTWARE

M.T.I. MONTSERRAT MASDEFIOL SUREZ.

SEGURIDAD EN INGENIERA DE SOFTWARE

M.T.I. MONTSERRAT MASDEFIOL SUREZ.

SEGURIDAD EN INGENIERA DE SOFTWARE

M.T.I. MONTSERRAT MASDEFIOL SUREZ.

SEGURIDAD EN INGENIERA DE SOFTWARE

M.T.I. MONTSERRAT MASDEFIOL SUREZ.

SEGURIDAD EN INGENIERA DE SOFTWARE

M.T.I. MONTSERRAT MASDEFIOL SUREZ.

SEGURIDAD EN INGENIERA DE SOFTWARE

M.T.I. MONTSERRAT MASDEFIOL SUREZ.

SEGURIDAD EN INGENIERA DE SOFTWARE

SEGURIDAD EN INGENIERA DE SOFTWARE

M.T.I. MONTSERRAT MASDEFIOL SUREZ.

SEGURIDAD EN INGENIERA DE SOFTWARE

SEGURIDAD EN INGENIERA DE SOFTWARE