Ingenieria de software - Unidad 4 seguridad

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.

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.

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.

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’.

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.

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.

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.

• 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.

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

• 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.

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).

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).

• 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.

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.

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.

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.

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.

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.

• 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.

• 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.

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.

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.

• 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.

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.

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.

• 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.

• 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.

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.

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.

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.

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.

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 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.

• 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.

• 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.

• 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.

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.

• 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.

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.

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Í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.

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.

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.

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:

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.

• 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.

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:

• 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

• 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

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.

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.

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.

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.

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.

• 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.

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.

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.

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.

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.

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.

Ingenieria de software - Unidad 4 seguridad

Más contenido relacionado

La actualidad más candente (20)

Destacado (20)

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

Más de José Antonio Sandoval Acosta (20)

Último (20)

Ingenieria de software - Unidad 4 seguridad