El precepto fundamental de la seguridad de la información es soportar la misión y activos de la organización, por tanto la gestión de riesgos es una función de gestión por encima de ser una función tecnológica. Todas las organizaciones desde las más grandes a las PYMES se ven expuestas a riesgos crecientes, algunos de los cuales impactan de una manera negativa en dichas organizaciones (robo de datos-identidades, modificación y/o escucha clandestina de información, daños humanos, medioambientales y físicos, degradación de la reputa-ción/imagen de empresas y personas, indisponibilidad, repudio, etc.). Desde la perspectiva de seguridad de las TIC/ICT la gestión de riesgos es el proceso de entender y responder a los factores que pueden conducir a algún fallo en la confidencialidad, integridad o disponibilidad de un sistema de información. El riesgo es función de la probabilidad de que una fuente de amenaza ejercite una vulnerabilidad potencial concreta y del impacto/criticidad que resulta de tal evento adverso sobre la organización. Una amenaza representa el potencial de que una fuente de amenaza ejercite (accidentalmente arranque o intencionalmente explote) una vulnerabilidad específica. Una fuente de amenaza es bien un intento  método dirigido a la explotación intencionada de una vulnerabilidad o bien una situación y método que pueda accidentalmente arrancar una vulnerabilidad. Una vulnerabilidad es una debilidad/defecto o fallo/bug en los procedimientos de seguridad del sistema, en el diseño, en la implementación o en los controles internos que pueda ser ejercitada (accidentalmente arrancada o intencionadamente explotada) y de lugar a una brecha de seguridad o a una violación de la política de seguridad del sistema. Existen numerosas metodologías de análisis y gestión de riesgos, la elección de una u otra depende de factores específicos de la organización, pero se infiere que aquellas que permiten desarrollar principios de seguridad que se adaptan a los mercados y perfiles de las organizaciones son de mayor interés y penetración. Así mismo, parece muy positivo implicar como participantes a todos los integrantes de la organización utilizando herramientas como la creación de reuniones específicas.

Metodología de valoración de riesgos octave. Evolución-métodos
OCTAVE (Operationally Critical Threat, Asset and Vulnerability Evaluation) es una metodología que mejora el proceso de toma de decisiones que tiene que ver con la protección y gestión de recursos de una organización, así como una herramienta de análisis de riesgos. Se pueden identificar principalmente dos métodos OCTAVE: el utilizado para grandes empresas de trescientos o más empleados y el OCTAVE-S para organizaciones con pocos empleados (por ejemplo PYMES). En junio de 1999 la Universidad de Carnegie Mellon publica OCTAVE Framework, versión 1.0. En septiembre de 2001 se publica OCTAVE Method versión 2.0 y en diciembre de 2001 se publica OCTAVE Criteria, versión 2.0, todas ellas para grandes organizaciones con jerarquía multi-nivel. En septiembre de 2003 se publica OCTAVE-S  versión 0.9 y en marzo del 2005 se publica OCTAVE-S versión 1.0 adecuadas para organizaciones más pequeñas (con 20 a 80 empleados) con estructura jerárquica plana. En junio del 2007 se publica OCTAVE Allegro versión 1.0 que mejora la capacidad de la organización para realizar la valoración de riesgos, por ejemplo cuando los activos de información son el foco de la valoración de riesgos de seguridad otros activos relacionados se consideran contenedores de información, almacenando, procesando o transportando activos de información. Los contenedores de información pueden ser personas, objetos (papeles) o tecnología (bases de datos); las amenazas a los activos de información se analizan considerando donde viven y limitando el número y tipos de activos en el proceso.

Pueden identificarse como principales aspectos de OCTAVE: (i) Es auto-dirigida, las personas de la organización realizan de hecho la evaluación y son conscientes de los requisitos y operaciones de la organización. (ii) Se enfoca en el riesgo de la organización y en las cuestiones estratégicas y las relacionadas con las prácticas. (iii) Utiliza un pequeño equipo de personas pertenecientes a unidades operacionales (de negocio) y del departamento de tecnologías de la información. (iv) Su enfoque se basa en conducirse por las prácticas de seguridad y riesgo operacional, la tecnología sólo se examina en relación a las prácticas de seguridad. OCTAVE establece pues un equilibrio entre tres aspectos: riesgo operacional, tecnología y prácticas de seguridad. OCTAVE permite un distinto comienzo y fin en las actividades de gestión de riesgos de las organizaciones, puede realizarse tanto de forma puntual-eventual como de forma periódica.

Como principales diferencias identificadas en relación a otros métodos: (a) Permite la evaluación de las organizaciones mientras que otros métodos sólo evalúan el sistema. (b) Se enfoca en las prácticas de seguridad mientras que otros métodos sólo se enfocan en la tecnología. (c) Aborda cuestiones estratégicas mientras que otros métodos sólo abordan cuestiones tácticas. (d) Permite auto-dirección, mientras que otros métodos son conducidas sólo por expertos.

OCTAVE presenta tres características clave: (i) Un equipo interdisciplinar, denominado equipo de análisis que realiza la evaluación. (ii) Cuando se caracteriza la visión organizacional global de riesgo de seguridad de la información se tienen en cuenta dos  perspectivas importantes, tanto la de negocio como la de TIC. (iii) Es un enfoque de evaluación del tipo conducido por activos. La valoración del riesgo de OCTAVE se basa en tres principios básicos de administración de seguridad: confidencialidad, integridad y disponibilidad por medio de una clasificación simple de información crítica se generará un plan de protección para la información dada. OCTAVE define un enfoque sistemático para toda la organización con vistas a evaluar los riesgos de seguridad de la información.  

En el enfoque OCTAVE se define sobre un conjunto de criterios que incluyen un conjunto de principios, atributos y salidas: (1) Los principios. Son conceptos fundamentales que conducen la naturaleza de la evaluación. Constituye el enfoque y proporciona la base para la evaluación. Por ejemplo la auto-dirección es uno de los principios de OCTAVE, el concepto de auto-dirección significa que las personas dentro de la organización se encuentran en la mejor posición para liderar la evaluación y la toma de decisiones. Los requisitos de la evaluación se embeben en los atributos y salidas. (2) Los atributos. Son cualidades o características de la evaluación que se pueden distinguir. Definen lo que hace que la evaluación tenga éxito. Son los requisitos que definen los elementos básicos del enfoque OCTAVE. Definen lo que es necesario hacer para que la evaluación sea un éxito desde las perspectivas de procesos y organizacional. Los atributos se derivan de los principios, por ejemplo, uno de los atributos de OCTAVE es que un equipo multidisciplinar denominado el equipo de análisis compuesto por personal de la organización conduce la evaluación. El principio que subyace tras la creación de un equipo de análisis es la auto-dirección. (3) Las salidas. Es el resultado requerido de cada fase. No se establecen actividades únicas ya que más de una actividad puede realizarse para llevar a cabo las salidas de OCTAVE. Las salidas definen los resultados que un equipo de análisis debe producir durante la evaluación.

Fases de la evaluación de riesgo con OCTAVE
El enfoque OCTAVE permite a las organizaciones entender, valorar y hacer frente a sus riesgos de seguridad de la información desde la perspectiva de la organización. OCTAVE no es un producto sino una metodología conducida por procesos para identificar, priorizar y gestionar los riesgos de seguridad de la información. OCTAVE permite a las organizaciones realizar diferentes funciones: (i) Desarrollar un criterio de evaluación de riesgos cualitativo sobre tolerancias de riesgo operacional. (ii) Identificar activos que son críticos para la misión de la organización. (iii) Identificar vulnerabilidades y amenazas a los activos críticos. (iv) Determinar y evaluar consecuencias potenciales para la organización si se realizan las amenazas. (v) Iniciar acciones correctivas para mitigar los riesgos y crear la estrategia de protección basada en prácticas.

En el proceso de OCTAVE, se pueden identificar las tres siguientes fases de evaluación de riesgos que se implantan como series progresivas de workshops: (1) Fase-1 (visión-evaluación organizacional). Se trata de construir los perfiles de amenazas basados en los activos. Se identifican los activos importantes, lo que se debe hacer para proteger los activos y los requisitos de seguridad para cada activo. El equipo de análisis determina los activos críticos y que se hace actualmente para protegerlos. Se identifican los requisitos de seguridad para cada activo crítico. Finalmente se establecen las vulnerabilidades organizacionales con las prácticas existentes y el perfil de amenazas para cada activo crítico. (2) Fase-2 (visión-evaluación tecnológica). El equipo de análisis identifica los caminos de acceso por red y las clases de componentes TIC relacionados con cada activo crítico. El equipo luego determina la extensión a la que cada clase de componente es resistente a los ataques de red y establece las vulnerabilidades tecnológicas que exponen a los activos críticos. Se trata de identificar las vulnerabilidades técnicas de infraestructura. Se examinan los caminos de acceso por red, las clases de componentes TIC para cada activo y se determina la resistencia a los ataques de red. (3) Fase-3 (desarrollo de planes y estrategia de seguridad). El equipo de análisis establece-evalúa los riesgos a los activos críticos de la organización en base al análisis de la información recogida y decide qué hacer al respecto. El equipo crea una estrategia de protección para la organización y planes de mitigación para abordar los riesgos identificados. El equipo determina también las siguientes etapas requeridas para la implementación y para ganar la aprobación de la alta dirección al resultado de todo el proceso. Se identifican los riesgos de los activos críticos, se desarrollan estrategias de protección y planes de mitigación y el análisis se basa en las fases previas.

Fases de la evaluación de riesgo con OCTAVE-S y OCTAVE-Allegro
En el proceso de OCTAVE-S, para pequeñas organizaciones se pueden identificar los cuatro siguientes procesos: (1) Proceso-1 (identificar la información de la organización). Consiste en identificar el conocimiento de gestión de alto nivel, el conocimiento de gestión de las áreas operacionales y el conocimiento del personal. (2) Proceso-2 (construir perfiles de amenazas basados en los activos). Consiste en crear el perfil de amenazas, es decir identificar las vulnerabilidades de la organización y amenazas actuales a cada activo crítico. (3) Proceso-3 (identificar las vulnerabilidades de la infraestructura). Consiste en identificar los componentes clave y evaluar los componentes seleccionados de la evaluación tecnológica. El equipo de análisis examina la infraestructura de computación para identificar los componentes relacionados a los activos críticos y vulnerabilidades tecnológicas establecidas. (4) Proceso-4 (desarrollar la estrategia de protección y el plan de mitigación). Consiste en analizar los riesgos y seleccionar el enfoque de mitigación.

En el proceso de OCTAVE-Allegro, se pueden identificar los ocho siguientes procesos organizados en cuatro fases: (1) Fase-1 (establecer drivers). La organización desarrolla criterios de medida del riesgo consistentes con los drivers de la organización. Incluye como Proceso-1 establecer los criterios de gestión de riesgos. (2) Fase-2 (generar el perfil de los activos). Los activos de información que se determina que son críticos, se identifican y se genera el perfil. Este proceso de generar perfil establece las fronteras claras para el activo, identifica sus requisitos de seguridad e identifica todas las localizaciones donde se almacena, transporta o procesa el activo. Incluye los procesos: (i) Proceso-2, desarrollar el perfil del activo de información. (ii) Proceso-3, identificar contenedores del activo de información. (3) Fase-1 (identificar amenazas). Se identifican las amenazas a los activos de información critica en el contexto de las localizaciones donde se guarda, transporta o procesa el activo. Incluye los procesos: (i) Proceso-4, identificar áreas de interés. (ii) Proceso-5, identificar escenarios de amenazas. (4) Fase-4 (identificar y mitigar riesgos). Se identifican y analizan los riesgos a los activos de información y se desarrollan enfoques de mitigación. Incluye los procesos: (i) Proceso-6, identificar riesgos. (ii) Proceso-7, analizar riesgos. (iii) Proceso-8, se selecciona enfoque de mitigación.

Proceso de modelización y análisis de amenazas. Microsoft. Categorías STRIDE y DREAD
El proceso de modelización del riesgo de amenazas de Microsoft ideado para la seguridad del desarrollo de aplicaciones Web, presenta cinco etapas: (i) Identificar los objetivos de seguridad. Los objetivos de seguridad de la aplicación pueden dividirse en las siguientes categorías: (a) Identidad. Ver si la aplicación protege la identidad del usuario de posibles abusos. (b) Pérdida financiera. Elevada si es una aplicación para la banca. (c) Pérdida de reputación si la aplicación es mal utilizada o atacada. (d) Protección de datos del usuario (privacidad, cumplimiento de regulaciones). (e) Garantías de disponibilidad. La aplicación requiere de un SLA (Service Level Agreement). (ii) Analizar la arquitectura y diseño de la aplicación. Revisar los componentes UML, flujos de datos y fronteras de confianza. (iii) Descomponer la aplicación en módulos (por ejemplo el módulo de autenticación, como valida la entrada de datos y las hipótesis que hace el módulo) y características. (iv) Identificar amenazas y vulnerabilidades y utilizar STRIDE/DREAD y vuelta al punto (ii). Un posible listado de amenazas es: atacante puede leer mensajes de otros usuarios; el usuario no puede cerrar sesión en un PC  compartido; la mala validación de datos puede permitir inyección SQL; la autorización puede fallar permitiendo el acceso no autorizado; la caché del navegador Web puede contener contenidos de mensaje. Como contramedidas: implementación de la validación de datos; Implementación de comprobaciones de autorización; implantar directivas anti-caching en cabeceras HTTP; si el riesgo de escuchas clandestinas es elevado utilizar SSL/TLS/SSH. Posibles entidades que pueden atacar una aplicación son: descubrimiento accidental por parte de un usuario ordinario por error funcional de la aplicación; malware automatizado (scripts/programas que buscan vulnerabilidades); atacante curioso; renegados-incomprendidos; atacantes motivados profesionales; crimen organizado, etc.   

STRIDE es un esquema de clasificación para caracterizar amenazas conocidas de acuerdo a las clases de exploit que se utilizan o por los motivos del atacante. El acrónimo STRIDE se forma de la primera letra de cada una de las siguientes categorías: (1) Spoofing de identidad (S). Es un riesgo clave para aplicaciones que tienen muchos usuarios pero proporcionan un único contexto de ejecución en el nivel de la aplicación o base de datos. En concreto los usuarios no deberían convertirse en cualquier otro usuario o asumir los atributos de otro usuario. (2) Tampering with data (T). Los usuarios pueden cambiar potencialmente los datos entregados a ellos, devolverlos y consecuentemente manipular potencialmente la validación del lado del cliente, los resultados GET y POST, las cookies, las cabeceras HTTP, etc. La aplicación no debería enviar datos al usuario, como tasas o períodos de interés que se obtienen sólo desde dentro de la propia aplicación. La aplicación también debería comprobar con cuidado los datos recibidos del usuario y validar que son sanos y aplicables antes de almacenarlos o utilizarlos. (3) Repudio (R). Los usuarios pueden disputar y repudiar transacciones si existe una insuficiente auditoría o registro de sus actividades. Por ejemplo, si un usuario dice “no transfiero dinero a esta cuenta externa” y no se puede seguir sus actividades a través de la aplicación, entonces es muy probable que la transacción tendrá que escribirse como una pérdida. Consecuentemente el considerar si la aplicación requiere controles de no repudio como logs de acceso Web, registros de auditoría en cada capa o el mismo contexto de usuario de arriba abajo. Es preferible que la aplicación debería ejecutarse con los privilegios de usuario, no más, pero esto puede no puede ser posible con muchas plataformas de aplicación. (4) Information disclosure (I). Los usuarios son desconfiados legítimamente de emitir detalles privados a un sistema. Si es posible para un atacante revelar públicamente datos del usuario a lo grande, anónimamente o como un usuario autorizado, existirá una pérdida inmediata de confidencialidad y un período sustancial de pérdida de reputación. Por tanto, las aplicaciones deben incluir controles fuertes para prevenir la captura y abuso del identificador de usuario, concretamente si utilizan un único contexto para ejecutar toda la aplicación. También se debe considerar si el navegador Web del usuario puede fugar información. Algunos navegadores Web pueden ignorar las directivas de no caching en las cabeceras HTTP o manejarlas incorrectamente. Así mismo cada aplicación segura tiene una responsabilidad de minimizar la cantidad de información almacenada por el navegador Web, en caso de fuga de información que puede utilizar un atacante para aprender detalles acerca de la aplicación, el usuario o potencialmente convertirse en ese usuario. A la hora de implementar valores persistentes tener en cuenta que el uso de campos ocultos es por naturaleza inseguro. Tal almacenamiento no debería descansar en información sensible segura o proporcionar las adecuadas salvaguardas de privacidad personal. (5) Denegación de servicios (D). Los diseñadores de aplicaciones deberían ser conscientes de que sus aplicaciones pueden ser sujeto de ataques de denegación de servicios. Por tanto, el uso de recursos caros como ficheros grandes, cálculos complejos, búsquedas muy pesadas o queries de gran longitud deberían reservarse para usuarios autenticados y autorizados y no estar disponible para usuarios anónimos. Para aplicaciones que no tienen este lujo, cada faceta de la aplicación debería ser diseñada por ingeniería para realizar el mínimo trabajo posible, utilizar pocas queries de base de datos rápidas, evitar la exposición a ficheros largos o únicos enlaces por usuario, para prevenir ataques de denegación de servicios simples. (6) Elevación de privilegios (E). Si una aplicación proporciona roles administrativos y de usuario distintos entonces es vital asegurarse de que el usuario no pueda elevar su rol a un privilegio más alto. En concreto, simplemente no visualizar enlaces de rol privilegiado es insuficiente. En su lugar todas las acciones deberían controlarse a través de una matriz de autorización para asegurar que sólo los roles permitidos puedan acceder a la funcionalidad con privilegios.

DREAD es un esquema de clasificación para cuantificar, comparar, ordenar y priorizar la cantidad de riesgo presentado por cada amenaza evaluada. El valor del riesgo se calcula por la fórmula: Riesgo-DREAD = (Daño-potencial + Reproducibilidad + Explotabilidad + Usuarios afectados + Descubribilidad) / 5. El acrónimo DREAD se forma de la primera letra de cada una de las siguientes categorías: (1) Daño-potencial (D). Determina si la amenaza ocurre ¿cuanto daño causará? Relacionado con el concepto de impacto. Una forma de cuantificar esta categoría DREAD es: Nada = 0; Los datos del usuario individual se han visto afectados o comprometidos = 5; Destrucción completa de los datos o del sistema = 10. (2) Reproducibili-dad (R). Determina la facilidad para reproducir el exploit de la amenaza. Relacionado con el concepto de probabilidad. Una forma de cuantificar esta categoría DREAD es: Muy difícil o imposible, incluso para los administradores de la aplicación = 0; Se requiere uno pasos, puede necesitar ser un usuario autorizado = 5; Sólo es suficiente un navegador Web y la barra de dirección, sin autenticación = 10. (3) Explotabilidad (E). Determina lo que se necesita para explotar esta amenaza. También relacionado con el concepto de probabilidad. Una forma de cuantificar esta categoría DREAD es: Programación avanzada y conocimiento de redes con herramientas de ataque avanzadas o a medida = 0; El malware existe en Internet o un exploit se realiza fácilmente utilizando herramientas de ataque disponibles = 5; Sólo un navegador Web = 10. (4) usuarios Afectados (A). Determina el número de usuarios que se verán afectados. También relacionado con el concepto de impacto. Una forma de cuantificar esta categoría DREAD es: Nada = 0; Algunos usuarios, pero no todos = 5; Todos los usuarios = 10. (5) Descubribilidad (D). Determina la facilidad para descubrir esta amenaza. También relacionado con el concepto de probabilidad. Una forma de cuantificar esta categoría DREAD es: Muy difícil o imposible, requiere el código fuente o acceso del administrador = 0; Se puede averiguar o monitorizando las trazas de red  = 5; Detalles de fallos como este están ya a dominio público y pueden ser fácilmente descubiertos utilizando un motor de búsqueda de alto rendimiento como Yahoo/Google = 9; La información esta visible en la barra de dirección del navegador Web o en un formulario = 10.

Consideraciones finales
Nuestro grupo de investigación lleva trabajado más de veinte años en el área del análisis, valoración, evaluación y gestión de riesgos tanto a nivel de redes, tecnologías, organizaciones, unidades de negocios como de ecosistemas y entornos donde las TIC y negocios interactúen de alguna manera. Se han utilizado diferentes metodologías y enfoques.

Este artículo se enmarca en las actividades desarrolladas dentro de LEFIS-Thematic Network.

Bibliografía

-    Areitio, J. “Seguridad de la Información: Redes, Informática y Sistemas de Información”. Cengage Learning-Paraninfo. 2012.
-    Areitio, J. “La gestión de identidades, privacidad estratégica para poder minimizar los riesgos de seguridad de la información”. Revista Conectrónica. Nº 146. Abril 2011.
-    OCTAVE: http://www.cert.org/octave/
-    Landoll, D. “Risk Assessment Handbook: A Complete Guide for Performing Security Risk Assessments”. 2nd Edition. CRC Press. 2011.
-    Pertier, T.R. “Information Security Risk Analysis”. 3rd Edition. Auerbach Publications. 2010.
-    Norman, T.L. “Risk Analysis and Security Countermeasure Selection”. CRC Press. 2009.
-    Vose, D. “Risk Analysis: A Quantitative Guide”. Wiley. 3rd Edition. 2008.
-    Tipton, H.F. “Information Security Management Handbook”. 6th Edition. Vol. 3. Auerbach Publications. 2009.
-    Gollmann, D. “Computer Security”. 3rd Edition. Wiley. 2011.

Autor:

Prof. Dr. Javier Areitio Bertolín – E.Mail: Esta dirección de correo electrónico está siendo protegida contra los robots de spam. Necesita tener JavaScript habilitado para poder verlo.
Catedrático de la Facultad de Ingeniería.
Director del Grupo de Investigación Redes y Sistemas. Universidad de Deusto.

Más información o presupuesto