Apuntes Unidad 4 Seguridad en Ingeniería de Software

PROFESORA
M.T.I. MONTSERRAT MASDEFIOL SUREZ
CARRERA
ING. EN SISTEMAS COMPUTACIONALES
MATERIA
INGENIERA DE SOFTWARE
TRABAJO
U4: SEGURIDAD EN INGENIERA DE SOFTWARE
NOMBRE DEL ALUMNO:

SERRANO BLAS, EPIFANIO
GRUPO
604 A
SAN ANDRS TUXTLA, VER., 25 DE MAYO DEL 2013.
INGENIERA DE SOFTWARE NDICE
INTRODUCCIN .................................................................................................... 5 UNIDAD 4 SEGURIDAD DE INGENIERA DE SOFTWARE................................... 6 Objetivo......................................................................................................... 6 Criterios de evaluacin ................................................................................. 6 Temario......................................................................................................... 6 4.1 SEGURIDAD DE SOFTWARE .......................................................................... 7 DEFINICIONES DE SEGURIDAD ................................................................ 7 IMPORTANCIA DE SEGURIDAD ................................................................. 7 USUARIOS COMUNES ................................................................................ 8 EDUCAR AL USUARIO ................................................................................ 8 CREANDO SOFTWARE............................................................................... 8 PROPIEDADES DE LA INFORMACIN ...................................................... 8 ATAQUES CONTRA EL FLUJO DE LA INFORMACIN ............................. 9 RAZONES PARA ATACAR LA RED DE UNA EMPRESA ......................... 10 CRACKER ........................................................................................ 10 HACKERS ........................................................................................ 10 4.2 SEGURIDAD EN EL CICLO DE DESARROLLO DEL SOFTWARE ............... 13 SEGURIDAD EN EL ANLISIS DE REQUERIMIENTOS........................... 14 SEGURIDAD EN EL DISEO .................................................................... 14 SEGURIDAD EN LA CODIFICACIN ........................................................ 15 TESTING / QA DE SEGURIDAD ................................................................ 16 IMPLEMENTACIN / PUESTA EN PRODUCCIN ................................... 17 Ventajas ........................................................................................... 18
Desventajas ..................................................................................... 18 SEGURIDAD EN EL DESARROLLO DE SOFTWARE............................... 19 PAPEL DE SEGURIDAD EN EL DESARROLLO DE SOFTWARE. ........... 20 4.3 CONFIABILIDAD DEL SOFTWARE ................................................................ 21 PRUEBAS DE CONFIABILIDAD ........................................................................... 26 Tipos de Pruebas de Confiabilidad ............................................................. 26 De Componentes ............................................................................. 26 Pruebas de Estrs ............................................................................ 26 De Integracin .................................................................................. 27 Pruebas de estrs de componentes ................................................. 27 Pruebas de estrs de integracin ..................................................... 27 Pruebas de Reales y Destruccin .................................................... 28 Pruebas de Integracin .................................................................... 28 Pruebas Estructurales ...................................................................... 29 4.4 INGENIERA DE SEGURIDAD ....................................................................... 31 COMPONENTES DE UN SISTEMA SEGURO .......................................... 36 RIESGOS DETERMINAN LA POLTICA Y ESTA DEFINE LA
TECNOLOGA A UTILIZAR ........................................................................ 37 UNA POLTICA DE SEGURIDAD PARA UN SISTEMA DEFINE LOS OBJETIVOS................................................................................................ 37 ATAQUE DE SEGURIDAD ................................................................................... 38 Servicios de seguridad................................................................................ 40 Mecanismos de implementacin ................................................................. 40 Generales ......................................................................................... 41 Especficos ....................................................................................... 41 PROTECCIN ...................................................................................................... 42
M.T.I. MONTSERRAT MASDEFIOL SUREZ 3
Criptografa ................................................................................................. 46 Criptoanlisis .............................................................................................. 47 TRABAJO RELACIONADO ........................................................................ 49 PROCESO SOFTWARE SEGURO ............................................................ 50 DESCRIPCIN SEMNTICA DE LOS ELEMENTOS DE
SEGURIDAD .................................................................................... 50 PROCESO DE DESARROLLO DE SOFTWARE PARA LA
SEGURIDAD .................................................................................... 51 EXTENSIN DE UML CON REQUISITOS DE SEGURIDAD .......... 51 INTEGRACIN DE REQUISITOS DE SEGURIDAD EN MODELOS SOFTWARE ..................................................................................... 52 CONCLUSIN ...................................................................................................... 53 BIBLIOGRAFA ..................................................................................................... 54
INGENIERA DE SOFTWARE INTRODUCCIN
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.
INGENIERA DE SOFTWARE UNIDAD 4 SEGURIDAD DE INGENIERA DE SOFTWARE
OBJETIVO
Identificar los riesgos posibles que puede enfrentar durante el proceso de desarrollo del software y aplicar medidas de seguridad para minimizarlos.
CRITERIOS DE EVALUACIN
Propuesta de proyecto Exposicin Investigacin documental Propuesta terica
10 % 35 % 25 % 20 %
TEMARIO 4.1 seguridad de software 4.2 seguridad en el ciclo de desarrollo del software 4.3 confiabilidad del software 4.4 ingeniera de seguridad
INGENIERA DE SOFTWARE 4.1 SEGURIDAD DE SOFTWARE

La seguridad informtica es un camino, no un destino, Objetivo: mantener los sistemas generando resultados, Si los sistemas no se encuentran funcionando entonces su costo se convierte en prdidas financieras (en el menos grave de los casos). El resultado generado por un sistema es la informacin que almacena o produce. La seguridad es un problema exclusivamente de las computadoras. Las computadoras y las redes son el principal campo de batalla. Se debe de proteger aquello que tenga un valor para alguien. DEFINICIONES DE SEGURIDAD Polticas, procedimientos y tcnicas para asegurar la integridad,
disponibilidad de datos y sistemas. Prevenir y detectar amenazas. Responder de una forma adecuada y con prontitud ante un incidente. Proteger y mantener los sistemas funcionando. IMPORTANCIA DE SEGURIDAD Por el dinero, el dueo de los sistemas tiene dinero invertido en algo que le trae un beneficio o ventaja. Por calidad, hay que acostumbrarse a hacer las cosas bien, aunque cuentes ms esfuerzo. La seguridad surge tecnolgicamente, la seguridad es gratis. Los sistemas operativos modernos contienen muchas caractersticas de seguridad. Las mejores herramientas de seguridad son open source.
USUARIOS COMUNES Los usuarios se acostumbran a usar la tecnologa sin saber cmo funciona o de los riesgos que pueden correr. Son las principales vctimas. Tambin son el punto de entrada de muchos problemas crnicos. El eslabn ms dbil en la cadena de seguridad. 2 enfoques para controlarlos. Principio del menor privilegio posible. Reducir la capacidad de accin del usuario sobre los sistemas. Objetivo: lograr el menos dao posible en caso de incidentes. EDUCAR AL USUARIO Generar una cultura de seguridad. El usuario ayuda a reforzar. Creadores del sistema. CREANDO SOFTWARE El software moderno es muy complejo y tiene una alta probabilidad de contener vulnerabilidad de seguridad. Un mal proceso de desarrollo genera software de mala calidad. Prefieren a que salga mal a que salga tarde. Usualmente no se ensea a incorporar requisitos ni protocolos de seguridad. PROPIEDADES DE LA INFORMACIN Confidencialidad: asegurarse que la informacin en un sistema de cmputo t la transmitida por un medio de comunicacin, puede ser leda solo por las personas autorizadas. Autenticacin: asegurarse que el origen de un mensaje o documento electrnico est correctamente identificado, con la seguridad que la entidad emisora o receptora no est suplantada. Integridad: asegurarse que solo el personal autorizado sea capaz de modificar la informacin o recursos de cmputo.
No repudiacin: asegurarse que ni el emisor o receptor de un mensaje o accin sea capaz de negar lo hecho. Disponibilidad: requiere que los recursos de un sistema de cmputo estn disponibles en el momento que se necesiten.
ATAQUES CONTRA EL FLUJO DE LA INFORMACIN Flujo normal Los mensajes en una red se envan a partir de un emisor a uno o varios receptores. El atacante es un tercer elemento. Interrupcin El mensaje no puede llegar a su destino, un recurso del sistema es destruido o temporalmente inutilizado. Es un ataque contra la disponibilidad. Intercepcin Una persona, computadora o programa sin autorizacin logra el acceso a un recurso controlado. Es un ataque contra confiabilidad. Modificacin La persona sin autorizacin, adems de lograr el acceso modifica el mensaje. Ejemplo: alterar la informacin que se transmite en la base de datos. Fabricacin Una persona sin autorizacin insertar objetos falsos en el sistema. Es un ataque contra la autenticidad. Ejemplo: suplementacin de identidades, robo de sesiones.
RAZONES PARA ATACAR LA RED DE UNA EMPRESA Dinero, ventaja econmica, ventaja competitiva, espionaje poltica,
espionaje industrial. Empleados descontentos, fraudes, extorsiones. Espacios de almacenamiento, ancho de banda, servidores de correo (SPAM). Lo que la empresa pierde. Cuanto te cuesta tener un sistema de cmputo detenida por causa de un incidente de seguridad. Costos econmicos. Costos de recuperacin. Costos de reparacin. Costos de tiempo. Costos legales. CRACKER Se refiere a las personas que rompen algn sistema de seguridad. Gobiernos extranjeros. Espas industriales o polticas. Criminales. Empleados descontentos y abusos interiores. Adolecentes sin nada que hacer. HACKERS Pirata informtico es una persona que pertenece a una de estas comunidades o subculturas distintas pero no completamente independientes: Gerente apasionado por la seguridad informtica. Esto concierte principalmente a entradas remotas.
10
NIVELES DE HACKER NIVEL 3: (ELITE): Expertos en varias reas de la informtica, son los que usualmente descubren los puntos dbiles en los sistemas y pueden crear herramientas para explotarlos. NIVEL 2: Tienen un conocimiento avanzado de la informtica y pueden obtener las herramientas creadas y pueden obtener las herramientas creadas por los del nivel 3. NIVEL 1 O SCRIPT KIDDIES: Obtienen las herramientas creadas por los de nivel 3, pero las ejecutan contra una vctima muchas veces sin saber lo que estn haciendo. ADMINISTRADORES DE LA TECNOLOGA DE INFORMACIN Son los que tienen directamente la responsabilidad de vigilar a los otros roles. Hay actividades de seguridad que deben de realizar de manera rutinaria. Obligados a capacitarse, investigar y proponer soluciones e implementarlas. PUNTOS DBILES EN LOS SISTEMAS Comunicaciones Aplicacin Servicios internos. Servicios pblicos. Sistema operativo Usuario Almacenamiento de datos SEGURIDAD DE SOFTWARE Aplica los principios de la seguridad de informacin al desarrollo de software. La seguridad de informacin se refiere a la seguridad de informacin comnmente: o Como la proteccin de sistemas de informacin contra el acceso.
11
12
INGENIERA DE SOFTWARE 4.2 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.
CICLO DE VIDA DE DESARROLLO
Anlisis de requerimientos. Diseo funcional y detallado. Codificacin. Testing/QA. Implementacin puesta en produccin.
13
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).
SEGURIDAD EN EL DISEO Antes de comenzar a escribir lneas de cdigo, hay numerosos aspectos de seguridad que deben ser tomados en cuenta durante el diseo de 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 En la etapa de codificacin, una de las reglas 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. 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 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.
15
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 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.
16
IMPLEMENTACIN / PUESTA EN PRODUCCIN
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 como: cambio de usuario y contrasea iniciales o por defecto. 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.
La integridad de seguridad a lo largo del SDLC ayuda a reducir las fallas de seguridad como as tambin los costos de la aplicacin, tanto tangibles como intangibles. 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
17
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.
18
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 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.
20
INGENIERA DE SOFTWARE 4.3 CONFIABILIDAD DEL SOFTWARE

Significa que un programa particular debe de seguir funcionando en la presencia de errores. Los errores pueden ser relacionados el 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. Software seguro debe de funcionar debajo de un ataque. Aunque casi todo el software tengan errores, la mayora de los errores nunca sern revelados debajo de circunstancias normales. Se dice que un software es confiable si realiza lo que el usuario desea, cuando as lo requiera. No es confiable si as no lo hiciera. Un software no es confiable cuando falla Las fallas se deben a errores en el software Si corregimos estos errores sin introducir nuevos, mejoramos la 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.
21
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: 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
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:
24
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
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.
25
INGENIERA DE SOFTWARE 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.
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.
26
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.
27
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 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.
28
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. PROCESO DE DEPURACIN Identificar el problema. Diagnstico del error. Correccin del error. Prueba de la correccin del error. Reinicio del programa.
DEFUNCIN DE ERRORES
ERRORES PREVIOS Persisten en el software luego de que el programador han trabajado en el corrigiendo un error o cambiado un cdigo ERRORES GENERADOS No existan en el software, hasta que son introducidos como consecuencia del debugging. MODELOS DE CONFIABILIDAD DE UN SOFTWARE Existen tres clasificaciones importantes del os modelos utilizados en el anlisis de confiabilidad de un software. Modelo de acuerdo al ciclo de vida Modelos de acuerdo a la naturaleza del proceso de falla. Modelos de acuerdo a consideraciones estructurales.
MODELOS DE ACUERDO AL CICLO DE VIDA Fase de desarrollo. o El software se prueba y se corrige. o La confiabilidad crece. Fase de validacin. o El software no se corrige, se aprueba o rechaza. Fase operacional o Validacin continua, enterada al software dependiente. Fase de mantenimiento. o Adicin de nuevas posibilidades, mejor de algoritmos.
30
INGENIERA DE SOFTWARE 4.4 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
31
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
32
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
33
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.
La ingeniera de seguridad son mtodos para disear y construir sistemas que permanezcan confiables a pensar de posibles actos maliciosos o errores de diverso tipo incluyendo las fallas de carcter fortuito. Algunos ejemplos de sistema en los que la seguridad es un aspecto fundamental son los siguientes: La contabilidad de un banco. Los cajeros automticos. Los mecanismos de proteccin fsica, como alarmas y sensores en general, destinados a detectar intrusos no deseados. Los servicios en lnea, va internet. Obviamente en aplicaciones militares. La privacidad es un tema de importancia en el caso de informacin de salud, o mala informacin obtenida a travs de los censos. La necesidad de manejar operaciones seguras en el internet, espacio en el cual los ataque del tipo negacin de servicios son comunes.
35
COMPONENTES DE UN SISTEMA SEGURO Identidad Correspondencia entre los nombres de dos principales significados que ellos se refieren a la misma persona o equipo. Secreto Se refiere al efecto del mecanismo usado para limitar el nmero de principales que tiene acceso a la informacin Confidencialidad Envuelve una obligacin de proteger el secreto de alguna otra persona u organizacin. Privacidad Es la habilidad y/o el derecho de una persona u organizacin de proteger sus secretos. Autenticidad Se refiere a integridad y frescura. Vulnerabilidad Propiedad de un sistema, o su ambiente, el cual en conjuncin con una amenaza interna o externa puede conducir a una falla de seguridad, el cual es un estado de cosas contrario a la poltica de seguridad del sistema Poltica de seguridad Declaracin sucinta de la estrategia de proteccin de un sistema Objetivo de seguridad Es una especificacin ms detallada que define los medios mediante los cuales se implementa una poltica de seguridad en un producto particular.
Perfil de proteccin Es similar al objetivo de seguridad excepto forma que est escrito en una
suficientemente genrica como para poder evaluar su efectividad con
diversos productos. La ingeniera de seguridad procede secuencialmente desde los
requerimientos de seguridad hasta la solucin, no desde la tecnologa ms novedosa. Estos significan que lo primero que hay que hacer es modelar el tipo de ataques al que se est sujeto, a partir de esto crear una poltica de seguridad y luego a partir de estos escoger la tecnologa a aplicar para evitar los riesgos antes modelados. RIESGOS DETERMINAN LA POLTICA Y ESTA DEFINE LA TECNOLOGA A UTILIZAR Pasos a seguir seran los siguientes: Comprender los riesgos reales del sistema y evaluar las probabilidades de esos riesgos. Describir la poltica de seguridad requerida para defenderse de esos ataques o riesgos. Disear las medidas de seguridad destinadas a contrarrestar esos riesgos. UNA POLTICA OBJETIVOS La poltica debe establecer: Quin es responsable (implementacin, reforzamiento, auditoria y revisin). Cules son las polticas de seguridad bsicas de la red. Por qu son implementadas en la manera en que son. DE SEGURIDAD PARA UN SISTEMA DEFINE LOS
37
INGENIERA DE SOFTWARE 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. 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.
38
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 y estn no pensados para
arquitecturas
mainframe/terminal
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. 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. 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. 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 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
42
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 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
43
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. 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.
44
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 reconstruirse. que permite que el software daado pueda
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.
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.
47
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.
48
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.
49
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 el anlisis del sistema. Ms an, las descripciones semnticas son la base para la reutilizacin de esos patrones.
50
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. 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. 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
52
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.
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.
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
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
54
55

Apuntes Unidad 4 Seguridad en Ingeniería de Software

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Apuntes Unidad 4 Seguridad en Ingeniería de Software

Uploaded by

Copyright:

Available Formats

PROFESORA

M.T.I. MONTSERRAT MASDEFIOL SUREZ

NOMBRE DEL ALUMNO:

SAN ANDRS TUXTLA, VER., 25 DE MAYO DEL 2013.

INGENIERA DE SOFTWARE NDICE

M.T.I. MONTSERRAT MASDEFIOL SUREZ

SEGURIDAD .................................................................................... 50 PROCESO DE DESARROLLO DE SOFTWARE PARA LA

M.T.I. MONTSERRAT MASDEFIOL SUREZ

INGENIERA DE SOFTWARE INTRODUCCIN

M.T.I. MONTSERRAT MASDEFIOL SUREZ

INGENIERA DE SOFTWARE UNIDAD 4 SEGURIDAD DE INGENIERA DE SOFTWARE

Propuesta de proyecto Exposicin Investigacin documental Propuesta terica

M.T.I. MONTSERRAT MASDEFIOL SUREZ

INGENIERA DE SOFTWARE 4.1 SEGURIDAD DE SOFTWARE

M.T.I. MONTSERRAT MASDEFIOL SUREZ

M.T.I. MONTSERRAT MASDEFIOL SUREZ

M.T.I. MONTSERRAT MASDEFIOL SUREZ

M.T.I. MONTSERRAT MASDEFIOL SUREZ

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

CICLO DE VIDA DE DESARROLLO

M.T.I. MONTSERRAT MASDEFIOL SUREZ

M.T.I. MONTSERRAT MASDEFIOL SUREZ

M.T.I. MONTSERRAT MASDEFIOL SUREZ

IMPLEMENTACIN / PUESTA EN PRODUCCIN

M.T.I. MONTSERRAT MASDEFIOL SUREZ

M.T.I. MONTSERRAT MASDEFIOL SUREZ

M.T.I. MONTSERRAT MASDEFIOL SUREZ

INGENIERA DE SOFTWARE 4.3 CONFIABILIDAD DEL SOFTWARE

M.T.I. MONTSERRAT MASDEFIOL SUREZ

M.T.I. MONTSERRAT MASDEFIOL SUREZ

M.T.I. MONTSERRAT MASDEFIOL SUREZ

INGENIERA DE SOFTWARE PRUEBAS DE CONFIABILIDAD

M.T.I. MONTSERRAT MASDEFIOL SUREZ

M.T.I. MONTSERRAT MASDEFIOL SUREZ

M.T.I. MONTSERRAT MASDEFIOL SUREZ

M.T.I. MONTSERRAT MASDEFIOL SUREZ

INGENIERA DE SOFTWARE 4.4 INGENIERA DE SEGURIDAD

El software de seguridad crtico se divide en dos clases:

M.T.I. MONTSERRAT MASDEFIOL SUREZ

M.T.I. MONTSERRAT MASDEFIOL SUREZ

M.T.I. MONTSERRAT MASDEFIOL SUREZ

M.T.I. MONTSERRAT MASDEFIOL SUREZ

suficientemente genrica como para poder evaluar su efectividad con

diversos productos. La ingeniera de seguridad procede secuencialmente desde los

M.T.I. MONTSERRAT MASDEFIOL SUREZ

INGENIERA DE SOFTWARE ATAQUE DE SEGURIDAD

M.T.I. MONTSERRAT MASDEFIOL SUREZ

La tabla 1.2 muestra los servicios que brindan los mecanismos.

M.T.I. MONTSERRAT MASDEFIOL SUREZ

M.T.I. MONTSERRAT MASDEFIOL SUREZ

M.T.I. MONTSERRAT MASDEFIOL SUREZ

M.T.I. MONTSERRAT MASDEFIOL SUREZ

M.T.I. MONTSERRAT MASDEFIOL SUREZ

M.T.I. MONTSERRAT MASDEFIOL SUREZ

M.T.I. MONTSERRAT MASDEFIOL SUREZ

M.T.I. MONTSERRAT MASDEFIOL SUREZ

PONS MARTORELL, MANUEL, Criptologa Obtenido en: http://www.tierradelazaro.com/public/libros/cripto.pdf

M.T.I. MONTSERRAT MASDEFIOL SUREZ

M.T.I. MONTSERRAT MASDEFIOL SUREZ

You might also like