Error: Es una equivocación cometida por el desarrollador.

Algunos ejemplos de errores son: un error de digitación, una malinterpretación de un

requerimiento o de la funcionalidad de un método. El estándar 829 de la IEEE coincide
con la definición de diccionario de error como "una idea falsa o equivocada". Por tal razón
un programa no puede tener o estar en un error, ya que los programas no tienen ideas;
las ideas las tienen la gente.
Defecto: Un defecto se encuentra en un artefacto y puede definirse como una diferencia
entre la versión correcta del artefacto y una versión incorrecta. Coincide con la definición
de diccionario, "imperfección".
Imperfección en un componente o sistema que puede causar que el componente o
sistema falle en desempeñar las funciones requeridas. Por ejemplo, si se localiza un
defecto durante una ejecución puede causar un fallo en el componente o sistema, por
ejemplo una sentencia o una definición de datos incorrecta.
Falla: En terminología IEEE, una falla es la discrepancia visible que se produce al ejecutar
un programa con un defecto, el cual es incapaz de funcionar correctamente (no sigue su
curso normal).
Manifestación física o funcional de un defecto, por ejemplo, desviación de un componente
o sistema respecto de la presentación, servicio o resultado esperado
Vulnerabilidad. Una vulnerabilidad es una debilidad que puede ser ‘activada’ de forma
accidental o intencionadamente. Es un factor de riesgo interno de un elemento expuesto a
una amenaza de ser susceptible a sufrir un daño y de encontrar dificultades en
recuperarse posteriormente. Debilidad o grado de exposición de un sujeto, objeto o
sistema.
Por ejemplo, cuentas de usuarios sin contraseña; el personal externo no registra su
entrada y salida a las instalaciones; falta de directrices para la construcción de
contraseñas; no hay un software de control de accesos; no contar con un plan de
recuperación de desastres.
Amenza. Es la posibilidad de que se produzca una determinada vulnerabilidad de forma
satisfactoria. Es una circunstancia o evento con la capacidad de causar daño a un
sistema, entendiendo como daño una forma de destrucción, revelación o modificación de
datos. Potencial ocurrencia de un hecho que pueda manifestarse en un lugar específico,
con una duración e intensidad determinadas. Materialización del riesgo.
Ejemplos:
- Naturales: Terremotos que destruyan el centro de cómputo.
- Humanas: Fraude realizado al modificar los saldos de cuentas por cobrar.
-Software: Cambios no autorizados al sistema que realicen cálculos incorrectos.
Riesgo. Un riesgo de un proyecto es un evento o condición incierto que, si se produce,
tendrá un efecto positivo o negativo sobre al menos un objetivo del proyecto, como
tiempo, coste, alcance o calidad.
La Norma ISO/IEC-27002 lo define como la combinación de la probabilidad de ocurrencia
de un determinado hecho y sus consecuencias.
- un evento definible
- probabilidad de ocurrencia
- consecuencia de la ocurrencia (impacto)
• RIESGO: (Inglés: Risk). Posibilidad de que una amenaza concreta pueda explotar una
vulnerabilidad para causar una pérdida o daño en un activo de información. Según [ISO
Guía 73:2002]: combinación de la probabilidad de un evento y sus consecuencias.
• AMENAZA: (Inglés: Threat). Según [ISO/IEC 13335-1:2004]: causa potencial de un
incidente no deseado, el cual puede causar el daño a un sistema o la organización.
• VULNERABILIDAD: (Inglés: Vulnerability). Debilidad en la seguridad de la información
de una organización que potencialmente permite que una amenaza afecte a un activo.
Según [ISO/IEC 13335-1:2004]: debilidad de un activo o conjunto de activos que puede
ser explotado por una amenaza.
De la lectura de la definición de vulnerabilidad, así como la mención en la propia ISO
27001:2005, cuando habla de “identificar los riesgos” (4.2.1.d) y dice “identificar las
vulnerabilidades bajo las que podrían actuar dichas amenazas”, se entiende que la
vulnerabilidad nunca es la consecuencia de la amenaza, sino una situación existente que
pudiera ser aprovechada (explotada) por una determinada amenaza.

Los tres conceptos coexisten entre si, la vulnerabilidad es el hecho real de que un sistema
pueda ser hackeado, dañado o destruido debido al grado de exposición a sufrir este daño
por la manifestación de una amenaza especifica, La amenaza es el factor que causa un
daño al sistema informatico, llamese hardware o software, una amenaza es un incendio,
terremoto, la amenaza por lo general es meteorologica, sismica o social y algo que
comunmente escapa del control de la seguridad informatica, El riesgo es la probabilidad
de que pase algo, tomando las variables flotantes anteriores.
Vulnerabilidad es el factor que permite que una amenaza se plasme, es decir, algo que no
hacemos o estamos haciendo mal, por ejemplo, la carencia de parches de seguridad en
un SO o no tener detectores de humo en el Centro de Datos, la amenaza es el hecho,
interno o externo, que puede alterar la Confdencialidad, Disponibilidad o intengridad de la
informacion, por ejemplo, un ataque de DoS, un incendio, un terremoto, etc. Y el riesgo es
la consecuencia que conlleva a la perdidad de continudiad o la vulneracion de al
seguridad, por ejemplo, robo de informacion, corte del servicio, etc.
Activo: cualquier recurso de la empresa necesario para desempeñar las actividades
diarias y cuya no disponibilidad o deterioro supone un agravio o coste. La naturaleza de
los activos dependerá de la empresa, pero su protección es el fin último de la gestión de
riesgos. La valoración de los activos es importante para la evaluación de la magnitud del
riesgo.

Análisis de riesgo: que consiste en averiguar el nivel de riesgo que la empresa está
soportando. Para ello, tradicionalmente las metodologías proponen que se realice un
inventario de activos, se determinen las amenazas, las probabilidades de que ocurran y
los posibles impactos
PMBoK. Guía de los fundamentos para la dirección de proyectos
1.Identificación del Riesgo: El análisis más complejo y completo nunca podrá
analizar todas las variables de riesgo que existen en un proyecto.
2.Cuantificación del Riesgo: Consiste en determinar qué riesgos tienen
probabilidad de afectar el desarrollo del proyecto y documentar las
características de cada uno.
3.Desarrollo de Respuesta al Riesgo: Consiste en evaluar el riesgo, las
repercusiones del mismo y su interacción con los resultados del proyecto.
Incluye determinar cuantitativamente el riesgo mismo. Es la fase más
complicada del proceso de gestión del riesgo.
4.Control de Respuesta al Riesgo:
Es el proceso que define los pasos a seguir en el momento en que se
presentan las amenazas y las oportunidades del proyecto con base en
los eventos de riesgo.
Involucra ejecutar el plan de control del riesgo de manera que se de
respuesta a los eventos de riesgo en el transcurso del proyecto.

1. Planificar la Gestión de Riesgos

2. Identificar los Riesgos
Identificar los Riesgos es el proceso por el cual se determinan los riesgos que pueden
afectar el proyecto y se documentan sus características.
es un proceso iterativo debido a que se pueden descubrir nuevos riesgos o pueden
evolucionar conforme el proyecto avanza a lo largo de su ciclo de vida.
3. Realizar el Análisis Cualitativo de Riesgos
el proceso que consiste en priorizar los riesgos para realizar otros análisis o acciones
posteriores, evaluando y combinando la probabilidad de ocurrencia y el impacto de
dichos riesgos
4. Realizar el Análisis Cuantitativo de Riesgos
es el proceso que consiste en analizar numéricamente el efecto de los riesgos
identificados sobre los objetivos generales del proyecto.
5. Planificar la Respuesta a los Riesgos
Planificar la Respuesta a los Riesgos es el proceso por el cual se desarrollan opciones y
acciones para mejorar las oportunidades y reducir las amenazas a los objetivos del
proyecto. Se realiza después de los procesos
6. Monitorear y Controlar los Riesgos
Monitorear y Controlar los Riesgos es el proceso por el cual se implementan planes de
respuesta a los riesgos, se rastrean los riesgos identificados, se monitorean los riesgos
residuales, se identifican nuevos riesgos y se evalúa la efectividad del proceso contra los
riesgos a través del proyecto.

Oracle Primavera, Microsoft Project 2018, WorkProject, Slack, Scrum

Alcance de la evaluación: el primer paso siempre es entender lo que está en juego. La
identificación de los activos tangibles, como bases de datos o archivos confidenciales o
sensible, usualmente es fácil. La comprensión de las capacidades proporcionadas por la
aplicación y la valoración de estas es más difícil. Cosas menos concretas, tales como la
reputación y el renombre comercial son los más difíciles de medir, pero a menudo son los
más críticos.
Identificar agentes de amenaza y posibles ataques: una parte fundamental del
modelado de amenazas es una caracterización de los diferentes grupos de personas que
podrían ser capaces de atacar a la aplicación. Estos grupos deben incluir elementos
internos y externos, y la realización de ambos, errores involuntarios y ataques maliciosos.
Entender contramedidas existentes: el modelo debe incluir las contramedidas
existentes.
Identificar las vulnerabilidades explotables: una vez que se tiene una comprensión de
la seguridad en la aplicación, luego se podrán analizar las nuevas vulnerabilidades. La
búsqueda es para las vulnerabilidades que se relacionan a los posibles ataques y las
consecuencias negativas que se han identificado.
Identificar riesgos prioritarios: la priorización es todo en el modelado de amenazas ya
que siempre hay muchos riesgos que simplemente no merecen ninguna atención. Para
cada amenaza, se debe estimar una probabilidad y factor de impacto para determinar el
riesgo general o el nivel de gravedad.
Identificar las contramedidas para reducir la amenaza: el último paso consiste en
identificar las contramedidas para reducir el riesgo a niveles aceptables.

Equipo de Respuesta ante Incidentes de Seguridad Informática

Equipo Rojo
Se encarga de estudiar el comportamiento de los cibercriminales y los principales
vectores de ataque,

uno de defensa (equipo azul), cuyo objetivo es analizar el tráfico de las

redes para estar alertas ante la presencia de una eventualidad informática.