Esa cosa llamada “Governance”

Para empezar la semana, hoy tenemos una entrada de uno de nuestros colaboradores habituales, Francisco Benet, sobre ingeniería social governance. Esperamos que les guste.

Hoy me gustaría hablarles de una palabra que todo el mundo tiene últimamente en la boca: el governance. Y es que ésta es una de esas palabras que gustan… como que hace tilín. Desde Marketing hasta los más altos CEO’s, CTO’s, CIO’s, y otros tantos, hablan del governance aquí, allí, hoy y mañana. En estos últimos años he oído la palabra governance en todos los foros donde creía que podía salir y en otros tantos en que nunca me lo hubiera imaginado, y es que es pegadiza y suena bien, y de paso le da a uno esa imagen de cosmopolita que tanto gusta.

¿Que es el governance? Partamos de la base que el governance no es nada si no hay algo que gobernar. Partiendo de esta premisa, podemos aplicar governance a todo, y de hecho se aplica por defecto (ya sea bien o mal, eso es otra historia) a todas las facetas —voy a restringir el campo— de la informática empresarial (sí, empresarial): desde la metodología de desarrollo hasta la seguridad de los puestos de trabajo. Y es que el governance (yo lo entiendo así) es el ‘como se hacen las cosas’, y por eso hay que definirlo bien, ya que sino las cosas se nos irán de madre. ¿Y qué tiene esto que ver con la seguridad? ¿Qué hace el governance compartiendo espacio en este foro a veces técnico, a veces legal pero siempre interesante? Pues señores, el governance y la seguridad deben ir ligados como si fueran parte de la fórmula de la Coca-cola. Pero, ¿por qué la Coca-cola? Pues porque nadie conoce realmente como se fabrica (bueno, espero que alguien sí lo sepa), y porque el governance no es una metodología, no es tangible, no es medible (bueno, existen aproximaciones), pero es necesario conjugarlo bien en todos los puntos para que no nos salga gaseosa marrón.

El governance y la seguridad comienzan desde el momento que se define que es neceasario ‘gobernar’ la situación para que esto no se vaya de madre. Por ejemplo, en desarrollos de arquitecturas SOA (software) se habla de que la seguridad debe estar desde el nacimiento y esto es parte del governance —y mira que se habla de governance cuando alguien menciona SOA… En la gestion de CPD’s (no estoy muy ducho en este tema, francamente) podríamos hablar que el governance debe velar porque los aspectos de seguridad se tengan en cuenta, en la integración de los sistemas (no en un proyecto de integración sino en el uso de ESB, EAI o simples hubs made-in-house) el governance debe velar entre otras cosas por que las interfaces sigan estándares y la integración, monitorización, control y deploy sea correcto (disponibilidad de servicios aparte de su desarrollo, finalmente algo de seguridad), en infraestructura de redes podríamos hablar de tener en cuenta la alta disponibilidad de hardware, el caudal de datos, los procedimientos operativos…

En fin, el governance es una pieza fundamental de cómo hacer las cosas, de qué cosas hacer y de quién debe hacerlas. Para mí es como ver una pirámide a vista de pájaro. Es la única manera de ver realmente todas las caras, incluso la no visible, y de esa forma entender de forma clara la estructura. Es por eso que las pirámides deben verse desde el cielo, pero construirse desde la base. Así que si alguno de ustedes pretende cogerle el gusto al governance, no comiencen por alzar la vista mirando al techo (N.d.E. cosa que, se lo digo yo, no sirve de nada más que para acabar mal de las cervicales), evalúen las situaciones desde los mandos intermedios (generalmente mas operativos), definan los objetivos (con ellos) y aprovechen su conocimiento para llevar a cabo las acciones procedimentales/técnicas/organizativas que deben asegurar que se esta gobernando la situación.

Subiendo la temperatura en el datacenter y ¿descontrolando la humedad? (I)

Para hoy martes tenemos una entrada de Rafa García, amigo y antiguo colaborador de S2 Grupo que ya ha participado en el blog en alguna ocasión.

Rafa ha dedicado los últimos años de su carrera profesional a la gestión de datacenters, campo en el que posee extensos conocimientos (como demuestra la presente entrada), y es actualmente Director de NIXVAL, un proveedor de servicios de externalización de centros de datos para alojamiento de sistemas de misión crítica, parte del grupo CLEOP. Esperemos que la entrada les guste tanto como a nosotros.

Recientemente, trabajando en una ampliación bastante importante de nuestro centro de datos he podido constatar ya de forma generalizada que el mercado propone parámetros de diseño de salas técnicas con temperatura ambiente de 25º C y control de humedad de humedad relativa al 80%. Este post va de porqué, cómo y hasta dónde pueden realizarse estos cambios en una sala técnica existente —en este caso una de un centro de datos real— ya que con estos nuevos parámetros de diseño los centros de datos han dejado de ser como los conocíamos hasta la fecha.

El aumento de la temperatura de la entrada en aire a los servidores de 21º hasta 25º es un cambio que está operativo desde hace aproximadamente 1 año en una de las salas de nuestro centro de datos, que alberga aproximadamente 130 kW de sistemas. ¿Porqué este aumento? Para ahorrar energía, claro. ¿Y no causa problemas en los sistemas? No. Los equipos actuales soportan temperaturas operativas de hasta 35º garantizadas por el fabricante. Como muestra los parámetros operativos del equipo DELL Poweredge R210, uno de los mas baratos (369 €) y populares servidores:

Temperature: Operating: 10° to 35°C with a maximum temperature gradation of 10°C per hour. Relative Humidity: Operating: 20% to 80% (non-condensing) with a maximum humidity gradation of 10% per hour

[Read more…]

La norma ISO 28000 y los jamones “pata negra”

Dado que el anterior post del blog tenía como protagonistas gráficos a un par de cerdos, voy a utilizarlos como nexo de unión para lo que quería comentarles (ya saben que me gusta encontrar situaciones -a veces curiosas- que nos permiten ver la necesidad de gestionar la seguridad en múltiples actividades cotidianas).

La norma ISO 28000 como ya hemos visto en posts anteriores introduce la gestión de la seguridad en la cadena logística o de suministro, y basa el sistema de gestión a implantar fundamentalmente en el análisis de riesgos, revisando las amenazas que pueden afectar a:

  • El personal.
  • La información que da soporte a los procesos de negocio.
  • Los bienes o mercancías.
  • El medio o los medios de transporte utilizados.
  • Las unidades de carga.

Pues bien, voy a comentarles los tres casos que he visto en la prensa digital de hoy.

[Read more…]

Cuando un cerdo no es suficiente, monta una granja (III)

Terminamos con éste la serie de artículos sobre la implantación de un IDS en un entorno con una alta tasa de tráfico, donde veremos las soluciones que se han tomado para el problema de los paquetes descartados y la escritura en base de datos.

Según dejamos el tema en el artículo anterior, el problema parece residir en que Snort, hasta que no termina de escribir la alerta en la base de datos, no procesa el siguiente paquete. La escritura en base de datos se realiza mediante una conexión TCP que precisa del handshake y de la escritura del INSERT en la misma; es por esto que constituye un proceso muy lento. Para solucionarlo, vamos a tomar cuatro pequeñas medidas que reducirán considerablemente el tiempo que necesita Snort en generar una alerta:

Escritura en disco local de la alerta y uso del formato unified2. La escritura en local es mucho más rápida que la escritura en red y si utilizamos un formato binario que ocupa muy poco espacio, se tardará mucho menos tiempo en generar la alerta. El formato binario unified2 es una evolución del formato unified introducido en Snort v.2.8. Se trata de un formato extensible formado por una cabecera que define el tipo de registro y su longitud, y que permite guardar en un mismo fichero diversos tipos de eventos como, por ejemplo, alertas IPv6, estadísticas o información de escaneos.

[Read more…]

La importancia de transmitir el conocimiento

A estas alturas empieza a ser difícil encontrarse con una organización que no quiera invertir tiempo y esfuerzo en la seguridad. Aunque queda camino por recorrer, poco a poco la madurez en la seguridad está evolucionando desde el “si no falla ni nos han entrado, no pasa nada” al “debemos controlar el riesgo“, de modo que ha habido una migración en los últimos años en cuanto al foco de la seguridad. Ésta ya no se centra sólo en la disponibilidad de los servicios, sino también en la integridad de los mismos; las diferentes normativas que se han elaborado en estos años, como la LOPD o el Esquema Nacional de Seguridad ha ayudado mucho a que la seguridad esté cada vez mas presente en todas las organizaciones. Conceptos como “correlación”, “IPS”, “consola de gestión” o “monitorización” son cada día más conocidos y ya no suenan a jerga especializada.

Sin embargo, a pesar de esta mejora la seguridad sigue siendo vista no como un aspecto que debe envolver todos los demás, según una perspectiva holística, sino como otro elemento más en nuestra infraestructura de red (el firewall, un router, la VPN) o como una auditoría que nos revela fallos que solventamos. Es decir, como un elemento o acción puntual y aislada que nos permite incrementar nuestra seguridad o a veces tan sólo la percepción de seguridad. Existen varios efectos colaterales de esta manera “compartimentada” de abordar la seguridad, que les indico a continuación:

  • Los beneficios del proyecto no se trasladan de manera efectiva a la organización, sino que se limitan a aquel departamento que ha promovido la iniciativa. No resulta nada raro que una organización decida abordar una auditoría 27002 pero el resultado efectivo sea la mejora de aquella parte de la seguridad de la que el departamento promotor es responsable, generalmente IT, por una simple cuestión de autoridad y competencias.
  • Las implantaciones de nuevos sistemas, productos o elementos se quedan “cojas”, introduciendo incluso nuevos problemas de seguridad; un concentrador VPN es mucho más que un elemento de red que nos permite acceder remotamente a la organización: requiere procedimientos de alta y baja de usuarios, revisión periódica de usuarios, actualizaciones, políticas de utilización acceso remoto (y teletrabajo si es una de sus funciones), etc.
  • El propio enfoque de la seguridad, unido a que se trata en muchos casos de iniciativas o proyectos “departamentales” e incluso en ocasiones casi personales, hace que no sea nada raro que el conocimiento y la experiencia que se deriva de estas iniciativas quede “atrapado” en el personal implicado en el proyecto. De este modo, no se incorporan al know-how de la organización, y se limita su utilización en posteriores iniciativas.

Aunque los tres efectos indicados son igualmente perniciosos, me gustaría incidir un poco más en el último. Si las lecciones aprendidas quedan dentro de las “cabezas pensantes” del personal de comunicaciones, el personal de sistemas, o tan sólo el responsable de IT, y no se traducen en documentos y acciones formales o incluso informales, no se tarda mucho en convertirse en departamentos reactivos, incapaces de responder de forma coordinada y sobre todo, anticipada y preventiva. Por utilizar una expresión que seguro que muchos conocen, el resultado es que nos limitamos a apagar fuegos. Claro que más de uno pensará: ¿Cómo demonios me voy a poner a pensar en detectores de humo cuando tengo una habitación llena de fuego? Pues haciendo que los cambios en la manera de trabajar se introduzcan de forma gradual, poco a poco. Es fantasioso pretender que elaborar procedimientos, documentación o introducir algo de necesaria burocracia en el día a día no vaya a afectar a nuestra manera de trabajar, tanto en la carga de trabajo que implica su elaboración e implantación, como en el rechazo que mostramos ante cualquier cambio de rutina, aunque su consecuencia sea positivo.

La cuestión, al final, radica en garantizar que el aprendizaje diario permanezca en la organización y no en la cabeza de esta o aquella persona, ya sea a través de procedimientos formales o informales, que permitan cumplir con la legalidad, retener el conocimiento, y que deben ser aplicables en el día a día de la organización. Esto en ocasiones puede entrar en conflicto con una mala concepción de la “imprescindibilidad” que algunas personas tienen, pero sólo de esta manera seremos capaces de transmitir el conocimiento de las personas a la organización, evitando caer en pequeñas parcelas de conocimiento y de poder, que sólo obstaculizan el normal funcionamiento de la empresa.

(Entrada elaborada en colaboración con Manuel Benet)

Introducción a SystemTap

Al hilo de una antigua entrada de nuestro compañero Antonio Villalón acerca de Dtrace y Solaris, me propuse encontrar algo parecido para sistemas Linux. Dtrace te permitia recolectar información del sistema a muy bajo nivel para detectar anomalías en su funcionamiento y en algunos casos poder prevenir futuros problemas.

Tras un tiempo de búsqueda, y después de descartar varias opciones que no me parecían todo lo completas que deberían, me encontré con SystemTap, una maravillosa herramienta que nos permite monitorizar la actividad del kernel mediante scripts sin tener que compilar y reiniciar cada vez que se requiera ejecutar una prueba.

Es crítico para un administrador de sistemas tener un control total sobre que ocurre en el sistema y herramientas como SystemTap, que te permiten obtener datos precisos del funcionamiento del sistema son de gran ayuda. También aporta seguridad el hecho de poder tener controlado cualquier evento del sistema, ya no a nivel de aplicación, sino de kernel. Conocer qué procesos están abriendo cierto fichero, el consumo de red de cualquier proceso o la ejecución de X función dentro del kernel por Y proceso nos proporciona una ingente cantidad de información que puede resultar necesaria en caso de una detectar una intrusión.

Por el propósito que tiene, SystemTap no es sencillo. Aunque la base es fácil de comprender, su programación requiere conocimientos avanzados de los diferentes módulos del kernel de Linux, aparte de conocimientos de su propia sintaxis. Por suerte para nosotros, existe abundante documentación, y para facilitarnos la tarea y reducir la barrera de entrada existen ya multitud de scripts de ejemplo que nos permitirán ver su funcionamiento e imaginar las posibilidades que tiene SytemTap.

Su instalación es bastante sencilla. En una distribución Fedora basta con instarlo mediante Yum y luego usar un comando propio para que descargue e instale el paquete kernel-debug correspondiente a nuestra versión actual del kernel:

#yum install systemtap
#stap-prep

Como breve introducción, en SystemTap tenemos “events” y “handlers”. La construcción habitual en SystamTap suele ser la siguiente

#codigo#
probe event {statements}

En lo que respecta a los “events” existen dos tipos, síncronos y asíncronos. Un evento síncrono ocurre cuando cualquier proceso ejecuta una operación en el kernel. Como ejemplos de este tipo de eventos tenemos:

  • Entradas a syscalls.
  • Operaciones en el VFS (Virtual File System).
  • Entradas en funciones del kernel, por ejemplo “sys_open”.
  • Entradas en funciones de cierto modulo.
  • etc.

Los eventos asíncronos, por contra, son aquellos que no están ligados a ninguna instrucción particular en el código. Consisten principalmente en contadores y temporizadores.

Los “handlers” es la parte del código llamada cuando ocurre un “event”. Este código, una mezcla entre C y AWK, nos permite tratar la información del evento, almacenarla y en general, utilizar cualquier función disponible en cualquier lenguaje moderno (salida por pantalla, uso de vectores, funciones,…). Vamos a ver un ejemplo básico de “probe”, el cual almacenaremos en un fichero denominado probe.stp, y ejecutaremos con la orden stap probe.stp

####código####
probe syscall.open
{
printf ("%s(%d) open\n", execname(), pid())
}

En este ejemplo, cuando se realice cualquier llamada a la función open() el script escribirá por pantalla el nombre y el PID del proceso que ha ejecutado la llamada.

A partir de aquí, el asunto se puede complicar todo lo que queramos. Se pueden declarar funciones para factorizar el código, variables globales para compartir información entre handlers, timers, etc., y como con cualquier lenguaje nuevo hay que aprender la sintaxis. Por si esto no fuera suficiente, hay que conocer los eventos que podemos registrar en el kernel. Lo más recomendable para no desanimarnos es comenzar probando los scripts de prueba, ver como trabajan, y adaptarlos a nuestras necesidades, leyendo la documentación correspondiente en cada caso. En el wiki del proyecto encontrareis abundante información, y en Fedora, además, podemos instalar el paquete systemtap-testsuite el cual nos copiará en /usr/share/systemtap/testsuite/systemtap.examples/ multitud de ejemplos.

Por último, me gustaría compartir un script que me gustó mucho (está en el paquete de testsuite que hemos mencionado) y que nos permite conocer el consumo de red de cada proceso del sistema en tiempo real. Os invito a que lo reviséis, veáis como se programa un script un poco complejo y las posibilidades de la herramienta. El script tan sólo almacena en cada llamada a las funciones transmit y receive la información en vectores para luego, en función de un timer, mostrarla por pantalla. Aquí esta:

#! /usr/bin/env stap 
global ifxmit, ifrecv 
global ifmerged 

probe netdev.transmit 
{ 
  ifxmit[pid(), dev_name, execname(), uid()] < << length 
}

probe netdev.receive 
{ 
  ifrecv[pid(), dev_name, execname(), uid()] <<< length 
} 

function print_activity() 
{ 
  printf("%5s %5s %-7s %7s %7s %7s %7s %-15s\n", 
          "PID", "UID", "DEV", "XMIT_PK", "RECV_PK", 
          "XMIT_KB", "RECV_KB", "COMMAND") 

  foreach ([pid, dev, exec, uid] in ifrecv) { 
    ifmerged[pid, dev, exec, uid] += @count(ifrecv[pid,dev,exec,uid]); 
  } 

  foreach ([pid, dev, exec, uid] in ifxmit) { 
    ifmerged[pid, dev, exec, uid] += @count(ifxmit[pid,dev,exec,uid]); 
  } 

  foreach ([pid, dev, exec, uid] in ifmerged-) { 
     n_xmit = @count(ifxmit[pid, dev, exec, uid]) 
     n_recv = @count(ifrecv[pid, dev, exec, uid]) 
     printf("%5d %5d %-7s %7d %7d %7d %7d %-15s\n", 
            pid, uid, dev, n_xmit, n_recv, 
            n_xmit ? @sum(ifxmit[pid, dev, exec, uid])/1024 : 0, 
            n_recv ? @sum(ifrecv[pid, dev, exec, uid])/1024 : 0, 
            exec) 
  } 

  print("\n") 

  delete ifxmit 
  delete ifrecv 
  delete ifmerged 
} 

probe timer.ms(5000), end, error 
{ 
  print_activity() 
}

¿El fin de los secretos?

Ahora que ha pasado un cierto tiempo desde el escándalo de la publicación de los diarios secretos de la guerra de Iraq y la reacción del gobierno de USA, que no desmintió la información, me gustaría compartir algunas reflexiones sobre el fenómeno WikiLeaks, su relación con la privacidad de datos y la corriente dentro de la que creo que se encuadra este caso.

No voy a entrar en la legalidad difusa de sus actuaciones, la falta de transparencia (casi inevitable) del origen de los fondos con que se mantiene o la contradictoria personalidad de su líder visible, Julian Assange, puesto que mi punto de vista es que WikiLeaks es la manifestación actual de una tendencia que no tiene vuelta atrás fácil (y creo que ni difícil).

A medida que la participación en la red se populariza, cada vez hay más personas introduciendo más información acerca de sus vidas y sus intereses, públicos o privados, en bases de datos gestionadas en la nube, cuya garantía de confidencialidad y privacidad es muy dudosa. Por poner un ejemplo, la más popular de las redes sociales, Facebook, tiene unas condiciones de uso que podrían constituir la pesadilla (o el sueño) de cualquier abogado. Por supuesto, esto no supone ningún problema para ninguno de nosotros, porque no nos las leemos… :-)

La mayor parte de la información que compartimos es básicamente irrelevante, sólo interesa a unos pocos amigos o familiares cercanos y, de hecho, consciente o inconscientemente, confiamos en que al resto del mundo no le importa en absoluto lo que digamos o las fotos que subamos. En gran medida, esto es cierto: es como aquello de que el mejor sitio para esconder un libro es una biblioteca. Entre tanta información, ¿quién va a encontrar nada nuestro si no lo está buscando explícitamente?

Sin embargo, lo que se sube a Internet ya nunca se borra. O, como decían en “la red social” (the movie), “Internet no está escrito con lápiz, Mark. Está escrito con tinta”. Y, en algún momento, alguien hará una búsqueda y aquello de lo que ya ni nos acordábamos, saldrá de nuevo a la luz. ¿Quién es capaz de mantener o explicar todo lo que ha dicho en algún momento de su vida?

Nos encaminamos hacia una sociedad en la que los secretos van a ser más difíciles de mantener o, dicho de otra forma, en la que nos tendremos que acostumbrar a una mayor transparencia en nuestras actuaciones.

Y lo que es aplicable a la vida social, es aplicable a las empresas, los gobiernos y las instituciones. No por la creciente responsabilidad de los gobernantes ni de la maquinaria del estado, sino por la evolución tecnológica, que es mucho más confiable.

Hace 100 años, si alguien quería mantener una conversación totalmente confidencial, podía, simplemente, alejarse del resto y hablar en voz baja, o tener cuidado de no dejar nada por escrito. De hecho, hace poco leí que la principal dificultad de los historiadores para entender la forma de gobernar en el imperio de Felipe II es que el rey no solía dejar por escrito sus órdenes, que se transmitían verbalmente. Hoy en día, no se puede estar seguro de que algo se vaya a mantener en secreto. Todo se registra de varias maneras diferentes, legales o no. Y ya no es posible guardar el registro bajo siete llaves. Las filtraciones, si hay algún interés en ello, son inevitables a la larga.

Por supuesto, el camino no será fácil ni directo. Seguro que veremos corrupciones en WikiLeaks o similares, corrupciones reales o montajes realizados para desprestigiar. Seguro que habrá filtraciones falsas que superen los mecanismos de comprobación establecidos (ya ocurre en los medios tradicionales).

En mi opinión, la tendencia es imparable. Sinceramente, creo que para bien.

Incumplimiento del deber de secreto

Hace unos días leí una noticia que me llamo la atención; por lo visto, algún trabajador de Google había filtrado a la prensa un comunicado interno (el cual indicaba expresamente que era confidencial) donde se informaba sobre un aumento del 10% del sueldo a todo la plantilla de Google y la recepción de una paga extra de 1000 $ (yo pensé mira que majos :) ). Un día más tarde al hilo de esta noticia aparecía una nueva, en la cual se informaba acerca del despido de la persona que había filtrado la información, que ya no podría disfrutar de ese aumento de sueldo.

Esto me hizo reflexionar en que a menudo los empleados firman acuerdos de confidencialidad o NDA (Non-disclosure Agreements), ya sea por la LOPD, por SGSI, por política propia de empresa o por exigencias de un proveedor o cliente, sin que la mayoría sean conscientes de las consecuencias personales que puede tener la violación de dichos acuerdos de confidencialidad; simplemente firman porque hay que firmar. No obstante, existen unas obligaciones en cuanto a la confidencialidad inherentes a cualquier relación contractual.

En esta entrada trataremos las referencias legales, más allá de las implicaciones dentro del marco de la LOPD, con respecto al incumplimiento del deber de secreto.

En este sentido podemos identificar los siguientes hechos:

El Estatuto de los trabajadores. El artículo 5, “Deberes laborales“, en su punto a) propone para los trabajadores:

Cumplir con las obligaciones concretas de su puesto de trabajo, de conformidad a las reglas de la buena fe y diligencia.

Lo cual implícitamente implica cierta obligación del trabajador para con la empresa en lo que respecta al deber de secreto. No obstante, esto no se considera suficiente como para eximir del desarrollo de un acuerdo de confidencialidad que especifique detalladamente las obligaciones del empleado en cuanto a confidencialidad.

La Ley de Competencia Desleal, en su artículo 13, propone:

1. Se considera desleal la divulgación o explotación, sin autorización de su titular, de secretos industriales o de cualquier otra especie de secretos empresariales a los que se haya tenido acceso legítimamente, pero con deber de reserva, o ilegítimamente, a consecuencia de alguna de las conductas previstas en el apartado siguiente o en el artículo 14.

2. Tendrán asimismo la consideración de desleal la adquisición de secretos por medio de espionaje o procedimiento análogo.

3. La persecución de las violaciones de secretos contempladas en los apartados anteriores no precisa de la concurrencia de los requisitos establecidos en el artículo 2. No obstante, será preciso que la violación haya sido efectuada con ánimo de obtener provecho, propio o de un tercero, o de perjudicar al titular del secreto.

En el Código Penal, son de aplicación tanto el artículo 197 como el 199, si bien el 199 en este contexto es más aplicable:

Artículo 199

1. El que revelare secretos ajenos, de los que tenga conocimiento por razón de su oficio o sus relaciones laborales, será castigado con la pena de prisión de uno a tres años y multa de seis a doce meses.

2. El profesional que, con incumplimiento de su obligación de sigilo o reserva, divulgue los secretos de otra persona, será castigado con la pena de prisión de uno a cuatro años, multa de doce a veinticuatro meses e inhabilitación especial para dicha profesión por tiempo de dos a seis años.

Artículo 197

1. El que, para descubrir los secretos o vulnerar la intimidad de otro, sin su consentimiento, se apodere de sus papeles, cartas, mensajes de correo electrónico o cualesquiera otros documentos o efectos personales o intercepte sus telecomunicaciones o utilice artificios técnicos de escucha, transmisión, grabación o reproducción del sonido o de la imagen, o de cualquier otra señal de comunicación, será castigado con las penas de prisión de uno a cuatro años y multa de doce a veinticuatro meses.

2. Las mismas penas se impondrán al que, sin estar autorizado, se apodere, utilice o modifique, en perjuicio de tercero, datos reservados de carácter personal o familiar de otro que se hallen registrados en ficheros o soportes informáticos, electrónicos o telemáticos, o en cualquier otro tipo de archivo o registro público o privado. Iguales penas se impondrán a quien, sin estar autorizado, acceda por cualquier medio a los mismos y a quien los altere o utilice en perjuicio del titular de los datos o de un tercero.

3. Se impondrá la pena de prisión de dos a cinco años si se difunden, revelan o ceden a terceros los datos o hechos descubiertos o las imágenes captadas a que se refieren los números anteriores.
Será castigado con las penas de prisión de uno a tres años y multa de doce a veinticuatro meses, el que, con conocimiento de su origen ilícito y sin haber tomado parte en su descubrimiento, realizare la conducta descrita en el párrafo anterior.

4. Si los hechos descritos en los apartados 1 y 2 de este artículo se realizan por las personas encargadas o responsables de los ficheros, soportes informáticos, electrónicos o telemáticos, archivos o registros, se impondrá la pena de prisión de tres a cinco años, y si se difunden, ceden o revelan los datos reservados, se impondrá la pena en su mitad superior.

5. Igualmente, cuando los hechos descritos en los apartados anteriores afecten a datos de carácter personal que revelen la ideología, religión, creencias, salud, origen racial o vida sexual, o la víctima fuere un menor de edad o un incapaz, se impondrán las penas previstas en su mitad superior.

6. Si los hechos se realizan con fines lucrativos, se impondrán las penas respectivamente previstas en los apartados 1 al 4 de este artículo en su mitad superior. Si además afectan a datos de los mencionados en el apartado 5, la pena a imponer será la de prisión de cuatro a siete años.

Como reflexión final, de todo esto podemos deducir que el incumplimiento del deber de secreto o de un acuerdo de confidencialidad tiene un carácter penal, pudiendo suponer al individuo en cuestión desde un despido procedente pasando por una reclamación en forma de indemnización hasta penas en prisión.

(Imagen de casey.marshall en Flickr)

Chrome Web Store

La guerra de navegadores entre Chrome (Google), Firefox (Mozilla), Safari (Apple) e Internet Explorer (Microsoft) es una más de las múltiples guerras tecnológicas que vamos viendo pasar estos días, a saber: sistemas operativos, móviles, tablets, plataformas de videojuegos, video bajo demanda por Internet, y un largo etcétera. Al final todas están o acabarán estando relacionadas, y un claro ejemplo es la guerra de navegadores y sistemas operativos. En ese sentido, Google ha lanzado Chrome Web Store, mirando en primer lugar a la promoción de su navegador Chrome, pero poniendo un ojo en el futuro con su Chrome OS.

Y bien, ¿qué es eso de Chrome Web Store? Pues es una plataforma accesible al público general que permite publicar aplicaciones por parte de desarrolladores de software. Actualmente se encuentra en fase de recolección de las primeras aplicaciones enviadas por éstos (developer preview), pero se prevé que antes que finalice el año se produzca el lanzamiento. El resultado será algo similar a las tiendas virtuales de venta de aplicaciones móviles, como AppStore de Apple, Android Market de Google o Blackberry AppWorld, pero orientado a aplicaciones web. Esto daría respuesta a la sensación actual de una mayor facilidad para encontrar aplicaciones para el móvil que para el propio ordenador personal, ofreciendo las mismas ventajas de los mercados de aplicaciones móviles, como la búsqueda por categorías o un top ten de las aplicaciones más reclamadas.

Con todo esto, cualquier desarrollador registrado podrá publicar tres clases de elementos: aplicaciones, temas y extensiones. De esta forma, los elementos adquiridos aparecerán en la pantalla de inicio de Google Chrome. Sin embargo, una de las primeras preguntas que nos surgen y que ya ha manifestado CNET indica que no ve la diferencia entre visitar un sitio web y tener una aplicación que redirecciona al mismo lugar. Probablemente, la respuesta se encuentra más allá de las típicas aplicaciones web, más bien deberíamos decir aplicaciones instalables vía web y ejecutables en el entorno de navegadores, quizá en HTML5 o Flash para sacarle el máximo provecho, o de aplicaciones “descargables” similares a Java WebStart. De momento, ya se han presentado aplicaciones interesantes como la de Sports Illustrated o juegos como el de Lego Star Wars. La idea parece llevar a un buscador de aplicaciones de calidad (y por tanto, en algunos casos, de pago) para diferentes propósitos, siempre con el marco de fondo del nuevo sistema operativo Chrome OS, que pretenden promocionar de esta forma. Sin embargo, por el momento parece que no limitan la utilización de estas aplicaciones a su navegador, indicando que podrán ejecutarse en cualquier navegador de última generación. Eso sí, el buscador y la página de inicio de Chrome ofrecerán un valor añadido respecto al resto de navegadores.

Sin embargo, en cuanto a las connotaciones que podría implicar en cuanto a la seguridad, no parece haber mucha información al respecto, y es necesaria, ya que en primer lugar los usuarios deberán tener una garantía en cuanto a confidencialidad, integridad y seguridad en sus sistemas, por lo que será necesaria información sobre los sistemas de verificación utilizados por Chrome Web Store, especialmente a la hora de aceptar una aplicación para formar parte del conjunto de aplicaciones ofertadas.

En cuanto a la realización del pago de las aplicaciones, parece que el tema es más claro, ya que se indica que permitirá dos opciones: un sistema de pago propietario (Chrome Web Store Payments) o uno de los sistemas de pago ampliamente utilizados (como PayPal, por ejemplo). Recientemente, se ha hablado de un posible pago de una tasa de 5 dólares para los desarrolladores que quieran comercializar aplicaciones, según Google, como método de comprobación de la autenticidad de una aplicación o extensión, para evitar un posible spam de aplicaciones. En cuanto al porcentaje de ventas que se quedaría Google, las últimas comunicaciones hablan de un 5% del total de ventas de cada aplicación. En pocos meses veremos cuál es el grado de aceptación de las aplicaciones ofertadas, así como las posibles repercusiones.

La “seriedad” de las auditorías del RDLOPD

Hace unas semanas aparecía en prensa la noticia de que el Ministerio de Economía y Hacienda había sancionado por falta grave a Gassó, la auditora que se encargó de supervisar las cuentas de la constructora Astroc en 2006, cuando salió a bolsa, al haber aprobado las mismas sin poner ninguna salvedad, cuando posteriormente PwC detectó irregularidades. Esto supuso una multa de aproximadamente 200.000 € para la auditora, y de 8.000 € para el auditor que firmó el trabajo.

No me cabe ninguna duda de que una auditoría del Reglamento de la LOPD tiene en general una relevancia menor que una auditoría financiera, por la relevancia e impacto que esta última tiene sobre los inversores y el desarrollo económico de la organización, pero no por ello deja de ser menos cierto que a la auditoría del RDLOPD no se le concede en mi opinión la importancia que se debería. Y en esto tiene culpa tanto el cliente, para quien la auditoría es en ocasiones poco más que un molesto trámite a cuyo resultado no le va a prestar la más mínima atención, como las empresas auditoras, que en muchos casos simplemente buscan cubrir el expediente y facturar los servicios; si bien es cierto que en nuestro equipo de consultoría tendemos a valorar en la auditoría aspectos que van más allá de lo que marca el RDLOPD, por tratarse de un reglamento de mínimos, he tenido acceso a informes de auditoría presumo que nada baratos que rozaban lo vergonzoso (en realidad, algunos lo eran). En una situación adecuada, la auditora propone iniciativas a cumplir, y el cliente implanta, dentro de sus análisis coste/riesgo y sus posibilidades económicas aquellas que considere oportunas, pero esto sólo se da en ocasiones.

Dicho esto, ¿qué razones hay para considerar algo “serio” una auditoría del RDLOPD?

La primera de todas, es que es un requisito legal/reglamentario para datos de nivel medio y alto (art. 96 y 110 del RDLOPD, respectivamente). No se trata de un capricho de las consultoras/auditoras, que nos gusta importunar a nuestros clientes con reuniones, informes, preguntas y demás parafernalia implicada. Si hay que molestar, pues se molesta, pero molestar para nada, como que no.

Sigamos con las razones económicas. Espero no decir una barbaridad al afirmar que una auditoría financiera viene a tomar el pulso a la “salud económica” de una entidad, de cara a los accionistas, inversiones, solicitud de subvenciones, préstamos bancarios, etc. Por su parte, lo que la auditoría del RDLOPD analiza es la “salud” de los tratamientos de datos de carácter personal, con el objetivo de detectar incumplimientos y evitar sanciones de la Agencia Española de Protección de Datos que puedan derivarse de éstos. Aunque la agencia ha reducido significativamente el importe de las multas, conocedora de las implicaciones que sus actuaciones pueden tener para una organización de tamaño pequeño o mediano, una sanción de 600.000 € (o incluso de más, si hay varios incumplimientos) es algo a tener en cuenta por el impacto económico tanto directo como indirecto (léase reputacional), ya sea para una empresa del IBEX35, empresas cotizadas más pequeñas, o simplemente, cooperativas. Dicho de otra forma, de la misma forma que el mercado obliga a ciertas empresas a publicar sus análisis de “salud financiera” y exponer así su “riesgo financiero”, el accionista de una empresa, un cooperativista o cualquier persona que aporta capital a una organización (incluso las entidades financieras) debería saber el riesgo que la organización de la que participan tiene de sufrir una sanción de la AEPD.

Por supuesto, una auditoría de la RDLOPD no tiene como fin solucionar los incumplimientos que detecta, ya que eso es tarea de la organización, pero sí ofrece una visión del grado de cumplimiento de la organización, y debe proponer iniciativas, proyectos y soluciones de aquellas no conformidades detectadas, de cara a mejorar el grado de adecuación, y de nuevo, reducir el riesgo.

Por último, vamos con las razones “éticas”, si las quieren llamar así. No debemos olvidar que la ley de protección de datos tiene por objeto garantizar y proteger, en lo que concierne al tratamiento de los datos personales, las libertades públicas y los derechos fundamentales de las personas físicas, y especialmente de su honor e intimidad personal y familiar (LOPD, Art. 1). La LOPD, más allá de una ley de obligado cumplimiento o un foco de riesgo económico y reputacional (que como les decía antes, viene a ser lo mismo), vela por un derecho de cualquier persona, y eso es algo que las organizaciones, y cualquier persona que trabaja con datos de carácter personal debería tener siempre muy en cuenta; la auditoría del RDLOPD simplemente cuida de que estos derechos se estén aplicando de la manera correcta. Esta razón debería ser en realidad la primera de la lista, aunque la he puesto aquí para que no me tildasen ustedes de idealista.

Llegados a este punto, tenemos tres razones de peso para que una auditoría de la RDLOPD deba considerarse algo “serio”: requisito legal, riesgo económico y obligación ética o moral. Sin embargo, insisto en que la auditoría del RDLOPD sigue siendo algo a lo que se le da escasa importancia, tanto para muchos clientes como para algunas consultoras (entre las que, cabe destacar, y como no podría ser de otra manera, nos estamos incluidos). Para los clientes, o responsables de los datos, está el cuerpo de inspectores de la AEPD y su capacidad sancionadora. Pero, ¿y para las consultoras? ¿Qué implicaciones tiene para una de estas empresas realizar de manera poco profesional, intencionadamente o por simple incompetencia, una auditoría del RDLOPD? ¿Qué pasa cuando una auditora entrega un informe (que en ocasiones no puede ni llamarse así) afirmando que todo está correcto, cuando en realidad existen problemas serios en la gestión de datos personales de la organización?

Básicamente, no pasa nada. Por un lado, porque aunque el cliente pueda ser el primero que prefiere que no le agobien con cambios de aplicaciones, declaración de ficheros, documentos de seguridad, y registros de acceso, tampoco es un experto en el tema; para eso ha contratado a la consultora, y si ésta dice que todo está correcto, pues es de suponer que será cierto, porque ellos son los que saben de esto. Segunda, porque a dicho informe no se le da demasiada importancia, más que en casos muy concretos, a diferencia de un informe de auditoría financiera. Tercera, porque más allá de las acciones legales que una organización pudiera emprender contra la auditora que ha realizado la auditoría del reglamento, no existe ninguna repercusión legal para ésta. Cuarta, que a menudo el responsable interno de la auditoría presiona para que se “maquillen” determinados aspectos encontrados, o al menos que no se encuentren visibles en el informe ejecutivo para dirección. Y quinto, que de la poca importancia que les comentaba antes, se deriva que exista un mercadeo en el que se audita el reglamento por “cuatro duros”, y que provoca que por tanto el trabajo realizado sea conforme a ese importe.

Aquí es donde vuelvo al párrafo inicial con el que comenzaba esta entrada: las sanciones económicas para las consultoras, pero en este caso para las que nos dedicamos a la protección de datos. Sería tan sencillo como hacer que la sanción fuese compartida en un determinado porcentaje entre la organización y la consultora (asusta, ¿eh?), con lo que se incrementaría automáticamente la importancia de la auditoría del reglamento y la protección de datos, y se garantizaría un mínimo de calidad en los informes entregados; el cliente podría hacer la vista gorda si quisiese, pero la auditora no. En ciertos casos, y estoy ya divagando, podrían incluso valorarse penalizaciones temporales o permanentes de inhabilitación para auditoras y auditores.

Por supuesto, la consultora debería poder garantizar que la sanción corresponde a un incumplimiento del que se informó en la auditoría, que el auditor solicitó pero no tuvo acceso a la información de la que se deriva la sanción (bien porque se le ha negado, bien porque no se le ha entregado en tiempo y forma), que el problema originador de la sanción no se encontraba presente en el momento de realizar la auditoría, o que es un aspecto no controlable externamente (por ejemplo, un empleado que habiendo sido formado en materia de LOPD, olvida gestionar una solicitud de acceso). De cualquier modo, aunque pueda ser interesante tratar este último punto en una entrada posterior, ¿qué les parecería una medida así?