UNIVERSIDAD AUTÓNOMA DE CHIHUAHUA.

TEMA: 1.17 TAREA PRESENTACIÓN

ADMINISTRACIÓN DE RIESGOS.

INGENIERÍA EN SOFTWARE MODALIDAD VIRTUAL.

MATERIA: SEGURIDAD DE SOFTWARE 7SC.

MAESTRO: ÓSCAR CÁRDENAS MORALES.

ALUMNO: JOSE JAVIER MACIAS MUÑOZ.

MATRICULA: a314787 FECHA DE ELABORACIÓN 16-02-2018

GESTIÓN DE RIESGOS.

• Es un enfoque estructurado para manejar la incertidumbre

relativa a una amenaza, a través de una secuencia de actividades
humanas las cuales son.
• Identificación de riesgos.
• Estimación de riesgos.
• Plan de riesgos.
¿ QUE ES EL RIESGO?

• El riesgo se define como la probabilidad de que una

amenaza se convierta en un desastre.

• Todo cambio implica riesgo.

• El riesgo implica elección e incertidumbre.
GESTIÓN DE RIESGOS DE SOFTWARE.

• El requisito más importante para la administración de

riesgos de software es adoptar una metodología de
ingeniería de software de alta calidad que permita
buenas prácticas de gestión de riesgos, la metodología
principal es el modelo espiral.
 MODELO EN ESPIRAL.
• El desarrollo del modelo en espiral es el mejor. Sin
embargo, la idea es ir en espiral hacia el objetivo final,
que generalmente es un producto completo y sólido. Gran
parte de la repetición en el modelo espiral a menudo se
reduce y a refinar su producto en base a nuevas
experiencias.

• En el modelo en espiral actividades:

• La primera actividad es derivar un conjunto de requisitos
los cuales son esenciales. Desde el punto de vista de la
seguridad, se le debe de dedicar tiempo y esfuerzos para
que se cumpla la seguridad como tema.
• La segunda actividad es identificar su mayor riesgo y evaluar
estrategias para resolver esos riesgos. En esta etapa, se
considera que es bueno realizar un análisis de seguridad
completo para garantizar que se aborde la seguridad.

• Un ejercicio de gestión de riesgos puede comenzar en

cualquier momento durante el ciclo de vida general del
software, es probable que haya algo de contaminación en el
ciclo de vida y haga que el software sea muy costosa.

• En el ciclo de vida en donde comienza la administración del

riesgo del software, todos los artefactos existentes y las
partes interesadas involucradas se pueden usar como recursos
para identificar el riesgo del software. Documentos de
requisitos , los documentos de arquitectura y diseño, los
modelos, cualquier código existente e incluso los casos de
prueba son artefactos útiles.
• Los riesgos se abordan a menudo a través de la creación
de prototipos, y se puede realizar cierta validación para
garantizar que una posible solución que gestione los
riesgos de forma apropiada.
• Cualquier solución se integra en el estado actual de las
cosas; quizás el código será modificado, quizás el diseño y
los requisitos se actualizarán.
• La clave del modelo espiral es que se aplica en
iteraciones locales en cada hito durante las fases del ciclo
de vida del software.
• Cada ciclo de gestión de riesgos implica la aplicación de
la misma serie de pasos, iteraciones locales del riesgo de
gestión del ciclo en un nivel más refinado y se aplica
específicamente al ciclo de vida.
• Como resultado, los proyectos se vuelven más
resistentes a cualquier problema que surja en el
camino.

• Este modelo contrasta fuertemente con el modelo de

cascada el más antiguo o clasico de los modelos, que
tiene todo el desarrollo en orden se basa en un
intento de formalizar el desarrollo de software pero
es muy repetitivo.

• La creación de software seguro se basa en gran

medida en la disciplina de la ingeniería de software
mediante métodos que funcionan haciendo uso de
artefactos(documentacion) de ingeniería críticos.
 EL ROL DEL PERSONAL DE SEGURIDAD.
Uno de los problemas que se encuentran en el mundo real
es la desconexión entre lo que llamamos "bandas errantes
de desarrolladores" y el departamento de seguridad del
departamento de tecnología de la información.
La seguridad se integra de manera directa en las
metodologías de ingeniería de software, aún requiere
tiempo y experiencia.
Un enfoque factible para cerrar la brecha es hacer que la
seguridad del software sea el trabajo de alguien. El truco
es encontrar a la persona correcta.
Se requieren dos calificaciones principales para un líder de
seguridad de software:

• (1) una comprensión profunda del desarrollo de software.

• (2) una comprensión de la seguridad.

De estos dos, la primera calificación es probablemente la más

importante.
Las ventajas de un desarrollador.
• Escuchar a personas que puedan ayudar al proyecto.
• Un especialista en seguridad de software debe actuar como
recurso para el desarrollo
• los desarrolladores y arquitectos deben tener motivos para
respetar el cuerpo de conocimientos que la persona aporta al
trabajo.
• Es más probable que se consulte un recurso útil al principio de
un proyecto durante las fases de diseño y arquitectura que es
cuando se puede lograr lo mejor.

Los desventajas de un desarrollador.

• Solo desarrollan y no contemplar las verificaciones de los
requisitos.
• Son tomados como un punto critico en el éxito de la seguridad
de software.
• ven las verificaciones como un obstáculo a vencer
Cualidades del personal de seguridad.
• la persona a cargo de la seguridad del software debe de conoser el
proyecto y su desarrollo.
• Un profesional de seguridad de software también necesita saber
sobre seguridad (bajo su experiencia).
• El o ella debe ser el recurso principal para desarrolladores y
arquitectos, constituyendo un recurso de primer nivel.
• El personal de seguridad debe de ayuda a las personas en un
proyecto a cumplir este objetivo sin ser visto como un impuesto u
obstáculo.
 PERSONAL DE SEGURIDAD DE SOFTWARE EN EL
CICLO DE VIDA.

• El personal de seguridad de software él o ella debe ser responsable de

asegurarse de que la seguridad esté representada de manera justa
durante cada fase del ciclo de vida del software.
• Este ingeniero podría ser líder o podría ser otro individuo. Durante cada
fase, debe ser la mejor persona (o personas) disponible para el trabajo.
 EVALUACIÓN DE RIESGOS.

• Un enfoque eficaz basado en el riesgo requiere un conocimiento

experto de la seguridad. El administrador de riesgos debe ser
capaz de identificar situaciones en las que los ataques conocidos
podrían aplicarse potencialmente al sistema, ya que pocos ataques
totalmente únicos se le ocurren.
• La identificación del riesgo funciona mejor cuando se tiene una
especificación detallada del trabajo de un sistema.
• En cómo se espera que el sistema actúe en circunstancias
particulares.
• Cuando las especificaciones están en el centro de desarrollo, y no
en papel, todo el proceso se vuelve mucho más complicado y
tedioso.
• Una vez que se han identificado los riesgos, el próximo paso es
clasificar los riesgos en orden de gravedad.

• La clasificación de los riesgos es esencial para asignar los recursos

de prueba y análisis más adelante, porque la asignación de
recursos es un problema comercial, por lo que las buenas
decisiones comerciales con respecto a dicha asignación requieren
datos sólidos.
• EJEMPLO DE COMO VERÍA LA ADMINISTRACIÓN DEL RIEGOS SI USTED
ESTUVIERA A CARGO DEL EQUIPO DE DESARROLLO Y TRABAJANDO EN
UN PROYECTO, QUE ES LO QUE HARÍA, COMO LO HARÍA Y PORQUE.
• Primero tendría que captar los requerimientos del cliente o
usuario para determinar un análisis de requerimientos para
captar junto el cliente lo necesario para crear el proyecto
porque todo debe de estar documentándolo.
• Determinar un plan de desarrollo, determinar el diseño del
software y la seguridad que deberá llevar por ejemplo en el
tamaño del sistema o producto, si va llevar modificaciones o
se va diseñar desde cero esto con el fin de determinar con
lo que se cuenta para su modificación o creación por
ejemplo base de datos o información que se maneja
tomando en cuenta lo siguiente para el desarrollo y llevar
acabo el software o proyecto como lo es.
• Determinar el tamaño del software y los riesgos general
por construir o modificarlo para establecer los alcances y
limitaciones que se pueden tener al momento de crear.
• Impacto que va generar en la empresa o negocio y las
limitaciones que se pueden tener, esto respecto en como
va a beneficiar y como esque se va restringir los procesos
que se realizan.
• Riesgo de falta de comunicación con el cliente y su
inconformidad con el proyecto esto debe de ser evitado
para llevar acabo un sistema exitoso.
• Riesgos asociados con la organización del desarrollo del
proyecto se debe de llevar una organización bien sentrada
en los procesos y la comunicación con el equipo.
• Disponibilidad y calidad de las herramientas para la
construcción del software y el riesgo que lleva para eso se
debe de contar con todo lo necesario para llevarlo acabo.
• Complejidad del riesgo del sistema al construirlo y la
tecnología que se va a utilizar en los proyectos.
• La experiencia del personal del equipo para realizar el proyecto.

Tratando de delimitar y minimizar los riesgos del software mediante

cada una de las etapas de la planeación y desarrollo.
Además de documentar todo lo posible en cada una de las etapas y
cada uno de los procesos para un determinado uso en un futuro para
el riesgo que se pueda tener durante las etapas de implementación y
mantenimiento o pruebas y mantenimiento.

Eso es lo que aria en la administración de riegos si yo estuviera a

cargo del equipo de desarrollo.
Y lo llevaría acabo asi por el hecho de que es una forma de tener
el éxito en el proyecto limitando los riesgos que este puede
presentar en el equipo de desarrollo y en el software en si.
CONCLUSIÓN:

• La gestión de riesgos va ligada al desarrollo y creación del software y va

jugando un papel importante en cada una de las etapas.
• Se va desarrollando de tal forma, que se tiene la interacción y la
comunicación con el cliente y con el equipo de trabajo.
• Se mide el riesgo en toda la vida del software y las soluciones de cada
aspecto del mismo.
• Se tiene que documentar cada proceso en la creación o modificación del
software.
• El equipo de trabajo de desarrollo deben de tener los conocimientos
necesarios para llevar acabo la creación y modificación del software.
Gracias por su atención.