UNIDAD
4
4.1 SEGURIDAD
EN INGENIERÍA DE SOFTWARE
La seguridad de
software aplica los principios de la seguridad de información al desarrollo de
software. Información security (La seguridad de información) se refiere a la
seguridad de información comúnmente como la protección de sistemas de
información contra el acceso desautorizado o la modificación de información, si
esta en una fase de almacenamiento, procesamiento o tránsito. También la protege
contra la negación de servicios a usuarios desautorizados y la provisión de
servicio a usuarios desautorizados, incluyendo las medidas necesarias para
detectar, documentar, y contrarear tales amenazas.
Muchas preguntas
con respecto a la seguridad, son relacionadas al ciclo vital de software. En
particular, la seguridad del código y el processo de software; deben de ser
considerados durante la fase del diseño y desarrollo. Además, la seguridad debe
de ser preservada durante la operación y el mantenimiento para asegurar la
integridad de una parte (pedazo) de software.
Una gran cantidad
de seguridad usada en los Sistemas de Redes de hoy, nos pueden engañar en la
creencia que nuestros trabajos como diseñadores de sistema de seguridad ya han
sido realizados. Sin embargo, las cadenas y computadoras son increíblemente
inseguras. La falta de seguridad se origina en dos problemas fundamentales: Los
sistemas que son teóricamente seguros pueden ser inseguros en la práctica,
Además los sistemas son cada vez más complejos. La complejidad proporciona más
oportunidades para los ataques. Es mucho más fácil probar que un sistema es
inseguro que demostrar que uno es seguro -- probar la inseguridad, simplemente
una toma ventaja de ciertas vulnerabilidades del sistema. Por otra parte,
probando un sistema seguro, requiere demostrar que todas las hazañas posibles
puedan ser defendidas contra (muy desalentadora), si no imposible, la
tarea
Actualmente, no hay
ninguna solución singular para asegurar la ingenieria de software. Sin embargo,
hay métodos específicos que mejoran la seguridad de los sistemas. En
particular, podemos mejorar la confiabilidad de software. Tambien podemos
mejorar nuestra comprensión de los requisitos de un pedazo de software.
4.2 SEGURIDAD
EN EL CICLO DE VIDA DEL DESARROLLO DE SOFTWARE”
Actualmente la mayoría de los procesos de
desarrollo no incluyen seguridad, o bien la incluyen al final (etapa de
testing)
El costo de solucionar las vulnerabilidades es
mayor cuanto más tarde se detectan las mismas (igual que los bugs)
Grandes mitos y excusas flacas
·
La seguridad de la aplicación es
responsabilidad del programador.
·
Nadie sabe cómo funciona, por ende, no la van a atacar.
·
Si no se encontraron vulnerabilidades hasta
ahora…
·
A nadie le interesaría atacar nuestra aplicación.
·
La aplicación es segura porque
corre detrás de un firewall.
·
La aplicación es segura porque usa encripción.
·
Si no corre como Administrator / root, no
funciona.
·
Si, ese feature (que es inseguro) viene
habilitado por default,pero el administrador lo puede deshabilitar. ƒNo hay manera de
explotarla.
·
No hay tiempo para incluir seguridad.
Seguridad en el an Seguridad en el aná álisis
de requerimientos lisis de requerimientos
Durante el análisis de requerimientos, se
pueden identificar diversas
características que derivarán en los requerimientos de seguridad del
software. Por ejemplo:
·
Arquitectura de la aplicación
·
¿Cliente/servidor o Desktop?
·
Plataforma donde correrála
aplicación
·
PC / Palm / Teléfono celular
·
Tipos de datos que se almacenan o
transfieren
·
Confidenciales / públicos
·
Requerimiento de compliance con
normativas y marcos regulatorios
·
SOX,
PCI-DSS, “A”4609
·
Tipos de registro que el sistema debe generar
Tipos de registro que el sistema debe generar
·
Acceso a recursos, uso de privilegios, etc.
·
Perfiles de usuario necesarios
para la aplicación
·
Administrador, revisor, ed itor, usuario básico, etc.
·
Tipos de acceso a los datos por
parte de cada perfil
·
Lectura, escritura, modificaci ón, agregado, borrado, etc.
·
Acciones sobre el sistema que
puede hacer cada perfil ƒ Cambiar la configuración del sistema
·
Arrancar o detener servicios
·
Modos de autenticación
·
Passwords, Tokens, Biométricos
·
1 factor, 2 factores, etc
Seguridad
en el diseño
Muchas de las vulnerabilidades encontradas en
aplicaciones tuvieron su causa en errores de diseño. Ej:
Aplicación Homebanking(WEB)
·
Incluía el número de cuenta en el requestde transferencias
·
No validaba que la cuenta origen
perteneciera al usuario logueado Vulnerabilidad:Transferencias desde cuentas
ajenas
·
Aplicación de Admy Finanzas
(Consola Unix)
·
Tomaba el usuario de una variable
de entorno
·
Permitía que el usuario “escapara”a un shell
·
Vulnerabilidad:Se puede establecer
un usuario arbitrario
Buenas prácticas para el diseño de una aplicación segura
·
Reducción de Superficie de ataque
·
Criterio del menor privilegio
·
Fallar de manera segura
·
Criterio de defensa en profundidad
·
Diseño seguro de mensajes de error
·
Diseño seguro de autenticación
·
Separación de privilegios
·
Interacción “amigable”con Firewalls e IDS's.
·
Administración segura información
Sensible
·
Diseño de Auditoría y Logging
·
Análisis de riesgo
4.3
CONFIABILIDAD Y TOLERANCIA A DEFECTOS
Conocer el concepto de confiabilidad, sus deterioros,
medios y atributos. Comprender las técnicas para el Logro de la confiabilidad
mediante el software, en especial los aspectos referentes a la Tolerancia a
defectos.
Confiabilidad
(“Dependability”) Confiabilidad:
propiedad de un sistema que permite que se justifique la confianza en el
servicio que ofrece.
Atributos de la Confiabilidad
Existen muchos tipos de aplicaciones cada una de las
cuales requiere de un énfasis particular en diferentes aspectos de la
confiabilidad. La confiabilidad se expresa mediante diferentes atributos o
propiedades:
Disponibilidad (“Availability”): medida en la cual el
sistema está listo para ser usado. Fiabilidad (“Reliability”): medida en la
cual el sistema suministra su servicio de forma continua. Seguridad (“Safety”)
medida en la cual un sistema evita consecuencias catastróficas sobre su
entorno. Confidencialidad (“”) Integridad: Mantenibilidad (“”): mediada en la
cual el sistema está apto para reparaciones y modificaciones.
Protección (“security”): integridad +
disponibilidad + confidencialidad.
Confiabilidad del Software 4 Luis Eduardo Leyva del
Foyo
Seguridad y Fiabilidad
Seguridad (“Safety”): ausencia de situaciones que
puedan causar muertes, heridas, enfermedades o daños en los equipos y en el
medio ambiente.
·
La mayoría de los sistemas que tienen algún elemento de
riesgo asociado a su uso son inseguros (“unsafe”).
·
Un accidente (“mishap”) es un suceso imprevisto que puede
producir daños inadmisibles
Fiabilidad (“reliability”) una medida del éxito con el
cual un sistema se ajusta a alguna especificación autorizada de su
comportamiento.
Seguridad y fiabilidad pueden estar en conflicto.
La seguridad es la probabilidad de que no se produzcan
situaciones que puedan conducir a accidentes, independientemente de que se
cumpla o no la especificación
Deterioros de la Confiabilidad
Existen tres factores de deterioro (“impairments”) de
la confiabilidad: Fracaso o Falla
(“failure”): es un comportamiento inaceptable del sistema que no cumple con su
especificación. Error: estado interno del sistema que difiere de uno válido y
que es susceptible de conducir a un fallo Defecto (“fault”): Condición que
provoca el error.
Cadena (Fundamental) de Fallas Los sistemas están constituidos por
componentes que son sistemas en si mismos: una falla en un sistema conducirá a
un defecto en otro y éste al error y así:
Tipos de Defectos (“faults”) o Defectos Transitorios (“Transient faults”):
inician en un instante de tiempo
particular, permanecen por algún período de tiempo y luego desaparecen
solos:
·
componentes de hardware con reacción adversa a alguna
interferencia externa, tal como los campos eléctricos o la radioactividad; o
muchos defectos en sistemas de comunicación.
·
Defectos Permanente (“Permanent faults”): se inician en
instante de tiempo específico y permanecen hasta tanto son reparados:
·
rotura de un conductor
o errores de diseño del software (“bugs”).
·
Defectos Intermitentes (“Intermitent faults”): son defectos
transitorios que ocurren de vez en cuando:
·
componente de hardware sensible al calor; este trabaja por un
tiempo, deja de trabajar, se enfría y luego comienza a trabajar
nuevamente.
Los sistemas confiables, tienen que prevenir que todos
estos tipos de defectos provoquen un comportamiento erróneo del sistema (o sea,
la falla)
Medios de la Confiabilidad Los Medios son los métodos y técnicas que
permiten: a. Proveer la capacidad de entregar un servicio sobre el que se pueda
depositar confianza b. Que se alcance la confianza en esa capacidad o Usados en el proceso de construcción de
software con el propósito de adquirir la confiabilidad: Evitación de Defectos
(“Fault avoidance”): para evitar o prevenir la introducción y ocurrencia de
defectos. Tolerancia a Defectos (“Fault
Tolerante”): para suministrar servicios que cumplan con su especificación a
pesar de la existencia de defectos. O
Contribuyen a la validación del software luego de ser desarrollado con el propósito de asegurar
la confiabilidad: Eliminación de Defectos (“Fault Removal”): detectar la
presencia de defectos y eliminarlos.
Predicción de Defectos/fallos (“Fault/failure forecasting”) para estimar
la presencia de defectos y la ocurrencia y consecuencia de los fallos. La Evitación y la Eliminación son técnicas de
Prevención de Defectos (“Fault Prevention”).
Evitación de Defectos (“fault Avoidance”)
La evitación (o evasión) de defectos intenta limitar
la introducción de componentes potencialmente imperfectos durante la
construcción del sistema. Hardware: Uso
de componentes más confiables dentro de las restricciones de costo y desempeño
determinadas. Técnicas refinadas y cuidadosas para interconectar componentes y
ensamblar subsistemas; Empaquetar el hardware para apantallar las formas de
interferencia esperadas.
Software: Los componentes de software son mucho más complejos
que los componentes de hardware. En general es imposible escribir programas sin
defectos. Sin embargo, es posible mejorar la calidad del software
mediante:
Especificación de requerimientos formal o rigurosa;
Empleo de metodologías de diseño probadas; Empleo de lenguajes con facilidades
para abstracción de datos y modularidad; Uso de entornos de ingeniería de
software que ayuden a manipular los componentes de software y por tanto manejar
la complejidad.
Eliminación de Defectos (“Fault Removal”).
La eliminación de defectos comprende los
procedimientos para encontrar y eliminar las causas de los errores. Por
ejemplo: Revisiones de diseño (“design
reviews”) Verificación de programas (“program verification”) Inspección de
código (“code inspections”) Pruebas del sistema (“system testing”)
En general se hace énfasis en las pruebas del sistema.
Estas son necesarias, pero tienen problemas: En general. Nunca pueden ser
exhaustivas; Sólo sirven para mostrar que hay errores, no que no hay. A menudo es imposible reproducir las
condiciones reales: la mayoría de las pruebas se hacen con el sistema en modo
de simulación y es difícil garantizar que la simulación sea exacta. Los errores de especificación no se detectan:
los errores introducidos en la etapa de requerimientos pueden no manifestarse
hasta tanto el sistema se ponga en operación.
A pesar de todas las técnicas de prueba y
verificación, los componentes de hardware fallarán.
Confiabilidad del Software 13 Luis Eduardo Leyva del
Foyo
Tolerancia a Defectos (“Fault Tolerance”)
Dada las limitaciones inherentes del método de
prevención de defectos, los diseñadores tienen que considerar el empleo de
tolerancia a defectos.
Un sistema puede suministrar varios niveles de
tolerancia a defectos:
·
Tolerancia a defectos completa (“fail operacional”) – el
sistema continúa operando en presencia de errores, aunque por un período
limitado, con ninguna pérdida significativa de funcionalidad o desempeño.
·
Degradación aceptable (“graceful degradation”) o falla suave
(“fail soft”) – el sistema continúa operando en presencia de errores, aceptando
una degradación parcial de su funcionalidad o desempeño durante la recuperación
o reparación.
·
Parada segura (“fail safe” o “fail stop”) – el sistema
mantienen su integridad aunque acepta un paro temporal y en estado seguro de su
operación.
El grado de tolerancia necesario en el sistema depende
de la aplicación
Confiabilidad del Software 14 Luis Eduardo Leyva del
Foyo
Redundancia
La tolerancia de fallos se basa en la redundancia. Se
utilizan componentes adicionales (que no hubiesen sido necesarios en un sistema
perfecto) para:
detectar los fallos y recuperar el comportamiento correcto.
A esto con frecuencia se le conoce como redundancia
protectora (“protective redundancy”)
Se pretende minimizar la redundancia a la vez que se
maximiza la fiabilidad que se le provee al sistema, sujeto a restricciones de costo y tamaño del
sistema.
Advertencia: Debe tenerse cuidado ya que:
Los componentes adicionales aumentan inevitablemente
la complejidad del sistema
Ello puede introducir fallos adicionales dando como
consecuencia sistemas menos fiables.
Redundancia (Hardware Tolerante a Defectos)
Redundancia estática:
Los componentes redundantes dentro del sistema están
siempre activos y se usan para enmascarar el efectos de los defectos (las
fallas). Por ejemlo: Redundancia
Modular Triple o TMR (“Triple Modular Redundancy”). Se puede extender a N. o 3 subcomponentes idénticos y circuitos de
votación por mayoría. Si uno difiere de los otros dos la salida del diferente
se enmascara. o Supone que los defectos no se deben a aspectos comunes (tales
como errores de diseño) sino a aspectos transitorios o debido al deterioro.
Redundancia dinámica:
Se suministra redundancia dentro del componente sólo
para la detección del error. La redundancia para la recuperación del error se
suministra mediante otros componentes externos que se activan sólo cuando se
detecta un error. Ejemplos:
Sumas de comprobación en las comunicaciones bits de
paridad en las memorias
Confiabilidad del Software 16 Luis Eduardo Leyva del
Foyo
Redundancia (Software Tolerante de Defectos)
La tolerancia a defectos del Software es el conjunto
de técnicas para detectar y corregir equivocaciones o errores del diseño.
Redundancia estática:
Programación con N versiones
Redundancia dinámica:
Tiene dos etapas: detección y recuperación del
error
Bloques de recuperación: Proporcionan recuperación
hacia atrás
Excepciones: Proporcionan recuperación de error hacia
adelante.
4.3
CONFIABILIDAD
La Calidad es una medida de la performance de un
elemento en un punto determinado del tiempo, presumiblemente t=0. La
Confiabilidad es una medida de performance a lo largo del tiempo. Una está
relacionada con la variable aleatoria “proporción” la otra con la variable
aleatoria “tiempo”. El Software no admite la misma discriminación.
Es posible hablar de Calidad, expresada ésta como
proporción de errores (Bugs) en el programa. Mientras la Confiabilidad está
expresada en función de la tasa de fallas (Hazard Failure Rate). La mayoría
de los especialistas hablan de Calidad y Confiabilidad en forma indistinta.
Lo cierto es que un Software no puede producirse en serie varias veces. Una
vez desarrollado, probado y liberado, todos los Softwares serán copia de éste,
en cualquier sistema que corran.
Los errores, no así las fallas, serán siempre los
mismos, no importa el entorno en el que corran.
·
Por lo tanto, es mucho más correcto hablar de Confiabilidad
de un Software que de la Calidad del mismo.
·
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.
·
A nuestros fines 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.
·
El 72% de los errores se originan en: “el traslado de los
requerimientos del usuario y en el diseño lógico”.
·
Podremos aumentar la Confiabilidad de un Software haciendo
hincapié en estas dos primeras etapas.
·
Fuentes de diversos tipos aseveran que, es en el diseño, en
donde debe ponerse énfasis para reducir la proporción de errores.
·
El costo de detección y corrección de errores durante y
después de las etapas de integración y test resultan entre 10 y 15 veces más
que en las etapas de desarrollo y codificación.
·
Estudios realizados
concluyen que el medio ambiente en el que se desarrolla el Software contribuye
enormemente al aumento de errores.
·
La Confiabilidad del Software pasa a ser un problema de
“Management” y no “Técnico”
4.4
INGENIERIA DE SEGURIDAD
El concepto de la
seguridad en los sistemas de software es un área de investigación que ha pasado
a ser vital dentro de la Ingeniería de Software. Con el crecimiento de
Internet, y otras aplicaciones sobre redes, como el comercio electrónico,
correo electrónico, etc., la posibilidad de ataques se ha incrementado
notablemente, como también lo han hecho las consecuencias negativas de estos
ataques. En la actualidad prácticamente
todo sistema debe incorporar cuestiones de seguridad para defenderse de ataques
maliciosos. El desarrollador ya no sólo debe concentrarse únicamente en los
usuarios y sus requerimientos, sino también en los posibles atacantes. Esto ha
motivado cambios importantes en el proceso de diseño y desarrollo de software
para incorporar a la seguridad dentro de los requerimientos críticos del
sistema.
Estos cambios son
los primeros pasos en la concientización
de los ingenieros de software acerca de la importancia de obtener un
software seguro. Como todo gran cambio, no se logra de un día para otro, sino
que es un proceso gradual que requiere tiempo y maduración. Todavía la
Ingeniería de Software no ha dado una respuesta eficaz, coherente y aplicable
que satisfaga plenamente a la comunidad informática, sino que las
aproximaciones actuales están plagadas de fallas y debilidades fruto de que
todavía es un proceso que se encuentra en su infancia.
En este sentido,
existe un nuevo paradigma de
programación, la programación orientada a aspectos (POA) [7,9], el cual al
permitir encapsular requerimientos o conceptos típicamente no funcionales, como
la seguridad, se convierte en una herramienta atractiva para el desarrollo de
software seguro. La POA nos permitiría encapsular las políticas de
seguridad de forma separada e independiente del resto del sistema, con las
consecuentes ventajas que esto implica:
- Mayor reusabilidad.
Asteasuain
Fernando, Schmidt Leandro. Universidad Nacional del Sur. Bahía Blanca 2
- Mejoras
sustanciales respecto al mantenimiento, modificaciones, etc. - Mayor grado de
especialización. - Menor complejidad del sistema.
Vemos que si bien
la POA no agrega por si misma seguridad a sus aplicaciones, nos brinda un
entorno ideal para incorporar el concepto de
seguridad de forma coherente y natural
en el desarrollo de software. Una de las reglas generales que gobiernan
la correcta implementación de la seguridad es que la misma debe aplicarse
correcta y consistentemente a través de todo el sistema [6]. Esto se logra
naturalmente con este nuevo paradigma.
Nuestro trabajo
apunta entonces a investigar la aplicabilidad de la POA a la seguridad en
software, al considerarlo como la alternativa más viable y prometedora en pos
de lograr software seguro.
2. Problemática
actual de la seguridad en el software
Los puntos débiles
más importantes de la Ingeniería de Software con respecto a la seguridad pueden
ser clasificados en dos grandes categorías: i) Fallas para implementar software
seguro. ii) Fallas para implementar seguridad en el software.
2.1 Fallas para
implementar software seguro
Lamentablemente, la
mayoría de las herramientas que tiene disponible un desarrollador de software
sufren de fallas propias de seguridad.
Una de las
debilidades más trascendentes al momento de implementar software seguro surge
del estado de los lenguajes de
programación desde el punto de vista de la seguridad. Son escasos los lenguajes
que proveen primitivas “seguras” que ayuden al programador a escribir un mejor
código.
Dos de los
lenguajes de programación más usados en la actualidad, C y C++, presentan
graves problemas de seguridad. Esto se debe a que al utilizar muchos de sus
servicios provistos por sus librerías estándar se introducen fallas de
seguridad que pasarán inadvertidas al programador debido a que éste las
considera libre de errores. Como ejemplo, podemos citar el problema de “buffer
overflow”, fallas en la rutina malloc(a,b) y en la rutina rand() [8]. También,
en un trabajo de John Viega y su equipo [10], se identifican numerosas fallas
en el lenguaje C: en la rutina gets, donde también se explota el “overflow” de
buffers, en las rutinas para manejar de strings strcat, strcpy, sprintf, en las
rutinas system y popen, para correr programas desde la línea de comandos, que
son generalmente usadas de manera incorrecta, y otras fallas más sutiles, que
se pueden introducir al considerar cuestiones de sincronización.
Asteasuain
Fernando, Schmidt Leandro. Universidad Nacional del Sur. Bahía Blanca 3
También lenguajes
con arquitecturas de seguridad mucho más
complejas, como Java, dejan mucho que desear. En [8], se establece que un alto
porcentaje de aplicaciones tiene problemas de seguridad que están presenten
desde la fase de diseño y que permanecen hasta la implementación,
independientemente del lenguaje de programación usado.
Las razones por las
cuales estas fallas “internas” permanecen en la actualidad son varias: mal
entendimiento de los protocolos de seguridad, una visión ingenua respecto a lo
que un sistema debiera considerar como seguro, aproximaciones no serias a la
seguridad como “corregir luego” o “no se van a dar cuenta”, o directamente
desconocimiento, ya que lamentablemente estas fallas no son conocidas
universalmente, y existen pocas fuentes de información para escribir código
seguro.
Otro tipo falla en
esta categoría, que se establece en [4],
nace del hecho de que la seguridad es un tema complejo y requiere un
entendimiento completo sobre lo que puede ir mal y qué es lo que puede ser
explotado por un posible atacante. Un programador promedio no cuenta con la
experiencia suficiente como para poder determinar los requerimientos de
seguridad que necesite su aplicación. Esto resulta en la subestimación de
pequeños detalles que luego pueden llegar a introducir grandes fallas de
seguridad.
Fallas para implementar seguridad en el software
En la actualidad,
el desarrollador de software que quiera incorporar seguridad a su sistema se
enfrentará con la difícil realidad de las técnicas de programación
tradicionales, y también, con una Ingeniería de Software que recién está
aprendiendo sobre la seguridad.
Típicamente la
seguridad es considerada como un requerimiento no funcional. Luego, debido a
los problemas de planificación y presupuesto, la seguridad sólo es tenida en
cuenta una vez que los requerimientos funcionales son obtenidos. Esto conduce a
que la seguridad sea considerada como un concepto “afterthougth”[1], y que se
incorpore tardíamente al sistema. Esto
lleva a una implementación pobre, ineficiente, e inadecuada de la seguridad.
También, la mayoría de las metodologías de diseño y herramientas dedicadas a la
seguridad trabajan de esta forma, como herramientas “afterthougth” (ver sección
de Trabajo Relacionado). Por lo tanto, es mandatorio que los conceptos de seguridad formen parte integral en todo el ciclo de vida de desarrollo de
software, tal como se lo demanda en [1,3].
Una de las
aproximaciones más ampliamente utilizada para la seguridad es la aproximación
“ataque-parche” ( en inglés “penetrate and patch”), en donde la seguridad es
tratada de una manera ad-hoc, a medida que las fallas se van revelando. Esto
es, se desarrolla el sistema con mínimas consideraciones con respecto a la
seguridad. Luego, una vez que el sistema está funcionando se detectarán los
ataques al mismo, y se buscará recién ahí la manera de corregirlos. Bajo esta
aproximación, claramente, es imposible implementar la seguridad de una manera
adecuada: 1) Se deben detectar los
ataques, que no es una tarea menor.
Asteasuain
Fernando, Schmidt Leandro. Universidad Nacional del Sur. Bahía Blanca 4
2) Una vez
identificado el ataque, se deben tomar las acciones necesarias como para que
este tipo de ataque no vuelva a ocurrir. Esto implica revisar todo el código
del sistema y ubicar el(los) lugar (lugares)
donde se deban introducir las modificaciones. Como sabemos, esta tarea
no es para nada sencilla. 3) Volver a revisar el código y analizar la posible
existencia de efectos colaterales introducidos por las modificaciones del paso
2).
Esta aproximación a
la seguridad es similar la gestión de riesgo “Indiana Jones”[11]: “no ocuparse
de la seguridad hasta que se de un ataque, entonces buscar una solución
heroica”. Como establece Pressman en [11], ni el ingeniero de software es
Indiana Jones ni el resto del equipo sus valientes colaboradores. Es imperioso por lo tanto un enfoque más
formal al tema de la seguridad en la Ingeniería de software.
Otra notable
debilidad proviene del hecho de que las técnicas tradicionales de descomposición no logran encapsular
correctamente el concepto de seguridad. Ya sea con la Programación Orientada a
Objetos (POO), con la programación estructurada por bloques, o con la
programación declarativa, no se consigue separar adecuadamente el concepto de
seguridad del resto del sistema.
En [4], Bart de Win
y sus colaboradores, sugieren que esta incorrecta modularización se produce por
una diferencia de estructuras. Se mencionan dos estructuras diferentes: por un
lado, las estructuras de abstracción y modularización propuestas por las
técnicas actuales de descomposición, y por el otro, la estructura de la
seguridad como requerimiento. Esta incompatibilidad estructural, lleva a que en
el momento de introducir la seguridad en
el sistema, el código correspondiente a la seguridad quede desparramado,
disperso, por todo el sistema. Los problemas que trae consigo este código
“mezclado”[7] son numerosos: - Código
duplicado. - Aumento en la complejidad del mantenimiento: introducir un cambio
implica revisar todo el código, ya que el código de seguridad resulta disperso,
y tan solo olvidarse de una modificación
llevará a una falla de seguridad. - Incremento en la complejidad global del
sistema: el código de la funcionalidad básica se ve “ensuciado” por el código
relativo a la seguridad. - Menor flexibilidad para el manejo de políticas de
seguridad: al ser compleja la realización de cambios, también será complejo
implementar cambios en la política de
seguridad.
3. Objetivos para
un software seguro
En pos de conseguir
un software seguro, se debe dejar claro qué se entiende por seguridad, para así
luego poder establecer requisitos mínimos que debe satisfacer un sistema que
pretenda ser considerado seguro.
Como definición del
concepto de seguridad en software, se adoptará en este trabajo la definición
que propone Doshi Shreyas en [1]: la seguridad de un sistema de
Asteasuain
Fernando, Schmidt Leandro. Universidad Nacional del Sur. Bahía Blanca 5
software es un
concepto multi-dimensional. Las múltiples dimensiones de la seguridad son: -
Autenticación: el proceso de verificar la identidad de una entidad. - Control
de acceso: el proceso de regular las clases de acceso que una entidad tiene
sobre los recursos. - Auditoria: un registro cronológico de los eventos
relevantes a la seguridad de un sistema. Este registro puede luego examinarse
para reconstruir un escenario en particular. - Confidencialidad: la propiedad
de que cierta información no esté disponible a ciertas entidades. - Integridad:
la propiedad de que la información no sea modificada en el trayecto
fuente-destino. - Disponibilidad: la propiedad de que el sistema sea accesible
a las entidades autorizadas. - No repudio: la propiedad que ubica la confianza
respecto al desenvolvimiento de una entidad en una comunicación.
La seguridad puede
tener diferentes significados en distintos escenarios. En general, cuando se
habla de seguridad implica referirse a más de una de las dimensiones
mencionadas anteriormente. Por ejemplo: - Seguridad en correo electrónico:
involucra confidencialidad, no repudio e integridad. - Seguridad en compras
online: implica autentificación, confidencialidad, integridad y no
repudio.
Bajo este punto de
vista, se define un ataque a la seguridad como un intento de afectar en forma
negativa una o más de las dimensiones del concepto de seguridad.
Una vez definido el
concepto de seguridad, se pueden establecer objetivos básicos para un software
seguro: - Independencia de la seguridad: la seguridad debe construirse y
utilizarse de manera independiente de la aplicación. - Independencia de la
aplicación: la aplicación no debe depender del sistema de seguridad usado, debe
ser desarrollada y mantenida en forma separada. - Uniformidad: la seguridad
debe aplicarse de manera correcta y consistente a través de toda la aplicación
y del proceso que desarrolla la misma. - Modularidad: mantener la seguridad
separada. Entre otras ventajas, esto nos brindará mayor flexibilidad y menor
costo de mantenimiento. - Ambiente seguro: se debe partir de un entorno
confiable. Es decir, las herramientas de desarrollo y lenguajes de programación
no deben contener agujeros de seguridad. - Seguridad desde el comienzo: la
seguridad debe ser considerada como un requerimiento desde el inicio del
diseño.
