Paloma Llaneza, con gran alegría por ser en parte madre de la criatura nos anuncia que ya tenemos oficialmente una nueva norma dentro del marco ISO 27000.

La nueva norma, oficialmente denominada “Information technology — Security techniques — Information security management — Measurement” viene a sofocar uno de los grandes abismos que existen en el proceso de construcción de un SGSI. Ya he comentado muchas veces que certificarse con ISO 27001 es establecer que las cosas se vigilan dentro de un marco de gestión y que existen procesos de mejora continua sobre el funcionamiento de las medidas de seguridad. Sin embargo, gestionar bien no implica tener buena seguridad. Obviamente ayuda mucho tener un marco de gestión y revisión continua pero es sólo una condición necesaria, no suficiente.

Esta nueva norma establece criterios para la medición del estado de la seguridad. Es aquí donde los datos y las evidencias deben poner al SGSI en su sitio. Es cuando los resultados nos proporcionan información sobre cual es la situación real de las medidas y si están o no funcionando de acuerdo a los objetivos planteados. Por eso es tan importante la publicación de esa norma. Es la única manera de valorar si tanta gestión de la seguridad está sirviendo para algo, y esos hechos avalados por resultados y datos concretos que se están midiendo.

Por tanto, un SGSI certificado y todo que no logre unos buenos resultados en sus indicadores será solo un adorno, dado que habrá una bonita gestión pero con ello no se estará logrando satisfacer los objetivos planteados.

Estas reflexiones ya las plantee de forma más extensa en el post SGSI virtuales en su momento. Os resumo lo que en aquel momento comentaba respecto a las métricas.

La medición debe servir para cuestionarnos continuamente en base a logs, datos y registros si las medidas de seguridad están funcionando bien. Hemos visto que es esencial establecer unos objetivos relevantes para la seguridad de la organización. Pues igual de crítico es establecer un buen conjunto de indicadores que sirvan para evidenciar que las cosas funcionan y podemos dormir tranquilos. Esta información, desde la perspectiva de la gestión, es la más crítica dado que es la base de la retroalimentación del sistema, los datos que se utilizan para hacer ajustes. Por tanto, debemos disponer de sensores de diferente naturaleza y con diferentes objetivos: medir la evolución de la ejecución del plan, valorar el rendimiento y funcionamiento de las medidas de seguridad, vigilar el entorno por si se vuelve más hostil y es necesario modificar la valoración de las amenazas, etc. Cuando se audita, al revisar el análisis de riesgos, mirar qué objetivos tiene el SGSI y en qué indicadores se basa ya te puedes hacer una idea de si tienes delante un SGSI real o virtual. ¿Por qué? Muy sencillo, si la información utilizada por las actividades de gestión es mala, la propia gestión es mala. Si las decisiones no están enfocando los verdaderos problemas y no se está vigilando lo que es importante, el ciclo PDCA da vueltas pero no aporta valor a la Organización. Tener un SGSI dando vueltas de mejora continua produce beneficios pero si quien tiene el timón del barco no sabe dónde tiene que ir, dificilmente podrá lograr llegar a puerto. Serán las incidencias que se vayan registrando las que nos pongan de manifiesto estos hechos pero de nuevo se reacciona en base a fallos, y esa no es la idea principal.

Etiquetas:

http://sgsi-iso27001.blogspot.com/2009/10/ya-es-oficial-iso-27004-nueva-norma.html

Click on pen to Use a Highlighter on this page
Tagged with:
 

Detección de anomalías

next up previous contents
Siguiente: Detección de usos indebidos Subir: Sistemas de detección de Anterior: IDSes basados en red Índice General

Detección de anomalías

Desde que en 1980 James P. Anderson propusiera la detección de anomalías como un método válido para detectar intrusiones en sistemas informáticos ([And80]), la línea de investigación más activa (esto es, la más estudiada, pero no por ello la más extendida en entornos reales) es la denominada Anomaly Detection IDS, IDSes basados en la detección de anomalías. La idea es a priori muy interesante: estos modelos de detección conocen lo que es `normal’ en nuestra red o nuestras máquinas a lo largo del tiempo, desarrollando y actualizando conjuntos de patrones contra los que comparar los eventos que se producen en los sistemas. Si uno de esos eventos (por ejemplo, una trama procedente de una máquina desconocida) se sale del conjunto de normalidad, automáticamente se cataloga como sospechoso.
Los IDSes basados en detección de anomalías se basan en la premisa de que cualquier ataque o intento de ataque implica un uso anormal de los sistemas ([Ko96], [KS94c]…). Pero, >cómo puede un sistema conocer lo que es y lo que no es `normal’ en nuestro entorno de trabajo? Para conseguirlo, existen dos grandes aproximaciones ([BB99]): o es el sistema el que es capaz de aprenderlo por sí mismo (basándose por ejemplo en el comportamiento de los usuarios, de sus procesos, del tráfico de nuestra red…) o bien se le especifica al sistema dicho comportamiento mediante un conjunto de reglas. La primera de estas aproximaciones utiliza básicamente métodos estadísticos (medias, varianzas…), aunque también existen modelos en los que se aplican algoritmos de aprendizaje automático; la segunda aproximación consiste en especificar mediante un conjunto de reglas los perfiles de comportamiento habitual basándose en determinados parámetros de los sistemas (con la dificultad añadida de decidir cuáles de esos parámetros que con mayor precisión delimitan los comportamientos intrusivos).
En el primero de los casos (el basado en métodos estadísticos), el detector observa las actividades de los elementos del sistema, activos – sujetos -, pasivos – objetos – o ambos, y genera para cada uno de ellos un perfil que define su comportamiento; dicho perfil es almacenado en el sistema, y se actualiza con determinada frecuencia envejeciendo la información más antigua y priorizando la más fresca. El comportamiento del usuario en un determinado momento se guarda temporalmente en otro perfil, denominado `perfil actual’ (current profile), y a intervalos regulares se compara con el almacenado previamente en busca de desviaciones que puedan indicar una anomalía.
En [JV93] se definen diferentes tipos de datos o medidas que pueden ser útiles en la elaboración de estos perfiles:

  1. Intensidad de la actividad. Reflejan el ratio de progreso de la actividad en el sistema, para lo cual recogen datos a intervalos muy pequeños – típicamente entre un minuto y una hora -. Estas medidas detectan ráfagas de comportamiento (por ejemplo, una excesiva generación de peticiones de entrada/salida en un cierto intervalo) que en espacios de tiempo más amplios no podrían ser detectadas.
  2. Numéricas. Se trata de medidas de la actividad cuyo resultado se puede representar en forma de valor numérico, como el número de ficheros leídos por cierto usuario en una sesión o la cantidad de veces que ese usuario se ha equivocado al teclear su contraseña de acceso al sistema.
  3. Categóricas. Las medidas categóricas son aquellas cuyo resultado es una categoría individual, y miden la frecuencia relativa o la distribución de una actividad determinada con respecto a otras actividades o categorías; por ejemplo, cual es la relación entre la frecuencia de acceso a un determinado directorio del sistema en comparación con la de acceso a otro. Seguramente la palabra `categoría’ no es la más afortunada (por lo menos, no la más clara), ya que bajo este término se pueden englobar tanto a objetos (por ejemplo, ficheros) como a eventos (por ejemplo, llamadas a la función crypt()) del sistema; esta definición genérica puede resultar más sencilla si distinguimos entre categorías globales e individuales: en castellano plano, podemos entender las categorías globales como acciones muy genéricas dentro de un entorno, mientras que las categorías individuales serían la particularización para un elemento determinado del sistema. Así, una categoría global puede ser la formada por el conjunto de accesos remotos a la máquina, mientras que una individual sería la formada por los accesos desde una determinada ubicación física.
  4. Distribución de registros de auditoría. Esta medida analiza la distribución de las actividades generadas en un pasado reciente basándose en los logs generados por las mismas; dicho análisis se realiza de forma ponderada, teniendo más peso las actividades más recientes, y es comparado con un perfil de actividades `habituales’ previamente almacenado, de forma que permite detectar si en un pasado reciente se han generado eventos inusuales.

La segunda aproximación a la que antes hemos hecho referencia era la consistente en indicar mediante un conjunto de reglas el comportamiento habitual del sistema; suele ser denominada detección de anomalías basada en especificaciones (specification-based anomaly detection), y fué propuesta y desarrollada inicialmente por Calvin Cheuk Wang Ko y otros investigadores de la Universidad de California en Davis, durante la segunda mitad de los noventa ([Ko96], [CKL97]…). La idea en la que se sustentan los sistemas de detección de anomalías basados en especificaciones es que se puede describir el comportamiento `deseable’ (entendiendo por `deseable’ el comportamiento `normal’) de cualquier programa cuya seguridad sea crítica; esta descripción se realiza en base a una especificación de seguridad mediante gramáticas, y se considera una violación de la seguridad – al menos en principio – a las ejecuciones de dichos programas que violen su respectiva especificación.
Para ver más claramente el concepto de la detección de anomalías basada en especificaciones, podemos pensar en la ejecución de un programa que se puede considerar crítico, por ser privilegiado: /bin/passwd. Si conseguimos diferenciar las diferentes ejecuciones de esta orden que se pueden considerar `habituales’ (por ejemplo, cuando un usuario cambia su contraseña sin problemas, cuando se equivoca, cuando el sistema no le deja cambiarla por los motivos típicos – es débil, hace poco que la cambió…-), podríamos especificar formalmente cada una de estas secuencias de operación. De esta forma, cada vez que un usuario invoque a /bin/passwd, el sistema de detección monitorizará las operaciones que esa llamada genere, y considerará una intrusión a cualquiera que no sea `habitual’.
La idea de los sistemas de detección de intrusos basados en la detección de anomalías es realmente atractiva; no obstante, existen numerosos problemas a los que estos mecanismos tratan de hacer frente. En primer lugar podemos pararnos a pensar en las dificultades que existen a la hora de `aprender’ o simplemente especificar lo habitual: si alguien piensa que por ejemplo obtener un patrón de tráfico `normal’ en una red es fácil, se equivoca; quizás establecer un conjunto de procesos habituales en una única máquina resulte menos complicado, pero tampoco se trata de una tarea trivial. Además, conforme aumentan las dimensiones de los sistemas (redes con un gran número de máquinas interconectadas, equipos con miles de usuarios…) estos se hacen cada vez más aleatorios e impredecibles.
Otro gran problema de los sistemas basados en detección de anomalías radica en la política de aprendizaje que éstos sigan ([Ran98]); si se trata de esquemas donde el aprendizaje es rápido, un intruso puede generar eventos para conseguir un modelo distorsionado de lo `normal’ antes de que el responsable – humano – de los sistemas se percate de ello, de forma que el IDS no llegue a detectar un ataque porque lo considera algo `habitual’. Si por el contrario el aprendizaje es lento, el IDS considerará cualquier evento que se aleje mínimamente de sus patrones como algo anómalo, generando un gran número de falsos positivos (falsas alarmas), que a la larga harán que los responsables de los sistemas ignoren cualquier información proveniente del IDS, con los evidentes riesgos que esto implica.


next up previous contents
Siguiente: Detección de usos indebidos Subir: Sistemas de detección de Anterior: IDSes basados en red Índice General 2003-08-08

http://132.248.182.159/Replicas/LuCAS/Manuales-LuCAS/doc-unixsec/unixsec-html/node286.html

Click on pen to Use a Highlighter on this page
Tagged with:
 

Skype Online Status 

Contáctanos por Skype Call me! - Rolando Escobar: Offline
» Get Skype, call free! Servicios en Línea
 
 
Servicios Interdata Ltda. Colaboración e Inteligencia de Negocios, SQL Server 2008, Analysis Services, SharePoint, Excel Services, Reporting Services

Switch to our mobile site