31 octubre 2006

Empresas y código penal

Habitualmente, al hablar de legislación aplicable en el entorno empresarial nuestro pensamiento se suele centrar en leyes "tecnológicas" como la LOPD, la LSSI o la LPI. Sin embargo, en muchas ocasiones nos olvidamos de que las empresas también están sujetas a la ordenación jurídica "común", es decir, las leyes de aplicación general.

En relación a este tema, la web ISO27000.es publica, entre las presentaciones de la jornada "Nuevos escenarios en Seguridad de la Información", que tuvo lugar en Valencia el día 27 de Septiembre de 2006, una presentación de Manuel Badenes, de Equipo Marzo, que expone las implicaciones que tiene el Código Penal en el ámbito de la empresa, y sus relaciones con las leyes anteriormente citadas. Una presentación realmente interesante, que nos recuerda que el incumplimiento de ciertas normativas y políticas internas no sólo puede llevar acarreadas acciones disciplinarias , sino que, si estas normas reflejan determinadas directrices legales, dicho imcumplimiento puede llegar a acarrear penas de prisión. Mejor tenerlo en cuenta, verdad?

30 octubre 2006

Cumpliendo con la LOPD

En un post anterior, un visitante exponía sus dudas acerca de las dificultades reales a la hora de cumplir con los requisitos del Reglamento de la LOPD. Esta reflexión me ha llevado a analizar un poco más a fondo lo que suponen las distintas exigencias de la LOPD y el reglamento, y los motivos más habituales de su incumplimiento.

Las obligaciones de la Ley (parte administrativa) son sencillas de cumplir para las empresas. Identificar los ficheros, definir su nivel y propiedades, desarrollar las fórmulas legales (garantizar derechos de acceso, rectificación, cancelación y oposición) y dar de alta los ficheros no es una tarea compleja. Sin embargo, la realidad nos dice que todavía hay empresas que no cumplen este apartado, sobre todo entre las PYMEs y microPYMEs, y la principal razón aducida suele ser el desconocimiento. Pese a todo, esto no supone un problema para el común de los usuarios, ya que en su mayoría también desconocen los citados derechos, y por lo tanto no suelen pretender hacer uso de ellos. Ni siquiera el ejercicio del deber de información (por cierto, uno de los apartados en los que más suspensos suelen tener las empresas) suele tener efectos, ya que los usuarios no suelen leer la "letra pequeña".

Las obligaciones técnicas impuestas por el Reglamento suponen un problema distinto. En este caso, se impone la adopción de determinadas medidas técnicas que, en muchos casos, obligan a la adquisición y uso de ciertas tecnologías que permitan control de accesos, logging, backup, etc. Aquí las empresas con presupuesto ajustado se llevan la peor parte, ya que muchas aducen que su presupuesto es incapaz de afrontar la compra de estas herramientas y/o la contratación de servicios técnicos para su integración. Por un lado, la compra de las licencias software necesarias no suele ser una prioridad, y en ciertos entornos con datos hasta ahora de nivel alto la adquisición de herramientas que cumplan con el control de acceso y logging a nivel de registro suele ser prohibitiva. Por otra parte, son todavía muchos los ámbitos en los que la informática se ve como un "bicho raro", y la filosofía de "mejor no tocar" suele ser común. Por lo tanto, en muchas empresas que cuentan con la tecnología base para implementar las citadas medidas técnicas, estas no se despliegan por desconocimiento o dejadez.

Y precisamente la dejadez es uno de los motivos por los que no se desarrollan las medidas operativas a las que obliga el reglamento. El mantenimiento de listas de usuario, la realización y comprobación de backups o el registro de entradas y salidas son tareas que exigen cierta dedicación. Sin embargo, son muchos los casos en los que no se da a estas tareas la prioridad necesaria, o en los que el responsable del fichero ni siquiera define a los encargados de realizarlas. En definitiva, estas tareas acaban por no realizarse con la frecuencia necesaria, y en algunos casos terminan por dejar de hacerse. Cuando el negocio y la productividad es lo fundamental, en algunos entornos se descuidan otras obligaciones. Sobre todo, si los recursos humanos son escasos, están sobre-explotados o sus responsabilidades están insuficientemente definidas.

Como comentaba este visitante, es dificil que las empresas que no cumplen adecuadamente con los requisitos de la LOPD garanticen la continuidad de su negocio. En este tipo de entornos, en muchos casos el día a día es suficiente preocupación. Y, sin embargo, toda empresa, independientemente de su dimensión, está obligada a cumplir con las exigencias legales aplicables, y por tanto con la LOPD. Es más: en un entorno cada día más interactivo e interconectado, aspectos como la seguridad de la información van a ir cobrando cada día más relevancia. ¿Cómo conciliar estos dos aspectos?

Esta última pregunta, desde mi punto de vista, subyace en la redacción del nuevo reglamento. Al menos, en el apartado de reducir el nivel de ciertos ficheros "comunes", con el fin de reducir las exigencias mínimas para las empresas "corrientes". Creo que este nuevo reglamento reduce estos mínimos y facilita la adopción de medidas, en muchos casos no-técnicas, para el común de las empresas. Sin embargo, creo que este nuevo borrador de reglamento también intensifica, en los ficheros de mayor nivel, los controles a implementar, con la particularidad de que tras la redefinición de niveles estas medidas son aplicables en entornos que habitualmente tienen mayor capacidad técnica y económica, a priori. De este modo, empresas pequeñas como talleres de reparación, bares o comercios verán relajadas sus exigencias, mientras que aseguradoras, banca o empresas del ámbito sanitario deberán cumplir con mayores exigencias, acordes al mayor nivel de los datos manejados y al mayor potencial económico para su cumplimiento. En definitiva, se trata de adecuar las medidas tanto a los datos manejados como a la capacidad de las empresas, para que todos podamos salir beneficiados.

Agradecimientos

Este post lo quiero dedicar únicamente a dar las gracias a todas las personas que han referenciado este blog, y que han contribuido a que tenga mucha más difusión de la que yo me esperaba. Son, como mínimo, los siguientes:
  • Sergio Hernando, a través de este post en su blog.
  • Jose Manuel Fernández, en este post.
  • Segu-Info.com.ar, en sus citas.

Seguro que me dejo a muchas personas (pido disculpas). A todos ellos, muchas gracias por los elogios, y espero no defraudaros. Intentaré que los post sigan teniendo la misma calidad que les habeis concedido a los publicados hasta el momento.

Y por último, gracias a todos los que leeis habitualmente el blog. Es una verdadera satisfacción ver que hay más personas a las que interesan estas reflexiones. Y que sepais que trataré de dar respuesta a todas las inquietudes que planteeis a través del blog.

Muchas gracias a todos.

Un saludo,

Joseba.

27 octubre 2006

Outsourcing de servicios de seguridad

No sé si por casualidad o porque en estos últimos tiempos se está poniendo de moda, el caso es que últimamente han caído entre mis manos varios artículos sobre outsourcing de seguridad. En general, el mensaje de todos ellos venía a ser similar:
El outsourcing de servicios de seguridad es positivo siempre y
cuando el prestador de servicios sea de garantía, se externalicen únicamente
aquellos servicios en los que el expertise externo suponga un verdadero
valor añadido y en todo caso se mantenga el adecuado control sobre los
servicios externalizados.

Realmente, la conclusión no aporta demasiado, puesto que las tres condiciones parecen evidentes y de sentido común. Pesea a ello, creo que es una conclusión interesante ya que define, a grandes rasgos, las líneas de trabajo a seguir por una organización que quiera externalizar servicios (nótese que no me limito exclusivamente a los servicios de seguridad):
  • Selección de prestadores de servicios de garantía: Definamos los requisitos a exigir a los prestadores, y verifiquemos las referencias. Si no tenemos claros los requisitos, las certificaciones pueden ser de gran ayuda (por ejemplo, exigir una certificación en seguridad tipo ISO 27001 a un prestador de servicios de seguridad parece una buena idea).
  • Definición de los servicios a externalizar: Este es quizás el punto clave, y por su extensión requeriría un post específico. Aquí me limito a señalar que, para empezar a externalizar, lo hagamos por aquellos servicios en los que claramente la subcontratación sea beneficiosa económicamente (subcontratar salga más barato que desarrollar con personal interno la misma tarea con el mismo nivel de servicio), y no suponga el acceso a know-how de negocio ni información confidencial. Si hay dudas, mejor empezar por otros servicios.
  • Control sobre los servicios externalizados: Tenemos que definir tanto los requisitos a controlar (SLAs, indicadores de nivel de servicio, cláusulas específicas, auditoría) como la metodología de control y supervisión, y que figure claramente en el contrato. No olvidemos que subcontratamos la operación, no la responsabilidad.

Como una primera aproximación, creo que estas ideas pueden servir para identificar los primeros pasos a seguir en la externalización de servicios. Si son ciertos los pronósticos de que el futuro va en esa dirección, tratemos de estar preparados para cuando se convierta en necesidad...

25 octubre 2006

Desarrollando Métricas

El objetivo de este post es ampliar un poco mi comentario en relación al post de Antonio Valle sobre métricas en su blog.

Como bien dice el citado post, las métricas están de moda. Sin embargo, a la hora de la verdad es difícil encontrar a alguien que tenga claro qué medir y cómo medirlo. Ni siquiera los propios estándares se ponen de acuerdo entre ellos, y hay diversos modelos de métricas. Esta pretende ser una breve guía sobre un modelo flexible y sencillo (espero), que creo que puede ser efectivo:
  1. En primer lugar, tenemos que identificar los procesos cubiertos y, sobre todo, qué hace cada uno (para una mayor aclaración sobre procesos, os recomiendo este post, de Jose Manuel Fernández).
  2. Una vez que tengamos claro el funcionamiento de cada proceso, tenemos que identificar aquellas situaciones en las que el proceso funciona bien. ¿Por qué decimos que funciona bien? Qué variable estamos identificando como correcta? Aquí tenemos los primeros candidatos a métricas.
  3. Cuando ya tenemos las primeras variables identificadas, tenemos que analizarlas. Ver sus interrelaciones, el significado de cada una, su composición y los parámetros que evalúa. ¿Cuáles son los que más nos interesan? ¿Cuáles reflejan de forma clara el principal objetivo del proceso? Tendremos que seleccionar los más adecuados, y ya tendremos las métricas operativas, de cada proceso.
  4. A continuación, pensemos en los procesos trabajando de forma conjunta para ofrecer servicios. Si cada proceso viene parametrizado por sus métricas, con los servicios va a suceder algo similar. El proceso a seguir es parecido, aunque con un elemento adicional a tener en cuenta. Van a aparecer métricas compuestas, derivadas de la interrelación de las anteriores, y otras propias del servicio, como entidad de nivel superior.
  5. Siguiendo el citado proceso de identificación y selección, llegaremos a escoger las métricas tácticas, que parametrizarán los servicios. Estas métricas serán más generales, estarán más cerca del nivel de negocio que las anteriores. Y si los servicios están estandarizados, algo necesario para el benchmarking, las métricas también lo estarán. Por tanto, aquí ya podemos hacer uso de estándares y guías que nos ayuden en esta identificación.
  6. Por último, y si queremos disponer de un juego de métricas completo, tendremos que desarrollar (o integrar) las métricas estratégicas. En este punto no sólo tendremos que identificar los parámetros de nuestros servicios, sino identificarlos y relacionarlos con parámetros de negocio como el rendimiento económico o la productividad. De nuevo, a este nivel nos ayudan los estándares, así como todo el conjunto de indicadores de negocio que, en mayor o menor medida, todas las organizaciones tienen desarrollado.

Por último, sólo señalar que esta es una aproximación botton-up, que parte de la ausencia de métricas para desarrollar el juego completo, de abajo hacia arriba. Sin embargo, en muchas organizaciones ya se cuenta, como he señalado, con indicadores estratégicos, y por lo tanto se puede tratar de usar una aproximación top-down. Para estos casos, mi consejo es que se siga una metodología compuesta, y que sea en el nivel táctico de parametrización de servicios donde se integren ambas aproximaciones. De este modo, será más sencillo identificar los indicadores de negocio con indicadores tácticos, y a partir de ahí encajar las métricas desarrolladas a nivel de proceso. Aunque esto sólo es un consejo...

Saludos

20 octubre 2006

Control Interno y Auditoría

En muchas ocasiones me encuentro con empresas que no tienen muy clara la diferencia entre control interno y auditoría. El objetivo de este post es, sencillamente, tratar de diferenciar ambos conceptos.

El control interno (siendo estrictos, las actividades de control interno) lo constituyen tareas y funciones inherentes a la propia actividad de la organización, y son aquellas actividades del día a día que tratan de verificar que los procesos se realizan según lo establecido. Son tareas distribuidas, que desarrollan desde los directivos hasta los técnicos y operarios. Hay actividades de control tan sencillas y acotadas como verificar que todas las piezas fabricadas están dentro del umbral permitido, y otras que pueden ser tan difusas como comprobar el grado de aprovechamiento de las acciones formativas. Ligado al control interno deberían aparecer los indicadores (tanto estratégicos como tácticos y operativos), como parámetros a evaluar dentro de esas actividades de control interno.

Por otro lado tenemos la auditoría. A diferencia de lo anterior, las auditorías son acciones puntuales y ajenas a los elementos auditados, cuyo objetivo es tratar de identificar el grado de cumplimiento de determinadas normativas y objetivos asociados. Las auditorías son análisis puntuales, cuyo objetivo es primordialmente emitir un diagnóstico objetivo y neutral sobre el estado del elemento auditado.

La confusión entre ambos conceptos nace de que ambas actividades están encaminadas a la evaluación del elemento controlado o auditado. Sin embargo, la diferencia es que las auditorías buscan más el análisis de estado y la consiguiente identificación de fortalezas y debilidades, mientras que el control interno se centra más en la identificación de tendencias. Además, las primeras son acciones puntuales, mientras que las segundas son continuas.

Está claro que existen muchas más connotaciones que habría que analizar a la hora de dar una definición y diferenciación completa entre ambos conceptos, pero espero que estas breves nociones sirvan para identificar más fácilmente las diferencias entre ambas. Al menos, para saber qué podemos exigir cuando tengamos que sentarnos frente a un auditor y pedirle que analice nuestra organización...

19 octubre 2006

Responsabilidad estatal en materia de seguridad (II)

Hoy recupero el tema de un post anterior, una vez que ha surgido algún que otro comentario al respecto. Como esperaba, es un tema que despierta controversia, aunque en este caso creo que no está correctamente interpretado.

La responsabilidad estatal, al menos desde mi punto de vista (creo que el autor del artículo se puede aproximar a él, pero prefiero no posicionarle y que lo haga él mismo si es que tiene conocimiento de este post y lo considera oportuno), pasa por establecer unas condiciones mínimas de funcionamiento. De hecho, no es algo nuevo, ya que estas condiciones mínimas son, sencillamente, las leyes (junto con el resto de ordenación y regulación, evidentemente). Si lo traducimos a términos relacionados con la seguridad de la información, y usamos un ejemplo tan conocido como puede ser la LOPD, creo que es sencillo de entender. Las leyes (en este caso, la propia Ley Orgánica de Protección de Datos) serían las políticas de seguridad, a las que entiendo que se refiere el artículo. Y el procedimiento correspondiente, que regula cómo se debe aplicar la política, no sería otro que el Reglamento de Medidas de Seguridad.

En este caso, el papel del estado pasa por definir cuáles son las medidas mínimas que se deben respetar en relación al tratamiento de datos personales, sobre todo en materia de confidencialidad. Pero si nos centramos en otra de las dimensiones de la seguridad, la disponibilidad, creo que podemos ver claramente las repercusiones que en este ámbito tienen ciertas infraestructuras críticas como pueden ser las líneas de comunicaciones o las de transporte de electricidad.

Desde mi punto de vista, el estado debe garantizar unas mínimas políticas de seguridad a sus clientes, los ciudadanos. A partir de ahí, serán las empresas y los propios usuarios los que decidan si prestan o exigen mejores condiciones. Pero si no se definen unos mínimos exigibles... ¿Cómo se puede garantizar que se alcanza el nivel de servicio necesario? En aspectos como la seguridad de la información, dejar todas estas condiciones en manos exclusivas del mercado (con los vicios inherentes que conlleva) creo que es demasiado arriesgado. Volviendo al ejemplo de la LOPD, me parece correcto que el estado, dentro de su responsabilidad en materia de seguridad, defina unos requisitos mínimos tanto a nivel de políticas como de procedimientos, que tanto empresas como administraciones deban cumplir. Y el propio mercado ya provocará que algunas de ellas mejoren esas condiciones y decidan incluso llegar a implantar un SGSI para mejorar dicha seguridad. Pero, mientras tanto, el tratamiento de los datos personales de los ciudadanos será mínimamente seguro.

17 octubre 2006

Definiendo el alcance del SGSI

Uno de los pasos más importantes a la hora de implementar un SGSI es definir adecuadamente el alcance. ¿Qué ámbito debe cubrir? Suele ser un tema complicado de decidir, principalmente porque un alcance global, que cubra toda la organización, no suele ser ni la opción más eficiente ni la más eficaz. Tenemos que pensar que la implantación de un SGSI es un proyecto de gran calado, con repercusiones transversales a todo el alcance que definamos, y cuyas raíces deberían llegar hasta la cultura de la organización. Por tanto, la mejor opción siempre será diseñar un SGSI para un alcance más reducido, optimizando recursos y resultados, que más adelante ya ampliaremos, cuando la filosofía de gestión de la seguridad haya calado y los controles implementados se puedan extender progresivamente.

Por tanto, una vez que hemos decidido que el alcance sea parcial... ¿Qué procesos, divisiones o departamentos debe cubrir? Se trata de identificar aquella parte de la organización en la que la seguridad puede aportar un mayor valor añadido. Pero... ¿Qué filosofía podemos seguir para identificar ese valor añadido? Aquí cito algunas de ellas:
  • Aumentar el valor de un servicio "seguro": Esta filosofía supone implementar un SGSI para potenciar un servicio que ya incorpora funciones de seguridad, en el que un SGSI va a aportar beneficios directos. Es una opción evidente, con el inconveniente es que sólo es aplicable para aquellos servicios en los que la seguridad es un valor intrínseco al mismo.
  • Potenciar un servicio final: Esta opción supone la implantación de un SGSI ligado a los servicios y/o procesos de negocio. De esta forma, se da un valor añadido a los mismos, bañándolos de una capa de seguridad adicional. Es una filosofía muy válida en aquellos entornos en los que se quiera sacar provecho de una certificación, ya que la seguridad repercute directamente en los clientes.
  • Reforzar los servicios y procesos internos: Esta filosofía pretende implantar el SGSI para fortalecer determinados servicios y procesos internos, en los que una mejora en la seguridad pueda suponer una ventaja para la organización. En general, se suele traducir en la implementación del SGSI en el área de IT, por ser uno de los principales responsables del tratamiento y conservación de la información de la compañía, o en áreas en las que se maneja información de especial relevancia, como podrían ser las áreas de I+D+i (prototipos, diseños, etc), recursos humanos (datos de caracter personal) o financiero (datos económicos).
  • Potenciar la gestión interna: Por último, otra de las filosofías que a veces se utiliza para decidir el alcance es identificar aquellas partes de la organización en las que la implantación del SGSI, como sistema de gestión, sirva para potenciar y estructurar la gestión interna. Es quizás una de las filosofías más discutibles, ya que existen multitud de sistemas de gestión centrados en distintos aspectos y quizás el de la seguridad pueda no ser el más indicado en todos los casos, pero en determinadas situaciones puede ser una opción.

Seguro que a todos se nos pueden ocurrir más filosofías para decidir la implantación de un SGSI en una u otra parte de la organización, pero desde mi punto de vista estas son las principales. Ahora, es suficiente con identificar cuál encaja mejor con nuestra organización, y utilizarla para identificar el mejor ámbito para implantar nuestro SGSI. Suerte en el intento...

11 octubre 2006

Responsabilidad estatal en materia de seguridad de las infraestructuras críticas

Hoy he estado releyendo un artículo de editorial de la revista Auditoría+Seguridad. En él, Ricardo Cañizares hace referencia, en un solo párrafo, a un tema de tanta trascendencia como es la responsabilidad estatal en materia de seguridad. El director de la revista afirma lo siguiente:

El estado debe asumir la responsabilidad de garantizar la seguridad de las Infraestructuras Críticas, legislando, implantando políticas y procedimientos, y coordinando los esfuerzos de todas las organizaciones involucradas en el despliegue y gestión de las Infraestructuras Críticas.

Este breve comentario es suficiente como para abrir un interesante debate. ¿En qué medida el estado debe intervenir de cara al aseguramiento de las infraestructuras críticas? ¿Cuál es el grado de responsabilidad estatal, frente al que corresponde a las organizaciones que despliegan dichas infraestructuras? ¿Qué grado de regulación es aceptable? Son muchas las preguntas que surgen alrededor de un tema escabroso, en el que se entremezclan intereses de muy diversa índole, como los económicos, los políticos o incluso los geo-estratégicos. Porque... ¿No es precisamente este uno de los principales argumentos que se esgrimieron durante la polémica surgida en torno a la famosa OPA de E.On? ¿Hasta qué punto es sincero el interés de los estados en proteger las infraestructuras críticas? Son temas delicados...

Como no quiero condicionar ninguna postura, prefiero deternerme aquí e invitar a todos los lectores a que dejen aquí su opinión. Seguro que todas sirven para enriquecer la propia ...

09 octubre 2006

Comentarios al nuevo reglamento para la LOPD

Hace unos días, un compañero de trabajo me hizo llegar un artículo muy interesante titulado "Posibles implicaciones para el directivo TIC del nuevo reglamento sobre la protección de datos", de Raúl Rubio. Es una explicación muy clara de las principales consecuencias que conllevaría el borrador del nuevo reglamento para la protección de datos, en caso de aprobarse.

Entre las aclaraciones más importantes del nuevo reglamento, podemos destacar las siguientes:
  • Se rebaja el nivel de muchos ficheros: Los ficheros de caracter general de las empresas (nóminas, por ejemplo) pasarán a ser de nivel bajo, aunque contengan datos económicos, de afiliación sindical o de salud, siempre y cuando la finalidad de esos ficheros no sea el tratamiento expreso de dichos datos.
  • Para los trabajadores externos que trabajen en nuestras dependencias se exige la firma de cláusulas de confidencialidad o documentos similares, y deberá indicarse en el documento de seguridad.
  • Todos los trabajadores externos con acceso a los ficheros pero cuyo trabajo no suponga el tratamiento de los datos (limpieza, mantenimiento, hosting, etc) deberán firmar cláusulas de prohibición de acceso a los datos y de obligación de mantener el derecho de secreto, en caso de que deban acceder a ellos. Por su parte, el responsable deberá limitar, en la medida de lo posible, el acceso de estas personas a los datos.
  • Los medios removibles que por su naturaleza no puedan ser etiquetados y clasificados (por ejemplo, Pen Drives) están exentos de cumplir dicha obligación.

Desafortunadamente, aparecen nuevas exigencias, entre las que se destacan las siguientes:

  • Se exige que, para TODOS los archivos, se definan no sólo los usuarios con acceso sino los perfiles y niveles de acceso de cada uno de ellos.
  • TODOS los usuarios deben tener identificadores unívocos y personalizados, independientemente del nivel del archivo al que tengan acceso.
  • Será necesario probar los backups con una frecuencia máxima de 6 meses, independientemente del nivel del archivo respaldado.
  • Los ficheros de nivel MEDIO y ALTO tendrán la obligación de registrar los accesos hasta el grado de identificar el registro accedido y el resultado del intento de acceso, a no ser que sólo el propietario del fichero tenga acceso a él.
  • Las auditorías, obligatorias para ficheros de nivel MEDIO y ALTO, deberán ser notificadas a la AEPD.

Por otra parte, el nuevo reglamento establece las exigencias para los ficheros no automatizados (papel). Las principales son las siguientes:

  • Inventariar y controlar el acceso en las mismas condiciones que con los ficheros automatizados.
  • Destruir o borrar cualquier documento o soporte que vaya a ser eliminado.
  • Registrar las entradas y salidas de documentos que contengan datos de nivel MEDIO y ALTO.
  • Almacenar los ficheros de nivel MEDIO y ALTO en lugares ignífugos y con acceso restringido o vigilado.
  • Procedimentar la realización de copias y reproducción de los documentos de nivel MEDIO y ALTO.
  • Para los ficheros de nivel ALTO, también habrá que registrar los accesos a los documentos (durante 2 años como mínimo) y protegerlos mediante llaves o medidas equivalentes.

Como se puede ver, el borrador del nuevo reglamento introduce importantes exigencias, algunas de las cuales van a suponer esfuerzos realmente importantes por las empresas, que deben cumplirlo. ¿Cuantas de estas exigencias sobrevivirán a la publicación final del reglamento? ¿Cuántas se eliminarán? ¿Cuál será el periodo de moratoria para su cumplimiento? En un futuro próximo (o quizás no tanto), lo veremos.

05 octubre 2006

Incumplimientos de la LOPD

Hoy hay varios blogs que hacen eco del informe sobre sentencias de la AEPD que publica firma-e.com en su web. De él se pueden destacar varios aspectos, como son:
  • El incumplimiento más común, y el que mayores sanciones ha supuesto, es el relativo a la calidad de los datos, sobre todo por contener datos inexactos.
  • El siguiente incumplimiento más habitual es el relativo al consentimiento del afectado, por no poder demostrarse un consentimiento inequívoco. En lo relativo a sanciones, se sitúa en tercer lugar.
  • El segundo incumplimiento que más sanciones ha supuesto es el relativo a cesiones no consentidas. Se debe a que, por la gravedad del incumplimiento, las sanciones son más elevadas, ya que este incumplimiento sólo motiva el 6% de las sentencias.
  • Finalmente, el tercer incumplimiento más habitual en las sanciones de la AEPD es el deber de secreto, con un 11% de los casos.

No tenemos que olvidar que estos resultados son los referidos a sanciones impuestas por la AEPD, es decir, a incumplimientos investigados por la AEPD. Sin embargo, si presuponemos que estas empresas sancionadas supone una muestra homogénea del parque empresarial nacional, podríamos extender estas conclusiones a incumplimientos generales en las empresas.

Por último, sólo añadir que estos resultados demuestran, sobre todo en el caso de las cesiones no consentidas, que la gravedad del incumplimiento va a determinar la importancia de la sanción. Como no podía ser de otra forma, existen medidas de seguridad más importantes que otras. Y lo fundamental es saber identificarlas, y reforzar las verdaderamente necesarias.

02 octubre 2006

Indicadores y metricas de seguridad

La web ISO27000.es publicó ayer un artículo muy interesante sobre métricas de seguridad. En resumidas cuentas, plantea los conceptos de "madurez" y "calidad de la seguridad" como parámetros principales para la definición de indicadores y métricas. En concreto, los pasos que se deben seguir para implantar un conjunto de métricas de acuerdo a dicho artículo se resume en:
  1. Identificar los elementos a medir a partir del índice de la ISO 17799
  2. Definir los niveles de madurez para cada uno de los elementos medidos
  3. Definir los niveles de calidad para cada uno de los niveles de madurez de cada elemento

De esta forma, tendremos una pareja de valores que, por cada elemento medido, nos informarán del grado de evolución del control y de la calidad con la que lo hemos implementado. Unos valores que, en conjunto, nos pueden dar una imagen REAL del nivel de seguridad de la organización. Métricas que se convierten en indicadores de seguridad. Muy sencillo de entender... aunque me temo que no tan fácil de implantar. Así que lo mejor en estos casos es, como se suele decir, menos hablar y más trabajar. Manos a la obra, y ya veremos cuál es el resultado...