Krypton Solid

Krypton Solid
Krypton Solid

La última tecnología en raciones de 5 minutos

Aplicación de la norma de gestión de riesgos ISO 27005

El estándar de metodología de gestión de riesgos ISO 27005 tiene debilidades en lo que respecta a la medición de riesgos. La teoría de las «matemáticas difusas» puede ayudar a llenar los vacíos.

ISO 27005, emitida en 2005, llenó un vacío notable en la serie de normas ISO 27000. La norma se titula oficialmente ISO / IEC 27005.2008, «Tecnología de la información – Técnicas de seguridad – Gestión de riesgos de seguridad de la información». La Organización Internacional de Normalización tardó tres años en documentar los estándares para la metodología de gestión de riesgos. Ahora, justo cuando la norma ISO 27005 está ganando terreno, la misma organización ha publicado una nueva norma, ISO 31000.2009, «Gestión de riesgos: principios y directrices». Como resultado, se ha vuelto a introducir cierto desconcierto en un tema que ya era confuso.

Existe una amplia gama de definiciones de la palabra riesgo ISO 27001, a pesar de exigir la gestión de riesgos, no define el término en absoluto. ISO 27001, que contiene los requisitos para un sistema de gestión de seguridad de la información, establece claramente que un SGSI debe «alinearse con el contexto estratégico de gestión de riesgos de la organización», «establecer criterios contra los cuales se evaluará el riesgo» e «identificar una metodología de evaluación de riesgos que sea adecuada al SGSI «.

ISO 27005 define el riesgo como «la posibilidad de que una amenaza determinada explote las vulnerabilidades de un activo o grupo de activos y, por lo tanto, cause daño a la organización». ISO 31000 establece que el riesgo es el «efecto de la incertidumbre sobre los objetivos». La definición que he usado anteriormente para riesgo, «la medición de la incertidumbre del daño a un activo o grupo de activos», se encuentra entre las dos.

Esta disparidad en las definiciones de riesgo se explica en cierta medida por el hecho de que el objetivo de ISO 27005 es un SGSI, mientras que ISO 31000 es un medio para el fin de la gestión de riesgo empresarial. Esto fuerza la cuestión de si el riesgo de seguridad de la información es distinto de, un componente de o subordinado para riesgo organizacional general. Claramente, los riesgos para la información son un subconjunto de los riesgos para la empresa, pero la naturaleza técnica tanto de las amenazas como de las vulnerabilidades los distingue. Si la TI es lo suficientemente diferente de la tecnología de cohetes, la tecnología de cirugía cerebral o la tecnología de plantas de energía nuclear para justificar su propio estándar, es una pregunta excelente, pero sin respuesta.

CONTENIDO RELACIONADO  Las bases de datos administradas de DigitalOcean agregan MySQL, compatibilidad con Redis

Por lo tanto, aquellos que intentan incorporar la gestión de riesgos en un programa de seguridad de la información deben cumplir con los estándares establecidos en ISO 27005, sin contravenir simultáneamente los requisitos, o al menos las intenciones, de ISO 31000.

Gestión y medición de riesgos con ISO 27005

El proceso de gestión del riesgo de seguridad de la información incluye muchos pasos superpuestos y poco diferenciados (o cláusulas, para usar el lenguaje ISO):

  • Establecimiento de contexto
  • Evaluación de riesgos
  • Tratamiento de riesgo
  • Aceptación del riesgo
  • Comunicación de riesgos
  • Monitoreo y revisión de riesgos

¿Cuál es, por ejemplo, el contexto de la gestión de riesgos sino la suma de todos los demás pasos? ¿No incluye la comunicación de riesgos el seguimiento y la revisión? La sección más agresivamente confusa de ISO 27005 es la de evaluación de riesgos, que incluye análisis de riesgos y evaluación de riesgos. El análisis de riesgos a su vez se compone de la identificación y estimación de riesgos. Algunos (pero no todos) de estos términos se definen en el glosario, pero de una manera tan arbitraria que un enfoque alternativo perfectamente válido podría usar los mismos términos de una manera diferente o usar términos diferentes en conjunto y aun así lograr el mismo objetivo: gestionar el riesgo .

Falta en ISO 27005: estimación de riesgos

Lo que no aparece en la norma es la medición del riesgo. Es axiomático que lo que no se puede medir no se puede gestionar. La omisión de la medición del riesgo de la norma es lo suficientemente significativa como para que, ya sea mencionada o no, debe ser realizada por cualquier persona que intente seriamente gestionar el riesgo. La medición se aborda indirectamente mediante la estimación del riesgo, en el mismo sentido que todas las estimaciones son mediciones de algún tipo, pero no al revés «Aproximadamente un pie» no es lo mismo que «12 1/2 pulgadas», como cualquiera que haya tenido que hacerlo. Cortar el vidrio de la ventana puede testificar.

La norma ISO 27005 reconoce la debilidad de su metodología de estimación:

Una metodología de estimación puede ser cualitativa o cuantitativa, o una combinación de estas, según las circunstancias. En la práctica, la estimación cualitativa se utiliza a menudo en primer lugar para obtener una indicación general del nivel de riesgo y para revelar los principales riesgos. Posteriormente, puede ser necesario realizar un análisis más específico o cuantitativo de los principales riesgos porque, por lo general, es menos complejo y menos costoso realizar un análisis cualitativo que cuantitativo.

Todos los riesgos de seguridad de la información, por definición, son relativamente raros y sus efectos son significativos. Si los riesgos fueran comunes pero insignificantes, no se necesitaría ningún estándar para gestionarlos. Por lo tanto, todas las estimaciones cualitativas mostrarían que la magnitud de cualquier riesgo de seguridad de la información es «alta» y la probabilidad «baja», para usar los términos de la norma ISO 27005. Pero si todos los riesgos relevantes se estiman al mismo nivel en las mismas escalas, ¿qué valor tienen las estimaciones?

La alternativa es la estimación cuantitativa. El estándar ISO 27005 establece que esto debe basarse en datos históricos de incidentes, que, dice, tiene «la desventaja [of] la falta de tales datos sobre nuevos riesgos o debilidades de seguridad de la información «. En su influyente libro sobre riesgo,» El cisne negro «, Nassim Nicholas Taleb escribió que» lo que no sabes es mucho más importante que lo que sabes «. Gerente nuevo los riesgos y las debilidades es, o debería ser, el objetivo de la gestión de riesgos.

La dificultad de trabajar con ISO 27005 se refleja en su definición de estimación de riesgo: «el proceso para asignar valores a la probabilidad y consecuencias de un riesgo». El cumplimiento de la norma significa asignar valores a lo incognoscible (probabilidad) y lo desconocido (consecuencias). ¡No es de extrañar que la estimación del riesgo sea una herramienta tan contundente para gestionar el riesgo!

Matemáticas difusas e ISO 27005

La solución para aplicar la ISO 27005 de una manera útil radica en aceptar que, aunque la medición del riesgo no puede ser precisa, puede serlo dentro de límites definidos. Esta es una forma de estimación con rigor en torno al proceso. Existe una metodología para manejar sistemáticamente conceptos que encarnan la imprecisión y la vaguedad: «teoría de conjuntos difusos».

Este campo de las matemáticas, ideado por LA Zadeh en 1965, describe objetos o procesos que no son susceptibles de una definición precisa o medición precisa. Reconoce que hay algunos aspectos de la experiencia humana que no se pueden expresar como cantidades numéricas absolutas, sino más bien como un rango de valores posibles. La teoría de conjuntos difusos se puede utilizar como técnica para modificar o enmendar la metodología de estimación de riesgos en ISO 27005.

En resumen, la aplicación de la matemática difusa a la gestión de riesgos se puede resumir de esta manera:

  • Ignorar probabilidad y reemplazarlo con el concepto de credibilidad. Si un riesgo es creíble, es decir, podría ocurrir de manera realista, debe gestionarse.
  • Encuentre términos cualitativos más razonables que altas, medias y bajas para medir las consecuencias. Estos deben comunicar significado sin necesidad de precisión. La imprecisión en los procesos de pensamiento y razonamiento es una ventaja porque permite transmitir una gran cantidad de información con muy pocas palabras. Por ejemplo, los términos utilizados para medir el impacto pueden variar desde la destrucción total hasta la pérdida de la mayor parte de un activo, la pérdida de parte de un activo, la pérdida de unidades de un activo y la pérdida intrascendente.
  • Asegúrese de que las definiciones de términos cualitativos estén claramente establecidas y ampliamente aceptado en términos semánticos generales, así como dentro de los límites del ejercicio de medición del riesgo.
  • Utilice medidas cuantitativas para los niveles de confianza, no por cantidades en dólares o probabilidades (número de eventos a lo largo del tiempo). En este caso, la confianza es un término ciertamente ambiguo. La confianza se usa en el sentido matemático de estimar un parámetro estadístico (como media o varianza) que tiende a incluir el valor verdadero del parámetro en una proporción predeterminada del tiempo. En otras palabras, el valor dominante en un conjunto difuso se usa para establecer el rango de riesgo, menos la precisión absoluta. No significa seguridad en el sentido conversacional. El teórico Taleb se opone a suponer que el valor con el mayor nivel de confianza realmente ocurrirá.

Sin duda, esto es lo que los autores de ISO 27005 tenían en mente cuando redactaron la norma. Sin embargo, un estándar no es inmutable y se deben abordar sus debilidades. No hacerlo resultará en prácticas de gestión de riesgos que se basan en sesgos y nociones preconcebidas, no evidencia discernible. Sin embargo, el hecho de que la evidencia sea un poco confusa en los bordes no socava el valor de ISO 27005 para medir el riesgo.

Steven J. Ross, CISSP / MP, MBCP, CISA es un escritor colaborador con sede en la ciudad de Nueva York. Háganos saber lo que piensa sobre la historia; Email [email protected]. Seguir @ITCompliance para obtener noticias sobre cumplimiento durante la semana.

¡Haz clic para puntuar esta entrada!
(Votos: Promedio: )

También te puede interesar...

Una introducción a eBPF y dónde brilla

Cada sistema operativo deja margen de mejora. Pero modificar cualquier sistema operativo puede crear riesgos de seguridad y penalizaciones de rendimiento, así como crear dependencias que son casi imposibles de acomodar en la versión del

Cómo solucionar cinco errores de enrutamiento comunes

Cuando me dispuse a tratar de determinar los cinco errores de enrutamiento más comunes, no me di cuenta del desafío que sería reducirlos. Consideré escribir sobre los cinco errores de enrutamiento más molestos, pero rápidamente

Filament Blocklet Chip conecta blockchain y IoT edge

operar de forma autónoma durante los períodos de desconexión. No es de extrañar, entonces, que, como siguiente paso, la compañía anunciara el lanzamiento beta de un chip que permite que el hardware del dispositivo final

¿Qué escollos deben evitar las empresas?

¿Cuáles son los riesgos de seguridad de la migración empresarial a la nube y cómo pueden mitigarse? ¿Cuáles son algunos específicos … las dificultades que deben tener en cuenta las empresas cuando trasladan sistemas o

¿Simular o emular? Esa es la pregunta

¡Construyamos algo! Ya sea en un Parallax BASIC Stamp o en un Samsung Orion, los problemas son casi los mismos. Tiene que construir algo de hardware, desarrollar software a lo largo de la pila de

Crecimiento profesional de un desarrollador de software

Actualmente trabajo como desarrollador de software de alta gama para una empresa de seguros de renombre. Me gustaría saber qué tipo de oportunidades / crecimiento profesional tendré en el futuro. El crecimiento profesional depende de

¿Qué es más rentable para sus aplicaciones?

Consumir recursos solo cuando los necesita parece la forma más obvia de aumentar la eficiencia. Si bien puede apagar un servidor para ahorrar centavos en energía y enfriamiento cuando no está en uso, no puede

¿Qué es Microsoft Powershell Core?

Microsoft PowerShell Core es la versión de código abierto de la herramienta de administración de configuración y automatización de Microsoft PowerShell construida en .NET Core que se ejecuta en sistemas Windows, Linux y macOS. Microsoft

El proceso ETL y MySQL

Si busca en Google para extraer, transformar y cargar (ETL), encontrará una gran cantidad de referencias a las herramientas ETL. La razón por la que se han desarrollado todas estas herramientas es simple: el proceso

MDM de código abierto ofrece flexibilidad, con desafíos

Las plataformas de código abierto pueden requerir más esfuerzo de TI que los productos comerciales, pero también pueden abordar los requisitos específicos de una organización, si la empresa está dispuesta a invertir en los recursos

¿Qué es Istio? Definición de Krypton Solid.

Istio es una tecnología de malla de servicios de código abierto e independiente que permite a los desarrolladores conectarse, proteger, controlar, observar y ejecutar una arquitectura de microservicio distribuida (MSA), independientemente de la plataforma, la

Explore las nuevas funciones de Android Pie

Google agregó algunas funciones a Android Pie, la última versión del sistema operativo de Android, que facilitan a los usuarios trabajar en un teléfono Android. Navegando por Android P de Google Este sistema operativo puede

5 amenazas de seguridad de IoT para priorizar

Con la gran superficie de ataque de IoT y la falta inherente de seguridad, los piratas informáticos tienen más oportunidades de ingresar a las redes de una organización. La industria de IoT no tiene un

¿Qué es Cliente 24/7 o [24]7 Inc?

24/7 Customer es un proveedor de servicios de subcontratación de procesos comerciales (BPO) que proporciona productos de autoservicio al cliente entregados a través de un modelo comercial de software como servicio (SaaS). Cliente 24/7, que

Habilitación de HTTPS en componentes web J2EE

¿Cómo implemento el protocolo HTTPS para JSP? O, ¿cómo se configura SSL en una aplicación web? Mi plataforma es WebLogic 8.1, Windows. La plataforma Java EE (J2EE) define un «Descriptor de implementación web (web.xml)» basado

4 formas de crear una cultura de aprendizaje continuo

Crear una cultura de aprendizaje continuo podría ser el arma secreta para retener a los empleados. Contratar, incorporar y capacitar a nuevos empleados es costoso. Sin embargo, cuando las empresas ofrecen a sus trabajadores una

Waterfall vs Agile vs desarrollo iterativo explicado

No hay un modelo de desarrollo de software único a seguir, aunque los enfoques iterativos e incrementales se están convirtiendo en normas para las organizaciones. Un modelo de desarrollo iterativo es una forma de crear

Deja un comentario