20 de Noviembre de 2017

TECNOLGICO NACIONAL DE MXICO

INSTITUTO TECNOLGICO DE ACAPULCO

INGENIERIA EN SISTEMAS COMPUTACIONALES

Tema 4: Seguridad en ingeniera de software

Ingeniera de software

Alumno: Elizabeth Garca Lozano

N de control: 13320875

1
Contenido
4.1 seguridad de software............................................................................................................. 3
IMPORTANCIA DE SEGURIDAD .................................................................................................. 3
USUARIOS COMUNES ................................................................................................................ 3
CREANDO SOFTWARE ............................................................................................................... 3
PROPIEDADES DE LA INFORMACIN ........................................................................................ 3
4.2 Seguridad en el ciclo de desarrollo del software .................................................................... 4
SEGURIDAD EN EL ANLISIS DE REQUERIMIENTOS .................................................................. 5
SEGURIDAD EN EL DISEO ........................................................................................................ 5
SEGURIDAD EN LA CODIFICACIN ............................................................................................ 5
TESTING / QA DE SEGURIDAD ................................................................................................... 6
IMPLEMENTACIN / PUESTA EN PRODUCCIN ....................................................................... 6
4.3 CONFIABILIDAD DEL SOFTWARE ............................................................................................. 7
PRUEBAS DE CONFIABILIDAD .................................................................................................... 8
De Componentes .................................................................................................................... 9
Pruebas de Estrs .................................................................................................................. 9
De Integracin ......................................................................................................................... 9
Pruebas de estrs de componentes .................................................................................... 9
Pruebas de Integracin ......................................................................................................... 9
Pruebas Estructurales ......................................................................................................... 10
4.4 INGENIERIA DE SOFTWARE ................................................................................................... 10
ATAQUE DE SEGURIDAD.............................................................................................................. 14
BIBLIOGRAFA .............................................................................................................................. 16

2
4.1 seguridad de software
El concepto de la seguridad en los sistemas de software es un rea de investigacin
que ha pasado a ser vital dentro de la Ingeniera de Software. Con el crecimiento de
Internet, y otras aplicaciones sobre redes, como el comercio electrnico, correo
electrnico, etc., la posibilidad de ataques se ha incrementado notablemente, como
tambin lo han hecho las consecuencias negativas de estos ataques. En la actualidad
prcticamente todo sistema debe incorporar cuestiones de seguridad para defenderse
de ataques maliciosos. El desarrollador ya no slo debe concentrarse nicamente en
los usuarios y sus requerimientos, sino tambin en los posibles atacantes.

IMPORTANCIA DE SEGURIDAD
Por el dinero, el dueo de los sistemas tiene dinero invertido en algo que le trae
un beneficio o ventaja.
Por calidad, hay que acostumbrarse a hacer las cosas bien, aunque cuentes
ms esfuerzo.
La seguridad surge tecnolgicamente, la seguridad es gratis. Los sistemas
operativos modernos contienen muchas caractersticas de seguridad.
Las mejores herramientas de seguridad son open source.

USUARIOS COMUNES
Los usuarios se acostumbran a usar la tecnologa sin saber cmo funciona o
de los riesgos que pueden correr.
Son las principales vctimas.
Tambin son el punto de entrada de muchos problemas crnicos.
El eslabn ms dbil en la cadena de seguridad.
2 enfoques para controlarlos.
Principio del menor privilegio posible.
Reducir la capacidad de accin del usuario sobre los sistemas.
Objetivo: lograr el menos dao posible en caso de incidentes.

CREANDO SOFTWARE
El software moderno es muy complejo y tiene una alta probabilidad de contener
vulnerabilidad de seguridad.
Un mal proceso de desarrollo genera software de mala calidad. Prefieren a que
salga mal a que salga tarde.
Usualmente no se ensea a incorporar requisitos ni protocolos de seguridad.

PROPIEDADES DE LA INFORMACIN
Confidencialidad: asegurarse que la informacin en un sistema de cmputo t la
transmitida por un medio de comunicacin, puede ser leda solo por las
personas autorizadas.
Autenticacin: asegurarse que el origen de un mensaje o documento
electrnico est correctamente identificado, con la seguridad que la entidad
emisora o receptora no est suplantada.
Integridad: asegurarse que solo el personal autorizado sea capaz de modificar
la informacin o recursos de cmputo.
No repudiacin: asegurarse que ni el emisor o receptor de un mensaje o accin
sea capaz de negar lo hecho.
3
 Disponibilidad: requiere que los recursos de un sistema de cmputo estn
disponibles en el momento que se necesiten.

4.2 Seguridad en el ciclo de desarrollo del software

La mayor parte de las organizaciones desarrolla o contrata el desarrollo de
aplicaciones propias para su gestin de negocio. Como todo software, estas
aplicaciones pueden contener fallas de seguridad y a diferencia del software comercial,
no se dispone de actualizaciones o parches liberados en forma peridica por el
fabricante. El tratamiento de las vulnerabilidades en aplicaciones propias corre por parte
de la organizacin que las desarrolla.
Est comprobado que cunto ms temprano se encuentre una falla de seguridad
en el ciclo de vida del desarrollo de software, ms rpida y econmica ser su mitigacin.
Cul es el rumbo a seguir? Las buenas prcticas indican la conveniencia de incluir
seguridad de la informacin desde el principio y a lo largo de todas las etapas del ciclo
de vida de desarrollo, conocido como SDLC (Software Development Life Cicle). Estas
etapas pueden variar segn la modalidad de cada organizacin, pero a grandes rasgos
son las siguientes: anlisis de requerimientos, diseo funcional y detallado, codificacin,
testing/QA, implementacin/puesta en produccin.
CICLO DE VIDA DE DESARROLLO

Anlisis de requerimientos.
Diseo funcional y detallado.
Codificacin.
Testing/QA.
Implementacin puesta en produccin.

4
SEGURIDAD EN EL ANLISIS DE REQUERIMIENTOS
En esta etapa, se deben identificar aquellos requerimientos funcionales que tendrn
impacto en los aspectos de seguridad de la aplicacin. Algunos de ellos son:
requerimientos de conformidad con normativas locales o internacionales, tipo de
informacin que se transmitir o procesar (por ejemplo: la Informacin pblica o
confidencial, datos personales, datos financieros, contraseas, datos de pago
electrnico, etc.) y requerimientos de registros de auditora (por ejemplo: qu debe
registrar la aplicacin en sus Logs).

SEGURIDAD EN EL DISEO
Antes de comenzar a escribir lneas de cdigo, hay numerosos aspectos de seguridad
que deben ser tomados en cuenta durante el diseo de aplicacin.

Algunos de ellos son: diseo de autorizacin (como definir los roles, permisos y
privilegios de la aplicacin), diseo de autenticacin (se deber disear el modo en el
que los usuarios se van a autenticar, contemplando aspectos tales como los
mecanismos o factores de autenticacin con contraseas, tokens, certificados, etc.
posibilidades de integrar la autenticacin con servicios externos como LDAP, Radius o
Active Directory) y los mecanismos que tendr la aplicacin para evitar ataques de
diccionario o de fuerza bruta (algunos de ejemplos son bloqueo de cuentas,
implementacin de captchas, etc.), diseo de los mensajes de error y advertencia, para
evitar que los mismos brinden demasiada informacin y que sta sea utilizada por
atacantes y diseo de los mecanismos de proteccin de datos (se debe contemplar el
modo en el que se proteger la informacin sensible en trnsito o almacenada; segn
el caso, se puede definir la implementacin de encripcin, hashes o truncamiento de la
informacin).

Una vez que se cuenta con el diseo detallado de la aplicacin, una prctica interesante
es la de realizar sobre el mismo un anlisis de riesgo orientado a software. Existen
tcnicas documentadas al respecto, tales como Threat Modeling. Estas tcnicas
permiten definir un marco para identificar debilidades de seguridad en el software, antes
de la etapa de codificacin. Como valor agregado, del anlisis de riesgo orientado a
software se pueden obtener casos de prueba para ser utilizados en la etapa de
Testing/QA.

SEGURIDAD EN LA CODIFICACIN
En la etapa de codificacin, una de las reglas es verificar todos los valores de entrada y
de salida. Esto es, asumir siempre que el valor pudo haber sido manipulado o ingresado
maliciosamente antes de ser procesado.

Una vez concluido el diseo, los desarrolladores tendrn que codificar los distintos
componentes de la aplicacin. Es en este punto en donde suelen incorporarse, por error
u omisin, distintos tipos de vulnerabilidades. Estas vulnerabilidades se pueden dividir
en dos grandes grupos: vulnerabilidades clsicas y vulnerabilidades funcionales. Las
primeras son bien conocidas y categorizadas. Ejemplo de estas vulnerabilidades son las
presentes en el OWASP Top 10 (Vulnerabilidades de inyeccin, Cross Site Scripting,
errores en manejo de sesiones, etc.), como as tambin otras vulnerabilidades no
ligadas directamente con las aplicaciones WEB, como desbordamiento de buffer,
denegacin de servicio, etc. Los Frameworks de desarrollo de aplicaciones son una

5
buena ayuda en este punto, ya que ofician de intermediario entre el programador y el
cdigo, y permiten prevenir la mayora de las vulnerabilidades conocidas. Ejemplos de
estos frameworks son Struts, Ruby on Rails y Zope.

Las vulnerabilidades funcionales son aquellas ligadas especficamente a la

funcionalidad de negocio que posee la aplicacin, por lo que no estn previamente
categorizadas. Algunos ejemplos ilustrativos de este tipo de vulnerabilidad son los
siguientes: una aplicacin de banca electrnica que permite realizar transferencias con
valores negativos, un sistema de subastas que permite ver los valores de otros
oferentes, un sistema de venta de entradas para espectculos que no impone lmites
adecuados a la cantidad de reservas que un usuario puede hacer. En la etapa de
codificacin, una de las reglas de oro es verificar todos los valores de entrada y de
salida. Esto es, asumir siempre que el valor pudo haber sido manipulado o ingresado
maliciosamente antes de ser procesado.

TESTING / QA DE SEGURIDAD

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

funcionales de la aplicacin. Para esto, se desarrollan casos de test basados en la
funcionalidad esperada. A esto se le denomina testing funcional y bsicamente consiste
en validar que la aplicacin haga lo que se esperaba que hiciera. Sucede que
habitualmente hay un desfasaje entre el diseo original de la aplicacin (lo que se
espera que haga) y la implementacin real (lo que realmente hace). Aqu surgen tres
reas bien definidas: lo que fue definido y la aplicacin hace, lo que fue definido y la
aplicacin no hace (errores funcionales) y lo que no fue definido pero la aplicacin hace.

Es en este ltimo grupo, en donde habitualmente estn las vulnerabilidades, y el testing

funcional clsico no es capaz de encontrarlas. Por este motivo se necesitan nuevas
tcnicas para explorar lo desconocido. El testing de seguridad se basa principalmente
en probar la aplicacin con escenarios no planificados, incluyendo valores mutados,
fuera de rango, de tipo incorrecto o malformados, acciones fuera de orden, etc. Existen
herramientas automticas que pueden ayudar al analista de QA en la bsqueda de
errores. Las mismas son tiles por su velocidad y capacidad de automatizacin, pero
pueden causar falsos positivos, y por lo general no son buenas detectando
vulnerabilidades funcionales. Es por esto que los mejores resultados resultan de la
combinacin de tcnicas automticas y manuales.

IMPLEMENTACIN / PUESTA EN PRODUCCIN

Tanto la aplicacin como el software de base deben configurarse de manera segura al

momento de poner el software en produccin. En este punto se deben contemplar tareas
como: cambio de usuario y contrasea iniciales o por defecto.

6
La seguridad en las aplicaciones de software debe abordarse desde el primer da del
proceso de desarrollo y a lo largo de todas las etapas del mismo. La integridad de
seguridad a lo largo del SDLC ayuda a reducir las fallas de seguridad como as tambin
los costos de la aplicacin, tanto tangibles como intangibles. Una mala configuracin al
momento de implementar la aplicacin podra echar por tierra toda la seguridad de las
capas anteriores. Tanto la aplicacin como el software de base deben configurarse de
manera segura al momento de poner el software en produccin. En este punto se deben
contemplar tareas tales como: cambio de usuarios y contraseas iniciales o por defecto,
borrado de datos de prueba y cambio de permisos de acceso. Es tambin importante
mantener una correcta separacin de los ambientes de desarrollo, testing y produccin
y procedimientos de traspaso seguro de uno a otro de estos ambientes.

4.3 CONFIABILIDAD DEL SOFTWARE

A veces los sistemas informticos caen y no consiguen realizar los servicios que
se les ha requerido. Los programas que se ejecutan sobre dichos sistemas pueden no
funcionar como se esperaba y, ocasionalmente, pueden corromper los datos que son
gestionados por el sistema. Se ha aprendido a vivir con este tipo de fallos, y pocas
personas confan plenamente en las computadoras personales que normalmente usan.

La confiabilidad de un sistema informtico es una propiedad del sistema que es

igual a su fidelidad. La fidelidad esencialmente significa el grado de confianza del
usuario en que el sistema operar tal y cmo se espera de l y que no fallar al utilizarlo
normalmente.

Es la probabilidad de operacin libre de fallas de un programa de computadora

en un entorno determinado y durante un tiempo especfico. El fallo es cualquier no
concordancia con los requerimientos del software. Hay distintos grados de fallos, estos
pueden ser simplemente desconcertantes o catastrficos.

La confiabilidad del software se encuentra en una etapa de formacin de

desarrollo y es la caracterstica de rendimiento ms costosa y difcil de conseguir y
garantizar. La naturaleza del proyecto ayuda para la formulacin de estimaciones de
costo y el esfuerzo que asegure la confiabilidad requerida.

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

el comportamiento importante para directores e ingenieros. La generacin de fallos
depende del cdigo desarrollado, tales como tamao y las caractersticas del proceso
de desarrollado como las tecnologas y herramientas de ingeniera de software usadas.

7
 La eliminacin de fallos depende del tiempo y del perfil operativo. Los modelos
de confiabilidad del software son generalmente procesos aleatorios. Estos modelos se
pueden dividir en dos grandes categoras:

Modelos que predicen la confiabilidad como una funcin cronolgica del tiempo.
Modelos que predicen la confiabilidad como una funcin del tiempo de
procesamiento transcurrido.

Esta propiedad no se puede expresar numricamente, sino que se utilizan

trminos relativos como no confiables, muy confiables y ultraconfiables para reflejar los
grados de confianza que se pueden tener en un sistema.

Existen cuatro dimensiones principales de la confiabilidad:

Disponibilidad. La disponibilidad de un sistema es la probabilidad de que este

activo y en funcionamiento y sea capaz de proporcionar servicios en cualquier
momento.
Fiabilidad. La fiabilidad de un sistema es la probabilidad de que durante un
determinado periodo de tiempo, el sistema funcione correctamente tal y como
espera el usuario.
Seguridad. La seguridad de un sistema es una valoracin de la probabilidad de
que el sistema cause daos a las personas o a su entorno.
Proteccin. La proteccin de un sistema es una valoracin de la probabilidad
de que el sistema pueda resistir al mal uso o ataques de intrusos.

PRUEBAS DE CONFIABILIDAD
La comprobacin de la confiabilidad consiste en probar una aplicacin para descubrir y
eliminar errores antes de que se implemente el sistema. Puesto que hay infinidad de
combinaciones distintas de recorridos alternativos a lo largo de una aplicacin, no es
muy probable que encuentre todos los errores posibles de una aplicacin compleja. No
obstante, puede probar las situaciones ms probables bajo condiciones normales de
uso y confirmar que la aplicacin proporciona el servicio previsto. Si dispone de tiempo
suficiente, puede realizar pruebas ms complicadas para detectar defectos menos
evidentes.

Tipos de Pruebas de Confiabilidad

De Componentes.
Pruebas de Estrs.
De Integracin.
Pruebas Reales.
Pruebas de Confiabilidad.
Pruebas de Destruccin Aleatoria.

8
 Pruebas de Integracin.
Pruebas Estructurales.

De Componentes
La idea es forzar cada componente de forma aislada ms de lo que la aplicacin podra
experimentar en condiciones normales. Por ejemplo: usar un bucle de 1 a 10.000.000 lo
ms rpidamente posible y observar si hay problemas evidentes.

Pruebas de Estrs
Consisten en la simulacin de grandes cargas de trabajo para observar de qu forma
se comporta la aplicacin ante situaciones de uso intenso.

De Integracin
Estn relacionadas con las interacciones con otras estructuras de datos, procesos y
servicios tanto de los componentes internos y externos de la aplicacin. Es necesario
conocer los recorridos codificados y las situaciones a las que se enfrenta el usuario y
que se identifiquen todas las maneras en las que el usuario se mueve por la aplicacin.

Pruebas de estrs de componentes

Con las pruebas de estrs de los componentes, se aslan los servicios y componentes
que conforman el sistema, se infieren los mtodos de navegacin, de funcionamiento y
de interfaz de estos servicios y componentes y se crea un cliente de prueba que llame
a dichos mtodos. Para aquellos mtodos que tienen acceso a un servidor de base de
datos o a cualquier otro componente, puede crear un cliente que proporcione datos
simulados en el formato previsto. El equipo de prueba inserta datos simulados una y
otra vez mientras observa los resultados.

Pruebas de estrs de integracin

Despus de forzar cada componente individual, deber someter a una situacin de

estrs a toda la aplicacin con todos sus componentes y servicios. Las pruebas de
estrs de integracin estn ntimamente relacionadas con las interacciones con otras
estructuras de datos, procesos y servicios tanto de los componentes internos como de
otros servicios externos de la aplicacin. Las pruebas de integracin comienzan con una
comprobacin bsica del funcionamiento. Es necesario que conozca los recorridos
codificados y las situaciones a las que se enfrentan los usuarios, que comprenda lo que
intentan hacer estos y que identifique todas las maneras en las que el usuario se mueve
por la aplicacin. Las secuencias de comandos de prueba debern probar la aplicacin
de acuerdo con el uso previsto.

Pruebas de Integracin
Identificar errores introducidos por la combinacin de programas probados
unitariamente. Verificar que las especificaciones de diseo sean alcanzadas.

Los componentes no estn implementados en el ambiente operativo. La fase de

integracin requiere mayor planificacin y un conjunto de datos de prueba. Los sistemas
grandes requieren varios pasos para realizar la integracin.

Existen tres tipos bsicos de pruebas:

9
 Todo de una vez: provee una solucin til para realizar la integracin de
problemas simples.
Down-Top: Se empieza con los mdulos de nivel inferior, y se verifica que los
mdulos de nivel inferior llaman a los de nivel superior de manera correcta, con
los parmetros correctos.
Top-Down: se empieza con los mdulos de nivel superior, y se verifica que los
mdulos de nivel superior llaman a los de nivel inferior de manera correcta, con
los parmetros correctos.

Pruebas Estructurales
Son tambin conocidas como "pruebas de caja blanca" o "pruebas basadas en cdigo",
donde se enfocan en probar cada una de las estructuras de cdigo, para que su
comportamiento sea el esperado.

Son las pruebas donde se conoce la estructura interna del componente a probar, y se
efecta una prueba sobre dicha estructura. En el caso de una aplicacin web tambin
se revisa la estructura interna de los links y otros elementos.

4.4 INGENIERIA DE SOFTWARE

En un mundo actual globalizado y sin fronteras de movilidad con respecto al uso

total de Sistemas de Informacin y de las Comunicaciones es imprescindible dejar de
evaluar el papel tan importante al cual se enfrentan los Ingenieros de Software en el
campo de la seguridad.

Se puede pensar en la definicin de seguridad como el grado de confianza que

exige un individuo o empresa para que su informacin no sea mostrada ni divulgada a
todo el mundo, entonces es donde se requiere un compromiso consiente por parte de
los profesionales involucrados en la creacin del software encargado de dicha funcin.

Los sistemas de seguridad crticos son sistemas en los que es esencial que el
funcionamiento del sistema sea siempre seguro. Esto es, el sistema nunca debera
provocar daos en las personas o en el entorno del sistema incluso si ste falla.
Ejemplos de sistemas de seguridad crticos son el control y monitorizacin de sistemas
de un avin, sistemas de control de procesos en plantas qumicas y farmacuticas y
sistemas de control de automviles.

El control mediante hardware de los sistemas de seguridad crticos es ms

sencillo de implementar y analizar que el control mediante software. Sin embargo,
actualmente se estn construyendo sistemas de tal complejidad que no se pueden
controlar nicamente mediante hardware. Es esencial realizar algn control mediante

10
software debido a la necesidad de gestionar un nmero muy grande de sensores y
actuadores con leyes de control complejas.

El software de seguridad crtico se divide en dos clases:

Software de seguridad crtico primario: Es el software que est embebido

como un controlador en un sistema. El mal funcionamiento de dicho software
puede ocasionar un mal funcionamiento del hardware, lo que puede provocar
lesiones personales o da un mal funcionamiento del hardware, lo que puede
provocar lesiones personales o daos en el enlomo.
Software de seguridad crtico secundario: Es el software que indirectamente
puede provocar lesiones. Ejemplos de dichos sistemas son los sistemas de
diseo asistido por computadora, cuyo mal funcionamiento podra provocar un
defecto de diseo en el objeto que se est diseando. Este defecto puede causar
lesiones personales si el sistema diseado no funciona bien. Otro ejemplo de un
sistema de seguridad crtico secundario es una base de datos mdica que
contiene los detalles de los medicamentos administrados a los pacientes. Los
errores en este sistema podran dar lugar a que se administrara una dosis de
medicamentos incorrecta.

La fiabilidad y la seguridad del sistema estn relacionadas, pero son distintos

atributos de confiabilidad. Desde luego, un sistema de seguridad crtico es fiable si est
de acuerdo con su especificacin y funciona sin fallos. Dicho sistema puede incorporar
caractersticas de tolerancia a defectos para que pueda proporcionar un servicio
continuo incluso si se producen defectos. Sin embargo, los sistemas tolerantes a
defectos no son necesariamente seguros. El software an puede funcionar mal y
ocasionar un comportamiento del sistema que provoque un accidente.

Adems del hecho de que nunca se pueda tener la certeza absoluta de que un
sistema est libre de defectos y es tolerante a fallos, hay muchas otras razones por las
que un sistema software que es fiable no necesariamente es seguro:

La especificacin puede estar incompleta en el sentido de que no describe el

comportamiento requerido del sistema en algunas situaciones crticas. Un alto
porcentaje de sistemas que funcionan mal (Natajo y Kume, 1991; Lutz, 1993) se
debe a errores de especificacin ms que a errores de diseo. En un estudio de
errores en sistemas empotrados, Lutz concluye que: Las dificultades con los

11
 requerimientos son la causa clave de los errores de software relacionados con
la seguridad que persistieron hasta la integracin y la prueba del sistema.

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

impredecible y enfrente al software con un entorno inesperado. Cuando los
componentes estn prximos a fallar, pueden comportarse de forma errtica y
generar seales que estn fuera de los rangos que puede manejar el software.

Los operadores del sistema pueden generar entradas que no son

individualmente incorrectas, pero que, en situaciones particulares, pueden dar
lugar a un mal funcionamiento del sistema. Como ejemplo anecdtico se puede
citar el caso en que un mecnico dio instrucciones al software de utilidades de
gestin de un avin para que levantara el tren de aterrizaje. El software ejecut
las instrucciones perfectamente. Por desgracia, el avin permaneci en tierra
todo el tiempo; claramente, el sistema debera haber inhabilitado el comando a
menos que el avin estuviese en el aire.

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

crticos y es importante comprender los trminos especficos utilizados.

La clave para garantizar la seguridad es asegurar que los accidentes no ocurran

o que las consecuencias de stos sean mnimas. Esto puede conseguirse de tres formas
complementarias:

Evitacin de contingencias: El sistema se disea para que las contingencias

se eviten. Por ejemplo, un sistema de corte que requiere que el operador
presione dos botones distintos al mismo tiempo para utilizar la mquina evita la
contingencia de que los dedos del operador estn cerca de las cuchillas.
Deteccin y eliminacin de contingencias: El sistema se disea para que las
contingencias se detecten y eliminen antes de que provoquen un accidente. Por
ejemplo, un sistema de una planta qumica puede detectar una presin excesiva
y abrir una vlvula de escape para reducir la presin antes de que ocurra una
explosin.
Limitacin de daos: El sistema incluye caractersticas de proteccin que
minimizan el dao que puede resultar de un accidente. Por ejemplo, el motor de
un avin normalmente incluye extintores de incendios automticos. Si se

12
 produce un fuego, a menudo ste se puede controlar antes de que suponga una
amenaza para el avin.

Los accidentes ocurren generalmente cuando varias cosas van mal al mismo
tiempo. Un anlisis de accidentes serios (Perrow, 1984) sugiere que casi todos ellos se
debieron a una combinacin de malos funcionamientos ms que a fallos aislados. La
combinacin no anticipada condujo a interacciones que provocaron fallos de
funcionamiento del sistema. Perrow sugiere tambin que es imposible anticiparse a
todas las posibles combinaciones de mal funcionamiento de un sistema, y que los
accidentes son una parte inevitable del uso de sistemas complejos. El software tiende a
incrementar la complejidad del sistema, de tal forma que al realizar el control mediante
software puede incrementar la probabilidad de accidentes del sistema.

Sin embargo, el software de control y monitorizacin puede mejorar tambin la

seguridad de los sistemas. Los sistemas controlados por software pueden monitorizar
un rango de condiciones ms amplio que los sistemas electromecnicos. Los primeros
se pueden adaptar con relativa facilidad. Adems implican el uso del hardware de la
computadora, el cual tiene una fiabilidad inherente muy alta y es fsicamente pequeo y
ligero. Los sistemas controlados por software pueden proporcionar mecanismos de
seguridad sofisticados. Pueden soportar estrategias de control que reducen la cantidad
de tiempo que las personas necesitan consumir en entornos con contingencias. En
consecuencia, si bien el software de control puede introducir ms formas en las que un
sistema puede funcionar mal, tambin permite una mejor monitorizacin y proteccin,
por lo tanto, puede mejorar la seguridad del sistema.

En todos los casos, es importante mantener un sentido de la proporcin sobre la

seguridad del sistema. Es imposible conseguir que un sistema sea totalmente seguro, y
la sociedad debe decidir si los beneficios del uso de tecnologas avanzadas compensan
o no las consecuencias de un accidente ocasional. Tambin es una decisin social y
poltica cmo utilizar unos recursos nacionales limitados a fin de reducir el riesgo para
la poblacin en su conjunto.

La ingeniera de seguridad son mtodos para disear y construir sistemas que

permanezcan confiables a pensar de posibles actos maliciosos o errores de diverso tipo
incluyendo las fallas de carcter fortuito.

13
 Algunos ejemplos de sistema en los que la seguridad es un aspecto fundamental
son los siguientes:

La contabilidad de un banco.
Los cajeros automticos.
Los mecanismos de proteccin fsica, como alarmas y sensores en general,
destinados a detectar intrusos no deseados.
Los servicios en lnea, va internet.
Obviamente en aplicaciones militares.
La privacidad es un tema de importancia en el caso de informacin de salud, o
mala informacin obtenida a travs de los censos.
La necesidad de manejar operaciones seguras en el internet, espacio en el cual
los ataque del tipo negacin de servicios son comunes.

ATAQUE DE SEGURIDAD
Hasta la aparicin de la informtica la valoracin de los activos de una
empresa se haca segn los objetos fsicos tiles, las producciones propias, las
infraestructuras, la tesorera y el capital humano. Desde los ltimos aos se ha
aadido un nuevo capital tan importante como los anteriores, el valor de la
informacin. No es que antes no existiera la informacin en las empresas, el
espionaje industrial es tan antiguo como la revolucin industrial, pero se
mantena con el sistema de papel y archivadores y formaba parte de los activos
de oficina. Hoy en da, la informacin se maneja en grandes cantidades y de
procedencias muy diversas, el valor aadido de una empresa puede ser la
informacin que maneja.

Como capital de la empresa cada vez es ms importante mantener la

seguridad de la informacin, pero tambin los riesgos cada vez son mayores.
Estos riesgos se pueden clasificar por su procedencia en tres categoras:

Errores involuntarios de personas y/o mquinas.

Desastres naturales.
Ataques voluntarios.

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

Denegacin de servicio: disponibilidad. Prohibir el acceso a la

informacin.
Observacin no autorizada: confidencialidad. Acceso a informacin
por personas que pueden utilizarla para daar la empresa, o sea,
personas no autorizadas.
Modificacin no autorizada: integridad. Acceso a la informacin y
modificacin, ya sea borrando, cambiando, aadiendo o sustituyendo
datos.

La proteccin de la informacin es ms grave desde la aparicin de las

redes telemticas. Estas redes y especialmente Internet, hacen que la
informacin sea un problema global y no aislado a las mquinas internas de la
empresa. Las tecnologas aplicadas a la seguridad en redes estn en su fase de
desarrollo inicial, especialmente por dos motivos:

La mayora de sistemas operativos estn pensados para

arquitecturas mainframe/terminal y no para arquitecturas
cliente/servidor o Internet/Intranet que se utilizan actualmente.
No existen estndares ni organizaciones mundiales aceptadas por
todas las empresas proveedoras de seguridad.

15
BIBLIOGRAFA
Ingeniera de software, sptima edicin, Iam Sommerville, Pearson Educacin, S.A.,
Madrid, 2005.

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

Del desarrollo de software
Obtenido en:
http://www.prensariotila.com/pdf/TutorialCybsec_0710.pdf

PONS MARTORELL, MANUEL, Criptologa

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

MAA ANTONIO, RAY DIEGO, SNCHEZ FRANCISCO, Integrando la Ingeniera de

seguridad en un proceso de ingeniera software.
Obtenido en:
http://web.iti.upv.es/~fsanchez/publications/RECSI04ManaSanchezRayYague.pdf

16