12 diciembre 2007
De todo un poco
La primera debería ser conocida, y sin embargo tengo la sensación de que no todo el mundo se pasea por la web de RedIRIS (¿quizás porque es un poco "gris"?). En ella, bajo el título de definición de una política de seguridad, dan un repaso bastante completo a la gestión de la seguridad de la información en términos globales. No es específicamente una guía de implantación de un SGSI, pero precisamente por éso me gusta. Contempla todos los aspectos de la seguridad desde un punto de vista práctico, pero sin encorsetarse a una norma específica. Una fantástica referencia para todos aquellos que realmente se interesen por la seguridad pero estén un poco "escaldados" con las normas.
Y la segunda referencia, que no tiene nada que ver con la anterior, es una pequeña introducción al origen y necesidades que resuelven los dispositivos UTM (Unified Threat Management, o gestión unificada de amenazas). Para los que no los conozcan, y espero que sean una minoría, son un tipo de dispositivos (creo que el término tecnología no es adecuado aquí) que aúnan en un solo dispositivo distintas funcionalidades de protección perimetral de red (Firewall, Antivirus, VPN, IPS, ...) en tiempo real y con gestión unificada de todas ellas. Creo que estos dispositivos tienen un futuro muy prometedor, sobre todo desde el punto de vista de la sencillez que supone la administración unificada de la seguridad perimetral. Seguro que tienen sus detractores, sobre todo entre aquellos que opinan que es mejor un equipo dedicado para cada función de seguridad, pero desde mi punto de vista la superior usabilidad de estos equipos terminará decantando la balanza a favor de la unificación. Y que no se preocupen aquellos que piensan que puede haber problemas de rendimiento o throughput, que si hay negocio los fabricantes ya se preocuparán de dar solución a este aspecto, que en realidad no es tan crítico a día de hoy.
Y por hoy, eso es todo...
10 diciembre 2007
Creando DRPs
En primer lugar, el artículo incide sobre la necesidad de integrar la recuperación ante desastres a nivel general y la específica de IT, aspecto clave si queremos una recuperación realmente efectiva.
A partir de ahí, y centrándose en la recuperación ante desastres de IT, el artículo recuerda un concepto a veces olvidado: el MTO (Maximum Tolerable Outage). Este parámetro, a veces también conocido como umbral de crisis, representa el tiempo máximo que la empresa es capaz de sobrevivir tras el incidente. Es un parámetro clave, ya que no sólo hay que tener en cuenta el RTO, sino el tiempo necesario para invocar el Plan de Recupración ante Desastres (DRP, Disaster Recovery Plan). Esta decisión es clave, ya que la invocación del DRP normalmente conlleva unos costes extraordinarios significativos, y es necesario analizar si existen medios alternativos, dentro del Plan de Contingencias, para resolver los daños puntuales sin recurrir a la activación del DRP.
En caso de que se invoque el DRP, hay que tener en cuenta ciertos aspectos sobre este documento. La profundidad de detalle es muy variable en función de las necesidades y capacidad de la organización, pero sobre todo tiene que tener en cuenta los siguientes aspectos:
- Centrarse en las consecuencias del incidente, que son las que se deben resolver, independientemente de la causa que lo haya provocado.
- Descripción de todos los roles participantes, junto con el listado de personas capaces de desempeñar ese papel y sus respectivos contactos.
- Prioridades de recuperación, para conocer el orden en que se deben recuperar los servicios.
- Contactos de todas las terceras partes necesarias para la recuperación.
- Y evidentemente la secuencia (flujo) general de actividades y sus dependencias.
Una vez creado el Plan de Recuperación ante Desastres es imprescindible probarlo. Hay que probar los planes, los procesos, las personas y la tecnología. Estas pruebas, que deberían ser como mínimo anuales, deben verificar la efectividad de las actividades, la capacitación del personal, la eficiencia y eficacia de las infraestructuras y documentación y la validez de los objetivos de recuperación, además de servir para identificar problemas y posibles mejoras.
El alcance de las pruebas no es un parámetro fijo, y siempre es posible llevar a cabo pruebas parciales. Sin embargo, no podemos caer en la tentación de probar sólo aquello que sabemos que va a tener éxito, focalizar nuestras pruebas exclusivamente en un apartado, no tener en cuenta la capacidad real necesaria, o ser excesivamente ambiciosos. En definitiva, las pruebas pueden ser parciales pero deberán cubrir todos los elementos del plan. Y sobre todo deben ser útiles.
En resumen, el artículo que he citado refleja unos pocos parámetros clave sobre los que reflexionar a la hora de desarrollar un buen Plan de Recuperación ante Desastres. Y no olvidemos que la parte reactiva es sólo la mitad de un buen Plan de Continuidad de Negocio, y si queremos hacer bien nuestro trabajo la parte preventiva debe estar todavía mejor. O alguien prefiere esperar a que suceda el incidente para demostrar que su plan de respuesta es correcto?
05 diciembre 2007
UNE-ISO/IEC 27001:2007
Es una buena noticia que exista una traducción oficial de la norma, sobre todo para evitar la creciente disparidad de traducciones y las posibilidades de diferencias de interpretación que eso puede suponer.
Es posible que haya alguna que otra confusión con el indicador del año, ya que la versión internacional es de 2005 y la nacional de 2007. Realmente no debería suponer ningún problema, pero habrá que estar atentos de mantener la coherencia: si hablamos de UNE supongo que habrá que poner 2007, y si hablamos de ISO, 2005.
Me llama la atención el hecho de que aparezca la UNE 71502:2004 como "otra versión vigente" de la nueva UNE. Más que nada, porque algunos defendían que eran dos normas distintas, al menos cuando la ISO todavía era BS. Supongo que las diferencias reales no eran tantas, al fin y al cabo, si resulta que ahora son dos versiones vigentes de la misma norma (o al menos la una lo es de la otra).
De todas formas, la labor de traducción en relación a las normas de seguridad sigue su curso. La última versión UNE de la ISO 27002 es la correspondiente a la ISO 17799:2002, y ya se indica que será anulada por la PNE-ISO/IEC 17799 (traducción oficial de la versión de 2005). Aunque, dado que todavía está en fase de proyecto, creo sería interesante que se publicara ya como UNE-ISO/IEC 27002:20xx, no?
Y por último, un deseo. No sería interesante que, siguiendo esta actividad frenética de fin de año, y tomando como referencia esta publicación, se animara también el mundillo en relación a la publicación del nuevo reglamento de medidas de seguridad para ficheros con datos de caracter personal? Algunos rumores que circulan por el sector dicen que para el primer trimestre de 2008 podría estar publicado el nuevo reglamento, pero otros dicen que el proyecto ha sufrido un nuevo revés y probablemente tendremos otra nueva versión del borrador antes de su trámite final (y sería la quinta). ¿Cuál acertará? Yo, visto lo visto, me decanto por el segundo... Y si no, siempre podremos anunciar su publicación el día 28.
03 diciembre 2007
Hay seguridad?
Si somos capaces de abstraernos de todo el sensacionalismo que rodea este tipo de noticias, el análisis que podemos hacer del caso puede distar bastante del previsible en muchos medios de comunicación. ¿Está la seguridad de la información en tela de juicio en el Reino Unido? Alguien lo podría pensar, dada la magnitud de las noticias y su cercanía temporal. Sin embargo, no creo que sea el caso.
En el Reino Unido existe una cultura de seguridad de la información más arraigada que en nuestro país. No sólo sirve de muestra la cantidad de empresas con SGSIs certificados que hay en ese país (363 en el último recuento oficial), sino el hecho de que las principales instituciones del país sean las que encabezan esa lista. ¿Cuál es el problema, entonces? Sencillamente, ese: SÍ HAY cultura de la seguridad.
Todos sabemos que puede haber dos motivos por los que no se registren incidentes de seguridad: que no existan, o que no se reporten. La consecuencia es la misma, pero la causa es bien distinta en cada caso. Sólo depende de la cultura de la organización (o del país, en términos más amplios). Sólo pueden salir a la luz pública los incidentes de seguridad reportados, los que nadie conoce difícilmente aparecerán en los medios. ¿Qué supone estas apariciones? Precisamente, que existe una buena gestión de la seguridad.
Sólo si hay una buena cultura de seguridad te "atreves" a hacer público un incidente de seguridad. Sólo si hay una buena gestión de la seguridad te "atreves" a comunicar a los medios dicho incidente, porque sabes que a partir de ese momento todos tus pasos van a ser estudiados con lupa, con el fin de poder aprovechar cualquier desliz de gestión. Por tanto, comunicar públicamente un incidente de seguridad supone que tienes que tener muy claros los procedimientos de asunción de responsabilidades y depuración de los hechos, demostrar que cada uno asume su parte de culpa y trata de resolver lo sucedido. ¿Cuántas organizaciones son capaces de hacer eso a la luz pública? Me temo que no tantas como deberían...
Por lo tanto, no creo que estas noticias deban ser signo de preocupación, al menos por el momento. Creo que el Reino Unido sigue manteniendo un buen nivel de seguridad. ¿O alguien cree que sólo se producen fugas de datos en ese país? Lamentablemente, la compra-venta de datos bancarios y personales está a la orden del día para cualquier país del mundo, y nosotros no somos una excepción. Ahora bien, a partir de esa realidad, la forma de encararlo puede variar mucho. ¿Cuántos lo ocultan? ¿Cuántos lo comunican? ¿Cuántos lo difunden? Y si fueras tú quien detectaras el incidente de seguridad, qué harías?