LOPD & ACREDITACIÓN SOFTWARE

Con objeto de cumplir debidamente con lo establecido en la Disposición Adicional Única del Real Decreto 1720/2007 he optado por solicitar a los distintos proveedores de software un documento a modo de acreditación del nivel de (in)seguridad que sus respectivos productos alcanzan. Como era de esperar esta información no aparece en la documentación que poseemos.
Disposición adicional única. Productos de software.
Los productos de software destinados al tratamiento automatizado de datos personales deberán incluir en su descripción técnica el nivel de seguridad, básico, medio o alto, que permitan alcanzar de acuerdo con lo establecido en el título VIII de este reglamento.

Tras más de un año de vigencia del mencionado RD, y sin que NINGÚN proveedor se haya tomado la molestia de suministrarnos formalmente esta acreditación, hemos decidido tomar la iniciativa. Bajo mi particular criterio considero que el cumplimiento de esta cláusula es competencia absoluta del desarrollador, pero por lo visto la cosa parece que no va con ellos .......

Con objeto de facilitarles aún más el trabajo he hecho una especie de "trasposición" de las medidas de seguridad del RD en clave de desarrollo de software. Los criterios (acumulativos) por los que se debe regir la acreditación del software dependiendo del nivel de seguridad que le corresponde son:
NIVEL BÁSICO
  • Resulta obvio pero debe disponer de mecanismos de control de acceso (por algo será ...... yo me he encontrado con más de uno, de dos, de tres, .............)
  • Relación actualizada de usuarios y accesos autorizados (repositorio propio o integrado en uno externo, por ejemplo eledap)
  • Distintos privilegios de acceso según funciones/perfiles de usuario (dependiendo de la complejidad del producto)
  • Mecanismos que eviten el acceso datos o recursos con derechos distintos de los autorizados (obvio no?)
  • Identificación y autenticación personalizada (entre otras cosas no permitir sesiones simultáneas desde distintos equipos)
  • Características básicas de las contraseñas (repetición, secuencias, combinar caracteres numéricos/alfanuméricos, etc..)
  • Sistema de almacenamiento ininteligible de las contraseñas
  • Mecanismos de caducidad de las contraseñas
  • Posibilidad de bloqueo de los datos (no eliminación física)

NIVEL MEDIO

  • Control de accesos fallidos (bloqueo de cuenta tras superar el límite establecido)
NIVEL ALTO
  • Log de accesos reflejando usuario, hora, registro accedido, tipo de acceso, autorizado o denegado
  • Conservación de los logs durante 2 años
  • Si el software en cuestión efectúa directamente la transmisión de datos por redes de telecomunicación, ésta debe ser de forma cifrada
Hay bastantes puntos más como por ejemplo las copias de seguridad, usuarios genéricos, etc. pero según mi particular criterio corresponden al ámbito general o global de la LOPD (política de seguridad) y no son directamente dependientes del producto de software como tal. Esta lista hace referencia a las medidas mínimas que todo software de tratamiento de datos de carácter personal, para entendernos el típico software de alta/baja/modificación, debe cumplir.
Obviamente no pretende ser un conjunto de requerimientos para todo tipo de software, para eso ya están los common criteria y sus EAL1, EAL2, ..... El objetivo es que sea una relación de las características mínimas que cualquier producto de software debería poseer para poder tratar datos de carácter personal de acuerdo a lo especificado en el RD.
CITA DEL DÍA: "Durante un análisis de riesgos no hay lugar para el optimismo"

LOGS Y RENDIMIENTO: ¿LEYENDA URBANA?

Desde hace muchos años siempre que los frikis del área de sistemas escuchan la frase "activación de los logs de auditoría" entramos en una situación bastante cercana al inicio de la 3ª Guerra Mundial. Lo habitual es que entren en un estado de cólera incontrolada llevándose las manos a la cabeza a la vez que vociferan ¡sacrilegio! ¡a la hoguera con él! pasando por un incontable número de recuerdos dirigidos a los diversos familiares del descerebrado que ha osado pronunciar, o simplemente pensar, semejante aberración.
Dejando de lado el espacio en disco necesario para guardar toda esa avalancha de datos siempre se antepone el grave impacto que supondrá, nótese que no digo supone, en el rendimiento. Para ser sincero, por suerte o por desgracia, en la práctica he estado alejado del área técnica más profunda (sistemas y comunicaciones), por lo que no soy nadie para afirmar si sus argumentos son fundados, demostrables y válidos. Lo que si puedo aportar es que en las muchas discusiones, como cliente, como auditor, etc. que he vivido con relación a este tema nunca se ha aportado información contrastable que permita adoptar una decisión razonada al respecto.
Que el rendimiento se verá afectado está claro que si, hasta ahí llegamos todos y todas, en esencia mi planteamiento de fondo es saber cuanto afecta. ¿Hay valores, cálculos, porcentajes, etc. concretos? Por más que he buscado información al respecto no he encontrado gran cosa. Siempre se da por supuesto que afecta pero nunca he visto reflejada la dimensión real de esa penalización. Particularmente creo que se trata de la típica respuesta automática o subconsciente, del tipo "leyenda urbana" (todo el mundo lo sabe pero nadie lo ha visto), que se va arrastrando generación tras generación. Este planteamiento es el que no me parece sensato en cuanto que en esta vida todo es relativo y siempre existe un punto de equilibrio.
Para salir de dudas he propuesto formalmente que se activen las directivas de auditoría (guindous 2003 server) para tener unos poquitos de datos empíricos. Obviamente empezaremos registrando poca cosa e iremos incrementando progresivamente. Ya os contaré.
CITA DEL DÍA: "La seguridad no tiene fin"

CRÓNICA II CONFERENCIA INTERNACIONAL BS25999

Esta mañana he tenido el placer de asistir a la II Conferencia Internacional de Continuidad de Negocio organizada por The British Standards Institution (BSI). Desde aquí agradezco públicamente a BSI la invitación gratuita al evento.
En esta ocasión no se ha cumplido aquel dicho de "segundas partes no fueron buenas ...", la verdad es que particularmente esta segunda jornada me ha gustado más que la primera edición. No sé exactamente el motivo, quizás los contenidos tratados............ Aquí podéis ver la agenda del evento.
En la actualidad estoy metido de lleno en el desarrollo de un PCN (área TIC por el momento) para los hospitales y la verdad es que han habido un par de cosas que me han llamado la atención.
Como no todo va a ser bueno ;-), desde mi más particular opinión y afán constructivo, quisiera expresar públicamente algunos aspectos ni buenos ni malos, sino todo lo contrario, para que sean considerados en, tan esperadas desde ya, próximas ediciones:
Pasar un poco por alto la teoría de la norma. Creo que el público en general la conoce suficientemente bien. Me hubiera gustado ver aplicaciones prácticas concretas y detalladas (la de Bankinter ha sido la que ha profundizado más aunque ........). Tampoco es necesario la exposición de organizaciones que se hayan certificado en la BS25999 o BS25777.
Herramientas, la verdad es que en una de las ponencias esperaba ver algún demo o alguna captura de algún producto. Remarcar que al oír Strohl Systems me ha venido a la memoria que por casa tengo un CD de BIA Professional. Lo he encontrado pero iluso de mi .... se trata de una versión un "poco" anticuada (para Windows 3.1/95), como pasa el tiempo .......
Nada más, espero ansioso la convocatoria del año próximo. Mis más sinceras felicitaciones a BSI y a los ponentes. Con uno de ellos me he reído mucho al plantear si el Chelsea tenía PCN que cubriera una disrupción en el minuto 92 ...... :-)
CITA DEL DÍA: "La seguridad no lo es todo, es lo ÚNICO"

AUDITORIA LOPD BIENAL INTERNA

Este año nos toca la auditoría bienal que establece la LOPD. Dada la situación de regularización actual nos estamos planteando la posibilidad de realizarla internamente. Como podéis apreciar me niego a llamarla "crisis", recesión, etc..., para mi no es más que una etapa necesaria y obligada para que se normalice la indecencia en la que estábamos inmersos. Desgraciadamente los que lo van a pagar en todos los sentidos somos los de siempre. En el presente ejercicio tenemos unas restricciones presupuestarias y un control del gasto abrumador, todo ello impuesto por el ministerio, que implican por ejemplo la imposibilidad de imputar ni un triste euro en determinadas rúbricas contables.
Al grano, internamente tenemos claro que la auditoría que hagamos será totalmente meticulosa y rigurosa. Desde el punto de vista legal no hay mayor problema ya que la LOPD contempla esta posibilidad. Con relación a este punto ya sabéis que "cualquiera" puede hacer auditorías de cumplimento de la LOPD por tanto, y muy a mi pesar, este punto es absolutamente irrelevante mientras no se regule semejante agujero negro. Por otro lado, periódicamente y desde hace ya tiempo, llevamos realizando auditorías por toda la red asistencial por lo que algo sabemos del tema. Aunque no es determinante ni representativo de nada soy CISA desde hace más de 10 años por lo que de algo debe servir ..... Señalar que en todas las auditorías externas que nos han realizado anteriormente no ha participado nadie con este perfil. A bote pronto es lo más parecido a un auditor LOPD (al menos en lo referente a las medidas de seguridad).
En el fondo nos inquieta la percepción o valoración que se pueda tener desde el exterior. Os cuento, en anteriores situaciones nos han requerido la presentación del informe de auditoría más reciente, y de modo expreso, se hacia referencia a que éste fuese de un entidad externa. En su momento ya comenté que por pedir que no quede pero si la LOPD dice blanco pues será blanco, por tanto, la auditoría interna es tan legitima como la externa. Otra cosa es que, de forma equivocada o no, se les da mayor o menor valor.
Como breve resumen intentaré detallar bajo mi criterio los pros y contras que supone llevar a cabo la auditoría LOPD internamente:
Pros
- mayor conocimiento del "negocio", en ocasiones la auditoría externa implica un curso formativo acelerado del auditor externo
- mayor transparencia/sinceridad de la parte auditada
- mayor nivel de autocrítica interna
- mayor dedicación en las carencias o puntos de mejora (perfectamente identificados)
- menor coste económico
- constitución de un equipo auditor multidisciplinar (a priori SS.II., RRHH, área sanitaria y área jurídica)
Contras
- dudas, por parte de terceros, acerca de su objetividad
- externamente poco valorada, quisiera remarcar que el "problema" lo tienen quienes opinan así no nosotros
- riesgo de ver un único árbol en lugar del bosque entero
- los componentes del equipo auditor deben hacer un esfuerzo por cambiar de rol
En esta otra entrada hablamos un poco más del tema. En definitiva, como lo veis ?? que nos dejamos ??
CITA DEL DÍA: "La elección final es aquella que implica menos inseguridad"

Las botnets en la Shmoocon

Del 6 al 8 de Febrero se celebró en Washington la Shmoocon 2009, cita obligada para estar al día en seguridad.

Como siempre, me guardé las presentaciones para pegarles un vistazo, pero por la carga que últimamente tenemos de trabajo me ha sido imposible hasta este "fin de semana largo".

Como no, representando a España estuvieron Chema Alonso (MVP Microsoft) y Palako (Yahoo), hablando de su tema estrella, BLIND SQL.

Entre el repertorio de presentaciones, que podéis encontrar aquí, me gustaría destacar la de Julia Wolf, acerca del spam y las botnets, especialmente relevante este mes, que se ha descubierto la mayor botnet bajo MAC.

Como yo no os lo voy a explicar mejor que de lo que está en las diapositivas, os animo a verlas.

CITA DEL DIA : "No llores como usuario lo que no has podido defender como administrador"