Una guía metodológica para el cálculo del retorno a la ...pegasus.javeriana.edu.co/~roisinfo/Documentos/Articulos/Entrega4.pdf · Determinación del nivel de riesgo 5.3.1.8

1

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

* [email protected] ♠ [email protected]

2

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

3

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

* [email protected] ♠ [email protected]

4

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.

5

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.

6

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

7

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,

8

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

9

(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.

10

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].

11

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

12

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

13

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

14

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

15

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

16

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.

17

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.

18

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

19

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.

20

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.

21

Probabilidad \ Impacto

Bajo (10) Medio (50) Alto (100)

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

22

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,

23

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.

24

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.

25

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.

26

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:

27

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

28

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

29

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

30

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:

InversiónimpactoCRIAAhorro −= )( 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

31

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:

recuperarporPendienteañodelGastoCRIAAhorro __)__( −−=

25$20)3580( USAhorro =−−= 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.

32

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:

33

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

34

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

35

• Á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.

36

• 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

37

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

38

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.

39

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.

40

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.

41

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)

añoaleventodelsocurrenciadeNoobabilidad .Pr = 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:

42

Riesgo NOA Corte servicio eléctrico 50 * Penetración a la red vía inalámbrica. 20 Denegación de servicio del servidor archivos

2†

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.


Tabla 7: Ejemplo –NOA penetración a al red inalámbrica • Denegación de servicio del servidor de archivos

43


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)

44

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)* 1. Inactividad organizacional ♠ $600 2. EL costo promedio de información perdida a causa de un corte eléctrico

$100

3. El costo promedio de costos de reparación de $10

45

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 información perdida.

$100

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)* 1. Inactividad organizacional ♠ $300

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

46

afectados. 2. Costo promedio de recuperación de información perdida.

$1.000

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 malintencionado

$100

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* ($Dólares)

Criticidad CUI*

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:

47

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 NOA

CUI Criticidad CUI

Criticidad del Riesgo

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

48

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:

NOACUICRIA ×= 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:

Riesgo NOA Criticidad NOA CUI Criticidad

CUI Criticidad del

Riesgo CRIA

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

49

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 mantenimiento $1.000

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 WPA (Wi-Fi Protected Access) $7.000

TOTAL $7.000 Tabla 27: Ejemplo- Costo control de penetración a la red vía inalámbrica

50

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

51

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.

InversiónimpactoCRIAAhorroóGasto −= )( 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.

52

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:

recuperarporPendienteañodelGastoCRIArecuperarporSaldooTotalAhorro −−= )( 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:

53

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.

54

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.

55

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/en6bl7yole4i5vzvzzzrl5ud3klueu2ex5mnyt2it3zwuivhfkenfftpxjn3gsewh3bihoeconfdy3u5x33zpw2mqlb/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=security-83207

56

[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

57

[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=SIGSEC02-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=SIGSEC02-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=SIGSEC01-1646.pdf

58

[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

Documents

Una guía metodológica para el cálculo del retorno a la ...pegasus.javeriana.edu.co/~roisinfo/Documentos/Articulos/Entrega4.pdf · Determinación del nivel de riesgo 5.3.1.8