El Esquema Nacional de Seguridad (I)

Este post pretende ser la primera entrada de lo que será una serie relacionada con el futuro Esquema Nacional de Seguridad.

La idea con esta serie es informar sobre el Esquema Nacional de Seguridad: su origen, a quién afecta tanto directa como indirectamente, los puntos destacables, y cómo afectan estos aspectos a los diferentes actores involucrados. A lo largo de las distintas entradas profundizaremos más en los puntos del Esquema Nacional de Seguridad que entendamos más relevantes, siempre con la idea de que se produzca información útil y eminentemente práctica. Como introducción, en esta primera entrada hablaremos del origen del Esquema Nacional de Seguridad, para lo que se hace imprescindible hablar de la Ley 11/2007. Si desean echarle un vistazo al primer borrador, del pasado 15 de julio, lo tienen disponible desde la página del Consejo Superior de Administración Electrónica.

Origen del Esquema Nacional de Seguridad. La Ley 11/2007

Como muchos de nuestros lectores ya conocerán, este próximo Diciembre entra en vigor la Ley 11/2007. De manera muy resumida podemos decir que esta ley viene a dar derechos a los ciudadanos para comunicar electrónicamente con las Administraciones Públicas (en adelante AAPP). Por ejemplo, obtener un certificado de empadronamiento o gestionar mis cuentas con Hacienda deberá ser factible y sencillo desde Internet. Los ejemplos son innumerables, y todos aportan beneficios para el ciudadano.

Vemos pues que, en un plano teórico esta ley, en su esencia, ayudará a que paulatinamente las AAPP sean cada vez más agiles y eficientes, lo que repercutirá en que los ciudadanos nos beneficiemos de esta eficiencia. Hasta aquí la teoría: la eficiencia al asalto de las AAPP.

La realidad es algo diferente a lo que el plano teórico pretende, principalmente porque los recursos son los que son. Aún así, es de esperar que con el paso de los meses (o más bien los años en algunos casos, esperemos que no muchos) las AAPP terminen encontrado los recursos, al mismo tiempo que los ciudadanos comenzamos a hacer uso de los derechos que esta ley nos otorga. Es decir, a medio-largo plazo esta ley (de nuevo, en su esencia) será muy positiva para todos; no cabe duda de ello. Los ciudadanos podremos gestionar de forma diligente las tramitaciones que necesitemos realizar, y al mismo tiempo las AAPP podrán atender las peticiones ciudadanas ejercidas electrónicamente de forma mucho más eficiente (adiós a las ventanillas y a los “vuelva usted mañana”).

Llegados a este punto, ya tenemos una ley que, en el medio plazo, entendemos como muy positiva para todos, en tanto en cuanto nos permite gestionar con las AAPP desde el sofá de casa. ¿Perfecto? Aun no.
Existe una implicación más en lo que a esta ley se refiere, que es la base del Esquema Nacional de Seguridad. El hecho de que los principales servicios que ofrece una organización como la AP —la mayor organización del Estado Español— sean de carácter electrónico hará que la dependencia de las tecnologías de la información y las comunicaciones sea significativamente mayor que hoy en día, hasta el punto de que esa dependencia sea simplemente absoluta.

Es decir: sin TIC, no habrá Administración Pública.

En ese futurible bastante cercano (años, no decenios) se deberá tener presente, al mismo nivel que la funcionalidad, la seguridad con la que se presten dichos servicios, requisito imprescindible que debe nacer con la propia funcionalidad y no abordarse a posteriori como un agregado más. Sin esta seguridad no lograremos que el ciudadano sienta la confianza necesaria para utilizar su DNI electrónico, para dar de alta sus datos en el Ministerio de turno, introducir pines, etc. Sin confianza, no hay relación electrónica posible y esta confianza debe venir dada por la Seguridad en mayúsculas, con la securización holística de los activos que dan soporte a los servicios definidos por la Ley 11/2007.

Este es el origen del Esquema Nacional de Seguridad: Securizar los activos que la AP necesita para funcionar ahora y en el futuro, establecer un marco de referencia al que mirar cuando la AP quiera dar contenido al verbo securizar. De esta manera la propia Ley 11/2007 define en su artículo 42.2 el Esquema Nacional de Seguridad:

«42.2. 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.»

Antes de terminar, una aclaración: cuando decimos Seguridad en mayúsculas, cuando utilizamos el inexistente verbo securizar, estamos hablando de muchas cosas: estamos hablando de responsabilidad, de globalidad, de gestión, de políticas, de controles, etc. En definitiva, estamos hablando de lo que las normas internacionales dicen de Seguridad.

En futuras entradas de esta serie comentaremos a quién afecta el Esquema Nacional de Seguridad, así como sus principales contenidos. Los detalles y las opiniones los desgranaremos más adelante.

Anécdotas del kernel de Linux: SysMagic

La tecla mágica es una interrupción que permite comunicarse con el kernel en situaciones de inestabilidad en una máquina Linux, que viene habilitada por defecto en la gran mayoría de kernels precompilados de las distribuciones actuales. En caso de que compilemos el núcleo a mano, la opción “Magic SysRq Key” se encuentra en el menú “Kernel Hacking”. En el fichero de configuración del kernel recibe el nombre de CONFIG_MAGIC_SYSRQ por lo que realizando un “grep” de éste veremos si la hemos habilitado (debe aparecer CONFIG_MAGIC_SYSRQ=Y).

[Read more…]

Incorporando la seguridad al proceso de desarrollo de software

No es un secreto para nadie que una parte importante de los problemas de seguridad de los sistemas de información tiene su origen en defectos de las aplicaciones que éstos ejecutan. Tampoco lo es que estos defectos, que se manifiestan en forma de vulnerabilidades, se introducen en el software durante su proceso de desarrollo. Lo que a día de hoy no es algo aún suficientemente conocido, es la solución a este problema.

Históricamente, la industria del software ha funcionado usando una dinámica de liberar al mercado productos con un escaso nivel de madurez y se ha ocupado sobre la marcha de corregir los defectos que fueran apareciendo (véase el enfoque de Berkeley frente al del MIT en la entrada de Javier Vela al respecto, ¿Peor es mejor?). La situación actual es algo distinta ya que la capacidad del entorno de encontrar y explotar vulnerabilidades es muy elevada. Por tanto, liberar una aplicación al mercado, especialmente si está destinada a ofrecer servicios al público a través de Internet, sin haber tomado un mínimo de medidas para evitar la aparición de vulnerabilidades, es sin lugar a dudas una invitación al desastre.

La presión por cumplir con el calendario y el presupuesto de proyecto y la exigencia de los usuarios por disponer de nuevas funcionalidades, provocan con frecuencia que la seguridad no esté precisamente en la parte alta de la lista de prioridades de los equipos de desarrollo. Además, la eliminación de vulnerabilidades se suele entender como una tarea de la que alguien se encarga en la fase de testeo al final del ciclo de desarrollo, cuando la fase de programación ha concluido.

Sin embargo, el énfasis que desde distintas organizaciones se está haciendo por incorporar la seguridad al ciclo de desarrollo de software, así como iniciativas en esta línea de grandes corporaciones productoras de software, parece indicar que las tendencias están cambiando. Muchos pensamos hoy que todas las fases del proceso de desarrollo deberían compartir un objetivo: garantizar la seguridad del software.

A pesar de todo, es bastante común que en organizaciones que producen software, no exista ninguna incorporación formal de medidas de seguridad al ciclo de desarrollo. Los motivos son diversos: falta de presupuesto, de concienciación, de conocimiento… La realidad es que en la mayoría de los casos el software se valora fundamentalmente por la funcionalidad que implementa y la calidad del código raramente se considera; hasta que ocurre lo que nadie tuvo en cuenta…

La existencia de defectos de seguridad es hoy por hoy algo inevitable, sin embargo, la incorporación de una serie de medidas al proceso de desarrollo de software, permite reducir el riesgo a unos niveles aceptables. Con este objetivo se puede actuar en distintos puntos del proceso aplicando cada medida en el momento adecuado:

Análisis de requisitos

Resolver problemas de seguridad en un sistema en producción suele ser un proceso muy costoso y en ocasiones, con un alto impacto en el negocio e incluso en la imagen de la organización que ofrece el producto o servicio. Por este motivo, es importante tener en cuenta los controles necesarios para evitar su aparición desde fases tempranas del proceso, considerando los requisitos de seguridad como parte del análisis junto con los requisitos funcionales.

Es importante además no olvidar la consideración de aspectos de conformidad legal que incluyan en el catálogo de requisitos las obligaciones introducidas por regulaciones como la LOPD o la SOX entre otras.

Diseño

El diseño debe considerar aspectos como la reducción al mínimo de la interfaz atacable, así como su protección mediante la introducción de patrones y soluciones adecuadas para evitar la aparición de vulnerabilidades conocidas. En este punto es referencia obligada alguna de las guías existentes (las recomendaciones de OWASP por ejemplo) que recogen las vulnerabilidades más frecuentes junto con medidas técnicas para evitar su aparición.

Análisis de riegos (Casos de abuso y Modelado de amenazas)

Es frecuente que los analistas especifiquen los requisitos describiendo el comportamiento de un sistema “cuando todo va bien”. Esto suele llevar a una visión funcional del sistema basada en la asunción de que no va a ser objeto de abusos intencionados. Nada más lejos de la realidad, si el sistema va a ser usado, con toda seguridad se abusará de él (voluntaria a involuntariamente). El modelado de amenazas se realiza para determinar si el diseño propuesto mitiga los riesgos identificados y permite a los diseñadores ponerse en el papel del atacante:

  • ¿Qué partes del sistema son más fáciles de comprometer?
  • ¿Cuál es el impacto?

De esta forma las amenazas se identifican y se priorizan. A continuación se comprueba si la amenaza se mitiga mediante la implantación de un control. Si esto no es posible, se cambia el diseño o se asume el riesgo (idealmente, en función del risk appetite definido formalmente por la organización).

Análisis estático de código

En el pasado, el análisis de código se realizaba únicamente de forma manual. Era un proceso que daba buenos resultados cuando lo realizaba un experto, pero suponía un coste muy elevado. Hoy disponemos de herramientas de análisis estático que son capaces de identificar una buena parte de los errores de código por un coste mucho menor que el de un análisis manual.

El uso de estas herramientas es óptimo cuando todos los módulos que componen el software están completos e integrados. El análisis estático se debería realizar como mínimo en cada integración y siempre antes de liberar una nueva versión.

Testeo (o auditoria) de seguridad

Sería estupendo que el análisis estático fuese capaz de identificar todas las vulnerabilidades existentes en el software, pero desgraciadamente esto no es así. Por este motivo es necesaria la introducción de métodos dinámicos de testeo que interactúen con la aplicación como lo haría un atacante (Penetration Testing).

El testeo de seguridad es similar al testeo funcional del software con la diferencia de que en este caso se busca que la aplicación funcione de formas para las que no ha sido diseñada. El testeo funcional acaba (idealmente) cuando cada “feature” ha sido testeada, sin embargo, no es fácil identificar todas las cosas que una aplicación no debería hacer. Por este motivo es importante seguir una aproximación priorizada en la que se puede tomar como criterio la priorización realizada en el modelado de amenazas.

Existen varias herramientas que permiten la automatización del Penn Testing, pero de nuevo en este caso, será necesario contar con las manos de un experto para testear aquellos aspectos que no es posible automatizar.

¿Cómo empezar?

La incorporación de todas estas medidas, especialmente cuando se parte de una situación de poca cultura de seguridad, puede resultar algo abrumadora. Aunque el objetivo final debe ser que el proceso de desarrollo se enriquezca con todas las aportaciones descritas, no es imprescindible que se adopten todas desde el principio para obtener mejoras significativas en la seguridad del software producido.

La modificación del proceso se puede plantear como un proceso de mejora continua, empezando por aquellas medidas que requieren un esfuerzo y nivel de conocimiento y especialización moderado, para ir incorporando el resto según la experiencia y el know-how de la organización vaya creciendo.

Teniendo en cuenta que, especialmente en este caso, algo es mejor que nada, algunas de las medidas presentadas pueden ser adoptadas inicialmente asumiendo un coste reducido y con un retorno importante. El análisis de requisitos de seguridad puede ser la primera de ellas, garantizando así una toma de consciencia de los aspectos de seguridad a implementar. Por otro lado, la implantación de herramientas de análisis estático desde un principio, permite evitar un cantidad importante de errores y potenciales vulnerabilidades con una inversión muy contenida.

En este post se han presentado algunas medidas que tienen que ver directamente con el proceso de producción de software, pero existen algunas más que aplican al entorno de soporte del proceso (separación de entornos, seguridad de los repositorios de información, control de configuración, etc), pero eso da para otra entrada y lo trataremos en una próxima ocasión. Como siempre, pasen un buen fin de semana.

(Fuente de la imagen: OWASP)

Spring Art Work

Para hoy, tenemos un par de breves cuestiones relacionadas tangencialmente con la Seguridad de la Información.

En primer lugar, me gustaría presentarles el blog Spring Art Work, un blog mantenido principalmente por nuestro compañero Néstor Tarín, en el que tratará de cuestiones propias de desarrollo en el uso de frameworks —principalmente Spring, tal y como indica su nombre— utilizados para el desarrollo de aplicaciones (java y .Net) de manera cómoda, sencilla y correcta. Se trata de un blog técnico que incluirá artículos de distintos niveles de dificultad, y puede ser útil para comprender conceptualmente el uso de los frameworks presentados desde un perfil no técnico. Inicialmente su periodicidad será semanal, pero probablemente se incrementará a medida que el blog vaya cogiendo velocidad.

En segundo lugar, si llevan algún tiempo siguiendo el blog, sabrán que de un tiempo a esta parte hemos incrementado la frecuencia de publicación hasta hacerla diaria, exceptuando los fines de semana y algún día suelto que la inventiva está por los suelos. No obstante, teniendo en cuenta la relativa densidad de algunas entradas, tenemos cierta curiosidad por saber cuál sería la frecuencia de publicación ideal para nuestros lectores; si estamos llegando, nos quedamos cortos o nos pasamos. De ahí que hayamos creado la encuesta que les muestro debajo.

[poll id=”17″]

Mañana continuaremos con la programación habitual.

Seguridad sectorial (IV): eléctricas. Producción

Continuando con la seguridad del sector eléctrico que iniciamos el pasado lunes, vamos a comentar hoy aspectos relativos a la seguridad en la producción de energía, sobre todo en las áreas funcionales nuclear, térmica e hidráulica; el área funcional de energías renovables (por ejemplo, parques solares o eólicos) sufre menos amenazas y de menor impacto, siendo quizás el robo el mayor de los problemas a los que se enfrentan estos parques, cuya probabilidad se multiplica por su ubicación en lugares relativamente aislados.

Quizás las amenazas de mayor impacto en la producción eléctrica son las relativas a accidentes (fuego, fugas, explosiones…) y las relativas a terrorismo (bombas —físicas o lógicas, pero especialmente las primeras—, ataques con munición pesada, sabotajes…); en el caso nuclear es tal la preocupación general por el correcto funcionamiento de las centrales, debido a las implicaciones de un incidente, que existen normas nacionales e internacionales para garantizar su seguridad a diferentes niveles. En el caso de España, se considera poco probable un ataque de gran magnitud hacia una central nuclear por parte de ETA —sobre todo porque no resulta fácil para la organización terrorista hacer estallar un artefacto de magnitud sin poner en peligro la vida de sus miembros, y además porque un ataque indiscriminado de esa magnitud podría generar una movilización sin precedentes de repulsa social hacia la banda—; no obstante, las centrales nucleares sí que pueden convertirse en objetivo del terrorismo islámico, además de ser un objetivo prioritario en conflictos bélicos con otros países.

Aunque la seguridad de la información es crucial en todas las áreas funcionales de la producción eléctrica, desde la nuclear hasta las energías renovables, es especialmente en el caso de la producción nuclear donde la protección de la información es crucial, sobre todo su confidencialidad: todos los países están interesados en obtener información nuclear, especialmente de ensayos, del resto del mundo, y están dispuestos a gastarse mucho dinero para obtener estos datos. Y esto aplica tanto a los soportes digitales como al soporte papel, y por supuesto también al soporte “cerebro”: es especialmente importante controlar el conocimiento que ciertas personas pueden tener sobre el proceso, las instalaciones, etc., así como blindar —contractual, económica, legalmente…— su vinculación con la empresa hasta cierto punto.

Como amenazas particulares en la producción hidráulica, nos encontramos ante las catástrofes naturales (rayos, inundaciones, desprendimientos…) a las que, por la ubicación física de las centrales, éstas se encuentran expuestas; es menos habitual el ataque terrorista, ya que aunque se trata de ubicaciones perfectas para el ataque (aisladas y de difícil acceso, no vigiladas…), la repercusión que tendría el mismo no sería muy elevada salvo en el caso de voladura completa de la presa, para lo cual se necesitarían grandes cantidades de explosivos. En estos casos, se añade también la amenaza de robo, ya que no suele haber personal en muchas centrales, y mucho menos personal de seguridad, por lo que los materiales de la central se convierten en un objetivo fácil para los ladrones (sobre todo el cobre).

Para finalizar es necesario hacer referencia, sobre todo en el caso de la producción nuclear, y en menor medida, en la producción térmica, a las amenazas relativas a vandalismo y revueltas, por la polémica que sobre todo el uso de la energía nuclear siempre genera: manifestaciones, actos vandálicos… que por lo general no se materializarán en problemas de gran impacto, pero sí que pueden dañar elementos estructurales de protección —típicamente, del perímetro— o incluso paralizar la producción durante un tiempo indeterminado: intrusiones por parte de activistas, bloqueo del paso de mercancías o personas, etc.

(La fotografía de la entrada es de Picture Newsletter)

Formación especializada de ITIL

Con poco que hayan seguido este blog, sabrán que no hacemos un uso comercial de éste, primero porque no nos gusta, segundo porque existe contenido mucho más interesante, tercero porque no es ese el propósito de un blog, y por último porque eso supondría ahogarlo irremediablemente. Dicho esto, no obstante, en este caso nos disculparán si hacemos una excepción, que en mi opinión está justificada.

S2 Grupo ha iniciado un ciclo de conferencias y cursos especializados en la línea del trabajo que desarrolla, y en este sentido, para el próximo mes de diciembre (concretamente, 14, 15, y 16 de diciembre) hemos organizado, en colaboración con New Horizons (actualmente Tecnofor), el segundo curso de formación especializada en ITIL e ISO 20000 con certificación APM GROUP opcional al finalizar la acción formativa. El curso consta de un módulo de Introducción al código de buenas prácticas ITIL, una revisión a la norma internacional ISO/IEC 20000 y un caso práctico de Gestión de Incidencias basado en lo sucedido en el Apollo XIII.

A diferencia de la mayor parte de los cursos, para los que es necesario desplazarse a Barcelona o Madrid, éste se impartirá en las nuevas instalaciones de S2 Grupo en Valencia (C/ Ramiro de Maeztu), lo que supone un ahorro considerable en desplazamiento y alojamiento para aquellas personas o empresas cercanas a Valencia y que estén interesadas en asistir a un curso de este tipo. Los cursos se imparten en grupos reducidos para poder sacar el máximo provecho.

Pueden obtener más información de los anexos que se incluyen a continuación, mandando un correo a formacion [en] s2grupo.es, o llamando al 96 3110300. Mañana retomaremos la programación habitual.

Más información: [Información del curso] [ITILv2] [ISO 20000] [Caso práctico: Apollo 13]

* * *

En enero realizaremos un curso de similares características basado en ISO 27001, del que les daremos detalles más adelante. No obstante, si podrían estar interesados y desean información sobre éste, ya conocen los datos de contacto.

Seguridad sectorial (III): eléctricas. Introducción

(Véanse las entradas previas de la serie sobre banca y puertos)

altatensionSin duda estaremos todos de acuerdo en que el sector eléctrico en su conjunto, la integridad de sus instalaciones, la disponibilidad del suministro… son elementos básicos para garantizar la supervivencia de muchos servicios profesionales y el bienestar de la sociedad en general (¿alguien imagina pasar unos días sin luz eléctrica en cualquier gran ciudad?). Por todo esto, está sometido a una serie de amenazas que en caso de materializarse causarían un elevado impacto en nuestra sociedad, de ahí que esté considerado Infraestructura Crítica Nacional.

¿Cómo llega luz a nuestros hogares, calles, empresas…? De forma simplificada, en una central de producción eléctrica se transforma algún otro tipo de energía en energía eléctrica; estas centrales suelen ser nucleares, térmicas o hidráulicas, aunque cada vez más están proliferando centrales basadas en energías limpias, como las solares. Esta energía eléctrica se transporta y distribuye a través de líneas de muy largo recorrido, que van desde las centrales de producción hasta las estaciones de transformación; en estas últimas estaciones o subestaciones, se transforma la energía y se hace llegar hasta el cliente final (ya en baja tensión) para su consumo. Obviamente, todo este proceso está altamente controlado desde una serie de centros distribuidos, que velan porque la energía eléctrica llegue correctamente a su destino, detectando problemas en tiempo real y actuando ante los mismos en el menor tiempo posible (lo que podríamos llamar “la seguridad de la energía eléctrica”). Adicionalmente, como cualquier empresa, las eléctricas necesitan de unas instalaciones, personal, infraestructuras… fuera del ámbito de la producción directa: comerciales, directivos, administrativos…

[Read more…]

¿Confidencialidad, o simple confianza?

No sé si recuerdan la entrada titulada “El cuento de la lechera en la nube 2.0 (o porqué Google no contesta con rotundidad)” que escribimos en este blog hace ya unos cuantos meses, a raíz de la polémica desatada por Javier Mestre con su crítica al gigante estadounidense y el riesgo de utilizar Google Apps Premium Edition en entornos corporativos.

Sea como fuere, en los comentarios de aquella entrada se creó un (pequeño) debate entre “g” y Edgard que me parece muy interesante de cara a entender qué entendemos por seguridad. Resumiendo, la cuestión se sitúa en torno a la confianza que la declaración/compromiso/”contrato” de confidencialidad que Google genera en el usuario de sus servicios. Edgard lo expresó de una manera cristalina: “[…] Me temo que si Google cumpliera con toda la legislación habida y por haber seguiría siendo una opción un tanto arriesgada desde el punto de vista de la confidencialidad de los datos.“. Efectivamente, no hay que olvidar que el buscador está bajo el paragüas del acuerdo de Puerto Seguro (dejemos de lado las numerosas pegas que tiene este acuerdo, por decirlo de una manera suave), y que sin duda implanta innumerables controles físicos y lógicos para preservar la confidencialidad de los datos que gestiona, independientemente de su tipología. Dicho de otra forma, y dejando de lado los datos de carácter personal, me atrevo a afirmar que hay pocas pegas que ponerle a Google en la gestión de los datos de sus clientes y usuarios, y que legalmente está totalmente regularizado, quizá mucho más que otras tantas multinacionales de telecomunicaciones u organismos públicos. Y aún así, a pesar de esto, Google sigue sin transmitir una sensación de seguridad, cuyos detractores están en muchos casos relacionados con la seguridad de la información.

Dejemos a Google; en este caso es sólo un ejemplo. Lo que me interesa de lo expuesto hasta ahora es: tal y como expuso “g” en aquel caso, si Google dispone de todas las garantías legales, ¿no debería traducirse eso en que tiene todas las garantías? Parece ser que no; la sensación de seguridad va mucho más allá en este caso del cumplimiento legal en forma de una declaración o compromiso de confidencialidad. Pero, ¿está este hecho condicionado por la situación global y en cierto sentido hegemónica del gigante americano? Probablemente sí; de hecho, muchas empresas locales gestionan una gran cantidad de datos de pequeñas empresas y autónomos sin que exista un contrato de confidencialidad por medio, y aunque lo haya, los controles lógicos y físicos son probablemente menos exhaustivos que los de Google.

¿Estoy diciendo que deberíamos confiar en Google para que gestione el correo corporativo? No; sigo pensando que mantener información confidencial en los sistemas de la organización aporta una seguridad (en el vertiente de la confidencialidad) que ningún sistema puede todavía igualar, y Google no es una excepción. El hilo de la argumentación es el opuesto: si no confiamos en Google a pesar de sus indudables esfuerzos e inversiones en seguridad, ¿deberíamos confiar en un proveedor, un cliente, o un empleado que va a tratar nuestros datos por el mero hecho de la firma de un compromiso o contrato de confidencialidad? La respuesta es obvia: no. Dejando de lado aquellos casos en los que ni siquiera existe tal firma, aunque legalmente un documento de este tipo supone una garantía, en muchos casos detectar y probar una filtración o robo de información es más bien complejo y costoso, por no decir casi imposible, excepto en casos muy obvios, en los que el volumen de información es significativo y es utilizado de manera muy obvia fuera de la organización.

Por tanto, concluyendo, creo que queda claro que la seguridad de un proveedor, cliente o empleado no puede limitarse a un mero documento firmado (tampoco hemos descubierto nada nuevo aquí). El caso es: dejando aparte la cuestión o garantía legal, ¿de qué sirve un compromiso de confidencialidad? ¿Es algo más que un apretón de manos, un “puedes confiar en mi”, una declaración de intenciones, una formalidad que viene a representar una sensación: la confianza?

Se lo dejo como reflexión para estos dos días. Pasen como siempre un buen fin de semana.

(Algunos) Beneficios de la implantación de un SGSI

En los últimos posts sobre SGSIs [1][2], planteábamos los problemas a los que los consultores nos solemos enfrentar a la hora de implantar un Sistema de Gestión de Seguridad de la Información y los errores más comunes que se suelen cometer.

Lejos de pretender mostrar una visión negativa de la decisión de implantar un SGSI, intentábamos advertir de cosas a tener en cuenta a lo largo del proceso. Es indudable que una vez el SGSI está implantado y en funcionamiento, éste aporta innumerables ventajas a la organización en general y al departamento TI en particular. Mucho se ha escrito sobre las ventajas de implantar un SGSI; como con el resto de Sistemas de Gestión, siempre se insiste en que el hecho de obtener un certificado hace que la organización aumente su competitividad, mejore su imagen respecto a las empresas de la competencia y se posicione mejor en el mercado. Todo eso es cierto, y está claro que esa puede ser una razón de peso para algunas organizaciones, ya que al fin y al cabo aumentar el nicho de mercado o fortalecer la posición y la imagen es algo imprescindible desde el punto de vista del negocio, y sin negocio, de nada sirven los sistemas de gestión y los certificados.

No obstante, dejando de lado el tema del certificado, desde nuestro punto de vista, el de una empresa especializada en Seguridad de la Información, existen otras muchas ventajas en la implantación de un Sistema de Gestión de Seguridad de la Información que son de otro ámbito. Entre otras, podríamos señalar como principales las siguientes:

  • La gran mayoría de las tareas que obliga a ejecutar un SGSI (auditoria técnica de la plataforma TI, sistema de detección de intrusos, análisis de vulnerabilidades, inventario de activos, control de accesos, etc.) son aspectos que cualquier departamento TI que se precie debe abordar. La diferencia en este caso es que una vez implantado el SGSI estas tareas —y muchas otras— se encuentran sistematizadas, tienen asignado un responsable de ejecución y en muchos casos otro para la revisión, se analiza el resultado que de su ejecución se desprende, y se toman medidas en función de éste.

    Dicho de otra forma, la mayoría del trabajo es el mismo que se realizaría —o debería realizarse— sin tener un SGSI, pero el SGSI formaliza las tareas y garantiza que se ejecuten cuándo y de la forma que se haya considerado adecuada y por ello establecido.

  • El Análisis de Riesgos es quizá uno de los aspectos que un departamento TI no aborda de forma sistemática si no ha implantado o se encuentra implantando un SGSI. No es necesario listar las ventajas que supone realizar y revisar de forma periódica un Análisis de Riesgos; basta con decir que nos permite conocer las amenazas a las que están expuestas nuestros activos —entre los que se encuentra la información—, la probabilidad de que éstas se materialicen y el impacto que dicha materialización tendría sobre nuestro negocio. Dicho de otro modo, nos permite conocer la situación en la que nos encontramos y a través del Plan de tratamiento de Riesgos (un requisito de la norma) planificar cómo llevar este riesgo a un nivel que consideremos aceptable y que estemos dispuestos a asumir.
  • La continuidad del negocio, contemplada de manera específica en uno de los dominios de la norma, obliga a la organización a plantear, aunque se a un nivel muy general, cómo garantizar la continuidad del negocio en caso de una catástrofe. Aunque es cierto que la elaboración, implantación y mantenimiento de un plan de continuidad de negocio es un proyecto en sí mismo, de (casi) tanta entidad como la implantación de un SGSI, para abordar la certificación se debe haber realizado y probado al menos un plan de contingencia, que sin llegar a ser un plan de continuidad de negocio, sí que constituye un primer paso.
  • El dominio correspondiente a Conformidad es otra de esas tareas que en la mayoría de las organizaciones queda fuera del alcance de las responsabilidades del departamento TI, y en la que interviene tanto jurídico como posiblemente recursos humanos. Este dominio obliga a identificar la legislación que nos aplica tanto a nivel de propiedad intelectual como de protección de datos de carácter personal, y no son pocas las empresas que pretenden implantar y certificar un SGSI sin cumplir las exigencias de la LOPD y su Reglamento de Desarrollo. La implantación de un SGSI obliga como mínimo a disminuir la probabilidad de incumplir algún requisito legal que puede acarrear sanciones o dañar la imagen corporativa, ya que hoy en día las entidades de certificación —o por lo menos aquellas con las que nosotros hemos trabajado— consideran una No Conformidad mayor cualquier incumplimiento legal y obligan a la empresa que aspira a obtener el certificado a un plazo de tres meses regularizar su situación. Lo que parece totalmente lógico, ¿no les parece?
  • Comentábamos en un post anterior que un problema con el que hay que lidiar al implantar un SGSI es involucrar a áreas como Recursos Humanos, Departamento Legal, Administración, Comercial, etc., en un proyecto liderado por el Departamento TIC, que ven como ajeno a ellos y una carga de trabajo extra. La implantación de un SGSI requiere superar este escollo, lo que conlleva muchas ventajas: la seguridad ha dejado de ser cosa del Departamento TI y gracias a la formación y concienciación toda la organización es consciente del valor que tiene la información corporativa que maneja diariamente. Sin olvidar la existencia de normativas que deben cumplir para garantizar la seguridad de dicha información y cuyo incumplimiento tiene definido en la mayoría de los casos un proceso sancionador.

    Por último, pero no por ello menos importante, el apoyo que la Dirección debe demostrar al proyecto de implantación del SGSI, hace que los empleados entiendan que el tema de la seguridad de la información no se trata de un ‘capricho’ del Director del área TI, sino de una directriz marchada por la alta Dirección y que es por tanto un aspecto vital de la organización.

  • Durante la fase de implantación de un SGSI se definen las directrices para detectar y actuar ante un incidente de seguridad, lo que evita que llegado el momento de enfrentarse a un incidente grave se tenga que pensar por dónde empezar, quién debe encargarse de qué, a quién hay que informar en primer lugar, y aspectos de ese estilo.
  • Por último, la mejora continua es una ventaja común a todos los Sistemas de Gestión, sobre la que hay cientos de artículos escritos pero no por ello queremos dejar de mencionarla. Gracias al ciclo PDCA garantizamos que existe un proceso continuo que comprueba cómo de segura está nuestra información y actuamos para conseguir que el nivel de seguridad aumente. Este trabajo no se termina nunca: medir y actuar para mejorar. Siempre hay algún aspecto de la seguridad de la información que se puede mejorar.

Aunque estas son algunas de las ventajas, es indudable que existen muchas otras. En próximas entradas pasaremos a ver cuáles son las ventajas de la integración de sistemas de gestión, o la conveniencia y ventajas que aporta contar con un sistema de gestión de eventos y alarmas a la hora de implantar un SGSI.

Un USB lleno de fotos

(La entrada de hoy es la cuarta colaboración de Francisco Benet , un amigo de algunos de nosotros —y familia de algún otro— que tiene gran experiencia en la gestión e integración de sistemas, protección de datos de carácter personal y evaluación de soluciones de integración de software y hardware, entre otros aspectos. Esperamos que les guste.)

Continuamente con el rabillo del ojo miraba hacia ambos lados, pero ya no quedaba casi nadie en la oficina. Tampoco le interesaba quedarse solo; había que aparecer y desaparecer, como en un día normal, como en una situación normal. Al fin y al cabo era un día ‘normal’ para todos… excepto para Ramón.

[Read more…]