Una guía metodológica para el cálculo del retorno a la

inversión (ROI) en seguridad informática

Nicolás Sánchez Acevedo* Juan Sebastián Segura Castañeda♠

Tabla de Contenido
1. Introducción
1.1. El problema
1.2. Estudio base de la investigación
1.3. Pregunta de investigación y objetivos
1.4. Importancia de la investigación

2. Revisión de Literatura
2.1. Historia y evolución de la Seguridad Informática
2.2. Conceptos y modelos Actuales de la Seguridad Informática
2.2.1. Objetivos de la Seguridad Informática
2.2.2. Principios de la Seguridad Informática
2.2.2.1. Confidencialidad
2.2.2.2. Integridad
2.2.2.3. Disponibilidad
2.2.3. Servicios de la Seguridad Informática
2.2.3.1. Autenticación
2.2.3.2. Autorización
2.2.3.3. No repudio
2.2.3.4. Auditabilidad
2.2.4. Definición de Seguridad Informática
2.3. Definición de Seguridad Informática
2.4. Retorno a la Inversión (ROI) en Seguridad Informática
2.4.1. Modelos propuestos para el cálculo del ROI en seguridad informática

3. Análisis Preliminar
3.1. Introducción
3.2. Administración de Riesgos
3.2.1. ¿Cómo favorece o aporta la Administración de Riesgos en el proceso
investigativo del Cálculo de ROI en seguridad informática?
3.3. Métricas en Seguridad Informática

4. Modelo propuesto para el retorno de la inversión

4.1. Introducción
4.2. Explicación del Modelo

5. Guía Metodológica
5.1. Introducción
5.2. Caracterización del ejemplo a desarrollar

*
nicolas.sanchez@javeriana.edu.co
♠
juan.segura@javeriana.edu.co

1
 5.3. Guía metodológica para el cálculo del retorno de la inversión en seguridad informática
(ROSI)
5.3.1. Proceso No.1: Análisis de riesgos
5.3.1.1. Caracterización de la organización
5.3.1.2. Identificación de amenazas
5.3.1.3. Identificación de vulnerabilidades
5.3.1.4. Análisis de controles existentes
5.3.1.5. Determinación del número de ocurrencias
5.3.1.6. Determinación del impacto
5.3.1.7. Determinación del nivel de riesgo
5.3.1.8. Recomendaciones de control
5.3.2. Proceso No.2: Estimación del ROSI
5.3.2.1. Estimación para el año 1
5.3.2.2. Estimación para el año 2 en adelante

6. Conclusión
7. Referencias

2
 Una guía metodológica para el cálculo del retorno a la
inversión (ROI) en seguridad informática

Nicolás Sánchez Acevedo* Juan Sebastián Segura Castañeda♠

Resumen

El presente documento presenta los avances de la investigaciones adelantadas sobre el cálculo del
retorno de la inversión en seguridad informática, para lo cual se ha revisado la evolución de la
seguridad de la información, los conceptos generales de la seguridad informática y los elementos
asociados con el retorno de la inversión, los cuales serán utilizados para plantear una alternativa
para la estimación del ROI. La alternativa planteada fue revisada a la luz de conceptos como la
administración de riesgos y las métricas de seguridad, las cuales deben ser refinadas de acuerdo
con los criterios de negocio que se plantean en las organizaciones. En los últimos capítulos de
este documento, se presentan los detalles del modelo propuesto, y una guía metodológica
propuesta para el fin ya descrito.

Palabras claves: seguridad informática, retorno, inversión, ROI, administración de riesgos, análisis de
riesgos, métricas.

1 Introducción

1.1 El problema
Muchas organizaciones hoy en día, son amenazadas constantemente en sus activos, lo que puede
representar miles o millones de dólares en pérdidas [HARR03]. Las vulnerabilidades en los
sistemas de información pueden representar problemas graves, por ello es muy importante que las
empresas contemporáneas comprendan los conceptos necesarios para combatir y defenderse de los
posibles ataques a su información.

En la actualidad, la información es el bien de mayor valor para las empresas [ALSI05]. El progreso
de la informática y de las redes de comunicación no sólo ha sido un beneficio para las mismas,
debido a que tienen mayores niveles de sistematización, sino que generan un mayor nivel de
prevención y responsabilidad frente a las amenazas sobre dicha información.

La seguridad de la información tiene como propósito proteger la información organizacional,

independiente del lugar en donde se encuentre, ya que esta se puede encontrar en diferentes medios
como por ejemplo en papel impreso, en los discos duros o incluso en la memoria de las personas
que la conocen [ALSI05]. Por esto, la seguridad de la información es un asunto importante para
todos, pues afecta directamente a los negocios de una empresa como a los individuos que hacen
parte de ella.

Es por ello que hoy en día las empresas buscan la mejor forma de asegurar la organización y los
recursos de la misma. En consecuencia surgen, tanto las empresas dedicadas a la seguridad
informática y a los servicios de consultoría para el aseguramiento de los recursos tecnológicos y

*
nicolas.sanchez@javeriana.edu.co
♠
juan.segura@javeriana.edu.co

3
humanos que se ven involucrados en la organización, como los departamentos encargados de la
seguridad de tecnología de información de las organizaciones. En ambos casos, es creciente la
necesidad de establecer formas para justificar frente a los clientes, o a la alta gerencia, las
ganancias o beneficios que se pueden llegar a obtener al implementar un proyecto de seguridad de
la información realizando las respectivas inversiones en ellos [WILS03].

Existen algunas iniciativas de guías, modelos, estándares, metodologías definidas que permiten
calcular los beneficios (tangibles e intangibles) que la organización podría percibir por concepto de
una inversión realizada en seguridad informática [SCHW03], es decir el ROI de la seguridad
informática, pero generalmente son de uso privado y es necesario pagar por ellas. Por tanto, y
considerando estos esfuerzos iniciales, se plantea esta investigación para proponer una guía
metodológica abierta a la comunidad para sugerir una manera básica de calcular el retorno a la
inversión en seguridad informática.

1.2 Estudio base de la investigación

Cuando se habla del retorno a la inversión, en cualquier área del conocimiento, se hace referencia
al rendimiento o ganancia que una o más inversiones, retorna en un momento dado, y que es más
rentable que no haber hecho dichas inversiones. De esta manera, al referirse al retorno a la
inversión en seguridad informática, se está hablando de todas las inversiones que encierra esta área
para una organización; y un área como éstas se ha caracterizado por ser una fuente de gastos,
debido a todos los requerimientos de la seguridad de la información y la tecnología [WILS03].
Para entender los aspectos relevantes de la seguridad informática con respecto a las inversiones, y
los requerimientos que llevan a estas, se necesitan examinar los principales conceptos e
implicaciones que la seguridad informática tiene en una organización, como son, sus objetivos,
principios, servicios y los recursos que soportan dichos conceptos.

Se comienza con una revisión de la historia y la evolución a través de los años de la seguridad
informática, para observar y analizar el crecimiento de los aspectos positivos y negativos, así como
la evolución del área tratada en esta investigación. A continuación, los conceptos, objetivos,
principios, y servicios de la seguridad informática, ayudan a crear una base para la definición de la
misma, y a comprender el modelo actual de la seguridad informática. Luego, se hace una revisión
de cómo la administración de la seguridad informática ayuda a hacer un acercamiento y
cumplimiento de los objetivos y principios antes mencionados, y qué implica ejecutar una gestión
de administración de este estilo: tareas, responsabilidades, conocimientos, etc.

En seguida, se explora el concepto básico de ROI (siglas en inglés de, Return on Investment), con
una definición elemental aplicable a cualquier área del conocimiento. Y finalmente, la revisión de
la literatura base para la investigación, concluye con un estado del arte de los principales avances y
propuestas existentes alrededor de la medición y cálculo del ROI en seguridad informática,
algunos modelos y críticas al tema.
Con base en los temas anteriormente mencionados, la propuesta de esta investigación busca
proponer una guía metodológica para el cálculo del retorno a la inversión (ROI), basada en la
administración de la seguridad informática, que incluye la administración de riesgos en la
organización, en busca del cumplimiento de los objetivos y principios de esta área.

4
1.3 Pregunta de investigación y Objetivos
El objetivo principal de esta investigación es proponer y evaluar una guía metodológica para el
cálculo del Retorno a la Inversión (ROI) en Seguridad Informática, aplicando dicha guía a un caso
de estudio específico. Esta investigación trata de dar respuesta a la pregunta: ¿cómo calcular el
retorno a la inversión en seguridad informática? Para responder a esta pregunta, primero se realiza
una revisión y síntesis de temas como, la historia de la seguridad informática, sus conceptos y
modelo, su administración y un estado del arte de las investigaciones y modelos propuestos para el
cálculo del ROI en dicha área. La síntesis de los temas anteriores, provee una base y los medios
para proponer una guía, que en este caso es una guía metodológica, que luego será probada y
analizada según sus resultados. Finalmente se evalúa la viabilidad y aplicabilidad de la guía
propuesta, dentro de los límites especificados para el caso de estudio.

1.4 Importancia de la investigación

La presente investigación está inmersa en uno de los temas actuales del campo de la tecnología,
más debatidos y con más campo abierto de investigación. El retorno a la inversión en la seguridad
informática, ha sido un tema interesante, y que según los juicios de algunos, es una pérdida de
tiempo [WILS03], por la dificultad que representa medir algunos aspectos intangibles que contiene
esta área.

Esta investigación hace un aporte al tema de ROI en seguridad informática, sintetizando algunas
de las propuestas realizadas, conceptos y teoría básica necesaria para el estudio de dicho tema,
finalizando con una propuesta de una guía metodológica para realizar dichos cálculos, con su
respectiva evaluación y análisis, que puede ser base para futuras investigaciones.

5
2 Revisión de Literatura

La base literaria de esta investigación está sustentada en diversos temas, pero centrada
fundamentalmente en los conceptos principales de la seguridad informática, retorno a la inversión
y algunos modelos de cálculo. Sin embargo, como se verá a lo largo de la investigación, esta
revisión de literatura provee solo un fragmento de la información necesaria para el desarrollo de la
guía metodológica. La siguiente revisión de literatura, busca construir una base de conocimiento y
una perspectiva sobre los temas concernientes a la investigación.

Este capítulo está organizado en 4 secciones. En la primera de ellas, se encuentra una discusión
acerca de la evolución de la seguridad informática, seguida de los conceptos y modelo actual de la
seguridad informática, que sirven como base a la administración de la misma, para finalmente
concluir con la revisión de los conceptos y referencias relativas al retorno a la inversión.

2.1. Historia y evolución de la Seguridad Informática

Los problemas de seguridad surgen desde antes de la interconexión de computadoras en los años
70’s y 80’s; estos problemas se remontan a los inicios del desarrollo de las máquinas de tiempo
compartido, en donde se presentaban riesgos de acceso no autorizado y modificación de
información. Previo a estos desarrollos, se hablaba de seguridad desde los inicios de la Segunda
Guerra Mundial, donde surgieron los problemas de comunicación segura entre las diferentes tropas
en misión; para solucionar estos problemas se empezó a hablar del cifrado de mensajes.

Aunque la seguridad computacional, realmente tuvo un auge importante cuando se conectaron los
computadores entre sí para compartir información, poco a poco se conectaban mayor cantidad de
equipos llegando a un crecimiento exponencial, que presentaban cada vez mayor riesgo para
asegurar la información.

A continuación se describen algunos de los hechos históricos que han marcado los inicios y
evolución de la seguridad informática [MACM02]:

A finales de los años 50 los computadores trabajaban con registros especiales para definir
particiones en memoria para el uso de programas separados y asegurar que un programa en
ejecución no pueda acceder a particiones de otro programa. La memoria virtual ofrece
mecanismos que permiten proteger la información como si estuviese es su propia partición de
memoria; las particiones y el concepto de memoria virtual proveen una de las primeras medidas
de protección de seguridad en ambientes multi-usuarios.

A principios de los años 60, los sistemas de tiempo compartido proveían almacenamiento de
información a usuarios individuales. Este sistema fue seguro usando control de acceso, que
permitía al dueño de la información, especificar y autorizar accesos a otros diferentes usuarios. La
primera característica de la seguridad fue la protección de contraseñas de usuarios, en donde los
sistemas de autenticación codificaban la imagen de estas.

En 1968 el sistema Multics del MIT, presentó algunas características de seguridad y privacidad,
donde se prestó mucha atención a identificar un pequeño kernel en el sistema operativo, que
garantizara que todas las políticas de seguridad del sistema fueran permitidas.
En 1969, vino la aparición de ARPANET (Advanced Research Project Agency Network)
comenzando con cuatro nodos, hasta convertirse en lo que es hoy en día Internet. Este continuo

6
aumento de interconexiones, incrementó el riesgo de acceso a usuarios externos no autorizados y
asimismo, el conocimiento sobre temas de seguridad a los administradores y propietarios de las
redes.

El Unix-Unix System Mail (UUCP) en 1975 permitía a usuarios Unix ejecutar comandos en un
sistema Unix secundario. Este permitía que, correos electrónicos y archivos fuesen transferidos
automáticamente entre sistemas, lo que también permitía a los atacantes borrar o sobre escribir los
archivos de configuración. Como no había una administración central del UUCP en la red, el
ARPANET hizo un acercamiento al control de los problemas de seguridad que no se aplicaban.
En los siguientes años se empezó a hablar sobre criptografía con llave pública y firmas digitales,
debido a la necesidad de permitir comunicación confidencial entre dos usuarios. Esto ha generado
que la criptografía sea un tema importante en el desarrollo de la seguridad informática.

En 1978 (Morris y Thompson) se realizó un estudio que demostraba que adivinar contraseñas a
partir de datos personales de los usuarios, como son el nombre, teléfono, fecha de nacimiento, era
más eficiente que decodificar las imágenes de dichas contraseñas. Estos fueron los primeros pasos
de la ingeniería social, dentro del área de seguridad informática, y en donde evolucionan así
mismo, los principios de la misma, y en específico, la confidencialidad.

En el mismo año nace una nueva preocupación de la seguridad informática, que consiste en la
protección de los pagos electrónicos a través de la red que comenzaron a hacerse disponibles a los
clientes. Este tipo de transacciones se tradujo en la necesidad de un alto nivel de seguridad,
evolucionando así los conceptos de confidencialidad e integridad.

El crecimiento exponencial de la red, comenzó a requerir un DNS (Directory Name Server)

dinámico, que actualizara la base de datos de asociación de nombres y direcciones. Estos nuevos
servidores se convierten en otro blanco para las atacantes y suplantadores. Los virus informáticos
tienen un crecimiento notable y se convierten en una seria amenaza para los administradores de
seguridad informática y para los usuarios.

En 1988, se destaca el primer ataque a gran escala, a través de gusanos cibernéticos, que podrían
llegar a infectar en horas un porcentaje significativo de la red. Este hecho permite reconocer las
vulnerabilidades que se tienen en la red.

La seguridad encuentra otro interés profundo en los años previos a 1993, donde los atacantes
utilizan métodos de sniffing (rastreo) para detectar contraseñas, y spoofing (suplantación) o usan
los mismos computadores con identificadores falsos para transmitir sus propios paquetes al ganar
accesos al sistema.

A raíz de dicho crecimiento de las redes, se comenzaron a presentar abusos computacionales

causados por los mismos usuarios. Estos abusos se pueden clasificar en [BAIL95]: robo de
recursos computacionales, interrupción de servicio, divulgación no autorizada de información y
modificación no autorizada de información. A partir de estos abusos, y a partir de la evolución de
los principios de la seguridad informática a través del tiempo, hoy en día se tiene un modelo actual
basado en dichos principios de confidencialidad, integridad y disponibilidad, que buscan proteger
la información, recursos y personas que hacen uso de esta, tratando así de evitar el continuo
crecimiento a dichos abusos. Dichos principios han ido evolucionando a través del tiempo, lo que
no significa que hayan surgido solo hasta esta época.

Se pueden definir además seis clases de abusos técnicos por los que debe preocuparse la seguridad
informática [BAIL95]: Errores humanos, abuso de usuarios autorizados, exploración directa,

7
exploración con software especializado, penetración directa, mecanismos de subversión de
seguridad.

En el caso de errores humanos, son simples errores cometidos por los usuarios que pueden llegar a
representar grandes daños al sistema. El abuso de usuarios autorizados, se refiere a los abusos que
hacen los usuarios al entregarles demasiada confianza o privilegios sobre algún sistema. La
exploración directa, se presenta cuando el usuario ingresa teniendo autorización, pero sin ser
previsto por los operadores del sistema. Por su parte, la exploración con software especializado,
consiste en exploraciones en donde se hace uso de herramientas especializadas para acceder a
recursos no autorizados o generar irregularidades en los sistemas. Algunos de estos software
empleados son: los troyanos que son ocultados en aplicaciones comunes y comerciales, los virus
que tienen la capacidad de reproducirse, las bombas de tiempo, entre otros. Ahora bien, en la
penetración directa, a diferencia de la exploración directa, no se tiene autorización, pero los
intrusos encuentran alguna falla o vulnerabilidad, y generan algún tipo de código malicioso para
explotarla y obtener el control del sistema. Por último en los mecanismos de subversión de
seguridad, se ataca el control interno para entrar sin autorización a un sistema, sin ser detectado.

Hoy en día, y con el paso del tiempo, los avances tecnológicos y la investigación, la seguridad
informática ha venido estructurándose de manera tal que se ha convertido en un arte y ciencia, con
principios fundamentales y una importante cantidad de teoría en todos sus aspectos.

Con esta historia, como base literaria de la investigación, se busca entonces, comprender la
evolución de los objetivos y principios de la seguridad informática vigentes en los modelos
actuales, para aplicarlos y tenerlos como base para el desarrollo de la guía metodológica.

2.2. Conceptos y Modelo Actual de la Seguridad Informática

La Seguridad Informática ha sido uno de los temas más mencionados en la literatura en la última
década, debido a su dinamismo y constantes cambios e innovaciones. Todo sistema es desarrollado
y cambiado varias veces a lo largo de su ciclo de vida [BAIL95], debido a nuevas funcionalidades
que son adicionadas, políticas, mejoras, etc. Todos estos cambios y nuevas funcionalidades alteran
los requerimientos de seguridad de los sistemas, y obligan a una reevaluación de dichos
requerimientos del sistema [BAIL95], para lograr una revaloración de las nuevas vulnerabilidades
y debilidades del nuevo sistema o sistema modificado, y así implementar soluciones ante estos
nuevos requerimientos.

Junto a estos grandes cambios que actualmente atañen a todas las organizaciones, han venido
surgiendo cada vez más retos, que se convierten no sólo en un problema tecnológico sino también
en un problema cultural de dichas organizaciones [ALSI05]; y entre dichos desafíos se encuentra
la seguridad informática, o también caracterizada como, Seguridad de Tecnología de Información
(Seguridad de TI) [BRIN95b], punto a discutir en la presente sección.

2.2.1. Objetivo de la Seguridad Informática

Los continuos desafíos de la Seguridad Informática que han venido surgido, han llevado a esta área
a definir metas y propósitos, los cuales han sido resumidos en su objetivo principal, y que permite
hacer un acercamiento al cumplimiento de los nuevos y cambiantes retos. Es así como la
Seguridad Informática busca dar apoyo a los objetivos y misión de las organizaciones, a través de
la protección de sus principales recursos y activos: la información, la tecnología que la soporta

8
(hardware y software) y las personas que la utilizan y/o conocen [ALSI05] [STON01], a través de
la selección y aplicación de protecciones adecuadas, manteniendo así, el debido cuidado de sus
recursos físicos, financieros, reputación, y otros activos tangibles e intangibles [NIST95].

Para el cumplimiento de dicho objetivo, la Seguridad Informática ha definido tres principios

básicos (confidencialidad, integridad y disponibilidad) y 4 servicios (autenticación, autorización,
no repudio y auditabilidad), los cuales serán detallados en secciones posteriores.

Desafortunadamente, la Seguridad Informática algunas veces ha sido vista, no sólo como una
fuente de gastos y grandes inversiones [WILS03], sino como un obstáculo para la misión de la
organización, debido a la imposición de reglas, procedimientos y protecciones mal seleccionadas,
que llegan a ser molestos para los usuarios, administradores, y para los mismos sistemas y su
respectiva administración. [NIST95]. Sin embargo, al procurar una buena administración de la
Seguridad Informática, y hacer una adecuada selección de procedimientos, reglas y protecciones,
puestas en su debido lugar, se dará apoyo a la organización al cumplimiento de su misión.
[NIST95]

2.2.2. Principios de la Seguridad Informática

Al ser la protección de los activos, uno de los objetivos principales de la seguridad informática,
esto significa mantenerlos seguros frente a las diversas amenazas a las que se enfrentan y que
pueden afectar su funcionalidad de diferentes maneras: corrupción, acceso indebido e incluso hurto
y eliminación. [ALSI05], la Seguridad Informática se basa en la preservación de unos principios
básicos, los cuales son enumerados y definidos por diferentes autores, con algunas variantes y
algunas constantes. Cada uno de dichos principios tiene un propósito específico dentro del marco
del objetivo de la seguridad informática [HARR03]. Para el desarrollo de esta investigación, se
definen los siguientes principios básicos:

2.2.2.1. Confidencialidad
Este principio tiene como propósito asegurar que sólo la persona o personas autorizadas tengan
acceso a cierta información. La información, dentro y fuera de una organización, no siempre puede
ser conocida por cualquier individuo, si no por el contrario, está destinada para cierto grupo de
personas, y en muchas ocasiones, a una sola persona. Esto significa que se debe asegurar que las
personas no autorizadas, no tengan acceso a la información restringida para ellos.

La confidencialidad de la información debe prevalecer y permanecer, por espacios de tiempo

determinados, tanto en su lugar de almacenamiento, es decir en los sistemas y dispositivos en los
que reside dentro la red, como durante su procesamiento y tránsito, hasta llegar a su destino final
[STON01].

2.2.2.2. Integridad
La integridad tiene como propósito principal, garantizar que la información no sea modificada o
alterada en su contenido por sujetos no autorizados o de forma indebida. Así mismo, la integridad
se aplica a los sistemas, teniendo como propósito garantizar la exactitud y confiabilidad de los
mismos. Debido a esto, la integridad como principio de la Seguridad Informática, se ha definido en
dos partes: integridad de los datos e integridad de los sistemas.

9
La integridad de los datos, se refiere a que la información y los programas solo deben ser
modificados de manera autorizada por las personas indicadas para ello. Estas alteraciones pueden
darse por inserciones, sustituciones o eliminaciones de contenido de la información.

Por su parte, la integridad de los sistemas, hace referencia a que todo sistema debe poder cumplir
su función a cabalidad, sin ninguna violación o modificación del mismo, en su estructura física y/o
lógica, sin perder necesariamente su disponibilidad [NIST95] [ALSI05].

2.2.2.3. Disponibilidad
Este principio tiene como propósito, asegurar que la información y los sistemas que la soportan,
estén disponibles en el momento en que se necesiten, para los usuarios autorizados a utilizarlos. Al
referirse a los sistemas que soportan la información, se trata de toda la estructura física y
tecnológica que permite el acceso, tránsito y almacenamiento de la información [ALSI05].

Adicionalmente, la disponibilidad hace referencia a la capacidad que deben tener los sistemas de
recuperarse ante interrupciones del servicio, de una manera segura que garantice el continuo
desarrollo de la productividad de la organización sin mayores inconvenientes [HARR03].

Se han presentado varias interpretaciones y discusiones alrededor de los principios de integridad y

confidencialidad; dichas discusiones radican en la pertinencia de dichos principios a los sistemas
que soportan la información. Algunos autores argumentan que la confidencialidad y la integridad
conciernen únicamente a la información, mientras que la disponibilidad atañe a la información y a
los sistemas que la soportan [BRIN95b].

Mientras que otros, plantean la integridad y la disponibilidad como principios relativos a dichos
sistemas que soportan la información [ALSI05] [HARR03] [STON01]. En la presente
investigación se tienen en cuenta los dos principios mencionados anteriormente, como
fundamentales para los sistemas que soportan la información, debido a que la violación de la
integridad de un sistema, física o lógicamente, no significa necesariamente su pérdida de
disponibilidad, aunque de forma contraria, la falta de disponibilidad de un sistema, posiblemente
puede estar ligada a una violación previa de su integridad, ya sea en su estructura física o lógica.

En conclusión, disponibilidad, integridad y confidencialidad son principios básicos de la seguridad

informática, y su adecuada comprensión es necesaria en esta investigación, para la correcta
identificación de problemas y las soluciones apropiadas a ellos a través de la administración de la
seguridad, con el objetivo de calcular el retorno a la inversión sobre dichas soluciones, [HARR03]

2.2.3. Servicios de la Seguridad Informática

Para lograr hacer cumplir la preservación y el cumplimiento de los tres principios básicos de la
seguridad informática, discutidos anteriormente, se han planteado cuatro servicios principales, que
sirven como base para la implementación de una infraestructura de seguridad de TI en una
organización [STON01]. Las definiciones planteadas a continuación, son resultado del compendio
de las definiciones dadas por los siguientes autores [NIST95], [STON01], [GASS88], [ALSI05],
[BRIN95b], [HARR03].

10
 2.2.3.1. Autenticación
Este servicio busca asegurar la validez de una identificación proporcionada para acceder cierta
información, proveyendo medios para verificar la identidad de un sujeto, básicamente, de tres
formas: por algo que el sujeto es, por algo que el sujeto tiene o por algo que el sujeto conoce.

2.2.3.2. Autorización
El servicio de autorización permite la especificación y continua administración de las acciones
permitidas por ciertos sujetos, para el acceso, modificación, o inserción de información de un
sistema, principalmente, mediante permisos de acceso sobre los mismos.

2.2.3.3. No repudio
La administración de un sistema de información debe estar en capacidad de asegurar quién o
quiénes son los remitentes y destinatarios de cualquier información. Es por esto que este servicio
provee los medios y mecanismos para poder identificar quien ha llevado a cabo una o varias
acciones en un sistema, para que los usuarios no puedan negar las responsabilidades de las
acciones que han llevado a cabo.

2.2.3.4. Auditabilidad
Este servicio proporciona los mecanismos para la detección y recuperación ante posibles fallas o
incidentes de seguridad, mediante el registro de todos los eventos y acciones hechas en un sistema.

2.2.4. Definición de Seguridad Informática

Luego de comprender los objetivos principales y los principios básicos de la seguridad
informática, esta se puede definir como, la definición y posterior implementación de protecciones,
políticas y procedimientos, en búsqueda de la preservación de la integridad, disponibilidad y
confidencialidad de la información, los recursos que la soportan (hardware, software, firmware,
dispositivos de comunicación) y los individuos que la utilizan o conocen.

Para llegar a cumplir los principios de la seguridad informática y lograr un buen funcionamiento
de sus servicios, se debe tener una buena base de administración de los recursos, tanto
tecnológicos como humanos, así como la información y los procesos que la seguridad busca
proteger, tratando de llevar un manejo de eficiente y eficaz de dichos recursos. En el siguiente
capítulo, se presentarán los conceptos generales de la administración de la seguridad informática, y
cómo ésta apoya los procesos de seguridad informática en una organización.

2.3. Administración de la Seguridad Informática

Diariamente se escucha en varios medios (periódicos, televisión, Internet, foros de discusión,

reportes de fabricantes de productos y proveedores de servicios, etc.) acerca de incidentes de
seguridad informática, como ataques de virus que causan pérdidas y daños que pueden llegar a
representar grandes sumas de dinero para una organización, ataques remotos de hackers a
instituciones financieras, ataques a los sitios Web de grandes y prestigiosas empresas y
corporaciones, etc. Este tipo de incidentes son los que hacen cada vez más interesante la seguridad
informática, pero así mismo significa tareas y responsabilidades diarias de esta área para prevenir

11
ataques como los antes mencionados. Es por esto que la administración de la seguridad informática
es uno de los temas más importantes en la estructura de seguridad informática de una organización
[HARR03].

Administrar la Seguridad Informática de una organización, es un trabajo fundamental para

conservar confiables, los sistemas de la misma. La tarea de administración, comprende la
administración de riesgos, definición, creación e implementación de políticas de seguridad,
procedimientos, estándares, guías, clasificación de información, organización de la estructura de
seguridad de la compañía, y la educación de los individuos de la organización, entre otras.
[HARR03] [ALSI05]

Como se mencionó en la sección anterior, la clave de un programa de seguridad informática, es la

protección de los activos más importantes de la compañía. Estos activos pueden ser identificados
mediante los análisis de riesgos, además de la identificación de las vulnerabilidades y amenazas
que pueden llegar a afectar dichos activos, y estimar los costos y daños que tendría para la
compañía, la materialización de una o más de dichas amenazas. Como resultado de los análisis de
riesgos se puede lograr tener un presupuesto de las inversiones necesarias para la protección de
dichos activos, contra los riesgos anteriormente identificados, no solo en cosas materiales, sino
también en implementación de políticas, educación del personal, desarrollo de guías o estándares,
etc. [ALSI05]
.
El administrador no es un simple observador de un sistema y de sus operaciones posteriores a su
instalación. Esta labor también incluye tareas previas de la instalación del sistema, tales como
validar y estructurar las políticas de seguridad para el mismo, aunque esto no quiere decir que esta
administración pertenece solo al área técnica, también tiene tareas administrativas como son la
creación de políticas, hacer que se cumplan y actualizarlas cuando sea necesario.

La administración de seguridad debe tener en cuenta que el desarrollo y crecimiento de un sistema,

las redes, etc., producen cambios constantes en las políticas de seguridad, en la protección de
bienes y las amenazas establecidas, lo cual requiere también de una debida gestión y
administración. [HARR03]

Una de las formas más utilizadas para hacer administración de la seguridad informática, se basa en
la utilización de estándares. El crecimiento de las necesidades de gestión de la seguridad
informática en las organizaciones, ha motivado la creación de estándares locales e internacionales
para la administración de tecnología de información, y en particular la seguridad de dicha
información, y todo lo que a ésta concierne [OUD05].

La historia de los estándares se remonta a los inicios del siglo XX, con los primeros usos que se
dieron a la electricidad; se comenzaron a desarrollar entonces aplicaciones eléctricas bajo los
primero estándares establecidos por la International Electronic Committee (IEC). Más adelante con
el paso del tiempo, fue surgiendo la necesidad de nuevos y mejores estándares en más y más áreas
del conocimiento, y así nació la International Organisation of Standarisation (ISO) [OUD05].

Pero no sólo existen estándares reconocidos internacionalmente, sino también han surgido
estándares locales o nacionales, referentes a la administración de seguridad informática. La razón
principal de la creación de estos estándares locales, radica en la casuística y especificidad que
pueden llegar a tener las mejores prácticas en el área, en un país o región determinada [OUD05].

Uno de los factores positivos de la existencia actual de los estándares, es la cantidad que hay de los
mismos, ya que esto permite a una organización particular, acoplarse o acomodarse a uno de estos

12
estándares, según sus características y necesidades, o en una situación determinada.
Adicionalmente, otro punto a favor de las organizaciones gracias a los estándares, no sólo es el
ahorro de recursos, tanto de dinero, como de personas y tiempo, en desarrollar estándares propios,
sino que pueden utilizar estándares que han sido demostrados a partir de las mejores prácticas en el
área, que para el caso de esta investigación, son las mejores prácticas en administración de la
seguridad informática [OUD05].

En dicha área, la administración de seguridad informática, existen varios estándares, nacionales e

internacionales, que están orientados a ser una guía para las organizaciones en la formación y
mantenimiento de la infraestructura de seguridad informática de las empresas. A continuación se
listan algunos de los estándares más importantes que existen en el área:

• ISO/IEC 13335-1:2004 : Information technology -- Security techniques --

Management of information and communications technology security -- Part 1:
Concepts and models for information and communications technology security
management
• ISO/IEC TR 13335-3:1998 : Information technology -- Guidelines for the
management of IT Security -- Part 3: Techniques for the management of IT Security
• ISO/IEC TR 13335-4:2000 : Information technology -- Guidelines for the
management of IT Security -- Part 4: Selection of safeguards
• ISO/IEC TR 13335-5:2001 : Information technology -- Guidelines for the
management of IT Security -- Part 5: Management guidance on network security
• ISO/IEC 17799:2005 : Information technology -- Security techniques -- Code of
practice for information security management
• British Standard 7799 – BS7799
• Estándares publicados por NIST (Nacional Institute of Standards and Technology)
• COBIT Security Baseline
• ISF Standard of Good Practice

Para lograr los objetivos de la administración de la seguridad informática, ésta se vale de controles
que se utilizan para hacer cumplir las directivas que esta área ha fijado para la organización.
Dichos controles se clasifican en: controles administrativos, controles técnicos y controles físicos.
[HARR03] Los controles administrativos, hacen referencia al desarrollo y publicación de políticas,
estándares, procedimientos, investigación del personal, entrenamiento y el cambio de los
procedimientos de control.

Los controles técnicos, se refieren a los mecanismos de control de acceso, administración de

recursos y contraseñas para su acceso, métodos de autenticación y autorización, dispositivos de
seguridad, y la configuración de la infraestructura técnica de seguridad de la organización.

Los controles físicos corresponden a los controles físicos de acceso a diferentes locaciones de la
organización, bloqueo de sistemas, monitoreo de los lugares críticos de almacenamiento y manejo
de información, etc.
[HARR03]

Dentro de la administración de la seguridad de la información, se deberían tener en cuenta las

inversiones requeridas para el desarrollo de los procedimientos, políticas, estándares, etc.,
anteriormente mencionados, y para que dichas inversiones lleguen a retornar los beneficios o
ganancias esperadas, se debería también conocer la forma de estimar las ganancias o posibles
pérdidas de dichas inversiones. Posteriormente en la sección a continuación, se expondrán algunas

13
ideas y acercamientos planteados por diferentes autores acerca del cálculo del retorno de las
inversiones en seguridad informática.

2.4. Retorno a la Inversión (ROI) en Seguridad Informática

“Retorno sobre la inversión: Métrica financiera de rentabilidad que muestra el número de veces
que una inversión retornará a la empresa en determinado período de tiempo.” [MEKA]

El ROI consiste en la ganancia que se obtendrá en un periodo de tiempo, debido a una inversión
realizada. La estimación de ROI no es una tarea fácil, ya que deben tenerse en cuenta dos factores
importantes, los cuantitativos y los cualitativos, Los factores cuantitativos, se refieren a lo que
puede ser medido numéricamente, los factores cualitativos, están orientados hacia los aspectos
intangibles, como son el valor de pérdida de datos o un mejoramiento esperado en eficiencia
operacional. [MCLE03].

Greg McLean y Jason Brown [MCLE03], afirman que la seguridad no debe ser planeada alrededor
del suministro de un retorno en la inversión en dólares devueltos en la administración de procesos,
debe ser planeada con el objetivo de proporcionar un nivel de comodidad a la alta gerencia,
mantener a los intrusos fuera de la red, y los errores u omisiones deben mantenerse a un nivel de
riesgo aceptable, etc. Estos factores deben tenerse en cuenta al estimar el retorno de la inversión,
siendo que son factores intangibles, por lo tanto difíciles de medir, estos pueden presentar
problemas inherentes en tratar de crear una fórmula para estimar su inversión, debido a que dichos
factores pueden presentar diferentes niveles de preocupación para cada tipo de organización.
Puede que muchas organizaciones tengan la misma infraestructura, pero cada una puede tener un
conjunto único de requerimientos de seguridad, y sus bienes pueden requerir diferentes niveles de
atención [FOST04]. Como ejemplo podemos ver los diferentes daños que puede causar un mismo
tipo de ataque a un servidor de un banco, o a un servidor de hosting. Las técnicas de ataque pueden
ser similares, pero las diferencias de pérdidas a dichos ataques pueden ser grandes. Los daños
causados en el servidor del banco pueden generar un alto nivel de pérdida de información valiosa,
en tanto que la pérdida de información de un servidor hosting puede no tener mayor costo.

Debido a estas dificultades, se han generado polémicas y varios puntos de vista de diferentes
autores los cuales proponen posibles intentos de calcular el ROI en seguridad informática. En la
siguiente sección se presentarán algunos de estos modelos propuestos.

2.4.1. Modelos propuestos para el cálculo del ROI en seguridad informática

La universidad de Carnegie Mellon trabajó con CERT (Computer Emergency Response Team)
para estudiar la supervivencia de un sistema en red. Su propuesta se basó en recolectar datos
empíricos sobre seguridad y amenazas de seguridad.

Las variables existentes para esta prueba, fueron la inversión en seguridad (nivel de protección), y
la supervivencia (impacto) de la infraestructura de tecnología de información. Basados en estas
variables, se realizaron y se documentaron ataques a un sistema, haciendo uso de una máquina que
generaba ataques, los cuales eran configurables para que fueran en ocasiones más robustos que en
otros casos. También fue necesario tener variación en los niveles de inversión en seguridad para
lograr concluir frente a estas variables, el impacto o supervivencia del sistema en prueba.

Después de realizar dichas pruebas, variando el nivel de inversión en seguridad y robustez de los
ataques, se evaluó la supervivencia del sistema atacado. Los gráficos resultantes (Supervivencia vs

14
Inversión en Seguridad), presentaron una curva “smokestack”, que refleja que a mayor inversión,
mayor supervivencia del sistema, pero se muestra claramente un punto de quiebre, en el cual, para
aumentar la supervivencia a partir de este punto, era necesario tener una mayor inversión para
lograr aumentar en tan solo un poco el nivel de supervivencia del sistema [FOST04].

En la Universidad de Idaho [FOST04], se realizó otra investigación para estimar el ROI. Esta
consistió en la construcción de un IDS (Sistema de Detección de Intrusos) y asignar valor a los
activos tangibles, los cuales eran medidos en dólares y los intangibles con valores relativos. De
esta completa valoración, los investigadores lograron calcular resultados teóricos a partir de lo que
llamaron Pérdida Anual Esperada (ALE): que es definido como el costo del daño causado por un
ataque, multiplicado por la frecuencia de ocurrencia durante un año. Según [FOST03] los estudios
de la Universidad de Idaho para estimar el ROI, puede ser reducido a:

(ALE x EFICIENCIA DEL IDS) – COSTO DEL IDS = ROI

Por su parte, Marcia J. Wilson [WILS03] propone una serie de pasos para tener en cuenta al
momento de tratar de estimar el ROI en seguridad informática, estos son:

• Identificar los activos de información: recursos, productos, infraestructura computacional

de red, la información referente a la organización, los clientes y empleados. Perder
confidencialidad, integridad y disponibilidad pueden representar pérdida tangible en
dólares y/o pérdidas intangibles, como puede ser de reputación o imagen organizacional.

• Identificar amenazas y vulnerabilidades: una amenaza es cualquier evento que causa un

resultado indeseado. Las amenazas pueden ser de diferentes tipos y causan diferentes
efectos. Los terremotos, los pleitos, entre otros, son amenazas que podrían afectar los
activos de la organización. Las vulnerabilidades son debilidades o la ausencia de
protección adecuada.

• Hacer una valoración de los activos: valorar los activos es importante, ya que puede
ayudar a priorizar la necesidad de protegerlos. Esta tarea puede llegar ser realizada a
partir de una matriz que liste cada uno de los activos en riesgo, y ser clasificados en una
escala de alto, medio o bajo según las necesidades del sistema.

Una vez se tenga conocimiento de lo que se tiene, es necesario comprender cuánto le costaría a la
organización la pérdida de estos, versus el costo que tendría protegerlos. A partir de estos
principios se podría llegar a estimar el ROI en seguridad informática de una organización.

A partir de este estudio, [WILS03] presenta algunas fórmulas que pueden ser empleadas para
ayudar a calcular el ROI en seguridad. Entre estas encontramos:

El Factor de exposición (EF): para un activo en particular, es el porcentaje de pérdida si un evento

ocurriese.

Pérdida Esperada (SLE): cantidad de dólares necesarios en caso de que ocurra un incidente.

Tasa de ocurrencia anual (ARO): estimación de la frecuencia de ocurrencia de un evento. Puede

ser estimado basado en tipos de vulnerabilidades y amenazas que son conocidas o han sido
documentadas.

Pérdida anual Esperada (ALE): SLE * ARO = ALE

15
La pérdida anual Esperada, puede llegar a ser útil para determinar el impacto causado por la
materialización de una amenaza, a partir de este estimado se lograría determinar el ahorro que una
inversión representa para un determinado riesgo.

Por su parte, Eddie Schwartz en [SCHW03] da sus opiniones sobre las proposiciones de Marcia J.
Wilson. Schwartz opina que las ecuaciones propuestas, son fórmulas estándar para la valoración
cuantitativa de riesgos; pero hacen falta datos estadísticos en la mayoría de las organizaciones,
para aplicar estas fórmulas. Por ejemplo, es muy escasa la información de ALE y ARO sobre
vulnerabilidades y amenazas de seguridad, lo cual hace que al aplicar dichas fórmulas, esto se haga
de forma incompleta. El ROI en seguridad informática, no es tangible, ya que el “retorno” no
incrementa tangiblemente la productividad de los empleados, ni disminuye los costos
operacionales.

Sin embargo Greg McLean y Jason Brown [MCLE03] proponen buscar estimar el retorno de la
inversión, listando los tipos de exposición y el costo que esto implicaría si llegase a ocurrir. Esta
clasificación se realiza tanto para factores cuantitativos, como cualitativos, los cuales son
clasificados en tres grupos: exposición financiera, procesos ineficientes y costos intangibles. Su
propuesta también incluye una clasificación de inversiones junto con el costo que sería necesario
para su implementación; estos serían agrupados en: inversiones de instalación e inversiones de
mantenimiento.

Este tipo de estimación se propone que debe hacerse cada tres años. A partir de estos datos la suma
del costo de inversiones de instalación se divide en tres años y se suman a los costos de
mantenimiento anual. Por lo tanto se suman las inversiones anuales y se restan los costos de
exposición evitados con la inversión correspondiente. Esto permitiría, según [MCLE03], calcular
una estimación de lo que se puede llegar a recibir después de hacer una inversión en seguridad.

Como conclusión de las investigaciones citadas en la presente sección, es clara la necesidad de

listar y valorar cada uno de los riesgos a los cuales esta expuesta una organización, junto con el
impacto que podrían llegar a causar si llegasen a ocurrir. A partir de esta estimación se puede
lograr una acercamiento de los costos e impacto que se lograría mitigar a partir de la inversión. La
diferencia entre estos dos factores, podría llegar a resumir la estimación del ROI. En el próximo
capítulo se presentarán elementos que serán de ayuda para lograr dicho objetivo.

16
3 Análisis Preliminar

3.1 Introducción

Durante los últimos años, las inversiones en el área de seguridad informática de las organizaciones,
han incrementado de manera notable, y esta tendencia se seguirá dando, debido al continuo
crecimiento de dicha área en las compañías actuales. De esta manera, los fondos económicos de
una organización destinados a la seguridad informática, se están incrementando cada vez más,
siendo esto bien visto y bienvenido por los administradores de seguridad de dichas empresas, ya
que de esta forma están logrando cubrir más y de mejor manera las brechas y requerimientos de
seguridad en la organización, dando un mayor nivel de protección dentro de las mismas, y a su
vez, a sus activos más importantes, buscando siempre el cumplimiento de los principios de la
seguridad informática, y el buen funcionamiento de sus servicios, con base en gestión y
administración adecuada de los recursos y procesos del área. Sin embargo, la seguridad
informática no está siendo solamente un punto crítico para las inversiones, sino que a su vez, debe
reflejar de la misma manera, el retorno de dichas inversiones económicas; es decir poder mostrar a
la alta gerencia o a cualquier persona de la organización, los réditos o beneficios que las
inversiones del área están dando. Es por esto, que los administradores de seguridad tienen la
responsabilidad de demostrar, de alguna manera, la efectividad y valor de sus programas e
infraestructuras de seguridad y las inversiones que se hacen en ella. [PAYN02] [FOUN03]

Esta labor para los administradores de seguridad y todo su personal, ha iniciado una búsqueda de
una forma para medir y poder demostrar dichos beneficios de las inversiones y la efectividad de la
infraestructura de seguridad, con el objetivo de justificar los proyectos del área. Una de las formas
de las que puede valerse el área de seguridad, es a través de las métricas en seguridad informática,
soportado por un programa de métricas que las desarrolle, implemente y mantenga. [PAYN02]

A su vez, las métricas pueden estar inmersas dentro de un proceso conocido como administración
de riesgos, en donde las métricas pueden ayudar y apoyar el proceso de medición del impacto y la
probabilidad de cada uno de los riesgos, y así determinar su nivel, para finalmente, apoyar y
facilitar el proceso de toma de decisiones en la organización con respecto a la situación de
seguridad informática, y tomar medidas tanto preventivas, como correctivas.

En este capítulo, se presenta un análisis de los tres temas fundamentales descritos anteriormente,
con miras al desarrollo de la guía metodológica, objetivo de esta investigación; ellos son:
Administración de Riesgos, Métricas en Seguridad Informática y un análisis de algunos de los
Modelos para el cálculo del retorno a la inversión propuestos y revisados en el capítulo anterior,
Revisión de Literatura. El desarrollo de este capítulo permitirá plantear más adelante, el modelo
propuesto para la construcción de la guía metodológica.

3.2 Análisis de Riesgos

En esta sección, se analizará el papel que juega la administración de riesgos en el aseguramiento

de las organizaciones, ya que este tiene un esquema interesente que nos ayuda a determinar en
grado de exposición de riesgos que se tiene y analizar en que medidas deben ser mitigados.

17
El análisis de riesgos hace parte de la administración organizacional, como bien se define en
[AZNZS] “La administración de riesgos es el término aplicado a un método lógico y sistemático
de establecer el contexto, identificar, analizar, evaluar, tratar, monitorear y comunicar los riesgos
asociados con una actividad, función o proceso de una forma que permita a las organizaciones
minimizar pérdidas y maximizar oportunidades. Administración de riesgos es tanto identificar
oportunidades como evitar o mitigar pérdidas.”

Podemos decir entonces que el análisis de riesgos es el proceso de identificación, valoración y

posible mitigación de riesgos, hasta un nivel aceptable, con el fin de proteger los activos
informáticos organizacionales y su misión.

El análisis de riesgos, tiene una estructura bien definida que nos ayuda a identificar los riesgos a
los cuales están sometidos los activos de la organización, para así evaluarlos y analizarlos con el
fin de priorizar y clasificar, qué riesgos deben ser administrados.

Las organizaciones poseen activos los cuales la seguridad informática busca proteger, estos están
conformados por tres elementos: la información, la tecnología que la soportan y las personas que la
utilizan [ALSI05-2]. La seguridad informática busca dicha protección, pero para que esta cumpla
su función, requiere inversión, lo cual trae costos elevados que no siempre están disponibles en las
organizaciones; por este motivo, es necesario tener una correcta administración de riesgos que
incluya su correspondiente análisis de riesgos, para lograr decidir en qué riesgos invertir y en
cuáles no es necesario, según su prioridad.

El NIST 800-30 Risk Management Guide for Information Technology Systems [STON02], define
el riesgo en función de la probabilidad de que se materialice una amenaza debido a una
vulnerabilidad existente, y el impacto resultante que perjudica a la organización a razón de dicho
evento. También propone una metodología para llevar acabo una análisis de riesgos. Esta
propuesta consta de nueve pasos principales:

1. Caracterización del sistema

Define alcance, se identifican los límites del sistema a partir de recursos y de la
información de éste.

Para identificar los riesgos en un sistema de tecnología de información se requiere tener

conocimiento del ambiente y de los procesos del sistema. Para lograr este fin, se propone
la recolección de información relacionada con el sistema, por medio de entrevistas,
cuestionarios, revisión de documentos, etc. Este proceso debe ser completo y debe incluir
el estudio del contexto organizacional y del negocio.

Después de realizar este paso podemos tener conocimiento de los límites del sistema,
funciones, sistemas y datos críticos. Este paso es importante, ya que se logra obtener una
contextualización en el ambiente organizacional.

2. Identificación de amenazas

Las amenazas son agentes capaces de explotar los fallos de seguridad, que denominamos
puntos débiles y, como consecuencia de ello, causar pérdidas o daños a los activos de una
organización, afectando a sus negocios [ALSI05-2].

Las amenazas se pueden presentar por diferentes causas: naturales, humanas o del
ambiente [STON02]; y pueden ser ocasionadas voluntarias o intencionalmente. La

18
 identificación de éstas, nos dan a luz algunas de las posibles necesidades de protección
Informática que requiere la organización.

Podemos notar las necesidades que tienen las organizaciones en proteger sus activos por
medio de la seguridad informática, ya que estos son amenazadas constantemente
generando un nivel alto de riesgo el cual puede llegar a perjudicar la misión
organizacional y trayendo consigo costos adicionales.

3. Identificación de vulnerabilidades

El análisis de identificación de amenazas (punto anterior) debe incluir un análisis de

vulnerabilidades asociado con el ambiente del sistema.

Las vulnerabilidades son debilidades que son atacadas por las amenazas mediante la
materialización de estas, y afectan la confidencialidad, disponibilidad e integridad de una
organización, su información o sus individuos [ALSI05-2].

Las vulnerabilidades pueden ser detectadas a partir de reportes, documentos previos de

valoración de riesgos, requerimientos de seguridad y resultados de pruebas de seguridad.
A partir de este estudio se puede concluir una lista de vulnerabilidades o debilidades, las
cuales a mayor cantidad se encuentren, demuestran mayor riesgo organizacional.

4. Análisis de controles existentes

Consiste en analizar los controles que ha sido implementado o se planean implementar,

con el fin de reducir la probabilidad de que una amenaza sea materializada y tomen
ventaja de una vulnerabilidad. Es importante tener en cuenta los controles implantados,
ya que una vulnerabilidad puede tener menor probabilidad de ser explotada, si se tiene un
mayor control de seguridad.

5. Determinación de probabilidad

Este proceso consiste en determinar la probabilidad de que una vulnerabilidad sea

explotada, en un ambiente con amenazas asociadas. Para estimar una probabilidad, se
debe tener en cuenta las amenazas, la naturaleza de la vulnerabilidad y la existencia y
eficiencia de controles actuales.

Para lograr una medición de la probabilidad, debemos referirnos a una medición que nos
establezca un valor que corresponda a las variables a considerar. Para ello debemos
definir métricas que serán estudiadas en el próximo capítulo

6. Análisis de impacto

Consiste en valorar el impacto causado, como resultado de la materialización de una

amenaza.

Para ello se debe tener en cuenta, en qué medida las amenazas afectan a los sistemas y a
los datos críticos, la misión del sistema, sistemas y datos sensitivos. El impacto de un
evento de seguridad, puede ser descrito en términos de pérdida o disminución de
cualquiera de los siguientes principios de seguridad: integridad, disponibilidad y
confidencialidad.

19
 Es posible medir el impacto que causa la materialización de una amenaza, calculando el
costo que implica la recuperación del daño causado. Pero esto solo es posible si los daños
son tangibles y pueden ser estimados en dinero. Sin embargo existen otro tipo de
impactos que no pueden ser medidos cuantitativamente, ya que son intangibles, por
ejemplo la pérdida de imagen, reputación, confianza del sistema, etc.

Este tipo de impactos solo pueden ser estimados cualitativamente, ya que no pueden ser
estimados en unidades específicas, sino calificados o descritos en términos de impacto
Alto, Medio o Bajo . Este tipo de medidas cualitativas son relativas, ya que cada persona
tiene un punto de vista diferente, y puede variar la valoración del impacto por cada
persona que los califique. Puede existir el caso en que para una persona, la pérdida de
imagen no afecte significativamente la organización, pero para otra persona, puede que
sea algo esencial para lograr los objetivos de esta. Por ello es importante definir qué es
en realidad Bajo, Medio y Alto; para ello es necesario definir alguna métrica que ayude a
calificar el impacto en un nivel más realista y menos relativo.

7. Determinación de riesgo

Este proceso consiste en la valoración del nivel de riesgo del sistema. La determinación
de riesgo para una pareja particular de amenaza/vulnerabilidad puede ser expresado como
una función de:

• La probabilidad de que una amenaza atente a una vulnerabilidad.

• La magnitud del impacto debido a la materialización de una amenaza.
• La adecuación de controles de seguridad planeados o existentes para reducir o
eliminar riesgo.

Para determinar el nivel de riesgo, es necesario multiplicar el impacto por la probabilidad

de ocurrencia. Esto puede llevarse a cabo a partir de una matriz con los diferentes niveles
de impacto y probabilidad; y dándole así valores numéricos a cada uno de los niveles
definidos. A partir de esta tabla se puede representar el nivel de riesgo que puede llegar a
tener la materialización de una amenaza frente a una vulnerabilidad, esta matriz realmente
muestra el nivel de riesgo que se tiene, el cual puede llegar a ser significativo para estimar
el ROI, ya que nos presenta y prioriza la necesidad de inversión. Es necesario al igual que
para estimar el nivel de impacto, el uso de métrica para definir a qué se hace referencia
con un nivel riesgo alto, medio o bajo; y así poder categorizar el nivel de riesgo al que
esta expuesto el sistema.

En seguida se muestra un ejemplo presentado en el NIST 800-30 [STON02] de lo que

podría ser una matriz de nivel de riesgos. A partir de este ejercicio, se pueden priorizar los
riesgos que presenta la organización.

20
Probabilidad \ Bajo (10) Medio (50) Alto (100)
Impacto
Alto(1.0) Bajo 10 * 1.0 = 10 Medio 50 * 1.0 = 50 Alto 100 * 1.0 = 100
Medio(0.5) Bajo 10 * 0.5 = 5 Medio 50 * 0.5 = 25 Medio 100 * 0.5 = 50
Bajo(0.1) Bajo 10 * 0.1 = 1 Bajo 50 * 0.1 = 5 Bajo 100 * 0.1 = 10
Tabla 1: Ejemplo NIST 800-30
Escala de riesgo: alto (>50 -100); medio (>10-50); bajo (1>10)

8. Recomendaciones de control

El objetivo de las recomendaciones de control es reducir el nivel de riesgo del sistema y

llevarlo a un nivel aceptable. Debe tenerse en cuenta los siguientes factores:
recomendaciones efectivas, regulación y legislación, políticas organizacionales, impacto
operacional y seguridad y confianza [STON02].

Aplicar seguridad es realmente lo que llamamos la inversión en Seguridad, al invertir en

ésta, se disminuye el riesgo, por lo cual se pueden identificar mejor las amenazas que
pueden llegar a tomar ventaja de una vulnerabilidad, las cuales podrían generar costos
elevados para la recuperación del impacto causado.

9. Documentación de Resultados

Una vez finalizado cada paso del proceso, los resultados deben ser documentados en un
reporte oficial.

Para finalizar esta sección, se presenta un diagrama explicativo del Análisis de riesgos:

Figura 1: Diagrama Análisis de Riesgos

21
3.2.1. ¿Cómo favorece o aporta la Administración de Riesgos en el proceso
investigativo del Cálculo de ROI en seguridad informática?

Antes de estimar el ROI puede ser útil hacer un análisis de riesgos, para lograr tener conocimiento
de las amenazas a las que está expuesta la organización, las vulnerabilidades que se tienen, la
estimación de la probabilidad de materialización de las amenazas, el riesgo al cual se está expuesto
y el impacto organizacional causado por tener niveles de riesgos inaceptables. A partir de dicho
análisis de riesgos, se pueden estimar las pérdidas a las cuales está expuesta la organización de
acuerdo con su nivel de exposición (su falta de aseguramiento).

Adicionalmente, un análisis de riesgos permite priorizar inversiones de seguridad en la

organización, frente a los recursos de inversión que se prevean para ello. Asimismo se puede
valorar el nivel de impacto organizacional que se produciría al no invertir en dichas soluciones de
seguridad o al hecho de estar expuestos a amenazas que impacten las vulnerabilidades del sistema,
lo cual perjudica la misión organizacional, y por consiguiente pérdida del buen funcionamiento del
sistema, el cual podría producir mayores costos.

Para lograr valorar o estimar los niveles de impacto que puede tener la organización, y la
probabilidad de la ocurrencia de los eventos, se puede llevar a cabo un proceso de definición de
métricas que ayuden a medir los costos de los activos y sus protecciones, con el objetivo de
obtener un nivel de riesgo con base en dichos factores. A continuación, se expondrán los conceptos
básicos para la definición de métricas.

3.3 Métricas en Seguridad Informática

Una métrica se puede definir como una herramienta diseñada para facilitar el proceso de toma de
decisiones, a través de la recolección, análisis y reporte de datos relevantes, relacionados con el
desempeño.[SWAN03]
Una buena métrica debe cumplir con las características SMART (por sus siglas en inglés,
especifica, medible, alcanzable, repetible y dependiente del tiempo).[PAYN02] En el campo de la
seguridad informática, se puede concluir que una métrica confiable, debe indicar el grado en que
los objetivos de la seguridad informática, descritos en el capítulo anterior, están siendo alcanzados,
y ayudan a llevar a cabo acciones en busca del mejoramiento del programa e infraestructura de
seguridad de la organización.

En esta área, las métricas pueden ser una herramienta efectiva para los administradores de
seguridad, para monitorear y medir la efectividad y el estado de diferentes componentes y sus
actividades, que componen su programa e infraestructura de seguridad, y de esta manera facilitar el
mejoramiento continuo de estas, mediante la aplicación de acciones correctivas. Estas métricas
pueden además ayudar a la identificación de los niveles de riesgo de ciertos componentes, siendo
así parte del proceso de administración de riesgos que lleva la organización, para de esta forma,
priorizar dichos riesgos, y llevar a cabo las acciones necesarias, para estar cada vez más cerca del
cumplimiento de las metas y objetivos de la seguridad de la organización, que seguramente,

22
estarán encaminados a los objetivos de la seguridad informática, confidencialidad, integridad y
disponibilidad.

En este punto vale la pena anotar y ahondar un poco en la diferencia entre metas y objetivos. Las
metas de seguridad, se refieren a los resultados deseados de la implementación de un programa de
seguridad informática en una organización; mientras que los objetivos de dicho programa de
seguridad, permiten llegar al cumplimiento de dichas metas mediante la identificación de prácticas
o actividades específicas, definidas por las políticas y procedimientos de seguridad de la
organización, que se traducen en los controles de seguridad implementados. [SWAN03] Es decir,
las metas de un programa de seguridad, se manejan y definen a un nivel estratégico, mientras que
los objetivos se definen en un nivel táctico, en donde se tienen cosas específicas en busca del
cumplimiento de dichas metas estratégicas.
Ahora bien, la idea de las métricas, es como su nombre lo dice, poder medir algo. De esta manera,
es deseable que las métricas de seguridad, produzcan información cuantificable, como porcentajes
o promedios, con el objetivo de poder realizar comparaciones y futuros mejoramientos, como se ha
venido mencionando; y de la misma manera, si se quieren comparar resultados de las métricas,
continuamente, se supone que el proceso de recolección de los datos, debe ser un proceso sencillo
y repetible, con datos fácilmente obtenibles, y procesos robustos y consistentes.[SWAN03]

Dichos procesos deben ser repetibles, debido a que las métricas en general, cambian de tres formas
[FOUN03]:
• A través del tiempo: debido a cambios en el entorno y en la tecnología, que obligan a
cambios en las medidas tomadas y los mecanismos de seguridad implementados.
• Según la industria: no todas las industrias son iguales, y por lo tanto su definición de
métricas es diferente, dependiendo de sus metas y objetivos de seguridad informática,
basados en la misión y objetivos organizacionales.
• Según las acciones: el estado de la seguridad de la organización cambia dependiendo de
las protecciones implementadas en un o u otro lugar para mitigar riesgos. Cada vez que se
implementa un nuevo control o protección, cambia el estado de la organización y por
consiguiente cambian las medidas de las métricas.

Las métricas pueden encontrarse tipificadas o categorizadas en tres tipos [SWAN03]:

• Métricas de Implementación, para medir la efectividad de la implementación de políticas
de seguridad.
• Métricas de Efectividad y Eficiencia, para medir los resultados de los servicios de
seguridad implementados.
• Métricas de Impacto, para medir el impacto de los eventos de seguridad en el negocio o la
misión de la organización.

Para el fin de esta investigación se utilizarán en su gran mayoría, las métricas de impacto, ya que
estas ayudarán a medir el impacto de los riesgos asociados, para luego poder calcular el retorno de
las inversiones que se pueden hacer con el objetivo de mitigar dichos riesgos. Sin embargo, no se
descartan los otros dos tipos de métricas, ya que también son útiles en el proceso de medición de
probabilidad de ocurrencia y efectividad de los procesos que actualmente se ejecutan en las
organizaciones.

23
Ahora bien, no es secreto que la medición a través de métricas tiene algunas dificultades, como por
ejemplo la medición de algunos activos que no son medibles como tal, es decir, que pueden ser
intangibles, como por ejemplo la reputación de la organización. ¿Cómo se puede medir la
reputación de una organización? ¿Qué métrica se puede aplicar? Las métricas de seguridad son
también algo difícil de crear y comprender, debido a que esta disciplina es un poco reciente, y se
encuentra en un estado de desarrollo. No hay entonces un vocabulario ni documentación suficiente
sobre las mejores prácticas a seguir.

Existen varios modelos que, a través de una serie de pasos, sirven de guía para la construcción de
programas de métricas en las organizaciones, y por lo tanto la construcción de las métricas
mismas. Luego de un análisis de los modelos propuestos por dos autores [PAYN02] y [SWAN03],
se puede deducir la siguiente guía para la generación de métricas, encaminada al uso de las
métricas en la presente investigación:

1. Identificar las metas y objetivos del sistema o programa de seguridad informática de la

organización.
2. Identificar las políticas, procedimientos y controles existentes
3. Definir qué métricas se van a generar: para este proceso, se puede utilizar un enfoque top-
down, de arriba hacia abajo, mediante el cual las métricas se definen, iniciando desde los
objetivos previamente identificados, y para cada uno de ellos, se pueden identificar
métricas específicas que pueden ayudar a determinar si dichos objetivos se están
cumpliendo o no.
4. Desarrollar y planear estrategias para la generación de las métricas (recolección y análisis
de datos)
5. Crear un plan de acción para la generación de las métricas, y ejecutarlo

La madurez de un programa de métricas está definida por la existencia e institucionalización de

procesos y procedimientos. Mientras más información disponible haya, la dificultad de medir, es
menor. Los tipos de métricas (implementación, eficiencia y efectividad, e impacto) que pueden ser
realmente obtenidos y que a su vez son útiles para el mejoramiento del rendimiento, dependen de
la madurez de la implementación de controles de seguridad.

Se puede concluir entonces, que las métricas de seguridad pueden ser utilizadas dentro de un
proceso de análisis y administración de riesgos, como se describió en la sección anterior, y dicho
proceso enmarcado en la búsqueda de la justificación de las inversiones, mediante el cálculo del
retorno de las inversiones en dichos proyectos. Es por eso, que la aplicación de métricas de
seguridad en una organización, puede ayudar a responder preguntas, tales cómo: ¿es la
organización más segura hoy que antes? ¿Cuál es el beneficio en términos económicos de aplicar
uno u otro proyecto de seguridad informática? ¿Cómo está la organización en materia de seguridad
informática, en comparación con otras compañías de la industria? ¿Está la organización, lo
suficientemente asegurada en términos informáticos? Estas y muchas otras preguntas, se pueden
tratar de resolver, con el cálculo del retorno a la inversión, bajo un proceso de administración de
riesgos, que permita identificar los beneficios de mitigar o aceptar uno u otro riesgo, conociendo
su prioridad, luego de haber medido su impacto y probabilidad de ocurrencia, mediante algunas
métricas definidas.

24
Con la conclusión de este y los anteriores capítulos, se puede establecer una base de conocimiento
y conceptualización que ayudará a establecer el modelo a proponer para el desarrollo de una guía
metodológica para lograr estimar el retorno de la inversión en seguridad informática. Con el
desarrollo de dicho modelo, se tratarán de enlazar los temas vistos en la revisión de literatura y el
análisis preliminar, lo que permitirá dar soporte al modelo mismo y a la guía metodológica, y
enfocar su desarrollo hacia los temas abarcados.

25
4 Modelo propuesto para el Retorno de la Inversión

4.1. Introducción

En el capítulo 2, sección 2.4, se presentaron y discutieron algunos de los modelos de cálculo del
retorno a la inversión en seguridad informática, propuestos por algunos autores, tales como:
[MCLE03], [FOST04] y [MAHJ03], por lo que, en el presente capítulo no se volverá a ahondar en
el tema, pero sí se presentará el modelo propuesto en esta investigación, acerca de cómo podría
hacerse el cálculo del ROSI (Return On Security Investment), teniendo en cuenta lo visto y
analizado en dichos modelos.

Una de las limitaciones que existen en los modelos propuestos presentados anteriormente, es la
falta de medición o formas de medir los activos o aspectos intangibles de las organizaciones. Este
parece ser uno de los factores más difíciles de abordar en la medición del retorno a la inversión, ya
que es muy complicado tratar de medir algo que no es fácilmente cuantificable, y más aún cuando
no hay datos o algún acercamiento hacia dichas medidas de los activos intangibles.

Adicionalmente, una de las aproximaciones que se ha venido evaluando a lo largo del capítulo
anterior, como opción para tener una base para la guía metodológica, objetivo de esta
investigación, es la Administración de Riesgos. A través del proceso de análisis y administración
de riesgos en una organización se puede llegar a medir el retorno de las inversiones en seguridad
informática. En los modelos propuestos y presentados en el capítulo 2, no se encuentra una
aproximación fuerte hacia dicho proceso, como una forma de acercarse al cálculo de retorno de
inversiones en el área. Es por esto, que el modelo a proponer en este capítulo, se construirá
alrededor de la administración y análisis de riesgos.

De esta manera, y como resultado de los análisis realizados alrededor de los modelos para el
cálculo del ROSI, el proceso de administración de riesgos y la utilidad de las métricas en la
seguridad informática, se planteará el diseño del modelo con miras a la guía metodológica a
desarrollar durante esta investigación.

El siguiente diagrama, muestra el modelo general de cálculo del retorno a la inversión que será
desarrollado en la guía metodológica, y que se detallará en las secciones siguientes:

26
 Figura 2: Modelo propuesto

4.2. Explicación del Modelo

El modelo inicia con base en el proceso de Administración de Riesgos, que para las
organizaciones, consiste en un proceso iterativo que consta de una secuencia de pasos, que al ser
ejecutados, posibilitan una mejora continua en el proceso de toma de decisiones. Este proceso
incluye la identificación de los riesgos a los que está expuesta la organización en un momento
dado, y que en este caso, se refieren a riesgos de seguridad de la información. Adicionalmente
luego de dicha identificación, este proceso permite analizar, evaluar, tratar, monitorear y
comunicar los riesgos asociados a la infraestructura de seguridad de la información.

Durante el proceso descrito anteriormente, la identificación y análisis de riesgos asociados,

involucra un subproceso llamado Análisis de Riesgos, descrito en la sección 3.2 del presente
documento. Como se explicó en su momento, este proceso permite establecer una lista de riesgos
clasificados según su nivel de criticidad, determinado por la probabilidad de ocurrencia y la
magnitud del impacto que generaría la materialización de un riesgo determinado. Los riesgos que

27
resultan ser más críticos, o con prioridad alta, involucran los activos más importantes y valiosos de
la organización, por lo cual son los que primero deben ser mitigados, en el menor tiempo posible.
Sin embargo, el modelo propuesto permitiría evaluar cualquier tipo de riesgo, ya sea con prioridad
alta, media o baja.

Ahora bien, para cuantificar tanto la probabilidad de ocurrencia como el impacto del riesgo, se
pueden utilizar como herramientas, algunas métricas definidas para valorar, por ejemplo, la
magnitud de dicho impacto. Estas métricas pueden estar basadas en estudios anteriores, o también
pueden ser definidas según las necesidades.

Para lograr la estimación de la probabilidad o número de ocurrencias de los eventos no deseados,

que para este modelo se tomarán en cuenta en períodos anuales, lo más deseable es contar con
datos históricos de los eventos sucedidos en la organización, relacionados con el riesgo que se esté
evaluando. De esta manera, se puede llegar a tener un estimado del número de ocurrencias anuales
por cada amenaza que se materializaría en dicho riesgo. En caso de no tener registros de los
eventos sucedidos en períodos anteriores que ayuden a estimar dicha probabilidad de ocurrencia,
es posible basarse en historiales obtenidos de organizaciones de características similares, en cuanto
a su tamaño, sector, ingresos anuales, número de clientes, entre otros aspectos. Sin embargo, es
posible que estas organizaciones semejantes mantengan este tipo de información de manera
confidencial y no sea de dominio público, por lo tanto, es poco probable que dicha información
esté disponible para otras organizaciones, y por lo tanto habría que buscar otro medio para realizar
dichas estimaciones. Es por esto que pueden ser de gran utilidad, las estadísticas que varios
fabricantes de soluciones de seguridad informática tienen a disposición del público, sobre los
eventos de seguridad más relevantes de los últimos períodos. De la misma forma, en algunas
ocasiones, estas estadísticas tienen en cuenta el tipo de negocio, sector, tamaño, entre otros, lo cual
también ayudaría a realizar un acercamiento más preciso a la probabilidad de ocurrencia de los
eventos.

La estimación del impacto que puede causar la ocurrencia de un evento no deseado, consistiría en
calcular el costo de recuperación de los daños causados por dicho evento. Para ello, es necesario
tener en cuenta el mayor número de aspectos implicados en la recuperación de los sistemas o
activos afectados por la ocurrencia del evento. Algunos de estos factores que se deben tener en
cuenta son: el número de horas de inactividad de la organización debido al evento ocurrido y el
costo que esto implica, porcentaje de actividades paralizadas debido al evento, cantidad
correspondiente en dinero que implica el porcentaje de inactividad del negocio, costo por hora de
los empleados afectados y de los empleados que se requieren para el reestablecimiento de los
sistemas afectados, tiempo estimado de recuperación, número de transacciones perdidas por hora,
entre muchos otros aspectos que pueden variar dependiendo del tipo y actividad principal de la
organización y del tipo de evento analizado.

Luego de tener la lista de los riesgos asociados a la infraestructura de seguridad de la organización,

y de haber realizado el análisis de dichos riesgos, se contaría con el costo de impacto para cada
uno de ellos, basado en la estimación del impacto, realizado en la valoración de cada uno de los
riesgos, como se describió anteriormente.

Por otra parte, para cada uno de los riesgos se puede también calcular el costo de mitigación, es
decir el costo de implementar y mantener una solución que permita disminuir la probabilidad de la
ocurrencia del evento o eventos asociados a dichos riesgos; esto incluye, el costo de la inversión
que implica la implementación de la solución, así como también, los costos de operación , que
incluyen los costos de mantenimiento y soporte anual que requiere dicha solución y que

28
comúnmente son ofrecidos por los mismos fabricantes de las soluciones que proveen la
implementación de las mismas.

Hay que tener en cuenta, que un riesgo no necesariamente se mitiga con un solo control o
inversión; es posible tener la necesidad de hacer varias inversiones con el objetivo de mitigar algún
riesgo de la manera más efectiva y que garantice un nivel de seguridad aceptable. Asimismo, es
posible que una inversión planeada para la mitigación de un riesgo específico, ayude también a
mitigar de manera parcial, otros riesgos identificados en la valoración realizada anteriormente.

A partir de este punto en el modelo propuesto, ya se cuenta con la información necesaria para
iniciar con el análisis periódico del comportamiento del ROSI, esto es:

• Lista de riesgos priorizados según su criticidad

• Probabilidad de ocurrencia y estimación de impacto para cada uno de dichos riesgos
• A partir de dicha estimación, se tiene el Costo de Impacto para cada riesgo, en caso de
presentarse un evento asociado a este
• Costo de Mitigación para cada uno de los riesgos

El modelo está diseñado para realizar periódicamente el proceso descrito, y se sugieren lapsos
anuales, en los cuales se realicen las iteraciones sobre el modelo, con el objetivo de ver y analizar
el comportamiento de las inversiones y su retorno a través del tiempo, y poder estimar los ahorros
e inversiones que cada año se harían.

Ahora bien, para cada uno de los análisis anuales, es importante tener en cuenta, además de los
factores listados anteriormente, un nuevo valor que desde este momento, llamaremos el Costo de
Referencia de Impacto Anual (CRIA). Este valor corresponde al costo estimado de impacto,
calculado en el año 0, es decir el costo de impacto que ya se tiene en el listado previo. Este valor
de referencia servirá para poder comparar, desde el segundo año en adelante, el ahorro anual que
se tiene gracias a la inversión realizada. Es decir que el CRIA, podría verse como la cantidad de
dinero que habría tenido que gastarse en la recuperación de los daños, en el caso en que no se
hubiera hecho la inversión inicial.

A continuación se presentarán ejemplos de los casos de análisis de los valores descritos, a través
del tiempo, y así poder observar los beneficios o retorno que da la inversión hecha, vista, por
ahora, como ahorro de dinero.

El análisis anual para cada riesgo, comienza entonces con la relación de los valores de Impacto
versus la Inversión inicial que se haría para mitigar el riesgo en el primer año, esto es:

Año 1

Impacto menor que la Inversión inicial

Riesgo n Año 1 (US$)

Inversión 100
Impacto 80
Operación -
Gasto Adicional -20
Tabla 2: Impacto menor que la inversión inicial

29
En este caso, el ejemplo muestra una inversión de 100 dólares, y un costo de impacto de 80
dólares. Adicionalmente a partir de estos datos, y como se dijo anteriormente, el valor del CRIA
sería de 80 dólares, ya que es la cantidad que se tendría que gastar en reparación de daños, si no se
se implementa la solución o inversión. Asimismo, se puede apreciar que para este año, se tiene un
valor negativo de -20 dólares; este valor muestra la relación entre Inversión e Impacto, que
haciendo una simple resta aritmética, indica que en dicho año hubo que gastar 20 dólares más de lo
que se hubiera gastado sin la inversión, es decir, 20 dólares más que el CRIA.

Son estos 20 dólares los que se tendrían que tener en cuenta para “recuperar” al siguiente año, y lo
demás sería parte del ahorro que representa el retorno o beneficio que da la inversión a través del
tiempo.

Impacto mayor que la Inversión inicial

Riesgo n Año 1 (US$)

Inversión 100
Impacto 120
Operación -
Ahorro +20
Tabla 3: Impacto mayor que la Inversión inicial

En este caso, la inversión inicial es de 100 dólares, contra un costo de impacto de 120 dólares. Es
por esto que en este primer año, cuando la inversión inicial es menor que el costo de impacto, ya se
tiene un ahorro de 20 dólares, con lo cual se tendría ya un retorno de la inversión, que estaría
representado por el beneficio del ahorro. En este caso, para el primer año, y con las condiciones
dadas entre el impacto y la inversión, se podría definir el ahorro como:

Ahorro = CRIA(impacto) − Inversión

Año 2 en adelante

Para los años siguientes al año 1, como se había mencionado anteriormente, se debe realizar una
nueva iteración sobre el modelo, para cada uno de los riesgos, y de esta manera se obtendrán
nuevos valores para el impacto y los costos de operación. En el caso de los costos de operación, se
tendrían en cuenta los costos de mantenimiento de la solución implementada en el año 1. Y en el
caso del impacto, se tendrían en cuenta los costos que implica la reparación de los daños residuales
asociados con cada uno de los riesgos. Es decir, el impacto que probablemente no fue mitigado en
su totalidad por la solución implementada.

Con base en lo anterior, para el año 2 se tendría, por ejemplo:

Riesgo n Año 1 (US$) Año 2 (US$)

Inversión 100 -
Impacto 80 20

30
 Operación - 15
Gasto o Ahorro -20 35
Pendiente por recuperar 20
Ahorro Total o Saldo por recuperar 25
Tabla 4: Estimación año 2

En el ejemplo, hubo una inversión (en costos de mantenimiento) en el año 2, de 15 dólares, y un

costo de impacto de 20 dólares. Esto daría un total de 35 dólares que habría que gastar en ese
segundo año, y comparando este valor con el valor del CRIA (US$80, para este caso), se tendría
un ahorro de 45 dólares; pero hay que tener en cuenta el valor que había pendiente por recuperar
del año anterior, que para el ejemplo, es de 20 dólares. Por lo tanto, el ahorro finalmente sería de
25 dólares.

Dado esto, se podría para estos casos, del año 2 en adelante, definir el ahorro como:

Ahorro = (CRIA − Gasto _ del _ año) − Pendiente _ por _ recuperar

Ahorro = (80 − 35) − 20 = US $25

De esta forma, la organización debería poder realizar un proceso iterativo que la lleve a determinar
a lo largo de los años, un valor estimado de los beneficios o retornos que se presentan debido a las
inversiones realizadas en períodos anteriores.

31
5. Guía Metodológica

5.1. Introducción

Luego de haber presentado en las secciones previas de este documento, el marco teórico y los
conceptos base para el desarrollo de la guía metodológica, así como el modelo propuesto para la
elaboración de la misma, se presenta en este capítulo la secuencia de pasos que compone la guía
metodológica objetivo de esta investigación, con la cual se busca proponer una forma para estimar
el retorno de las inversiones en seguridad de la información, para posteriormente evaluar su
funcionamiento, viabilidad y aplicabilidad.

Como se ha expuesto a lo largo del presente documento, esta guía metodológica busca ser una
referencia acerca de cómo poder estimar el retorno a la inversión (ROSI) en seguridad informática,
y como se presentó en el capítulo anterior, estará basada y guiada por un proceso iterativo de
Análisis de Riesgos; pero esto no quiere decir que se presentará una guía para realizar dicho
proceso. Para esto, la guía metodológica que se presentará a continuación estará basada en un
documento de recomendaciones del NIST (National Institute of Standards and Technology),
titulado: NIST SP 800-30 Risk Management Guide for Information Technology Systems
[STON02]. Dicho documento presenta una guía práctica para la administración de riesgos
relacionados con tecnologías de información en las organizaciones, por lo que se tendrá en cuenta
durante el desarrollo de la guía metodológica, realizando algunas modificaciones en los puntos de
determinación de probabilidad de ocurrencia, impacto y priorización de riesgos.

Como se dijo anteriormente, la presente guía busca orientar al lector y usuario de la misma, para
estimar el retorno de las inversiones en seguridad informática, más no calcularlo con precisión, ya
que dicho valor se conocería únicamente después de una inversión. Es por esto, que el presente
capítulo, busca mostrar cómo poder realizar dichas estimaciones positivamente.

A lo largo de la guía metodológica, se ilustrará mediante un ejemplo de un caso, cada uno de los
pasos que componen dicha guía. Vale la pena aclarar también, como ya se ha hecho anteriormente,
que esta guía metodológica busca ser flexible, es decir, se podría adaptar o tener algunas
modificaciones, dependiendo del tipo de organización en donde se aplique, condiciones o
situaciones particulares. Es por esto que, en los puntos en que sea necesario se darán algunas
sugerencias de manera general para cualquier tipo organización, a tener en cuenta durante la
aplicación de la guía.

Finalmente, es recomendable que la aplicación y manipulación de la guía metodológica, sea hecha

por personas con conocimiento y experiencia en el área, buscando así la mejor comprensión y
aplicación correcta de dicha guía, y de la misma forma, poder desarrollar y adaptar el desarrollo de
la misma, a las condiciones dadas en cada organización en particular.

5.2. Caracterización del ejemplo a desarrollar

Como se mencionó anteriormente, durante la exposición de la guía metodológica se irá ilustrando

cada paso, con un ejemplo de un caso dado. Las siguientes son las características de la
organización a tener en cuenta para dicho ejemplo:

32
Nombre de la Organización: Soluciones Informáticas Paquita S.A.

Tipo de Organización: Prestación de Productos y Servicios

Misión: Prestar a las organizaciones nacionales e internacionales productos y servicios

especializados en sistemas de información empresariales, para el manejo y administración de la
información relevante de cada organización.

Tamaño de la organización: la empresa cuenta con aproximadamente 32 empleados, distribuidos

en 4 áreas organizacionales:

• Área Comercial
• Área Tecnológica
• Área Financiera
• Área de Recursos Humanos

Información crítica de la organización: debido a que la empresa se dedica a proveer productos y

servicios, los datos críticos son aquellos que corresponden a la información que suministran los
clientes antes y durante la implementación de los proyectos desarrollados. Asimismo, la
organización cuenta con información crítica propia de la misma empresa, como son, los datos de
sus empleados, datos de nómina, contabilidad, datos financieros en general, convenios con
empresas externas, entre otros.

Arquitectura de Red: a continuación se presenta el diagrama de la arquitectura de red con que

cuenta la organización para el caso del ejemplo.

Figura 3: Ejemplo - Arquitectura de red

33
5.3. Guía metodológica para el cálculo del retorno de la inversión en
seguridad informática (ROSI)
A continuación se presenta la guía metodológica objetivo de este trabajo de investigación, la cual
sigue el esquema presentado en el modelo propuesto en el capítulo anterior del presente
documento, y se divide en dos partes principales; la primera de ellas se refiere al proceso de
Análisis de Riesgos, en el cual está basada la guía, y la segunda parte, que describe el proceso de
estimación del retorno de las inversiones determinadas en el análisis de riesgos anteriormente
mencionado.

5.3.1. Proceso No. 1: Análisis de Riesgos

Este proceso consiste en la identificación de los riesgos a los cuales está expuesta la organización,
así como de los controles existentes para algunos de dichos riesgos identificados, y finalmente la
recomendación de nuevos controles; adicionalmente durante dicho proceso se priorizan los riesgos
identificados, con base en el número de ocurrencias e impacto de cada uno de ellos, en un tiempo
determinado.

A continuación se detallan los pasos a seguir durante este primer proceso.

5.3.1.1. Caracterización de la Organización

Durante la identificación y la valoración de riesgos, el primer paso consiste en definir el alcance

del estudio a realizar, con el objetivo de trazar los límites de la organización, sus sistemas e
información relevante. Este paso es importante ya que permite el conocimiento y contextualización
dentro de la organización, y será la base para la posterior identificación de amenazas y
vulnerabilidades correspondientes a la misma.

Esta caracterización consiste básicamente en un levantamiento de información, de los factores más

relevantes de la organización. Debido a que las empresas no se desempeñan en el mismo campo, ni
son del mismo tipo, ni tienen los mismos objetivos, es decir, todas son distintas, no se puede
generalizar en este punto acerca del levantamiento de información, ni en forma ni en fondo; es
decir no se puede tener una forma general de levantamiento de información, ni una misma técnica
para dicho procedimiento. Es por esto, que a continuación se presentan algunas sugerencias
generales, de algunos puntos que se han identificado como relevantes en el levantamiento de
información, así como algunas técnicas sugeridas; todo lo anterior, debe ser adaptado en cada
organización, según sus características y condiciones dadas.

Sugerencias para el levantamiento de información

Para el levantamiento de información de la organización, se pueden tener en cuenta, entre otros,

los siguientes aspectos:

• Nombre de la Organización
• Tipo de organización
• Misión
• Visión
• Objetivos organizacionales
• Planes estratégicos

34
 • Ámbito (Local, nacional, internacional)
• Información crítica de la organización
• Tamaño de la organización
• Áreas funcionales
• Estructura organizacional
• Requerimientos funcionales del área de tecnología de información
• Usuarios de los sistemas
• Políticas de seguridad implementadas
• Procedimientos
o Copias de respaldo
o Seguridad
o Mantenimiento
• Topología de Red – Arquitectura de Seguridad
• Descripción detallada de la topología de red y de la arquitectura de seguridad
• Administración de la información
o Protecciones
o Formas y lugares de almacenamiento
• Administración de Red
• Flujos de información
• Controles implementados en materia de seguridad de la información
• Planes de seguridad
• Inventario de hardware
• Inventario de software
• Activos de la organización

En caso de tener una organización en fase de planeación o construcción, el levantamiento de

información puede derivarse de los documentos pertinentes de planeación de la misma, así como
de varias de las técnicas que se describirán más adelante.

Técnicas sugeridas para el levantamiento de información

A continuación se presentan algunas de las técnicas utilizadas durante un levantamiento de

información, las cuales pueden ser usadas individualmente o en conjunto, para una mejor
completitud del proceso. Algunas de ellas, entre otras, son:

• Cuestionarios: durante el proceso de recolección de información, la persona o personas

que se encuentren realizando el análisis de riesgos, pueden desarrollar cuestionarios de
manera continua, haciéndolos cada vez más especializados para las condiciones dadas de
la organización. Estos cuestionarios pueden ser desarrollados también durante las
entrevistas en sitio, que se describen más adelante. Es recomendable aplicar los
cuestionarios, no sólo al personal técnico de la organización ni el personal administrativo.
En general la recolección de información debe hacerse en gran parte de la organización.

• Entrevistas en sitio: las entrevistas con el personal relacionado con tecnologías de

información, puede ser útil al momento de recolectar información acerca de los sistemas
que utilizan en dicha área, y los sistemas de seguridad implementados en la organización.
Este tipo de entrevistas en sitio, permiten también una observación más detallada del
ambiente físico de la organización, y de la seguridad de la organización en un nivel
operacional.

35
 • Revisión de documentos: comúnmente las organizaciones poseen la documentación de
las políticas, procedimientos, planes de seguridad, sistemas implementados, etc., que
pueden proveer información acerca de la situación actual de la organización y los planes
estratégicos de la misma.

• Herramientas automáticas de escaneo: las herramientas de escaneo son útiles con

frecuencia, en el levantamiento de información detallado de la topología de red y la
arquitectura de seguridad de la información, mediante herramientas de mapeo de red, que
proveen información detallada de los servicios, estado de conexiones, etc.

Este primer paso de levantamiento de información, puede ser desarrollado continuamente desde el
primero al último paso del análisis de riesgos; es decir es un proceso continuo.

5.3.1.2. Identificación de amenazas

El objetivo de este paso, es identificar las principales amenazas que ponen en peligro los activos de
la organización. Una amenaza puede ser definida como un agente o circunstancia, capaz de
explotar una vulnerabilidad específica, es decir, una debilidad que puede ser accionada accidental
o intencionalmente.

En este paso, las amenazas se pueden identificar y clasificar en tres tipos:

• Amenazas Naturales: condiciones de la naturaleza y la intemperie que pueden causar

daños a los activos. Por ejemplo, incendios, inundaciones, terremotos, tormentas
eléctricas, entre otros.
• Amenazas Humanas: eventos causados por humanos, ya sea, con intención (ataques de
red, accesos no autorizados, ejecución de software mal intencionado, etc.), o sin ella
(modificación de datos por accidente).
• Amenazas Ambientales: polución, fallos de energía prolongados, derrame de líquidos
y/o químicos, etc.

Para el desarrollo de este paso durante el análisis de riesgos, la persona o personas encargadas de
este proceso en la organización, deben identificar las amenazas más significativas para la misma,
dependiendo de la organización, y las condiciones de la misma. A continuación se presentan
algunas de las amenazas identificadas que pueden ser una guía para la identificación de las
mismas.

Amenazas Naturales

• Incendios
• Inundaciones
• Terremotos
• Tornados
• Avalanchas
• Tormentas eléctricas

36
Amenazas Humanas

• Hacking
• Ingeniería Social
• Accesos no autorizados a los sistemas
• Intrusos en los sistemas
• Spoofing
• Terrorismo
• Denegación de servicio
• Penetración de sistemas
• Robo de información
• Blackmail (Chantaje a través de correo electrónico)
• Ejecución de código malicioso (virus, troyanos)
• Bugs o errores de los sistemas
• Divulgación de información confidencial

Amenazas Ambientales

• Fallos de energía prolongados

• Polución
• Corrosión
• Derrame de líquidos y/o químicos

Alternativamente, la identificación de amenazas también puede hacerse a través de una

clasificación de las mismas, basada en los principios de la seguridad informática: confidencialidad,
integridad y disponibilidad. Como ya se ha dicho anteriormente, esta es una guía metodológica
flexible que permite a la persona o personas que la estén aplicando, acomodarla a sus necesidades,
y las de la organización.

Para nuestro caso de ejemplo Soluciones Informáticas Paquita S.A, se asume que se realizaron los
diferentes mecanismos recomendados de levantamiento de información. Como resultado de dicho
proceso se identificaron algunas amenazas de las cuales para el ejemplo solo asumiremos 5, las
cuales son:

• Corte de servicio eléctrico por tiempo prolongado.

• Penetración al sistema vía inalámbrica.
• Denegación al servidor de archivos
• Inundación del centro de cómputo, por lluvias fuertes.
• Ingeniería Social, técnica utilizada por hackers y crakers para obtener datos esenciales
sobre los sistemas, realizando preguntas a los usuarios y sacar información sensible sin
que el usuario se de cuenta.

5.3.1.3. Identificación de vulnerabilidades

El objetivo de este paso, es identificar y desarrollar una lista de las principales vulnerabilidades de
seguridad de la organización, determinadas por debilidades o defectos que hay en el ambiente de la

37
organización o en los sistemas de la misma, y que pueden ser explotadas en un momento dado por
una o más amenazas, las cuales han sido identificadas en el paso anterior de este primer proceso.

Vale la pena anotar, que los tipos de vulnerabilidades que se identificarán durante este paso, así
como los métodos utilizados para el mismo, pueden variar dependiendo de la naturaleza de la
organización y sus sistemas de seguridad.

Para la identificación de las vulnerabilidades a nivel de seguridad de la organización, se sugieren

tres métodos en esta guía, pero no se limita a estos.

• Fuentes de información

Existen varias fuentes de información, de las cuales se pueden extractar vulnerabilidades que han
sido previamente identificadas y reportadas. Adicionalmente, una las técnicas descritas
anteriormente en el numeral 5.3.1.1., durante el proceso de levantamiento de información, pueden
ayudar también a identificar las debilidades o defectos en la seguridad de la organización.
Asimismo, se pueden encontrar varias fuentes de información sobre vulnerabilidades en Internet,
como por ejemplo, en páginas Web de fabricantes de soluciones de seguridad informática, acerca
de las vulnerabilidades mitigadas o eliminadas por los hot fixes, parches, service packs, etc. A
continuación se listan algunas fuentes de información que pueden ser de utilidad para la
identificación de las debilidades de la organización en materia de seguridad:

o Documentación de análisis de riesgos realizados previamente

o Reportes de auditorias, pruebas de seguridad y anomalías de sistemas
o Listas de vulnerabilidades, por ejemplo la base de datos de vulnerabilidades
NIST I-CAT (http://icat.nist.gov)
o Reportes y noticias de seguridad de fabricantes y vendedores de soluciones de
seguridad informática
o Listas de correo y foros de seguridad, por ejemplo, Security Focus
(http://securityfocus.com)

• Pruebas de seguridad

Este método consiste en el uso de herramientas de prueba en sistemas y redes computacionales,

que pueden ser útiles para la identificación eficiente de vulnerabilidades en la infraestructura
tecnológica de una organización. Este método incluye:

o Herramientas automatizadas de escaneo de vulnerabilidades: son utilizadas para

escanear un grupo de hosts, parte de una red o una red completa, y buscar
posibles servicios en la red que puedan ser vulnerables, por ejemplo, servicio de
FTP (File Transfer Protocol) que permite el acceso anónimo, o la retransmisión
de correo a través del servidor de la organización. Hay que tener en cuenta que
estas herramientas pueden generar falsos positivos, debido a que no tienen en
cuenta la naturaleza de la organización o de los sistemas que hay en ella.

o Evaluaciones y pruebas de seguridad: consiste en la ejecución de planes de

pruebas de seguridad, mediante procedimientos de pruebas o pruebas
prediseñadas, con el objetivo de evaluar la efectividad de los controles de
seguridad con que cuenta en un momento dado la organización.

38
 o Pruebas de penetración: son usadas para evaluar la habilidad de la
infraestructura tecnológica de la organización, o parte de ella, para defenderse
ante intentos mal intencionados de penetración a la misma, que pueden causar
daños a los activos de la organización.

• Lista de chequeo de requerimientos de seguridad

Mediante este método, el personal encargado del análisis de riesgos, puede determinar si los
requerimientos de seguridad estipulados en la organización, y que probablemente fueron
recolectados durante el primer paso, caracterización de la organización, están siendo satisfechos
con los controles existentes o planeados.

Este tipo de listas de chequeo, están basadas en los estándares de seguridad que ayudan a
identificar las vulnerabilidades de los activos de la organización (hardware, software, personas,
información). En este documento se sugiere el NIST SP 800-26 Security Self – Assesment Guide
for Information Technology Systems, como una guía para el desarrollo de las listas de chequeo, ya
que provee varios puntos que contienen objetivos de control específicos en los cuales una
organización puede llegar a ser medida o puesta a prueba.

Para el caso de ejemplo, Soluciones Informáticas Paquita S.A, después de realizar la identificación
de vulnerabilidades del ambiente organizacional de la organización, a partir de los elementos
propuestos para dicho fin, las principales vulnerabilidades son:

• Falta de conocimiento de los usuarios de tener contraseñas fuerte, y mala administración

de estas.
• El punto de Acceso inalámbrico tiene una configuración débil respecto a la autenticación
de usuarios.
• Las instalaciones de la organización presenta goteras debido a la falta de mantenimiento.
• Las instalaciones de la organización no tiene planta eléctrica, o algún sistema de
contingencia para fallas eléctricas.
• Las instalaciones están ubicadas en una región con gran cantidad de lluvias, y están
ubicadas a corta distancia de un río.
• El centro de cómputo esta descentralizado y no tiene un lugar determinado, el rack de
conexión esta en un lugar de acceso público.

5.3.1.4. Análisis de controles existentes

El principal objetivo de este paso, es analizar los controles de seguridad que se han implementado
o se planea implementar en la organización, para minimizar o eliminar la probabilidad de
ocurrencia de una amenaza frente a una vulnerabilidad existente. A partir de este paso, se pueden
conocer en qué estado está la organización frente a las vulnerabilidades, en qué nivel de protección
se encuentra y qué falta por prevenir o corregir. De esta manera, y cómo resultado de la ejecución
del procedimiento que significa este paso, se tendrá una lista de los riesgos a los que está expuesta
la organización, luego de analizar cuáles de las vulnerabilidades están salvaguardadas y cuales no.

A continuación se listan algunos métodos, categorías y técnicas, que pueden ayudar a ejecutar la
identificación y análisis de los controles existentes.

39
Métodos de los controles
Al identificar los controles de seguridad de la organización, se puede tener en cuenta que estos,
utilizan dos métodos, el técnico y el no técnico. Los controles técnicos son mecanismos de
protección que están incorporados en hardware, software o firmware, por ejemplo, mecanismos de
control de acceso, de identificación o autenticación, de encripción, sistemas detectores de intrusos,
etc. Los no técnicos consisten en controles administrativos y operativos, tales como, políticas de
seguridad, procedimientos referentes a la seguridad del personal, la seguridad física o del
ambiente.

Categorías de los controles

Dentro de los métodos descritos anteriormente, se puede tener en cuenta también una clasificación
por categorías: preventivos y detectivos. El objetivo de los controles preventivos, es rechazar los
intentos de violación a la seguridad de la organización; mientras que los controles detectivos,
informan de los intentos de violación a la infraestructura de seguridad.

Técnica de análisis de controles

Como se detalló anteriormente en este documento, en este caso, las listas de chequeo de
requerimientos de seguridad pueden ser útiles para realizar un análisis eficiente y sistemático de
los controles. Las listas de chequeo pueden ayudar a determinar la conformidad o no conformidad
de los requerimientos de seguridad de la organización frente a los controles que están o van a ser
implementados.

En este punto de este primer proceso, denominado análisis de riesgos, y luego de haber hecho la
identificación de las amenazas y vulnerabilidades existentes, y de los controles que cubren parcial
o totalmente dichas debilidades, se tendrá entonces como resultado una lista de los riesgos
asociados, a los que está expuesta la organización, los cuáles serán aquellos que no tienen un
control específico implementado, que mitigue o elimine la probabilidad de la materialización de la
amenaza que representa el riesgo.

Para la organización Soluciones Informáticas Paquita S.A, se identificaron los siguientes controles
existentes, entre otros:
• Firewall Checkpoint FW-1/VPN-1: a partir de este control se previene el acceso de
software malintencionado y se logra controlar la entrada a la red por solo personas
autorizadas basadas en políticas de la red en base a las configuraciones.
• Autenticación de usuarios al conectarse a la red inalámbrica, mediante WEP. Este control
de autenticación es débil, los datos no se transmiten de forma cifrada.
• Las conexiones remotas se hacen utilizando una VPN (Virtual Private Network), la cual
controla el acceso remoto a partir de un medio seguro y privado.
• Se tiene implementada una zona desmilitarizada, con el fin de controlar los servicios
prestados por el servidor, el cual presta servicio de Correo, Webmin, WebMail, FTP,
SSH. El servidor de Archivos (PEDECE) se encuentra localizado en la LAN como puede
notarse en el diagrama de infraestructura de red (Figura 3).

Los pasos siguientes, están orientados a la determinación de la probabilidad de ocurrencia de cada

uno de los riesgos identificados anteriormente, y el impacto de los mismos, en el caso en que se
materializara el riesgo, y no haya control implementado.

40
 5.3.1.5. Determinación del numero de ocurrencias

Cada uno de los riesgos identificados anteriormente, representa un evento en el cual dicho riesgo
se materializaría. Estos eventos no suceden una única vez, pueden llegar a suceder varias veces, en
un período de tiempo determinado. Para efectos de practicidad y manejo de la presente guía
metodológica, se tendrán en cuenta períodos anuales para todos los cálculos e información acerca
de los eventos.

Así, la probabilidad de ocurrencia de un riesgo, estará definida como, el número de ocurrencias de

un evento en un período de un año, que de ahora en adelante también llamaremos NOA (Número
de Ocurrencias Anuales)

Pr obabilidad = No. de ocurrencias del evento al año

De esta forma, cada uno de los riesgos que se tienen listados, como resultado de la ejecución de los
numerales anteriores, tendrá asociado un NOA, que deberá ser mayor a 0 (cero) en cualquier caso,
ya que, un riesgo que tuviera 0 ocurrencias al año, no tendría sentido tratarlo. Podrán haber valores
entre cero y uno, en el caso que por ejemplo, un evento se presente una vez cada dos años, en
donde el NOA sería de 0,5.

Para determinar el número de ocurrencias anuales, y como se había sugerido anteriormente en la

explicación del modelo que se sigue en esta guía metodológica, existen varias formas de hacerlo,
tomando los datos de diferentes fuentes, pero se sugiere la primera de ellas, debido a que es un
dato más realista y propio de la empresa. Dichas fuentes de información son:

• Registros históricos de eventos: esta es la fuente de información más deseable para el

número de ocurrencias de los eventos. Consiste en tomar dicho dato de cada evento, de
los logs, historiales, registros de software o hardware, que hayan sucedido en períodos
anteriores.

• Organizaciones similares: alternativamente se puede tratar de buscar los datos de

organizaciones similares, con respecto al evento del riesgo que se esté evaluando. Cuando
se trata de una organización similar, se espera que esta sea parecida en su tamaño, sector,
ingresos anuales, etc. Comúnmente dicha información de una organización no es de
dominio público por cuanto es confidencial y probablemente no sea sencillo de obtener.

• Fabricantes y/o Vendedores: otra forma de obtener datos del número de ocurrencias de
un evento, es de forma estadística, a través de reportes que algunos fabricantes y/o
vendedores de soluciones de seguridad informática, tienen a disposición del público en
sus sitios Web, reportes vía correo electrónico, foros, etc.

Para el caso de ejemplo que se esta llevando, se podría estimar el numero de ocurrencias a partir de
los registros históricos de eventos ocurridos en periodos anteriores, ya que la amenazas
identificadas para nuestro ejemplo son independientes a la infraestructura organizacional, y
características de la misma.

El número de ocurrencias Anuales (NOA) de las amenazas identificadas en la sección 5.3.1.2

serían:

41
 Riesgo NOA
Corte servicio eléctrico 50 *
Penetración a la red vía inalámbrica. 20
Denegación de servicio del servidor 2†
archivos
Inundación del centro de cómputo ♠
0.5
Ingeniería Social 15
Tabla 5: Ejemplo - número de ocurrencias

* El corte de servicio eléctrico, se estima en número de horas anuales.

† La denegación de servicio del servidor archivos es estima en número de horas anuales.
♠
El número de ocurrencias anuales es de 0.5, ya que dicho evento ocurre una vez cada dos años.

Teniendo ahora la lista de riesgos y el NOA asociado para cada uno, se puede proceder a asignar a
cada uno de ellos, y basado en el número de ocurrencias determinado, un nivel de ocurrencia
cualitativo con valores de Alto, Medio o Bajo, con base en unos rangos de valores que debe
determinar la organización misma para cada uno de los riesgos, a través del personal que esté
realizando este proceso. Estos rangos no pueden ser generalizados, debido a que, como se ha
explicado anteriormente, las organizaciones no son iguales y de su naturaleza, misión, objetivos
principales, tipo, etc., depende la importancia o nivel de criticidad de un riesgo para una
organización determinada. Es decir, por ejemplo, en una organización X, un riesgo A con tres
ocurrencias anuales, puede ser de criticidad alta, mientras que para una organización Y, el mismo
riesgo con el mismo número de ocurrencias, sea de criticidad media o baja.

La organización Soluciones Informáticas Paquita S.A, para dicho proceso determino un rango de
ocurrencias, para clasificar el nivel de criticidad de ocurrencia para cada una de las amenazas en
estudio, estos rangos son:

• Corte servicio eléctrico

Rango NOA Criticidad NOA

0 - 19 BAJO
20 – 44 MEDIO
> 45 ALTO
Tabla 6: Ejemplo –NOA corte servicio eléctrico

• Penetración a la red vía inalámbrica.

Rango NOA Criticidad NOA

0-2 BAJO
3–7 MEDIO
>8 ALTO
Tabla 7: Ejemplo –NOA penetración a al red inalámbrica

• Denegación de servicio del servidor de archivos

42
 Rango NOA Criticidad NOA
0-5 BAJO
6 – 24 MEDIO
> 25 ALTO
Tabla 8: Ejemplo –NOA denegación de servicio del servidor de archivos

• Inundación del centro de cómputo

Rango NOA Criticidad NOA

0–1 BAJO
2–3 MEDIO
>4 ALTO
Tabla 9: Ejemplo –NOA inundación del centro de cómputo

• Ingeniería Social

Rango NOA Criticidad NOA

0-5 BAJO
6 – 15 MEDIO
> 16 ALTO
Tabla 10: Ejemplo –NOA ingeniería social

*Los niveles de criticidad NOA son determinados por la organización, el número de niveles puede
ser mayor o menor si así la organización lo ve necesario, así mismo con los rangos de ocurrencia
anual.

A partir de esta especificación de rangos para la organización, se obtiene la siguiente clasificación

de criticidad de riesgos identificados:

Riesgo NOA Criticidad NOA

Corte servicio eléctrico 50 ALTO
Penetración a la red vía inalámbrica. 10 ALTO
Denegación al servidor de archivos 2 BAJO
Inundación del centro de cómputo 0.5 BAJO
Ingeniería Social 15 MEDIO
Tabla 11: Ejemplo –nivel Criticidad NOA

En resumen, hasta este punto del análisis de riesgos, se debe tener una lista de riesgos, cada uno
con un NOA asignado, y con un nivel de criticidad basado en dicho dato. Es importante tener los
dos datos anteriores, cuantitativo el primero, y cualitativo el segundo, para cada riesgo, debido a
que con el cualitativo se podrán priorizar posteriormente los riesgos, y con el cualitativo (NOA) se
podrán ejecutar los cálculos para la estimación del retorno de la inversión.

5.3.1.6. Determinación del impacto

El objetivo principal de este paso, es determinar, para cada uno de los riesgos, el impacto de una
ocurrencia del evento que materializaría cada uno de dichos riesgos, lo que llamaremos también
Costo Unitario de Impacto (CUI)

43
De la misma forma como se describió en el paso anterior, se tendrán dos valores de impacto para
cada riesgo, una cualitativo (CUI; en dinero) y uno cuantitativo que representa también el nivel de
criticidad (Alto, Medio, Bajo).

Primero, para determinar el CUI para cada riesgo, se deben tener en cuenta la mayor cantidad de
factores que puedan generar un costo a la organización en el momento en que se presentase el
evento que materialice el riesgo que se esté evaluando. Es decir, se deben sumar aritméticamente
todos los costos causados por los daños ocasionados a la organización en la ocurrencia del evento.
Cada organización es responsable de determinar cuáles son dichos factores a tener en cuenta,
dependiendo de las condiciones de la empresa y de las características del evento presentado; sin
embargo, y como se ha hecho a lo largo de la guía metodológica, a continuación se sugieren
algunos de los factores a tener cuenta para el cálculo de los costos de impacto:

• Número de horas de inactividad parcial o total en la organización debido al evento, y el

costo que esto implica
• Costo por hora del personal afectado o con labores paralizadas
• Costo por hora del personal necesario para la recuperación del sistema o sistemas
afectados
• Costo de pérdida de productividad por hora de inactividad
• Costo de posibles pérdidas de información crítica
• Número de transacciones perdidas por hora
• Costo de mantenimiento de software o hardware afectado en el evento
• Costos de recuperación de infraestructuras físicas afectadas
• Costo de recuperación de equipos de cómputo, equipos de red, etc.
• Costos por posibles daños a terceros

Ahora bien, con base en el CUI de cada riesgo, se debe determinar el nivel de criticidad para cada
uno de ellos, según las características y condiciones dadas en cada organización en particular. Este
nivel de criticidad, al igual que para el NOA, se debe asignar en una escala de Alto, Medio o Bajo.

Hasta este punto del proceso de análisis de riesgos, se tendría entonces, una lista, en donde cada
riesgo tendrá su respectivo NOA, CUI, y el nivel de criticidad de los valores anteriores. Es decir se
debe tener una tabla similar a esta:

Riesgo NOA Criticidad NOA CUI Criticidad CUI

Tabla 12: Nivel criticidad CUI

Para cada uno de los riesgos a los cuales esta expuesta la organización Soluciones Informáticas
Paquita S.A, se tuvieron en cuenta los siguientes aspectos para determinar el CUI:

• Corte de servicio eléctrico:

Factor CUI ($Dólares)*

♠ $600
1. Inactividad organizacional
2. EL costo promedio de información perdida a $100
causa de un corte eléctrico
3. El costo promedio de costos de reparación de $10

44
 daños causados a equipos por cada corte
eléctrico
TOTAL $710
Tabla 13: Ejemplo –CUI corte servicio eléctrico

* El costo corresponde al impacto causado por una hora sin servicio eléctrico.
♠
El costo de inactividad organizacional por cada hora sin servicio eléctrico es calculado a partir de
la siguiente información:

o La totalidad de la organización es paralizada si no se presta el servio eléctrico.

o El costo total de nómina de tener a los 32 empleados por hora es: $200
o Producción organizacional por hora: $400

• Penetración a la red vía inalámbrica:

Factor CUI ($Dólares)

1. Valor promedio de información perdida $200
2. Costo promedio de recuperación de $100
información perdida.
3. Costo de daños causados a terceros (clientes) $300
TOTAL $600
Tabla 14: Ejemplo –CUI penetración a la red vía inalámbrica

• Denegación al servidor de Archivos:

Factor CUI ($Dólares)*

♠ $300
1. Inactividad organizacional
TOTAL $300
Tabla 15: Ejemplo –CUI denegación de servicio del servidor de archivos

* El costo corresponde al impacto causado por una hora sin acceso al Servidor de Archivos
(PEDECE).
♠
El costo de inactividad organizacional por cada hora sin acceso al Servidor de Archivos
(PEDECE) es calculado a partir de la siguiente información:

o La organización es paralizada parcialmente, personal afectado por dicho evento

es de un 50% que corresponde a 16 empleados.
o El costo total de nómina de tener a 3 empleados por hora es: $100
o Producción organizacional por hora: $400. El evento afecta al 50% de la
organización, por lo tanto el costo hora de producción sería de $200.

• Inundación centro de cómputo:

Factor CUI ($Dólares)

1. Recuperación de daños causados a equipos $2.000

45
 afectados.
2. Costo promedio de recuperación de $1.000
información perdida.
3. Costo de inactividad organizacional $1.500
TOTAL $4.500
Tabla 16: Ejemplo –CUI inundación centro de cómputo

• Ingeniería Social:

Factor CUI ($Dólares)

1. Daños causados por acceso a la red $100
malintencionado
TOTAL $100
Tabla 17: Ejemplo –CUI ingeniería social

En la organización Soluciones Informáticas Paquita S.A, para la clasificación del nivel de

criticidad CUI, se definieron los siguientes rangos:

Rango CUI* Criticidad CUI*

($Dólares)
0 - 199 BAJO
200 – 599 MEDIO
> 600 ALTO
Tabla 18: Ejemplo –Rango nivel CUI

*Los niveles de criticidad CUI son determinados por la organización, el número de niveles puede
ser mayor o menor si así la organización lo ve necesario, así mismo con los rangos de CUI.

El costo unitario de Impacto (CUI) y grado de criticidad CUI, para cada uno de los riesgos
identificados en el ejemplo sería:

Riesgo CUI Criticidad CUI

Corte servicio eléctrico $710 ALTO
Penetración a la red vía inalámbrica. $600 ALTO
Denegación al servidor de archivos $300 MEDIO
Inundación del centro de cómputo $4.500 ALTO
Ingeniería Social $100 BAJO
Tabla 19: Ejemplo –Nivel criticidad CUI

Hasta este punto del proceso de análisis de riesgos, se tendría entonces, una lista, en donde cada
riesgo tendrá su respectivo NOA, CUI, y el nivel de criticidad de los valores anteriores. Es decir
para el ejemplo que se esta llevando a cabo esta sería la información obtenida hasta este momento
en el proceso de Administración de Riesgos:

46
 Riesgo NOA Criticidad NOA CUI Criticidad CUI
Corte servicio eléctrico 50 ALTO $710 ALTO
Penetración a la red vía inalámbrica. 10 ALTO $600 ALTO
Denegación al servidor de archivos 2 BAJO $300 MEDIO
Inundación del centro de cómputo 0.5 BAJO $4.500 ALTO
Ingeniería Social 15 MEDIO $100 BAJO
Tabla 20: Ejemplo – Nivel criticidad NOA y nivel criticidad CUI

5.3.1.7. Determinación del nivel de riesgo

Con la ejecución de este paso, se busca obtener una lista priorizada de los riesgos que se han
relacionado en la tabla anterior. En este punto, y como se había mencionado anteriormente, se
utilizarán para cada riesgo, los niveles de criticidad asociados, tanto para el número de ocurrencias
anuales (NOA) como para el costo unitario de impacto (CUI).

Con base en la siguiente tabla, se agregará una columna más a la tabla anterior, con el nombre de
Criticidad del Riesgo, que se definirá con base en la relación entre la criticidad del NOA y del
CUI, de la siguiente manera:

Criticidad CUI
Criticidad NOA
Bajo Medio Alto
Alto Bajo Medio Alto
Medio Bajo Medio Medio
Bajo Bajo Bajo Bajo
Tabla 21: Relación criticidad NOA - CUI

Al relacionar la criticidad del NOA con la criticidad del CUI de cada uno de los riesgos, se podrá
establecer entonces, la Criticidad del Riesgo, obteniendo una tabla similar a la siguiente:

Riesgo NOA Criticidad NOA CUI Criticidad CUI Criticidad del Riesgo

Tabla 22: Nivel de riesgo

De esta forma, se podrá construir ahora una lista de riesgos priorizada, en donde quedarán los
riesgos con criticidad Alta y Media únicamente. Esta lista será la base para las recomendaciones y
estimaciones del retorno a las inversiones, de aquí en adelante. Se tratarán únicamente dichos
riesgos, debido a que son los que más criticidad representan tanto en impacto como en número de
ocurrencias para la organización.

Para el ejemplo en curso, la clasificación del nivel de riesgo a partir de la tabla 21 de clasificación
de riesgo, daría como resultado la siguiente tabla del orden de prioridad:

Riesgo NOA Criticidad CUI Criticidad Criticidad del

NOA CUI Riesgo
Corte servicio eléctrico 50 ALTO $710 ALTO ALTO
Penetración a la red vía inalámbrica 10 ALTO $600 ALTO ALTO

47
Denegación al servidor de archivos 2 BAJO $300 MEDIO BAJO
Inundación del centro de cómputo 0.5 BAJO $4.500 ALTO BAJO
Ingeniería Social 15 MEDIO $100 BAJO BAJO
Tabla 23: Ejemplo- Nivel de riesgo

Finalmente, y como también se ha hecho en los anteriores numerales, en este paso se calculará un
valor cualitativo que servirá para el próximo proceso en la estimación del ROSI. Este valor
consiste en el Costo de Recuperación de Impacto Anual (CRIA), el cual ya se había descrito en el
capítulo anterior, y que representa el valor en dinero del impacto anual de cada uno de los riesgos.
Es decir, el costo de recuperación de los daños causados por la ocurrencia de un evento que
representa un riesgo, en un período de un año, por lo que, este valor se puede definir y calcular de
la siguiente manera:

CRIA = CUI × NOA

De esta forma, para cada uno de los riesgos se debe calcular este valor, que como ya se dijo, será
fundamental en la estimación del ROSI. Así, la tabla que se ha venido detallando como ejemplo,
podría verse ahora similar a la siguiente:

Riesgo NOA Criticidad NOA CUI Criticidad CUI Criticidad del Riesgo CRIA

Tabla 24: Valor CRIA

Para la organización Soluciones Informáticas Paquita S.A, el Costo de Recuperación de Impacto

Anual (CRIA) corresponde a la siguiente tabla:

Criticidad Criticidad Criticidad del

Riesgo NOA CUI CRIA
NOA CUI Riesgo
Corte servicio eléctrico 50 ALTO $710 ALTO ALTO $35.500
Penetración a la red vía inalámbrica 10 ALTO $600 ALTO ALTO $6.000
Denegación al servidor de archivos 2 BAJO $300 MEDIO BAJO $600
Inundación del centro de cómputo 0.5 BAJO $4.500 ALTO BAJO $2.250
Ingeniería Social 15 MEDIO $100 BAJO BAJO $1.500
Tabla 25: Ejemplo- Valor CRIA

Como se puede observar en la tabla 25, el nivel de criticidad es superior en los dos primeros
riesgos; corte de servicio eléctrico y Penetración a la red vía inalámbrica, por lo tanto la
organización Soluciones Informáticas Paquita S.A., debería mitigar el riesgo perteneciente a estos
en primera medida, ya que podrían llegar involucrar los activos más importantes de la
organización, y generar el mayor impacto en ellos.

5.3.1.8. Recomendaciones de control

El objetivo de este paso es proveer las recomendaciones de implementación de controles de

seguridad para mitigar o reducir la criticidad de cada uno de los riesgos de la lista priorizada

48
obtenida del punto anterior. De esta manera, a cada uno de los riesgos, se les debe asignar uno o
más controles recomendados para la mitigación de cada uno de ellos, y llevarlo a un nivel de
criticidad aceptable.

Existen hoy en día, una gran cantidad de controles de seguridad asociados a los principales riegos
y vulnerabilidades más comunes. En esta guía metodológica, se recomiendan algunas fuentes
bibliográficas que contienen sugerencias de los controles más utilizados. Las siguientes son las
recomendaciones a consultar:

• NIST SP 800-53: Recommended Security Controls for Federal Information Systems

[ROSS05]
• NIST SP 800-26: Security Self-Assessment Guide for Information Technology Systems.
Revised NIST SP 800-26 System Questionnaire with NIST SP 800-53 References and
Associated Security Control Mappings. [SWAN01]
• NIST SP 800-36: Guide to Selecting Information Security Products- [GRAN03]

Con la ejecución de este paso, no se está obligando a la organización a implementar todas las
recomendaciones de control. Esta guía metodológica solamente busca que el personal encargado
de ejecutarla, sugiera los controles más apropiados y más recomendados, con base en su retorno de
la inversión, y los beneficios que este traería a futuro para la organización.

En el ejemplo se estudiarán solo los controles para los riesgos que representan un nivel crítico para
la organización, ya que son los que deben ser mitigados en el menor tiempo posible, ya que
involucran los activos de la organización.

Para mitigar el riesgo de un corte eléctrico los controles a implementar serían:

Control Costo de control

Compra e instalación de UPS $16.000
Crea políticas de
$1.000
mantenimiento
TOTAL $17.000
Tabla 26: Ejemplo- Costo control de corte eléctrico

Para mitigar el riesgo de penetración a la red vía inalámbrica los controles a implementar serían:

Control Costo de control

Implementación del protocolo
$7.000
WPA (Wi-Fi Protected Access)
TOTAL $7.000
Tabla 27: Ejemplo- Costo control de penetración a la red vía inalámbrica

49
 5.3.2. Proceso No. 2: Estimación del ROSI
Este segundo proceso consiste en la ejecución de un proceso iterativo para cada uno de los riesgos,
mediante el cual se podrá estimar el retorno de las inversiones que cada uno de ellos necesita como
resultado de las recomendaciones de control realizadas en el último numeral de la sección anterior.

Durante la ejecución de este proceso será importante tener en cuenta y disponibles, los costos de
los controles de seguridad recomendados para cada riesgo, así como los costos de impacto o CRIA
de cada uno de ellos. El proceso que se lleva a cabo durante este segundo proceso, se ha detallado
también anteriormente en el capítulo anterior durante la explicación del modelo propuesto; para
efectos de claridad, se puede hacer referencia a dicho capítulo en donde se puede encontrar un
sencillo ejemplo para cada uno de los casos.

Los pasos que se describirán a continuación deben ejecutarse para cada uno de los riesgos que ya
han sido identificados y priorizados en los pasos anteriores. Adicionalmente, debe tenerse en
cuenta que este es un proceso iterativo, el cual se debe ejecutar cada año, con el objetivo de
calcular los beneficios anuales de las inversiones realizadas, y por lo tanto se debe tener en cuenta
en qué año se está desarrollando cada iteración, para lo cual se recomienda una completa
documentación de este proceso.

5.3.2.1. Estimación para el año 1

Para cada uno de los riesgos se debe construir una tabla similar a la siguiente:

Riesgo n Año 1 ($)

Inversión
Impacto
Operación -
Gasto o Ahorro
Tabla 28: Estimación primar año

En el campo correspondiente a Inversión, se debe colocar el total del costo de las inversiones que
representan los controles recomendados para la mitigación del riesgo que se esté tratando. A
continuación en el campo de Impacto, se debe hacer referencia al costo de impacto anual
calculado en pasos anteriores, es decir el CRIA para el riesgo específico. El campo de Operación,
corresponde a los costos de operación que generan las soluciones o controles dados para la
mitigación del riesgo; estos costos pueden incluir, entre otros, los costos de soporte y
mantenimiento. En este caso, por ser la estimación para el primer año, no se tendrán costos de
operación; se tendrán en cuenta a partir del segundo año. Finalmente, en el campo Gasto o
Ahorro, resultará de una resta aritmética, entre los campos Impacto e Inversión. A partir de esta
resta, se pueden identificar dos casos:

Impacto menor que Inversión

Cuando el valor del impacto (CRIA), es menor que el valor de la Inversión, la resta dará como
resultado un valor negativo. En este caso, el valor negativo representa un Gasto Adicional, que se
tendría que hacer en el año, con el objetivo de mitigar el riesgo. Es decir, en el año 1, la inversión
sale más costosa que el impacto, por lo que habría un valor Pendiente por Recuperar, que estaría

50
ubicado en el campo Gasto o Ahorro. Este valor recuperar, es importante tenerlo en cuenta para
las iteraciones de los años posteriores.

En el Ejemplo del presente documento, la estimación para el año 1 del riesgo de penetración a la
red inalámbrica sería:

Riesgo n Año 1 ($)

Inversión $7.000
Impacto $6.000
Operación -
Gasto o Ahorro $-1.000
Tabla 29: Ejemplo- Estimación primer año, penetración a la red vía inalámbrica

El gasto adicional que implicaría la inversión es de $1.000, el cual representa un valor Pendiente
por Recuperar para los años posteriores.

Impacto mayor que Inversión

En este caso, los costos de inversión en controles de seguridad serían menores que los costos de
impacto (CRIA), por lo que la resta aritmética entre estos dos valores, daría un resultado positivo,
representando que en el primer año, ya habría un ahorro con respecto al valor del CRIA; es decir
en este punto, y en este caso, ya se tendría un retorno de la inversión tangible, representado en el
beneficio del ahorro de dinero. Este valor ahorrado, estaría ubicado entonces en el campo de Gasto
o Ahorro, con signo positivo.

Gasto ó Ahorro = CRIA(impacto) − Inversión

En el Ejemplo del presente documento, la estimación para el año 1 del riesgo de corte de servicio
eléctrico sería:

Riesgo n Año 1 ($)

Inversión $17.000
Impacto $35.500
Operación -
Gasto o Ahorro $18.500
Tabla 30: Ejemplo- Estimación primer año, corte de servicio eléctrico

El ahorro con respecto al valor del CRIA es de $18.500, el cual significa un retorno de la inversión
en el primer año, representado en el beneficio del ahorro de dinero.

5.3.2.2. Estimación para el año 2 en adelante

Desde el año 2 en adelante, se debe realizar una nueva iteración sobre el modelo, para cada uno de
los riesgos, asignando nuevos valores en los campos de Impacto y Operación. En el caso de los
costos de operación, se tendrían en cuenta los costos de mantenimiento y/o soporte de la solución
implementada en el año 1. Y en el caso del impacto, se tendrían en cuenta los costos que implica la
reparación de los daños residuales asociados con cada uno de los riesgos. Es decir, el impacto que
probablemente no fue mitigado en su totalidad por la solución implementada.

51
Con base en lo anterior, para el año 2 se tendría una tabla similar a la siguiente:

Riesgo n Año 1 (US$) Año 2 (US$)

Inversión -
Impacto
Operación -
Gasto o Ahorro
Pendiente por recuperar -
Ahorro Total o Saldo por recuperar -
Tabla 31 Estimación para el año 2 en adelante

En este caso, para el año 2 en adelante, el valor calculado para el campo de Gasto o Ahorro, se
calcula de otra forma. Allí se tendrá en cuenta el resultado de la suma aritmética entre los campos
Impacto y Operación del año. De esta forma, esto significaría los gastos en los que incurre la
organización en ese año. En el campo Pendiente por recuperar, se debe colocar el posible valor
negativo que viene del año anterior, es decir, en el caso del año 2, se debe colocar el pendiente por
recuperar del año 1, en el caso en que el impacto haya sido menor que la inversión inicial en dicho
año. Finalmente, el campo Ahorro Total o Saldo por recuperar, puede tener estas dos variantes
debido a que, puede darse el caso en que en el año 2, no se haya recuperado todavía todo el valor
que había pendiente por recuperar de períodos anteriores. Por otra parte, puede que dicho valor
pendiente, se recupere en el año 2, por lo cual se tendría un valor de Ahorro Total, que estaría
representando un retorno a la inversión expresado en el beneficio de ahorro de dinero. En resumen,
este último campo, se puede calcular de la siguiente forma:

Ahorro Total o Saldo por recuperar = (CRIA − Gasto del año) − Pendiente por recuperar

De esta manera, la organización debería poder realizar un proceso iterativo que la lleve a
determinar a lo largo de los años, un valor estimado de los beneficios o retornos que se presentan
debido a las inversiones realizadas en períodos anteriores.

• Estimación del año 2 para el riesgo de Penetración a la red inalámbrica:

Riesgo Penetración a la red inalámbrica Año 1 (US$) Año 2 (US$)

Inversión $7.000 -
Impacto $6.000 $1.500
Operación - $1.000
Gasto o Ahorro $ - 1.000 $2.500
Pendiente por recuperar - $ 1.000
Ahorro Total o Saldo por recuperar - $2.500
Tabla 32 Estimación para el año 2, penetración a la red vía enalámbrica

Como se puede ver en campo de ahorro total, se estima que para en el año 2 hay un
retorno de la inversión de $2.500 a favor de la organización.

• Estimación del año 2 para el riesgo de Corte de servicio eléctrico:

52
Para este caso como pudo verse en la tabla 30, debido a que en el año uno ya se presento
un ahorro de dinero, no se harán las estimaciones para los años posteriores, ya que dicho
ahorro represento un retorno de la inversión de los controles para este riesgo.

53
6. Conclusión

A partir del modelo expuesto anteriormente, se desarrolló una guía metodológica objetivo de esta
investigación, explicando en detalle cada uno de los pasos a seguir para la estimación del ROSI,
considerando posibles condiciones o situaciones particulares de las organizaciones o arquitecturas,
que se han identificado a lo largo de la investigación.

Con base en esta guía metodológica, y como se describió en los objetivos de esta investigación en
el presente documento, se realizará una prueba de la misma, a través de un caso de estudio
definido, en donde se pretende analizar la viabilidad, aplicabilidad, debilidades y fortalezas de la
guía metodológica desarrollada.

Posteriormente se presentarán los detalles de los resultados de la aplicación de la guía

metodológica, y el análisis de los mismos.

54
7. Referencias
[SWAN03] SWANSON, Marianne; BARTOL, Nadya; SABATO, John; HASH, Joan y GRAFFO
Laurie. NIST Special Publication 800-55: Security Metrics Guide for Information Technology
Systems. Washington, Estados Unidos de América. National Institute of Standards and
Technology (NIST), 2003. Disponible en: http://www.csrc.nist.gov/publications/nistpubs/800-
55/sp800-55.pdf

[NIST95] NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY. An Introduction

to Computer Security: The NIST Handbook, Special Publication 800-12 Washington, Estados
Unidos de América. National Institute of Standards and Technology (NIST), 1995. Disponible en:
http://www.csrc.nist.gov/publications/nistpubs/800-12/handbook.pdf

[STON01] STONEBURNER, Gary. NIST Special Publication 800-33: Underlying Technical

Models for Information Technology Security. Gaithersburg, Estados Unidos de América. National
Institute of Standards and Technology (NIST), 2001. Disponible en:
http://csrc.nist.gov/publications/nistpubs/800-33/sp800-33.pdf

[ARDI04] ARDITA, Julio César. El Estado del Arte de la Seguridad Informática. Buenos Aires,
Argentina. Centro de Investigaciones en Seguridad Informática Aislar. 2004. Disponible en:
http://www.criptored.upm.es/guiateoria/gt_m241b.htm

[MCLE03] MCLEAN, Greg y BROWN, Jason. Determining the ROI in IT security. Toronto,
Canadá. CICA. 2003. Disponible en: http://www.davidfrico.com/mclean03.htm

[NSW03] NSW DEPARTMENT OF COMMERCE. Return on Investment for Information

Security. Estados Unidos de América. Government Chief Information Office. 2003. Disponible en:
http://www.oit.nsw.gov.au/content/7.1.15.ROSI.asp

[MAHJ03] MAHJUB, Ghazy M. A Robust Model toward Software Security Return on

Investment. Chicago, Estados Unidos de América. DePaul University. 2003. Disponible en:
http://students.depaul.edu/~gmahjub/ThesisFirstRev.doc

[FOST04] FOSTER, Steve y PACL, Bob. Análisis of Return on Investment for Information
Security. Billerica, MA Estados Unidos de América. Getronics. 2004. Disponible en:
http://www.getronics.com/NR/rdonlyres/en6bl7yole4i5vzvzzzrl5ud3klueu2ex5mnyt2it3zwuivhfke
nfftpxjn3gsewh3bihoeconfdy3u5x33zpw2mqlb/SecurityROI.pdf

[DAUG04] DAUGHTREY, Taz y NEARY, Becky. Return on Security Investment. James

Madison University. 2004. Disponible en: www.educause.edu/ir/library/powerpoint/SPC0401.pps

[SCHW03] SCHWARTZ, Eddie. Security ROI can’t be proved. Estados Unidos de América.
ComputerWorld. 2003. Disponible en:
http://www.computerworld.com/securitytopics/security/story/0,10801,83450,00.html

[WILS03] WILSON, Marcia J. Calculating security ROI is tricky business. Estados Unidos de
América. ComputerWorld. 2003. Disponible en:
http://www.computerworld.com/securitytopics/security/story/0,10801,83207,00.html?SKC=securit
y-83207

55
[KINN02] KINN, David y TIMM, Kevin. Justifying the expense of IDS, Part One: An Overview
of ROIs for IDS. Estados Unidos de América. SecurityFocus. 2002. Disponible en:
http://www.securityfocus.com/infocus/1608

[GASS88] GASSER, Morrie. Building a Secure Computer System. Nueva York, Estados Unidos
de América. Library of Congreso. 1988. Disponible en:
http://www.acsac.org/secshelf/book002.html

[ALSI05] ACADEMIA LATINOAMERICANA DE SEGURIDAD INFORMÁTICA. Unidad 1:

Introducción a la Seguridad de la Información. Microsoft Technet. 2005. Disponible en:
http://www.mslatam.com/latam/technet/cso/Html-ES/home.asp

[MACM02] Computer Science Study Guide. Estados Unidos de América. Gale Group, Macmillan
Referente. 2002. Disponible en: http://www.bookrags.com/sciences/computerscience/security-csci-
01.html

[BRIN95a] BRINKLEY, Donald L. y SCHELL, Roger R. Information Security: An Integrated

Collection of Essays: Essay 1 What is there to worry about? An Introduction to the Computer
Security Problem. California, Estados Unidos de América. ACSAC. 1995. Disponible en:
http://www.acsac.org/secshelf/book001/01.pdf

[BRIN95b] BRINKLEY, Donald L. y SCHELL, Roger R. Information Security: An Integrated

Collection of Essays: Essay 2 Concepts and Terminology for Computer Security. California,
Estados Unidos de América. ACSAC. 1995. Disponible en:
http://www.acsac.org/secshelf/book001/02.pdf

[BAIL95] BAILEY, David. Information Security: An Integrated Collection of Essays: Essay 3 A

Philosophy of Security Management. California, Estados Unidos de América. ACSAC. 1995.
Disponible en: http://www.acsac.org/secshelf/book001/03.pdf

[HARR03] HARRIS, Shon. CISSP Certification: All-in-one Exam Guide. Second Edition.
Emerville, California, Estados Unidos de América. McGraw Hill. 2004

[OUD05] OUD, Ernst Jan. The value to IT of using Internacional Standards. En: Information
Systems Control Journal. Vol. 3. (2005); p. 35-39

[MEKA] MEKATE [.GLOSARIO] En: http://www.mekate.com/glosario-r.html. Fecha de última

consulta: martes 6 de septiembre de 2005.

[SWEE82] SWEENY, Allen H.W. El rendimiento sobre la inversión (ROI): Fundamentos, cálculo
y principios básicos. 1982.

[RUSS91] RUSSELL, Deborah y GANGEMI Sr., G.T. Computer Security Basics. Primera
edición. Estados Unidos de América. O’Reilly & Associates, Inc. 1992

[AZNZS] AS/NZS 4360:1999 Estandar Australiano: Administración de Riesgos. Segunda Edición.

Australia. 2003

[CAVU03] CAVUSOGLU, Huseyin. B.Sc in I.E. The economics of information technology

security. Dallas, Texas, United Status of America. The University of Texas at Dallas. 2003

56
[PAYN02] PAYNE, Shirley C. A Guide to Security Metrics. Estados Unidos de América. SANS
Institute. 2002. Disponible en:
http://www.sans.org/rr/papers/download.php?id=55&c=4f096b16c5b7e00c7bda5a6fac7031e1

[FOUN03] FOUNDSTONE – Strategic Security. Information Security Metrics: Using

Foundstone’s FoundScoreTM to Assign Metrics and Measure Enterprise Risk. Estados Unidos de
América. FoundStone. 2003. Disponible en:
http://www.foundstone.com/resources/whitepapers_registration.htm?file=wp_securitymetrics.pdf

[SOO00] SOO HOO, Kevin J. How Much Is Enough? A Risk-Management Approach to

Computer Security. Estados Unidos de América. Consortium for Research on Information Security
and Policy (CRISP). 2000. Disponible en: http://exted.fullerton.edu/dschatz/Soo_Hoo_Paper.pdf

[BERI05] BERINATO, Scout. A few good metrics. Estados Unidos de América. CSO Magazine
Online, 2005. Disponible en: http://www.csoonline.com/read/070105/metrics.html

[ALSI05-2] ACADEMIA LATINOAMERICANA DE SEGURIDAD INFORMÁTICA. Unidad 2:

Concepto de Análisis de Riesgo. Microsoft Technet. 2005. Disponible en:
http://www.mslatam.com/latam/technet/cso/Html-ES/home.asp

[STON02] STONEBURNER, Gary; GOGUEN, Alice; FERINGA Alexis. NIST Special

Publication 800-30: Risk Management Guide for Information Technology Systems. Gaithersburg,
Estados Unidos de América. National Institute of Standards and Technology (NIST), 2002.
Disponible en: http://csrc.nist.gov/publications/nistpubs/800-30/sp800-30.pdf

[WUSA05] WU, Yu; SAUNDERS, Carol. Decision Making, IT Governance, and Information
Systems Security. Proceedings of the Eleventh Americas Conference on Information Systems,
Omaha, NE, EUA. Agosto 11 – 14, 2005. Disponible en:
http://aisel.isworld.org/proceeding_passwordAMCIS2005.asp?Vpath=AMCIS/2005&PDFpath=SI
GSEC02-1133.pdf

[JELE98] JELEN, George F.; WILLIAMS, Jeffrey R. A Practical Approach to Measuring

Assurance. SSE-CMM Systems Security Engineering – Capability Maturity Model. Estados
Unidos de América. 1998. Disponible en: http://www.sse-cmm.org/docs/Measuring.pdf

[CANO04] CANO, Jeimy J. Apuntes sobre la inversión y gestión de la seguridad informática.

Colombia. Julio de 2004. Disponible en: http://www.criptored.upm.es/descarga/GestionSeg04.zip

[JAHN05] JAHNER, Stefanie; KRCMAR, Helmut. Beyond technical aspects of information

security: Risk culture as a success factor for IT risk management. Proceedings of the Eleventh
Americas Conference on Information Systems, Omaha, NE, EUA. Agosto 11 – 14, 2005.
Disponible en:
http://aisel.isworld.org/proceeding_passwordAMCIS2005.asp?Vpath=AMCIS/2005&PDFpath=SI
GSEC02-1448.pdf

[RAMA04] RAMACHANDRAN, Sriraman. WHITE, Grez B. Methodology to determine Security

ROI. Proceedings of the Eleventh Americas Conference on Information Systems, Omaha, NE,
EUA. Agosto 11 – 14, 2005. Disponible en:
http://aisel.isworld.org/proceeding_passwordAMCIS2004.asp?Vpath=AMCIS/2004&PDFpath=SI
GSEC01-1646.pdf

57
[GRAN03] GRANCE, Timothy. STEVENS, Marc. MYERS, Marissa. NIST Special Publication
SP 800-36: Guide to Selecting Information Technology Security Products. Washington, Estados
Unidos de América. National Institute of Standards and Technology (NIST), 2003. Disponible en:
http://csrc.nist.gov/publications/nistpubs/800-36/NIST-SP800-36.pdf

[ROSS05] ROSS, Ron. KATZKE, Stu. JOHNSON, Arnold. SWANSON, Marianne.

STONEBURNER, Gary. ROGERS, George. LEE, Annabelle. NIST Special Publication SP 800-
53: Recommended Security Controls for Federal Information Systems. Washington, Estados
Unidos de América. National Institute of Standards and Technology (NIST), 2005. Disponible en:
http://csrc.nist.gov/publications/nistpubs/800-53/SP800-53.pdf

[SWAN01] SWANSON, Marianne. NIST Special Publication SP 800-26: Security Self –

Assessment Guide for Information Technology Systems. Washington, Estados Unidos de América.
National Institute of Standards and Technology (NIST), 2001. Disponible en:
http://csrc.nist.gov/publications/nistpubs/800-26/sp800-26.pdf

58