APUNTES UNIDAD 4 SEGURIDAD EN INGENIERÍA DE SOFTWARE

PROFESORA

M.T.I. MONTSERRAT MASDEFIOL SUÁREZ

CARRERA

ING. EN SISTEMAS COMPUTACIONALES

MATERIA

INGENIERÍA DE SOFTWARE

TRABAJO

U4: SEGURIDAD EN INGENIERÍA DE SOFTWARE

NOMBRE DEL ALUMNO:

SERRANO BLAS, EPIFANIO

GRUPO

604 “A”

SAN ANDRÉS TUXTLA, VER., 25 DE MAYO DEL 2013.

INSTITUTO TECNOLÓGICO SUPERIOR DE SAN ANDRÉS TUXTLA

ÍNDICE

INTRODUCCIÓN.....................................................................................................5

UNIDAD 4 SEGURIDAD DE INGENIERÍA DE SOFTWARE...................................6

Objetivo..........................................................................................................6

Criterios de evaluación..................................................................................6

Temario..........................................................................................................6

4.1 SEGURIDAD DE SOFTWARE...........................................................................7

DEFINICIONES DE SEGURIDAD.................................................................7

IMPORTANCIA DE SEGURIDAD..................................................................7

USUARIOS COMUNES.................................................................................8

EDUCAR AL USUARIO.................................................................................8

CREANDO SOFTWARE...............................................................................8

PROPIEDADES DE LA INFORMACIÓN.......................................................8

ATAQUES CONTRA EL FLUJO DE LA INFORMACIÓN..............................9

RAZONES PARA ATACAR LA RED DE UNA EMPRESA..........................10

CRACKER.........................................................................................10

HACKERS.........................................................................................10

4.2 SEGURIDAD EN EL CICLO DE DESARROLLO DEL SOFTWARE................12

SEGURIDAD EN EL ANÁLISIS DE REQUERIMIENTOS...........................13

SEGURIDAD EN EL DISEÑO.....................................................................13

SEGURIDAD EN LA CODIFICACIÓN.........................................................14

TESTING / QA DE SEGURIDAD.................................................................15

IMPLEMENTACIÓN / PUESTA EN PRODUCCIÓN....................................16

Ventajas............................................................................................17

M.T.I. MONTSERRAT MASDEFIOL SUÁREZ 2


Desventajas......................................................................................17

SEGURIDAD EN EL DESARROLLO DE SOFTWARE...............................18

PAPEL DE SEGURIDAD EN EL DESARROLLO DE SOFTWARE.............19

4.3 CONFIABILIDAD DEL SOFTWARE.................................................................20

PRUEBAS DE CONFIABILIDAD............................................................................25

Tipos de Pruebas de Confiabilidad..............................................................25

De Componentes..............................................................................25

Pruebas de Estrés.............................................................................25

De Integración...................................................................................26

Pruebas de estrés de componentes..................................................26

Pruebas de estrés de integración......................................................26

Pruebas de Reales y Destrucción.....................................................27

Pruebas de Integración.....................................................................27

Pruebas Estructurales.......................................................................28

4.4 INGENIERÍA DE SEGURIDAD........................................................................30

COMPONENTES DE UN SISTEMA SEGURO...........................................35

RIESGOS DETERMINAN LA POLÍTICA Y ESTA DEFINE LA TECNOLOGÍA A

UTILIZAR.....................................................................................................36

UNA POLÍTICA DE SEGURIDAD PARA UN SISTEMA DEFINE LOS OBJETIVOS

.....................................................................................................................36

ATAQUE DE SEGURIDAD....................................................................................37

Servicios de seguridad................................................................................39

Mecanismos de implementación..................................................................39

Generales..........................................................................................40

Específicos........................................................................................40



PROTECCIÓN.......................................................................................................41

Criptografía..................................................................................................45

Criptoanálisis...............................................................................................46

TRABAJO RELACIONADO.........................................................................48

PROCESO SOFTWARE SEGURO.............................................................49

DESCRIPCIÓN SEMÁNTICA DE LOS ELEMENTOS DE SEGURIDAD 49

PROCESO DE DESARROLLO DE SOFTWARE PARA LA SEGURIDAD 50

EXTENSIÓN DE UML CON REQUISITOS DE SEGURIDAD...........50

INTEGRACIÓN DE REQUISITOS DE SEGURIDAD EN MODELOS

SOFTWARE......................................................................................51

CONCLUSIÓN.......................................................................................................52

BIBLIOGRAFÍA......................................................................................................53



INTRODUCCIÓN

En la presente investigación se abordarán los temas de seguridad en el ciclo de

desarrollo del software que se refiere a la protección de sistemas de información contra el

acceso desautorizado o la modificación de información, la confiabilidad del software la cual

se define a que todo sistema opere sin fallas bajo condiciones establecidas por un periodo de

tiempo determinado, asimismo, la descripción de cada uno de los componentes que posee la

confiabilidad, y por último en la Ingeniería de seguridad se tratará la seguridad, la protección

contra los sistemas de información, definición de ingeniería de seguridad, así mismo algunas

herramientas que permiten la protección de los sistemas de software, además de algunos

ataques de seguridad que existen en los sistemas de información.



UNIDAD 4 SEGURIDAD DE INGENIERÍA DE SOFTWARE

OBJETIVO

Identificar los riesgos posibles que puede enfrentar durante el proceso de desarrollo del

software y aplicar medidas de seguridad para minimizarlos.

CRITERIOS DE EVALUACIÓN

Propuesta de proyecto 10 %

Exposición 35 %

Investigación documental 25 %

Propuesta teórica 20 %

TEMARIO

4.1 seguridad de software

4.2 seguridad en el ciclo de desarrollo del software

4.3 confiabilidad del software

4.4 ingeniería de seguridad



4.1 SEGURIDAD DE SOFTWARE

La seguridad informática es un camino, no un destino,

Objetivo: mantener los sistemas generando resultados,

Si los sistemas no se encuentran funcionando entonces su costo se convierte en

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

Lo que la empresa pierde.

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

Almacenamiento 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:

o Como la protección de sistemas de información contra el acceso.



4.2 SEGURIDAD EN EL CICLO DE DESARROLLO DEL SOFTWARE

La mayor parte de las organizaciones desarrolla o contrata el desarrollo de

aplicaciones propias para su 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.

Está comprobado que cuánto más temprano se encuentre una falla de seguridad en el

ciclo de vida del desarrollo de software, más rápida y económica será su mitigación. ¿Cuál es

el rumbo a seguir? 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.

CICLO DE VIDA DE DESARROLLO

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.), 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 encripció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. Las primeras son

bien conocidas y categorizadas. Ejemplo de estas vulnerabilidades son las presentes en el

“OWASP Top 10” (Vulnerabilidades de inyección, Cross Site Scripting, errores en manejo de

sesiones, etc.), como así también otras vulnerabilidades no ligadas directamente con las

aplicaciones WEB, como desbordamiento de buffer, denegación de servicio, etc. Los

Frameworks de desarrollo de aplicaciones son una buena ayuda en este punto, ya que

ofician de intermediario entre el programador y el código, y permiten prevenir la mayoría de

las vulnerabilidades conocidas. Ejemplos de estos frameworks son Struts, Ruby on Rails y

Zope.

Las vulnerabilidades funcionales son aquellas ligadas específicamente a la

funcionalidad de negocio que posee la aplicación, por lo que no están previamente

categorizadas. Algunos ejemplos ilustrativos de este tipo de vulnerabilidad son los siguientes:

una aplicación de banca electrónica que permite realizar transferencias con valores

negativos, un sistema de subastas que permite ver los valores de otros oferentes, un sistema

de venta de entradas para espectáculos que no impone límites adecuados a la cantidad de

reservas que un usuario puede hacer. En la etapa de codificación, una de las reglas de oro

es “verificar todos los valores de entrada y de salida”. Esto es, asumir siempre que el valor

pudo haber sido manipulado o ingresado maliciosamente antes de ser procesado.



TESTING / QA DE SEGURIDAD

Tradicionalmente, la labor del equipo de Testing/QA es la de encontrar y reportar

errores funcionales de la 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.

Es en este último grupo, en donde habitualmente están las vulnerabilidades, y el

testing funcional clásico no es capaz de encontrarlas. Por este motivo se necesitan nuevas

técnicas para explorar lo desconocido. El testing de seguridad se basa principalmente en

probar la aplicación con escenarios no planificados, incluyendo valores mutados, fuera de

rango, de tipo incorrecto o malformados, acciones fuera de orden, etc.

Existen herramientas automáticas que pueden ayudar al analista de QA en la

búsqueda de errores. Las mismas son útiles por su velocidad y capacidad de automatización,

pero pueden causar falsos positivos, y por lo general no son buenas detectando

vulnerabilidades funcionales. Es por esto que los mejores resultados resultan de la

combinación de técnicas automáticas y manuales.



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.

VENTAJAS

Consistencia. La herramienta ve lo que ve, sin ideas preconcebidas.

Apuntan a la causa raíz, no a los síntomas. Una prueba de penetración puede

establecer que hay un problema, pero no su causa final ni cómo corregirlo.

Detección precoz. La aplicación no tiene que estar integrada ni necesita ejecutarse.

Su ejecución es barata. Un sistema puede reanalizarse cuando se aplican cambios, o

cuando se descubre una nueva vulnerabilidad de aplicación.

DESVENTAJAS

Falsos positivos. Impacto (coste) crece al tener que evaluar cada positivo.

Falsos negativos. Suelen ser incapaces de detectar vulnerabilidades de seguridad

achacables al diseño, o específicas del contexto propio de la aplicación (se centran en

vulnerabilidades genéricas, de codificación).

¿Qué es mejor? En seguridad, sin duda, baja tasa de falsos negativos sin una tasa

desproporcionada de falsos positivos.

SEGURIDAD EN EL DESARROLLO DE SOFTWARE

Cuando el desarrollador realiza algún tipo de sistema software sin importar cuál sea la

finalidad que vaya a tener el mismo, es importante que se tomen algunos recaudos, ya que al

tratarse de un sistema tan delicado, es importante que se tenga en cuenta que en cualquier

momento puede sufrir alguna falla en su funcionamiento. Generalmente la seguridad en el



desarrollo de software es tan importante como cuando se está ejecutando ya que

lógicamente, para poder desarrollarlo, se requiere de un sistema operativo especial, el cual

también está en riesgo. Se dice eso porque durante el desarrollo de programas, siempre se

deben realizar diferentes tipos de pruebas, y son precisamente estas ejecuciones a prueba

las que ponen el riesgo el sistema que se está utilizando en general.

Pero es importante que se destaque el hecho de que existen sistemas de seguridad

que se utilizan especialmente para proteger a los sistemas operativos sobre los cuales se

realizan pruebas durante el desarrollo de software, y solo es cuestión de averiguar cuál es el

más indicado en el caso de que se esté trabajando en esta área. Las tiendas de

informática suelen tener varios sistemas de seguridad para el desarrollo de software,

los cuales son muy variados, y generalmente traen diferentes aplicaciones según las

necesidades y requerimientos de la persona que esté trabajando sobre un software.

También es importante tener en cuenta el asesoramiento de personas especializadas

en los sistemas de seguridad ya que las aplicaciones son totalmente diferentes para cada

uno de los casos. Por otro lado es muy importante hacer hincapié en el hecho de que es

esencial que cuando se trata de la seguridad en el desarrollo de software nunca se busque

en Internet, es decir que la descarga de este tipo de programas, ya sean antivirus o de

cualquier otro tipo, sean descargados desde una página Web online. Esto es principalmente

porque se tiene que tener en cuenta que el campo de desarrollo de software es bastante

competitivo, y más de una vez ha pasado que por haberse infiltrado algún tipo de virus para

el espionaje o el robo de información, y justamente este tipo de virus suelen estar en

archivos en Internet que prometen la seguridad en el desarrollo del software, por eso

es suma importancia cuidarse de este tipo de problemas, sin importar cuan tentador pueda

llegar a ser, adquirir la seguridad para el desarrollo de software de manera gratuita.

PAPEL DE SEGURIDAD EN EL DESARROLLO DE SOFTWARE.

Para que se pueda entender de qué manera trabaja un sistema de seguridad en el

desarrollo de software se dice que generalmente evita que se produzcan errores generales

en los sistemas operativos que se utilizan tanto para el desarrollo del mismo, como para las



pruebas piloto del funcionamiento del software. Al tratarse de un prototipo de prueba, es muy

común que se produzcan fallas permanentemente, y que esto pueda afectar al sistema,

además, se debe decir que las fallas en el sistema de software que se está desarrollando

necesitan ser ejecutadas para poder corregirlas, ya que de otro modo, no se podría

desarrollar ningún tipo de programa que tenga fallas al ejecutarlo.

Por eso, tomando en cuenta que las fallas deben existir aunque las mismas pongan en

riesgo el funcionamiento del sistema en general, se debe siempre contar con algún programa

de seguridad para evitar que las mismas produzcan un daño mayor. En el caso de que se

esté trabajando online, el programa de seguridad en el desarrollo de software que se esté

utilizando, debe también ser a prueba de virus informáticos, especialmente de aquellos que

roban la información o dañan el sistema operativo imposibilitando a quien está trabajando

que continúe con su actividad.



4.3 CONFIABILIDAD DEL SOFTWARE

Significa que un programa particular debe de seguir funcionando en la presencia

de errores.

Los errores pueden ser relacionados el 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.

Es la probabilidad de operación libre de fallas de un programa de computadora en un

entorno determinado y durante un tiempo específico. El fallo es cualquier no concordancia



con los requerimientos del software. Hay distintos grados de fallos, estos pueden ser

simplemente desconcertantes o catastróficos.

La confiabilidad del software se encuentra en una etapa de formación de desarrollo y

es la característica de rendimiento más costosa y difícil de conseguir y garantizar. La

naturaleza del proyecto ayuda para la formulación de estimaciones de costo y el esfuerzo

que asegure la confiabilidad requerida.

Los modelos de confiabilidad del software se usan para caracterizar y predecir el

comportamiento importante para directores e ingenieros. La generación de fallos depende del

código desarrollado, tales como tamaño y las características del proceso de desarrollado

como las tecnologías y herramientas de ingeniería de software usadas.

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 este activo

y en funcionamiento y sea capaz de proporcionar servicios en cualquier momento.

Fiabilidad. La fiabilidad de un sistema es la probabilidad de que durante un

determinado periodo de tiempo, el sistema funcione correctamente tal y como espera

el usuario.



Seguridad. La seguridad de un sistema es una 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.

Las propiedades anteriores, también expresadas de una manera gráfica (ver Figura

1.1), pueden descomponerse a su vez en otras propiedades más simples. Por ejemplo, la

protección incluye la integridad (asegurar que el programa y los datos de los sistemas no

resultan dañados) y la confidencialidad (asegurar que solo las personas autorizadas puedan

acceder a la información). La fiabilidad incluye la corrección (asegurar que los servicios que

proporciona el sistema son los que se han especificado), precisión (asegurar que la

información se proporciona al usuario con el nivel de detalle adecuado), y oportunidad

(asegurar que la información que proporciona el sistema se hace cuando es requerida).

Las propiedades de la confiabilidad ya mencionadas como son la disponibilidad,

seguridad, fiabilidad y protección están interrelacionadas. El funcionamiento de un sistema

seguro depende normalmente de que el sistema esté disponible y su funcionamiento sea

fiable. Un sistema puede convertirse en no fiable debido a que sus datos han sido

corrompidos por algún intruso. Los ataques de denegación de servicio en un sistema tienen

como propósito comprometer su disponibilidad. Si un sistema que ha demostrado ser seguro

es infectado por un virus, ya no se le puede suponer un funcionamiento seguro. Estas



Figura 1.1

interrelaciones entre las cuatro propiedades son la razón de introducir la noción de

confiablidad como una propiedad que las engloba.

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.



Los diseñadores normalmente deben buscar un equilibrio entre el rendimiento del

sistema y su confiabilidad. Por lo general, niveles altos de confiabilidad solamente pueden

alcanzarse a costa del rendimiento del sistema. Un software confiable incluye código extra, a

menudo redundante, para realizar las comprobaciones necesarias para estados

excepcionales del sistema y para recuperar el sistema ante un fallo. Esto reduce la

confiabilidad del sistema e incrementa la cantidad de memoria requerida por el software.

Además, también se incrementan de forma significativa los costos del desarrollo del sistema.

Debido al diseño adicional, implementación y costos de validación, el incremento de la

confiabilidad de un sistema puede hacer crecer significativamente los costos de desarrollo.

En particular, los costos de validación son elevados para los sistemas críticos. Además de

validar que el sistema cumple con sus requerimientos, el proceso de validación tiene que

comprobar que el sistema es confiable a través de un sistema de regulación externo.

Cuanto mayor sea la confiablidad que se necesita, mas habrá que gastar en probar y

chequear que efectivamente se ha alcanzado dicho nivel de confiabilidad. Debido al carácter

exponencial de la curva coste/confiabilidad, no es posible demostrar que un sistema es

totalmente confiable, ya que los costes necesarios para asegurar esto podrían ser infinitos.

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.

DE INTEGRACIÓN

Están relacionadas con las interacciones con otras estructuras de datos, procesos y

servicios tanto de los componentes internos y externos de la aplicación. Es necesario

conocer los recorridos codificados y las situaciones a las que se enfrenta el usuario y que se

identifiquen todas las maneras en las que el usuario se mueve por la aplicación.

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. Los datos de entrada pueden

ser eventos del mouse (ratón) o del teclado, secuencias de mensajes del

programa, páginas Web, cachés de datos o cualquier otra condición de entrada

que pueda introducirse en la aplicación. Deberá utilizar pruebas de destrucción

aleatorias para comprobar las rutas de errores importantes y poner de

manifiesto errores de programación del software. Este tipo de pruebas mejora la

calidad del código ya que da lugar a errores que permiten examinar el control

de los errores devueltos. Las pruebas aleatorias pasan por alto de forma

intencionada cualquier especificación del comportamiento del programa. Si se

interrumpe la aplicación, no se ha superado la prueba. Si no se interrumpe la



aplicación, la prueba se ha superado. La cuestión es que las pruebas aleatorias

pueden tener un alto nivel de automatización porque nada tienen que ver con el

modo en que se supone que funciona la aplicación subyacente.

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.

DEFUNCIÓN DE ERRORES

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.

o El software se prueba y se corrige.

o La confiabilidad crece.

Fase de validación.

o El software no se corrige, se aprueba o rechaza.

Fase operacional

o Validación continua, enterada al software dependiente.



Fase de mantenimiento.

o Adición de nuevas posibilidades, mejor de algoritmos.

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

Se puede pensar en la definición de seguridad como el grado de confianza que exige

un individuo o empresa para que su información no sea mostrada ni divulgada a todo el

mundo, entonces es donde se requiere un compromiso consiente por parte de los

profesionales involucrados en la creación del software encargado de dicha función.

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.

Además del hecho de que nunca se pueda tener la certeza absoluta de que un

sistema está libre de defectos y es tolerante a fallos, hay muchas otras razones por las que

un sistema software que es fiable no necesariamente es seguro:

La especificación puede estar incompleta en el sentido de que no describe el

comportamiento requerido del sistema en algunas situaciones críticas. Un alto

porcentaje de sistemas que funcionan mal (Natajo y Kume, 1991; Lutz, 1993) se debe

a errores de especificación más que a errores de diseño. En un estudio de errores en



sistemas empotrados, Lutz concluye que: Las dificultades con los requerimientos son

la causa clave de los errores de software relacionados con la seguridad que

persistieron hasta la integración y la prueba del sistema.

El mal funcionamiento del hardware hace que el sistema se comporte de forma

impredecible y enfrente al software con un entorno inesperado. Cuando los

componentes están próximos a fallar, pueden comportarse de forma errática y generar

señales que están fuera de los rangos que puede manejar el software.

Los operadores del sistema pueden generar entradas que no son individualmente

incorrectas, pero que, en situaciones particulares, pueden dar lugar a un mal

funcionamiento del sistema. Como ejemplo anecdótico se puede citar el caso en que

un mecánico dio instrucciones al software de utilidades de gestión de un avión para

que levantara el tren de aterrizaje. El software ejecutó las instrucciones perfectamente.

Por desgracia, el avión permaneció en tierra todo el tiempo; claramente, el sistema

debería haber inhabilitado el comando a menos que el avión estuviese en el aire.

Se ha creado un vocabulario especializado para tratar los sistemas de seguridad

críticos y es importante comprender los términos específicos utilizados.

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.

Los accidentes ocurren generalmente cuando varias cosas van mal al mismo tiempo.

Un análisis de accidentes serios (Perrow, 1984) sugiere que casi todos ellos se debieron a

una combinación de malos funcionamientos más que a fallos aislados. La combinación no

anticipada condujo a interacciones que provocaron fallos de funcionamiento del sistema.

Perrow sugiere también que es imposible anticiparse a todas las posibles combinaciones de

mal funcionamiento de un sistema, y que los accidentes son una parte inevitable del uso de

sistemas complejos. El software tiende a incrementar la complejidad del sistema, de tal forma

que al realizar el control mediante software puede incrementar la probabilidad de accidentes

del sistema.

Sin embargo, el software de control y monitorización puede mejorar también la

seguridad de los sistemas. Los sistemas controlados por software pueden monitorizar un

rango de condiciones más amplio que los sistemas electromecánicos. Los primeros se

pueden adaptar con relativa facilidad. Además implican el uso del hardware de la

computadora, el cual tiene una fiabilidad inherente muy alta y es físicamente pequeño y

ligero. Los sistemas controlados por software pueden proporcionar mecanismos de seguridad

sofisticados. Pueden soportar estrategias de control que reducen la cantidad de tiempo que

las personas necesitan consumir en entornos con contingencias. En consecuencia, si bien el

software de control puede introducir más formas en las que un sistema puede funcionar mal,

también permite una mejor monitorización y protección, por lo tanto, puede mejorar la

seguridad del sistema.

En todos los casos, es importante mantener un sentido de la proporción sobre la

seguridad del sistema. Es imposible conseguir que un sistema sea totalmente seguro, y la



sociedad debe decidir si los beneficios del uso de tecnologías avanzadas compensan o no

las consecuencias de un accidente ocasional. También es una decisión social y política cómo

utilizar unos recursos nacionales limitados a fin de reducir el riesgo para la población en su

conjunto.

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

Confidencialidad

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.

Autenticidad

Se refiere a integridad y frescura.

Vulnerabilidad

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.

La ingeniería de seguridad procede secuencialmente desde los requerimientos de

seguridad hasta la solución, no desde la tecnología más novedosa.



Estos significan que lo primero que hay que hacer es modelar el tipo de ataques al que

se está sujeto, a partir de esto crear una política de seguridad y luego a partir de estos

escoger la tecnología a aplicar para evitar los riesgos antes modelados.

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. No es que antes no existiera la

información en las empresas, el espionaje industrial es tan antiguo como la revolución

industrial, pero se mantenía con el sistema de papel y archivadores y formaba parte de los

activos de oficina. 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:

Análisis de riesgos. Estudiar los riesgos posibles, cuantificar el valor las

consecuencias de estos riesgos sobre la información y valorar los costes totales.

Analizar las medidas de protección. Valorar las diferentes medidas de protección,

tanto cuantitativamente como de facilidad de uso y velocidad de acceso.

Decidir las medidas adecuadas. Comparar los dos análisis y decidir la solución que

amortiza los riesgos.

Política de seguridad. Adaptar la forma de trabajo de la empresa a las nuevas

medidas de seguridad.

Mantenimiento. Mantener continuamente las medidas de seguridad así como

actualizar el diseño a las nuevas realidades del capital de información.

Planes de contingencia. Planificar las actuaciones para cuando se producen ataques

con o sin éxito.

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.



La Tabla 1.1 indica que ataques protegen los servicios anteriores:

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.

La tabla 1.2 muestra los servicios que brindan los mecanismos.

Los mecanismos: cifrado, firma digital, control de accesos e integridad utilizan

criptología para su implementación.

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. La conexión a Internet también conlleva que los detalles sobre vulnerabilidades

particulares del sistema pueden difundirse fácilmente para que más personas sean capaces



de atacar al sistema. Del mismo modo, sin embargo, la conexión puede acelerar la

distribución de parches del sistema para reparar estas vulnerabilidades.

Ejemplos de ataques podrían ser los virus, el uso no autorizado de servicios del

sistema y la modificación no autorizada del sistema o sus datos. La protección es importante

para todos los sistemas críticos. Sin un nivel razonable de protección, la disponibilidad,

fiabilidad y seguridad del sistema pueden verse comprometidas si ataques externos que

provocan daños al mismo.

La razón de esto es que todos los métodos para asegurar la disponibilidad, fiabilidad y

seguridad se valen del hecho de que el sistema operacional es el mismo que se instaló

originalmente. Si dicho sistema instalado se ha visto comprometido de alguna forma (por

ejemplo, si el software se ha modificado para aceptar un virus), entonces los argumentos

para la fiabilidad y la seguridad originalmente establecidos dejan de ser ciertos. El sistema de

software puede entonces corromperse y comportarse de forma impredecible.

Por el contrario, los errores en el desarrollo de un sistema pueden provocar agujeros

de protección. Si un sistema no responde a entradas inesperadas o si los límites de un vector

no se verifican, entonces los atacantes pueden explotar estas debilidades para tener acceso

al sistema. Los incidentes de protección más importantes tales como el gusano de Internet

original (Spafford, 1989) y el gusano Code Red más de diez años después (Berghel, 2001)

se aprovecharon del hecho de que los programas en C no incluyen verificación de los límites

de los vectores. Los gusanos sobrescribieron parte de la memoria con código que permitió el

acceso no autorizado al sistema.

Por supuesto, 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 billetes de avión no está disponible, esto provoca

inconvenientes y algunos retrasos en la emisión de los billetes. 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. Dependiendo del tipo de datos, esto podría afectar a la seguridad del

sistema y puede permitir ataques posteriores que afecten a la disponibilidad o

fiabilidad del sistema.

Como con otros aspectos de la confiabilidad, existe una terminología especializada

asociada con la protección. Algunos términos importantes, como los tratados por Pfleeger

(1977), se definen de la siguiente manera:

Exposición: posible pérdida o daño en un sistema informático. Un ejemplo

puede ser la pérdida o daño de los datos o la pérdida de tiempo y esfuerzo si es

necesaria una recuperación del sistema después de una violación de

protección.

Vulnerabilidad: debilidad en un sistema informático que se puede aprovechar

para provocar pérdidas o daños.

Ataque: aprovechamiento de la vulnerabilidad de un sistema. Generalmente, se

produce desde fuera del sistema y con una intención deliberada de causar

algún daño.



Amenaza: circunstancias que potencialmente pueden provocar pérdidas o

daños. Se pueden entender como una vulnerabilidad del sistema que está

expuesto a un ataque.

Control: medida de producción que reduce la vulnerabilidad del sistema. La

encriptación podría ser un ejemplo de un control que reduce una vulnerabilidad

de un sistema de control de acceso deficiente.

Existe una clara analogía con cierta terminología de la seguridad en el sentido de que

una exposición es análoga a un accidente y una vulnerabilidad es análoga a una

contingencia. Por tanto, existen aproximaciones comparables que se utilizan para garantizar

la protección de un sistema:

Evitar la vulnerabilidad. El sistema se diseña para que las vulnerabilidades no

ocurran. Por ejemplo, si un sistema no está conectado a una red pública externa,

entonces no existe la posibilidad de un ataque por parte de otras personas

conectadas a la red.

Defección y neutralización de ataques. El sistema se diseña para detectar

vulnerabilidades y eliminarlas antes de que provoquen una exposición del sistema.

Un ejemplo de detección y eliminación de la vulnerabilidad es la utilización de un

verificador de virus que analiza los ficheros entrantes y los modifica para eliminar el

virus.

Limitación de la exposición. Las consecuencias de un ataque exitoso se minimizan.

Ejemplos de limitación de la exposición son los sistemas de copias de seguridad

periódicas y una política de gestión de configuraciones que permite que el software

dañado pueda reconstruirse.

La gran mayoría de las vulnerabilidades en los sistemas informáticos se originan en

fallos humanos en lugar de en problemas técnicos. Las personas eligen palabras clave

fáciles de recordar o las escriben en lugares en donde resulta fácil encontrarlas. Los

administradores del sistema cometen errores en la actualización del control de acceso o de



ficheros de configuración y los usuarios olvidan instalar o usar software de protección. Para

mejorar la protección, por lo tanto, se necesita adoptar una perspectiva sociotécnica y pensar

en cómo se usan realmente los sistemas y no solamente en sus características técnicas.

Dentro de las herramientas de protección para los sistemas de información se

encuentra la criptología.

La criptología está formada por dos técnicas complementarias: criptoanálisis y

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.

CRIPTOGRAFÍA

Para encriptar 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 la encriptación y desencriptación.

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

encriptar y otro para desencriptar, pero son completamente inservibles para el criptoanalista

sin el conocimiento de la clave.

CRIPTOANÁLISIS

El criptoanálisis abarca muchas técnicas diversas, muchas veces no dependen del

conocimiento del algoritmo sino que mediante sistemas de aproximación matemática se

puede descubrir el texto en claro o la clave. La dificultad del análisis depende de la

información disponible, así el criptoanalista puede tener acceso a:

Un criptograma

Un criptograma y su texto en claro.

Un texto claro elegido y su criptograma.

Un criptograma elegido y su texto en claro.



Un texto en claro y su criptograma que están los dos elegidos.

Aumenta la dificultad cuanta menos información se tiene. En todos se busca la clave

que proporciona la solución para todo el sistema de seguridad.

En el criptoanálisis científico se utilizan las siguientes definiciones:

Distancia unívoca. Cantidad mínima del mensaje para poder descifrar la clave. Un

sistema ideal tiene una distancia unívoca infinito.

Sistema incondicionalmente seguro. El criptograma generado es menor que la

distancia unívoca.

Romper un sistema. Conseguir un método práctico para descifrar la clave de un

sistema criptográfico.

Sistema probablemente seguro. No se ha probado como romperlo.

Sistema condicionalmente seguro. Los analistas potenciales no disponen de

medios para romperlo.

No existen los sistemas completamente seguros, siempre se pueden violar probando

todas las claves posibles. Por lo tanto, en criptografía se buscan sistemas que cumplan una

de siguientes condiciones:

El precio para romperlo es más caro que el valor de la información.

El tiempo necesario para romperlo es más largo que el tiempo de vida de la

información.

Algunas de las aplicaciones, tales como sistemas de objetos distribuidos, servicios

web o computación grid, pueden representar pasos fundamentales en el uso extensivo de

Internet. Sin embargo, la ausencia de seguridad y de mecanismos de colaboración fiables

está obstaculizando su desarrollo. La falta de soluciones adecuadas que permitan garantizar

que los sistemas y aplicaciones puedan resolver los problemas de seguridad asociados,

representa en la práctica una barrera impracticable para el desarrollo extendido de esas

aplicaciones.



Se podría decir que, al contrario que la ingeniería del software, la ingeniería de

seguridad está aún en la fase experimental. Es poco frecuente que los problemas

relacionados con la seguridad se consideren en las fases iniciales de desarrollo de software.

La seguridad y la eficiencia son aspectos no funcionales muy importantes en cualquier

sistema en red o distribuido, y su consecución debe afrontarse a lo largo de todo el ciclo de

vida software.

TRABAJO RELACIONADO

Hay muy poco trabajo concerniente a la integración de aspectos de seguridad desde

las primeras fases del desarrollo de software. Aunque se han propuesto ciertas alternativas

para la integración de la seguridad, actualmente no hay una metodología completamente

definida para ayudar a los desarrolladores de sistemas que requieran seguridad. La falta de

soporte para la ingeniería de la seguridad en esas propuestas para el desarrollo de sistemas

software puede verse como una consecuencia de que:

Los requisitos de seguridad son muy difíciles de analizar y modelar.

De la falta de experiencia en el desarrollo de software seguro por parte de

los desarrolladores.

Las propuestas existentes no son lo suficientemente completas ni extensas, en el

sentido de que se centran bien en alguna fase especial del desarrollo, por ejemplo en el

diseño o la implementación, o bien en un aspecto de seguridad particular tal como el control

del acceso.

Se introduce un enfoque de la ingeniería de la seguridad respecto a una arquitectura

dirigida por modelo, llamada Model Driven Security. Este acercamiento, llamado SecureUML,

integra las políticas de control de acceso basadas en roles en un proceso de desarrollo de

software basado en UML y dirigido por el modelo.



UMLsec ha sido propuesto como una extensión del Lenguaje Unificado de Modelado

para modelar propiedades de seguridad de sistemas informáticos. UMLsec usa mecanismos

de extensión estándares para introducir nueva semántica dentro de los modelos UML.

PROCESO SOFTWARE SEGURO

Para solventar los problemas previamente mencionados, el trabajo se ha centrado en

definir un proceso de desarrollo de software que integra prácticas de ingeniería de la

seguridad en el propio ciclo de desarrollo software. Durante el transcurso, se definió

mecanismos que aseguren la coherencia entre los modelos correspondientes a los diferentes

niveles de abstracción.

El enfoque se basa en:

Descripción semántica de los requisitos de seguridad.

Extensión de UML con requisitos de seguridad.

Desarrollo de una librería de patrones de seguridad.

Integración de los componentes anteriores dentro de una herramienta. software para

ofrecer un proceso de ingeniería enfocado a la seguridad.

DESCRIPCIÓN SEMÁNTICA DE LOS ELEMENTOS DE SEGURIDAD

Automatizar el procesamiento de la información semántica es un gran reto para la

resolución de muchos problemas relevantes, tal como puede ser la clasificación de la web, o

en nuestro caso, la integración de soluciones genéricas a problemas recurrentes en el campo

de la ingeniería de seguridad. Las herramientas automáticas para la clasificación, selección y

composición de patrones están en desarrollo, y permiten la integración automática de los

patrones que implementan los requisitos de seguridad especificados.

Las descripciones semánticas no sólo ayudan en la selección del patrón correcto sino

que además son esenciales para la composición de patrones y para el análisis del sistema.

Más aún, las descripciones semánticas son la base para la reutilización de esos patrones.



La creación de una metodología y herramientas automáticas para la clasificación,

selección y composición de patrones de seguridad. El procesamiento automático consta de

dos componentes principales:

Catalogación y búsqueda basada en los metamodelos semánticos. La

información semántica acerca de los patrones y de los servicios de seguridad que

ofrecen es esencial para conseguir unas búsquedas eficientes y una selección

automática de patrones capaces de plasmar en el sistema requisitos de seguridad

específicos a partir de información del modelo.

Composición Inteligente. Ser tiene que tener la capacidad de seleccionar

automáticamente los patrones apropiados y componerlos para completar esos

requisitos de seguridad.

PROCESO DE DESARROLLO DE SOFTWARE PARA LA SEGURIDAD

El proceso de desarrollo de software integra técnicas de ingeniería de la seguridad

basadas en la noción de patrón de seguridad. Un patrón describe un problema recurrente

que surge en un contexto específico y que presenta un esquema de solución genérico y bien

probado para su solución. También se usa el concepto de patrones de seguridad para

representar soluciones de seguridad existentes.

A partir de unos requisitos de seguridad definidos en el modelo, se busca

automáticamente los patrones que mejor los representen. Entonces, los patrones

seleccionados deben adaptarse e integrarse en el modelo de usuario. Hay que resaltar que

cuando el cliente expresa requisitos de seguridad complejos puede ser necesaria la

composición de diferentes patrones antes de integrarlos en el modelo.

EXTENSIÓN DE UML CON REQUISITOS DE SEGURIDAD

Estas transformaciones ayudan a la creación de modelos usando puntos de vista

específicos, por ejemplo llegar a la creación de un modelo de requisitos de seguridad de

‘nivel de diseño’ a partir de un modelo de requisitos de seguridad a ‘nivel de especificación’,



y/o ayudan a la configuración e instalación de modelos de infraestructura comenzando desde

un modelo de requisitos de seguridad de negocio.

La caracterización de los requisitos de seguridad como base, del trabajo está enfocada

en las siguientes áreas:

La definición de un perfil UML para los requisitos de seguridad.

La extensión de las herramientas UML para que gestionen esos perfiles UML.

Las transformaciones de Arquitectura Dirigidas por Modelos (MDA) y las

extensiones de las herramientas UML asociadas.

La especificación de los requisitos de seguridad está integrada dentro de los modelos

UML de tal forma que estos requisitos pueden procesarse fácilmente de forma automática.

Los requisitos de seguridad se representan habitualmente por expresiones complejas

con modificadores y parámetros que los estereotipos no son capaces de capturar. Por

ejemplo, si se considera el caso del requisito de confidencialidad; sería necesario especificar

para quién es esa confidencialidad. Cuando se consideran estos requisitos en profundidad,

se descubren otros aspectos que pueden y en ocasiones deben ser especificados. Pese a

todo, se usan estereotipos durante las primeras etapas del desarrollo, especialmente en el

modelo de negocio.

INTEGRACIÓN DE REQUISITOS DE SEGURIDAD EN MODELOS SOFTWARE

El proceso gestionará el desarrollo de sistemas seguros de forma sistemática y guiada

desde la especificación hasta la implementación. El objetivo es usar el marco de trabajo para

la especificación de los requisitos y la librería de patrones de seguridad para ayudar al

desarrollador en el diseño de soluciones seguras. Las herramientas automatizadas bajo

desarrollo están diseñadas para ofrecer un proceso de ingeniería de la seguridad basada en

componentes a través de todo el ciclo de desarrollo completo, desde la especificación a la

implementación y desarrollo. El proceso de desarrollo tiene en cuenta condiciones del

entorno para conseguir implementaciones seguras.



CONCLUSIÓN

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. En cada una de estas

etapas, se pueden realizar diversas actividades que en su conjunto ayudarán a aumentar la

seguridad de la aplicación de software que se está desarrollando. Es importante que en cada

organización, el sector de seguridad de la información sea invitado a participar a lo largo de

todo el proceso de desarrollo como supervisor de las tareas y verificaciones de seguridad.

La integración 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 (tiempo/dinero) como

intangibles (imagen de la organización).

Por lo tanto la complejidad de un programa de computación o software es una medida

de la dificultad para llevar a cabo esa computación y está muy relacionada con su

confiabilidad. Por otra parte, se dice que un software es confiable si realiza lo que el usuario

desea, cuando así lo requiera.

Se podrá aumentar la Confiabilidad de un Software haciendo hincapié en las dos

primeras etapas de su desarrollo, el traslado de los requerimientos del usuario y en el diseño

lógico.

En el desarrollo de software el ingeniero en sistemas debe de tener en cuenta un

punto fundamental y este es la seguridad ya que juega un papel fundamental del sistema,

esto conlleva a que el sistema sea fiable en la seguridad. También en los sistemas de

seguridad críticos es esencial que el funcionamiento del sistema sea siempre seguro. El

sistema nunca debería provocar daños en las personas o en el entorno del sistema incluso si

éste falla.

En el control mediante hardware de los sistemas de seguridad críticos es más sencillo

de implementar y analizar que el control mediante software.

Es importante tener en cuenta los aspectos esenciales de la seguridad al desarrollar

un sistema, y también ver la manera más viable para procurar la confiabilidad del sistema.



BIBLIOGRAFÍA

Ingeniería de software, séptima edición, Iam Sommerville, Pearson Educación, S.A., Madrid,

2005.

ANÓNIMO, Software de seguridad

Obtenido en:

http://www.softwareseguridad.com/seguridadeneldesarrollodesoftware.html

Fecha: MAYO 2013

PABLO MILANO, CONSULTOR CYBSEC, Seguridad en el ciclo de vida

Del desarrollo de software

Obtenido en:

http://www.prensariotila.com/pdf/TutorialCybsec_0710.pdf

Fecha: MAYO DE 2013

PONS MARTORELL, MANUEL, Criptología

Obtenido en:

http://www.tierradelazaro.com/public/libros/cripto.pdf

Fecha: MAYO DE 2013

MAÑA ANTONIO, RAY DIEGO, SÁNCHEZ FRANCISCO, Integrando la Ingeniería de

seguridad en un proceso de ingeniería software.

Obtenido en:

http://web.iti.upv.es/~fsanchez/publications/RECSI04ManaSanchezRayYague.pdf

Fecha: MAYO 2013



APUNTES UNIDAD 4 SEGURIDAD EN INGENIERÍA DE SOFTWARE

Documents

Transcript of APUNTES UNIDAD 4 SEGURIDAD EN INGENIERÍA DE SOFTWARE