SlideShare uma empresa Scribd logo
1 de 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
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
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
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
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
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
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
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
• 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
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
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
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
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
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
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
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
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
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
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
• 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
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
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
 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
• 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
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
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
.
INGENIERÍA DE SOFTWARE
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
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
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
• 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
• 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
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
INGENIERÍA DE SOFTWARE
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
• 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
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
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
• 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
• 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
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
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
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
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
MODELOS DE CONFIABILIDAD DE UN SOFTWARE
Existen 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 operacional
Validación continua, enterada al software dependiente.
• Fase de mantenimiento.
 Adición de nuevas posibilidades, mejor de algoritmos.
INGENIERÍA DE SOFTWARE
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
• 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
• 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
• 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
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
• 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
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
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
.
INGENIERÍADESOFTWARE
Autenti-
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.
RIESGOS DETERMINAN LA POLÍTICA Y ESTA DEFINE LA TECNOLOGÍA A
UTILIZAR
Pasos 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
UNA POLÍTICA DE SEGURIDAD PARA UN SISTEMA DEFINE LOS OBJETIVOS
La 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
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
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
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
• 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
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
• Estudiar los riesgos posibles, cuantificar el valor las consecuencias de
estos riesgos sobre la información y valorar los costes totales.
Análisis de
Riesgos
• 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
• 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
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
MECANISMOS DE IMPLEMENTACIÓN
Por 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
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
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
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
• 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
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
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
INGENIERÍA DE SOFTWARE
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
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
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

Mais conteúdo relacionado

Mais procurados

Portafolio unidad 2 [Lenguajes y autómatas]- Expresiones y lenguajes regulares
Portafolio unidad 2 [Lenguajes y autómatas]- Expresiones y lenguajes regularesPortafolio unidad 2 [Lenguajes y autómatas]- Expresiones y lenguajes regulares
Portafolio unidad 2 [Lenguajes y autómatas]- Expresiones y lenguajes regularesHumano Terricola
 
Modelo de desarrollo concurrente
Modelo de desarrollo concurrenteModelo de desarrollo concurrente
Modelo de desarrollo concurrentesamuel ospino
 
3. conceptos de calidad del software
3. conceptos de calidad del software3. conceptos de calidad del software
3. conceptos de calidad del softwareJuan Pablo Carvallo
 
Cuadro comparativo estandares de calidad software
Cuadro comparativo estandares de calidad softwareCuadro comparativo estandares de calidad software
Cuadro comparativo estandares de calidad softwareHumano Terricola
 
Ventajas y desventajas de cmmi
Ventajas y desventajas de cmmiVentajas y desventajas de cmmi
Ventajas y desventajas de cmmiSandrea Rodriguez
 
Tecnicas y herramientas para el desarrollo de software
Tecnicas y herramientas para el desarrollo de softwareTecnicas y herramientas para el desarrollo de software
Tecnicas y herramientas para el desarrollo de softwareReynaldo Mayz
 
Métricas de Proceso y proyecto de software
Métricas de Proceso y proyecto de softwareMétricas de Proceso y proyecto de software
Métricas de Proceso y proyecto de softwareLorena Quiñónez
 
Protocolos de las capas sesion,presentacion y aplicacion
Protocolos de las capas sesion,presentacion y aplicacionProtocolos de las capas sesion,presentacion y aplicacion
Protocolos de las capas sesion,presentacion y aplicacionEduardo J Onofre
 
Sistemas operativos distribuidos
Sistemas operativos distribuidosSistemas operativos distribuidos
Sistemas operativos distribuidosnathalyrivasdiaz
 
Estrategias prueba de software
Estrategias prueba de softwareEstrategias prueba de software
Estrategias prueba de softwareCentro Líbano
 
Presentacion herramientas CASE
Presentacion herramientas CASEPresentacion herramientas CASE
Presentacion herramientas CASEdavidsande
 
ATRIBUTOS DE CALIDAD ARQUITECTURA DE SOFTWARE.pdf
ATRIBUTOS DE CALIDAD ARQUITECTURA DE SOFTWARE.pdfATRIBUTOS DE CALIDAD ARQUITECTURA DE SOFTWARE.pdf
ATRIBUTOS DE CALIDAD ARQUITECTURA DE SOFTWARE.pdfDavidVeraOlivera
 
Fundamentos de Pruebas de Software - Introducción
Fundamentos de Pruebas de Software - IntroducciónFundamentos de Pruebas de Software - Introducción
Fundamentos de Pruebas de Software - IntroducciónProfessional Testing
 
MODELO COCOMO (INGENIERA DE SOFTWARE)
MODELO COCOMO (INGENIERA DE SOFTWARE)MODELO COCOMO (INGENIERA DE SOFTWARE)
MODELO COCOMO (INGENIERA DE SOFTWARE)Yadith Miranda Silva
 

Mais procurados (20)

Estimación Software por Puntos de Función
Estimación Software por Puntos de FunciónEstimación Software por Puntos de Función
Estimación Software por Puntos de Función
 
Herramientas case full informacion
Herramientas case full informacionHerramientas case full informacion
Herramientas case full informacion
 
Portafolio unidad 2 [Lenguajes y autómatas]- Expresiones y lenguajes regulares
Portafolio unidad 2 [Lenguajes y autómatas]- Expresiones y lenguajes regularesPortafolio unidad 2 [Lenguajes y autómatas]- Expresiones y lenguajes regulares
Portafolio unidad 2 [Lenguajes y autómatas]- Expresiones y lenguajes regulares
 
Modelo de desarrollo concurrente
Modelo de desarrollo concurrenteModelo de desarrollo concurrente
Modelo de desarrollo concurrente
 
3. conceptos de calidad del software
3. conceptos de calidad del software3. conceptos de calidad del software
3. conceptos de calidad del software
 
Cuadro comparativo estandares de calidad software
Cuadro comparativo estandares de calidad softwareCuadro comparativo estandares de calidad software
Cuadro comparativo estandares de calidad software
 
Ventajas y desventajas de cmmi
Ventajas y desventajas de cmmiVentajas y desventajas de cmmi
Ventajas y desventajas de cmmi
 
Estimación de Proyectos de Software
Estimación de Proyectos de SoftwareEstimación de Proyectos de Software
Estimación de Proyectos de Software
 
Tecnicas y herramientas para el desarrollo de software
Tecnicas y herramientas para el desarrollo de softwareTecnicas y herramientas para el desarrollo de software
Tecnicas y herramientas para el desarrollo de software
 
2. El proceso del software
2. El proceso del software2. El proceso del software
2. El proceso del software
 
Métricas de Proceso y proyecto de software
Métricas de Proceso y proyecto de softwareMétricas de Proceso y proyecto de software
Métricas de Proceso y proyecto de software
 
Protocolos de las capas sesion,presentacion y aplicacion
Protocolos de las capas sesion,presentacion y aplicacionProtocolos de las capas sesion,presentacion y aplicacion
Protocolos de las capas sesion,presentacion y aplicacion
 
Sistemas operativos distribuidos
Sistemas operativos distribuidosSistemas operativos distribuidos
Sistemas operativos distribuidos
 
Estrategias prueba de software
Estrategias prueba de softwareEstrategias prueba de software
Estrategias prueba de software
 
Presentacion herramientas CASE
Presentacion herramientas CASEPresentacion herramientas CASE
Presentacion herramientas CASE
 
Guia iso 9126
Guia iso 9126Guia iso 9126
Guia iso 9126
 
ATRIBUTOS DE CALIDAD ARQUITECTURA DE SOFTWARE.pdf
ATRIBUTOS DE CALIDAD ARQUITECTURA DE SOFTWARE.pdfATRIBUTOS DE CALIDAD ARQUITECTURA DE SOFTWARE.pdf
ATRIBUTOS DE CALIDAD ARQUITECTURA DE SOFTWARE.pdf
 
Fundamentos de Pruebas de Software - Introducción
Fundamentos de Pruebas de Software - IntroducciónFundamentos de Pruebas de Software - Introducción
Fundamentos de Pruebas de Software - Introducción
 
Iso 12207
Iso 12207Iso 12207
Iso 12207
 
MODELO COCOMO (INGENIERA DE SOFTWARE)
MODELO COCOMO (INGENIERA DE SOFTWARE)MODELO COCOMO (INGENIERA DE SOFTWARE)
MODELO COCOMO (INGENIERA DE SOFTWARE)
 

Destaque

Seguridad en la ingeniería de software
Seguridad en la ingeniería de software Seguridad en la ingeniería de software
Seguridad en la ingeniería de software kratosVA
 
Ingenieria de software - Unidad 3 arquitecturas de software
Ingenieria de software - Unidad 3 arquitecturas de softwareIngenieria de software - Unidad 3 arquitecturas de software
Ingenieria de software - Unidad 3 arquitecturas de softwareJosé Antonio Sandoval Acosta
 
Programacion de base de datos - unidad 3 Programacion de base de datos
Programacion de base de datos - unidad 3 Programacion de base de datosProgramacion de base de datos - unidad 3 Programacion de base de datos
Programacion de base de datos - unidad 3 Programacion de base de datosJosé Antonio Sandoval Acosta
 
Tópicos Avanzados de Programación - Unidad 4 Acceso a datos
Tópicos Avanzados de Programación - Unidad 4 Acceso a datosTópicos Avanzados de Programación - Unidad 4 Acceso a datos
Tópicos Avanzados de Programación - Unidad 4 Acceso a datosJosé Antonio Sandoval Acosta
 
Fundamentos de ingenieria de Sosftware - Unidad 2 metodologias de desarrollo
Fundamentos de ingenieria de Sosftware - Unidad 2 metodologias de desarrolloFundamentos de ingenieria de Sosftware - Unidad 2 metodologias de desarrollo
Fundamentos de ingenieria de Sosftware - Unidad 2 metodologias de desarrolloJosé Antonio Sandoval Acosta
 
Fundamentos de Telecomunicaciones - Unidad 1 conceptos basicos
Fundamentos de Telecomunicaciones - Unidad 1 conceptos basicosFundamentos de Telecomunicaciones - Unidad 1 conceptos basicos
Fundamentos de Telecomunicaciones - Unidad 1 conceptos basicosJosé Antonio Sandoval Acosta
 
Bases de Datos para Dispositivos Móviles - Unidad I Introducción a la Progra...
Bases de Datos para Dispositivos Móviles - Unidad I Introducción a la Progra...Bases de Datos para Dispositivos Móviles - Unidad I Introducción a la Progra...
Bases de Datos para Dispositivos Móviles - Unidad I Introducción a la Progra...José Antonio Sandoval Acosta
 
Bases de Datos para Dispositivos Móviles - Unidad II: Arquitectura de Base de...
Bases de Datos para Dispositivos Móviles - Unidad II: Arquitectura de Base de...Bases de Datos para Dispositivos Móviles - Unidad II: Arquitectura de Base de...
Bases de Datos para Dispositivos Móviles - Unidad II: Arquitectura de Base de...José Antonio Sandoval Acosta
 
M1 actividad 3.1 - Presentación dimensión académica
M1 actividad 3.1 - Presentación dimensión académicaM1 actividad 3.1 - Presentación dimensión académica
M1 actividad 3.1 - Presentación dimensión académicaJosé Antonio Sandoval Acosta
 
BD para Dispositivos Moviles - Unidad 3 SMBD Moviles
BD para Dispositivos Moviles - Unidad 3 SMBD MovilesBD para Dispositivos Moviles - Unidad 3 SMBD Moviles
BD para Dispositivos Moviles - Unidad 3 SMBD MovilesJosé Antonio Sandoval Acosta
 
Tópicos Avanzados de Programación - Unidad 2 componentes y librerias
Tópicos Avanzados de Programación - Unidad 2 componentes y libreriasTópicos Avanzados de Programación - Unidad 2 componentes y librerias
Tópicos Avanzados de Programación - Unidad 2 componentes y libreriasJosé Antonio Sandoval Acosta
 
Simulacion para ISC - Unidad 1 Introducción a la Simulación
Simulacion para ISC - Unidad 1 Introducción a la SimulaciónSimulacion para ISC - Unidad 1 Introducción a la Simulación
Simulacion para ISC - Unidad 1 Introducción a la SimulaciónJosé Antonio Sandoval Acosta
 
Estructura de Datos - Unidad 5 metodos de ordenamiento
Estructura de Datos - Unidad 5 metodos de ordenamientoEstructura de Datos - Unidad 5 metodos de ordenamiento
Estructura de Datos - Unidad 5 metodos de ordenamientoJosé Antonio Sandoval Acosta
 
Estructura de Datos - Unidad 4 Estructuras no lineales
Estructura de Datos - Unidad 4 Estructuras no linealesEstructura de Datos - Unidad 4 Estructuras no lineales
Estructura de Datos - Unidad 4 Estructuras no linealesJosé Antonio Sandoval Acosta
 
Programación de Base de Datos - Unidad II: Aplicaciones con Arquitectura Clie...
Programación de Base de Datos - Unidad II: Aplicaciones con Arquitectura Clie...Programación de Base de Datos - Unidad II: Aplicaciones con Arquitectura Clie...
Programación de Base de Datos - Unidad II: Aplicaciones con Arquitectura Clie...José Antonio Sandoval Acosta
 
Estructura de Datos - Unidad III Estructuras Lineales
Estructura de Datos - Unidad III Estructuras LinealesEstructura de Datos - Unidad III Estructuras Lineales
Estructura de Datos - Unidad III Estructuras LinealesJosé Antonio Sandoval Acosta
 
Fundamentos de Ingenieria de Software - Unidad 1 modelo de negocios
Fundamentos de Ingenieria de Software - Unidad 1 modelo de negociosFundamentos de Ingenieria de Software - Unidad 1 modelo de negocios
Fundamentos de Ingenieria de Software - Unidad 1 modelo de negociosJosé Antonio Sandoval Acosta
 
Fundamentos de Programacion - Unidad 4 control de flujo
Fundamentos de Programacion - Unidad 4 control de flujoFundamentos de Programacion - Unidad 4 control de flujo
Fundamentos de Programacion - Unidad 4 control de flujoJosé Antonio Sandoval Acosta
 

Destaque (20)

Seguridad en la ingeniería de software
Seguridad en la ingeniería de software Seguridad en la ingeniería de software
Seguridad en la ingeniería de software
 
M2 actividad 2.3 INSTRUMENTACIÓN DIDÁCTICA 2015
M2 actividad 2.3 INSTRUMENTACIÓN DIDÁCTICA 2015 M2 actividad 2.3 INSTRUMENTACIÓN DIDÁCTICA 2015
M2 actividad 2.3 INSTRUMENTACIÓN DIDÁCTICA 2015
 
Ingenieria de software - Unidad 3 arquitecturas de software
Ingenieria de software - Unidad 3 arquitecturas de softwareIngenieria de software - Unidad 3 arquitecturas de software
Ingenieria de software - Unidad 3 arquitecturas de software
 
Programacion de base de datos - unidad 3 Programacion de base de datos
Programacion de base de datos - unidad 3 Programacion de base de datosProgramacion de base de datos - unidad 3 Programacion de base de datos
Programacion de base de datos - unidad 3 Programacion de base de datos
 
Tópicos Avanzados de Programación - Unidad 4 Acceso a datos
Tópicos Avanzados de Programación - Unidad 4 Acceso a datosTópicos Avanzados de Programación - Unidad 4 Acceso a datos
Tópicos Avanzados de Programación - Unidad 4 Acceso a datos
 
Fundamentos de ingenieria de Sosftware - Unidad 2 metodologias de desarrollo
Fundamentos de ingenieria de Sosftware - Unidad 2 metodologias de desarrolloFundamentos de ingenieria de Sosftware - Unidad 2 metodologias de desarrollo
Fundamentos de ingenieria de Sosftware - Unidad 2 metodologias de desarrollo
 
Fundamentos de Telecomunicaciones - Unidad 1 conceptos basicos
Fundamentos de Telecomunicaciones - Unidad 1 conceptos basicosFundamentos de Telecomunicaciones - Unidad 1 conceptos basicos
Fundamentos de Telecomunicaciones - Unidad 1 conceptos basicos
 
Bases de Datos para Dispositivos Móviles - Unidad I Introducción a la Progra...
Bases de Datos para Dispositivos Móviles - Unidad I Introducción a la Progra...Bases de Datos para Dispositivos Móviles - Unidad I Introducción a la Progra...
Bases de Datos para Dispositivos Móviles - Unidad I Introducción a la Progra...
 
Bases de Datos para Dispositivos Móviles - Unidad II: Arquitectura de Base de...
Bases de Datos para Dispositivos Móviles - Unidad II: Arquitectura de Base de...Bases de Datos para Dispositivos Móviles - Unidad II: Arquitectura de Base de...
Bases de Datos para Dispositivos Móviles - Unidad II: Arquitectura de Base de...
 
M1 actividad 3.1 - Presentación dimensión académica
M1 actividad 3.1 - Presentación dimensión académicaM1 actividad 3.1 - Presentación dimensión académica
M1 actividad 3.1 - Presentación dimensión académica
 
Estructura de Datos - Unidad 6 Metodos de busqueda
Estructura de Datos - Unidad 6 Metodos de busquedaEstructura de Datos - Unidad 6 Metodos de busqueda
Estructura de Datos - Unidad 6 Metodos de busqueda
 
BD para Dispositivos Moviles - Unidad 3 SMBD Moviles
BD para Dispositivos Moviles - Unidad 3 SMBD MovilesBD para Dispositivos Moviles - Unidad 3 SMBD Moviles
BD para Dispositivos Moviles - Unidad 3 SMBD Moviles
 
Tópicos Avanzados de Programación - Unidad 2 componentes y librerias
Tópicos Avanzados de Programación - Unidad 2 componentes y libreriasTópicos Avanzados de Programación - Unidad 2 componentes y librerias
Tópicos Avanzados de Programación - Unidad 2 componentes y librerias
 
Simulacion para ISC - Unidad 1 Introducción a la Simulación
Simulacion para ISC - Unidad 1 Introducción a la SimulaciónSimulacion para ISC - Unidad 1 Introducción a la Simulación
Simulacion para ISC - Unidad 1 Introducción a la Simulación
 
Estructura de Datos - Unidad 5 metodos de ordenamiento
Estructura de Datos - Unidad 5 metodos de ordenamientoEstructura de Datos - Unidad 5 metodos de ordenamiento
Estructura de Datos - Unidad 5 metodos de ordenamiento
 
Estructura de Datos - Unidad 4 Estructuras no lineales
Estructura de Datos - Unidad 4 Estructuras no linealesEstructura de Datos - Unidad 4 Estructuras no lineales
Estructura de Datos - Unidad 4 Estructuras no lineales
 
Programación de Base de Datos - Unidad II: Aplicaciones con Arquitectura Clie...
Programación de Base de Datos - Unidad II: Aplicaciones con Arquitectura Clie...Programación de Base de Datos - Unidad II: Aplicaciones con Arquitectura Clie...
Programación de Base de Datos - Unidad II: Aplicaciones con Arquitectura Clie...
 
Estructura de Datos - Unidad III Estructuras Lineales
Estructura de Datos - Unidad III Estructuras LinealesEstructura de Datos - Unidad III Estructuras Lineales
Estructura de Datos - Unidad III Estructuras Lineales
 
Fundamentos de Ingenieria de Software - Unidad 1 modelo de negocios
Fundamentos de Ingenieria de Software - Unidad 1 modelo de negociosFundamentos de Ingenieria de Software - Unidad 1 modelo de negocios
Fundamentos de Ingenieria de Software - Unidad 1 modelo de negocios
 
Fundamentos de Programacion - Unidad 4 control de flujo
Fundamentos de Programacion - Unidad 4 control de flujoFundamentos de Programacion - Unidad 4 control de flujo
Fundamentos de Programacion - Unidad 4 control de flujo
 

Semelhante a Ingenieria de software - Unidad 4 seguridad

Origen de los_problemas_de_seguridad_informatica_nuevo
Origen de los_problemas_de_seguridad_informatica_nuevoOrigen de los_problemas_de_seguridad_informatica_nuevo
Origen de los_problemas_de_seguridad_informatica_nuevoJhanz Sanchez
 
Seguridad informatica (clase 2)
Seguridad informatica (clase 2)Seguridad informatica (clase 2)
Seguridad informatica (clase 2)Haruckar
 
Seguridad informatica 2
Seguridad informatica 2Seguridad informatica 2
Seguridad informatica 2danny1712
 
Seguridad informatica 2
Seguridad informatica 2Seguridad informatica 2
Seguridad informatica 2danny1712
 
Seguridad informática TAREA FINAL DEL SEMESTRE LOS 6 EQUIPOS EN POWER POINT
Seguridad informática TAREA FINAL DEL SEMESTRE LOS 6 EQUIPOS EN POWER POINTSeguridad informática TAREA FINAL DEL SEMESTRE LOS 6 EQUIPOS EN POWER POINT
Seguridad informática TAREA FINAL DEL SEMESTRE LOS 6 EQUIPOS EN POWER POINTyair juarez
 
03SeguridadenInformaticaV1.0.pptx
03SeguridadenInformaticaV1.0.pptx03SeguridadenInformaticaV1.0.pptx
03SeguridadenInformaticaV1.0.pptxJhon887166
 
03 seguridadeninformaticav1.0
03 seguridadeninformaticav1.003 seguridadeninformaticav1.0
03 seguridadeninformaticav1.0OttoLpezAguilar
 
Origen de los_problemas_de_seguridad_informatica_nuevo[1]
Origen de los_problemas_de_seguridad_informatica_nuevo[1]Origen de los_problemas_de_seguridad_informatica_nuevo[1]
Origen de los_problemas_de_seguridad_informatica_nuevo[1]yuliaranda
 
Origen de los_problemas_de_seguridad_informatica_nuevo[1]
Origen de los_problemas_de_seguridad_informatica_nuevo[1]Origen de los_problemas_de_seguridad_informatica_nuevo[1]
Origen de los_problemas_de_seguridad_informatica_nuevo[1]yuliaranda
 
Origen de los_problemas_de_seguridad_informatica_nuevo[1]
Origen de los_problemas_de_seguridad_informatica_nuevo[1]Origen de los_problemas_de_seguridad_informatica_nuevo[1]
Origen de los_problemas_de_seguridad_informatica_nuevo[1]yuliaranda
 
Origen de los_problemas_de_seguridad_informatica_nuevo[1]
Origen de los_problemas_de_seguridad_informatica_nuevo[1]Origen de los_problemas_de_seguridad_informatica_nuevo[1]
Origen de los_problemas_de_seguridad_informatica_nuevo[1]yuliaranda
 
Origen de los_problemas_de_seguridad_informatica_nuevo
Origen de los_problemas_de_seguridad_informatica_nuevoOrigen de los_problemas_de_seguridad_informatica_nuevo
Origen de los_problemas_de_seguridad_informatica_nuevoKatherine Reinoso
 
Seguridad informática
Seguridad informática Seguridad informática
Seguridad informática Alexader
 

Semelhante a Ingenieria de software - Unidad 4 seguridad (20)

Origen de los_problemas_de_seguridad_informatica_nuevo
Origen de los_problemas_de_seguridad_informatica_nuevoOrigen de los_problemas_de_seguridad_informatica_nuevo
Origen de los_problemas_de_seguridad_informatica_nuevo
 
Seguridad informatica (clase 2)
Seguridad informatica (clase 2)Seguridad informatica (clase 2)
Seguridad informatica (clase 2)
 
Seguridad informatica 2
Seguridad informatica 2Seguridad informatica 2
Seguridad informatica 2
 
Seguridad informatica 2
Seguridad informatica 2Seguridad informatica 2
Seguridad informatica 2
 
Seguridad informática TAREA FINAL DEL SEMESTRE LOS 6 EQUIPOS EN POWER POINT
Seguridad informática TAREA FINAL DEL SEMESTRE LOS 6 EQUIPOS EN POWER POINTSeguridad informática TAREA FINAL DEL SEMESTRE LOS 6 EQUIPOS EN POWER POINT
Seguridad informática TAREA FINAL DEL SEMESTRE LOS 6 EQUIPOS EN POWER POINT
 
Seguridad de redes informaticas
Seguridad de redes informaticasSeguridad de redes informaticas
Seguridad de redes informaticas
 
S2 cdsi1
S2 cdsi1S2 cdsi1
S2 cdsi1
 
S2 cdsi1-1
S2 cdsi1-1S2 cdsi1-1
S2 cdsi1-1
 
03SeguridadenInformaticaV1.0.pptx
03SeguridadenInformaticaV1.0.pptx03SeguridadenInformaticaV1.0.pptx
03SeguridadenInformaticaV1.0.pptx
 
Tarea de-maria
Tarea de-mariaTarea de-maria
Tarea de-maria
 
Tarea de-maria
Tarea de-mariaTarea de-maria
Tarea de-maria
 
Tarea de-maria
Tarea de-mariaTarea de-maria
Tarea de-maria
 
03 seguridadeninformaticav1.0
03 seguridadeninformaticav1.003 seguridadeninformaticav1.0
03 seguridadeninformaticav1.0
 
Origen de los_problemas_de_seguridad_informatica_nuevo[1]
Origen de los_problemas_de_seguridad_informatica_nuevo[1]Origen de los_problemas_de_seguridad_informatica_nuevo[1]
Origen de los_problemas_de_seguridad_informatica_nuevo[1]
 
Origen de los_problemas_de_seguridad_informatica_nuevo[1]
Origen de los_problemas_de_seguridad_informatica_nuevo[1]Origen de los_problemas_de_seguridad_informatica_nuevo[1]
Origen de los_problemas_de_seguridad_informatica_nuevo[1]
 
Origen de los_problemas_de_seguridad_informatica_nuevo[1]
Origen de los_problemas_de_seguridad_informatica_nuevo[1]Origen de los_problemas_de_seguridad_informatica_nuevo[1]
Origen de los_problemas_de_seguridad_informatica_nuevo[1]
 
Origen de los_problemas_de_seguridad_informatica_nuevo[1]
Origen de los_problemas_de_seguridad_informatica_nuevo[1]Origen de los_problemas_de_seguridad_informatica_nuevo[1]
Origen de los_problemas_de_seguridad_informatica_nuevo[1]
 
Origen de los_problemas_de_seguridad_informatica_nuevo
Origen de los_problemas_de_seguridad_informatica_nuevoOrigen de los_problemas_de_seguridad_informatica_nuevo
Origen de los_problemas_de_seguridad_informatica_nuevo
 
Seguridad informática
Seguridad informática Seguridad informática
Seguridad informática
 
Impacto computadoras web
Impacto computadoras webImpacto computadoras web
Impacto computadoras web
 

Mais de José Antonio Sandoval Acosta

Ing. Mecatronica Prog. Básica U4 Arreglos y estructuras
Ing. Mecatronica Prog. Básica U4 Arreglos y estructurasIng. Mecatronica Prog. Básica U4 Arreglos y estructuras
Ing. Mecatronica Prog. Básica U4 Arreglos y estructurasJosé Antonio Sandoval Acosta
 
Ing. Mecatrónica, Prog. Básica U3 control de flujo
Ing. Mecatrónica, Prog. Básica U3 control de flujoIng. Mecatrónica, Prog. Básica U3 control de flujo
Ing. Mecatrónica, Prog. Básica U3 control de flujoJosé Antonio Sandoval Acosta
 
Ing. Mecatrónica, Prog. Básica, U2 intro a la programacion
Ing. Mecatrónica, Prog. Básica, U2 intro a la programacionIng. Mecatrónica, Prog. Básica, U2 intro a la programacion
Ing. Mecatrónica, Prog. Básica, U2 intro a la programacionJosé Antonio Sandoval Acosta
 
Ing. Mecatrónica, Prog. Básica U1; Conceptos basicos y algoritmos
Ing. Mecatrónica, Prog. Básica U1; Conceptos basicos y algoritmosIng. Mecatrónica, Prog. Básica U1; Conceptos basicos y algoritmos
Ing. Mecatrónica, Prog. Básica U1; Conceptos basicos y algoritmosJosé Antonio Sandoval Acosta
 

Mais de José Antonio Sandoval Acosta (20)

Linea del tiempo de la inteligencia artificial.pptx
Linea del tiempo de la inteligencia artificial.pptxLinea del tiempo de la inteligencia artificial.pptx
Linea del tiempo de la inteligencia artificial.pptx
 
UNIDAD 2 CLASIFICACION DE LOS MATERIALES.pptx
UNIDAD 2 CLASIFICACION DE LOS  MATERIALES.pptxUNIDAD 2 CLASIFICACION DE LOS  MATERIALES.pptx
UNIDAD 2 CLASIFICACION DE LOS MATERIALES.pptx
 
croquis de aulas UAIM topolobampo FEB 2024
croquis de aulas UAIM topolobampo  FEB 2024croquis de aulas UAIM topolobampo  FEB 2024
croquis de aulas UAIM topolobampo FEB 2024
 
Ing. Mecatronica Prog. Básica, U5 Módulos
Ing. Mecatronica Prog. Básica, U5 MódulosIng. Mecatronica Prog. Básica, U5 Módulos
Ing. Mecatronica Prog. Básica, U5 Módulos
 
Ing. Mecatronica Prog. Básica U4 Arreglos y estructuras
Ing. Mecatronica Prog. Básica U4 Arreglos y estructurasIng. Mecatronica Prog. Básica U4 Arreglos y estructuras
Ing. Mecatronica Prog. Básica U4 Arreglos y estructuras
 
Ing. Mecatrónica, Prog. Básica U3 control de flujo
Ing. Mecatrónica, Prog. Básica U3 control de flujoIng. Mecatrónica, Prog. Básica U3 control de flujo
Ing. Mecatrónica, Prog. Básica U3 control de flujo
 
Ing. Mecatrónica, Prog. Básica, U2 intro a la programacion
Ing. Mecatrónica, Prog. Básica, U2 intro a la programacionIng. Mecatrónica, Prog. Básica, U2 intro a la programacion
Ing. Mecatrónica, Prog. Básica, U2 intro a la programacion
 
Ing. Mecatrónica, Prog. Básica U1; Conceptos basicos y algoritmos
Ing. Mecatrónica, Prog. Básica U1; Conceptos basicos y algoritmosIng. Mecatrónica, Prog. Básica U1; Conceptos basicos y algoritmos
Ing. Mecatrónica, Prog. Básica U1; Conceptos basicos y algoritmos
 
Manual de prácticas y antología para POO
Manual de prácticas y antología para  POOManual de prácticas y antología para  POO
Manual de prácticas y antología para POO
 
Aplicaciones móviles intro.
Aplicaciones móviles intro.Aplicaciones móviles intro.
Aplicaciones móviles intro.
 
Economia
EconomiaEconomia
Economia
 
ISCA-quimica-Equipo 2.pptx
ISCA-quimica-Equipo 2.pptxISCA-quimica-Equipo 2.pptx
ISCA-quimica-Equipo 2.pptx
 
Plantilla presentación.pptx
Plantilla presentación.pptxPlantilla presentación.pptx
Plantilla presentación.pptx
 
kitchenham.pptx
kitchenham.pptxkitchenham.pptx
kitchenham.pptx
 
Diagrama de Casos de Uso UML
Diagrama de Casos de Uso UMLDiagrama de Casos de Uso UML
Diagrama de Casos de Uso UML
 
Introducción al Diagrama de Clases UML
Introducción al Diagrama de Clases UMLIntroducción al Diagrama de Clases UML
Introducción al Diagrama de Clases UML
 
Diagrama de clases UML
Diagrama de clases UMLDiagrama de clases UML
Diagrama de clases UML
 
Diagrama UML Casos de Uso
Diagrama UML Casos de UsoDiagrama UML Casos de Uso
Diagrama UML Casos de Uso
 
Tema 3 - Comandos básicos.pdf
Tema 3 - Comandos básicos.pdfTema 3 - Comandos básicos.pdf
Tema 3 - Comandos básicos.pdf
 
Tema 1 - Intro.pdf
Tema 1 - Intro.pdfTema 1 - Intro.pdf
Tema 1 - Intro.pdf
 

Último

Obras paralizadas en el sector construcción
Obras paralizadas en el sector construcciónObras paralizadas en el sector construcción
Obras paralizadas en el sector construcciónXimenaFallaLecca1
 
UNIDAD 3 ELECTRODOS.pptx para biopotenciales
UNIDAD 3 ELECTRODOS.pptx para biopotencialesUNIDAD 3 ELECTRODOS.pptx para biopotenciales
UNIDAD 3 ELECTRODOS.pptx para biopotencialesElianaCceresTorrico
 
Clase 7 MECÁNICA DE FLUIDOS 2 INGENIERIA CIVIL
Clase 7 MECÁNICA DE FLUIDOS 2 INGENIERIA CIVILClase 7 MECÁNICA DE FLUIDOS 2 INGENIERIA CIVIL
Clase 7 MECÁNICA DE FLUIDOS 2 INGENIERIA CIVILProblemSolved
 
ECONOMIA APLICADA SEMANA 555555555555555555.pdf
ECONOMIA APLICADA SEMANA 555555555555555555.pdfECONOMIA APLICADA SEMANA 555555555555555555.pdf
ECONOMIA APLICADA SEMANA 555555555555555555.pdffredyflores58
 
Magnetismo y electromagnetismo principios
Magnetismo y electromagnetismo principiosMagnetismo y electromagnetismo principios
Magnetismo y electromagnetismo principiosMarceloQuisbert6
 
Comite Operativo Ciberseguridad 012020.pptx
Comite Operativo Ciberseguridad 012020.pptxComite Operativo Ciberseguridad 012020.pptx
Comite Operativo Ciberseguridad 012020.pptxClaudiaPerez86192
 
CARGAS VIVAS Y CARGAS MUERTASEXPOCI.pptx
CARGAS VIVAS Y CARGAS MUERTASEXPOCI.pptxCARGAS VIVAS Y CARGAS MUERTASEXPOCI.pptx
CARGAS VIVAS Y CARGAS MUERTASEXPOCI.pptxvalenciaespinozadavi1
 
TEXTO UNICO DE LA LEY-DE-CONTRATACIONES-ESTADO.pdf
TEXTO UNICO DE LA LEY-DE-CONTRATACIONES-ESTADO.pdfTEXTO UNICO DE LA LEY-DE-CONTRATACIONES-ESTADO.pdf
TEXTO UNICO DE LA LEY-DE-CONTRATACIONES-ESTADO.pdfXimenaFallaLecca1
 
desarrollodeproyectoss inge. industrial
desarrollodeproyectoss  inge. industrialdesarrollodeproyectoss  inge. industrial
desarrollodeproyectoss inge. industrialGibranDiaz7
 
Mapas y cartas topográficas y de suelos.pptx
Mapas y cartas topográficas y de suelos.pptxMapas y cartas topográficas y de suelos.pptx
Mapas y cartas topográficas y de suelos.pptxMONICADELROCIOMUNZON1
 
NTP- Determinación de Cloruros en suelos y agregados (1) (1).pptx
NTP- Determinación de Cloruros  en suelos y agregados (1) (1).pptxNTP- Determinación de Cloruros  en suelos y agregados (1) (1).pptx
NTP- Determinación de Cloruros en suelos y agregados (1) (1).pptxBRAYANJOSEPTSANJINEZ
 
Ingeniería clínica 1 Ingeniería biomedica
Ingeniería clínica 1 Ingeniería biomedicaIngeniería clínica 1 Ingeniería biomedica
Ingeniería clínica 1 Ingeniería biomedicaANACENIMENDEZ1
 
LA APLICACIÓN DE LAS PROPIEDADES TEXTUALES A LOS TEXTOS.pdf
LA APLICACIÓN DE LAS PROPIEDADES TEXTUALES A LOS TEXTOS.pdfLA APLICACIÓN DE LAS PROPIEDADES TEXTUALES A LOS TEXTOS.pdf
LA APLICACIÓN DE LAS PROPIEDADES TEXTUALES A LOS TEXTOS.pdfbcondort
 
aCARGA y FUERZA UNI 19 marzo 2024-22.ppt
aCARGA y FUERZA UNI 19 marzo 2024-22.pptaCARGA y FUERZA UNI 19 marzo 2024-22.ppt
aCARGA y FUERZA UNI 19 marzo 2024-22.pptCRISTOFERSERGIOCANAL
 
CLASe número 4 fotogrametria Y PARALAJE.pptx
CLASe número 4 fotogrametria Y PARALAJE.pptxCLASe número 4 fotogrametria Y PARALAJE.pptx
CLASe número 4 fotogrametria Y PARALAJE.pptxbingoscarlet
 
ECONOMIA APLICADA SEMANA 555555555544.pdf
ECONOMIA APLICADA SEMANA 555555555544.pdfECONOMIA APLICADA SEMANA 555555555544.pdf
ECONOMIA APLICADA SEMANA 555555555544.pdfmatepura
 
01 MATERIALES AERONAUTICOS VARIOS clase 1.ppt
01 MATERIALES AERONAUTICOS VARIOS clase 1.ppt01 MATERIALES AERONAUTICOS VARIOS clase 1.ppt
01 MATERIALES AERONAUTICOS VARIOS clase 1.pptoscarvielma45
 
TAREA 8 CORREDOR INTEROCEÁNICO DEL PAÍS.pdf
TAREA 8 CORREDOR INTEROCEÁNICO DEL PAÍS.pdfTAREA 8 CORREDOR INTEROCEÁNICO DEL PAÍS.pdf
TAREA 8 CORREDOR INTEROCEÁNICO DEL PAÍS.pdfAntonioGonzalezIzqui
 
CAPITULO 4 ANODIZADO DE ALUMINIO ,OBTENCION Y PROCESO
CAPITULO 4 ANODIZADO DE ALUMINIO ,OBTENCION Y PROCESOCAPITULO 4 ANODIZADO DE ALUMINIO ,OBTENCION Y PROCESO
CAPITULO 4 ANODIZADO DE ALUMINIO ,OBTENCION Y PROCESOLUISDAVIDVIZARRETARA
 

Último (20)

VALORIZACION Y LIQUIDACION MIGUEL SALINAS.pdf
VALORIZACION Y LIQUIDACION MIGUEL SALINAS.pdfVALORIZACION Y LIQUIDACION MIGUEL SALINAS.pdf
VALORIZACION Y LIQUIDACION MIGUEL SALINAS.pdf
 
Obras paralizadas en el sector construcción
Obras paralizadas en el sector construcciónObras paralizadas en el sector construcción
Obras paralizadas en el sector construcción
 
UNIDAD 3 ELECTRODOS.pptx para biopotenciales
UNIDAD 3 ELECTRODOS.pptx para biopotencialesUNIDAD 3 ELECTRODOS.pptx para biopotenciales
UNIDAD 3 ELECTRODOS.pptx para biopotenciales
 
Clase 7 MECÁNICA DE FLUIDOS 2 INGENIERIA CIVIL
Clase 7 MECÁNICA DE FLUIDOS 2 INGENIERIA CIVILClase 7 MECÁNICA DE FLUIDOS 2 INGENIERIA CIVIL
Clase 7 MECÁNICA DE FLUIDOS 2 INGENIERIA CIVIL
 
ECONOMIA APLICADA SEMANA 555555555555555555.pdf
ECONOMIA APLICADA SEMANA 555555555555555555.pdfECONOMIA APLICADA SEMANA 555555555555555555.pdf
ECONOMIA APLICADA SEMANA 555555555555555555.pdf
 
Magnetismo y electromagnetismo principios
Magnetismo y electromagnetismo principiosMagnetismo y electromagnetismo principios
Magnetismo y electromagnetismo principios
 
Comite Operativo Ciberseguridad 012020.pptx
Comite Operativo Ciberseguridad 012020.pptxComite Operativo Ciberseguridad 012020.pptx
Comite Operativo Ciberseguridad 012020.pptx
 
CARGAS VIVAS Y CARGAS MUERTASEXPOCI.pptx
CARGAS VIVAS Y CARGAS MUERTASEXPOCI.pptxCARGAS VIVAS Y CARGAS MUERTASEXPOCI.pptx
CARGAS VIVAS Y CARGAS MUERTASEXPOCI.pptx
 
TEXTO UNICO DE LA LEY-DE-CONTRATACIONES-ESTADO.pdf
TEXTO UNICO DE LA LEY-DE-CONTRATACIONES-ESTADO.pdfTEXTO UNICO DE LA LEY-DE-CONTRATACIONES-ESTADO.pdf
TEXTO UNICO DE LA LEY-DE-CONTRATACIONES-ESTADO.pdf
 
desarrollodeproyectoss inge. industrial
desarrollodeproyectoss  inge. industrialdesarrollodeproyectoss  inge. industrial
desarrollodeproyectoss inge. industrial
 
Mapas y cartas topográficas y de suelos.pptx
Mapas y cartas topográficas y de suelos.pptxMapas y cartas topográficas y de suelos.pptx
Mapas y cartas topográficas y de suelos.pptx
 
NTP- Determinación de Cloruros en suelos y agregados (1) (1).pptx
NTP- Determinación de Cloruros  en suelos y agregados (1) (1).pptxNTP- Determinación de Cloruros  en suelos y agregados (1) (1).pptx
NTP- Determinación de Cloruros en suelos y agregados (1) (1).pptx
 
Ingeniería clínica 1 Ingeniería biomedica
Ingeniería clínica 1 Ingeniería biomedicaIngeniería clínica 1 Ingeniería biomedica
Ingeniería clínica 1 Ingeniería biomedica
 
LA APLICACIÓN DE LAS PROPIEDADES TEXTUALES A LOS TEXTOS.pdf
LA APLICACIÓN DE LAS PROPIEDADES TEXTUALES A LOS TEXTOS.pdfLA APLICACIÓN DE LAS PROPIEDADES TEXTUALES A LOS TEXTOS.pdf
LA APLICACIÓN DE LAS PROPIEDADES TEXTUALES A LOS TEXTOS.pdf
 
aCARGA y FUERZA UNI 19 marzo 2024-22.ppt
aCARGA y FUERZA UNI 19 marzo 2024-22.pptaCARGA y FUERZA UNI 19 marzo 2024-22.ppt
aCARGA y FUERZA UNI 19 marzo 2024-22.ppt
 
CLASe número 4 fotogrametria Y PARALAJE.pptx
CLASe número 4 fotogrametria Y PARALAJE.pptxCLASe número 4 fotogrametria Y PARALAJE.pptx
CLASe número 4 fotogrametria Y PARALAJE.pptx
 
ECONOMIA APLICADA SEMANA 555555555544.pdf
ECONOMIA APLICADA SEMANA 555555555544.pdfECONOMIA APLICADA SEMANA 555555555544.pdf
ECONOMIA APLICADA SEMANA 555555555544.pdf
 
01 MATERIALES AERONAUTICOS VARIOS clase 1.ppt
01 MATERIALES AERONAUTICOS VARIOS clase 1.ppt01 MATERIALES AERONAUTICOS VARIOS clase 1.ppt
01 MATERIALES AERONAUTICOS VARIOS clase 1.ppt
 
TAREA 8 CORREDOR INTEROCEÁNICO DEL PAÍS.pdf
TAREA 8 CORREDOR INTEROCEÁNICO DEL PAÍS.pdfTAREA 8 CORREDOR INTEROCEÁNICO DEL PAÍS.pdf
TAREA 8 CORREDOR INTEROCEÁNICO DEL PAÍS.pdf
 
CAPITULO 4 ANODIZADO DE ALUMINIO ,OBTENCION Y PROCESO
CAPITULO 4 ANODIZADO DE ALUMINIO ,OBTENCION Y PROCESOCAPITULO 4 ANODIZADO DE ALUMINIO ,OBTENCION Y PROCESO
CAPITULO 4 ANODIZADO DE ALUMINIO ,OBTENCION Y PROCESO
 

Ingenieria de software - Unidad 4 seguridad

  • 1. 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
  • 2. 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
  • 3. 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
  • 4. 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
  • 5. 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
  • 6. 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
  • 7. 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
  • 8. 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
  • 9. • 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
  • 10. 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
  • 11. 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
  • 12. 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
  • 13. 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
  • 14. 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
  • 15. 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
  • 16. 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
  • 17. 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
  • 18. 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
  • 19. 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
  • 20. • 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
  • 21. 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
  • 22. 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
  • 23.  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
  • 24. • 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
  • 25. 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
  • 26. 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
  • 28. 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
  • 29. 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
  • 30. 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
  • 31. • 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
  • 32. • 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
  • 33. 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
  • 35. 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
  • 36. • 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
  • 37. 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
  • 38. 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
  • 39. • 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
  • 40. • 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
  • 41. 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
  • 42. 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
  • 43. 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
  • 44. 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
  • 45. MODELOS DE CONFIABILIDAD DE UN SOFTWARE Existen 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 operacional Validación continua, enterada al software dependiente. • Fase de mantenimiento.  Adición de nuevas posibilidades, mejor de algoritmos. INGENIERÍA DE SOFTWARE
  • 46. 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
  • 47. • 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
  • 48. • 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
  • 49. • 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
  • 50. 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
  • 51. • 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
  • 52. 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
  • 53. 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
  • 54. . INGENIERÍADESOFTWARE Autenti- 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.
  • 55. RIESGOS DETERMINAN LA POLÍTICA Y ESTA DEFINE LA TECNOLOGÍA A UTILIZAR Pasos 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
  • 56. UNA POLÍTICA DE SEGURIDAD PARA UN SISTEMA DEFINE LOS OBJETIVOS La 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
  • 57. 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
  • 58. 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
  • 59. 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
  • 60. • 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
  • 61. 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
  • 62. • Estudiar los riesgos posibles, cuantificar el valor las consecuencias de estos riesgos sobre la información y valorar los costes totales. Análisis de Riesgos • 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
  • 63. • 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
  • 64. 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
  • 65. MECANISMOS DE IMPLEMENTACIÓN Por 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
  • 66. 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
  • 67. 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
  • 68. 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
  • 69. • 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
  • 70. 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
  • 71. 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
  • 73. 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
  • 74. 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
  • 75. 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