Академический Документы
Профессиональный Документы
Культура Документы
DGEST
INSTITUTO TECNOLGICO
DE LZARO CRDENAS
SES
MONOGRAFIA:
METODOLOGA DE DESARROLLO DE SOFTWARE
SEGURO
POR:
EDSON TAYDE MACIEL RUMBO.
MITZI NELLY MALDONADO CARRILLO.
DORINA QUINTANA CARMONA.
EDGAR SALVATORE ESPINDOLA FLORES.
PROFESOR:
ING.JESUS DANIEL ROJAS CID
NOVIEMBRE DE 2013.
Av. Melchor Ocampo # 2555, Col. Cuarto Sector, C.P. 60950, Cd. Lzaro Crdenas, Michoacn,
Telfono (753) 53 7 19 77, 53 2 10 40, 53 7 53 91, 53 7 53 92 Direccin Ext. 109 , Fax. 108
e-mail: direccion@itlac.mx Internet: www.itlazarocardenas.edu.mx.
Pgina 1
INDICE
INTRODUCCIN A LA SEGURIDAD DE SOFTWARE. ___________________ 5
1.1 Introduccin a la Seguridad de Aplicaciones. ___________________________ 8
1.1.1
Introduccin a la seguridad informtica _____________________________________ 9
1.1.2 Introduccin a la seguridad _________________________________________________ 10
1.1.3 Objetivos de la seguridad informtica ________________________________________ 10
4.5
Autorizacin _______________________________________________________ 60
BIBLIOGRAFIA _____________________________________________________ 80
Pgina 3
Lista de figuras:
Figura 1 Seguridad en el desarrollo _________________________________ 9
Figura 2 Definicin de riesgo _____________________________________ 14
Figura 3Estadisticas del nivel de riesgos.____________________________ 15
Figura 4 Grafica de evaluacin. ___________________________________ 15
FIGURA 5. Diseo De Software Seguro______________________________44
FIGURA 6. Diagrama de secuencias ________________________________45
FIGURA 7. Diagrama de clases ____________________________________46
FIGURA 8. Patrones de diseo de seguridad__________________________50
FIGURA 9. Seguridad en las operaciones del software __________________77
Pgina 4
UNIDAD 1
INTRODUCCIN A LA SEGURIDAD DE SOFTWARE
_______________________________________________________________
UNIDAD 1:
INTRODUCCIN A LA
SEGURIDAD DE
SOFTWARE.
CONTENIDO:
1.1 Introduccin a la Seguridad de Aplicaciones
1.2. Controles de Seguridad de la Informacin.
1.3. Problemas de Seguridad.
1.4. Principios de Seguridad.
1.5 Riesgos en el Ciclo de Desarrollo de Software.
Pgina 5
UNIDAD 1
INTRODUCCIN A LA SEGURIDAD DE SOFTWARE
_______________________________________________________________
INTRODUCCIN:
En primer lugar definiremos el concepto de seguridad como salvaguarda de las
propiedades bsicas de la informacin.
Entre las caractersticas que debe cumplir para ser seguro, encontramos la
integridad, es decir, que slo los usuarios autorizados pueden crear y modificar
los componentes del sistema, la confidencialidad, slo estos usuarios pueden
acceder a esos componentes, la disponibilidad, que todos los componentes
estn a disposicin de los usuarios siempre que lo deseen, y el no repudio, o
lo que es lo mismo, la aceptacin de un protocolo de comunicacin entre el
servidor y un cliente, por ejemplo, mediante certificados digitales.
Pgina 6
UNIDAD 1
INTRODUCCIN A LA SEGURIDAD DE SOFTWARE
_______________________________________________________________
OBJETIVO:
Al trmino del curso, el alumno ser capaz de:
Analizar diferentes escenario de seguridad y propondr alternativas para
la prevencin y resolucin de problemas de seguridad en sistemas y
algunas redes.
Identificar los diferentes conceptos de seguridad y tipos de ataques en
una red de computadoras.
Desarrollar y utilizar herramientas contra ataques en una red de
computadoras.
Pgina 7
UNIDAD 1
INTRODUCCIN A LA SEGURIDAD DE SOFTWARE
_______________________________________________________________
Hay que identificar los objetivos de seguridad de una aplicacin para saber si un
diseo o implementacin los satisfacen.
Pgina 8
UNIDAD 1
INTRODUCCIN A LA SEGURIDAD DE SOFTWARE
_______________________________________________________________
UNIDAD 1
INTRODUCCIN A LA SEGURIDAD DE SOFTWARE
_______________________________________________________________
1.1.2 Introduccin a la seguridad
Los riesgos, en trminos de seguridad, se caracterizan por lo general mediante
la siguiente ecuacin.
Para que un sistema sea seguro, deben identificarse las posibles amenazas y
por lo tanto, conocer y prever el curso de accin del enemigo. Por tanto, el
objetivo de este informe es brindar una perspectiva general de las posibles
motivaciones de los hackers, categorizarlas, y dar una idea de cmo funciona
para conocer la mejor forma de reducir el riesgo de intrusiones.
UNIDAD 1
INTRODUCCIN A LA SEGURIDAD DE SOFTWARE
_______________________________________________________________
UNIDAD 1
INTRODUCCIN A LA SEGURIDAD DE SOFTWARE
_______________________________________________________________
lugar la confidencialidad, integridad y disponibilidad de los datos, entre otros,
pues existe tambin la autenticidad. En Colombia son muchas las leyes que
regulan y dictan disposiciones generales para proteccin de los datos
personales, cuyo objetivo es garantizar y proteger los derechos fundamentales
de las personas, datos personales en lo concerniente a su privacidad, intimidad
e imagen.
Pgina 12
UNIDAD 1
INTRODUCCIN A LA SEGURIDAD DE SOFTWARE
_______________________________________________________________
1.2.1 Objeciones que enfrenta la seguridad informtica
La Seguridad Informtica en el contorno empresarial enfrenta algunas luchas
muy comunes relacionadas con su actividad y funcionamiento, como son:
algunas
organizaciones no
implementan
medidas
de
UNIDAD 1
INTRODUCCIN A LA SEGURIDAD DE SOFTWARE
_______________________________________________________________
(SGSI), es una norma que se adecua a cualquier tipo de organizacin sea grande
o pequea, o de cualquier sector, y debe enfocarse a la proteccin de la
informacin crtica. La gestin de la seguridad de la informacin debe realizarse
mediante un proceso sistemtico, documentado y conocido por toda la
organizacin.
Pgina 14
UNIDAD 1
INTRODUCCIN A LA SEGURIDAD DE SOFTWARE
_______________________________________________________________
1.3.1 Cul es el nivel de riesgo en la actualidad?
Las amenazas tambin aumentan:
Cada vez es necesaria menos especializacin y menos conocimiento tcnico
para llevar a cabo ataques, robar y/o modificar informacin o cometer fraudes.
No slo est disponible y al alcance de todos la informacin sobre los fallos y las
vulnerabilidades sino que tambin lo estn los exploits y las herramientas para
llevar a cabo todo tipo de acciones.
Pgina 15
UNIDAD 1
INTRODUCCIN A LA SEGURIDAD DE SOFTWARE
_______________________________________________________________
1.3.2 Tipos de ataques actuales
Ataques hbridos: Son ataques en los que se mezclan ms de una tcnica.
DOS,
DDOS,
Exploits,
Escaneos,
Troyanos,
Virus,
Buffer
Overflows,
Pgina 16
UNIDAD 2
UNIDAD 2:
ANLISIS DEL
SOFTWARE SEGURO.
OBJETIVO:
El alumno conocer e identificar los riesgos que se tienen al poner
en prctica la seguridad del software, as como los mecanismos
para la evaluacin del desarrollo de sistemas seguros.
CONTENIDO:
2.1 Herramientas de anlisis del software seguro.
2.2 Captura de los requerimientos de seguridad.
2.3 Anlisis de los requerimientos de seguridad.
Pgina 17
UNIDAD 2
INTRODUCCIN:
Actualmente, las nuevas tecnologas son un orquestador fundamental en la
Sociedad de la Informacin, lo cual incluye a las personas y los nuevos tipos de
relaciones que se establecen entre ellas. Esta dependencia est presente en
mltiples escenarios y contextos, desde actividades comerciales y sociales hasta
el mbito militar o la gestin de las infraestructuras crticas nacionales. Esto ha
provocado una necesidad creciente en que la tecnologa se comporte como se
espera, esto es, de acuerdo a sus especificaciones, y que implemente los
mecanismos de seguridad apropiados para prevenir que terceros puedan
perturbar nuestro modo de vida o daar nuestros intereses, privacidad y
seguridad. Por todo ello, el correcto funcionamiento de la tecnologa debe poder
verificarse no slo de manera objetiva sino tambin percibirse desde la
subjetividad del individuo. Es decir, la sociedad debe poder confiar en la
tecnologa.
Es cierto que algunos escenarios demandan unos requisitos de seguridad ms
rigurosos que otros. Sin embargo, la interdependencia entre sistemas de
informacin en un contexto global como el actual nos sugiere la necesidad de
una aproximacin global, haciendo de la confiabilidad en la tecnologa un
concepto de aplicacin universal y no particular a un campo especfico.
Una de las reas de investigacin que me resultan ms atractivas es la aplicacin
de mtodos formales para la construccin y verificacin de software seguro. De
todas las iniciativas existentes (muy numerosas y algunas realmente
interesantes), los mtodos formales son aquellos que son capaces de aportar
mayores garantas en cuanto a la robustez del software. Estos mtodos emplean
modelos y razonamiento matemtico para verificar las propiedades del software
y construir las evidencias necesarias sobre su correccin. Es importante resaltar
que, tal y como indic Boehm (Boehm, B., Verifying and validating software
requirements and design specifications. IEEE Software, Vol. 1(1), 1984), los
mtodos formales pueden ser tiles para verificar el software (hace lo que se ha
especificado que haga), pero no para validar el software (hace lo que se
esperaba que hiciera).
Pgina 18
UNIDAD 2
Pgina 19
UNIDAD 2
en
redes
con
IP.
Puede
realizar
anlisis
de
protocolos,
Pgina 20
UNIDAD 2
Hping2: Una utilidad de observacin {probe} para redes similar a ping pero con
esteroides. Hping2 ensambla y enva paquetes de ICMP/UDP/TCP hechos a
medida y muestra las respuestas. Fue inspirado por el comando ping, pero ofrece
mucho ms control sobre lo enviado. Tambin tiene un modo traceroute bastante
til y soporta fragmentacin de IP. Esta herramienta es particularmente til al
tratar de utilizar funciones como las de traceroute/ping o analizar de otra manera,
hosts detrs de un firewall que bloquea los intentos que utilizan las herramientas
estndar.
Pgina 21
UNIDAD 2
UNIDAD 2
SMTP, bsqueda en sitios web, y ms. Los que no son usuarios de Windows
pueden disfrutar de las versiones online de muchas de sus herramientas.
UNIDAD 2
en requerimientos funcionales y
Pgina 24
UNIDAD 2
Pgina 25
UNIDAD 2
Pgina 26
UNIDAD 2
completa
de
los
requerimientos
de
los
mismos.
UNIDAD 2
Pgina 28
UNIDAD 2
Las tareas asociadas con el anlisis y especificacin existen para dar una
representacin del programa que pueda ser revisada y aprobada por el cliente.
En un mundo ideal el cliente desarrolla una especificacin de requerimientos del
software completamente por s mismo. Esto se presenta raramente en el mundo
real. En el mejor de los casos, la especificacin se desarrolla conjuntamente
entre el cliente y el tcnico.
UNIDAD 2
Pgina 30
UNIDAD 2
ellas sern satisfechas por el software y cuales por algn otro producto del
sistema.
2.2.4.2 Especificacin de Requisitos de Software (SRS)
La especificacin de requisitos de software es la actividad en la cual se genera
el documento, con el mismo nombre, que contiene una descripcin completa de
las necesidades y funcionalidades del sistema que ser desarrollado; describe
el alcance del sistema y la forma en como har sus funciones, definiendo los
requerimientos funcionales y los no funcionales.
En la SRS se definen todos los requerimientos de hardware y software,
diagramas, modelos de sistemas y cualquier otra informacin que sirva de
soporte y gua para fases posteriores.
Es importante destacar que la especificacin de requisitos es el resultado final
de las actividades de anlisis y evaluacin de requerimientos; este documento
resultante ser utilizado como fuente bsica de comunicacin entre los clientes,
usuarios finales, analistas de sistema, personal de pruebas, y todo aquel
involucrado en la implementacin del sistema.
Los clientes y usuarios utilizan la SRS para comparar si lo que se est
proponiendo, coincide con las necesidades de la empresa. Los analistas y
programadores la utilizan para determinar el producto que debe desarrollarse. El
personal de pruebas elaborar las pruebas funcionales y de sistemas en base a
este documento. Para el administrador del proyecto sirve como referencia y
control de la evolucin del sistema.
Pgina 31
UNIDAD 2
Requerimientos "ergonmicos"
l ms conocido de los requerimientos ergonmicos es la interface con el usuario
o GUI (Graphic User Interface). En otras palabras, los requerimientos
ergonmicos son la forma en que el ser humano interacta con el ser sistema.
Requerimientos de Interface
La interface es como interacta el sistema con el ser humano o con otros
sistemas (el enfoque es prcticamente el opuesto a los requerimientos
ergonmicos), La interface es la especificacin formal de los datos que el sistema
Pgina 32
UNIDAD 2
UNIDAD 2
UNIDAD 2
los cuales son por definicin inalterables debido a que son parte del entorno,
limitan el mbito del diseo subsecuente y de la implementacin. De hecho, la
nica diferencia entre el sistema y su entorno es que el esfuerzo de diseo e
implementacin subsecuente opera exclusivamente sobre la especificacin del
sistema. La especificacin del entorno facilita que se especifique la interfaz del
sistema de la misma forma que el propio sistema, en vez de introducir otro
formalismo.
PRINCIPIO #5. Una especificacin de sistema debe ser un modelo cognitivo.
La especificacin de un sistema debe ser un modelo cognitivo, en vez de un
modelo de diseo o implementacin. Debe describir un sistema tal como es
percibido por su comunidad de usuario. Los objetivos que manipula deben
corresponderse con objetos reales de dicho dominio; los agentes deben modelar
los individuos, organizaciones y equipo de ese dominio; y las acciones que
ejecutan deben modelar lo que realmente ocurre en el dominio. Adems, debe
ser posible incorporar en la especificacin las reglas o leyes que gobiernan los
objetos del dominio. Algunas de estas leyes proscriben ciertos estados del
sistema (tal como "dos objetos no pueden estar en el mismo lugar al mismo
tiempo"), y por tanto limitan el comportamiento de los agentes o indican la
necesidad de una posterior elaboracin para prevenir que surjan estos estados.
PRINCIPIO #6. Una especificacin debe ser operacional. La especificacin debe
ser completa y lo bastante formal para que pueda usarse para determinar si una
implementacin propuesta satisface la especificacin de pruebas elegidas
arbitrariamente. Esto es, dado el resultado de una implementacin sobre algn
conjunto arbitrario de datos elegibles, debe ser posible usar la especificacin
para validar estos resultados. Esto implica que la especificacin, aunque no sea
una especificacin completa del cmo, pueda actuar como un generador de
posibles comportamientos, entre los que debe estar la implementacin
propuesta. Por tanto, en un sentido extenso, la especificacin debe ser
operacional.
Pgina 35
UNIDAD 2
sino
un
objeto
dinmico
que
sufre
considerables
Pgina 36
UNIDAD 2
contabilidad
capacidad
de
actualizacin.
Este
tipo
de
Pgina 37
UNIDAD 2
UNIDAD 2
Pgina 39
UNIDAD 2
de
interconectividad
busca
optimizar
el
componente
de
Pgina 40
UNIDAD 2
Pgina 41
UNIDAD 4
PROGRAMACION SEGURA
_______________________________________________________________
UNIDAD 3:
DISEO DE SOFTWARE
SEGURO
OBJETIVO:
El alumno conocer e identificar los riesgos que se tienen al poner en prctica
la seguridad del software, as como los mecanismos para la evaluacin del
desarrollo de sistemas seguros.
CONTENIDO:
3.1 Herramientas de Diseo de software seguro.
3.1.1 Diagramas de secuencias y clases.
3.1.2 Definicin Servicios Comunes.
3.1.3 Modelamiento de Amenazas por Casos de Uso
3.1.4 Patrones de Diseo Funcional
3.1.5 Patrones de Diseo de Seguridad (por Amenazas)
Pgina 42
UNIDAD 3
DISEO DE SOFTWARE SEGURO
_______________________________________________________________
INTRODUCCION:
Durante el proceso del ciclo de vida del software, normalmente se toman en
consideracin algunos parmetros, mtricas y pruebas para asegurar la calidad
del producto final, todas las pruebas y validaciones son enfocadas a garantizar
que el software cumpla con los requerimientos funcionales, es decir, que el
software haga lo que dice hacer.
Al considerar que la calidad es lo primordial durante ste proceso, se deja de
lado la seguridad de ste y en el mejor de los casos, proveer de seguridad al
software es relegado al final del proceso.
La seguridad debe de ir de la mano de la calidad a lo largo de todo el proceso
del ciclo de vida del software, lo cual implica que el software debe ser concebido
de calidad y seguro.
En todas las etapas del proceso debe estar inmersa la seguridad tanto en el
anlisis, diseo, desarrollo, pruebas y mantenimiento.
Pgina 43
UNIDAD 3
DISEO DE SOFTWARE SEGURO
_______________________________________________________________
Pgina 44
UNIDAD 3
DISEO DE SOFTWARE SEGURO
_______________________________________________________________
Pgina 45
UNIDAD 3
DISEO DE SOFTWARE SEGURO
_______________________________________________________________
Pgina 46
UNIDAD 3
DISEO DE SOFTWARE SEGURO
_______________________________________________________________
nimo de lucro, existen otras alternativas en desarrollo. Tanto en lo referente a
metodologas como a herramientas.
pentesters,
consultoresetc.)
participen
en
el
proceso
de
UNIDAD 3
DISEO DE SOFTWARE SEGURO
_______________________________________________________________
de ellas es que debe haber comprobado su efectividad resolviendo problemas
similares en ocasiones anteriores. Otra es que debe ser reutilizable, lo que
significa que es aplicable a diferentes problemas de diseo en distintas
circunstancias.
Los patrones de diseo pretenden:
Proporcionar catlogos de elementos reusables en el diseo de sistemas
software.
Evitar la reiteracin en la bsqueda de soluciones a problemas ya
Pgina 48
UNIDAD 3
DISEO DE SOFTWARE SEGURO
_______________________________________________________________
intervienen en el patrn.
Pgina 49
UNIDAD 3
DISEO DE SOFTWARE SEGURO
_______________________________________________________________
Participantes: Enumeracin y descripcin de las entidades abstractas (y
participantes.
Consecuencias: Consecuencias positivas y negativas en el diseo
patrn.
Usos conocidos: Ejemplos de sistemas reales que usan el patrn.
Patrones relacionados: Referencias cruzadas con otros patrones.
3.1.5.1 Motivacin
Para explicar la motivacin del uso de este patrn veamos un escenario donde
su aplicacin sera la solucin ms adecuada al problema planteado.
Consideremos un editor que puede incluir objetos grficos dentro de un
Pgina 50
UNIDAD 3
DISEO DE SOFTWARE SEGURO
_______________________________________________________________
documento. Se requiere que la apertura de un documento sea rpida, mientras
que la creacin de algunos objetos (imgenes de gran tamao) es cara. En este
caso no es necesario crear todos los objetos con imgenes nada ms abrir el
documento porque no todos los objetos son visibles. Interesa por tanto retrasar
el coste de crear e inicializar un objeto hasta que es realmente necesario (por
ejemplo, no abrir las imgenes de un documento hasta que no son visibles).
La solucin que se plantea para ello es la de cargar las imgenes bajo
demanda. Pero, cmo cargar las imgenes bajo demanda sin complicar el resto
del editor? La respuesta es utilizar un objeto proxy. Dicho objeto se comporta
como una imagen normal y es el responsable de cargar la imagen bajo demanda.
Aplicabilidad
El patrn proxy se usa cuando se necesita una referencia a un objeto ms flexible
o sofisticado que un puntero. Dependiendo de la funcin que se desea realizar
con dicha referencia podemos distinguir diferentes tipos de proxies:
proxy remoto: representante local de un objeto remoto.
proxy
Participantes
La clase Proxy: mantiene una referencia al objeto real (en el siguiente ejemplo
se le denomina _sujetoReal) y proporciona una interfaz idntica al sujeto (la
clase Sujeto). Adems controla el acceso a dicho objeto real y puede ser el
Pgina 51
UNIDAD 3
DISEO DE SOFTWARE SEGURO
_______________________________________________________________
responsable de su creacin y borrado. Tambin tiene otras responsabilidades
que dependen del tipo de proxy:
proxy virtual: puede hacer cach de informacin del objeto real para diferir
en lo posible el acceso a este.
La clase Sujeto: define una interfaz comn para el proxy (Proxy) y el objeto real
(de la clase SujetoReal), de tal modo que se puedan usar de manera indistinta.
La clase SujetoReal: clase del objeto real que el proxy representa.
Colaboraciones
Dependiendo de la clase de proxy, el objeto proxy redirige las peticiones al objeto
real que representa.
Ejemplos de funcionamiento:
Consecuencias
El uso de un proxy introduce un nivel de indireccin adicional con
diferentes usos:
UNIDAD 3
DISEO DE SOFTWARE SEGURO
_______________________________________________________________
Adems, su uso tambin permite realizar una optimizacin COW (copy-onwrite), puesto que copiar un objeto grande puede ser costoso, y si la copia no
se modifica, no es necesario incurrir en dicho gasto. Adems el sujeto mantiene
un nmero de referencias, y slo cuando se realiza una operacin que modifica
el objeto, ste se copia. Es til por tanto para retrasar la replicacin de un objeto
hasta que cambia.
Pgina 53
UNIDAD 4
PROGRAMACION SEGURA
_______________________________________________________________
UNIDAD 4:
PROGRAMACIN
SEGURA
Objetivo general:
Desarrollar aplicaciones Conocer y usar un lenguaje de alto nivel para el desarrollo
de aplicaciones seguras.
CONTENIDO:
4.1 Introduccin
4.2 Modelo de Seguridad
4.3 Introduccin a la Criptografa
4.4 Autentificacin
4.5 Autorizacin
4.6 Validacin de Input y Limpieza de Output
4.7 Registro de Datos (Logging)
4.8 Administracin de Sesiones y Estados en Aplicaciones
4.9 Seguridad de Acceso a Datos
4.10 Desarrollo de las Funcionalidades para Preservar la Seguridad.
4.11 Resiliencia y control de las aplicaciones.
Pgina 54
UNIDAD 4
PROGRAMACION SEGURA
_______________________________________________________________
4.1 Introduccin.
La programacin segura es una rama de la programacin que estudia la
seguridad del cdigo fuente de un software cuyo objetivo es encontrar y
solucionar los errores de software, esto incluye: Utilizacin de funciones seguras
para proteger de desbordamientos de pila, declaracin segura de estructuras de
datos, control del trabajo con el flujo de datos, anlisis profundo de otros errores
de software mediante testeos del software en ejecucin y creacin de parches
para los mismos, diseo de parches heursticos y meta-heursticos para proveer
un cierto grado de seguridad proactiva, utilizacin de criptografa y otros mtodos
para evitar que el software sea crackeado.
Pgina 55
UNIDAD 4
PROGRAMACION SEGURA
_______________________________________________________________
3. Expresar la poltica exigida por un sistema de cmputo especfico.
4.4 Autentificacin.
Llamamos autentificacin a la comprobacin de la identidad de una persona o
de un objeto. Hemos visto hasta ahora diversos sistemas que pueden servir para
la autentificacin de servidores, de mensajes y de remitentes y destinatarios de
mensajes. Pero hemos dejado pendiente un problema: las claves privadas
suelen estar alojadas en mquinas clientes y cualquiera que tenga acceso a
estas mquinas puede utilizar las claves que tenga instaladas y suplantar la
identidad de su legtimo usuario.
Pgina 56
UNIDAD 4
PROGRAMACION SEGURA
_______________________________________________________________
Por tanto es necesario que los usuarios adopten medidas de seguridad y utilicen
los medios de autentificacin de usuario de los que disponen sus ordenadores
personales. Hay tres sistemas de identificacin de usuario, mediante contrasea,
mediante dispositivo y mediante dispositivo biomtrico.
Los dispositivos biomtricos son un caso especial del anterior, en los que la
llave es una parte del cuerpo del usuario, huella dactilar, voz, pupila o iris.
Existen ya en el mercado a precios relativamente econmicos ratones que llevan
incorporado un lector de huellas dactilares.
Autenticacin, autentificacin (no recomendado) o mejor dicho acreditacin, en
trminos de seguridad de redes de datos, se puede considerar uno de los tres
pasos fundamentales (AAA). Cada uno de ellos es, de forma ordenada:
1. Autenticacin. En la seguridad de ordenador, la autenticacin es el
proceso de intento de verificar la identidad digital del remitente de una
comunicacin como una peticin para conectarse. El remitente siendo
autenticado puede ser una persona que usa un ordenador, un ordenador
por s mismo o un programa del ordenador. En un web de confianza,
"autenticacin" es un modo de asegurar que los usuarios son quien ellos
dicen que ellos son - que el usuario que intenta realizar funciones en un
sistema es de hecho el usuario que tiene la autorizacin para hacer as.
2. Autorizacin. Proceso por el cual la red de datos autoriza al usuario
identificado a acceder a determinados recursos de la misma.
3. Auditora. Mediante la cual la red o sistemas asociados registran todos y
cada uno de los accesos a los recursos que realiza el usuario autorizados
o no.
Pgina 57
UNIDAD 4
PROGRAMACION SEGURA
_______________________________________________________________
Pgina 58
UNIDAD 4
PROGRAMACION SEGURA
_______________________________________________________________
Sistema puedan ser referidas luego a esa identidad y aplicar los mecanismos de
autorizacin y/o auditora oportunos.
UNIDAD 4
PROGRAMACION SEGURA
_______________________________________________________________
o probar una identidad, cualquiera. Hay ediciones difciles que estn al acecho
debajo de qu aparece ser una superficie directa.
4.5 Autorizacin
En ingeniera de seguridad y seguridad informtica, la autorizacin es una parte
del sistema operativo que protege los recursos del sistema permitiendo que slo
sean usados por aquellos consumidores a los que se les ha concedido
autorizacin para ello. Los recursos incluyen archivos y otros objetos de dato,
programas, dispositivos y funcionalidades provistas por aplicaciones. Ejemplos
de consumidores son usuarios del sistema, programas y otros dispositivos.
Pgina 60
UNIDAD 4
PROGRAMACION SEGURA
_______________________________________________________________
ste hace uso del proceso de autenticacin para identificar a los consumidores.
Cuando un consumidor intenta usar un recurso, el proceso de autorizacin
comprueba que al consumidor le ha sido concedido permiso para usar ese
recurso. Los permisos son generalmente definidos por el administrador de
sistemas en algn tipo de aplicacin de polticas de seguridad, tales como una
ACL o una capacidad, sobre la base del principio de privilegio mnimo: a los
consumidores slo se les deben conceder los permisos que necesitan para
realizar su trabajo. Los sistemas operativos monousuarios ms antiguos solan
tener sistemas de autenticacin y autorizacin dbiles o carecan por completo
de ellos. Se llama consumidores annimos o invitados a aquellos
consumidores a los que no se les ha exigido que se autentiquen. A menudo
tienen muy pocos permisos. En un sistema distribuido, suele ser deseable
conceder acceso sin exigir una identidad nica. Ejemplos familiares de tokens
de autorizacin incluyen llaves y tiques, que permiten conceder acceso sin que
se provea una identidad.
UNIDAD 4
PROGRAMACION SEGURA
_______________________________________________________________
Pgina 62
UNIDAD 4
PROGRAMACION SEGURA
_______________________________________________________________
Duracin limitada de los datos Como los datos globales almacenados en
el estado de aplicacin son voltiles, se perdern si se destruye el proceso
de servidor web que los contiene, por ejemplo si el servidor se queda
bloqueado, se actualiza o se apaga.
Requisitos de recursos El estado de aplicacin necesita memoria del
servidor, lo que puede afectar al rendimiento del mismo as como a la
escalabilidad de la aplicacin.
Informacin general sobre el rendimiento de ASP.NET.
Pgina 63
UNIDAD 4
PROGRAMACION SEGURA
_______________________________________________________________
Extensibilidad Puede personalizar y ampliar el estado de sesin
escribiendo su propio proveedor de estados de sesin. Implementar un
proveedor de almacn de estados de sesin.
Consideraciones sobre el rendimiento Las variables de estado de sesin
permanecen en la memoria hasta que se quitan o se reemplazan y
pueden, por tanto, perjudicar al rendimiento del servidor.
Pgina 64
UNIDAD 4
PROGRAMACION SEGURA
_______________________________________________________________
4.8.4 Compatibilidad con bases de datos
Seguridad El usuario escribe un nombre de cuenta y una contrasea en
una pgina de inicio de sesin del sitio.
Personalizacin Si dispone de informacin de seguridad, el sitio puede
distinguir a cada usuario leyendo la cookie en el equipo cliente.
Personalizacin.
Consistencia Si ha creado un sitio Web de comercio electrnico, es
posible que desee mantener los registros transaccionales de las compras
de productos y servicios realizados en el sitio.
Extraccin de datos La informacin sobre el uso del sitio, los visitantes o
las transacciones de un producto se pueden almacenar de forma segura
en la base de datos.
Seguridad El acceso a las bases de datos requiere una autenticacin y
autorizacin rigurosas.
Capacidad de almacenamiento Se puede almacenar en la base de datos
tanta informacin como se desee.
Persistencia de los datos La informacin de la base de datos se puede
almacenar durante el tiempo deseado, y no est sujeta a la disponibilidad
del servidor web.
Solidez e integridad de los datos Las bases de datos suelen incluir
diversas funciones para el mantenimiento de la correccin de los datos,
entre ellas desencadenadores e integridad referencial, transacciones, etc.
Accesibilidad Un gran nmero de herramientas de procesamiento de la
informacin pueden tener acceso a los datos almacenados en la base de
datos.
Compatibilidad generalizada Existe una gran variedad de herramientas
de bases de datos y configuraciones disponibles.
Complejidad Si se utiliza una base de datos para la administracin de
estado, las configuraciones del hardware y el software sern ms
complejas.
Pgina 65
UNIDAD 4
PROGRAMACION SEGURA
_______________________________________________________________
Consideraciones sobre el rendimiento Una construccin deficiente del
modelo de datos relacionales puede generar problemas de escalabilidad.
Pgina 66
UNIDAD 4
PROGRAMACION SEGURA
_______________________________________________________________
impedir consultas SQL desde las aplicaciones o capa de usuarios. Para ello se
pueden considerar (como administrador):
Limitar el acceso a los procedimientos a ciertos usuarios.
Delimitar el acceso a los datos para ciertos usuarios, procedimientos y/o
datos.
Declinar la coincidencia de horarios entre usuarios que coincidan.
4.9.4 Endurecimiento
Como resultado de una evaluacin de la vulnerabilidad a menudo se dan una
serie de recomendaciones especficas. Este es el primer paso en el
endurecimiento de la base de datos. Otros elementos de endurecimiento
implican la eliminacin de todas las funciones y opciones que se no utilicen.
Aplique una poltica estricta sobre que se puede y que no se puede hacer, pero
asegrese de desactivar lo que no necesita.
4.9.5 Audite
Una vez que haya creado una configuracin y controles de endurecimiento,
realice auto evaluaciones y seguimiento a las recomendaciones de auditora
para asegurar que no se desve de su objetivo (la seguridad).
Automatice el control de la configuracin de tal forma que se registre cualquier
cambio en la misma. Implemente alertas sobre cambios en la configuracin.
Cada vez que un cambio se realice, este podra afectar a la seguridad de la base
de datos.
4.9.6 Monitoreo
Monitoreo en tiempo real de la actividad de base de datos es clave para limitar
su exposicin, aplique o adquiera agentes inteligentes de monitoreo, deteccin
de intrusiones y uso indebido.
Por ejemplo, alertas sobre patrones inusuales de acceso, que podran indicar la
presencia de un ataque de inyeccin SQL, cambios no autorizados a los datos,
cambios en privilegios de las cuentas, y los cambios de configuracin que se
ejecutan a mediante de comandos de SQL.
Pgina 67
UNIDAD 4
PROGRAMACION SEGURA
_______________________________________________________________
Recuerde que el monitoreo usuarios privilegiados, es requisito para la
gobernabilidad de datos y cumplimiento de regulaciones como SOX y
regulaciones de privacidad. Tambin, ayuda a detectar intrusiones, ya que
muchos de los ataques ms comunes se hacen con privilegios de usuario de alto
nivel.
El monitoreo dinmico es tambin un elemento esencial de la evaluacin de
vulnerabilidad, le permite ir ms all de evaluaciones estticas o forenses. Un
ejemplo clsico lo vemos cuando mltiples usuarios comparten credenciales con
privilegios o un nmero excesivo de inicios de sesin de base de datos.
Pgina 68
UNIDAD 4
PROGRAMACION SEGURA
_______________________________________________________________
4.9.8 Autenticacin, control de acceso, y Gestin de derechos
No todos los datos y no todos los usuarios son creados iguales. Usted debe
autenticar a los usuarios, garantizar la rendicin de cuentas por usuario, y
administrar los privilegios para de limitar el acceso a los datos.
Implemente y revise peridicamente los informes sobre de derechos de usuarios,
como parte de un proceso de formal de auditora.
Utilice el cifrado para hacer ilegibles los datos confidenciales, complique el
trabajo a los atacantes, esto incluye el cifrado de los datos en trnsito, de modo
que un atacante no puede escuchar en la capa de red y tener acceso a los datos
cuando se enva al cliente de base de datos.
UNIDAD 4
PROGRAMACION SEGURA
_______________________________________________________________
controlar el acceso no autorizado, pues existen componentes que
son los nicos que pueden acceder a elementos de la aplicacin.
Datos no validos a la entrada, la aplicacin como tal realiza las verificacin con
el fin de controlar la informacin que entra con elfin de evitar que campos
invlidos puedan afectar el comportamiento interno del sistema como sus
respectivas salidas. La idea es que cualquier tipo de datos entrando al software
ser verificado con el fin de que no contenga algn tipo de ataque. Los sistemas
por su arquitectura y tecnologas de desarrollo facilitar los procesos de mejoras
en lo referente al tema de seguridad, dado que las caractersticas de los riesgos
presentes en los sistemas de informacin obedecen a un patrn muy dinmico
en el tiempo, obligando a los desarrolladores, administradores de la red y
oficiales de seguridad estar en un ciclo continuado de aprendizaje de nuevas
tecnologas para defenderse con las amenazas tanto externas como internas y
tambin un entendimiento detallado y profundo de las caractersticas
fundamentales de estas amenazas para estar mejor preparados para
enfrentarlas, as como una gestin adecuado de incidentes de seguridad que
puedan ocurrir sobre el sistema; documentarlos adecuadamente y en la medida
de lo posible aprender de ellos y realizar idneamente las medidas correctivas
necesarias y requeridas.
Por ltimo se debe controlar adecuadamente los datos de entrada a las
aplicaciones, considerando los casos de uso con el fin de detectar los siguientes
errores:
-Valores fuera de rango
-Caracteres invlidos en los campos de datos
-Datos incompletos o faltantes
-Datos Inconsistentes de Control
-Se debe hacer una revisin peridica de campos importantes de los
datos, con el fin de confirmar su validez e integridad
-Se deben inspeccionar los documentos de entrada para detectar algn
cambio no autorizado. (Todos los cambios a los documentos de entrada
deben poseer su respectiva autorizacin del propietario de la informacin)
-Se deben tener procedimientos para responder a errores de validacin.
Pgina 70
UNIDAD 4
PROGRAMACION SEGURA
_______________________________________________________________
-Se deben tener procedimientos para detectar la veracidad de los datos.
-Se deben definir las responsabilidades de todo el personal involucrado
en procesos de entrada de datos.
Pgina 71
UNIDAD 5
PRUEBAS DE SEGURIDAD DE SOFTWARE
_______________________________________________________________
UNIDAD 5:
PRUEBAS DE
SEGURIDAD DE
SOFTWARE
Objetivo general:
Planear y elaborar las estrategias prueba de software seguro
CONTENIDO:
5.1 Pruebas Funcionales.
5.1.1 Pruebas de las Funcionalidades de Seguridad de los Sistemas
5.2 Aceptacin del Software.
5.2.1 Implicaciones de Seguridad en la Fase de Aceptacin del Software
5.3 Seguridad en las Operaciones de Software
5.3.1 Mantenimiento y Operacin del Software
Pgina 72
UNIDAD 5
PRUEBAS DE SEGURIDAD DE SOFTWARE
_______________________________________________________________
Entre el tipo de pruebas que se realiza en un sistema est el tipo que evala la
funcionalidad de ste.
Prueba Funcional.
Objetivo:
Enfoque:
Pgina 73
UNIDAD 5
PRUEBAS DE SEGURIDAD DE SOFTWARE
_______________________________________________________________
Prueba de Seguridad.
Tcnica: Caja Negra.
Objetivo:
Nivel de Seguridad del Sistema: Verificar que solo los actores con acceso
al sistema y a la aplicacin estn habilitados para accederla.
reas:
Garantiza:
Tcnicas:
Identificar cada tipo de usuario y las funciones y datos a los que se debe
autorizar.
Pgina 74
UNIDAD 5
PRUEBAS DE SEGURIDAD DE SOFTWARE
_______________________________________________________________
Prueba de Volumen.
Objetivo:
Verificar que la aplicacin funciona adecuadamente bajo los siguientes
escenarios de volumen:
Tcnica.
mltiples
clientes
para
correr
consultas
Pgina 75
UNIDAD 5
PRUEBAS DE SEGURIDAD DE SOFTWARE
_______________________________________________________________
5.2.1 Implicaciones de Seguridad en la Fase de Aceptacin del software
Para eliminar la influencia de conflictos de intereses, y para que sea lo ms
objetiva posible, la prueba de aceptacin nunca debera ser responsabilidad de
los
ingenieros
de
software
que
han
desarrollado
el
producto.
Pgina 76
UNIDAD 5
PRUEBAS DE SEGURIDAD DE SOFTWARE
_______________________________________________________________
Pgina 77
UNIDAD 5
PRUEBAS DE SEGURIDAD DE SOFTWARE
_______________________________________________________________
Pgina 78
UNIDAD 5
PRUEBAS DE SEGURIDAD DE SOFTWARE
_______________________________________________________________
Facilidad de prueba: Capacidad del producto software de permitir evaluar las
partes modificadas.
Conformidad: Capacidad del producto software de satisfacer los estndares o
convenciones relativas a la mantenibilidad.
Pgina 79
UNIDAD 5
PRUEBAS DE SEGURIDAD DE SOFTWARE
_______________________________________________________________
BIBLIOGRAFIA
Bibliografa
(s.f.). Obtenido de
http://www.addima.org/Documentos/Articulos/Articulo%20Cristina%20Vill
alba
(s.f.). Obtenido de
http://www.sisteseg.com/files/Microsoft_Word__RECOMENDACIONES_
PARA_SOFTWARE_E_INFRAESTRUCTURA_SEGURA.pdf
(s.f.). Obtenido de http://www.pmoinformatica.com/2012/11/5-herramientaspara-la(s.f.). Obtenido de http://es.wikipedia.org/wiki/Entrada/salida
(s.f.). Obtenido de http://msdn.microsoft.com/es-es/magazine/cc507646.aspx
(s.f.). Obtenido de http://es.tldp.org/Informes/informe-seguridad-SL/informeseguridad-SL.pdf
(s.f.). Obtenido de
http://www.calidadysoftware.com/testing/pruebas_funcionales.php
AUTENTICI. (s.f.). Obtenido de
http://es.wikipedia.org/wiki/Autenticaci%C3%B3n
PEREZ, J. (s.f.). FSFFSFS. Obtenido de http://www.linuxmagazine.es/issue/62/008-009_InseguridadesLM62.pdf
SECURITY MODEL. (s.f.). Obtenido de
http://www.bi.dev42.es/wpcontent/uploads/2011/05/obiee11g_security_m
odel.jpg
UNAM.MX. (s.f.). Obtenido de
http://www.revista.unam.mx/vol.7/num7/art55/jul_art55.pdf
Pgina 80