Blog sobre seguridad informática:
Hacking ético y asuntos de traje y corbata,
todos de interés en este campo profesional
Mostrando entradas con la etiqueta FIRST. Mostrar todas las entradas
Mostrando entradas con la etiqueta FIRST. Mostrar todas las entradas
martes, 16 de septiembre de 2008
Gestión de riesgos y CVSS
En risktical.com nos hacen una interesante serie sobre gestión del riesgo y CVSS. Realmente, son los pensamientos del autor sobre por qué CVSS puede ser útil para quien haga un análisis de riesgos sobre una nueva vulnerabilidad, y cuáles son las diferencias con respecto al análisis completo. Particularmente, lo relaciona con una metodología de análisis de riesgos denominada FAIR.
Nos hace, entre otras reflexiones, una muy importante, para no confundir términos. Yo los confundía cuando empecé en estos temas, por lo que me parece interesante plasmarlo aquí. Y es que el resultado de la métrica no es una medida real del riesgo que una organización corre, pues hay otros factores a tener en cuenta para calcular la severidad real de una vulnerabilidad para una organización.
Con CVSS, la valoración de una vulnerabilidad no tiene en cuenta las salvaguardas que una organización ya tuviera desplegadas y que pueden servir para mitigar o incluso impedir un posible ataque. Tampoco la frecuencia con la que se tienen pérdidas debido a un ataque realizado con éxito, o el coste de las salvaguardas. Por tanto, es obvio que la medida final que se obtiene con CVSS no es lo mismo que el riesgo real que supone la vulnerabilidad medida. Y sin embargo, en CVSS Guide se indica que uno de los beneficios es obtener un nivel de riesgo priorizado.
Por tanto, CVSS debería ser usado como lo que es, es decir una métrica para valorar una vulnerabilidad por sí misma, y no el riesgo que supone para una organización. Hay que tener en cuenta, además, que el cálculo realizado por CVSS podría variar con el tiempo, pues uno de sus grupos de métricas, "temporal", refleja datos que pueden cambiar, por ejemplo, si hay un exploit efectivo disponible públicamente (en sitios como milw0rm). Por lo que la valoración de la vulnerabilidad en un momento dado, puede no ser la que haya que tener en cuenta finalmente para el análisis de riesgos. O podría requerirse una segunda iteración de este análisis.
Creo que podría ser interesante ver otros mapeos de CVSS con respecto a metodologías de análisis de riesgos.
Aquí van los enlaces a las cinco entradas de que consta la serie, como os digo, muy interesante:
Risk and CVSS - parte 1
Risk and CVSS - parte 2
Risk and CVSS - parte 3
Risk and CVSS - parte 4
Risk and CVSS - parte 5
Entradas relacionadas:
Measurable security: sobre CVSS y otros proyectos de FIRST
Slds!
Si te gustó esta entrada, quizás quieras suscribirte al blog por email o por RSS...
jueves, 10 de abril de 2008
Measurable Security
Leyendo sobre SSA (una utilidad que permite chequear tu equipo), he encontrado este sitio web de Mitre, que no conocía: Measurable Security.
Es básicamente un pequeño compendio de proyectos útiles, ya sean de Mitre o no, que sirven para que la seguridad de una organización pueda ser medida más fácilmente, definiendo los conceptos que han de ser medidos, y facilitando la transmisión de sus resultados. Creo que todos los que llevamos algo de tiempo en el mundillo de la seguridad habremos visto alguno, y en mi opinión, hay que alabar todos sus esfuerzos.
Está por ejemplo el estándar CVE, que proporciona un identificador único a cada vulnerabilidad, y que se ha impuesto como una referencia. Prácticamente todos los fabricantes, herramientas de análisis y bases de datos de vulnerabilidades, utilizan este identificador, imprescindible para poder relacionar la descripción de una vulnerabilidad en una fuente con otra.
Otro de mis favoritos es el estándar CVSS, que permite valorar una vulnerabilidad, para saber si es crítica o no, en una escala de 0 a 10, atendiendo a tres tipos de criterios:
- "Base" son características que se identifican en el momento de la vulnerabilidad y que no van a cambiar con el tiempo, por ejemplo, si es explotable de forma local o remota.
- "Temporal" son características que sí pueden cambiar posteriormente, por ejemplo, si hay un exploit público para la vulnerabilidad.
- "Environment" son características que dependen del entorno en el que evalúas la vulnerabilidad, por ejemplo, la criticidad del servidor que se esté analizando.
Puedo estar un rato muy largo hablando de estos proyectos, pero... ¡mejor míralos tú mismo!. Son, de verdad, de las mejores iniciativas que se puede encontrar :)
Slds!
domingo, 16 de marzo de 2008
CERTs, CSIRTs, etc
Al ver los videos del post anterior, pensé en buscar un poco más de información sobre CERTs. He usado muchas veces este término, he tenido noticia de algunos de ellos, pero nunca me había puesto a hurgar para buscar información en profundidad. Este post es una introducción, a modo de artículo, a lo que hacen, cuáles son conocidos, qué organizaciones hay a nivel europeo y mundial, etc.
De qué hablamos
Hoy día se utilizan los términos CERT (Computer Emergency Response Team) y CSIRT (Computer Security and Incident Response Team) de forma indiferente, para denominar a aquellos grupos dedicados a estudiar problemas de seguridad (vulnerabilidades) en Internet, proporcionar servicios a entidades que han sido atacadas, así como divulgar avisos de seguridad. Además, proporcionan información que contribuye a mejorar la seguridad de los equipos y redes de las comunidades a las que prestan servicio.
Los servicios concretos que da un CERT, cómo contactar con él, de quién depende, a qué comunidad se dirigen sus servicios etc, está definido en una "carta de constitución", que tiene cada uno. El RFC 2350 es un modelo a seguir para una organización que constituye un CERT. Se puede ver un ejemplo aquí.
CERTs en España
Existen ya varios de estos centros de este tipo en España, tanto públicos como privados. Entre los públicos, destacan los universitarios IRIS-CERT y esCERT. También dos creados en el año 2007, que son el CCN-CERT del Centro Criptológico Nacional, con el fin de dar servicios a las Administraciones Públicas, y el creado por INTECO (Instituto Nacional de Tecnologías de la Comunicación), dirigido a particulares así como a pequeñas y medianas empresas. También existen centros a nivel autonómico.
Los privados corresponden a empresas del sector de la seguridad informática, o a entidades privadas grandes, como es ejemplo el Cert de La Caixa (e-LC CSIRT). Este cert cubre aquellos problemas que podrían afectar a la propia entidad y a sus clientes, en transacciones realizadas online.
¿Y en el mundo?
La labor de un CERT no sería efectiva sin la colaboración con los demás. Ya en 1989, cuando se creó el primer cert del mundo, el CERT/CC, quedó clara la necesidad del trabajo en equipo, por lo que en 1990 fue creado el Forum of Incident Response and Security Teams (FIRST).
Asociados en el FIRST hay ahora mismo 192 equipos de respuesta a incidentes, en 41 países, principalmente en Europa (Alemania tiene 16, Reino Unido 17) y Estados Unidos (62). La mayoría de los países está más o menos al nivel de España, que tiene registrados 4 equipos.
Con este organismo suele colaborar otro a nivel europeo, TERENA, con varias iniciativas, como son su grupo de trabajo TF-CSIRT, y Trusted Introducer. Esta última proporciona servicios a equipos acreditados, como son foros y listas de discusión, compartición de información, etc.
A nivel gubernamental en la UE, la ENISA (Agencia y Red Europea para la Seguridad de la Información), está planificando la creación de un programa, denominado “Sistema Europeo de Alertas e Información Compartida” (EISAS), que aúne los esfuerzos que realizan los centros de alerta de los países de la UE, así como los hechos por los departamentos de delitos informáticos de la Policía de cada país.
Esta misma organización tiene otros proyectos interesantes, como es una guía para poner en marcha tu propio CERT, ejemplos incluidos.

Conclusión
Esta misma organización tiene otros proyectos interesantes, como es una guía para poner en marcha tu propio CERT, ejemplos incluidos.
Conclusión
Los servicios de los centros de respuesta a emergencias son aún poco conocidos por los profesionales de la informática, y menos aún por otros tipos de usuarios, debido a que hasta hace poco tiempo, los únicos que había españoles eran de ámbito universitario. Queda aún mucho trabajo por divulgarlos, por ejemplo entre PYMEs, como es el objetivo de Inteco. Las iniciativas realizadas a nivel español y europeo, hacen pensar que este tipo de servicios tendrá un crecimiento elevado a medio plazo.
Referencias
RFC 2828: Internet Security Glossary
RFC 2350: Expectations for Computer Security Incident ResponseForum of Incident Response and Security Teams (FIRST)
ENISA: European Network and Information Security Agency
Intentaré ampliar la información puesta aquí, con lo que vea en la guía antes mencionada, y con lo que lea en este otro libro que he encontrado: "Handbook for security incident response teams (CSIRTs)".
Slds!
Suscribirse a:
Entradas (Atom)