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?
30 noviembre 2007
Apuntes técnicos
- La primera es esta, una seria y bastante profunda descripción de tecnologías anti-malware. Muy aconsejable para todo aquél que quiera profundizar a un nivel medianamente serio sobre el estado del arte en este mundo.
- La segunda, que no tiene nada que ver con la anterior, es esta otra. Es un documento que diserta sobre qué criterios utilizar a la hora de seleccionar un producto VPN SSL. Obviando la parte comercial del documento, que le hace perder puntos, me parece una reflexión interesante, aunque no sea excesivamente profunda, sobre temas en los que pensar antes de elegir un producto que implementa una tecnología, desde mi punto de vista, muy interesante y con mucho futuro.
Y por esta semana, eso es todo. Que paseis un buen fin de semana...
28 noviembre 2007
Calidad, interna o externa?
Está claro que uno de los objetivos básicos de cualquier negocio es el de satisfacer las necesidades del cliente. Pero... qué necesidades? Con un ejemplo creo que se puede entender fácilmente. Imaginemos a un fabricante de coches. Y a un cliente que lo que quiere es un coche bonito estéticamente, en el que la música se escuche con mucha potencia y que tenga asientos cómodos de materiales nobles. Le estaremos dando un buen coche si cumplimos con sus requisitos? El cliente no ha dicho nada sobre potencia del motor, consumo, número de plazas... Una berlina de alta gama con un buen equipo de sonido puede satisfacer sus necesidades, pero también lo podría hacer un compacto "tuneado". O por qué no un buggy convenientemente personalizado?
El problema de fondo, exagerado en el ejemplo, es la definición de requisitos. Qué características tiene mi producto, y qué necesidades del cliente debe satisfacer? En teoría pueden parecer dos preguntas sencillas de responder, pero la práctica nos dice que en muchos casos no es así. Sobre todo, si estamos hablando de servicios. Porque un producto, ya sea coche, tuerca u ordenador (y en este último caso no está tan claro) está bastante claro qué hace, para qué sirve, y qué problemas soluciona. Pero... y un servicio? ¿Podemos dar un servicio de CAU contratando una empresa de teleoperadoras? Qué necesidades del cliente satisface una consultoría? ¿Sabe realmente el cliente lo que quiere conseguir con una consultoría? Y si no lo tiene claro... cómo podemos ofrecer un servicio "de calidad"?
Yo creo que la calidad tiene dos vertientes, interna y externa. Acepto que haya que cumplir con los requisitos de los clientes, pero sin olvidar los propios. Creo que la base de la calidad bien entendida debe ser cumplir COMO MÍNIMO los requisitos propios, que al fin y al cabo somos los que conocemos nuestro propio negocio. Establecer unos "baselines" de calidad en los productos y servicios que ofrecemos. Y a partir de ahí, podemos empezar a pensar en satisfacer, además, los requisitos del cliente. Y de paso ayudar al cliente a que reflexione acerca de si las necesidades que él quiere satisfacer realmente se satisfacen con el producto o servicio que va a comprar, y si realmente tiene que contemplar sólo esos requisitos, o alguno más. No sea que la solución apropiada para el cliente del coche sea instalar un home-cinema...
La idea de que la calidad tiene que empezar "por uno mismo" no es en absoluto extraña. Si hablamos de servicios, probablemente todos seremos conscientes de que la forma de poder ofrecer un buen servicio es acotarlo. El primer paso será definir nuestro catálogo de servicios. A alguien le suena? Tendremos que parametrizar qué ofrecemos, qué características tiene, para qué sirve... En resumidas cuentas, qué necesidades satisface, y a qué nivel. Tendremos que ser capaces de identificar los SLAs que puede cumplir nuestro servicio. Qué minimos podemos ofrecer, cuál va a ser nuestra "baseline" de calidad. Y a partir de ahí, analizar en qué medida podemos "mejorar" nuestro servicio para cumplir con las exigencias del cliente... si es que son mayores que las de referencia.
Y si alguien quiere volver a releer el post, aquí tiene una pregunta final: ¿Qué pasa si cambiamos el término calidad por el término seguridad? Todo se puede mirar desde distintos puntos de vista...
19 noviembre 2007
Riesgo de negocio o riesgo IT?
En concreto, el artículo anima a los gerentes de negocio a entender los riesgos IT como riesgos de negocio, y evaluar sus consecuencias desde este punto de vista. En concreto, el artículo plantea esta reflexión en base a cuatro objetivos de negocio:
- Disponibilidad: Disponibilidad de los procesos de negocio ligada a la disponibilidad y recuperación ante incidentes de los sistemas IT.
- Acceso: Permitir accesos a la información y los sistemas en base a las necesidades del puesto, y bloquearlos a todos aquellos que no lo necesiten.
- Exactitud: Los sistemas IT deben proporcionar toda la información que se precise en el momento y forma oportunos, con el fin de garantizar el cumplimiento de los requisitos de negocio que se definan.
- Agilidad: Los sistemas IT deben permitir y adaptarse a los cambios de negocio que pueda sufrir la organización.
El artículo plantea la necesidad de que los gerentes de negocio adquieran las herramientas necesarias para gestionar los riesgos IT, con el fin de que sean capaces de determinar los riesgos que desean asumir y los que deben reducir. Para ello, propone tres líneas de acción:
- Un sólido modelo de activos que interrelacione procesos, activos IT, personas y controles.
- Una estructura de gobierno de riesgos que contemple la gestión de riesgos IT como parte integral de la misma.
- Una cultura de gestión de riesgos que alcance a toda la organización.
El artículo concluye resaltando la necesidad de integrar cuanto antes la gestión de riesgos IT dentro de la gestión de riesgos de negocio, ya que "los peores riesgos son aquellos que nunca se consideran".
Realmente me ha parecido un artículo muy interesante, tanto por el punto de vista que refleja como por la concretitud de los consejos que da. ¿Sabrán las empresas poner em práctica estos consejos? ¿Echais de menos alguna línea de acción que os parezca necesaria incluir? Sería interesante contar con la opinión de alguien que viera el artículo desde el punto de vista de los gerentes de negocio...
09 noviembre 2007
La función de seguridad
La puntualización es, sencillamente, el título del artículo. En él se hace referencia a la función de seguridad informática, aunque en el desarrollo del mismo en muchos casos se excede este alcance. Este es un aspecto que a mí, personalmente, me fastidia bastante. Es cierto que la seguridad de la información recae en buena medida en el ámbito informático, pero si realmente se desarrolla por completo esta función, una parte importante de su actividad debería desarrollarse también fuera de él. Por eso en el título de mi post me he "comido" la última palabra. Porque en caso contrario los conflictos de intereses no sólo se producirían dentro del área de sistemas, sino sobre todo en el exterior, ya que desde un área técnica se deberían realizar prescripciones de aspectos que en absoluto tienen que ver con los ámbitos técnicos.
05 noviembre 2007
Abaratar costes... a qué precio?
La verdad es que la idea, desde el punto de vista de la seguridad, me parece demasiado atrevida. Pero ni siquiera hace falta recurrir a estos argumentos para cuestionarla, basta con pensar un poco en costes indirectos. Es cierto que si los propios empleados compran y mantienen sus equipos, no hay que dedicar ni un céntimo del presupuesto corporativo para atención al usuario ni para adquisición y/o mantenimiento de equipos. Ahora bien, si la condición indispensable (tal y como afirma el artículo) es migrar las aplicaciones a un entorno web... qué coste tienen estos proyectos? Probablemente sea significativo. Ciertamente es un coste puntual, pero puede que no sea despreciable, y que la rentabilidad del cambio de estrategia se retrase unos años.
Además del coste de la migración... ¿Qué garantías de rendimiento puede ofrecer la compañía? En general, el uso de los equipos es un factor determinante para el rendimiento del personal, y por el momento a nadie se le exigen conocimientos de administración de sistemas para acceder a un puesto que no sea de este área. Si los equipos funcionan mal, la única forma de asegurar que los empleados pueden arreglarlos (y que sigan siendo productivos) es habilitar un programa de formación técnica para todos los empleados. Y eso tiene un coste.
Por otra parte... qué aplicaciones van a utilizar los usuarios para desarrollar su trabajo? Son todas freeware? Y si no es así, quién corre con los gastos derivados de las licencias? La empresa o el empleado? Hay muchos programas informáticos cuyo coste en licencias no es precisamente bajo. Y no todos los productos son capaces de funcionar vía web.
Por otra parte, una vez que todos los equipos están accediendo a los sistemas de la organización, hay que asegurar la interoperabilidad. Y si el entorno es heterogéneo, puede ser algo complicado...
Ya desde el punto de vista de la seguridad... qué políticas de usuario puede aplicar la compañía? Se puede forzar una longitud mínima de contraseña, por ejemplo, si el usuario puede administrar su propia máquina? Se puede forzar la navegación a través de proxy, si el usuario puede modificar su configuración de red? Porque debe poder hacerlo, si queremos que administre su propio equipo...
En resumidas cuentas, creo que la iniciativa en términos generales es bastante desacertada. Sobre todo, porque no se tienen en cuenta costes indirectos derivados de esa decisión, ni perjuicios colaterales que puedan surgir. Y desde el punto de vista de la seguridad, difícilmente se pueden establecer muchos controles corporativos si los usuarios tienen que tener por propia política de empresa la capacidad de saltárselos. Que de proponer un abanico de opciones para elegir el equipo de trabajo, a dar una libertad completa en su selección, el salto es enorme. Y no tiene red.
31 octubre 2007
Seguridad o Gestión de la Seguridad?
La gestión de la seguridad es, en principio, el nivel más avanzado en relación a la seguridad. Pero para llegar a este nivel es obviamente necesario haber superado los anteriores. Para gestionar la seguridad antes debemos tener seguridad. Parece una obviedad, pero la realidad es que no siempre se tiene en cuenta. No debemos tener en cuenta que el objetivo no es la gestión, sino la seguridad, y que la gestión es sencillamente una vía para mantener y mejorar sistemáticamente la seguridad. Es la vía más avanzada, y para llegar a ella tendremos que haber superado las anteriores. Si no, el batacazo será estrepitoso, y tarde o temprano llegará.
Vamos a por un ejemplo, que probablemente sea la forma más sencilla de verlo: Un antivirus. Qué pretendemos conseguir con él? Estar libres de virus, para no sufrir los efectos dañinos que pueden ocasionar si nos infectamos. Querríamos detectar y eliminar todos los virus que lleguen a nuestro PC. Dónde está la seguridad y dónde la gestión de la seguridad en relación a este antivirus?
Imaginemos una empresa que tiene un parque de PCs en el que todos los equipos tienen su antivirus totalmente actualizado, con un motor de detección que combina heurística avanzada y nuevas firmas que se publican diariamente, que detecta todo tipo de malware, que escanea automáticamente todo el parque de PCs, ... Tenemos el mejor antivirus posible, y con la mejor instalación y configuración posible. Eso es seguridad. Independientemente de que la configuración esté o no documentada, de que se revise periódicamente o de que monitoricemos la tasa de actualización de los antivirus.
Ahora pensemos en otra empresa con un antivirus del montón, sin heurística, de un fabricante que publica nuevas firmas de vez en cuando, que sólo está instalado en los PCs más nuevos de la empresa, ... Tenemos un antivirus mediocre con una instalación y configuración mediocre. Tenemos seguridad? No mucha. Sin embargo, esta empresa tiene totalmente documentada su política de antivirus, la dirección la revisa anualmente, tiene indicadores que le permiten conocer el % de ordenadores con el antivirus actualizado, mide como incidentes de seguridad todas las infecciones detectadas y no eliminadas, ... Tiene una muy buena gestión de la seguridad en relación al antivirus. Se ve la diferencia?
Evidentemente, he simplificado mucho las cosas. En el primer caso la seguridad de la empresa en relación a los virus es muy buena... en ese momento. Si no hay una gestión asociada, ese nivel de seguridad no se podrá mantener. Habrá que hacer un seguimiento de la situación si queremos seguir garantizando ese nivel de seguridad. Y en el segundo caso, si la gestión de la seguridad es muy buena, habrá seguimiento del estado, revisiones periódicas y auditorías que nos digan que nuestra protección frente a virus no es muy buena, y se establecerán medidas correctoras para solucionar estas carencias, de forma que a medio plazo probablemente se podría alcanzar una situación aceptable. Las cosas nunca son blancas o negras, y en este caso tampoco iba a ser menos. Sin embargo, creo que el ejemplo ha servido para aclarar las diferencias.
Esta dicotomía no tiene por qué ser grave, ya que es muy habitual que ambas tendencias, mejor o peor llevadas, tiendan a converger. Esa es su evolución natural. El problema puede surgir cuando se introducen factores que pueden hacer que cambie el rumbo de esa convergencia natural. Y uno de esos factores puede ser la certificación de sistemas de gestión. Si la obtención de un certificado que avala un sistema de gestión se considera algo positivo, puede que la empresa centre sus esfuerzos en la gestión, y tienda a olvidarse de la seguridad. Incluso puede llegar a romper esa convergencia natural, y primar la gestión sobre la seguridad. No es algo nuevo, esto ya ha ocurrido en muchos casos en relación a los sistemas de gestión de la calidad (recordais?). Y creo que este es el momento de empezar a recordar estos peligros, antes de que la seguridad corra el peligro de convertirse en la secuela de la "decepción de la calidad". Todavía estamos a tiempo de paranos a pensar, y una reflexión a tiempo siempre sirve de ayuda...
24 octubre 2007
Sin entrar a valorar específicamente los indicadores, sí que me gustaría aportar mi punto de vista sobre sus posibles causas y algunas posibles vías de actuación. Porque con lo que sí coincido completamente es con la visión pesimista que ofrecen los citados indicadores.
El principal problema, creo yo, es que no hay conciencia social en relación a la seguridad. Pero no sólo porque a la gente no le preocupe la seguridad, sino porque la desconocen. En muchos casos, los ordenadores son unos cacharros con los que te peleas hasta que consigues hacer lo que quieres, más o menos, y a su manera. En otros, son un juguete más o menos sofisticado con el que enredar. Y en otros, símplemente una vía para acceder a un montón de material gratuito que realmente sólo interesa por el hecho de que no hay que pagar específicamente por él. En resumen, una herramienta bastante compleja cuyo funcionamiento real se desconoce y no interesa, mientras haga lo que nosotros queremos.
Creo que el principal problema está en convencer a los usuarios de que los ordenadores no hacen sólo lo que queremos, que aunque no se den cuenta están realizando un montón de tareas además de las que ellos les encomiendan. Y que si no los entiendes bien, ni siquiera conseguirás que hagan lo que tú quieres, sino sólo algo que se le parece. Los usuarios deben ser conscientes de la complejidad real de la máquina que tienen entre manos. Porque sólo si lo vislumbran se empezarán a preocupar. Y sólo si se preocupan (perciben el riesgo) decidirán que puede ser interesante adoptar ciertas medidas de seguridad.
Por otra parte, creo que sería necesario realizar un esfuerzo para conseguir que el usuario medio doméstico conozca las distintas soluciones gratuitas de seguridad que existen. Hay muchas webs públicas donde se pueden localizar, pero... ¿Cuántas de estas webs son visitadas por el usuario doméstico medio?
También creo que sería necesario que estos productos (antivirus, antispyware, firewall personal, etc.) estuviesen integrados en los equipos desde el momento inicial (compra). Pero no una versión temporal, sino una completamente funcional y por la que el usuario no deba pagar. Seamos sinceros, la mayor parte de los usuarios no paga por seguir utilizando algo que le han "regalado" sin pedirlo expresamente. Y tampoco si lo puede conseguir sin pagar por una vía alternativa. Así el usuario adquiriría un producto en el que la suite de seguridad no provoca ralentizaciones adicionales (ya que no conoce la velocidad sin ella) y cuya estabilidad y funcionamiento adecuado de partida estaría probado.
En definitiva, creo que las vías de actuación pasan por "obligar" al usuario a disponer de soluciones de seguridad fácilmente utilizables, y por "meterle miedo" hasta que sea consciente de los riesgos que existen. No son soluciones políticamente correctas, pero a corto plazo me parecen más efectivas que un programa de concienciación colectiva acerca de la seguridad de la información. Y de hecho podrían servir de caldo de cultivo para que una posible campaña de concienciación tuviera más gancho. Al fin y al cabo, la inseguridad no es un enemigo que juegue limpio...
22 octubre 2007
Gestion de cambios
En primer lugar, es importante identificar los cambios. Cambios que no tienen por qué ser internos o por iniciativa propia, sino que se pueden producir en el entorno. Y el punto crucial es ser capaces de detectarlos. Nuevas amenazas o vulnerabilidades quizás sean el ejemplo más socorrido, pero no tiene por qué ser el único. Cualquier factor del entorno, tanto cercano como lejano, puede cambiar, y nosotros tenemos que ser capaces de identificarlo y evaluarlo.
La segunda parte es, como acabo de indicar, evaluar el impacto de los cambios. Tanto directo como indirecto, tanto inmediato como a largo plazo. Ahora bien, hay que ser prácticos. No podemos evaluar absolutamente todas las consecuencias, muchas veces no sólo es poco rentable sino que es prácticamente imposible. No podemos estar evaluando infinitamente, la gestión de cambios debe seguir. Habrá que evaluar los pros y los contras más evidentes, sopesarlos, y decidir. Que habrá consecuencias que no hayamos previsto? Seguro. Y es que en cualquier decisión estamos asumiendo riesgos. Pero que conste que también lo hacemos si continuamos con nuestra evluación...
Decidir es el punto crítico. Hacer algo, o no hacer nada. Pero debemos tener en cuenta que la decisión de partida es no hacer nada. Mientras estamos evaluando, no estamos reaccionando al cambio. Estamos tomando, de facto, la decisión de no hacer nada. Y esa decisión tiene sus riesgos, al igual que la decisión de reaccionar al cambio. Sea cual sea la decisión, algo debe quedar patente: quién asume la decisión, sus motivos, y sus consecuencias. Y si estos tres factores quedan por escrito, mejor que mejor.
Hasta ahora hemos pensado que nuestra decisión de cambio es como reacción a otro cambio externo. En general suele ser así (reacciones a los cambios del entorno, del negocio, de las estrategias, ...), pero aun en caso de que el cambio sea originado internamente, la situación es idéntica: habrá que especificar quién decide (en base a sus funciones y responsabilidades), sus motivos, y las consecuencias previstas por dicha decisión.
Una vez que hemos recorrido el circuito de decisión del cambio, el resto es fácil. Hay que planificar (pensar) el cambio y cómo se va a llevar a cabo, ejecutarlo, verificarlo y registrarlo. El circuito típico. Sin embargo... cuántas veces se cumple por completo? Además, tenemos que tener en cuenta que dentro del ciclo de "ejecución" del cambio pueden aparecer nuevos factores que realimenten a la fase de decisión, y que puedan llegar a motivar su cambio. Esto no es algo que deba asustarnos, o que debamos evitar: una correcta gestión de cambios debe tenerlo en cuenta. Pero debe tenerlo en cuenta de esta forma, sin necesidad de una planificación "virtual" de todo el ciclo en la fase de decisión. Si no, nunca reaccionaremos a los cambios...
Quizás la mejor forma de ilustrar todo este ciclo es con un ejemplo. Pensemos en la publicación de una vulnerabilidad asociada a una aplicación de nuestro servidor central. El entorno ha cambiado. Cuál es la reacción asociada? Parchear. Qué inconvenientes tiene? Inestabilidad, mal funcionamiento, necesidad de una parada programada... Las ventajas también son claras: reducción del nivel de riesgo, que ha aumentado al publicarse la vulnerabilidad. Quién debe decidir? Supongamos que el director de sistemas, con el asesoramiento del responsable de seguridad y de los técnicos expertos en la aplicación y el servidor central. Qué decide?
Hasta este punto, la historia es más o menos sencilla. Pero... qué ocurre si el director de sistemas no cuenta con un entorno de pruebas para verificar la estabilidad del parche? O si el personal no tiene tiempo para realizar las pruebas? O si no cuenta con la asesoría necesaria? Sencillamente, que el riesgo de tomar la decisión aumenta. Pero esto en ningún caso significa que no pueda tomar la decisión. Y vuelvo a decir que mientras se llevan a cabo las pruebas, o se buscan recursos, se está tomando la decisión de no hacer nada, y por tanto asumir el riesgo asociado a la vulnerabilidad que se acaba de publicar.
Si el director de sistemas decide parchear, lo siguiente será planificar la parada, procedimentar el parcheo si es necesario, ejecutarlo, verificar la estabilidad del sistema tras la operación, registrar las tareas realizadas, ... Y que conste que todas estas fases son necesarias, no vale sólo con la ejecución. Por supuesto, "con cabeza": probablemente la instalación de una nueva fuente TrueTipe no requiera la misma profundidad de gestión que el parcheo de la base de datos Oracle. Aunque sí las mismas fases...
En resumen, una buena gestión de los cambios es clave para la seguridad. Tanto a nivel IT como a cualquier otro: documental, operativo, contractual, ... Nuestra gestión de cambios deberá ser integral, y asegurar que se cumplen todos los pasos en todos los entornos. Y si no, ser conscientes de que estamos asumiendo el riesgo de no realizar una correcta gestión de cambios. Cómo se cuantifica este riesgo? Eso ya es otra historia...
19 octubre 2007
Fallos de recuperación
En primer lugar, me llama la atención la afirmación de apertura del artículo. Y no tanto porque refleje las dificultades de gestión económica intrínsecas a la gestión de riesgos, sino porque hace referencia al "director de sistemas". Entiendo que es Symantec, y que por tanto hablan de IT, pero no puedo hacer otra cosa que recordar uno de los últimos post acerca de las diferencias entre continuidad IT y continuidad de negocio...
Las preocupaciones a nivel de seguridad tampoco son nuevas. Aparece el malware, los desastres (de origen natural o humano), las fugas de información y la no continuidad del negocio. La solución pasa, cómo no, por garantizar la disponibilidad de la información (con backups seguros), pero sin olvidar la seguridad (confidencialidad, integridad, control de acceso, etc.) de la misma.
La parte más llamativa viene de la mano de los datos numéricos. Se afirma que una empresa enfrentada a una situación de desastre muere en un año, sin un plan de recuperación. Dónde está el truco? Por supuesto, en que la probabilidad de que la empresa se enfrente a ese desastre es muy baja. Precisamente ese es el motivo de que muchas empresas carezcan de un Plan de Continuidad de Negocio. Y si los riesgos asociados a esta carencia están analizados y asumidos, la opción me parece totalmente lícita.
Por otro lado, tenemos la opción de implementar un Plan de Continuidad. Aunque si hacemos caso al informe, tampoco parece una opción muy halagüeña. Se consigue una sensación de seguridad, pero luego resulta que en el 50% de los casos el Plan falla. Y los motivos son muy amplios: plan mal diseñado, fallos en su ejecución o fallos en la tecnología. Pero... cuál es la causa última? Desde mi punto de vista, creo que el origen de estas situaciones es común: planes de recuperación implementados más "por cumplir" que por garantizar el negocio. Por eso no se prueban, y por eso fallan: falta concienciación.
En definitiva, creo que el problema es que la continuidad de negocio debe ser algo más que una moda entre la alta dirección. Deberá llegar el momento en el que se deje de pensar en quedar bien frente a los accionistas y se empiece a pensar en desarrollar Planes de Continuidad que realmente sean abordables, eficientes y eficaces. Porque sólo en ese momento la continuidad de negocio se podrá ver como algo de todos, y los departamentos de sistemas empezarán a tomárselo como una ventaja en lugar de entenderlo como un capricho impuesto. Porque en algunos casos, cierta razón no les falta...
15 octubre 2007
Cuanto le cobramos?
La verdad es que cobrar por horas suele ser una táctica habitual para los servicios de consultoría. A tanto la hora de consultor senior, a tanto la de junior… Como cuando vas a la charcutería a comprar embutido. Sin embargo, la diferencia entre un kilogramo de jamón cocido o una hora de consultor es evidente…
Es cierto que, como dicen en un famoso anuncio de televisión, hay cosas que no tiene precio… Y lo malo es que incluso a ésas alguien decide ponerles uno. Calculado, para más inri, con lápiz y calculadora y en un par de minutos (cuando no se usa la táctica de chuparse el dedo y levantarlo en alto como método empírico de cálculo). El resultado, por supuesto, suele ser poco agradecido tanto para el consultor, que ve cómo se subestima la importancia de su trabajo, como para el cliente, que acaba con la sensación de que le están tomando el pelo. Y algo de razón no le falta, cuando resulta que si el consultor es bueno y le resuelve la papeleta en la mitad de tiempo, a él le saldría a mitad de precio… Vamos, un sinsentido.
Para mí, esto del cobro por servicios se parece a una partida de mus. Hay unas empresas que juegan a grande, y otras que juegan a chica. Las que juegan a grande son esas empresas que apuestan por la formación, por la contratación de personal altamente cualificado… y que no pestañean al cobrarte una buena suma de dinero por resolver un determinado problema. Sin horas, sin cálculos para justificar el precio. Sólo teniendo en cuenta los resultados, y con la seguridad de que el cliente quedará satisfecho. Empresas capaces incluso de hablar de SLAs en este tipo de servicios. En definitiva, empresas que apuestan fuerte porque tienen varios reyes de mano. Cuántas hay de este tipo? No muchas, me temo.
El otro tipo de empresas son, como ya he dicho, las que juegan a chica. Las que tratan de ganar dinero hora a hora, punto a punto, envidando a chica cuando todos han querido el envite a grande. Es una estrategia contraria a la anterior, conservadora, que se queda con unas cartas mediocres si piensa que conseguirá algún punto. El objetivo es no perder dinero, así que se cobra por horas, tratando de garantizar en todo momento que se cubren los gastos y el margen para ese determinado servicio.
El problema en sí no es la estrategia de la empresa. Es tan defendible un caso como el otro. Cada uno tiene sus ventajas y sus inconvenientes. El peligro es, como en el mus, las empresas que juegan de farol. Que van de empresas punteras, que se venden como tales, pero que en realidad juegan sin cartas. Donde sus personas no están suficientemente formadas, ni se dan mus para buscar reyes que les permitan completar la mano. Estas empresas son un problema tanto para el mercado como para el cliente. Para este último, porque el riesgo de que sus expectativas no se vean satisfechas es alto. Y para el primero, porque demasiadas empresas de este tipo provocan una devaluación del mercado, y una sensación generalizada de que el sector de la consultoría vende humo. A alguien le suena?
En definitiva, esto del cobro por servicios es un tema que da para muchas reflexiones. Si sirven o no para llegar a alguna parte, ya se verá con el tiempo. Espero, al menos, que este semi off-topic haya sido ilustrativo… y que haya despertado el interés por el mus para todos aquellos que aún no lo conozcan. :-)
05 octubre 2007
BCMS o ITCMS?
Y pese a que esté tan de moda, en muchos casos es habitual encontrarse con graves errores de concepto en este ámbito. El más preocupante, a mi entender, es confundir un BCMS (Sistema de Gestión de la Continuidad del Negocio) con un ITCMS (Sistema de Gestión de la Continuidad de los Servicios IT). En demasiados casos se escucha el término continuidad de negocio para referirse a la continuidad de los servicios IT. Y las diferencias son enormes.
Es cierto que cada vez más las actividades de negocio están soportadas por la infraestructura IT. Sin embargo, negocio y servicios IT no tienen por qué ser lo mismo. De hecho, casi nunca lo son. Hay que aprender a diferenciar los servicios IT de los servicios profesionales, o prestados por personas. Por qué? Porque realmente hay muchos negocios que no son IT, sino profesionales. Y en esos casos, garantizando la continuidad de los servicios IT no garantizamos la del negocio.
Pensemos, por ejemplo, en la banca. Pueden funcionar las ventanillas sin ordenadores? Probablemente sí. Quizás no puedan hacerlo indefinidamente, pero para sacar o meter dinero en nuestra cuenta no necesitamos al ordenador, si la persona que está en la ventanilla puede registrar los movimientos a mano (y ya los volcará en los sistemas informáticos cuando estén disponibles).
En qué casos coinciden un ITCMS y un BCMS? En aquellos en los que el negocio es EN SÍ MISMO un servicio IT. Pensemos en la banca por Internet, o en las tiendas on-line. Esto no quita que en un ITCMS no haya que tener en cuenta a las personas, ya que los sistemas siempre son administrados y mantenidos por alguien, pero supone que un BCMS deberá exceder, y con mucho, al departamento IT. Si queremos que nuestro negocio de venta de tornillos siga adelante, nuestro BCMS tendrá que tener en cuenta aspectos como la línea de producción, la actividad de los comerciales, la logística... Si nos quedamos en un ITCMS para todos los sistemas, podemos encontrarnos con que una inundación o una nevada de esas que hacen historia nos paraliza por completo la actividad de nuestro negocio. Y si nuestros comerciales cogen una infección en una comida de empresa y se tiran en cama durante dos semanas, resulta que durante esas dos semanas no hay nuevas ventas. Eso sí: nuestros sistemas no han tenido ni un segundo de parada. Pero el negocio está parado...
En definitiva, creo que es necesario tener clara la diferencia entre negocio y servicios IT. Que cada día la dependencia es mayor, pero mientras el negocio recaiga sobre las personas, no será suficiente con salvaguardarnos ante una caida de la infraestructura informática. Y menos si resulta que las personas clave para el negocio están fuera del departamento IT...
03 octubre 2007
Gestion de terceros
La primera necesidad es, sencillamente, regular el papel de estas terceras partes. Definir concretamente qué hacen y qué no, en relación a nosotros. Puede parecer una obviedad, pero este es el primero de los problemas. ¿Qué ocurre si hay una discrepancia? ¿Nos podemos agarrar al contrato? ¿A la oferta? Pero... ¿existe algún sitio en el que se especifique qué me suministra esta empresa, o qué horario de servicio tiene para mi? Es sorprendente la cantidad de veces que "no se encuentra" el dichoso documento...
Supongamos que ya tenemos claro el "catálogo de servicios recibidos". Ahora que ya conocemos el papel de estos terceros, podemos identificar en cuáles de mis actividades están implicados. Porque resulta que les tendré que exigir lo mismo que me exijo a mí mismo... en cada caso. Si el servicio soporta la fabricación, posiblemente no tenga sentido incluir exigencias de tratamiento de datos personales. Y a un servicio de limpieza no tiene por qué ser necesario exigirle una disponibilidad >99%. Los SLAs son necesarios en algunos casos, pero el sentido común es imprescindible en todos. Y no por meter más cláusulas y condiciones tenemos mejores contratos.
Pero resulta que la parte complicada en la gestión de terceros no es el contrato, que a fin de cuentas se redacta y firma una vez, sino su ejecución. Para una correcta gestión de terceros es necesario un seguimiento del mismo. Las reuniones periódicas entre la organización y los terceros son imprescindibles. Hay que hacer ajustes, aparecerán cambios que quieran introducir ambas partes, el mercado evoluciona... Además, los propios implicados en el servicio (por ambas partes) deben participar en este seguimiento. Jefes y comerciales suelen ser habituales en este tipo de reuniones, pero las fricciones surgen en el día a día, y los que las conocen son los que las sufren. Y por regla general también quienes más claramente pueden identificar fallos y posibilidades de mejora. Muchas veces basta con preguntar adecuadamente para obtener la respuesta que se busca...
Por último, y en términos de seguridad, es necesario prevenir la relajación. Seguro que el primer día, si estamos concienciados en materia de seguridad, establecimos todas las medidas necesarias para asegurar que las terceras partes cumplen con nuestras políticas. Comunicaciones seguras, logs de actividad, registros, ... Y cómo trabajamos hoy con nuestro proveedor, que ya es "de confianza"? Seguimos manteniendo las mismas medidas? La revisión y auditoría de este tipo de relaciones con terceras partes es una medida necesaria para prevenir la aparición de los problemas derivados de la relajación de las medidas de seguridad. Por supuesto que las medidas internas también deben ser auditadas de igual modo, ya que se suponen equivalentes, pero no podemos olvidarnos de los proveedores. Y os aseguro que pocas empresas proveedoras pasan auditorías de sus clientes.
En definitiva, la gestión de terceras partes es clave para garantizar la propia seguridad. Los SLAs, además de estar de moda, son una herramienta muy útil para regular esta gestión, pero no debemos olvidar que la parte complicada no es la firma del SLA, sino su cumplimiento. Y que una organización que sepa gestionar estas terceras partes, aunque no tenga ningún tipo de SLA, probablemente rinda a más nivel que una en la que se cumpla el caso contrario. Ah, se me olvidaba! Herramientas que se puedan utilizar en estos casos? Sobre todo, una sin automatizar y más cara de lo que parece: sentido común.
28 septiembre 2007
El Esquema Nacional de Seguridad
La Ley de Acceso Electrónico de los Ciudadanos a los Servicios Públicos (Ley 11/2007, de 22 de Junio) regula, en términos generales, las condiciones que deberán cumplir las Administraciones Públicas para permitir el acceso electrónico a los servicios prestados, tanto por parte de los ciudadanos como entre las propias administraciones. Sin embargo, y pese a que el contenido principal de dicha Ley se centra en regular la "interoperabilidad electrónica", esta Ley también lleva a cabo un importante esfuerzo en tratar de garantizar la seguridad de los servicios electrónicos prestados por las administraciones.
Ya en el Artículo 1. párrafo 2. podemos leer que las Administraciones Públicas asegurarán "la disponibilidad, el acceso, la integridad, la autenticidad, la confidencialidad y la conservación de los datos, informaciones y servicios". ¿A alguien le suenan esos conceptos? ¿No recuerda este enunciado al contenido de cualquier Carta o Política de Seguridad de la Información de Alto Nivel de cualquier organización que disponga de ella?
La Ley habla de las distintas dimensiones de la seguridad de la información a lo largo de todo su articulado. Sin embargo, la parte más "jugosa" la podemos encontrar en el Artículo 41. párrafo 2., en el que podemos leer que "el Esquema Nacional de Seguridad tiene por objeto establecer la política de seguridad en la utilización de medios electrónicos en el ámbito de la presente Ley, y está constituido por los principios básicos y requisitos mínimos que permitan una protección adecuada de la información". ¿Puede recordar a una articulación clásica de las Políticas o Normativas de Seguridad de cualquier organización? Por supuesto que sí.
La propia Ley indica, en el párrafo siguiente, que dicho Esquema se aprobará por Real Decreto, y señala los participantes y supervisores previstos para su elaboración. Lamentablemente, la redacción de la Ley está en futuro, y pese a que la Ley es del verano, ya se sabe que en temas legales el tiempo transcurre muy lentamente. Sin embargo, creo que la propia aparición de la Ley ya debe ser motivo de satisfacción dentro del sector, y si los plazos que marcan las disposiciones finales de la propia Ley se cumplen apropiadamente, la redacción preliminar de dicho Esquema es posible que llegue bastante antes de lo previsto.
Pese a la importancia que pueda tener la aparición de un marco regulatorio completo en materia de seguridad de la información, no debemos olvidar que dicho marco sólo es aplicable a la administración electrónica. Es cierto que puede servir de "inspiración" para la empresa privada, pero hay que tener claro que previsiblemente el futuro Esquema deje de lado muchos ámbitos de actuación. Ya nos lo recordaba en su día el director de la revista SiC, de modo que no está de más tener en cuenta que este marco regulatorio es un marco de mínimos generales, y que siempre podrán aparecer exigencias adicionales que completen y refuercen los requisitos exigibles.
24 septiembre 2007
Gestión de perfiles: la clave de la seguridad
El primer tema que quiero tratar es la gestión de perfiles como piedra angular de la seguridad ligada al personal. Pero no gestión de perfiles desde un punto de vista técnico, sino gestión de perfiles desde el punto de vista de gestión de los recursos humanos.
El término perfiles puede ser ambiguo, así que prefiero hablar de los distintos aspectos que debemos gestionar en relación a las personas: funciones, roles, responsabilidades y privilegios. Vamos por partes.
La gestión de roles (o cargos, si se prefiere) es un aspecto presente en todas las organizaciones. Al menos, en apariencia. Todas las empresas tienen sus organigramas, mejor o peor definidos, y cada persona tiene su "título" dentro de la organización. Sin embargo, poca "gestión" suele haber en relación a estos roles: en general, los organigramas no se suelen revisar ni retocar demasiado (al menos, no como consecuencia de una revisión sistemática de los mismos).
La gestión de funciones suele ser un aspecto mucho más descuidado. En general, es poco habitual encontrarse con una definición completa de las funciones asociadas a cada rol, y si ni siquiera están escritas difícilmente podrán ser gestionadas adecuadamente. Quizás sea un rasgo cultural, tal como dejaba entrever Samuel Linares en su blog, pero el caso es que la carencia es clave desde el punto de vista de la seguridad. Cómo se pueden articular las medidas adecuadas para que cada persona preserve la integridad, confidencialidad y disponibilidad de la información que maneja en su día a día, si no está definido ese día a día? La solución de "café con leche para todos" acaba volviéndose en contra de la organización, tanto por exceso de presión normativa para unos como por reglas insuficientemente estrictas para otros. Pero no se puede ser más granular si no está establecida la vase sobre la que se deben aplicar las normas de seguridad...
La gestión de responsabilidades es el eterno caballo de batalla. Cuántas veces nos hemos encontrado con "marrones" que nadie quiere asumir? Y todo por que, unido a lo anterior, no se definen los roles encargados de ratificar determinadas decisiones, o de supervisar determinadas acciones. A río revuelto... Y ni siquiera las empresas que más se preocupan por estos temas suelen tener en cuenta dos aspectos clave: las responsabilidades delegadas lo deben estar formalmente (y "aceptadas" documentalmente), y la definición de responsabilidades se debe revisar periódicamente. Cuántas personas siguen siendo "responsables" de una tarea que realizaban en un puesto en el que ya no están?
Por último, tenemos la gestión de permisos o privilegios de acceso. En realidad no debería ser algo con entidad propia, ya que estos permisos no deberían ser más que la articulación tecnológica de los aspectos anteriores, pero desde el punto de vista técnico la tarea tiene un peso específico propio nada desdeñable. Los permisos de los usuarios, o más bien los permisos asociados al identificador lógico de cada persona, deberían ir en consonancia con las funciones y responsabilidades asociadas al rol que cada uno desempeña dentro de la organización. Y su revisión no debería ser más que la constatación de que ambos coinciden. Ahora bien: si todo lo anterior no está formalmente definido, contra qué se van a contrastar estos permisos de acceso? Difícilmente podrá nadie de Sistemas verificar si los permisos son correctos o no. ¿A quién corresponde llevar a cabo esta revisión? Evidentemente, a la empresa. Pero la pregunta es: ¿A quién, dentro de la empresa? Sencillamente, a quien tenga definida esa tarea entre sus funciones. Aunque claro, si el problema es que esa definición es la que falta...
En resumen, la revisión de funciones, roles, responsabilidades y permisos debe ser una tarea propia de la gestión de los recursos humanos, no de los departamentos técnicos. Sólo debería llegar a este área cuando exista una documentación formal, aprobada, revisada y mantenida contra la que contrastar dichos permisos. Y en caso de que no exista, la validación de privilegios de acceso debería ir escalando por el organigrama hasta llegar al máximo órgano competente... siempre que esté definido.
Alguien se preguntará que por qué no he citado ninguna herramienta de gestión de identidades, ni he hablado de metadirectorios, ni he mencionado en ningún momento un LDAP. Sencillamente, porque la gestión de perfiles es previa, y excede a cualquier tecnología, como acabo de señalar. ¿En cuántos proyectos de gestión de identidades se respeta esta premisa? ¿Cuántos proyectos de gestión del conocimiento tienen en cuenta estos aspectos? ¿Cuántos de ellos tienen un trabajo exhaustivo de definición de perfiles previo a la implantación de la herramienta de turno? Y claro, luego suele sorprender que muchas organizaciones sigan teniendo problemas de gestión de perfiles y usuarios tras la implantación de la super-herramienta de turno...
19 septiembre 2007
El problema interno
Sin embargo, como dice este artículo, no son necesarios los atacantes externos para que las empresas puedan sufrir graves incidentes de seguridad. De hecho, el error humano, los ataques internos de personal descontento, los errores de programación o los fallos de hardware son causas mucho más habituales de incidentes de seguridad que los ataques externos, y en muchos casos con repercusiones mucho mayores. De hecho, tal y como afirman en este artículo, uno de los principales quebraderos de cabeza de los responsables de seguridad actuales son los pen-drives, o memorias USB. Tanto desde el punto de vista de la extracción de información corporativa para beneficio propio como desde el relativo a los riesgos que puede suponer la pérdida de estos pequeños dispositivos con tan alta capacidad de almacenamiento.
¿Cómo se pueden evitar estos problemas? En general, mediante dos estrategias complementarias. La primera de ellas trata de gestionar los riesgos derivados del eslabón humano, el más débil de la cadena. Y no sólo mediante la formación, evidente para cualquier iniciado, sino sobre todo desde el departamento de recursos humanos, que debe desarrollar políticas de personal que traten de mantener "contentas" a todas las personas de la organización.
La segunda estrategia es complementaria, ya que se encamina a la gestión de los riesgos de componente técnico. Básicamente, y en línea con lo que refleja el artículo señalado inicialmente, hay que tratar de simplifircar la tecnología y tener en cuenta la seguridad desde el principio. Divide, asegura, y vencerás. La tecnología lo permite. Entonces, cuál es el problema? El de siempre: el coste. Queremos realmente hacer el esfuerzo de diseñar e implementar sistemas seguros? Compensa la inversión?
Precisamente los costes son uno de los principales problemas de los gestores de TI en todo el mundo, tal y como dice este artículo. Pese a que la seguridad de la información sea una de las prioridades en este ámbito, parece ser que el coste es excesivo. Además, ese mismo artículo refleja la aseveración inicial de que el riesgo interno no se percibe como tal, y desde mi punto de vista esta puede ser una de las causas del insuficiente apoyo directivo a la seguridad de la información del que también se quejan los gestores TI.
Cuál es, por tanto, la vía de actuación a seguir? Ambas estrategias de reducción de riesgos de seguridad de la información son complementarias, pero con la ventaja de que hasta cierto punto una puede cubrir las carencias de la otra. Aquello que no podemos lograr con tecnología quizás seamos capaces de conseguirlo con "mano izquierda" en materia de seguridad. Por tanto, será cuestión de cada responsable, una vez conocida la cultura empresarial, decidir qué combinación de estrategias adoptar a la hora de tratar de reducir los riesgos identificados para conseguir los fines deseados. Al fin y al cabo, cocinar es algo más que mezclar ingredientes. Y todos sabemos que la cocina es un arte...
17 septiembre 2007
Fiarse del entorno
- Las necesidades de almacenamiento crecen de forma importante.
- En general, las empresas están poco preparadas en caso de pérdida de datos.
- Uno de los principales retos para una buena gestión del almacenamiento parece ser la actualización tecnológica.
- Las decisiones de compra de soluciones de almacenamiento están influenciadas por el entorno.
La verdad es que si analizamos detenidamente el informe, el resultado puede ser más preocupante de lo que parece a priori. Sobre todo, si partimos de los dos últimos apartados.
La importancia del entorno en la toma de decisiones me parece preocupante. Máxime si la conjugamos con la actualización tecnológica como solución. Que me entero de que el vecino tiene un problema y se ha comprado un nuevo "juguete" para resolverlo? Pues yo también. Parece como si el criterio de decisión fuera "lo que hacen los demás", y sobre todo "lo que compran los demás". Un panorama peligroso si ahora ponemos en juego a los avispados comerciales que tratan de vender estos nuevos "juguetes", y que vienen contándonos que "al vecino le ha funcionado". ¿Qué profundidad de conocimiento tengo del problema del vecino? ¿Y de mi problema? ¿Es realmente cierto que a él le ha funcionado la solución? ¿Por qué motivos? ¿Seguro que a mí me sirve la misma solución? Y si es así... ¿Es la mejor solución para mi? ¿La relación coste-beneficio de esa solución es la que yo necesito? ¿Tengo una opción más eficiente?
La verdad es que fiarse tanto del entorno me parece peligroso. Y fiarse del entorno para nuevas compras, más todavía. El problema de fondo es que falta una reflexión profunda sobre las necesidades reales de mi organización. ¿Es cierto que mis necesidades de almacenamiento crecen tanto? ¿Qué almaceno, datos o información? Qué información necesito almacenar, y por cuánto tiempo? Necesito salvaguardarla? La gestión del almacenamiento puede llegar a ser un arte, pero una empresa que cuente con una buena gestión del almacenamiento se puede llegar a ahorrar MUCHO dinero. Y sobre todo, seguro que se puede ahorrar muchas inversiones ineficientes e ineficaces. Si es tan beneficioso, dónde está el problema? Sencillamente, en que para conseguir una buena gestión del almacenamiento necesitamos previamente una buena gestión de la información. No podemos ahorrarnos los backups diarios de una información que sólo cambia semanalmente si quien debe configurar dichos backups no conoce esa característica. Y esa situación se debe dar con toda la información de la organización...
En resumen, fiarse del entorno puede ser peligroso si no conocemos todos los datos, y siempre es más conveniente buscar colaboración en la propia organización que en los problemas del vecino. Al fin y al cabo, además de ahorrar espacio en disco estaremos ayudando a conseguir esa deseada alineación entre las TI y el negocio, aunque sea en el ámbito concreto del almacenamiento. Y seguro que, en el fondo, todos nos agradecen no tener que ampliar nuestra cabina de discos...
12 septiembre 2007
Buscadores y Datos Personales
Supongamos que tengo un buscador. En concreto, un buscador "patrocinado con publicidad personalizada" (textualmente). Que mi página principal de acceso a ese servicio web muestra un texto que dice que, si uso el servicio, estoy declarando haber leído y aceptado las condiciones de uso del mismo. Que ese texto es un link a las condiciones de uso en las que afirmo, entre otras cosas, que voy a registrar toda la información de búsquedas asociadas a cada identificador de usuario con el fin de proporcionarle una publicidad personalizada de acuerdo al perfil que demuestren sus búsquedas. Que esa información la guardo cifrada en mis servidores por un periodo de un año desde el día de su recogida y procesamiento, y que el usuario puede dirigirse a una dirección de e-mail de contacto para ejecutar sus derechos de acceso, rectificación, oposición y cancelación.
Y la pregunta es: ¿Incumple este buscador la LOPD? Estoy informando de la recogida de datos personales, el usuario está aceptando dicha recogida, tiene capacidad para ejercer sus derechos en relación a los mismos, la finalidad de la recogida es acorde con el modo de financiación del servicio, y además estoy conservando la información cifrada por si el perfil del usuario puede ser entendido como datos especialmente protegidos (nivel alto). Supongamos que, por otra parte, cumplo con los requisitos del Reglamento para ficheros de nivel alto. Sería legal mi situación?
Yo no soy un experto en leyes, y no puedo responder con rotundidad a la pregunta. Pero a priori tiene pinta de que la respuesta es que sí. Entonces, cuál es la causa real de la polémica en torno a estos casos?
Creo que el problema es que la polémica, más allá de los términos legales, está mal enfocada. Muchos de los argumentos que se leen en relación a este caso hacen referencia al "abuso" de los buscadores, a que pueden llegar a actuar como un "gran hermano". Sin embargo, a la hora de atacar a los buscadores, se utiliza la "vía legal" como arma. Y el problema es que, desde mi punto de vista, creo que es posible seguir ejerciendo esa función de "gran hermano" dentro de la legalidad. Quizás el ejemplo que he presentado no sea completo, ni puede que el más apropiado, pero tengo la sensación de que empresas del tamaño de las que están sujetas a la citada polémica son capaces de encontrar vías para seguir actuando del modo en que lo hacen actualmente y que dicha actuación sea completamente legal en términos de protección de datos. Al fin y al cabo, es famoso el refrán de "hecha la ley, hecha la trampa". Entonces, cuál es la vía?
En caso de que se quiera conseguir que este tipo de empresas cambie su modo de actuación, creo que la única vía de "protesta" realmente consistente es la del uso de argumentos éticos. Es cierto que en la sociedad actual hay veces en las que este tipo de argumentos no tienen demasiado peso, pero también es cierto que muchas de estas empresas basan gran parte de su poder en la imagen de marca. Y si la ética de las empresas se ve públicamente cuestionada, la marca probablemente se vea afectada, y por tanto la compañía en conjunto. Al fin y al cabo, la progresión creciente de los esfuerzos de las empresas en desarrollar la Responsabilidad Social Corporativa (RSC) sólo se justifica porque este tipo de relaciones son más reales de lo que parece. Por tanto, creo que llegará el tiempo en el que la ética recupere parte del valor histórico que ha tenido, y no sólo como una moda, sino como un elemento diferencial de valor de una compañía. ¿Cuándo será éso? Probablemente deba pasar mucho tiempo antes de que lo veamos, pero por el bien de la sociedad, espero que sea antes de lo que parece...
07 septiembre 2007
Troyanos gubernamentales
Hoy quiero comentar brevemente toda la serie de noticias que han ido apareciendo durante los últimos días en relación a la existencia y utilización de software espía por parte de algunos gobiernos. Y creo que un buen punto de partida para argumentar mi posición es esta noticia, que recoge una postura crítica ante esta idea.
En primer lugar, y como puntualización, creo que es incorrecto hablar de troyanos. Aquí hay spyware, sí, pero en ningún momento se afirma que se haga pasar por software lícito. Vamos, que no hay “caballo”, sólo “soldados” que se infiltran en la “ciudad”. Pero ya que es el término que se está utilizando, lo mantengo en el título.
Por otra parte, reitero mi postura de que el software es neutral. En este caso, estamos hablando de un software que se usa para monitorizar exhaustivamente equipos remotos. De aquí a que esta monitorización se use para hacer un seguimiento de la actividad del usuario sin que este sea consciente ya va un trecho, y sólo ahora llegamos a la finalidad del software. Socialmente se considera que dicha finalidad es ilícita, y es por eso los fabricantes de soluciones de seguridad tratan de eliminarlo. Ahora bien: es realmente ilícita esta actuación? Las recientes noticias parece que lo ponen en duda, porque en realidad lo que se acaba valorando es la intencionalidad de dicha monitorización: sólo es ilícita si no se lleva a cabo por el bien de la persona monitorizada (sin entrar en si dicho “espionaje” lo realiza un gobierno o una empresa, que también existe).
Cuál es el problema? Precisamente, la neutralidad del software. Nadie asegura que las mismas herramientas se sigan usando de acuerdo a las intenciones iniciales, ni que las puertas abiertas para unos (con fines teóricamente lícitos, al menos para el gobierno en cuestión) las puedan aprovechar otros con fines ilícitos. Qué postura deben adoptar los fabricantes de software de seguridad? No introducir firmas para el spyware “legal”? Crear listas blancas de firmas? Y si algún spyware “malicioso” consigue “parecerse” lo suficiente al spyware legal? Seguro que es más fácil que ocultarse…
En resumen, el caso es que no estamos ante un problema técnico, sino principalmente legal y ético. Las mismas acciones deben ser legales o ilegales por defecto en función de quién las ejecute? Es un tema que se debería resolver en entornos legislativos y jurídicos, y permitir (e incentivar) a los fabricantes de software de seguridad que, por defecto, sigan protegiendo lo mejor posible la actividad informática de cualquier persona, sin excepciones. Al fin y al cabo, ya es suficiente con tratar de no perder mucho terreno frente al malware, como para empezar a poner obstáculos en una carrera en la que la desventaja ya es significativa… sobre todo, mientras hacer negocio con el malware siga siendo tan asequible.
Actualización: Según un juez, parece que el spyware sí es spyware, y los fabricantes hacen bien en catalogarlo como tal. Mantendrán esa misma postura si el spyware es gubernamental en lugar de privado?
06 septiembre 2007
Diferencias entre ISO 27001 e ISO 27002
Cuando hablo de las diferencias entre ellas no me refiero sencillamente al hecho de que una (27002) sea un código de buenas prácticas y la otra (27001) una especificación, sino a la filosofía y alcance que tienen una y otra.
La ISO 27002 es una guía para, en distintos ámbitos, conocer qué se puede hacer para mejorar la seguridad de la información. Expone, en distintos campos, una serie de apartados a tratar en relación a la seguridad, Los objetivos de seguridad a perseguir, una serie de consideraciones(controles) a tener en cuanta para cada objetivo y un conjunto de "sugerencias" para cada uno de esos controles. Sin embargo, la propia norma ya indica que no existe ningún tipo de priorización entre controles, y que las "sugerencias" que realiza no tienen por qué ser ni siquiera convenientes, en función del caso en cuestión.
Por su parte, y no nos olvidemos de ello, la ISO 27001 habla de los controles de forma residual. El núcleo de la norma anterior queda reducido a un listado de objetivos de control y controles incluidos en un anexo (normativo, pero anexo). No aparecen en el cuerpo de la norma, porque en absoluto son la parte más importante. Porque lo que importa en esta norma es la gestión de la seguridad, en forma de SISTEMA DE GESTIÓN. Desde mi punto de vista, los controles forman parte del anexo más por "compasión" que por necesidad. Lo que importa en la ISO 27001 es que los riesgos se analicen y se gestionen, que la seguridad se planifique, se implemente y, sobre todo, se revise y se corrija y mejore. Pero claro, a la hora de la verdad no se "atrevieron" a dejar totalmente abierto, sin ningún tipo de guía ni mínimo, el modo de implementar o mejorar la seguridad de la información, y por eso establecieron, aprovechando la norma anterior, un listado de controles sobre los que seleccionar los más apropiados. Para facilitar la gestión de riesgos tanto al implementador como al auditor, ya que la norma anterior (27002) sólo establecía sugerencias, pero no requisitos. Al menos, eso creo yo.
Por qué intento dejar claras las diferencias entre una y otra norma? Porque en muchos casos a la hora de pensar en implementar un SGSI la gente piensa rápidamente en ponerse a "cumplir" los 133 controles del anexo, y tratar de cumplir con todas las "sugerencias" que da la ISO 27002 para cada control. Y se olvidan de que el objetivo de la ISO 27001, que es la norma que define cómo tiene que ser un SGSI, es precisamente el CONTRARIO: que la empresa sea capaz de priorizar y seleccionar controles en base a sus posibilidades y a sus necesidades/riesgos de seguridad.
Qué quiero decir con esto? Que es mucho más importante asegurar el respaldo de la dirección, el establecimiento de una metodología efectiva de mejora continua o la existencia de un comité de seguridad que el cumplimiento exhaustivo y la trazabilidad del control x.y.z en no-sé-qué entorno de producción. Con la ventaja adicional de que probablemente sea más barato conseguir lo primero que lo segundo (si es más fácil o más difícil ya entra en el pantanoso terreno de la cultura empresarial... ). Qué pensais vosotros?
03 septiembre 2007
Re-pensando la estrategia de recuperacion
Hoy quiero comentar uno de estos artículos, que invita a re-pensar la estrategia de recuperación ante desastres desde un punto de vista tecnológico. En concreto, el artículo propone diseñar una estrategia de recuperación ante desastres basada en un centro de respaldo configurado en alta disponibilidad con el principal, como soporte para cinco "estrategias":
- Resolver los problemas rápidamente: Gracias a una detección temprana de los incidentes, mediante el uso de herramientas de gestión de la configuración (centralizadas y multi-consola, se sobrentiende).
- Automatizar los procesos de recuperación: Mediante la utilización de sistemas en alta disponibilidad y fail-overs automatizados entre ambos centros.
- Testear los planes de recuperación: Sin necesidad de parar el centro primario y en menor tiempo, gracias a la existencia de soluciones de alta disponibilidad y gestión centralizada.
- Sacar el valor del centro de respaldo: Gracias a su uso "en condiciones normales" como solución de alta disponibilidad o entorno alternativo multi-propósito.
- Virtualizar las soluciones de alta disponibilidad y recuperación: Como solución para lograr una infraestructura de respaldo más barata y sencilla de gestionar en situaciones de crisis.
Sin entrar a valorar los pros y contras de cada una de estas estrategias, lo que es cierto es que uno de las mayores dificultades a la hora de definir la estrategia de continuidad suelen ser los costes asociados a una solución de este tipo. Por tanto, creo que el principal requisito que debemos contemplar en la gestión de la continuidad de negocio es el famoso cost-effectiveness. Sin embargo, no debemos de perder de vista que la gestión de la continuidad debe estar integrada con el negocio (propiamente dicho), y por tanto yo resaltaría la cuarta "estrategia": dar valor al centro de respaldo.
En esta línea, sin embargo, creo que una inversión moderada puede permitir el traslado de entornos (ya existentes) de alta disponibilidad, desarrollo o pruebas a un CPD secundario y la adquisición de una solución medianamente potente de gestión de discos y backups que permita su uso "dual", como solución de continuidad, en caso de necesidad. En muchos casos, esta vía (crear un centro de respaldo con elementos pre-existentes) suele ser más sencilla (de entender) y viable que la alternativa (crear un centro de respaldo, y luego dar "utilidad" a ese equipamiento).
La solución "definitiva" para la viabilidad de este tipo de soluciones suele ser, como ya dice la quinta "estrategia", la virtualización. De hecho, la apuesta por la virtualización no es algo exclusivo de este artículo, sino que otros muchos expertos la secundan, como en este (1-2-3) artículo. Por supuesto, con sus ventajas e inconvenientes. Pero la verdad es que, a día de hoy, la virtualización es una de las mejores soluciones a la carencia de hardware idéntico...
28 agosto 2007
Gadget de seguridad
La idea es que, tras autenticarte a través de tu huella, ese aparato puede guardar en su memoria una "copia" de todas tus tarjetas, y grabar sobre la tarjeta virgen una réplica de aquella que necesites en cada momento (seleccionable a través de los botones y la pantalla). Luego, al volver a guardar la tarjeta dentro del dispositivo, los datos almacenados se borran.
A priori parece un dispositivo interesante. Sobre todo, porque según afirman en la web, también sirve para copiar tarjetas que funcionen con códigos de barras (que luego se visualizan en la pantalla) y tarjetas sin contacto. Vamos, que bastante completito. Pero claro, algunos detalles quizás se podrían mejorar...
El primero es el lector de huellas. Mis experiencias con ordenadores portátiles que incorporan dispositivos de ese tipo no son demasiado buenas. POr otra parte, existen cantidad de "tretas" para burlar este tipo de lectores biométricos... (y por lo que parece, funcionan). Por lo tanto, dos problemas: que el lector de huellas no funcione correctamente (indisponibilidad) o que alguien falsifique nuestra huella (no me paro a analizar los peligros de que te corten el dedo). Y claro, es el único control de acceso que se ha habilitado... Acaso es tan complicado la incorporación de un teclado numérico y el uso de un PIN como control de acceso adicional? Al fin y al cabo, todas nuestras tarjetas están almacenadas en ese dispositivo...
La segunda pega es, precisamente, el hecho de que todos los datos estén almacenados en un único dispositivo. Evidentemente, el riesgo de que te roben "todas" las tarjetas aumenta, ya que sólo tienen que robar un único aparato. Pero lo que me preocupa es que por el momento no he sido capaz de encontrar ningún dato que afirme que la memoria del dispositivo es segura. No vaya a ser que si el ladrón accede físicamente a la memoria del aparato sea capaz de leer la información almacenada...
Y la tercera es que, si nos ponemos quisquillosos, sería interesante que la tarjeta fuese una tarjeta inteligente, y contase con un chip de contacto programable. Al fin y al cabo, es una tecnología que en ciertos ámbitos se está extendiendo cada vez más, sobre todo en formato de tarjeta monedero.
Y por último, una duda. Más de una vez he tenido problemas con las bandas magnéticas de mis tarjetas, que por estar demasiado rayadas no se podían leer. Si esta tarjeta va a ser la única que utilicemos en todos los casos... cuántas veces al cabo del día va a ser leída? Cuál es la vida útil de la tarjeta virgen? Quiero pensar que habrán tenido este dato en cuenta, y que el aparato incluirá más de una...
27 agosto 2007
Gestionando con controles
La relación entre la aplicación o no de los controles y su intensidad es obvia. Evidentemente, sólo hablaremos de la intensidad con la que se aplican los controles que sí están aplicados. Aunque también sería posible hablar de la intensidad de todos, si definimos como “intensidad 0” todos los no aplicados. Así podríamos “comernos” una de las dimensiones, y facilitar la representación gráfica…
La relación entre la fortaleza de cada control y el alcance no es directa, y sin embargo es clave en todo SGSI. Esta relación viene a través de una “segunda derivada”: el análisis y la gestión de los riesgos. Es evidente que el análisis de riesgos se va a llevar a cabo dentro del entorno definido por el alcance. Y su resultado son los riesgos que es necesario gestionar. Ahora bien: cómo se deben gestionar dichos riesgos?
En primer lugar, debemos tener claro cual es el máximo nivel de riesgo que admite nuestra organización. A partir de ahí, si existen riesgos que superen dicho umbral, tendremos que seleccionar los controles a aplicar para reducirlos. Estos controles, por supuesto, pueden ser “nuevos” (previamente no estaban aplicados) o pueden estar ya aplicados. Diferencia entre ambos casos? A nivel teórico, ninguna: en las dos situaciones se trata de intensificar un control (de nivel 0 a nivel x o de nivel y a nivel y+x), con el fin de que la reducción del nivel de riesgo sea tal que el riesgo residual quede por debajo del umbral máximo definido.
Cuál es, entonces, la clave para seleccionar una u otra opción? La eficiencia y eficacia de cada una de ellas. De entre todas las opciones (aplicar un nuevo control a, intensificar otro b, o modificar un tercero c, por ejemplo) siempre va a haber una que sea la más barata, y una cuyos resultados sean los mejores. Y lo más habitual es que nunca coincidan. Así que habrá que valorar tanto el nivel de beneficio (reducción de riesgos) obtenido como los costes (inicial, de mantenimiento, de intensificación del control en caso de que se decidiera, …) asociados a cada uno de ellos.
Respecto a la selección de controles, un consejillo. En muchos casos suele ser más barato (y más sencillo) adoptar un nuevo control con “poca profundidad” (de forma manual en muchos casos y/o artesana en la mayoría) que intensificar uno ya aplicado (que habitualmente pasa por la adopción o mejora de soluciones tecnológicas, normalmente más caras). Y en muchos casos puede ser suficiente, sobre todo si tenemos en cuenta que el objetivo debe ser reducir el nivel de riesgo, no “eliminarlo”.
En resumen, vemos que una pieza clave sobre la que se articula la relación entre las dimensiones de un SGSI es el análisis de riesgos, y que su adecuada gestión va a ser un punto clave para conseguir un SGSI que se adecue a nuestras expectativas. No es una conclusión sorprendente, verdad? Al fin y al cabo, por algo es uno de los requisitos de la ISO 27001.
Y es que, en el fondo, todo se resume en lo mismo: conoce tu entorno, analiza y gestiona sus riesgos, y aplica el sentido común.
21 agosto 2007
Alcances globales
En el anterior post dejaba pendiente analizar las dependencias entre las dimensiones de un SGSI. Hoy me voy a poner con ello, analizando sobre todo una de estas dependencias, y haciendo un pequeño alegato contra-corriente: la apuesta por alcances “globales” para un SGSI.
Las dependencias naturales entre el alcance y los controles implementados son muchas. Es cierto que es posible definir un alcance “a medida” en el que pasemos por alto estas dependencias “naturales”, y librarnos en gran medida de dichas dependencias, pero es a fuerza de “inventar” límites y de poner puertas al campo. Y claro, el resultado más habitual suele ser la aparición de una burocracia exagerada y, sobre todo, antinatural ligada a estas fronteras artificiales.
Pero… de qué estoy hablando exactamente? Veamos:
- Los controles relativos a la seguridad del personal (A.8) normalmente suelen ser actividades desarrolladas por el área de recursos humanos.
- Los controles relacionados con la gestión de terceras partes (A.6.2, A.10.2) normalmente suelen recaer en las actividades que lleva a cabo el departamento de compras.
- La seguridad física (A.9) en muchas ocasiones corre a cargo del departamento de recursos generales.
- Las tareas que tienen que ver con controles técnicos (A.10 – A.12) suelen quedar en manos del área de informática interna, y repartidos entre los distintos departamentos en los que se suele subdividir (sistemas, redes, microinformática, …).
- La verificación de todo lo relacionado con los aspectos de cumplimiento (A.15) suele quedar en manos del departamento de auditoría interna.
- Y el resto de los controles (si es que se llevan a cabo) normalmente son actividades globales, comunes a toda la compañía, y cuya responsabilidad no suele estar demasiado bien definida.
Y qué ocurre cuando queremos implementar un SGSI cuyo alcance sea únicamente un solo proceso productivo, por ejemplo? Pues que los controles aplicables son, a priori, los del último punto… y todos los demás, ya que en ese proceso también tenemos personas, servicios subcontratados, ubicaciones físicas, sistemas informáticos… Y claro, nos encontramos con el problema de que tenemos que aplicar un montón de controles cuyos responsables “habituales” quedan fuera del alcance.
Cómo se resuelve este problema? La solución más habitual suele ser la creación de una serie de SLAs internos (quizás alguien los conozca como OLAs o MoUs) en los que se regulen las condiciones de seguridad en las que el resto de las áreas prestan servicios al proceso cubierto por el alcance, con una trazabilidad mínima que garantice que dichas condiciones puedan ser verificadas. Y claro, es aquí donde aparece el trabajo “en balde” y la burocratización, ya que hay que mantener unos “contratos” totalmente artificiales, que han aparecido simplemente por la necesidad de regular unos límites virtuales.
Existe otra solución? Yo creo que sí. Sencillamente, ampliar el alcance. De ese modo nos ahorramos la creación y mantenimiento de estos SLAs, y manejamos un alcance más completo y lógico. Evidentemente, la contrapartida es la necesidad de analizar los riesgos de nuevos procesos desarrollados por estas áreas, con el consiguiente aumento de recursos y tiempo necesario, pero creo que el diferencial final no es excesivamente grande, y además estamos cubriendo una serie de procesos en los que la información normalmente suele ser un activo de elevado valor.
Y con esto y un bizcocho… hasta el próximo post. Que todavía queda analizar el resto de dependencias, y este está quedando muy extenso.
17 agosto 2007
Dimensiones de un SGSI
La primera de las dimensiones de un SGSI es el alcance. Tenemos la libertad de decidir el número de procesos (o mejor llamarlos procesos de negocio?) que van a estar cubiertos por el SGSI. Seleccionarlos no es fácil, y en muchos casos es la clave para conseguir un SGSI realmente útil y efectivo. Como se puede comprobar aquí, casi existen tantos ejemplos de alcances como SGSIs... y no todos tienen por qué ser igual de efectivos. En su día ya dejé algunos consejos sobre cómo seleccionar el alcance, que creo que siguen siendo válidos. Es la dimensión "principal", hasta el punto de que debe ser pública, de modo que cualquiera sea capaz de verificar realmente qué partes de la organización están "protegidas" con una gestión segura de la información.
La segunda de las dimensiones de un SGSI es la relación de controles que vamos a implementar. Es una dimensión que aparece reflejada en el SoA (Statement of Applicability, o Declaración de Aplicabilidad), donde se indica al menos la relación de controles aplicados y descartados, junto con su justificación. Su importancia es tal que incluso aparece en las propias certificaciones, aunque en este caso sólo referenciada, ya que se considera que no debe ser una información pública. Pese a ello, yo creo que esta información debería ser accesible para clientes y/o proveedores que nos exijan requisitos de seguridad, ya que es un modo sencillo de que puedan verificar qué medidas de seguridad está teniendo en cuenta nuestra organización (y cuáles no).
La tercera dimensión es el grado de "fortaleza" de cada uno de los controles, el grado de intensidad (profundidad) con el que se está aplicando. No es lo mismo plantear un control de acceso físico visual que uno mediante tarjeta electrónica o que otro que además utilice reconocimiento de retina. Y está claro que es más efectivo disponer de un gestor de incidencias automatizado que mantener un registro manual en papel. Y sin embargo, todas las opciones estarían implementando el control correspondiente. Sin embargo, esta es una dimensión que no sólo no se suele identificar explícitamente, sino que en muchos casos es incluso difícil de evaluar. Y el problema es que es una dimensión clave para optimizar la eficiencia de un SGSI, ya que en muchos casos la inversión requerida para cubrir cada control depende directamente de la intensidad con la que se quiera cubrir...
En resumen, estas 3 dimensiones creo que pueden servir para reflejar de forma sencilla e intuitiva el "tamaño" de un SGSI. Lamentablemente, la representación gráfica del alcance suele hacerse en 2 dimensiones, así que si añadimos las 2 que nos faltan, el resultado puede no ser tan sencillo de interpretar (aunque siempre se podría incorporar una cuarta dimensión en forma de mapa de calor, por ejemplo). Podría ser su representación gráfica uno de los componentes del tan famoso cuadro de mando de seguridad? Quizás la segunda dimensión sea demasiado amplia, pero como propuesta, ahí queda...
P.D.: Y alguien pensará... A qué viene la referencia inicial de que las 3 dimensiones no son independientes, si luego no desarrolla la idea? Es cierto, me queda ese tema pendiente. Pero prefiero dejarlo para otro post, que este ya esta quedando lo suficientemente extenso... y el tema lo merece.
14 agosto 2007
Robos de datos
En este caso, parece que lo que han robado es un servidor con datos secretos de la policía británica. Y lo han hecho cuando dicho servidor estaba en manos de una tercera empresa. ¿Qué análisis se podría hacer de este hecho en términos de seguridad de la información? Unos cuantos, desde mi punto de vista.
En primer lugar, está el hecho de que exista una subcontratación. No es problemático en sí mismo, siempre que se tomen las medidas adecuadas. Aunque está claro que un secreto lo es menos cuantas más personas/entidades participen en él... Se supone que la policía debería obligar a la empresa subcontratista a cumplir unos estrictos requisitos de seguridad, y del tono del artículo se desprende que esto se cumple, así que primer escollo superado. ¿Se cumplirán todas las premisas y recomendaciones de la 27002 en los apartados de acuerdos con terceras partes? Contemplará el SLA correspondiente las penalizaciones y consecuencias derivadas de este tipo de incidentes?
El segundo aspecto a destacar es el reparto de responsabilidades no sólo por el incidente en sí mismo, sino también de cara a su resolución. La empresa subcontratista parece que ha cumplido su parte (datos protegidos (cifrados?) y copia restaurada), y la policía aparentemente también, como responsable de los propios datos (del artículo original parece desprenderse una asunción de responsabilidades). Aunque... hasta qué punto estaría esto regulado en el contrato?
Y sin conocer nada más que la información que aporta el artículo oficial, me aventuro a pensar que el principal fallo no ha estado en las medidas preventivas, sino en su verificación. La verdad es que no es habitual el realizar "tests físicos de intrusión", pero si estamos hablando de datos de tal sensibilidad, y de una subcontratación por medio, creo que la auditoría por parte del subcontratista de las medidas reales de seguridad que está implementando la empresa subcontratada debe ser obligatorio por contrato. Y sin embargo, es una práctica anecdótica (si es que existe) en la casi totalidad de las organizaciones que conozco...
En resumen, la noticia tiene pinta de ser uno de los pocos casos en los que aparentemente se ha explotado el riesgo residual una vez tratado, ese % restante para llegar al 100% de seguridad. Quiere decir esto que hay que "perdonar" el incidente? Realmente, no. Habrá que vigilar que las medidas de resolución de problemas realmente se llevan a cabo (se corrige la causa subyacente, revisando tal y como afirman toda la seguridad de la compañía), habrá que solicitar la depuración de responsabilidades ante los organismos apropiados (que ya decidirán si el castigo es o no necesario, y cuál debe ser si lo es) y sobre todo habrá que abrir una vía de actuación encaminada a resolver los problemas que pueda causar el uso de los datos robados. El incidente ya se ha producido, pero la diferencia entre una buena gestión de la seguridad y una mala se verá a la hora de verificar el cumplimiento de estos aspectos...