Monografia Desarrllo de Software Seguro

SEP
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
CD. Y PUERTO DE LZARO CRDENAS, MICHOACN.
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
1.2. Controles de Seguridad de la Informacin. ____________________________ 11

1.2.1 Objeciones que enfrenta la seguridad informtica______________________________ 13
1.3. Problemas de Seguridad._____________________________________________ 14

1.3.1 Cul es el nivel de riesgo en la actualidad? __________________________________ 15
1.3.2 Tipos de ataques actuales __________________________________________________ 16
1.4. Principios de Seguridad. _____________________________________________ 16
ANLISIS DEL SOFTWARE SEGURO. ________________________________ 17

2.1 HERRAMIENTAS DE ANLISIS DEL SOFTWARE SEGURO.______________ 19
2.1.1 Mtodos, tcnicas y herramientas para la ingeniera de requerimientos de la
seguridad del software. _________________________________________________________ 19
2.1.2 Herramientas de anlisis de software. ________________________________________ 20
2.2.1 Caractersticas de los requerimientos ________________________________________ 24
2.2.2 Ingeniera de Requerimientos vs. Administracin de Requerimientos. ____________ 26
2.2.3 Fundamentos del Anlisis de Requerimientos _________________________________ 27
2.2.4 Tareas del Anlisis ________________________________________________________ 28
2.3 ANLISIS DE LOS REQUERIMIENTOS DE SEGURIDAD. _________________ 39

2.3.1 Aseguramiento de componentes de datos. ___________________________________ 39
2.3.2 Aseguramiento de componente humano. _____________________________________ 40
2.3.3 Administracin de la seguridad informtica. ___________________________________ 41
DISEO DE SOFTWARE SEGURO ___________________________________ 42

3.1 HERRAMIENTAS DE DISEO DE SOFTWARE SEGURO. ________________ 44
3.1.1 Diagramas de secuencias y clases. __________________________________________ 44
3.1.2 Definicin Servicios Comunes. ______________________________________________ 46
3.1.3 Modelamiento de Amenazas por Casos de Uso. _______________________________ 46
3.1.4 Patrones de Diseo Funcional. ______________________________________________ 47
3.1.5 Patrones de Diseo de Seguridad (por Amenazas) ____________________________ 50
PROGRAMACIN SEGURA _________________________________________ 54

4.1 Introduccin. ________________________________________________________ 55
4.2 Modelo de seguridad._________________________________________________ 55
4.3 Introduccin a la criptografa__________________________________________ 56
4.4 Autentificacin. ______________________________________________________ 56
4.4.1 Mtodos de autenticacin __________________________________________________ 58
4.4.2 Caractersticas de autenticacin_____________________________________________ 58
4.4.3 Mecanismo general de autenticacin ________________________________________ 58
4.4.4 Control de acceso _________________________________________________________ 59
4.5
Autorizacin _______________________________________________________ 60
4.6 Validacin de Input y Limpieza de Output ______________________________ 62

Pgina 2
4.7 Registro de Datos (Logging) __________________________________________ 62

4.8 Administracin de Sesiones y Estados en Aplicaciones _________________ 62
4.8.1 Estado de aplicacin ______________________________________________________ 62
4.8.2 Estado de sesin__________________________________________________________ 63
4.8.3 Propiedades de perfiles ____________________________________________________ 64
4.8.4 Compatibilidad con bases de datos __________________________________________ 65
4.9 Seguridad de Acceso a Datos _________________________________________ 66

4.9.1 Principios bsicos de seguridad de bases de datos ____________________________ 66
4.9.2 Identifique su sensibilidad __________________________________________________ 66
4.9.3 Evaluacin de la vulnerabilidad y la configuracin _____________________________ 66
4.9.4 Endurecimiento ___________________________________________________________ 67
4.9.5 Audite ___________________________________________________________________ 67
4.9.6 Monitoreo ________________________________________________________________ 67
4.9.7 Pistas de Auditora ________________________________________________________ 68
4.9.8 Autenticacin, control de acceso, y Gestin de derechos _______________________ 69
4.10 Desarrollo de las Funcionalidades para Preservar la Seguridad. ________ 69

4.11 Resiliencia y control de las aplicaciones. _____________________________ 71
PRUEBAS DE SEGURIDAD DE SOFTWARE __________________________ 72

5.1 Pruebas Funcionales _________________________________________________ 73
5.1.1 Pruebas de las Funcionalidades de Seguridad de los Sistemas __________________ 73
5.2 Aceptacin del Software ______________________________________________ 75

5.2.1 Implicaciones de Seguridad en la Fase de Aceptacin del software ______________ 76
5.3 Seguridad en las Operaciones de Software _____________________________ 76

5.3.1 Mantenimiento y Operacin del Software _____________________________________ 77
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:
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.
Entre las diferencias de seguridad entre un Software Libre y el Software

Propietario, podemos destacar:
-Seguridad en el Software Propietario: En el caso de tener agujeros de
seguridad, puede que no nos demos cuenta y que no podamos repralos. Existe
una dependencia del fabricante, retrasndose as cualquier reparacin, y la falsa
creencia de que es ms seguro por ser obscuro (la seguridad por obscuridad
determina los fallos de seguridad no parcheados en cada producto).
-Seguridad en el Software Libre: Por su carcter pblico y su crecimiento

progresivo, se van aadiendo funciones, y se nos permite detectar ms
fcilmente los agujeros de seguridad para poder corregirlos. Los problemas
tardan mucho menos en ser resueltos por el apoyo que tiene de los hackers y
una gran comunidad de desarrolladores, y al ser un software de cdigo libre,
cualquier empresa puede aportar soporte tcnico.
Pgina 6
UNIDAD 1
_______________________________________________________________
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.
Al trmino del curso de seguridad podrs desarrollar habilidades con el fin de

proponer soluciones o alternativas de proteccin competitivas, utilizando para
ello el autoaprendizaje y la retroalimentacin de conocimientos, y asumiendo
actitudes de honestidad, responsabilidad, confidencialidad y empata
Pgina 7
UNIDAD 1
_______________________________________________________________
1.1 Introduccin a la Seguridad de Aplicaciones.

En general se suele decir que los tres objetivos fundamentales de la seguridad
informtica son:
Confidencialidad; el acceso a los activos del sistema est limitado a
usuarios autorizados.
Integridad; los activos del sistema slo pueden ser borrados o modificados
por usuarios autorizados.
Disponibilidad; el acceso a los activos en un tiempo razonable est
garantizado para usuarios autorizados.
Hay que identificar los objetivos de seguridad de una aplicacin para saber si un
diseo o implementacin los satisfacen.
COMMON CRITERIA o CC (ISO/IEC 15408:1999): estndar internacional para

identificar y definir requisitos de seguridad. Se suele emplear para redactar dos
tipos de documentos:
Perfil de proteccin (PROTECTION PROFILE o PP): es un documento
que define las propiedades de seguridad que se desea que tenga un
producto; bsicamente se trata de un listado de requisitos de seguridad.
Objetivo de seguridad (Security Target o ST): es un documento que
describe lo que hace un producto que es relevante desde el punto de vista
de la seguridad.
La seguridad de las aplicaciones se suele contemplar en las ltimas fases del

ciclo de vida de la aplicacin (Despliegue). Esto un error, ya que los costos se
reducen drsticamente si la seguridad es incluida desde el inicio. Los tiempos de
desarrollo se acortan y se evitan muchos problemas. Proteger la aplicacin es
un elemento clave en la seguridad de los sistemas de informacin de cualquier
Organizacin.
Pero entonces, dnde deberamos incluir seguridad? La respuesta es sencilla:
En todas las fases.
Pgina 8
UNIDAD 1
_______________________________________________________________
Figura 1 Seguridad en el desarrollo
La seguridad en las aplicaciones va ms all de controlar el acceso utilizando

un usuario y password, o de colocar el servidor web en una dmz.
1.1.1 Introduccin a la seguridad informtica

Debido a que el uso de Internet se encuentra en aumento, cada vez ms
compaas permiten a sus socios y proveedores acceder a sus sistemas de
informacin. Por lo tanto, es fundamental saber qu recursos de la compaa
necesitan proteccin para as controlar el acceso al sistema y los derechos de
los usuarios del sistema de informacin. Los mismos procedimientos se aplican
cuando se permite el acceso a la compaa a travs de Internet.
Adems, debido a la tendencia creciente hacia un estilo de vida nmada de hoy
en da, el cual permite a los empleados conectarse a los sistemas de informacin
casi desde cualquier lugar, se pide a los empleados que lleven consigo parte del
sistema de informacin fuera de la infraestructura segura de la compaa.
Pgina 9
UNIDAD 1
_______________________________________________________________
1.1.2 Introduccin a la seguridad
Los riesgos, en trminos de seguridad, se caracterizan por lo general mediante
la siguiente ecuacin.
Riesgo = (amenaza * vulnerabilidad) / contramedida

La amenaza representa el tipo de accin que tiende a ser daina, mientras que
la vulnerabilidad (conocida a veces como falencias (flaws) o brechas (breaches)
representa el grado de exposicin a las amenazas en un contexto particular.
Finalmente, la contramedida representa todas las acciones que se implementan
para prevenir la amenaza.
Las contramedidas que deben implementarse no slo son soluciones tcnicas,

sino tambin reflejan la capacitacin y la toma de conciencia por parte del
usuario, adems de reglas claramente definidas.
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.
1.1.3 Objetivos de la seguridad informtica

Generalmente, los sistemas de informacin incluyen todos los datos de una
compaa y tambin en el material y los recursos de software que permiten a una
compaa almacenar y hacer circular estos datos. Los sistemas de informacin
son fundamentales para las compaas y deben ser protegidos.
Generalmente, la seguridad informtica consiste en garantizar que el material y

los recursos de software de una organizacin se usen nicamente para los
propsitos para los que fueron creados y dentro del marco previsto.
Pgina 10
UNIDAD 1
_______________________________________________________________
La seguridad informtica se resume, por lo general, en cinco objetivos

principales:
Integridad: garantizar que los datos sean los que se supone que son
Confidencialidad: asegurar que slo los individuos autorizados tengan
acceso a los recursos que se intercambian
Disponibilidad: garantizar el correcto funcionamiento de los sistemas de
informacin
Evitar el rechazo: garantizar de que no pueda negar una operacin
realizada.
Autenticacin: asegurar que slo los individuos autorizados tengan
acceso a los recursos.
1.2. Controles de Seguridad de la Informacin.

La seguridad de informacin es fundamental para las organizaciones porque les
ayuda a prevenir la divulgacin de informacin confidencial as como proteger
los datos en diversos entornos. El costo de la violacin a la seguridad de la
informacin en trminos monetarios y credibilidad empresarial es alto. Resulta
de vital importancia tener en cuenta que mientras la informacin gire en un
entorno informtico y de tecnologa, siempre habr que protegerla por los riesgos
a que puede estar expuesta, por eso todas las organizaciones deberan estar
pensando siempre en asegurar su informacin.
Hay que destacar que existe diferencia entre la Seguridad de la Informacin y la

Proteccin de Datos cuando su motivo u obligacin corresponde a actividades
de seguridad, no obstante, las medidas de proteccin a aplicar normalmente
sern las mismas. Para comprender un poco estas diferencias entre los dos
conceptos anunciados, recordemos que para la Seguridad de la Informacin su
objetivo es la proteccin de los datos mismos y as tratar de evitar su perdida y
modificacin no autorizada, mientras que la proteccin debe garantizar en primer
Pgina 11
UNIDAD 1
_______________________________________________________________
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.
A veces se tiene el concepto de que las amenazas de seguridad slo alcanzan

a las empresas reconocidas en el mbito internacional y consideran que es muy
distante de suceder en empresas medianas o pequeas. Sin embargo, el ataque
de hackers a travs de redes que roban informacin a las empresas es un hecho
poco frecuente, si se compara con las verdaderas amenazas que regularmente
se materializan en la mayora de los ambientes empresariales, como son:
accesos no autorizados a la informacin, prdida de datos por negligencia o por
virus, entre otros, catalogados como amenazas reales de la seguridad de la
informacin. Generalmente cuando se aborda la problemtica de la seguridad,
la organizacin lo que primero relaciona son aspectos como: disponibilidad de
los datos, copias de seguridad, mantenimiento de los equipos y servidores,
mantenimiento de las redes de telecomunicaciones, etc., todos ellos enfocados
a la disponibilidad de los datos, olvidando otras caractersticas importantes que
se deben cuidar como son la integridad y la confidencialidad. Dado lo anterior,
no debemos ver las amenazas como simples elementos conceptuales, sino
como reales evidencias prcticas que nos permitan darle una mayor importancia
a la informacin, asimismo verla como un activo esencial para la organizacin.
Lo anterior debe motivar a las organizaciones a implementar medidas de

proteccin que respondan a la Seguridad de la Informacin, para garantizar
proteccin tanto de los aspectos fsicos, lgicos como tambin el factor humano;
y que permitan contrarrestar las amenazas a fin de evitar que stas traigan
consecuencias negativas para una organizacin, as como el resultado de
prdidas econmicas.
Pgina 12
UNIDAD 1
_______________________________________________________________
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:
La seguridad de la informacin la ven como un tema normal, lo que hace que no

reciba la atencin adecuada que debe merecer; por consiguiente nadie vive o
trabaja para su seguridad, sino que la implementa para cumplir sus objetivos.
Manejo inadecuado del tiempo y dinero; implementar medidas de proteccin
implica invertir en estos recursos valiosos.
Falta de seguimiento a los procesos de implementacin de seguridad, lo cual
genera que se haga una vez y despus quede en el olvido, un proceso de
implementacin de seguridad de la informacin requiere un control permanente
de seguimientos peridicos para estar verificando el cumplimiento de las
medidas de proteccin implementadas, asimismo el estar revisando los cambios
que surgen en su entorno.
Lastimosamente
algunas
organizaciones no
implementan
medidas
de
proteccin, hasta que no sucede un siniestro o desastre, lo cual puede ser

demasiado tarde en algunas ocasiones. Por eso las medidas deben ser
preventivas, y se hace necesario trabajar en la Gestin de riesgo, es decir en:
Identificar el riesgo, Clasificarlo y establecer las soluciones para minimizar los
impactos que estos puedan ocasionar. Para una buena Gestin de riesgos no se
debe tomar como una tarea nica sino que debe ser un proceso continuo,
dinmico y permanente que tiene que estar integrado a los procesos operativos
de una organizacin; proceso en el que se debe involucrar a los directivos y
empleados, quienes deben apoyar las medidas que se tomen.
Para la implementacin y desarrollo de la seguridad de la informacin, se utilizan

estndares que contienen buenas prcticas como la norma ISO 27001. Esta
norma tiene como objetivo garantizar la seleccin de controles de seguridad y
permitir a las organizaciones, gestionar y proteger sus valiosos activos de
informacin. ISO/IEC 27001 es la nica norma internacional auditable que define
los requisitos para un sistema de gestin de la seguridad de la informacin
Pgina 13
UNIDAD 1
_______________________________________________________________
(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.
Es recomendable que para la implementacin de un sistema de gestin de la

seguridad de la informacin, se apoyen en el acompaamiento de un especialista
en el tema y que cuente con las debidas certificaciones.
1.3. Problemas de Seguridad.
Figura 2 Definicin de riesgo
Conforme la tecnologa avanza, el nivel de los problemas de seguridad

informticos tambin lo hace, esto es porque se desarrollan nuevos mtodos de
ataque, se usan las nuevas tecnologas para daar los bienes informticos y en
cuanto se pretende lanzar una nueva tecnologa, los perpetradores ya estn
trabajando para encontrar vulnerabilidades en las mismas.
Existen diferentes vulnerabilidades a las que las organizaciones y personas se

enfrentan. stas normalmente se presentan debido a que no se le da la
importancia requerida a ciertos aspectos de seguridad o porque simplemente
minimizan la posibilidad de que pueda ser causa de un ataque informtico.
Pgina 14
UNIDAD 1
_______________________________________________________________
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.
Figura 3Estadisticas del nivel de riesgos.
Figura 4 Grafica de evaluacin.
Pgina 15
UNIDAD 1
_______________________________________________________________
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,
Inyecciones, etc. Suelen ser de muy rpida propagacin y siempre se basan en

alguna vulnerabilidad de algn sistema.
Por ejemplo los gusanos Blaster, Sasser, o Slammer se propagaron por todo el
planeta en cuestin de pocas horas gracias a una mezcla de tcnicas de uso de
vulnerabilidad, Buffer Overflows, escaneado de direcciones, transmisin va
Internet, y mimetizacin en los sistemas.
Ingeniera social: Son ataques en los que se intenta engaar a algn usuario
para hacerle creer como cierto algo que no lo es.
- Buenos das, es la secretaria del Director del Departamento?
- Si dgame, que desea?
- Soy Pedro, tcnico informtico del Centro de Apoyo a Usuarios y me han
avisado para reparar un virus del ordenador del director pero la clave que me
han indicado para entrar no es correcta, podra ayudarme, por favor?
Otros ataques de este tipo son:
Farming
SPAM
Pishing
Cajeros automticos
1.4. Principios de Seguridad.
Confidencialidad: La informacin puede ser accedida nicamente por las
personas que tienen autorizacin para hacerlo.
Integridad: La informacin no ha sido borrada, copiada o alterada, no slo en
su trayecto, sino tambin desde su origen.
Disponibilidad: Los usuarios deben tener disponibles todos los componentes
del Ing. Henry Eduardo Bastidas Paruma sistema cuando as lo deseen.
Autenticidad: La integridad nos informa que el archivo, por ejemplo, no ha sido
retocado ni editado, y autenticidad nos informa que el archivo en cuestin es el
real.
Pgina 16
UNIDAD 2
ANALISIS DEL SOFTWARE SEGURO
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
2.1 HERRAMIENTAS DE ANLISIS DEL SOFTWARE SEGURO.

El concepto de seguridad de la informacin no debe ser confundido con el de
seguridad informtica, ya que este ltimo solo se encarga de la seguridad en
el medio informtico, pero la informacin puede encontrarse en diferentes
medios o formas, y no solo en medios informticos.
La seguridad informtica es la disciplina que se ocupa de disear las normas,
procedimientos, mtodos y tcnicas destinados a conseguir un sistema de
informacin seguro y confiable.
2.1.1 Mtodos, tcnicas y herramientas para la ingeniera de
requerimientos de la seguridad del software.
Algunos mtodos utilizados en proyectos de desarrollo de software en la
industria, o en pruebas piloto exitosas en el rea de investigacin, y que han
sido considerados como una tecnologa lista para ser transferida. Estas tcnicas
hacen posible considerar la seguridad en los requerimientos de software, con
herramientas que implementan o dan soporte a la tcnica. Mirando crticamente,
todas ellas hacen uso de la misma informacin. Realizan cosas similares con
nombres diferentes o poniendo diferente nfasis. No es la intencin seleccionar
uno a desmedro de otro. Diferentes tcnicas resultan en diferentes puntos de
vista del problema y se complementan entre s.
Por ejemplo, es necesario conocer sobre amenazas para definir defensas:
utilizar patrones de ataque me puede facilitar la bsqueda de casos de mal uso.
Algunas tcnicas se enfocan en la licitacin, otras en anlisis, y otras en la
especificacin, documentacin, verificacin o gestin de requerimientos a lo
largo de todo el CVDS.
Hay varias tcnicas y herramientas para modelar amenazas, ataques y
vulnerabilidades. Microsoft, por ejemplo, ha reforzado este tipo de modelos en
su iniciativa de software seguro. Por otro lado, en los ltimos aos han surgido
mltiples metodologas que permiten a los desarrolladores conducir el modelado
de amenazas y valoracin de riesgos en la construccin de software.
Pgina 19
UNIDAD 2
2.1.2 Herramientas de anlisis de software.

Algunas de las herramientas que se ocupan para un buen anlisis del software
en las que destacan las 10 mejores ms utilizadas son las siguientes:
Nessus: Es la herramienta de evaluacin de seguridad "Open Source" de mayor
renombre.
Nessus es un escner de seguridad remoto para Linux, BSD, Solaris y Otros

Unix. Est basado en plug-in(s), tiene una interfaz basada en GTK, y realiza ms
de 1200 pruebas de seguridad remotas. Permite generar reportes en HTML,
XML, LaTeX, y texto ASCII; tambin sugiere soluciones para los problemas de
seguridad.
Snort: Un sistema de deteccin de intrusiones (IDS) libre para las masas.
Snort es una sistema de deteccin de intrusiones de red de poco peso (para el
sistema), capaz de realizar anlisis de trfico en tiempo real y registro de
paquetes
en
redes
con
IP.
Puede
realizar
anlisis
de
protocolos,
bsqueda/identificacin de contenido y puede ser utilizado para detectar una

gran varidad de ataques y pruebas, como por ej. Buffer overflows, escaneos
indetectables de puertos {"stealth port scans"}, ataques a CGI, pruebas de SMB
{"SMB Probes"}, intentos de reconocimientos de sistema operativos {"OS
fingerprinting"} y mucho ms. Snort utilizar un lenguaje flexible basado en reglas
para describir el trfico que debera recolectar o dejar pasar, y un motor de
deteccin modular. Mucha gente tambin sugiri que la Consola de Anlisis para
Bases de Datos de Intrusiones (Analysis Console for Intrusion Databases, ACID)
sea utilizada con Snort.
Netcat: La navaja multiuso para redes.

Una utilidad simple para Unix que lee y escribe datos a travs de conexiones de
red usando los protocolos TCP o UDP. Est diseada para ser una utilidad del
tipo "back-end" confiable que pueda ser usada directamente o fcilmente
manejada por otros programas y scripts. Al mismo tiempo, es una herramienta
rica en caractersticas, til para depurar {debug} y explorar, ya que puede crear
Pgina 20
UNIDAD 2
Casi cualquier tipo de conexin que podamos necesitar y tiene muchas

habilidades includas.
TCPDump / WinDump: El sniffer clsico para monitoreo de redes y adquisicin

de informacin. Tcpdump es un conocido y querido analizador de paquetes de
red basado en texto. Puede ser utilizado para mostrar los encabezados de los
paquetes en una interfaz de red {"network interface"} que concuerden con cierta
expresin de bsqueda. Podemos utilizar esta herramienta para rastrear
problemas en la red o para monitorear actividades de la misma. Hay una versin
{port} para Windows llamada WinDump. TCPDump es tambin la fuente de las
bibliotecas de captura de paquetes Libpcap y WinPcap que son utilizadas
por Nmap y muchas otras utilidades. Hay que tener en cuenta que muchos
usuarios prefieren el sniffer ms nuevo Ethereal.
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.
Whisker/Libwhisker: El escner y la biblioteca de vulnerabilidades de CGI de

Rain.Forest.Puppy. Whisker es un escner que nos permite poner a prueba
servidores de HTTP con respecto a varias agujeros de seguridad conocidos,
particularmente, la presencia de peligrosos scripts/programas que utilicen CGI.
Libwhisker es una biblioteca para perl (utilizada por Whisker) que nos permite
crear escneres de HTTP a medida. Si lo que se desea es auditar ms que slo
servidores de web, podemos darle una mirada a Nessus.
Pgina 21
UNIDAD 2
John the Ripper: Un extraordinariamente poderoso, flexible y rpido cracker de

hashes de passwords multi-plataforma. John the Ripper es un cracker de
passwords rpido, actualmente disponible para muchos sabores de Unix (11 son
oficialmente soportados, sin contar arquitecturas diferentes), DOS, Win32, BeOs,
y OpenVMS. Su propsito principal es detectar passwords de Unix dbiles.
Soporta varios tipos de hashes de password de crypt (3) que son comnmente
encontrados en varios sabores de Unix, as como tambin AFS de Kerberos y
las "LM hashes" de Windows NT/2000/XP. Otros varios tipos de hashes se
pueden agregar con algunos parches que contribuyen algunos desarrolladores.
OpenSSH / SSH: Una manera segura de acceder a computadoras remotas.Un

reemplazo seguro para rlogin/rsh/rcp. OpenSSH deriva de la versin de ssh de
OpenBSD, que a su vez deriva del cdigo de ssh pero de tiempos anteriores a
que la licencia de ssh se cambiara por una no libre. Ssh (secure shell) es un
programa para loggearse en una mquina remota y para ejecutar comandos en
una mquina remota. Provee de comunicaciones cifradas y seguras entre dos
hosts no confiables {"untrusted hosts"} sobre una red insegura. Tambin se
pueden redirigir conexiones de X11 y puertos arbitrarios de TCP/IP sobre este
canal seguro. La intencin de esta herramienta es la de reemplazar a `rlogin',
`rsh' y `rcp', y puede ser usada para proveer de rdist', y rsync' sobre una canal
de comunicacin seguro. Hay que notar que la versin del siguiente link a
SSH.com cuesta dinero para algunos usos, mientras que OpenSSH es siempre
de uso libre. Los usuarios de Windows quizs quieran el cliente de SSH
libre PuTTYo la linda versin para terminal {"terminal-based port"} de OpenSSH
que viene con Cygwin.
Sam Spade: Herramienta de consulta de redes de distribucin gratuita.

SamSpade nos provee de una interfaz de usuario grfica (GUI) consistente y de
una implementacin de varias tareas de investigacin de red tiles. Fue diseada
con la idea de rastrear spammers en mente, pero puede ser til para muchas
otras tareas de exploracin, administracin y seguridad. Incluye herramientas
como ping, nslookup, whois, dig, traceroute, finger, explorador de web crudo,
transferencia de zona de DNS {"DNS zone transer"}, comprobacin de "relay" de
Pgina 22
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.
ISS Internet Scanner: Evaluacin de vulnerabilidades a nivel de Aplicacin.

Internet Scanner comenz en el '92 como un pequeo escner "Open Source"
escrito por Christopher Klaus. ISS creci hasta ser una enorme empresa con una
amplia gama de productos de seguridad. El escner de Internet de ISS es
bastante bueno, pero no es barato! Las empresas con presupuestos ajustados
quizs quieran darle una mirada a Nessus. Una revisin de 5 herramientas de
anlisis de vulnerabilidades {"VA tools"} en la revista "Information Security" de
marzo del 2003 est disponible ac.
Tripwire: El abuelo de las herramientas de comprobacin de integridad de

archivos.Un comprobador de integridad de archivos y directorios. Tripwire es una
herramienta que ayuda a administradores y usuarios de sistemas monitoreando
alguna posible modificacin en algn set de archivos. Si se usa regularmente en
los archivos de sistema (por ej. diariamente), Tripwire puede notificar a los
administradores del sistema, si algn archivo fue modificado o reemplazado,
para que se puedan tomar medidas de control de daos a tiempo. Una version
"Open Source" para Linux est disponible de manera gratuita en Tripwire.Org.
Nikto: Un escner de web de mayor amplitud. Nikto es un escner de servidores

de web que busca ms de 2000 archivos/CGIs potencialmente peligrosos y
problemas en ms de 200 servidores. Utiliza la biblioteca LibWhisker pero
generalmente es actualizado ms frecuentemente que el propio Whisker.
Kismet: Un poderoso sniffer para redes inalmbricas. Kismet es un sniffer y
disecador de redes 802.11b. Es capaz de "sniffear" utilizando la mayora de las
placas inalmbricas; de detectar bloques de IP automaticamente por medio de
paquetes de UDP, ARP, y DHCP; listar equipos de Cisco por medio del "Cisco
Discovery Protocol"; registrar paquetes criptogrficamente dbiles y de generar
archivos de registro compatibles con los de ethereal y tcpdump. Tambin incluye
la habilidad de graficar redes detectadas y rangos de red estimados sobre mapas
Pgina 23
UNIDAD 2
o imgenes. La versin para Windows est todava en etapas preliminares. Es

por eso que quien lo necesite quizs quiera darle una mirada a Netstumbler si
tiene algn problema.
2.2 CAPTURA DE LOS REQUERIMIENTOS DE SEGURIDAD

Qu son Requerimientos?
Normalmente, un tema de la Ingeniera de Software tiene diferentes significados.

De las muchas definiciones que existen para requerimiento, a continuacin se
presenta la definicin que aparece en el glosario de la IEEE.
(1) Una condicin o necesidad de un usuario para resolver un problema o
alcanzar un objetivo. (2) Una condicin o capacidad que debe estar presente en
un sistema o componentes de sistema para satisfacer un contrato, estndar,
especificacin u otro documento formal. (3) Una representacin documentada de
una condicin o capacidad como en (1) o (2).
Los requerimientos puedes dividirse
en requerimientos funcionales y
requerimientos no funcionales. Los requerimientos funcionales definen las

funciones que el sistema ser capaz de realizar. Describen las transformaciones
que el sistema realiza sobre las entradas para producir salidas.
Los requerimientos no funcionales tienen que ver con caractersticas que de una
u otra forma puedan limitar el sistema, como por ejemplo, el rendimiento (en
tiempo y espacio), interfaces de usuario, fiabilidad (robustez del sistema,
disponibilidad de equipo), mantenimiento, seguridad, portabilidad, estndares,
etc.
2.2.1 Caractersticas de los requerimientos
Las caractersticas de un requerimiento son sus propiedades principales. Un
conjunto de requerimientos en estado de madurez, deben presentar una serie de
caractersticas tanto individualmente como en grupo. A continuacin se
presentan las ms importantes.
Pgina 24
UNIDAD 2
Necesario: Un requerimiento es necesario si su omisin provoca una deficiencia

en el sistema a construir, y adems su capacidad, caractersticas fsicas o factor
de calidad no pueden ser reemplazados por otras capacidades del producto o
del proceso.
Conciso: Un requerimiento es conciso si es fcil de leer y entender. Su redaccin
debe ser simple y clara para aquellos que vayan a consultarlo en un futuro.
Completo: Un requerimiento est completo si no necesita ampliar detalles en su
redaccin, es decir, si se proporciona la informacin suficiente para su
comprensin.
Consistente: Un requerimiento es consistente si no es contradictorio con otro
requerimiento.
No ambiguo: Un requerimiento no es ambiguo cuando tiene una sola
interpretacin.
Verificable: Un requerimiento es verificable cuando puede ser cuantificado de
manera que permita hacer uso de los siguientes mtodos de verificacin:
inspeccin, anlisis, demostracin o pruebas.
Dificultades para definir los requerimientos
requerimientos no son obvios y vienen de muchas fuentes.
Son difciles de expresar en palabras (el lenguaje es ambiguo).
Existen muchos tipos de requerimientos y diferentes niveles de detalle.
La cantidad de requerimientos en un proyecto puede ser difcil de manejar.
Nunca son iguales. Algunos son ms difciles, ms riesgosos, ms
importantes o ms estables que otros.
Los requerimientos estn relacionados unos con otros, y a su vez se
relacionan con otras partes del proceso.
Cada requerimiento tiene propiedades nicas y abarcan reas funcionales
especficas.
Un requerimiento puede cambiar a lo largo del ciclo de desarrollo.
Son difciles de cuantificar, ya que cada conjunto de requerimientos es
particular para cada proyecto.
Pgina 25
UNIDAD 2
2.2.2 Ingeniera de Requerimientos vs. Administracin de Requerimientos.

El proceso de recopilar, analizar y verificar las necesidades del cliente para un
sistema es llamado Ingeniera de Requerimientos. La meta de la ingeniera de
requerimientos (IR) es entregar una especificacin de requisitos de software
correcta y completa.
Los requerimientos son la Pieza fundamental en un proyecto de desarrollo de

software, es ellos se basan muchos participantes del proyecto para:
Planear el proyecto y los recursos que se usarn en l. Los lderes de proyecto
usan los requerimientos como una base para la estimacin del esfuerzo
necesario en un proyecto.
Especificar el tipo de verificaciones que se habrn de realizar al sistema. Por

ejemplo: cuando se est tratando de alinearse a cierta norma oficial o estndar.
Planear la estrategia de prueba a la que habr de ser sometido el sistema. Los
requerimientos son la base sobre la cual se decide si un caso de prueba fue
ejecutado exitosamente por el sistema o no.
Son el fundamento del ciclo de vida del proyecto. Los requerimientos

documentados son la base para crear la documentacin del sistema
De ah su importancia y la importancia de que deban de ser definidos y
manejados de la forma ms adecuada posible.
2.2.2.1 Caractersticas de un requerimiento

Ya que visualizamos la importancia de los requerimientos en un sistema de
software entonces debemos de definir qu caractersticas deben de poseer los
requerimientos adecuadamente formulados.
Los requerimientos deben ser:
Especificados por escrito. Como todo contrato o acuerdo entre dos partes
Pgina 26
UNIDAD 2
Posibles de probar o verificar. Si un requerimiento no se puede comprobar,

entonces cmo sabemos si cumplimos con l o no?
Descritos como una caracterstica del sistema a entregar. Esto es: que es lo que
el sistema debe de hacer (y no como debe de hacerlo)
Lo ms abstracto y conciso posible. Para evitar malas interpretaciones.
2.2.3 Fundamentos del Anlisis de Requerimientos
Definicin: Es el conjunto de tcnicas y procedimientos que nos permiten
conocer los elementos necesarios para definir un proyecto de software. Es la
etapa ms crucial del desarrollo de un proyecto de software. La IEEE los divide
en funcionales y no funcionales:
Funcionales: Condicin o capacidad de un sistema requerida por el
usuario para resolver un problema o alcanzar un objetivo.
No Funcionales: Condicin o capacidad que debe poseer un sistema
para satisfacer un contrato, un estndar, una especificacin u otro
documento formalmente impuesto.
Para realizar bien el desarrollo de software es esencial realizar una

especificacin
completa
de
los
requerimientos
de
los
mismos.
Independientemente de lo bien diseado o codificado que est, un programa

pobremente especificado decepcionar al usuario y har fracasar el desarrollo.
La tarea de anlisis de los requerimientos es un proceso de descubrimiento y
refinamiento, El mbito del programa, establecido inicialmente durante la
ingeniera del sistema, es refinado en detalle. Se analizan y asignan a los
distintos elementos de los programas las soluciones alternativas.
Tanto el que desarrolla el software como el cliente tienen un papel activo en la
especificacin de requerimientos. El cliente intenta reformular su concepto, algo
nebuloso, de la funcin y comportamiento de los programas en detalles
concretos, El que desarrolla el software acta como interrogador, consultor y el
que resuelve los problemas.
El anlisis y especificacin de requerimientos puede parecer una tarea
relativamente sencilla, pero las apariencias engaan. Puesto que el contenido
Pgina 27
UNIDAD 2
de comunicacin es muy alto, abundan los cambios por mala interpretacin o

falta de informacin. El dilema con el que se enfrenta un ingeniero de software
puede ser comprendido repitiendo la sentencia de un cliente annimo: "S que
crees que comprendes lo que piensas que he dicho, pero no estoy seguro de
que lo que creste or sea lo que yo quise decir".
Los requerimientos de un sistema de software, cuando se ven en su conjunto
son extensos y detallados, y adems contienen mltiples relaciones entre s. Lo
que nos da a concluir, que el conjunto de requerimientos de un sistema
computacional es complejo.
Obtenemos la posibilidad de especificar sistemas complejos al documentar
especificaciones simples y concisas para el sistema. Esto se logra mediante al
clasificar, estructurar y organizar todo lo que el sistema debe de hacer. En otras
palabras al analizar sus requerimientos.
El anlisis de requerimientos es la tarea que plantea la asignacin de software a
nivel de sistema y el diseo de programas. El anlisis de requerimientos facilita
al ingeniero de sistemas especificar la funcin y comportamiento de los
programas, indicar la interfaz con otros elementos del sistema y establecer las
ligaduras de diseo que debe cumplir el programa. El anlisis de requerimientos
permite al ingeniero refinar la asignacin de software y representar el dominio de
la informacin que ser tratada por el programa. El anlisis de requerimientos de
al diseador la representacin de la informacin y las funciones que pueden ser
traducidas en datos, arquitectura y diseo procedimental. Finalmente, la
especificacin de requerimientos suministra al tcnico y al cliente, los medios
para valorar la calidad de los programas, una vez que se haya construido.
2.2.4 Tareas del Anlisis
El anlisis de requerimientos puede dividirse en cuatro reas:
1.- Reconocimiento del problema
2.- Evaluacin y sntesis
3.- Especificacin
4.- Revisin.
Pgina 28
UNIDAD 2
Inicialmente, el analista estudia la especificacin del sistema (si existe) y el plan

de proyecto. Es importante comprender el contexto del sistema y revisar el
mbito de los programas que se us para generar las estimaciones de la
planificacin. A continuacin, debe establecerse la comunicacin necesaria para
el anlisis, de forma que se asegure el reconocimiento del problema.
El analista debe establecer contacto con el equipo tcnico y de gestin del

usuario / cliente y con la empresa que vaya a desarrollar el software. El gestor
del programa puede servir como coordinador para facilitar el establecimiento de
los caminos de comunicacin. El objetivo del analista es reconocer los elementos
bsicos del programa tal como lo percibe el usuario / cliente.
La evaluacin del problema y la sntesis de la solucin es la siguiente rea

principal de trabajo del anlisis. El analista debe evaluar el flujo y estructura de
la informacin, refinar en detalle todas las funciones del programa, establecer las
caractersticas de la interface del sistema y descubrir las ligaduras del diseo,
Cada una de las tareas sirve para descubrir el problema de forma que pueda
sintetizarse un enfoque o solucin global.
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.
Una vez que se hayan descrito las funcionalidades bsicas, comportamiento,

interface e informacin, se especifican los criterios de validacin para demostrar
una comprensin de una correcta implementacin de los programas. Estos
criterios sirven como base para hacer una prueba durante el desarrollo de los
programas. Para definir las caractersticas y atributos del software se escribe una
especificacin de requerimientos formal. Adems, para los casos en los que se
desarrolle un prototipo se realiza un manual de usuario preliminar.
Pgina 29
UNIDAD 2
Puede parecer innecesario realizar un manual de usuario en una etapa tan

temprana del proceso de desarrollo, Pero de hecho, este borrador del manual de
usuario fuerza al analista a tomar el punto de vista del usuario del software. El
manual permite al usuario / cliente revisar el software desde una perspectiva de
ingeniera humana y frecuentemente produce el comentario: "La idea es correcta
pero esta no es la forma en que pens que se podra hacer esto". Es mejor
descubrir tales comentarios lo ms tempranamente posible en el proceso.
Los documentos del anlisis de requerimiento (especificacin y manual de

usuario) sirven como base para una revisin conducida por el cliente y el tcnico.
La revisin de los requerimientos casi siempre produce modificaciones en la
funcin, comportamiento, representacin de la informacin, ligaduras o criterios
de validacin. Adems, se realiza una nueva apreciacin del plan del proyecto
de software para determinar si las primeras estimaciones siguen siendo vlidas
despus del conocimiento adicional obtenido durante el anlisis.
2.2.4.1 Obteniendo de la informacin

Los requerimientos son el punto de acuerdo entre el cliente y el proyecto de
desarrollo de software, este entendimiento es necesario para poder construir
software que satisfaga las necesidades de nuestro cliente.
Si los requerimientos se enfocan a describir las necesidades del cliente,
entonces es lgico que para recabarlos haya que obtener la informacin de
primera mano. Esto es, mediante entrevistas con el cliente o recabando
Documentacin que describa la manera que el cliente desea que funcione el

sistema de software.
Las necesidades y / o requerimientos del cliente evolucionan con el tiempo y

cada cambio involucra un costo. Por eso es necesario tener archivada una copia
de la documentacin original del cliente, as como cada revisin o cambio que
se haga a esta documentacin. Como cada necesidad del cliente es tratada de
diferente forma, es necesario clasificar estas necesidades para saber cules de
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.
La SRS posee las mismas caractersticas de los requerimientos: completa,

consistente, verificable, no ambigua, factible, modificable, rastreable, precisa,
entre otras. Para que cada caracterstica de la SRS sea considerada, cada uno
de los requerimientos debe cumplirlas; por ejemplo, para que una SRS se
considere verificable, cada requerimiento definido en ella debe ser verificable;
para que una SRS se considere modificable, cada requerimiento debe ser
modificable y as sucesivamente. Las caractersticas de la SRS son verificadas
en la actividad de Validacin, descrita en el punto.
Pgina 31
UNIDAD 2
La estandarizacin de la SRS es fundamental pues ayudar, entre otras cosas,

a facilitar la lectura y escritura de la misma. Ser un documento familiar para
todos los involucrados, adems de asegurar que se cubren todos los tpicos
importantes.
Existen plantillas creadas para la SRS, sin embargo, cada uno tiene la potestad
de crear su propia plantilla.
Clasificacin de los requerimientos
El clasificar requerimientos es una forma de organizarlos, hay requerimientos
que por sus caractersticas no pueden ser tratados iguales.
La siguiente es una recomendacin de cmo pueden ser clasificados los
requerimientos aunque cada proyecto de software pueda usar sus propias
clasificaciones.
Requerimientos del "entorno"
El entorno es todo lo que rodea al sistema. Aunque no podemos cambiar el
entorno, existen cierto tipo de requerimientos que se clasifican en esta categora
porque:
El sistema usa el entorno y lo necesita como una fuente de los servicios
necesarios para que funcione. Ejemplos del entorno podemos mencionar:
sistemas operativos, sistema de archivos, bases de datos.
El sistema debe de ser robusto y tolerar los errores que puedan ocurrir en el
entorno, tales como congestin en los dispositivos y errores de entrada de datos,
por lo tanto el entorno se debe de considerar dentro de los requerimientos.
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
recibe o manda al exterior. Usualmente se especifica el protocolo, el tipo de

informacin, el medio para comunicarse y el formato de los datos que se van a
comunicar.
2.2.4.3 Actividades de la Ingeniera de Requerimientos
En el proceso de IR son esenciales diversas actividades. En este documento
sern presentadas, sin embargo, en un proceso de ingeniera de requerimientos
efectivo, estas actividades son aplicadas de manera continua y en orden variado.
Dependiendo del tamao del proyecto y del modelo de proceso de software
utilizado para el ciclo de desarrollo, las actividades de la IR varan tanto en
nmero como en nombres. La tabla #1 muestra algunos ejemplos de las
actividades identificadas para cada proceso.
A pesar de las diferentes interpretaciones que cada desarrollador tenga sobre el
conjunto de actividades mostradas en la tabla anterior, podemos identificar y
extraer cinco actividades principales que son:
Anlisis del Problema
Evaluacin y Negociacin
Especificacin
Validacin
Evolucin
2.2.4.4 Principios de Especificacin

La especificacin, independientemente del modo en que se realice, puede ser
vista como un proceso de representacin. Los requerimientos se representan de
forma que conduzcan finalmente a una correcta implementacin del software.
Baltzer y Goldman proponen ocho principios para una buena especificacin:
PRINCIPIO #1. Separar funcionalidad de implementacin.
Primero, por definicin, una especificacin es una descripcin de lo que se
desea, en vez de como se realiza (implementa). Las especificaciones pueden
adoptar dos formas muy diferentes. La primera forma es la de funciones
matemticas: dado algn conjunto de entrada, producir un conjunto particular de
salida. La forma general de tales especificaciones es encontrar [un/el/todos]
Pgina 33
UNIDAD 2
resultado tal que P (entrada), donde P representa un predicado arbitrario. En

tales especificaciones, el resultado a ser obtenido ha sido expresado
enteramente en una forma sobre el que (en vez de como). En parte, esto es
debido a que el resultado es una funcin matemtica de la entrada (la operacin
tiene puntos de comienzo y parada bien definidos) y no est afectado por el
entorno que le rodea.
PRINCIPIO #2. Se necesita un lenguaje de especificacin de sistemas orientado

al proceso. Considerar una situacin en la que el entorno sea dinmico y sus
cambios afecten al comportamiento de alguna entidad que interacte con dicho
entorno. Su comportamiento no puede ser expresado como una funcin
matemtica de su entrada. En vez de ello, debe emplearse una descripcin
orientada al proceso, en la cual la especificacin del que se consigue mediante
la especificacin de un modelo del comportamiento deseado en trminos de
respuestas funcionales, a distintos estmulos del entorno.
PRINCIPIO #3. Una especificacin debe abarcar el sistema del cual el software
es una componente.
Un sistema est compuesto de componentes que interactan. Solo dentro del
contexto del sistema completo y de la interaccin entre sus partes puede ser
definido el comportamiento de una componente especfica. En general, un
sistema puede ser modelado como una coleccin de objetos pasivos y activos.
Estos objetos estn interrelacionados y dichas relaciones entre los objetos
cambian con el tiempo. Estas relaciones dinmicas suministran los estmulos a
los cuales los objetos activos, llamados agentes, responden. Las respuestas
pueden causar posteriormente cambios y, por tanto, estmulos adicionales a los
cuales los agentes deben responder.
PRINCIPIO #4. Una especificacin debe abarcar el entorno en el que el sistema
opera. Similarmente, el entorno en el que opera el sistema y con el que interacta
debe ser especificado. Afortunadamente, esto tan solo necesita reconocer que
el propio entorno es un sistema compuesto de objetos que interactan, pasivos
y activos, de los cuales el sistema especificado es una agente, Los otros agentes,
Pgina 34
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
PRINCIPIO #7. La especificacin del sistema debe ser tolerante con la

incompletitud y aumentable. Ninguna especificacin puede ser siempre
totalmente completa. El entorno en el que existe es demasiado complejo para
ello. Una especificacin es siempre un modelo, una abstraccin, de alguna
situacin real (o imaginada). Por tanto, ser incompleta. Adems, al ser formulad
existirn muchos niveles de detalle. La operacionalidad requerida anteriormente
no necesita ser completa. Las herramientas de anlisis empleadas para ayudar
a los especificadores y para probar las especificaciones, deben ser capaces de
tratar con la incompletitud. Naturalmente esto debilita el anlisis, el cual puede
ser ejecutado ampliando el rango de comportamiento aceptables, los cuales
satisfacen la especificacin, pero tal degradacin debe reflejar los restantes
niveles de incertidumbre.
PRINCIPIO #8. Una especificacin debe ser localizada y dbilmente acoplada.
Los principios anteriores tratan con la especificacin como una entidad esttica.
Esta surge de la dinmica de la especificacin. Debe ser reconocido que aunque
el principal propsito de una especificacin sea servir como base para el diseo
e implementacin de algn sistema, no es un objeto esttico
Pre-compuesto,
sino
un
objeto
dinmico
que
sufre
considerables
modificaciones. Tales modificaciones se presentan en tres actividades

principales: formulacin, cuando se est creando una especificacin inicial;
desarrollo, cuando la especificacin se est elaborando durante el proceso
iterativo de diseo e implementacin; y mantenimiento, cuando la especificacin
se cambia para reflejar un entorno modificado y / o requerimientos funcionales
adicionales.
Requerimientos funcionales
Estos son los que describen lo que el sistema debe de hacer. Es importante que
se describa l Qu? Y no l Cmo?. Estos requerimientos al tiempo que
avanza el proyecto de software se convierten en los algoritmos, la lgica y gran
parte del cdigo del sistema.
Requerimientos de desempeo
Pgina 36
UNIDAD 2
Estos requerimientos nos informan las caractersticas de desempeo que deben

de tener el sistema. Qu tan rpido?, Que tan seguido?, Cuantos recursos?,
Cuantas transacciones?
Este tipo de requerimientos es de especial importancia en los sistemas de tiempo
real en donde el desempeo de un sistema es tan crtico como su
funcionamiento.
Disponibilidad (en un determinado periodo de tiempo)
Este tipo de requerimientos se refiere a la durabilidad, degradacin, potabilidad,
flexibilidad,
contabilidad
capacidad
de
actualizacin.
Este
tipo
de
requerimientos es tambin muy importante en sistemas de tiempo real puesto

que estos sistemas manejan aplicaciones crticas que no deben de estar fuera
de servicio por periodos prolongados de tiempo.
Entrenamiento
Este tipo de requerimientos se enfoca a las personas que van usar el sistema.
Qu tipo de usuarios son?, Qu tipo de operadores?, Que manuales se
entregarn y en qu idioma?
Este tipo de requerimientos, aunque muchas veces no termina en un pedazo de
cdigo dentro del sistema, son muy importantes en el proceso de diseo ya que
facilitan la introduccin y aceptacin del sistema en donde ser implementado.
Restricciones de diseo
Muchas veces las soluciones de un sistema de software son normadas por leyes
o estndares, este tipo de normas caen como "restricciones de diseo".
Materiales
Aqu se especifica en que medio se entregara el sistema y como esta
empaquetado. Es importante para definir los costos de industrializacin del
sistema.
2.2.4.5 Manejo de requerimientos

De acuerdo con el "Capability Maturity Model" (CMM), el manejo de
requerimientos involucra:
Pgina 37
UNIDAD 2
"Establecer y mantener un acuerdo con el cliente sobre los requerimientos del

proyecto de software. Este acuerdo son los requerimientos del sistema alojados
al software. ".
Este acuerdo cubre requerimientos tcnicos y no tcnicos (como fechas de
entrega). El acuerdo forma las bases para estimar, planear, ejecutar y monitorear
el proyecto de desarrollo de software a travs de todo su ciclo de vida. "Bajo
las restricciones del proyecto, el grupo de manejo de requerimientos toma las
medidas necesarias para que los requerimientos que estn bajo su
responsabilidad estn documentados y controlados"
De qu manera podemos controlar los requerimientos de software si estos
siempre evolucionan con el tiempo?. El CMM nos proporciona las guas para
lograrlo.
"Para lograr el control de los requerimientos, el grupo de requerimientos revisa
los requerimientos antes de que estos sean incorporados al proyecto de software
y cada vez que los requerimientos cambian los planes, productos, y actividades
son ajustadas para quedar en lnea con los nuevos requerimientos de software".
En otras palabras, para obtener el nivel que requiere el CMM en manejo de
requerimientos dbenos de tomar en cuenta dos cosas.
Que los requerimientos deben de ser revisados (y aprobados) por el grupo
de requerimientos, y no son impuestos por en su totalidad por presiones
externas ajenas al proyecto.
El requerimiento tcnico podr ser impuesto por el mercado o presiones de la
competencia, pero entonces los requerimientos no tcnicos (Calidad, Costo y
Tiempo de entrega) debern estar especificados de comn acuerdo con el grupo
de requerimientos del proyecto de software.
Los requerimientos tcnicos y no tcnicos forman un conjunto entre s, si
cambia uno forzosamente debern cambiar los dems. Esto es: ms
contenido tcnico implica o ms costo, o menos calidad o ms tiempo
estimado de entrega. De modo que los cambios tcnicos debern ser
aprobados por el grupo de requerimientos y este grupo estimar los
impactos en tiempo, costo, calidad. El resultado de la estimacin es la
entrada a los lderes del proyecto para decidir si el cambio se acepta o no
Pgina 38
UNIDAD 2
2.3 ANLISIS DE LOS REQUERIMIENTOS DE SEGURIDAD.

Para analizar de forma efectiva las necesidades de seguridad de una
organizacin y evaluar y elegir distintos productos y polticas de seguridad, el
responsable de seguridad necesita una forma sistemtica de definir los
requerimientos de seguridad y caracterizar los enfoques para satisfacer dichos
requerimientos.
Si en un entorno centralizado de procesamiento de datos esto es bastante difcil,

con el uso de redes de rea local y de banda ancha esto se magnifica.
Para optimizar la seguridad de un sistema de informacin se deben realizar los

siguientes procesos:
Anlisis de riesgos. El anlisis de riesgos, como su nombre lo indica,

consiste en analizar el sistema de informacin y su entorno para detectar
todos los riesgos que amenazan su estabilidad y su seguridad.
Anlisis de requerimientos y establecimiento de polticas de seguridad

informtica. El anlisis de requerimientos de seguridad informtica consiste en
estudiar la organizacin, su sistema de informacin (y todos sus componentes)
y los riesgos que lo amenazan, y definir el nivel de seguridad informtica
necesario para el adecuado funcionamiento de la organizacin. A partir de dicho
anlisis, se define una serie de requerimientos que se deben satisfacer para
alcanzar el nivel de seguridad deseado. El proceso de anlisis tambin debe
usarse para modelar el documento de polticas de seguridad informtica, que
debe reflejar el estado ptimo de seguridad informtica que desea obtener la
organizacin, y las polticas que se deben seguir para obtenerlo.
2.3.1 Aseguramiento de componentes de datos.
La seguridad de datos busca garantizar que la informacin del sistema de
informacin est siempre disponible (disponibilidad), que se mantenga ntegra
(integridad), y que solamente pueda ser accesada por personas autorizadas
(confidencialidad).
Pgina 39
UNIDAD 2
Aseguramiento de componentes de software. La seguridad de software busca

optimizar los sistemas operativos y las aplicaciones que trabajan en el sistema
de informacin, de manera que sean configurados de manera segura y solo
permitan su uso dentro de parmetros de funcionamiento predefinidos y
aceptados (aseguramiento), que funcionen de manera continua y estable
(disponibilidad), que ofrezcan un servicio con un nivel de calidad aceptable
(calidad del servicio), que no permitan su uso por personas no autorizadas
(control de acceso), y que permitan establecer las responsabilidad de uso
(accountability).
Aseguramiento de componentes de hardware. La seguridad de software busca
optimizar los componentes de hardware del sistema de informacin (equipos de
cmputo, perifricos, medios de almacenamiento removibles, etc.), de manera
que sean configurados de manera segura y solo permitan su uso dentro de
parmetros de funcionamiento predefinidos y aceptados (aseguramiento), que
funcionen de manera continua y estable (disponibilidad), que ofrezcan un
servicio con un nivel de calidad aceptable (calidad del servicio), que no permitan
su utilizacin por personas no autorizadas (control de acceso), y que permitan
establecer las responsabilidad de uso (accountability).
2.3.2 Aseguramiento de componente humano.
La seguridad humana busca optimizar el componente humano del sistema de
informacin (usuarios, administradores, auditores, etc.) para que su interaccin
entre ellos y con terceros sea segura, no filtre informacin que pueda permitir la
vulneracin del sistema de informacin, y permita detectar ataques de ingeniera
social en su contra.
Aseguramiento de componentes de interconectividad. La seguridad del
componente
de
interconectividad
busca
optimizar
el
componente
de
comunicaciones del sistema de informacin (cableado, dispositivos de

interconexin hubs, switches, routers, etc.-, antenas, etc.), de manera que los
canales funcionen de manera continua y estable (disponibilidad) se pueda
establecer la identidad de los participantes (autenticacin), los datos transmitidos
puedan ser accesados nicamente por personas autorizadas (confidencialidad),
Pgina 40
UNIDAD 2
los datos no puedan ser modificados durante su transmisin (integridad) y se

pueda establecer el origen de toda comunicacin (no repudio).
Aseguramiento de infraestructura fsica. La seguridad de la infraestructura fsica

busca optimizar el entorno fsico (las instalaciones) en las cuales opera el
sistema de informacin, de manera que estas provean niveles de seguridad
industrial adecuados para proteger los componentes del sistema de informacin
que contiene.
2.3.3 Administracin de la seguridad informtica.
La administracin de la seguridad informtica consiste en una serie de procesos
que tienen como propsito mantener un nivel adecuado de seguridad informtica
en el sistema de informacin a lo largo del tiempo. Los procesos no se limitan al
mantenimiento y la optimizacin de la seguridad informtica en el presente, sino
que incluyen tambin procesos de planeacin estratgica de seguridad
informtica, que garanticen que el nivel de seguridad se mantendr en el futuro,
y que le permitan al sistema de seguridad informtica anticiparse a los
requerimientos de seguridad impuestos por el entorno, o por la organizacin a la
cual el sistema de informacin sirve.
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
_______________________________________________________________
3.1 HERRAMIENTAS DE DISEO DE SOFTWARE SEGURO.
FIGURA 5. Diseo De Software Seguro
3.1.1 Diagramas de secuencias y clases.

3.1.1.1 Diagrama de secuencia.
En un diagrama de secuencia se indicarn los mdulos o clases que forman
parte del programa y las llamadas que se hacen en cada uno de ellos para
realizar una tarea determinada.
Se realizan diagramas de secuencia para definir acciones que se pueden realizar
en la aplicacin en cuestin. As, en el caso de una aplicacin para jugar al
ajedrez, se podran realizar diagramas de secuencia para jugar una partida o
bien para acciones ms especficas como mover pieza.
El detalle que se muestre en el diagrama de secuencia debe estar en
consonancia con lo que se intenta mostrar o bien con la fase de desarrollo en la
que est el proyecto, no es lo mismo un diagrama de secuencia que muestre la
accin de mover pieza a otro que sea mover caballo, o bien no es lo mismo
un diagrama de secuencia mover pieza que verifique ciertos parmetros antes
de mover como la viabilidad del movimiento con respecto a una estrategia
marcada a una diagrama que no muestre este nivel de detalle por estar en una
fase inicial de diseo del sistema.
Pgina 44
UNIDAD 3
_______________________________________________________________
FIGURA 6. Diagrama de secuencias
3.1.1.2 Diagrama de clases.

Un diagrama de clase es un tipo de diagrama esttico que describe la estructura
de un sistema mostrando sus clases, atributos, y nos permite visualizar de forma
clara las relaciones entre cada clase, as como no perder de vista sus mtodos.
Recordando un poco que estoy trabajando en el desarrollo de un programa que

permita crear grficas de una forma fcil y ms directa que con otros programas,
pienso en una interfaz sencilla pero con suficientes opciones, por lo menos las
bsicas.
El siguiente es mi diagrama de clases donde podemos ver la relacin que existe

entre clase y clase, tal y como ya se los vena comentando en entradas
anteriores. Es ms fcil identificar cual clase es heredera cosas de otra. Y como
clase padre encontramos al Men, que en primera instancia nos desplegar la
ventana con unas cuantas opciones, como la de crear un nuevo registro, editarlo,
visualizarlo, y a partir de ah, generar una grfica.
Pgina 45
UNIDAD 3
_______________________________________________________________
FIGURA 7. Diagrama de clases
3.1.2 Definicin Servicios Comunes.

3.1.3 Modelamiento de Amenazas por Casos de Uso.
El modelado de amenazas es una tcnica de ingeniera cuyo objetivo es ayudar
a identificar y planificar de forma correcta la mejor manera de mitigar las
amenazas de una aplicacin o sistema informtico.
Para aprovechar mejor los beneficios que proporciona su uso, en un escenario
ideal debera iniciarse desde las primeras etapas del desarrollo y planificacin
de cualquier aplicacin o sistema.
La verdadera ventaja de esta tcnica reside en el hecho de que al aplicarse
como un proceso durante todo el ciclo de vida de desarrollo del software, supone
un enfoque diferente al tradicional anlisis de riesgos y la posterior aplicacin de
medidas que contribuyan a mejorar la seguridad. Es por esto que el anlisis y
modelado de amenazas, aunque es un campo relativamente nuevo, est
despertando un gran inters.
En este sentido, y de forma reciente, Microsoft ha sido uno de los grandes
impulsores de esta tcnica, llegando a resultar su particular visin sobre el tema
(por el momento) bastante bien encaminada. Al menos eso es lo que opinan
distintas entidades como la OWASP Foundation y expertos de reconocidas
empresas de seguridad a nivel internacional. Aunque, para alivio de algunos
posibles detractores acrrimos de soluciones procedentes de entidades con
Pgina 46
UNIDAD 3
_______________________________________________________________
nimo de lucro, existen otras alternativas en desarrollo. Tanto en lo referente a
metodologas como a herramientas.
El anlisis y modelado de amenazas, trata por lo tanto, de un proceso que nos

va a facilitar la comprensin de las diferentes amenazas de seguridad a las que
va a estar expuesto un sistema o una aplicacin, y cuya finalidad es preparar las
defensas adecuadas durante las fases de diseo, implementacin y tambin
durante su posterior revisin y testeo. Se trata de identificar las amenazas y
definir una poltica adecuada que nos permita mitigar el riesgo a unos niveles
aceptables, de una forma efectiva y en base a unos costes razonables.
Bsicamente, consiste en revisar el diseo y/o la arquitectura siguiendo una

metodologa que nos facilite encontrar y corregir los problemas de seguridad
actuales o futuros. La idea que persigue esta tcnica es que los diferentes
actores involucrados (desarrolladores, testers, gerencia, administradores de
sistemas,
pentesters,
consultoresetc.)
participen
en
el
proceso
de
identificacin de las posibles amenazas. Tomando una actitud defensiva y

tambin ponindose en ocasiones, en el papel de un posible atacante. Siguiendo
este enfoque, se fuerza a todos ellos a explorar las debilidades que puedan surgir
o que ya estn presentes, y se determina de este modo si existen las oportunas
contramedidas, o en caso contrario, se definen.
Al mismo tiempo, la realizacin de un modelado de amenazas contribuye a

identificar y cumplir con los objetivos de seguridad especficos de cada entorno
y facilita la priorizacin de tareas en base al nivel de riesgo resultante.
3.1.4 Patrones de Diseo Funcional.

Los patrones de diseo son la base para la bsqueda de soluciones a problemas
comunes en el desarrollo de software y otros mbitos referentes al diseo de
interaccin o interfaces.
Un patrn de diseo resulta ser una solucin a un problema de diseo. Para que
una solucin sea considerada un patrn debe poseer ciertas caractersticas. Una
Pgina 47
UNIDAD 3
_______________________________________________________________
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
conocidos y solucionados anteriormente.

Formalizar un vocabulario comn entre diseadores.
Estandarizar el modo en que se realiza el diseo.
Facilitar el aprendizaje de las nuevas generaciones de diseadores
condensando conocimiento ya existente.

Asimismo, no pretenden:
Imponer ciertas alternativas de diseo frente a otras.
Eliminar la creatividad inherente al proceso de diseo.
No es obligatorio utilizar los patrones, solo es aconsejable en el caso de tener el

mismo problema o similar que soluciona el patrn, siempre teniendo en cuenta
que en un caso particular puede no ser aplicable. "Abusar o forzar el uso de los
patrones puede ser un error".
3.1.4.1 Categoras de patrones

Segn la escala o nivel de abstraccin:
Patrones de arquitectura: Aquellos que expresan un esquema organizativo

estructural fundamental para sistemas de software.
Patrones de diseo: Aquellos que expresan esquemas para definir

estructuras de diseo (o sus relaciones) con las que construir sistemas de
software.
Pgina 48
UNIDAD 3
_______________________________________________________________
Dialectos: Patrones de bajo nivel especficos para un lenguaje de

programacin o entorno concreto.
Adems, tambin es importante resear el concepto de "anti-patrn de diseo",

que con forma semejante a la de un patrn, intenta prevenir contra errores
comunes de diseo en el software. La idea de los anti-patrones es dar a conocer
los problemas que acarrean ciertos diseos muy frecuentes, para intentar evitar
que diferentes sistemas acaben una y otra vez en el mismo callejn sin salida
por haber cometido los mismos errores.
Adems de los patrones ya vistos actualmente existen otros patrones como el
siguiente:
Interaccin: Son patrones que nos permiten el diseo de interfaces web.
3.1.4.2 Estructuras o plantillas de patrones

Para describir un patrn se usan plantillas ms o menos estandarizadas, de
forma que se expresen uniformemente y puedan constituir efectivamente un
medio de comunicacin uniforme entre diseadores. Varios autores eminentes
en esta rea han propuesto plantillas ligeramente distintas, si bien la mayora
definen los mismos conceptos bsicos.
La plantilla ms comn es la utilizada precisamente por el GoF y consta de los

siguientes apartados:
Nombre del patrn: nombre estndar del patrn por el cual ser
reconocido en la comunidad (normalmente se expresan en ingls).

Clasificacin del patrn: creacional, estructural o de comportamiento.
Intencin: Qu problema pretende resolver el patrn?
Tambin conocido como: Otros nombres de uso comn para el patrn.
Motivacin: Escenario de ejemplo para la aplicacin del patrn.
Aplicabilidad: Usos comunes y criterios de aplicabilidad del patrn.
Estructura: Diagramas de clases oportunos para describir las clases que
intervienen en el patrn.
Pgina 49
UNIDAD 3
_______________________________________________________________
Participantes: Enumeracin y descripcin de las entidades abstractas (y
sus roles) que participan en el patrn.

Colaboraciones: Explicacin de las interrelaciones que se dan entre los
participantes.
Consecuencias: Consecuencias positivas y negativas en el diseo
derivadas de la aplicacin del patrn.

Implementacin: Tcnicas o comentarios oportunos de cara a la
implementacin del patrn.

Cdigo de ejemplo: Cdigo fuente ejemplo de implementacin del
patrn.
Usos conocidos: Ejemplos de sistemas reales que usan el patrn.
Patrones relacionados: Referencias cruzadas con otros patrones.
3.1.5 Patrones de Diseo de Seguridad (por Amenazas)

El patrn Proxy es un patrn estructural que tiene como propsito proporcionar
un subrogado o intermediario de un objeto para controlar su acceso.
FIGURA 8. Patrones de diseo de seguridad
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
_______________________________________________________________
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
virtual: crea objetos costosos bajo demanda (como la
clase ImagenProxy en el ejemplo de motivacin).

proxy de proteccin: controla el acceso al objeto original (ejemplo
de proxy de proteccin: [1])

proxy de referencia inteligente: sustituto de un puntero que lleva a cabo
operaciones adicionales cuando se accede a un objeto (ej. contar nmero

de referencias al objeto real, cargar un objeto persistente bajo demanda
en memoria, control de concurrencia de acceso tal como bloquear el
objeto para impedir acceso concurrente, ).
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
_______________________________________________________________
responsable de su creacin y borrado. Tambin tiene otras responsabilidades
que dependen del tipo de proxy:
proxy remoto: responsable de codificar una peticin y sus argumentos, y de

enviarla al objeto remoto.
proxy virtual: puede hacer cach de informacin del objeto real para diferir
en lo posible el acceso a este.
proxy de proteccin: comprueba que el cliente tiene los permisos

necesarios para realizar la peticin.
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:
Diagrama de clases para un ejemplo del patrn proxy.[2]
Diagrama de secuencia para un ejemplo en el que no se utiliza el

patrn proxy. [3]
Diagrama de secuencia para un ejemplo en el que se utiliza el

patrn proxy.[4]
Consecuencias
El uso de un proxy introduce un nivel de indireccin adicional con
diferentes usos:
Un proxy remoto oculta el hecho de que un objeto reside en otro espacio de

direcciones.
Un proxy virtual puede realizar optimizaciones, como la creacin de objetos

bajo demanda.
El proxy de proteccin y las referencias inteligentes permiten realizar

diversas tareas de mantenimiento adicionales al acceder a un objeto.
Pgina 52
UNIDAD 3
_______________________________________________________________
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.
4.2 Modelo de seguridad.

Un modelo de seguridad es la presentacin formal de una poltica de seguridad.
El modelo debe identificar el conjunto de reglas y prcticas que regulan cmo un
sistema maneja, protege y distribuye informacin delicada (Lpez Barrientos &
Quezada Reyes, 2006).
De acuerdo a (Lpez Barrientos & Quezada Reyes, 2006), los modelos se
clasifican en:
1. Modelo abstracto: se ocupa de las entidades abstractas como sujetos y
objetos. El modelo Bell LaPadula es un ejemplo de este tipo.
2. Modelo concreto: traduce las entidades abstractas en entidades de un
sistema real como procesos y archivos.
Adems, los modelos sirven a tres propsitos en la seguridad informtica:
1. Proveer un sistema que ayude a comprender los diferentes conceptos.
Los modelos diseados para este propsito usan diagramas, analogas,
cartas. Un ejemplo es la matriz de acceso.
2. Proveer una representacin de una poltica general de seguridad formal
clara. Un ejemplo es el modelo Bell-LaPadula.
Pgina 55
UNIDAD 4
PROGRAMACION SEGURA
_______________________________________________________________
3. Expresar la poltica exigida por un sistema de cmputo especfico.
4.3 Introduccin a la criptografa

La criptografa es una herramienta muy til cuando se desea tener seguridad
informtica; puede ser tambin entendida como un medio para garantizar las
propiedades de confidencialidad, integridad y disponibilidad de los recursos de
un sistema. Con la criptografa se puede garantizar las propiedades de integridad
y confidencialidad, pero hay que saber cmo utilizarla, para ello es importante
tener claros los conceptos bsicos que estn detrs de los sistemas
criptogrficos modernos. Estos conceptos van desde entender qu es la
criptografa, cmo est clasificada, entender el funcionamiento bsico de
algunos sistemas de cifrado y conocer cmo se forman los documentos digitales
como firmas y sobres digitales.
La palabra criptografa proviene en un sentido etimolgico del griego

Kriptos=ocultar, Graphos=escritura, lo que significara ocultar la escritura, o en
un sentido ms amplio sera aplicar alguna tcnica para hacer ininteligible un
mensaje. En su clasificacin dentro de las ciencias, la criptografa proviene de
una rama de las matemticas, que fue iniciada por el matemtico Claude Elwood
Shannon en 1948, denominada: Teora de la Informacin.
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.
La autentificacin mediante contrasea es el sistema ms comn ya que viene

incorporado en los sistemas operativos modernos de todos los ordenadores. Los
ordenadores que estn preparados para la autentificacin mediante dispositivo
slo reconocer al usuario mientras mantenga introducida una llave,
normalmente una tarjeta con chip. Hay sistemas de generacin de claves
asimtricas que introducen la clave privada en el chip de una tarjeta inteligente.
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
_______________________________________________________________
4.4.1 Mtodos de autenticacin

Los mtodos de autenticacin estn en funcin de lo que utilizan para la
verificacin y estos se dividen en tres categoras:
Sistemas basados en algo conocido. Ejemplo, un password (Unix) o
passphrase (PGP).
Sistemas basados en algo posedo. Ejemplo, una tarjeta de identidad, una
tarjeta inteligente (smartcard), dispositivo USB tipo epass token,
smartcard o dongle criptogrfico.
Sistemas basados en una caracterstica fsica del usuario o un acto
involuntario del mismo: Ejemplo, verificacin de voz, de escritura, de
huellas, de patrones oculares.
4.4.2 Caractersticas de autenticacin

Cualquier sistema de identificacin ha de poseer unas determinadas
caractersticas para ser viable:
Ha de ser fiable con una probabilidad muy elevada (podemos hablar de
tasas de fallo de en los sistemas menos seguros).
Econmicamente factible para la organizacin (si su precio es superior al
valor de lo que se intenta proteger, tenemos un sistema incorrecto).
Soportar con xito cierto tipo de ataques.
Ser aceptable para los usuarios, que sern al fin y al cabo quienes lo
utilicen.
4.4.3 Mecanismo general de autenticacin
La mayor parte de los sistemas informticos y redes mantienen de uno u otro
modo una relacin de identidades personales (usuarios) asociadas normalmente
con un perfil de seguridad, roles y permisos. La autenticacin de usuarios permite
a estos sistemas asumir con una seguridad razonable que quien se est
conectando es quien dice ser para que luego las acciones que se ejecuten en el
Pgina 58
UNIDAD 4
PROGRAMACION SEGURA
_______________________________________________________________
Sistema puedan ser referidas luego a esa identidad y aplicar los mecanismos de
autorizacin y/o auditora oportunos.
El primer elemento necesario (y suficiente estrictamente hablando) por tanto

para la autenticacin es la existencia de identidades biunvocamente
identificadas con un identificador nico (valga la redundancia).
Los identificadores de usuarios pueden tener muchas formas siendo la ms
comn una sucesin de caracteres conocida comnmente como login. El
proceso general de autenticacin consta de los siguientes pasos:
1. El usuario solicita acceso a un sistema.
2. El sistema solicita al usuario que se autentique.
3. El usuario aporta las credenciales que le identifican y permiten verificar la
autenticidad de la identificacin.
4. El sistema valida segn sus reglas si las credenciales aportadas son
suficientes para dar acceso al usuario o no.
4.4.4 Control de acceso
Un ejemplo familiar es el control de acceso. Un sistema informtico supuesto
para ser utilizado solamente por aquellos autorizados, debe procurar detectar y
excluir el desautorizado. El acceso a l por lo tanto es controlado generalmente
insistiendo en un procedimiento de la autentificacin para establecer con un
cierto grado establecido de confianza la identidad del usuario, por lo tanto
concediendo esos privilegios como puede ser autorizado a esa identidad. Los
ejemplos comunes del control de acceso que implican la autenticacin incluyen:
Retirar de dinero de un cajero automtico.
Control de un computador remoto sin Internet.
Uso de un sistema Internet banking.
Sin embargo, observar que mucha de la discusin sobre estos asuntos es

engaosa porque los trminos se utilizan sin la precisin. Parte de esta confusin
puede ser debido al tono de la aplicacin de ley de mucha de la discusin.
Ninguna computadora, programa de computadora, o poder del usuario de la
computadora confirman la identidad de otro partido. No es posible establece
Pgina 59
UNIDAD 4
PROGRAMACION SEGURA
_______________________________________________________________
o probar una identidad, cualquiera. Hay ediciones difciles que estn al acecho
debajo de qu aparece ser una superficie directa.
Es solamente posible aplicar una o ms pruebas que, si estn pasadas, se han

declarado previamente para ser suficientes proceder. El problema es
determinarse qu pruebas son suficientes, y muchos tales son inadecuadas.
Tienen sido muchos casos de tales pruebas que son spoofed con xito; tienen
por su falta demostrada, ineludible, ser inadecuadas. Mucha gente contina
mirando las pruebas -- y la decisin para mirar xito en pasar -como aceptable,
y para culpar su falta en sloppiness o incompetencia de parte alguien. El
problema es que la prueba fue supuesta para trabajar en la prctica -- no bajo
condiciones ideales de ningn sloppiness o incompetencia-y no. Es la prueba
que ha fallado en tales casos. Considerar la caja muy comn de un email de la
confirmacin a el cual deba ser contestado para activar una cuenta en lnea de
una cierta clase. Puesto que el email se puede arreglar fcilmente para ir a o
para venir de direcciones falsas y untraceable, ste es justo sobre la menos
autenticacin robusta posible. El xito en pasar esta prueba significa poco, sin
consideracin alguna hacia sloppiness o incompetencia.
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.
El proceso de autorizacin se usa para decidir si la persona, programa o

dispositivo X tiene permiso para acceder al dato, funcionalidad o servicio Y. La
mayora de los sistemas operativos multiusuarios modernos incluyen un proceso
de autorizacin.
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.
Existe tambin el concepto de consumidores confiables (trusted). Los

consumidores que se han autenticado y a los que se sealan como confiables
se les permite acceso ilimitado a los recursos.
Los consumidores parcialmente confiables e invitados estn sujetos a
autorizacin para usar los recursos protegidos. Las aplicaciones de polticas de
seguridad de algunos sistemas operativos, conceden por defecto a todos los
consumidores acceso completo a todos los recursos. Otros hacen lo opuesto,
insistiendo en que el administrador lleve a cabo acciones deliberadas para
permitir a cada consumidor el uso de cada recurso.
Incluso cuando la autorizacin se realiza usando una combinacin de
autenticacin y ACLs, los problemas de mantener los datos de las polticas de
seguridad no es trivial, representando a menudo tanta sobrecarga administrativa
como la prueba de las necesarias identidades de usuario. A menudo es deseable
eliminar la autorizacin de un usuario: para ello, con la aplicacin de polticas de
seguridad, es necesario que los datos sean actualizables.
Pgina 61
UNIDAD 4
PROGRAMACION SEGURA
_______________________________________________________________
4.6 Validacin de Input y Limpieza de Output

4.7 Registro de Datos (Logging)
En informtica, o concretamente en el contexto de una base de datos relacional,
un registro (tambin llamado fila o tupla) representa un objeto nico de datos
implcitamente estructurados en una tabla. En trminos simples, una tabla de
una base de datos puede imaginarse formada de filas y columnas o campos.
Cada fila de una tabla representa un conjunto de datos relacionados, y todas las
filas de la misma tabla tienen la misma estructura.
Un registro es un conjunto de campos que contienen los datos que pertenecen
a una misma repeticin de entidad. Se le asigna automticamente un nmero
consecutivo (nmero de registro) que en ocasiones es usado como ndice
aunque lo normal y prctico es asignarle a cada registro un campo clave para su
bsqueda.
4.8 Administracin de Sesiones y Estados en Aplicaciones

4.8.1 Estado de aplicacin
HttpApplicationState como un mtodo para almacenar informacin global

especfica de la aplicacin de forma que sea visible para toda la aplicacin.
Informacin general sobre el estado de aplicacin de ASP.NET
Informacin general sobre la administracin de estados de ASP.NET.
Implementacin sencilla El estado de aplicacin es fcil de usar, es
coherente con otras clases de .NET Framework y los programadores de
ASP lo conocen bien.
mbito de la aplicacin Dado que todas las pginas de una aplicacin
pueden tener acceso al estado de aplicacin, si se almacena informacin
en el estado de aplicacin puede ocurrir que slo exista una nica copia
de la informacin (a diferencia, por ejemplo, de si se guardan copias de la
informacin en el estado de sesin o en pginas individuales).
mbito de la aplicacin El mbito del estado de aplicacin tambin puede
ser una desventaja.
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.
4.8.2 Estado de sesin

HttpSessionState como mtodo para almacenar informacin especfica de la
sesin de forma que sea visible slo dentro de sta. Informacin general sobre
la administracin de estados de ASP.NET e Informacin general sobre el estado
de sesin de ASP.NET.
Implementacin sencilla El estado de sesin es fcil de usar, es
coherente con otras clases de .NET Framework y los programadores de
ASP lo conocen bien.
Eventos especficos de la sesin Se pueden desencadenar eventos de
administracin de sesiones y utilizarlos en la aplicacin.
Persistencia de los datos Los datos guardados en variables de estado
de sesin se conservan cuando se reinician Internet Information Services
(IIS) y los procesos de trabajo sin que se pierdan datos de sesin, ya que
stos se almacenan en otro espacio de proceso.
Escalabilidad de la plataforma El estado de sesin se puede utilizar en
configuraciones multisistema y multiproceso, optimizando as los
escenarios de escalabilidad.
Compatibilidad sin cookies El estado de sesin funciona con los
exploradores que no admiten las cookies HTTP, aunque se suele utilizar
en combinacin con stas para proporcionar servicios de identificacin de
usuario a las aplicaciones Web. Administracin de sitios web 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.
4.8.3 Propiedades de perfiles

Informacin general sobre las propiedades de perfil de ASP.NET.
Persistencia de los datos Los datos situados en las propiedades de
perfiles se mantienen cuando se reinician Internet Information Services
(IIS) y el proceso de trabajo sin que se pierdan datos, porque stos estn
almacenados en un mecanismo externo.
Escalabilidad de la plataforma Las propiedades de perfiles se pueden
utilizar en configuraciones multisistema y multiproceso, optimizando as
los escenarios de escalabilidad.
Extensibilidad Para utilizar las propiedades de perfiles, debe configurar
un proveedor de perfiles. SqlProfileProvider que permite almacenar los
datos del perfil en una base de datos SQL, aunque tambin puede crear
una clase propia de proveedor de perfiles que almacene los datos del perfil
en un formato personalizado y disponga de un mecanismo de
almacenamiento personalizado, como un archivo XML o incluso un
servicio Web.
Proveedores de perfiles de ASP.NET e Implementar un proveedor de perfiles.

Consideraciones de rendimiento Las propiedades de perfiles
normalmente son ms lentas que el estado de sesin porque en lugar de
almacenar los datos en la memoria, los datos se conservan en un almacn
de datos.
Mantenimiento de los datos Las propiedades de perfiles requieren cierto
mantenimiento.
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.
4.9 Seguridad de Acceso a Datos

4.9.1 Principios bsicos de seguridad de bases de datos
Recomendaciones sobre seguridad en bases de datos, instaladas en servidores
propios de la organizacin.
4.9.2 Identifique su sensibilidad

No se puede asegurar lo que no se conoce. Confeccione un buen catlogo de
tablas o datos sensibles de sus instancias de base de datos.
Adems, automatice el proceso de identificacin, ya que estos datos y su
correspondiente ubicacin pueden estar en constante cambio debido a nuevas
aplicaciones o cambios producto de fusiones y adquisiciones.
Desarrolle o adquiera herramientas de identificacin, asegurando stas contra el
malware, colocado en su base de datos el resultado de los ataques de inyeccin
SQL; pues aparte de exponer informacin confidencial debido a vulnerabilidades,
como la inyeccin SQL, tambin facilita a los atacantes incorporar otros ataques
en el interior de la base de datos.
4.9.3 Evaluacin de la vulnerabilidad y la configuracin
Evale su configuracin de bases de datos, para asegurarse que no tiene huecos

de seguridad. Esto incluye la verificacin de la forma en que se instal la base
de datos y su sistema operativo (por ejemplo, la comprobacin privilegios de
grupos de archivo -lectura, escritura y ejecucin- de base de datos y bitcoras
de transacciones).
Asimismo con archivos con parmetros de configuracin y programas
ejecutables. Adems, es necesario verificar que no se est ejecutando la base
de datos con versiones que incluyen vulnerabilidades conocidas; as como
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.
4.9.7 Pistas de Auditora

Aplique pistas de auditora y genere trazabilidad de las actividades que afectan
la integridad de los datos, o la visualizacin los datos sensibles.
Recuerde que es un requisito de auditora, y tambin es importante para las
investigaciones forenses.
La mayora de las organizaciones en la actualidad emplean alguna forma de
manual de auditora de transacciones o aplicaciones nativas de los sistemas
gestores de bases de datos. Sin embargo, estas aplicaciones son a menudo
desactivadas, debido a:
Su complejidad
Altos costos operativos
Problemas de rendimiento
La falta de segregacin de funciones y
La necesidad mayor capacidad de almacenamiento.
Afortunadamente, se han desarrollado soluciones con un mnimo de impacto en

el rendimiento y poco costo operativo, basado en tecnologas de agente
inteligentes.
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.
4.10 Desarrollo de las Funcionalidades para Preservar la

Seguridad.
Los principios de desarrollo seguro de software que fueron utilizados en la
realizacin de los programas:
1. Se analizaron la gran mayora de amenazas que pueden afectar al
desarrollo seguro y tambin se consideraron posibles futuros ataques al
sistema como:
a). Buffer Overflow, es decir cuando un espacio de memoria pueda
ser escrito con ms informacin que la existente en este espacio
limitado causando un problema de prestacin de servicio o la
inclusin de un cdigo malicioso dentro de la ejecucin del
programa.
b). Cdigo malicioso, puede ser insertado de manera no visible
dentro de un proceso de desarrollo, para esto se consider la
proteccin tanto fsica como lgica a los ambientes de desarrollo y
controles tecnolgicos para verificar de manera que continua que
el cdigo no sea modificado durante su creacin por usuarios no
autorizados. Tambin se consideraron tcnicas que permiten por
medio de una operacin matemtica calcular un cdigo que nos
informa que la integridad del programa ha sido o no afectada. La
arquitectura por capas, fundamento de nuestro desarrollo, permite
Pgina 69
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.
4.11 Resiliencia y control de las aplicaciones.

En sistemas tecnolgicos, la resiliencia es la capacidad de un sistema de
soportar y recuperarse ante desastres y perturbaciones;
En ecologa, la resiliencia es la capacidad de las comunidades de
soportar, adaptarse y recuperarse a perturbaciones ambientales
adquiriendo nuevas herramientas.
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
_______________________________________________________________
5.1 Pruebas Funcionales

Se denominan pruebas funcionales o Functional Testing, a las pruebas de
software que tienen por objetivo probar que los sistemas desarrollados, cumplan
con las funciones especficas para los cuales han sido creados, es comn que
este tipo de pruebas sean desarrolladas por analistas de pruebas con apoyo de
algunos usuarios finales, esta etapa suele ser la ltima etapa de pruebas y al dar
conformidad sobre esta el paso siguiente es el pase a produccin.
Estas estn basadas en la ejecucin, revisin y retroalimentacin de las
funcionalidades previamente diseadas para el software. Las pruebas
funcionales se hacen mediante el diseo de modelos de prueba que buscan
evaluar cada una de las opciones con las que cuenta el paquete informtico.
Dicho de otro modo son pruebas especficas, concretas y exhaustivas para
probar y validar que el software hace lo que debe y sobre todo, lo que se ha
especificado.
5.1.1 Pruebas de las Funcionalidades de Seguridad de los Sistemas
Entre el tipo de pruebas que se realiza en un sistema est el tipo que evala la
funcionalidad de ste.
Prueba Funcional.
Objetivo:
Se asegura el trabajo apropiado de los requisitos funcionales, incluyendo

la navegacin, entrada de datos, procesamiento y obtencin de
resultados.
Metas de estas pruebas son:
Verificar el procesamiento, recuperacin e implementacin adecuada de

las reglas del negocio.
Verificar la apropiada aceptacin de datos.
Enfoque:
Pgina 73
UNIDAD 5
_______________________________________________________________
Los requisitos funcionales (Casos de Uso) y las reglas del negocio.
Prueba de Seguridad.
Tcnica: Caja Negra.
Se ejecuta cada caso de uso, flujo de caso de uso, o funcin, usando

datos vlidos e invlidos, para verificar lo siguiente:
Que se aplique apropiadamente cada regla de negocio.
Que los resultados esperados ocurran cuando se usen datos vlidos.
Que sean desplegados los mensajes apropiados de error y precaucin

cuando se usan datos invlidos.
Objetivo:
Nivel de Seguridad de la Aplicacin: Verifica que un actor solo pueda

acceder a las funciones y datos que su usuario tiene permitido.
Nivel de Seguridad del Sistema: Verificar que solo los actores con acceso
al sistema y a la aplicacin estn habilitados para accederla.
reas:
Seguridad del sistema, incluyendo acceso a datos o Funciones de

negocios.
Seguridad del sistema, incluyendo ingresos y accesos remotos al sistema.
Garantiza:
Que los usuarios estn restringidos a funciones especficas o su acceso

est limitado nicamente a los datos que est autorizado a acceder.
Que solo aquellos usuarios autorizados a acceder al sistema son capaces

de ejecutar las funciones del sistema.
Objetivos especficos de seguridad de cada sistema.
Tcnicas:
Identificar cada tipo de usuario y las funciones y datos a los que se debe
autorizar.
Pgina 74
UNIDAD 5
_______________________________________________________________
Prueba de Volumen.
Objetivo:
Verificar que la aplicacin funciona adecuadamente bajo los siguientes
escenarios de volumen:
Mximo (actual o fsicamente posible) nmero de clientes conectados (o

simulados), todos ejecutando la misma funcin (peor caso de desempeo)
por un perodo extendido.
Mximo tamao de base de datos (actual o escalado) y mltiples

consultas ejecutadas simultneamente.
Tcnica.
Usar mltiples clientes, corriendo las mismas pruebas o pruebas

complementarias para producir el peor caso de volumen por un perodo
extendido.
Utilizar un tamao mximo de Base de datos (actual o con datos

representativos)
mltiples
clientes
para
correr
consultas
simultneamente para perodos extendidos.

Criterio de Completitud.
Todas las pruebas planeadas han sido ejecutadas y los lmites

especificados en el sistema se han conseguido o excedido sin que el
sistema falle.
5.2 Aceptacin del Software

El uso de cualquier producto de software tiene que estar justificado por las
ventajas que ofrece. Sin embargo, antes de empezar a usarlo es muy difcil
determinar si sus ventajas realmente justifican su uso. El mejor instrumento para
esta determinacin es la llamada 'prueba de aceptacin'. En esta prueba se
evala el grado de calidad del software con relacin a todos los aspectos
relevantes para que el uso del producto se justifique.
Pgina 75
UNIDAD 5
_______________________________________________________________
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.
Para la preparacin, la ejecucin y la evaluacin de la prueba de aceptacin ni

siquiera hacen falta conocimientos informticos. Sin embargo, un conocimiento
amplio de mtodos y tcnicas de prueba y de la gestin de la calidad en general
facilitan esta labor.
La persona adecuada (o el equipo adecuado) para llevar a cabo la prueba de

aceptacin dispone de estos conocimientos y adems es capaz de interpretar
los requerimientos especificados por los futuros usuarios del sistema de software
en cuestin.
5.3 Seguridad en las Operaciones de Software

La creencia habitual de un equipo de trabajo de que su tarea ha finalizado
cuando instala y pone en funcionamiento el software en las instalaciones del
cliente no puede ser ms errnea. Un producto software envuelve muchos
aspectos y caractersticas que provocan que sea totalmente necesario
supervisar su funcionamiento correcto durante un tiempo despus de la entrega
del mismo. Ante la dificultad que entraa garantizar el comportamiento correcto
del programa en circunstancias no previstas, los test de aceptacin del producto
incluyen pruebas a largo plazo del software (a peticin del cliente). A esta fase
de supervisin se le denomina fase de operacin.
Pgina 76
UNIDAD 5
_______________________________________________________________
FIGURA 9. Seguridad en las operaciones del software
5.3.1 Mantenimiento y Operacin del Software

Muchos equipos de trabajo tiende a creer que su misin ha terminado cuando el
software esta instalado y funcionando en las instalaciones del cliente y sin
embargo es rara vez as. Hacen que sea necesario supervisar el correcto
funcionamiento del mismo durante bastante tiempo despus de haber sido
entregado.
Slo cuando termina esta fase el cliente acepta definitivamente el producto, que
haba sido aceptado provisionalmente al ser entregado (fase de transferencia).
Ms tarde, es posible que el software necesite ser modificado, ya sea
consecuencia de la deteccin de errores o bien ante nuevas exigencias y/o
necesidades del usuario del sistema. A esta fase se le conoce como fase de
mantenimiento. Es importante resear que durante estas fases de operacin y
mantenimiento (OM) se debe generar y actualizar el denominado documento
de historia del proyecto (DHP); documento que incluye todos los errores (y sus
correcciones) y/o modificaciones realizadas en el producto.
Pgina 77
UNIDAD 5
_______________________________________________________________
Entre las caractersticas sobresalientes del mantenimiento del software

destacan:
- El software no envejece.
- El mantenimiento del software supone adaptar el paquete o sistema objeto del
mismo a nuevas situaciones como:
Cambio de hardware.
Cambio de software de base (S.O.).
- Todo sistema software conlleva mejoras o aadidos indefinidamente.
Las fases principales en el Ciclo de Vida del Software son:
- Anlisis y Definicin de Requisitos.
- Especificacin.
- Diseo.
- Programacin (escritura del cdigo).
- Prueba e instalacin.
- Operacin y mantenimiento.
Software Product Evaluation: Quality Characteristics and Guidelines for their
Use. Publicado en 1991, se divide en dos estndares separados:
- El nuevo ISO/IEC 9126, llamado Software Quality Characteristics and Metrics,
al que nos referiremos a continuacin.
- ISO/IEC 14598, llamado Software Product Evaluation.
La mantenibilidad se define como la capacidad de un producto software para ser

modificado. Se subdivide en 5 subcaractersticas:
Analizabilidad: Capacidad del producto software de diagnosticar sus
deficiencias o causas de fallos, o de identificar las partes que deben ser
modificadas.
Cambiabilidad: Capacidad del producto software de permitir implementar una
modificacin previamente especificada.
Estabilidad: Capacidad del producto software de minimizar los efectos
inesperados de las modificaciones.
Pgina 78
UNIDAD 5
_______________________________________________________________
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
_______________________________________________________________
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

Monografia Desarrllo de Software Seguro

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Monografia Desarrllo de Software Seguro

Caricato da

Copyright:

Formati disponibili

SEP

CD. Y PUERTO DE LZARO CRDENAS, MICHOACN.

1.2. Controles de Seguridad de la Informacin. ____________________________ 11

1.3. Problemas de Seguridad._____________________________________________ 14

1.4. Principios de Seguridad. _____________________________________________ 16

ANLISIS DEL SOFTWARE SEGURO. ________________________________ 17

2.3 ANLISIS DE LOS REQUERIMIENTOS DE SEGURIDAD. _________________ 39

DISEO DE SOFTWARE SEGURO ___________________________________ 42

PROGRAMACIN SEGURA _________________________________________ 54

4.6 Validacin de Input y Limpieza de Output ______________________________ 62

4.7 Registro de Datos (Logging) __________________________________________ 62

4.9 Seguridad de Acceso a Datos _________________________________________ 66

4.10 Desarrollo de las Funcionalidades para Preservar la Seguridad. ________ 69

PRUEBAS DE SEGURIDAD DE SOFTWARE __________________________ 72

5.2 Aceptacin del Software ______________________________________________ 75

5.3 Seguridad en las Operaciones de Software _____________________________ 76

Entre las diferencias de seguridad entre un Software Libre y el Software

-Seguridad en el Software Libre: Por su carcter pblico y su crecimiento

Al trmino del curso de seguridad podrs desarrollar habilidades con el fin de

1.1 Introduccin a la Seguridad de Aplicaciones.

COMMON CRITERIA o CC (ISO/IEC 15408:1999): estndar internacional para

La seguridad de las aplicaciones se suele contemplar en las ltimas fases del

Figura 1 Seguridad en el desarrollo

La seguridad en las aplicaciones va ms all de controlar el acceso utilizando

1.1.1 Introduccin a la seguridad informtica

Riesgo = (amenaza * vulnerabilidad) / contramedida

Las contramedidas que deben implementarse no slo son soluciones tcnicas,

1.1.3 Objetivos de la seguridad informtica

Generalmente, la seguridad informtica consiste en garantizar que el material y

La seguridad informtica se resume, por lo general, en cinco objetivos

1.2. Controles de Seguridad de la Informacin.

Hay que destacar que existe diferencia entre la Seguridad de la Informacin y la

A veces se tiene el concepto de que las amenazas de seguridad slo alcanzan

Lo anterior debe motivar a las organizaciones a implementar medidas de

La seguridad de la informacin la ven como un tema normal, lo que hace que no

proteccin, hasta que no sucede un siniestro o desastre, lo cual puede ser

Para la implementacin y desarrollo de la seguridad de la informacin, se utilizan

Es recomendable que para la implementacin de un sistema de gestin de la

1.3. Problemas de Seguridad.

Figura 2 Definicin de riesgo

Conforme la tecnologa avanza, el nivel de los problemas de seguridad

Existen diferentes vulnerabilidades a las que las organizaciones y personas se

Figura 3Estadisticas del nivel de riesgos.

Figura 4 Grafica de evaluacin.

Inyecciones, etc. Suelen ser de muy rpida propagacin y siempre se basan en

ANALISIS DEL SOFTWARE SEGURO

ANALISIS DEL SOFTWARE SEGURO

ANALISIS DEL SOFTWARE SEGURO

2.1 HERRAMIENTAS DE ANLISIS DEL SOFTWARE SEGURO.

ANALISIS DEL SOFTWARE SEGURO

2.1.2 Herramientas de anlisis de software.

Nessus es un escner de seguridad remoto para Linux, BSD, Solaris y Otros

bsqueda/identificacin de contenido y puede ser utilizado para detectar una

Netcat: La navaja multiuso para redes.

ANALISIS DEL SOFTWARE SEGURO

Casi cualquier tipo de conexin que podamos necesitar y tiene muchas

TCPDump / WinDump: El sniffer clsico para monitoreo de redes y adquisicin

Whisker/Libwhisker: El escner y la biblioteca de vulnerabilidades de CGI de

ANALISIS DEL SOFTWARE SEGURO

John the Ripper: Un extraordinariamente poderoso, flexible y rpido cracker de

OpenSSH / SSH: Una manera segura de acceder a computadoras remotas.Un

Sam Spade: Herramienta de consulta de redes de distribucin gratuita.

ANALISIS DEL SOFTWARE SEGURO