lunes, 30 de marzo de 2009 0 comentarios

Malware, rebelión en la granja

Aunque no es uno de mis temas preferidos, como decían en Expediente X, "el malware está ahí fuera."
Sin embargo voy siguiendo las noticias de estos ultimos meses y esta plaga que parecía que hacía tiempo que no alcanzaba cierta notoriedad, de nuevo ruge como la marabunta. La gente de Hispasec que ven a diario todo tipo de especímenes, lleva unos días publicando noticias que denotan cierta preocupación.

Sabemos desde hace ya mucho tiempo que el antivirus perfecto no existe. En su tesis doctoral para la Universidad de California, Fred Cohen demostraba, en 1983, que no hay ningún algoritmo general que pueda concluir con total fiabilidad -100%- si un programa es o no un virus. Para ello se valía de la siguiente demostración por reducción al absurdo:
Supóngase que existe un algoritmo general A que, analizando cualquier programa P, devuelve "true" si y sólo si P es un virus. Entonces sería posible crear un programa, P, que hiciera lo siguiente: if ( A(P) = false ) then infecta el sistema if ( A(P) = true ) then no infectes nada Es decir: P es un virus si A dice que no lo es, y no lo es si A dice que lo es. Por contradicción, ese algoritmo general A no existe.


El especimen que parece ahora traer de cabeza a todo el mundo es el Downadup o Conficker. Las noticias destacan su alta capacidad de infección así como las diferentes alternativas que utiliza para lograrlo.
La propia Symantec ha publicado un minucioso estudio de este especímen que podéis consultar aquí. Otro resumen interesante ha sido proporcionado por el Blog de Seguridad de VerizonBusiness.

Como ya ha hecho otras veces, Microsoft ofrece un cuarto de millón de dólares por la 'cabeza' del creador del virus, mientras que éste, en sus anteriores versiones, ha acaparado titulares por haber afectado incluso a los ejércitos francés y alemán. Sus sucesivas versiones han hecho que este virus se convierta en una auténtica plaga como no se recordaban de la epoca del Code Red, Nimda, MyDoom o Storm.

Pero lo realmente preocupante son las reflexiones de Hispasec respecto a la necesidad del cambio de estrategia de los programas antivirus.

Por un lado porque se empiezan a disparar los falsos positivos y ya sabemos que una alarma que salta cada cinco minutos acaba siendo ignorada y más cuando se comprueba que además detecta algo que no es potencialmente peligroso. Por otro, porque el malware cada vez se dirige hacia elementos menos vigilados como ponen de manifiesto en su Una-al-día sobre Routers, modems y botnets.

Asusta ver todo lo que se cuece ultimamente en la trastienda del malware. Tenemos de todo pero empiezan a atisbarse los peores pronósticos. Hoy también salen a la luz noticias sobre un malware dirigido que se especializa en el espionaje llamado Ghostnet y que apunta hacia China aunque no se sabe a ciencia cierta si realmente es éste país el que está detras o es desde ahí desde donde se lanza aunque se controle desde otro.
También la industria del malware parece que pretende seguir como estrategia de ataque el desbordar con infinitas variantes los especímenes creados para saturar así el poder de detección y generar ineficacia en los productos antivirus. Tanto es así que se plantea como alternativa la detección del Goodware en vez del Malware. Tal como explica Hispasec, "Si en febrero de 2004 podíamos leer en el recién estrenado blog de F-Secure: "Dos nuevas variantes de Bagle han sido avistadas. Otra vez. Parece que tendremos un fin de semana ocupado", ¿qué tendrían que decir hoy en cualquier laboratorio antivirus donde se reciben a diario miles de nuevas variantes de malware?."

Además, la tendencia se extiende hacia infectar los equipos de red, menos interactivos con el usuario y por tanto, menos vigilados y notorios respecto a su detección, sobre todo para usuarios no muy avezados.
jueves, 26 de marzo de 2009 0 comentarios

ADSL más barato

Lo que ocurre con la conexión a Internet en nuestro país no tiene nombre. Pagamos por conexiones de "hasta X megabytes" que permiten facturar con calidades de servicio mucho más bajas.

A esto se suma otra noticia política que al menos defiende al pobre usuario. El Parlamento Europeo rechaza que se corte Internet como sanción al considerar que el "analfabetismo electrónico" será el "nuevo analfabetismo del siglo XXI", por lo que si se garantiza el acceso a Internet a todos los ciudadanos se asegura su "acceso a la escolarización". Ahora que resulta algo incoherente que ese derecho solo esté en manos de aquellos que pueden destinar una cantidad de su presupuesto al gasto en telecomunicaciones. Y es que si hacemos estudio financiero de nuestros gastos, la telefonía movil y el ADSL se pilla un pellizco importante. Lo que no entiendo es porqué no existe una facturación racional por consumo. Tanto consultas, tanto pagas con un precio por mega razonable. En mi movil por conexiones GPRS se llevan 1€ por llamada independientemente de si bajo 0,1byte o los 10MB antes de volver a cobrarme otro euro. Las aplicaciones básicas de acceso a datos meteorológicos las debo deshabilitar porque encima el movil viene configurado para "conectar/facturar" por defecto.

Asi que desde el blog, me uno a la iniciativa de solicitar un precio de ADSL más barato a través de la plataforma ADSLMasbarato.com
Podéis acceder a la Web, leer el manifiesto y firmar.



Y lo que me ha cabreado especialmente es que encima, mi proveedor que es Telefónica por fiabilidad básicamente y por ser española, me cobra a mi más porque entiende que en España se puede abusar más facilmente. Sólo hay que ver las ofertas de Telefónica en España y otros países:
Alemania
ADSL 4 Megas: 30 €
ADSL 8 Megas: 33 €
ADSL 16 Megas: 35 €
Reino Unido
ADSL 8 Megas (1,3 Mbps de subida): 13,75 €
ADSL 20 Megas (1,3 Mbps de subida): 16,50 €
ADSL 20 Megas (2,5 Mbps de subida): 24,77 €
España
ADSL 3 o 6 Megas (320 Kbps de subida): 40,90 €
ADSL 10 Megas (320 Kbps de subida): 44,90 €
ADSL 20 Megas (800 Kbps de subida): 150 €

Y luego quieren mejorar su imagen corporativa. Sin embargo su servicio al cliente sólo hace que me plantees cada día si debo cambiar de proveedor. Cuando salió el Iphone iba detrás de uno y tuve que fastidiarme porque los pocos que habían eran para los clientes de otros operadores y los clientes como yo de más de seis años teníamos que esperar y además pagar más por él.

En New York como en otras grandes ciudades del mundo, se utiliza mucho la tecnología Push-to-Talk, que permite usar el móvil como walkie gratis sin tener que pagar aun siendo una comunicación unidireccional. Es más comodo que una llamada perdida porque permite transmitir un mensaje. Aquí tenemos los moviles con la aplicación y son los operadores los que no quieren tener que dar servicio para seguir facturando.
Recuerdo además hubo un osado intento de querer hasta cobrar por las llamadas perdidas, lo que demuestra el gran lobby que son las telcos, como van a demostrar seguramente en su guerra particular contra la SGAE.

7 comentarios

¿Dónde pongo un CPD?

Aunque es un tema complejo y muy técnico, es crucial la selección de una buena ubicación para el CPD que minimice en el diseño los máximos riesgos posibles. A este respecto existen ya algunas normativas de construcción para garantizar que se tienen en consideración todos los aspectos importantes y lograr así el mejor alojamiento para los sistemas de información de una organización.

Este estándar que en sus orígenes se basa en una serie de especificaciones para comunicaciones y cableado estructurado, avanza sobre los subsistemas de infraestructura proporcionando los criterios que se deben seguir para clasificar estos subsistemas en función de los distintos grados de disponibilidad que se pretende alcanzar. Los requisitos que este tipo de normas establecen afectan a:

  • Estructura

  • Ubicación

  • Acceso

  • Protección contra incendios

  • Equipos

  • Redundancia



Existe una norma que puede ser considerada de referencia y se denomina ANSI\TIA-942. Al respecto leo en NIXVAL una serie de recomendaciones bastantes interesantes:

  • 1. Consideraciones arquitectónicas:
    - 2 accesos al edificio desde carreteras\calles separadas.
    - Preferentemente edificio de una planta dedicato exclusivamente a datacenter
    - Otros inquilinos del edificio si los hay no deberán dedicarse a actividades industriales
    - La posible altura de la sala del centro de datos debe tenerse en cuenta, ya que alturas de 4 metros pueden ser necesarias para albergar la totalidad de la instalación.
    - Existencia de un muelle de descarga
    - Distancia a fuentes de radiaciones electromagnéticas y de radiofrecuencia.
    - Ubiciación por encima de los niveles de agua. Nunca deben instalarse sistemas críticos en los sótanos.
    - No ubicar la sala de alojamiento bajo salas con instalaciones de fontanería.
    - La sala no debe tener ventanas.

  • 2. Consideraciones eléctricas:
    - Verificar la capacidad de las acometidas eléctricas al edificio, disponibilidad de mas de un proveedor y que el edificio dispone de acometidas eléctricas subterráneas.

  • 3. Telecomunicaciones:
    - El edificio debe disponer de al menos 2 entrance rooms de fibra óptica que sigan caminos diferentes.
    - Estas acometidas de fibra deben terminar en ubicaciones físicas distintas de los proveedores.
    - Diversos proveedores de servicios de telecomunicaciones tienen que ofrecer servicios en las instalaciones.
    - El equipamiento de telecomunicaciones debe estar instalado en el área del CPD y no en areas compartidas del edificio. El cableado debe estar adecuadamente canalizado, estar dedicado a telecomunicaciones y no ser accesible a terceros.

  • 4. Seguridad:
    - Accesibilidad 24x7x365
    - Monitorización de accesos, parking y muelle de descarga y resto de zonas comunes.
    - El edificio no deberá ubicarse en una zona con riesgo medio de inundaciones o superior, es decir frecuencia inferior a 100 años y calado alto (0,8 m), o en áreas con riesgos sísmicos, o de otro tipo de catástrofes.
    - No se ubicará el CPD en edificios que puedan resultar dañados por edificios colindantes durante un terremoto o inundación.
    - El edificio no podrá ubicarse en los pasillos aéreos de aeropuertos.
    - El edificio se ubicará como mínimo a 0,4 Km. de aeropuertos, ríos, la costa o presas con reservas de agua.
    - El edificio de debe ubicarse a menos de 0,8 Km de autopistas.
    - El edificio estará como mínimo a 0,8 Km. de bases militares.
    - El edificio no se ubicará a menos de 1,6 Km. de centrales nucleares, polvorines y fábricas de armamento.
    - El edificio no se ubicará adyacente a una embajada extranjera.
    - Se indicará la proximidad de estaciones de policía, parque de bomberos y hospitales.


Esta norma clasifica las infraestructuras en cuatro grandes niveles o TIERS que vienen asociados a unos niveles de uptime.
  • Tier I.Porcentaje de Disponibildad:99.671%, Porcentaje de indisponibilidad:0.329%, Tiempo de parada al año: 28.82 horas.

  • Tier II.Porcentaje de Disponibildad:99.741%, Porcentaje de indisponibilidad:0.251%, Tiempo de parada al año: 22.68 horas.

  • Tier III.Porcentaje de Disponibildad:99.982%, Porcentaje de indisponibilidad:0.018%, Tiempo de parada al año: 1.57 horas.

  • Tier IV.Porcentaje de Disponibildad:99.995%, Porcentaje de indisponibilidad:0.005%, Tiempo de parada al año: 52.56 minutos.

Para el que quiera curiosear más sobre esta norma, podéis consultar esta presentación y este documento. También es interesante conocer el "Codigo de buenas prácticas de la Unión Europea" en materia de CPD.

Y recordar que siempre los riesgos es mejor evitarlos que tener que solventarlos. A colación solo tenéis que ver el vídeo del post CPD inundado.
jueves, 19 de marzo de 2009 3 comentarios

Reflexiones sobre la falta de concienciación: los logs

De nuevo otro capitulo de la serie de post que voy a dedicar a la falta de concienciación en materia de seguridad. Una de las grandes bondades de la norma ISO/IEC 27001 es el cambio de filosofía que fuerza el ciclo de Demming respecto a la gestión de la seguridad tradicional. Esta norma hace pasar de la filosofía apagafuegos a una cultura de la prevención y detección temprana. Tanto es así que la propia norma, en las cláusulas relativas a la operación y supervisión del funcionamiento del SGSI obliga a establecer procesos de detección y de mitigación inmediata de incidentes.

Sin embargo me sorprendo muy a menudo al constatar la ausencia de aplicaciones de gestión de logs y monitorización que hagan más sencillo a los administradores las tareas de operación y mantenimiento TI.

Los logs son el rastro que dejan las operaciones cuando hay problemas, por tanto, es la información en tiempo real sobre posibles incidencias.
Tienen una doble misión: servir de evidencia e informar en tiempo real. Esta segunda función es quizás la más útil para un administrador de sistemas dado que puede influir positivamente en su propio beneficio. Por desgracia, este tipo de información los sistemas operativos y las aplicaciones la generan de una forma dificil de gestionar. Es por ello que existen aplicaciones específicas que permiten procesar grandes volumenes de datos y presentan una información mas concreta y sencilla de analizar de forma visual. La gran ventaja de este tipo de aplicaciones es que permiten procesar un gran volumen de información de un solo vistazo y además, de forma sencilla se pueden detectar situaciones anómalas. De esa manera, se identifica el lugar donde está el problema y de inmediato se reacciona. Como "una imagen vale más que mil palabras", adjunto unas capturas de dos de las aplicaciones más conocidas.
Nagios:

Mrtg:


De un simple vistazo se pueden detectar situaciones como que los discos estan llenos, que la carga del procesador supera las cotas tolerables, que la memoria está saturandose, etc. Además sorprende ver como los usos de los sistemas de información se rigen por ciertos patrones que se repiten y que de alguna forma, dibujan siempre una misma figura a lo largo del tiempo. Por tanto, la no repetición de este tipo de patrones o cualquier variación sobre ellos indica una situación anómala que debe ser investigada.

Entre las herramientas Opensource que destacan, estarían las siguientes:
  • Nagios: Sistema de monitorización de equipos y servicios, diseñado para informarte de los problemas de sistemas y red. Diseñado para ejecutarse en Sistemas GNU/Linux. El demonio de monitorización realiza chequeos intermitentes en los equipos y en los servicios que especifiques usando "plugins" externos los cuales devuelven información a Nagios. El demonio puede enviar notificaciones de eventos sucedidos a los contactos de varias maneras (email, mensajería instantánea, SMS.). Permite la instalación de agentes en maquinas Windows con lo que da cobertura a casi todo tipo de sistemas.Toda la información de estado, histórico de logs e informes, pueden ser consultados vía web. Mas información aqui.


  • MRTG: Herramienta para generar información visual sobre la monitorización de la carga del tráfico o el estado de la red. MRTG genera páginas HTML que contienen imagenes PNG que nos proporcionan una información visual viva de el tráfico de nuestros dispositivos.Más información aqui.


  • Cacti: Es una solución para la representación gráfica de datos de monitorización de red, y está basada en RRDTool (Round Robin Database Tool), una solución de gestión de logs y representación gráfica muy extendida y popular por su calidad, trayectoria y por las enormes ventajas que tiene que sea código libre según GPL. Sergio Hernando en su blog hace una extensa descripción que puede consultarse aquí.


  • mMonit: Herramienta más sencilla para la vigilancia preventiva. Es posible también configurar diferentes medios de notificación de las incidencias. Mas información aqui.


  • Zabbit: Herramienta de las más completas que permiten una gestión completa de todo tipo de recursos y de la monitorización de casi todos los parámetros significativos respecto al diagnóstico de anomalías. Mas información aquí.


Es por ello que este tipo de aplicaciones aparecen siempre en las pantallas de los grandes centros de operación como podéis ver en este antiguo post. En España contamos con el Centro Nacional de Supervisión y Operaciones de Telefónica en Pozuelo por el que pasaba a diario cuando iba a la empresa donde trabajaba en Madrid y del que hay fotos aquí y aquí.
Para terminar, recomiendo leer este artículo publicado en la Linux-Magazine titulado "De un vistazo".
lunes, 16 de marzo de 2009 1 comentarios

La caducidad de los datos

Estaba hoy leyendo el último cryptogram llegado a mi correo cuando me he encontrado con el artículo que Schneier titula "Privacy in the Age of Persistence".

En estos últimos meses se viene debatiendo en foros dedicados a la protección de datos de carácter personal lo agresivos que son los medios que vomitan información a Internet (como las famosas redes sociales comandadas por Facebook, los boletines y diarios electrónicos, los blogs, etc).

Cierto es que todos somos libres respecto a aquello que decidimos publicar, pero muchas veces no es razonable y proporcional el periodo de conservación de dicha información. Por eso andaba yo planteándome si debemos empezar a pensar en un nuevo principio de la protección de datos que establezca la "caducidad de la información".
Suena duro pero ¿por qué hay que guardarlo todo para siempre? ¿Acaso los administradores de sistemas de información padecemos el síndrome de Diógenes respecto a los datos que custodiamos?

Esto lo digo porque no es muy coherente que se conserven los datos durante años pero que en ningún momento exista cierta preocupación por garantizar su ciclo de vida conocido en ingles por las siglas ILM o Information Lifecycle Management.


La evolución de la tecnología es tan rápida que los formatos electrónicos dejan de estar en vigor en poco tiempo. Sin embargo, mucha información permanece en formatos caducos en las copias de seguridad. Si el contenido no vale, ¿para qué almacenarlo?. Si el contenido vale, ¿por qué no preocuparnos por ir migrando la información a otros formatos legibles y utilizables?

En cualquier caso, el escenario que plantea Schneier en su ensayo es cuanto menos inquietante y hace pensar aunque su reflexión va más orientada a cuestionar si no estamos inundando la Web con información basura.

Consciente o inconscientemente estamos dejando rastro continuamente de nuestra actividad: publicaciones por motu propio, mensajes en redes sociales, publicación de información en boletines oficiales, portales, etc.

Mucha de esta información es visible pero otra no lo es y sirve para alimentar las grandes bases de datos que permiten conocer al usuario y poder así explotar unas mejores estrategias de marketing. Si bien la legislación en materia de protección de datos arbitra derechos para conocer qué información es conocida por nosotros, es nuestra labor ir preguntando en cada sitio por ello. La propia legislación en su "Artículo 27. Comunicación de la cesión de datos" obliga a dejar traza de las comunicaciones para que el afectado pueda seguir el rastro de dónde finalmente acaban sus datos pero este artículo se incumple en la gran mayoría de los casos.

La caducidad de los datos establecería un periodo de pertinencia para la conservación de información, de forma que tuviera que ser el afectado el que fuera renovando la autorización para garantizar su conservación una vez que este periodo finalizase. De esta manera, la información de ciertos tratamientos de datos de carácter personal serían eliminados una vez que se superara este periodo y se evitarían situaciones donde la larga retención de datos no se utiliza de forma adecuada.


De lo contrario, cada vez que uno se enfrenta a una pantalla y decide escribir algo para la Web deberá pensar que Internet es como el matrimonio, para toda la vida.
jueves, 12 de marzo de 2009 0 comentarios

Consejos de Benjamin Frankin para los administradores de sistemas

Un amigo me enviaba hoy un correo de la Web de IBM con reflexiones de Benjamin Franklin aplicadas a los administradores de sistemas.

Esta Web recoge además de las frases del propio Frankin una serie de 10 consejos. La url es 10 tips for sensible systems administration.
A continuación os dejo algunas de las más interesantes.


  • Franklin on security. "Distrust and caution are the parents of security."

  • Franklin on consistency. "It is easier to prevent bad habits than to break them."

  • Franklin on preparedness. "By failing to prepare, you are preparing to fail."

  • Franklin on frugality. "Beware small expenses. A small leak will sink a great ship."

  • Franklin on information. "Who you gonna believe, me or your own eyes?"

  • Franklin on education. "If a man empties his purse into his head, no one can take it from him."
sábado, 7 de marzo de 2009 0 comentarios

SGSI virtuales

La proliferación de subvenciones y la motivación que proporciona el coleccionar certificaciones a nivel de organizaciones está generando un pequeño "boom" dentro del mundillo de la seguridad de la información y en concreto, la certificación bajo la norma ISO 27001:2005.

Esto que en teoría es viento favorable y debería generar cada vez más concienciación y producir mejoras en la gestión puede entrar en un círculo vicioso nada deseable. Por parte de las consultoras siempre se comenta que lograr la certificación es el premio al buen trabajo y el esfuerzo realizado en materia de seguridad. Sin embargo, se empieza ya a detectar una tendencia algo más peligrosa que es cuando el esfuerzo se dirige exclusivamente a lograr la medalla tratando de pasar la auditoría de certificación de cualquier forma, aun cuando ello no suponga disponer de una verdadera "gestión de la seguridad de la información".

Quiero comentar qué cosas son imprescindibles para que una organización tenga un SGSI real, y no uno virtual y certificado.

  • Primero: Es necesario tener claro cuales son nuestros objetivos de seguridad. Cada organización tiene un por qué en relación a sus necesidades de seguridad. Esta información se obtiene en la fase de análisis de riesgos, donde por cada proceso debemos pensar qué consecuencias puede tener la inseguridad. De esta forma hallamos qué es lo que tiene valor para la organización, atendiendo a requisitos de disponibilidad, integridad y confidencialidad. Obtener estos requisitos es también el por qué es necesario hacer el análisis de riesgos.


  • Segundo: Definir los objetivos que el SGSI debe perseguir. Una vez que acaba la fase de análisis de riesgos, conocemos cuales son los peligros potenciales que podrían generar mucho daño a la organización y por tanto, tenemos identificados todos aquellos eventos que bajo ningún concepto queremos que sucedan. El SGSI debe ser valorado y revisado al menos anualmente, para verificar que todo el esfuerzo que se está realizando en la materia se está logrando rentabilizar. Este concepto significa para el caso del SGSI que las medidas de seguridad funcionan y que los incidentes no visitan nuestra organización. Para ayudarnos en estas cuestiones es para lo que deben establecerse los objetivos del SGSI y sus correspondientes indicadores. ¿Cuantos son necesarios? Personalmente creo que los suficientes para valorar si todas las directrices dadas en la "Política de seguridad" se están cumpliendo. Cuantos más sensores del estado de la seguridad mejor, siempre que su gestión y mantenimiento sea algo llevable. A más información, más criterio para tomar decisiones. Los indicadores son una parte muy importante en el proceso de feedback que todo SGSI realiza para ajustarte a los objetivos planteados.


  • Tercero: Realizar el despliegue de medidas de seguridad para gestionar los riesgos y ejecutar el plan de tratamiento de riesgos que se haya planteado. Esta norma en esencia tiene como estrategia base de seguridad la prevención. El mérito de un buen SGSI es que evita daños. Por tanto, pervertir este funcionamiento elimina la esencia del beneficio que la gestión de la seguridad debe proporcionar a la organización. ¿Qué significa esto? Pues que no hay que hacer las cosas para superar la certificación sino para mitigar riesgos. Tengo la sensación de que muchos procedimientos se escriben para que queden bonitos el día de la auditoría pero en el fondo no está detrás la búsqueda de un buen mecanismo de eliminación de vulnerabilidades. El SGSI debe prevenir o detectar lo más tempranamente posible. De lo contrario, los daños se producen y aunque luego en la fase de revisión del sistema se pueden producir ajustes, el impacto ya se ha producido y la revisión sólo sirve para intentar no caer dos veces en la misma piedra.


  • Cuarto: Gestionar y monitorizar el funcionamiento de las medidas de seguridad. Una vez que el sistema está en marcha, la gestión de incidentes y de no conformidades son el nuevo pilar en el que se basa el SGSI. La mejora continua crea un proceso de retroalimentación que realiza los ajustes necesarios al funcionamiento establecido en base a detectar fallos que generan o bien acciones correctoras o bien acciones preventivas o bien sugerencias de mejora. El mantenimiento del SGSI se basará en solucionar las pegas del día a día y en la revisión del sistema que se realiza cada vuelta del ciclo donde se valoran también los resultados obtenidos en el seguimiento de indicadores y cumplimiento de objetivos.


  • Quinto: Formación y concienciación en la materia. Como me apunta "Deincógnito" en los comentarios, la formación de las personas que vayan a gestionar el SGSI sobre esta disciplina de la seguridad de la información es esencial. Dificilmente se puede gestionar "algo" sobre lo que se desconoce su funcionamiento, conceptos y criterios. Además de esta formación de las personas que operan el SGSI, es necesario que los actores principales de la protección, los usuarios del sistema estén entrenados para que la protección sea una cosa de todos.


Dicho esto, voy a tratar de identificar los sintomas principales de un "SGSI virtual".

  • Los objetivos de seguridad no son proporcionados por la Dirección: Nadie sabe mejor lo que se juega que quién es dueño del negocio. Por tanto, de cara a establecer los objetivos, deben surgir de dentro para solucionar los potenciales problemas que más daño podrían producir a la organización que se quiere certificar. Las consultoras en estos aspectos podemos asesorar pero no decidir. No es lo mismo plantear opciones en relación a objetivos en forma de propuestas que deben seleccionarse que darlos por escrito como si fueran ya decisiones definitivas.

  • La metodología de análisis y gestión del riesgo no se entiende por parte de la Organización: Esta situación es un auténtico cáncer para un SGSI. Esta fase es el corazón del SGSI dado que es donde se realiza el diagnóstico de situación. Un mal diagnóstico implica un mal tratamiento y unos malos resultados. Por eso es importante que este proceso sea realizado por parte de profesionales adecuadamente formados y con criterio y conocimientos de "seguridad de la información". Es la barrera de entrada que existe para profesionales dedicados actualmente a otras certificaciones de sistemas de gestión y que algunos no parecen percibir. Ponerse a realizar un plan de tratamientos de riesgos sin haber leido al menos la norma ISO 27002 me parece muy osado y sobre todo, poco profesional pero allá cada organización en relación a las manos en las que quiera ponerse.
    Por otro lado, la dinámica utilizada por la Organización para ir realizando el diagnóstico de sus deficiencias y necesidades debe ser sencilla de gestionar por parte de la Organización y en la medida de lo posible, para estas tareas deben ser autónomos. Es cierto que en el inicio de todo proyecto de construcción de un SGSI muchas empresas se ven sobrepasadas dado que son muchos conceptos específicos sobre esta materia. Pero cuando el SGSI empieza a funcionar y da su primera vuelta, la Organización debe poder seguir con el ciclo de mejora continua y debe afrontar la primera revisión del análisis de riesgos con suficientes armas como para poder ajustar todos aquellos matices y aspectos que fallaran o pasaran ignorados en la primera fase. En este sentido, también detecto una peligrosa tendencia que ya he comentado alguna vez. Hay consultoras que no entienden la verdadera importancia del análisis y gestión del riesgo y se lanzan a inventar su propia metodología. No critico que esto se haga, pero si alguien se lanza, que lo haga bien. ¿Qué significa? Al menos la metodología debe cumplir con los puntos especificados por la norma 27001 y debe generar resultados razonables y repetibles. Para ello por suerte, ya disponemos de ISO 27005 que deja asentados ciertos conceptos base que toda metodología debe contemplar. Como organización, para plantearse si la metodología es buena o no el mejor diagnóstico es seleccionar un control y preguntarse por qué es necesario. Algo como esto qué hago qué sentido tiene. Si la metodología es robusta, debe identificar esa medida dónde debe aplicarse, en base a qué tengo que hacerla (gestiona un riesgo, satisface un requisito legal o es un objetivo de negocio), en qué situación se encuentra y a qué situación debo acabar llevándola, y por último, cómo valoro que está funcionando y ayuda al cumplimiento de los objetivos del SGSI.

  • No existen tareas de seguridad: Esto de la certificación 27001 y disponer de la medalla de la seguridad es muy bonito pero el premio hay que sudarlo. Otro síntoma de un SGSI virtual es que no se definen las tareas que por seguridad deben ir realizándose a diario para evitar, detectar o remediar las incidencias que se van produciendo. Antes ya dije que la estrategia de la norma es siempre que sea posible la prevención o detección temprana. Para ello, es necesario que existan ciertas rutinas que proporcionen datos que sirvan para valorar nuestra situación, sensores o termómetros que nos avisen de cómo están funcionando nuestros sistemas de información y de cuándo pueden estar produciéndose situaciones potencialmente peligrosas. Esto obedece a la famosa frase de Lord Kelvin "si no puedes medirlo, no puedes mejorarlo" para la que Google ahora tiene un nuevo enunciado "Si puedes medirlo, puedes mejorarlo".La seguridad se debe basar fundamentalmente en la monitorización constante. Como toda área de control, es necesario vigilar que las cosas están en orden. Para ello, los mecanismos de seguridad deben servir para detectar, prevenir o predecir potenciales peligros de manera que podamos estar reaccionando al posible incidente antes de que este ocurra. Con esta filosofía de trabajo o bien somos capaces de hacer que la amenaza no nos afecte o bien disminuimos mucho su daño si la reacción arranca de forma muy temprana. No es necesario caer dos veces en la misma piedra para saber que si hay un obstáculo y no lo esquivamos, podemos caer. Por tanto, el SGSI se fundamenta en un despliegue de termómetros de seguridad distribuidos por toda la organización de manera que cuando se superan ciertos niveles salten alarmas que nos pongan manos a la obra a trabajar. Es todo lo contrario de lo que se venía haciendo hasta ahora en seguridad: apagar fuegos.

  • Los indicadores de seguridad son irrelevantes: 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 ostil 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.



Toda esta reflexión sólo tiene un motivo que es hacer ver que tener una organización certificada bajo ISO 27001 no va a servir de nada si no creemos en la necesidad de gestionar bien la seguridad de la información. Cuando uno se certifica en ISO 9001, se esfuerza por lograr la "calidad de sus servicios/productos". De no lograrlo es posible que la satisfacción del cliente no mejore y los resultados de la empresa no crezcan. Estas situaciones se controlan puesto que las cifras de resultados se vigilan continuamente de forma que cualquier fallo en la "calidad" puede ser identificado y se pueden realizar rápidamente ajustes.

Pues cuando uno se certifica en ISO 27001 se esfuerza por lograr la "seguridad de la información" de sus procesos productivos. De no lograrlo puede suceder que se presente una amenaza importante y que la organización no supere el incidente, y por tanto, la empresa no sobreviva. La seguridad sólo es vigilada por el SGSI de forma que no hay una segunda oportunidad para hacerlo bien. Si el incidente se presenta y falla por ejemplo el plan de continuidad de negocio, podremos tener unos magníficos procedimientos que no servían para nada y lucir nuestro maravilloso "sello 27001" pero la información de la empresa habrá desaparecido para siempre.
El hombre es un animal inteligente que no debe caer dos veces en la misma piedra. Debería ser suficiente con aprender de los demás pero no tener que sufrirlo en las propias carnes para reaccionar.

Cuando trabajaba en Madrid, hice varios cursos de Microsoft y seguridad en la Torre Windsor. Era un edificio gigante con 8 ascensores que se llenaban hasta arriba en las horas puntas. Me pregunto de las más de trescientas empresas cuantas superaron aquel incidente. Al menos he podido encontrar dos que si hicieron bien los deberes pero ¿2 de 200 es un buen ratio?.
Dada la edad de este blog, aquellos acontecimentos fueron ya comentados en su momento y las reflexiones sobre lo que ocurrió, lo que se perdió, los que hicieron bien las cosas y lo que debería hacerse ya han sido publicados.
 
;