Ingenieria de software - Unidad 4 seguridad

75
Ingeniería en Sistemas Computacionales Fundamentos de Ingeniería de Software Unidad IV: Seguridad en la Ingeniería de Software Este material está desarrollado para la asignatura Fundamentos de Ingeniería de Software, de la carrera de Ingeniería en Sistemas Computacionales, plan de estudios ISIC-2010-224 INGENIERÍA DE SOFTWARE

Transcript of Ingenieria de software - Unidad 4 seguridad

Page 1: Ingenieria de software - Unidad 4 seguridad

Ingeniería en Sistemas Computacionales

Fundamentos de Ingeniería de SoftwareUnidad IV: Seguridad en la Ingeniería

de Software

Este material está desarrollado para la asignatura Fundamentos de Ingeniería de Software, de la carrera de Ingeniería en Sistemas Computacionales, plan de estudios ISIC-2010-224

INGENIERÍA DE SOFTWARE

Page 2: Ingenieria de software - Unidad 4 seguridad

Competencia: Identificar los riesgos posibles que puede enfrentar durante el proceso de desarrollo del software y aplicar medidas de seguridad para minimizarlos.

INGENIERÍA DE SOFTWARE

Page 3: Ingenieria de software - Unidad 4 seguridad

SEGURIDAD DE SOFTWARE

• La seguridad informática es un camino, no un destino.• Su objetivo: mantener los sistemas generando resultados.• Si los sistemas no se encuentran funcionando entonces su costo se

convierte en pérdidas financieras (en el menos grave de los casos).• El resultado generado por un sistema es la información 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.

INGENIERÍA DE SOFTWARE

Page 4: Ingenieria de software - Unidad 4 seguridad

DEFINICIONES DE SEGURIDAD

• Políticas, procedimientos y técnicas 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.

INGENIERÍA DE SOFTWARE

Page 5: Ingenieria de software - Unidad 4 seguridad

IMPORTANCIA DE SEGURIDAD

• Por el dinero, el dueño 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 más esfuerzo.

• La seguridad surge tecnológicamente, la seguridad es gratis. Los sistemas operativos modernos contienen muchas características de seguridad.

• Las mejores herramientas de seguridad son ‘open source’.

INGENIERÍA DE SOFTWARE

Page 6: Ingenieria de software - Unidad 4 seguridad

USUARIOS COMUNES

• Los usuarios se acostumbran a usar la tecnología sin saber cómo funciona o de los riesgos que pueden correr.• Son las principales víctimas.• También son el punto de entrada de muchos problemas crónicos.• El eslabón más débil en la cadena de seguridad.• 2 enfoques para controlarlos.• Principio del menor privilegio posible.• Reducir la capacidad de acción del usuario sobre los sistemas.• Objetivo: lograr el menos daño posible en caso de incidentes.

INGENIERÍA DE SOFTWARE

Page 7: Ingenieria de software - Unidad 4 seguridad

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 enseña a incorporar requisitos ni protocolos de

seguridad.

INGENIERÍA DE SOFTWARE

Page 8: Ingenieria de software - Unidad 4 seguridad

PROPIEDADES DE LA INFORMACIÓN

• Confidencialidad: asegurarse que la información en un sistema de cómputo t la transmitida por un medio de comunicación, puede ser leída solo por las personas autorizadas.

• Autenticación: asegurarse que el origen de un mensaje o documento electrónico 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 información o recursos de cómputo.

INGENIERÍA DE SOFTWARE

Page 9: Ingenieria de software - Unidad 4 seguridad

• No repudiación: asegurarse que ni el emisor o receptor de un mensaje o acción sea capaz de negar lo hecho.

• Disponibilidad: requiere que los recursos de un sistema de cómputo estén disponibles en el momento que se necesiten.

INGENIERÍA DE SOFTWARE

Page 10: Ingenieria de software - Unidad 4 seguridad

ATAQUES CONTRA EL FLUJO DE LA INFORMACIÓN

Flujo normal• Los mensajes en una red se envían a partir de un emisor a uno o varios

receptores.• El atacante es un tercer elemento.

Interrupción • El mensaje no puede llegar a su destino, un recurso del sistema es destruido

o temporalmente inutilizado.• Es un ataque contra la disponibilidad.

INGENIERÍA DE SOFTWARE

Page 11: Ingenieria de software - Unidad 4 seguridad

Intercepción• Una persona, computadora o programa sin autorización logra el acceso a un

recurso controlado.• Es un ataque contra confiabilidad.

Modificación • La persona sin autorización, además de lograr el acceso modifica el

mensaje.• Ejemplo: alterar la información que se transmite en la base de datos.

INGENIERÍA DE SOFTWARE

Page 12: Ingenieria de software - Unidad 4 seguridad

Fabricación• Una persona sin autorización insertar objetos falsos en el sistema.• Es un ataque contra la autenticidad.• Ejemplo: suplementación de identidades, robo de sesiones.

INGENIERÍA DE SOFTWARE

Page 13: Ingenieria de software - Unidad 4 seguridad

RAZONES PARA ATACAR LA RED DE UNA EMPRESA• Dinero, ventaja económica, ventaja competitiva, espionaje política, espionaje industrial.• Empleados descontentos, fraudes, extorsiones.• Espacios de almacenamiento, ancho de banda, servidores de correo (SPAM).

Cuanto te cuesta tener un sistema de cómputo detenida por causa de un incidente de seguridad.

Costos económicos. Costos de recuperación. Costos de reparación. Costos de tiempo. Costos legales.

INGENIERÍA DE SOFTWARE

Page 14: Ingenieria de software - Unidad 4 seguridad

CRACKER• Se refiere a las personas que rompen algún sistema de seguridad.• Gobiernos extranjeros.• Espías industriales o políticas.• Criminales.• Empleados descontentos y abusos interiores.• Adolecentes sin nada que hacer.

INGENIERÍA DE SOFTWARE

Page 15: Ingenieria de software - Unidad 4 seguridad

HACKERS

• Pirata informático es una persona que pertenece a una de estas comunidades o subculturas distintas pero no completamente independientes:• Gerente apasionado por la seguridad informática.• Esto concierte principalmente a entradas remotas.

INGENIERÍA DE SOFTWARE

Page 16: Ingenieria de software - Unidad 4 seguridad

NIVELES DE HACKER

• NIVEL 3: (ELITE): Expertos en varias áreas de la informática, son los que usualmente descubren los puntos débiles en los sistemas y pueden crear herramientas para explotarlos.• NIVEL 2: Tienen un conocimiento avanzado de la informática 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 víctima muchas veces sin saber lo que están haciendo.

INGENIERÍA DE SOFTWARE

Page 17: Ingenieria de software - Unidad 4 seguridad

ADMINISTRADORES DE LA TECNOLOGÍA DE INFORMACIÓN• 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 DÉBILES EN LOS SISTEMAS Comunicaciones Aplicación Servicios

internos. Servicios

públicos.

Sistema operativo

Usuario Almacenamient

o de datos

INGENIERÍA DE SOFTWARE

Page 18: Ingenieria de software - Unidad 4 seguridad

SEGURIDAD DE SOFTWARE

• Aplica los principios de la seguridad de información al desarrollo de software.

• La seguridad de información se refiere a la seguridad de información comúnmente: Como la protección de sistemas de información contra el acceso.

INGENIERÍA DE SOFTWARE

Page 19: Ingenieria de software - Unidad 4 seguridad

SEGURIDAD EN EL CICLO DE DESARROLLO DEL SOFTWARE• La mayor parte de las organizaciones desarrolla o contrata el desarrollo

de aplicaciones propias para su gestión 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 periódica por el fabricante. El tratamiento de las vulnerabilidades en aplicaciones propias corre por parte de la organización que las desarrolla.

• Entre más pronto se detecten las fallas de seguridad es más económica su solución.

INGENIERÍA DE SOFTWARE

Page 20: Ingenieria de software - Unidad 4 seguridad

• Las buenas prácticas indican la conveniencia de incluir seguridad de la información 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 según la modalidad de cada organización, pero a grandes rasgos son las siguientes:

Análisis de requerimientos, Diseño funcional y detallado, Codificación, Testing/QA, Implementación/puesta en producción.

INGENIERÍA DE SOFTWARE

Page 21: Ingenieria de software - Unidad 4 seguridad

SEGURIDAD EN EL ANÁLISIS DE REQUERIMIENTOS • En esta etapa, se deben identificar aquellos requerimientos funcionales que

tendrán impacto en los aspectos de seguridad de la aplicación. Algunos de ellos son: Requerimientos de conformidad con normativas locales o

internacionales, Tipo de información que se transmitirá o procesará (por ejemplo: la

Información pública o confidencial, datos personales, datos financieros, contraseñas, datos de pago electrónico, etc.) y

Requerimientos de registros de auditoría (por ejemplo: qué debe registrar la aplicación en sus Logs).

INGENIERÍA DE SOFTWARE

Page 22: Ingenieria de software - Unidad 4 seguridad

SEGURIDAD EN EL DISEÑO• Antes de comenzar a escribir líneas de código, hay numerosos aspectos de

seguridad que deben ser tomados en cuenta durante el diseño de aplicación. Algunos de ellos son: Diseño de autorización (como definir los roles, permisos y privilegios de la

aplicación), Diseño de autenticación (se deberá diseñar el modo en el que los usuarios

se van a autenticar, contemplando aspectos tales como los mecanismos o factores de autenticación con contraseñas, tokens, certificados, etc. posibilidades de integrar la autenticación con servicios externos como LDAP, Radius o Active Directory) y los mecanismos que tendrá la aplicación para evitar ataques de diccionario o de fuerza bruta (algunos de ejemplos son bloqueo de cuentas, implementación de “captchas”, etc.),

FUNDAMENTOS DE INGENIERÍA DE SOFTWARE

Page 23: Ingenieria de software - Unidad 4 seguridad

Diseño de los mensajes de error y advertencia; para evitar que los mismos brinden demasiada información y que ésta sea utilizada por atacantes, y

Diseño de los mecanismos de protección de datos (se debe contemplar el modo en el que se protegerá la información sensible en tránsito o almacenada; según el caso, se puede definir la implementación de encriptación, hashes o truncamiento de la información).

INGENIERÍA DE SOFTWARE

Page 24: Ingenieria de software - Unidad 4 seguridad

• Una vez que se cuenta con el diseño detallado de la aplicación, una práctica interesante es la de realizar sobre el mismo un análisis de riesgo orientado a software. Existen técnicas documentadas al respecto, tales como Threat Modeling.

• Estas técnicas permiten definir un marco para identificar debilidades de seguridad en el software, antes de la etapa de codificación. Como valor agregado, del análisis de riesgo orientado a software se pueden obtener casos de prueba para ser utilizados en la etapa de Testing/QA.

INGENIERÍA DE SOFTWARE

Page 25: Ingenieria de software - Unidad 4 seguridad

SEGURIDAD EN LA CODIFICACIÓN• En la etapa de codificación, 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 diseño, los desarrolladores tendrán que codificar los

distintos componentes de la aplicación. Es en este punto en donde suelen incorporarse, por error u omisión, distintos tipos de vulnerabilidades. Estas vulnerabilidades se pueden dividir en dos grandes grupos: Vulnerabilidades clásicas, y Vulnerabilidades funcionales.

INGENIERÍA DE SOFTWARE

Page 26: Ingenieria de software - Unidad 4 seguridad

TESTING / QA DE SEGURIDAD• Tradicionalmente, la labor del equipo de Testing/QA es la de encontrar y

reportar errores funcionales de la aplicación. Para esto, se desarrollan ‘casos de test’ basados en la funcionalidad esperada.• A esto se le denomina testing funcional y básicamente consiste en validar

que la aplicación ‘haga lo que se esperaba que hiciera’. Sucede que habitualmente hay un desfasaje entre el diseño original de la aplicación (lo que se espera que haga) y la implementación real (lo que realmente hace). Aquí surgen tres áreas bien definidas: Lo que fue definido y la aplicación hace, Lo que fue definido y la aplicación no hace (errores funcionales), y Lo que no fue definido pero la aplicación hace.

INGENIERÍA DE SOFTWARE

Page 27: Ingenieria de software - Unidad 4 seguridad

.

INGENIERÍA DE SOFTWARE

Page 28: Ingenieria de software - Unidad 4 seguridad

IMPLEMENTACIÓN / PUESTA EN PRODUCCIÓN

• Tanto la aplicación como el software de base deben configurarse de manera segura al momento de poner el software en producción.• En este punto se deben contemplar tareas como: cambio de usuario y

contraseña iniciales o por defecto.• La seguridad en las aplicaciones de software debe abordarse desde el

primer día 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í también los costos de la aplicación, tanto tangibles como intangibles.

INGENIERÍA DE SOFTWARE

Page 29: Ingenieria de software - Unidad 4 seguridad

Una mala configuración al momento de implementar la aplicación podría echar por tierra toda la seguridad de las capas anteriores. Tanto la aplicación como el software de base deben configurarse de manera segura al momento de poner el software en producción. En este punto se deben contemplar tareas tales como: • Cambio de usuarios y contraseñas iniciales o por defecto, • Borrado de datos de prueba y cambio de permisos de acceso.

Es también importante mantener una correcta separación de los ambientes de desarrollo, testing y producción y procedimientos de traspaso seguro de uno a otro de estos ambientes.

INGENIERÍA DE SOFTWARE

Page 30: Ingenieria de software - Unidad 4 seguridad

CONFIABILIDAD DEL SOFTWARE

• Significa que un programa particular debe de seguir funcionando en la presencia de errores.• Los errores pueden ser relacionados el diseño, a la implementación, a la programación, o el uso

de errores.• Así como los sistemas llegan a ser cada vez más complejos, aumenta la probabilidad de errores.• Software seguro debe de funcionar debajo de un ataque.• Aunque casi todo el software tengan errores, la mayoría de los errores nunca serán 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.

INGENIERÍA DE SOFTWARE

Page 31: Ingenieria de software - Unidad 4 seguridad

• A veces los sistemas informáticos 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 confían plenamente en las computadoras personales que normalmente usan.

• La confiabilidad de un sistema informático 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 cómo se espera de él y que no fallará al utilizarlo normalmente.

INGENIERÍA DE SOFTWARE

Page 32: Ingenieria de software - Unidad 4 seguridad

• La eliminación 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 categorías: Modelos que predicen la confiabilidad como una función cronológica del

tiempo. Modelos que predicen la confiabilidad como una función del tiempo de

procesamiento transcurrido.

• Esta propiedad no se puede expresar numéricamente, sino que se utilizan términos relativos como no confiables, muy confiables y ultraconfiables para reflejar los grados de confianza que se pueden tener en un sistema.

INGENIERÍA DE SOFTWARE

Page 33: Ingenieria de software - Unidad 4 seguridad

Existen cuatro dimensiones principales de la confiabilidad:

Disponibilidad. La disponibilidad de un sistema es la probabilidad de que esté 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 valoración de la probabilidad de que el sistema cause daños a las personas o a su entorno.

Protección. La protección de un sistema es una valoración de la probabilidad de que el sistema pueda resistir al mal uso o ataques de intrusos.

INGENIERÍA DE SOFTWARE

Page 34: Ingenieria de software - Unidad 4 seguridad

INGENIERÍA DE SOFTWARE

Page 35: Ingenieria de software - Unidad 4 seguridad

Además de estas cuatro dimensiones principales, también se pueden considerar otras propiedades del sistema incluidas en el término confiabilidad:• Reparabilidad: Los fallos de funcionamiento del sistema son inevitables, pero

la interrupción causada por estos fallos se puede minimizar si el sistema se puede reparar rápidamente. La reparabilidad del software se mejora cuando se tiene acceso al código 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 cambiándolo 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.

INGENIERÍA DE SOFTWARE

Page 36: Ingenieria de software - Unidad 4 seguridad

• 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 identificación de componentes del sistema clave y en asegurar que estos pueden ofrecer un servicio de funcionamiento mínimo. Se utilizan tres estrategias para asegurar que el sistema pueda continuar funcionando con un servicio mínimo, a saber: resistencia al ataque, reconocimiento del ataque y recuperación de daños ocasionados por un ataque.• Tolerancia a errores: Esta propiedad refleja hasta qué punto el sistema ha

sido diseñado 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 automática o pedir al usuario que vuelva a introducir sus datos.

INGENIERÍA DE SOFTWARE

Page 37: Ingenieria de software - Unidad 4 seguridad

PRUEBAS DE CONFIABILIDAD• La comprobación de la confiabilidad consiste en probar una aplicación 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 aplicación, no es muy probable que encuentre todos los errores posibles de una aplicación compleja.

• No obstante, puede probar las situaciones más probables bajo condiciones normales de uso y confirmar que la aplicación proporciona el servicio previsto. Si dispone de tiempo suficiente, puede realizar pruebas más complicadas para detectar defectos menos evidentes.

INGENIERÍA DE SOFTWARE

Page 38: Ingenieria de software - Unidad 4 seguridad

TIPOS DE PRUEBAS DE CONFIABILIDAD

De Componentes. Pruebas de Estrés. De Integración. Pruebas Reales. Pruebas de Confiabilidad. Pruebas de Destrucción Aleatoria. Pruebas de Integración. Pruebas Estructurales.

INGENIERÍA DE SOFTWARE

Page 39: Ingenieria de software - Unidad 4 seguridad

• DE COMPONENTES: La idea es forzar cada componente de forma aislada más de lo que la aplicación podría experimentar en condiciones normales. Por ejemplo: usar un bucle de 1 a 10.000.000 lo más rápidamente posible y observar si hay problemas evidentes. • PRUEBAS DE ESTRÉS: Consisten en la simulación de grandes cargas de trabajo para

observar de qué forma se comporta la aplicación ante situaciones de uso intenso.• PRUEBAS DE ESTRÉS DE COMPONENTES: Con las pruebas de estrés de los

componentes, se aíslan los servicios y componentes que conforman el sistema, se infieren los métodos de navegación, de funcionamiento y de interfaz de estos servicios y componentes y se crea un cliente de prueba que llame a dichos métodos. Para aquellos métodos 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.

INGENIERÍA DE SOFTWARE

Page 40: Ingenieria de software - Unidad 4 seguridad

• PRUEBAS DE ESTRÉS DE INTEGRACIÓN: Después de forzar cada componente individual, deberá someter a una situación de estrés a toda la aplicación con todos sus componentes y servicios. Las pruebas de estrés de integración están í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 aplicación. Las pruebas de integración comienzan con una comprobación básica 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 aplicación. Las secuencias de comandos de prueba deberán probar la aplicación de acuerdo con el uso previsto.

INGENIERÍA DE SOFTWARE

Page 41: Ingenieria de software - Unidad 4 seguridad

PRUEBAS DE REALES Y DESTRUCCIÓN:

• Pruebas Reales: El software que es confiable de forma aislada en un entorno de prueba protegido puede no serlo en la implementación real. Un entorno de prueba real garantiza que las aplicaciones simultáneas no interfieren entre sí. Debe asegurarse de que la nueva aplicación puede ejecutarse con la configuración final.• Pruebas de destrucción aleatorias Una de las formas más sencillas de

probar la confiabilidad es utilizar datos de entrada aleatorios. Este tipo de pruebas intenta por todos los medios bloquear la aplicación o que ésta produzca errores; para ello, se proporcionan datos ilógicos y falsos.

INGENIERÍA DE SOFTWARE

Page 42: Ingenieria de software - Unidad 4 seguridad

PRUEBAS DE INTEGRACIÓN• Identificar errores introducidos por la combinación de programas probados

unitariamente. Verificar que las especificaciones de diseño sean alcanzadas. • Los componentes no están implementados en el ambiente operativo. La fase de

integración requiere mayor planificación y un conjunto de datos de prueba. Los sistemas grandes requieren varios pasos para realizar la integración. Existen tres tipos básicos de pruebas: Todo de una vez: provee una solución útil para realizar la integración de problemas

simples. Down-Top: Se empieza con los módulos de nivel inferior, y se verifica que los

módulos de nivel inferior llaman a los de nivel superior de manera correcta, con los parámetros correctos.

Top-Down: se empieza con los módulos de nivel superior, y se verifica que los módulos de nivel superior llaman a los de nivel inferior de manera correcta, con los parámetros correctos.

INGENIERÍA DE SOFTWARE

Page 43: Ingenieria de software - Unidad 4 seguridad

PRUEBAS ESTRUCTURALES• Son también conocidas como "pruebas de caja blanca" o "pruebas basadas

en código", donde se enfocan en probar cada una de las estructuras de código, para que su comportamiento sea el esperado.• Son las pruebas donde se conoce la estructura interna del componente a

probar, y se efectúa una prueba sobre dicha estructura. En el caso de una aplicación web también se revisa la estructura interna de los links y otros elementos.

INGENIERÍA DE SOFTWARE

Page 44: Ingenieria de software - Unidad 4 seguridad

PROCESO DE DEPURACIÓN Identificar el problema. Diagnóstico del error. Corrección del error. Prueba de la corrección del error. Reinicio del programa.

• ERRORES PREVIOS: Persisten en el software luego de que el programador han trabajado en el corrigiendo un error o cambiado un código• ERRORES GENERADOS: No existían en el software, hasta que son

introducidos como consecuencia del debugging.

INGENIERÍA DE SOFTWARE

Page 45: Ingenieria de software - Unidad 4 seguridad

MODELOS DE CONFIABILIDAD DE UN SOFTWAREExisten tres clasificaciones importantes del os modelos utilizados en el análisis 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.

El software se prueba y se corrige. La confiabilidad crece.

• Fase de validación.El software no se corrige, se aprueba o rechaza.

• Fase operacionalValidación continua, enterada al software dependiente.

• Fase de mantenimiento.Adición de nuevas posibilidades, mejor de algoritmos.

INGENIERÍA DE SOFTWARE

Page 46: Ingenieria de software - Unidad 4 seguridad

INGENIERÍA DE SEGURIDAD • En un mundo actual globalizado y sin fronteras de movilidad con respecto al

uso total de Sistemas de Información 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.• Los sistemas de seguridad críticos son sistemas en los que es esencial que el

funcionamiento del sistema sea siempre seguro. Esto es, el sistema nunca debería provocar daños en las personas o en el entorno del sistema incluso si éste falla. Ejemplos de sistemas de seguridad críticos son el control y monitorización de sistemas de un avión, sistemas de control de procesos en plantas químicas y farmacéuticas y sistemas de control de automóviles.

INGENIERÍA DE SOFTWARE

Page 47: Ingenieria de software - Unidad 4 seguridad

• El control mediante hardware de los sistemas de seguridad críticos es más sencillo de implementar y analizar que el control mediante software. Sin embargo, actualmente se están construyendo sistemas de tal complejidad que no se pueden controlar únicamente mediante hardware. Es esencial realizar algún control mediante software debido a la necesidad de gestionar un número muy grande de sensores y actuadores con leyes de control complejas.

El software de seguridad crítico se divide en dos clases: • Software de seguridad crítico 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 puede provocar lesiones personales o da un mal funcionamiento del hardware, lo que puede provocar lesiones personales o daños en el enlomo.

INGENIERÍA DE SOFTWARE

Page 48: Ingenieria de software - Unidad 4 seguridad

• Software de seguridad crítico secundario: Es el software que indirectamente puede provocar lesiones. Ejemplos de dichos sistemas son los sistemas de diseño asistido por computadora, cuyo mal funcionamiento podría provocar un defecto de diseño en el objeto que se está diseñando. Este defecto puede causar lesiones personales si el sistema diseñado no funciona bien. Otro ejemplo de un sistema de seguridad crítico secundario es una base de datos médica que contiene los detalles de los medicamentos administrados a los pacientes. Los errores en este sistema podrían dar lugar a que se administrara una dosis de medicamentos incorrecta.

INGENIERÍA DE SOFTWARE

Page 49: Ingenieria de software - Unidad 4 seguridad

• La fiabilidad y la seguridad del sistema están relacionadas, pero son distintos atributos de confiabilidad. Desde luego, un sistema de seguridad crítico es fiable si está de acuerdo con su especificación y funciona sin fallos. Dicho sistema puede incorporar características 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 aún puede funcionar mal y ocasionar un comportamiento del sistema que provoque un accidente.

INGENIERÍA DE SOFTWARE

Page 50: Ingenieria de software - Unidad 4 seguridad

La clave para garantizar la seguridad es asegurar que los accidentes no ocurran o que las consecuencias de éstos sean mínimas. Esto puede conseguirse de tres formas complementarias:• Evitación de contingencias: El sistema se diseña 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 máquina evita la contingencia de que los dedos del operador estén cerca de las cuchillas.• Detección y eliminación de contingencias: El sistema se diseña para que las

contingencias se detecten y eliminen antes de que provoquen un accidente. Por ejemplo, un sistema de una planta química puede detectar una presión excesiva y abrir una válvula de escape para reducir la presión antes de que ocurra una explosión.

INGENIERÍA DE SOFTWARE

Page 51: Ingenieria de software - Unidad 4 seguridad

• Limitación de daños: El sistema incluye características de protección que minimizan el daño que puede resultar de un accidente. Por ejemplo, el motor de un avión normalmente incluye extintores de incendios automáticos. Si se produce un fuego, a menudo éste se puede controlar antes de que suponga una amenaza para el avión.

La ingeniería de seguridad son métodos para diseñar y construir sistemas que permanezcan confiables a pensar de posibles actos maliciosos o errores de diverso tipo incluyendo las fallas de carácter fortuito.

INGENIERÍA DE SOFTWARE

Page 52: Ingenieria de software - Unidad 4 seguridad

Algunos ejemplos de sistema en los que la seguridad es un aspecto fundamental son los siguientes: La contabilidad de un banco. Los cajeros automáticos. Los mecanismos de protección física, como alarmas y sensores en general,

destinados a detectar intrusos no deseados. Los servicios en línea, vía internet. Obviamente en aplicaciones militares. La privacidad es un tema de importancia en el caso de información de

salud, o mala información obtenida a través de los censos. La necesidad de manejar operaciones seguras en el internet, espacio en el

cual los ataque del tipo negación de servicios son comunes.

INGENIERÍA DE SOFTWARE

Page 53: Ingenieria de software - Unidad 4 seguridad

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 número de principales que tiene acceso a la información.

Confiden-cialidad

• Envuelve una obligación de proteger el secreto de alguna otra persona u organización.

Privacidad

• Es la habilidad y/o el derecho de una persona u organización de proteger sus secretos.

INGENIERÍA DE SOFTWARE

Page 54: Ingenieria de software - Unidad 4 seguridad

.

ING

ENIE

RÍA

DE

SOFT

WAR

EAutenti-

cidad

• Se refiere a integridad y frescura.

Vulnerabi-lidad

• Propiedad de un sistema, o su ambiente, el cual en conjunción con una amenaza interna o externa puede conducir a una falla de seguridad, el cual es un estado de cosas contrario a la política de seguridad del sistema

Política de seguridad

• Declaración sucinta de la estrategia de protección de un sistema.

Objetivo de

seguridad

• Es una especificación más detallada que define los medios mediante los cuales se implementa una política de seguridad en un producto particular.

Perfil de protección

• Es similar al objetivo de seguridad excepto que está escrito en una forma suficientemente genérica como para poder evaluar su efectividad con diversos productos.

Page 55: Ingenieria de software - Unidad 4 seguridad

RIESGOS DETERMINAN LA POLÍTICA Y ESTA DEFINE LA TECNOLOGÍA A UTILIZARPasos a seguir serían los siguientes:

• Comprender los riesgos reales del sistema y evaluar las probabilidades de esos riesgos.• Describir la política de seguridad requerida para defenderse de esos

ataques o riesgos.• Diseñar las medidas de seguridad destinadas a contrarrestar esos riesgos.

INGENIERÍA DE SOFTWARE

Page 56: Ingenieria de software - Unidad 4 seguridad

UNA POLÍTICA DE SEGURIDAD PARA UN SISTEMA DEFINE LOS OBJETIVOSLa política debe establecer:

• Quién es responsable (implementación, reforzamiento, auditoria y revisión).• Cuáles son las políticas de seguridad básicas de la red.• Por qué son implementadas en la manera en que son.

INGENIERÍA DE SOFTWARE

Page 57: Ingenieria de software - Unidad 4 seguridad

ATAQUE DE SEGURIDAD• Hasta la aparición de la informática la valoración de los activos de una

empresa se hacía según los objetos físicos útiles, las producciones propias, las infraestructuras, la tesorería y el capital humano. Desde los últimos años se ha añadido un nuevo capital tan importante como los anteriores, el valor de la información.

• Hoy en día, la información se maneja en grandes cantidades y de procedencias muy diversas, el valor añadido de una empresa puede ser la información que maneja.

INGENIERÍA DE SOFTWARE

Page 58: Ingenieria de software - Unidad 4 seguridad

Como capital de la empresa cada vez es más importante mantener la seguridad de la información, pero también los riesgos cada vez son mayores. Estos riesgos se pueden clasificar por su procedencia en tres categorías: • Errores involuntarios de personas y/o máquinas. • Desastres naturales. • Ataques voluntarios.

Dentro de los ataques voluntarios, los problemas creados por éstos se pueden clasificar en tres familias:

INGENIERÍA DE SOFTWARE

Page 59: Ingenieria de software - Unidad 4 seguridad

Denegación de servicio: Disponibilidad. Prohibir el acceso a la información.

Observación no autorizada: Confidencialidad. Acceso a información por personas que pueden utilizarla para dañar la empresa, o sea, personas no autorizadas.

Modificación no autorizada: Integridad. Acceso a la información y modificación, ya sea borrando, cambiando, añadiendo o sustituyendo datos.

INGENIERÍA DE SOFTWARE

Page 60: Ingenieria de software - Unidad 4 seguridad

• La protección de la información es más grave desde la aparición de las redes telemáticas. Estas redes y especialmente Internet, hacen que la información sea un problema global y no aislado a las máquinas internas de la empresa. Las tecnologías aplicadas a la seguridad en redes están en su fase de desarrollo inicial, especialmente por dos motivos:

La mayoría de sistemas operativos están pensados para arquitecturas mainframe/terminal y no para arquitecturas cliente/servidor o Internet/Intranet que se utilizan actualmente.

No existen estándares ni organizaciones mundiales aceptadas por todas las empresas proveedoras de seguridad.

INGENIERÍA DE SOFTWARE

Page 61: Ingenieria de software - Unidad 4 seguridad

Al diseñar un sistema de seguridad para la empresa la pregunta es ¿existe un sistema completamente seguro? La respuesta es clara, no. En la práctica siempre existe un compromiso entre el nivel de seguridad y los parámetros:

Costes. La seguridad es proporcional al coste de las medidas de protección.

Entorno de usuario. La seguridad es opuesta a los sistemas abiertos que pretenden facilitar el acceso a cualquier usuario con o sin preparación.

Por lo tanto, la instalación de la seguridad es un problema de ingeniería, un compromiso entre gastos y facilidad de uso frente a protección. Se debe planificar y seguir los pasos siguientes:

INGENIERÍA DE SOFTWARE

Page 62: Ingenieria de software - Unidad 4 seguridad

• Estudiar los riesgos posibles, cuantificar el valor las consecuencias de estos riesgos sobre la información y valorar los costes totales.

Análisis deRiesgos

• Valorar las diferentes medidas de protección, tanto cuantitativamente como de facilidad de uso y velocidad de acceso.

Analizar las Medidas

de Protección

• Comparar los dos análisis y decidir la solución que amortiza los riesgos.

Decidir las Medidas

Adecuadas

INGENIERÍA DE SOFTWARE

Page 63: Ingenieria de software - Unidad 4 seguridad

• Adaptar la forma de trabajo de la empresa a las nuevas medidas de seguridad.

Política de Seguridad

• Mantener continuamente las medidas de seguridad así como actualizar el diseño a las nuevas realidades del capital de información.

Mantenimiento

• Planificar las actuaciones para cuando se producen ataques con o sin éxito.

Planes de Contingencia

INGENIERÍA DE SOFTWARE

Page 64: Ingenieria de software - Unidad 4 seguridad

SERVICIOS DE SEGURIDAD: Para proteger la información se utilizan los servicios de seguridad. Se pueden clasificar según su utilidad en:

• Autenticación. Asegura que el usuario y la información son auténticos. • Control de accesos. Protege la información contra accesos no deseados,

tanto físicos como lógicos. • Confidencialidad. Oculta los datos a observaciones no deseadas. • Integridad. Comprueba que la información no ha sido modificada. • No repudio. Evita que una persona autorizada sea rechazada al acceder a

la información. • Disponibilidad. Asegura la disponibilidad de todos los recursos.

INGENIERÍA DE SOFTWARE

Page 65: Ingenieria de software - Unidad 4 seguridad

MECANISMOS DE IMPLEMENTACIÓNPor el ámbito de su aplicación se pueden dividir en dos grandes familias:

• Específicos. Se aplican a una capa OSI del sistema para implementar un servicio. • Generales. Se aplican al sistema para cumplir la política general.

INGENIERÍA DE SOFTWARE

Page 66: Ingenieria de software - Unidad 4 seguridad

GENERALES

• Funcionalidad de confianza. El sistema de seguridad está libre de ataques. • Etiquetas. Clasifica la información por niveles de seguridad: secreta,

confidencial, no clasificada, etc. • Auditorias. Almacena las acciones realizadas sobre el sistema. • Detección de eventos. Detecta movimientos peligrosos dentro del sistema. • Recuperación de desastres. Todas las políticas para recuperar la

información después de un ataque con éxito: Backups, mirrors, etc. Políticas de personal. Normativas sobre las actuaciones del personal.

INGENIERÍA DE SOFTWARE

Page 67: Ingenieria de software - Unidad 4 seguridad

ESPECÍFICOS • Cifrado. Se transforman los datos para que sólo sean inteligibles a los usuarios autorizados. • Firma digital. A la información se le añaden unos datos que únicamente puede generar un

usuario concreto, además no permiten la modificación de la información por otros usuarios. • Control de accesos. No permiten el acceso físico o lógico a la información a usuarios no

autorizados. • Integridad de datos. Añaden datos a la información que detectan si ésta ha sido

modificada. • Tráfico de relleno. Inyectan tráfico sin información en las redes para confundir a los

observadores de la red.• Control de encaminamiento. Se utilizan los sistemas de encaminamiento para proteger la

información. • Notorización. Una tercera persona física o jurídica confirma la seguridad de procedencia e

integridad de los datos.

INGENIERÍA DE SOFTWARE

Page 68: Ingenieria de software - Unidad 4 seguridad

PROTECCIÓN

• La protección es un atributo del sistema que refleja su capacidad para protegerse de ataques externos que pueden ser accidentales o provocados. La protección ha adquirido cada vez más importancia en tanto que más y más 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 conexión a Internet también significa que el sistema puede ser atacado por personas con intenciones hostiles.

INGENIERÍA DE SOFTWARE

Page 69: Ingenieria de software - Unidad 4 seguridad

• En algunos sistemas críticos, la protección es la dimensión más importante de la confiabilidad del sistema. Los sistemas militares, los sistemas de comercio electrónico y los sistemas que implican el procesamiento e intercambio de información confidencial, se deben diseñar de tal forma que alcancen altos niveles de protección.

• Por ejemplo, si un sistema de reservas de boletos de avión no está disponible, esto provoca inconvenientes y algunos retrasos en la emisión de los boletos. Sin embargo, si el sistema no está protegido y puede aceptar reservas falsas, entonces la línea aérea propietaria del sistema puede perder una gran cantidad de dinero.

INGENIERÍA DE SOFTWARE

Page 70: Ingenieria de software - Unidad 4 seguridad

Existen tres tipos de daños que pueden ser causados por ataques externos:

Denegación de servicio: El sistema puede verse forzado a entrar en un estado en que sus servicios normales no están disponibles. Esto, obviamente, afecta a la disponibilidad del sistema.

Corrupción 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 daño es grave, la disponibilidad del sistema puede verse afectada.

Revelación de información confidencial: La información gestionada por el sistema puede ser confidencial y los ataques externos pueden exponerla a personas no autorizadas.

INGENIERÍA DE SOFTWARE

Page 71: Ingenieria de software - Unidad 4 seguridad

CRIPTOGRAFÍA• La criptografía es la técnica de convertir un texto inteligible, texto en claro

(plaintext), en otro, llamado criptograma (ciphertext), cuyo contenido de información es igual al anterior pero sólo lo pueden entender las personas autorizadas. El criptoanálisis es la técnica de descifrar un criptograma sin tener la autorización.• Para cifrar se debe transformar un texto mediante un método cuya función

inversa únicamente conocen las personas autorizadas. Así se puede utilizar un algoritmo secreto o un algoritmo público que utiliza una palabra, llamada clave, sólo conocida por las personas autorizadas, esta clave debe ser imprescindible para cifrar y descifrar.

INGENIERÍA DE SOFTWARE

Page 72: Ingenieria de software - Unidad 4 seguridad

INGENIERÍA DE SOFTWARE

Page 73: Ingenieria de software - Unidad 4 seguridad

Los sistemas actuales utilizan algoritmo público y claves secretas, debido a los siguientes motivos:• El nivel de seguridad es el mismo. • Los algoritmos públicos se pueden fabricar en cadena, tanto chips de

hardware como aplicaciones software. De esta manera el desarrollo es más barato. • Los algoritmos públicos están más probados, ya que toda la comunidad

científica 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 más fácil y más seguro transmitir una clave que todo el funcionamiento de

un algoritmo.

INGENIERÍA DE SOFTWARE

Page 74: Ingenieria de software - Unidad 4 seguridad

Así un sistema de comunicaciones con criptografía utiliza un algoritmo público para cifrar y otro para descifrar, pero son completamente inservibles para el criptoanalista sin el conocimiento de la clave.

INGENIERÍA DE SOFTWARE

Page 75: Ingenieria de software - Unidad 4 seguridad

BIBLIOGRAFÍA

Pressman, R.S. Ingeniería del Software un Enfoque Práctico. McGraw-Hill. Madrid, España. 2008.

Kendall E. K., Análisis y Diseño de sistemas. 1ª. Edición. Prentice Hall. México. 2005.

INGENIERÍA DE SOFTWARE