“Problemas LOPD” (III): Plásticos Cremallera

16 de diciembre de 2008 Por

(Primero, la solución del anterior)

Hace ya demasiado tiempo, recordarán que planteamos el problema de Piruletas de Motilla del Palancar. Resumiendo, Piruletas es una empresa que utiliza los servicios de la empresa Bolsa de Trabajo, (BdT) cuya actividad es un portal web de selección de personal. Cuando un candidato ve una oferta de Piruletas, se apunta a ella y Piruletas es informada de ello. El problema es que BdT no permite que Piruletas informe al candidato de sus derechos respecto de dicha cesión cuando se le informa de que se ha apuntado a la oferta, por lo que el candidato sabe que sus datos son cedidos pero no cómo y frente a quién exactamente ejercer sus derechos.

A lo largo de los comentarios que hemos mantenido Javier Cao, Edgard (inspirador del caso) y un servidor, han quedado evidenciadas algunas lagunas en el procedimiento de actuación de BdT. Al parecer, aunque el candidato conoce el nombre de la empresa ofertante, BdT no permite que tras la inscripción, Piruletas le conteste con los datos de contacto para el ejercicio de derechos ARCO (asumo que Piruletas no conoce los datos de contacto “externos” del candidato, ya que esto facilitaría mucho las cosas); esto no tiene como finalidad (creo) que BdT siga actuando de intermediaria durante todo el proceso. Continuando las suposiciones, se me ocurre que pueden existir empresas que se quieren mantener anónimas hasta el final del proceso, en el cual ellas mismas se ponen en contacto con los “finalistas”, o que como sugería Javier, el negocio de BdT se centre en la gestión, filtrado y envío inicial del lote de candidatos, tras lo cual la empresa (en este caso Piruletas), puede ponerse en contacto con ellos.

Dejando ya el campo de las suposiciones, y pasando a la solución, existe por supuesto una solución inmediata que es el cese de la colaboración con la empresa, aunque quiero considerar esa opción como el último recurso a efectos del presente caso. Por supuesto, en el mundo real ™, cuando se valoran ofertas de diferentes proveedores, uno de los criterios para escoger no es otro que el cumplimiento legal. Otra solución aportada por Javier es la de que BdT anonimice los datos de los candidatos, ya que en un proceso de selección, y excepto cuando la presencia personal tiene un papel importante, los datos identificativos carecen de sentido. Esta solución, aunque es buena, obligaria a BdT a cambiar su forma de trabajar, algo a lo que no creemos que BdT sea especialmente receptiva.

En nuestra opinión el problema reside en su mayoría en la actuación de BdT, que realiza una cesión cuyo destinatario no está definido. Por parte de Piruletas, es cierto que accede a datos identificativos de personas a quienes no puede informar de sus derechos durante el tiempo que dura el proceso de selección (entiendo que no hay manera de contactar con ellos), pero no vemos mayor problema. Respecto a aquellos que rechaza, no está obligado a comunicarles sus derechos ya que no va a tratar sus datos (de forma similar a un curriculum que se destruye nada más ser recibido. Aún así, si considerasemos que existe tratamiento, éste puede verse como extremadamente marginal para ser significativo). Respecto a los que acepta para una fase posterior del proceso de selección, es obvio que tarde o temprano tendrá que conocer sus datos de contacto, que es cuando deberá informarles de sus derechos. Quizá hilando muy fino podríamos ver una no conformidad “temporal”, pero en cualquier caso, creo que no supone un gran problema.

¿Qué os parece?

* * *

Andrés Cremallera fundó Plásticos Cremallera la primavera de 1987. Gracias a varios contratos con la administración pública y a una impecable gestión, pasó de tres empleados a trescientos cincuenta diez años después, momento en el que el crecimiento de la compañía se estabilizó. A partir de 1991, y por requerimientos legales y del negocio, se decidió contratar una empresa de atención médica (Atmedsa) que prestase servicios de asistencia médica en las oficinas de la planta. Dicha atención médica se facilita actualmente por parte de un médico “residente”, en una sala anexa al despacho de Antonio Botón, Responsable del Departamento de Prevención de Riesgos Laborales. Aunque en un principio para el almacenamiento de información había sólo un único archivador, en la actualidad dispone de cinco archivadores con llave (copias de las cuales están en posesión de Antonio Botón), y un ordenador personal propiedad de Cremallera, ubicado lógicamente en el segmento de usuarios, y cuya copia de seguridad diaria (incremental) y semanal (total) están incluidas en las políticas de backup de la compañía. El médico utiliza dicho equipo para almacenar la información habitual (minusvalías, alergias, analíticas) en ficheros ofimáticos de rápido acceso, y para conectar, por medio de la salida a Internet de Plásticos Cremallera, a la aplicación de Atmedsa para la gestión de historiales clínicos.

Ayer, primer día de la primera auditoría del reglamento a la que la empresa se somete, Antonio Botón se dió cuenta de cómo la cara del auditor cambiaba a medida que le describía el funcionamiento del servicio médico, así que por miedo a haber metido “la pata hasta el fondo”, llamó a un amigo suyo que se dedica a “eso” de la LOPD. ¿Qué le dijo éste?

—

Actualización 19/12, 12h: Dani, de Eddasec, plantea una solución en esta entrada de su blog.

Otra pérdida masiva de datos de caracter personal

13 de diciembre de 2008 Por

Hoy, El Pais da cuenta de una noticia: “Filtrados a un diario alemán los datos de tarjetas de crédito de miles de clientes”, en la que se informa de otra pérdida de datos de tarjetas de crédito.

¿Por qué se producen tantos incidentes graves en la gestión de datos personales que hacen las entidades públicas o privadas? Hoy el Berliner Landesbank, pero no hace mucho fue la Hacienda británica ¡por segunda, tercera vez! la que perdió datos personales de los ciudadanos.

No sé si es por la forma de redactar del periodista de El País, pero no da la impresión de que a nadie le haya extrañado demasiado ni se haya rasgado las vestiduras. Estas noticias están dejando de ser noticia. Voy a hacer una predicción: cada vez vamos a enterarnos de casos más graves, en los que se pierda información más sensible o de más millones de usuarios. ¿Hasta cuándo?

¿Nos podemos imaginar que se hubiera perdido dinero, contenido de las cajas de seguridad o documentación confidencial del banco? Seguro que alguien acabaría en la calle. O secretos militares… menudo escándalo. A algún ministro le costaría el cargo.

¿Cuál es la diferencia? En mi opinión, hay tres: (1) se trata de información de los ciudadanos, que no perjudica directamente a los depositarios de la misma, sino a los propios ciudadanos; (2) el perjuicio es difuso, no es que le hayan robado nada a nadie, sino que podrían robarle a algunos de los ciudadanos, si no toman las medidas adecuadas; y (3) la información “extraviada” no la maneja un grupo reducido de personas que entienden su valor, sino mucha gente dentro de varias organizaciones: el banco, la empresa subcontratada para la gestión de los cómputos bancarios (¿?), la delegación… es tan sencillo copiarse una base de datos o una hoja de cálculo…

En resumen, información que manejan muchas personas que no valoran adecuadamente su importancia, que la manejan de manera rutinaria, sino con indeferencia.

Hace falta formación, hacen falta procedimientos y hacen falta mecanismos de seguridad adecuados. Y mucha, mucha concienciación.

No podemos pasarlo por alto

11 de diciembre de 2008 Por

Aunque el objeto de este blog no es, ni mucho menos, servir de trampolín comercial para la empresa que de alguna manera está detrás de estas páginas, no podemos pasar por alto que para el equipo de trabajo de S2 Grupo estos últimos días han sido algo ajetreados, tal y como habrán podido comprobar en la frecuencia de las actualizaciones. Además de haber consolidado nuestras actividades en el Centro de Respuesta ante incidentes de la Comunidad Valenciana (CSIRT-CV), hemos sido adjudicatarios del concurso para la implantación de un SGSI en la Universitat Jaume I de Castellón, del concurso para el desarrollo de una auditoría RDLOPD en RTVV y de un contrato de consultoría para el Desarrollo Seguro para la Consellería de Economía y Hacienda de la Generalitat Valenciana y otros.

Pero la gota que ha colmado el vaso de la satisfacción de nuestra empresa no ha sido, por ahora, un premio gordo de la lotería, sino el premio que el Instituto Ideas de la Universidad Politécnica de Valencia ha otorgado a S2 Grupo como empresa consolidada. Ayer, en un acto en el Paraninfo de la UPV, el Instituto IDEAS de la UPV concedió a S2 Grupo (y, por tanto, a todos nosotros) el primer accésit del Premio a la Empresa Consolidada. Se valoró la trayectoria de la empresa, su proyección de crecimiento, sus iniciativas de I+D+i y su relación con la UPV.

No podemos cerrar esta pequeña contribución como muestra de nuestra alegría sin agradecer públicamente al Instituto Ideas y a la Universidad Politécnica de Valencia el premio concedido.

XSS Cross-site Scripting (II)

9 de diciembre de 2008 Por

(…)

—Perdona por la interrupción. Como te decía, desde el punto de vista de Alicia, hay poco que pueda hacer. Puede desactivar la ejecución de script en su navegador, lo que la dejará sin poder visitar muchas de las páginas que le interesan. Puede activarlo sólo para los sitios de confianza, asumiendo que éstos no son vulnerables a este tipo de ataques (lo que es mucho asumir) y, por supuesto, ser sanamente desconfiada para evitar la parte de ingeniería social del ataque. Y poco más. La responsabilidad está en quienes han desarrollado el sitio web vulnerable, que deben corregir la aplicación Web para que no lo sea.
—¿Se puede conseguir eso?
—Claro. El éxito del ataque se basa en que el sitio Web devuelve el código script que se le inyecta y que se ejecuta en el navegador de Alicia. Basta con no hacerlo.
—¿No devolver el script que luego se ejecuta?
—Ese es el enfoque que siguen muchos desarrolladores. Aplicar “html encoding“. ¿Sabes lo que significa?
—Sí, claro, se trata de “escapar” un carácter especial de un código html para que se muestre como tal, en lugar de ser interpretado por el navegador. Se utiliza siempre que se muestran ejemplos de html en un sitio Web.
—Exacto. Si quiero que en una página salga “<br />” en lugar de un salto de línea en el navegador, debo escribir “&lt;br /&gt;”, ya que esa secuencia tiene un significado especial. He de indicarle al navegador que no debe interpretarla, sino mostrarla, utilizando &lt; para “<" y lo mismo con el resto de caracteres. —Entonces, basta con “escapar" todos los caracteres especiales. —En principio. Claro que eso tiene el inconveniente de no permitir al usuario que introduzca negritas, cursivas o enlaces dentro de su texto. Quizás un inconveniente aceptable. —Bueno, se pueden permitir algunos de los caracteres especiales o, mejor dicho, determinadas combinaciones, como “<a href=", pero no otras, como “<script>". —Sí, claro. Es la táctica de detectar las entradas no deseables y eliminarlas o neutralizarlas. El problema es que hay más formas de introducir un script en un texto de manera que no se detecte con facilidad. Por ejemplo, se puede introducir “%3D%3C%73%63%72%69%70%74%3E", que es lo mismo que “<script>", como parte de una URL. Pero lo peor es que puedes estar protegiendo la aplicación frente a determinadas formas de introducir un script, pero luego aparecer en el futuro otras que no tenías previstas y no ser capaz de detectarlas. —Pero seguro que sabes una solución y me la vas a contar… —Pues la solución es obvia, si aplicamos una de las buenas prácticas de programación que cualquier buen desarrollador conoce: validar cualquier entrada del usuario contra una especificación de las entradas correctas. O sea, admitir lo que es correcto según las especificaciones del programa y rechazar cualquier otra cosa. —Usando expresiones regulares. —Es uno de los métodos más útiles, sí. —En resumen, que el XSS se evita controlando bien todas las entradas a la aplicación, validándolas según la especificación de lo que se considere una entrada correcta. —Ni más, ni menos.

“Bugs” del RDLOPD

5 de diciembre de 2008 Por

Con la entrada en vigor del RDLOPD el pasado mes de abril, se realizaron una serie de “reformas” en el RMS con el fin de mejorar y “aclarar” ciertos aspectos que el RMS no contemplaba, o bien, dejaba muy abiertos a múltiples interpretaciones. Tratándose de un Real Decreto, no es comprensible que muchas ocasiones un mismo artículo pudiera significar tantas cosas, dependiendo de para donde sople el viento.

El caso es que el RDLOPD, creo que sin mala intención sino más bien todo lo contrario, nos ha aclarado ciertas cosas, pero otras se han vuelto a quedar en el tintero e, incluso, han surgido nuevas dudas debido a modificaciones efectuadas respecto al RMS. Un ejemplo es la intención de considerar la aplicación de medidas de seguridad de nivel básico en ciertos ficheros con datos de salud. Me refiero al fichero habitualmente llamado “PERSONAL”, “GESTIÓN DE NÓMINAS”, “RRHH” o como queramos llamarle. Es decir, aquel que contiene datos de trabajadores para realizar la gestión de personal y cálculo de las nóminas.

Con el RDLOPD, este fichero que suele contener el grado de minusvalía pasaría a un nivel básico de protección, lo que se puede interpretar como una medida que ayude a las PYME a adaptarse a la LOPD de una manera más sencilla (ya que implica menos medidas de seguridad a implantar) y les genere un menor coste económico y funcional. Pero, teniendo en cuenta la resolución que les enlazo, ¿qué pasa con la aptitud de un trabajador a efectos de prevención de riesgos laborales o las obligaciones impuestas al empresario para indicar el motivo de una incapacidad laboral, datos incluidos en el mismo fichero? ¿Nivel alto o nivel básico? ¿Hoy básico, mañana alto y pasado ya veremos?

De momento, estos “bugs” están siendo solventados por la AEPD a base de dictámenes jurídicos, conferencias, etc., pero creo que la mejor opción hubiera sido incluirlo de manera clara y definitiva en el lugar donde debería figurar: el RDLOPD.

XSS Cross-Site Scripting (I)

3 de diciembre de 2008 Por

—Maestro, una vez más me atrevo a acercarme a ti con mis preguntitas sobre seguridad.
—Menos guasa, que ya sabes que yo “sólo sé que no sé nada”.
—Bueno, algo sabes…
—¿Qué tripa se te ha ro… digo… en qué puedo ayudarte?
—Estaba leyendo un blog en el que se hablaba de Cross-Site Scripting y, la verdad, no consigo entender de qué va el asunto; ni San Google me ha podido ayudar. Sólo he sacado en claro que el nombre no es del todo descriptivo y que se trata de utilizar una vulnerabilidad para inyectar código en un sitio para obtener datos de un usuario que cree estar visitando otro o algo así.
—Pues efectivamente, se trata de aprovechar una vulnerabilidad y es de lo más interesante. Es uno de los casos en los que puede caer hasta un usuario prudente, ya que no depende de que realice una actividad temeraria durante la navegación. Como sabes que suelo hacer, empezaré por describirte un posible escenario de lo que puede pasarle a un usuario, antes de entrar en la descripción de las interioridades.

“Alicia está leyendo uno de sus blogs favoritos sobre economía. Esta vez hay un post sobre un tema un tanto polémico y, como suele ocurrir, alguno de los comentarios es un poco incendiario, por lo que todos los demás se dedican a darle la razón o a contradecirlo. Alicia, curiosa, navega hasta el comentario en cuestión, lo lee, y aporta su opinión, identificándose previamente como usuaria registrada. El mal ya está hecho.

Al día siguiente, aparece un comentario de Alicia en el que se comporta como un troll, pero no ha sido ella. No es nada muy importante, pero tiene que dar algunas explicaciones al propietario del blog, a alguno de sus conocidos del MundoReal® que saben su nick y, por supuesto, pedir que le den de baja su usuario registrado.

Luego, empieza a ponerse un poco paranoica (o no) y piensa que el mismo usuario y contraseña lo está usando en otros blogs y foros y hasta en su cuenta de ¿flickr? ¿Facebook? … No en nada importante, como el banco online, claro. En fin, te haces una idea, ¿no?”

—Pero ¿qué ha hecho mal Alicia?
—Nada.
—Entonces, ¿de quién es la culpa?
—En este caso, de quien ha desarrollado la plataforma del blog, pero esto puede ocurrir en cualquier aplicación Web que acepte entradas de los usuarios (formularios, blogs, foros).
—Y, ¿cómo funciona?
—La base está en hacer que el sitio web vulnerable te muestre código script que tú has introducido (inyectado) previamente. Por ejemplo, en un campo buscador o en uno de un formulario o, en el caso del blog, en el campo de entrada del comentario. Si en lugar de introducir texto inocuo, el hacker pone código script y el servidor lo almacena o lo devuelve, el navegador de Alicia ejecutaría ese script.
—No acabo de entenderlo. ¿El hacker introduce el código y luego otro usuario lo ve y se ejecuta? Pero el otro usuario estará en otro sitio y en otro momento, ¿no?
—Cierto, te lo explico un poco mejor: el hacker pone un comentario en el blog de antes, pero además de texto normal, introduce un trozo de código en (java)script. Si la aplicación guarda esa información en una BD o en un archivo para uso posterior (como ocurre con los blogs), cuando Alicia accede a los comentarios del blog, el script se muestra, y por tanto se ejecuta en su navegador. Es lo que se llama un ataque stored (almacenado).
—¿Y si no se almacena el texto?
—Entonces, es ligeramente más complejo. Se trata de conseguir que Alicia acceda al sitio vulnerable con toda la información que el atacante necesita ya metida en la URL. Es decir, tiene que “clickar” en una URL que contiene la dirección de la página del sitio vulnerable, el campo correspondiente, el contenido y el “efecto” del click de enviar. Aunque parece complejo, en realidad no es muy complicado construir la URL. En este caso, se trata de un ataque reflected (reflejado).
—¿Cómo consigue el hacker que Alicia clicke en una URL así?
—Normalmente, ingeniería social. Es decir, engañándola. Puede ser con un email en el que se le dice que mire algo en un sitio web (que, además, conoce y en el que probablemente confía), o con una URL con una referencia a una noticia o a otro contenido del sitio Web vulnerable. El usuario clicka porque conoce el sitio destino, pero la URL es maligna y contiene un script. En fin, hay muchas formas.
—Y con eso el hacker consigue…
—Por ejemplo, la cookie de sesión de Alicia, con la que puede suplantarla, obtener y cambiar su contraseña, obtener información privada que tiene el sitio vulnerable, etc. Además, como mucha gente utiliza el mismo usuario y la misma contraseña en varios sitios, puede empezar a acceder a esos sitios, obtener más información … en fin, te haces una idea.
—Entiendo. Y, ¿cómo se puede evitar?
—Desde el punto de vista de Alicia, hay poco que pueda hac…

Ring, Riiinngg

—Vaya, el teléfono. Espera, ahora te cuento.

(Continuará…)

Seguridad y riesgos en las TIC (III)

1 de diciembre de 2008 Por

Nos van a disculpar la ausencia de estos días, pero diversas cuestiones nos han mantenido alejados del blog, y no hemos podido dejarnos caer por aquí. En cualquier caso, dicho eso y esperando que acepten las disculpas, volvemos con la tercera parte de la serie “Seguridad y Riesgos en las TIC” (uno, y dos), que se centra en el Análisis de Riesgos. Al igual que en otros “capítulos” de la serie, no esperen demasiada profundidad ni tecnicismos, ya que no es ese el propósito de esta serie.

El Análisis de Riesgos es una herramienta de diagnóstico utilizada para determinar la exposición de una organización a los riesgos. Sus objetivos son (a) identificar los riesgos mediante la identificación de sus elementos, (b) determinar el riesgo total o exposición bruta al riesgo, como combinación de los elementos que lo conforman, y (c) determinar el riesgo residual.

Comúnmente se calcula el valor del impacto promedio por la probabilidad de ocurrencia para cada amenaza y activo. De esta manera tendremos, para cada combinación válida de activos y amenazas:

RT (riesgo total) = Probabilidad x Impacto Promedio

Por ejemplo, si la probabilidad anual de sufrir un incendio es de 0,0001 y su impacto promedio en términos monetarios es 600.000 €, la exposición al riesgo anual es de 60. Al cálculo previo se debe agregar el efecto de medidas mitigantes de las amenazas, lo que generará el riesgo residual: el riesgo “que queda” tras la aplicación de las medidas implantadas para reducir los riesgos existentes. Estas medidas son conmunmente conocidas como controles, por lo que tendremos que el riesgo residual es una medida del riesgo total remanente después de contemplar la efectividad de las contramedidas implantadas.

De esta manera, siguiendo con el ejemplo planteado, si el riesgo total de la amenaza de incendio es 60, tras contratar un seguro sobre la totalidad de los activos, el riesgo residual resultante sería igual a cero; si en su lugar se asegurara por la mitad del capital, el riesgo residual sería igual a 30. Ni que decir tiene que el ejemplo está simplificado, con el único objetivo de ayudar a comprender los conceptos anteriores; en la realidad no es nada sencillo cuantificar adecuadamente los riesgos, y es habitual utilizar un enfoque cualitativo en lugar del anterior cuantitavivo, expresando los riesgos en escalas: alto, medio, bajo, o equivalentes.

El proceso de análisis descrito genera habitualmente un documento que se conoce como matriz de riesgo, en el que se muestran todos los elementos identificados, sus relaciones y los cálculos realizados. La suma de los riesgos residuales calculados será la exposición neta total de la organización a los riesgos. Simplificando, su resultado será positivo si decidimos asumir un cierto nivel de riesgo residual (lo que en términos anglosajones se conoce como el risk appetite de la organización), cero en el caso ideal (número justo de controles para mitigar todos los riesgos), o negativo si la organización se encuentra cubierta de cualquier riesgo pero tiene más controles de los necesarios (y por tanto su coste es superior al óptimo).

Realizar un análisis de riesgos es indispensable para llevar a cabo una administración adecuada de los riesgos, aspecto que consiste en gestionar los recursos de la organización para lograr un nivel de exposición determinado, generalmente establecido por el tipo de activo: a mayor criticidad del activo, menor exposición y viceversa. El ciclo de administración de riesgo se cierra (tras el análisis) con la determinación de las acciones a seguir respecto a los riesgos residuales identificados.

Acciones que pueden ser (a) controlar el riesgo, si se fortalecen los controles existentes o se agregan nuevos, (b) eliminar el riesgo, si se elimina el activo relacionado y por lo tanto el riesgo, (c) transferir el riesgo, traspasando parte de éste (o su totalidad) a un tercero (un ejemplo típico son los seguros), o (d) aceptar el riesgo, al determinar que el nivel de exposición es adecuado. La opción a escoger para administrar cada uno de los riesgos dependerá de diferentes factores, tanto económicos como estratégicos, teniendo en cuenta que las consecuencias asociadas a un determinado riesgo no siempre aceptan todas “opciones posibles”; se puede transferir el impacto económico de un robo en un banco a través de un seguro, pero no su impacto en la imagen de marca.

En la próxima entrada, veremos un poco más en profundidad el proceso de administración del riesgo como proceso continuo.

“Problemas LOPD@@@ (II): Piruletas de Motilla del Palancar

20 de noviembre de 2008 Por

Siguiendo con la línea de “Problemas LOPD” que comenzó con Palotes de Chiclana, a continuación les presento un caso que hace unas semanas plantearon Edgard y Dani Puente en su blog Eddasec; les advierto que en este caso, a diferencia del anterior, es posible que no exista una solución clara más que la interrupción de la relación comercial. Vamos allá.

Una empresa, llamémosla Piruletas de Motilla del Palancar, tiene una relación mercantil con la página web “Bolsa de trabajo”, cuyo negocio se centra en la gestión de ofertas de empleo a través de Internet; se trata obviamente de un portal de búsqueda de empleo. Ésta informa al candidato de sus derechos en los términos establecidos por la LOPD, y puesto que existe una relación de comunicación/cesión de datos con el ofertante de empleo, “Bolsa de trabajo” recoge el debido consentimiento.

No obstante, Piruletas de Motilla del Palancar está preocupada porque en ningún momento se informa claramente al candidato del destinatario de los datos, en este caso ellos, aspecto que aunque está implícito en la oferta a la cual se inscriben, no se ajusta a los requisitos de la LOPD. A tal efecto, han pensado en incluir una advertencia legal con sus datos (en calidad de responsables “temporales” del tratamiento, mientras valoran la posible adecuación del candidato al puesto ofertado) en el correo de respuesta que automáticamente reciben todos/as los/as candidatos/as que se inscriben a las ofertas, incluyendo por supuesto en éste las direcciones de contacto para el ejercicio de derechos ARCO.

Sin embargo, “Bolsa de trabajo” no permite que se incluya este tipo de información de contacto, y sus condiciones de uso no permiten facilitar datos de contacto a los candidatos, seguramente para mantener su modelo de negocio y otras razones permitir a las empresas mantener el anonimato hasta el final del proceso de selección. No obstante, ¿qué debería hacer “Piruletas” al respecto? ¿Es necesario que informen de su condición de destinatarios de la cesión, o ese aspecto le concierne a la web “Bolsa de trabajo”? ¿Hay alguna solución “intermedia”? ¿Qué opinan ustedes?

Nuestra “solución”, en una próxima entrega.

La (in)seguridad del software

14 de noviembre de 2008 Por

Hace unos meses leía en la web de Bruce Schneier un artículo en el que hablaba de la responsabilidad -o irresponsabilidad- de los generadores de software (por “generadores” me refiero a programadores, empresas de desarrollo, analistas, etc.) en la seguridad de la información. Bajo mi punto de vista, el software -en especial las aplicaciones- fallan. Fallan y mucho. Y demasiado. No únicamente desde el punto de vista de seguridad -que también-, sino incluso desde el punto de vista de la funcionalidad. Y lo peor, es que todos lo asumimos como algo habitual, como lo más normal del mundo, y como decía Schneier, incluso parcheamos nosotros mismos las aplicaciones (algo impensable con un coche, por ejemplo).

¿Por qué falla el software? Mi opinión es que en términos generales el software falla por cuatro grandes motivos; los comento, sin ningún orden particular:

La incultura de la seguridad
Muchos programadores (por programadores no me refiero únicamente a los que pican código, por supuesto) carecen de una cultura de seguridad a la hora de trabajar; simplemente no se tienen en cuenta los requisitos de seguridad de una aplicación, de un producto, ni en sus fases iniciales, ni en su implementación, ni en sus pruebas, ni en nada. El único objetivo es que funcione (hoy en día, ni siquiera que funcione rápido), que sea bonito (recuerden aquello de programa=algoritmo+marketing) y, en ocasiones, que sea tecnológicamente interesante. Poco más. ¿Seguridad? ¿Yesoqués?

El desconocimiento técnico
Incluso teniendo en cuenta la seguridad en el diseño o en la especificación de un programa, a la hora de implementarlo el desconocimiento técnico del programador hace que se cometan fallos garrafales en el código que, si no son corregidos a tiempo, acaban comprometiendo la seguridad de la información con la que tratan. No creo que valga la pena ahora hablar de errores habituales como buffer overflows o condiciones de carrera, pero alguna pregunta: ¿cuántos desarrolladores conocen el término TOCTTOU? ¿cómo se comprueban los datos que devuelve una orden del sistema? ¿qué alternativas a system() existen?

Las empresas de desarrollo
Una empresa siempre busca beneficios, y la seguridad es algo que no se ve. En ocasiones, los beneficios generados por un desarrollo seguro no se perciben desde la Dirección, por lo que en muchas empresas únicamente se busca la funcionalidad de las aplicaciones para obtener beneficios de las mismas. Dicho de otra forma, no se invierten los recursos necesarios en garantizar la calidad del software generado, únicamente se busca que la aplicación funcione y que se pueda liberar una nueva versión cuanto antes. Adicionalmente, una empresa de desarrollo no suele decir que no a nada. ¿Reprogramar la página web para poner una zona privada que enlaza con una base de datos externa? Para mañana. ¿Cifrado? Bah, no hace falta… Imaginad que necesitáramos un coche anfibio, con alas, reforzado, blindado y capaz de transportar 20 toneladas consumiendo menos de cinco litros. En un concesionario nos tomarían por locos, pero en una empresa de desarrollo nos dirían “Para mañana”. Ojo, un programa open source no suele tener la presión comercial detrás, y tampoco está libre de errores (le afectan por supuesto el resto de factores comentados aquí).

El error residual
Finalmente, incluso evitando todos los problemas anteriores, hay un porcentaje de errores que es inevitable; ese porcentaje es, a día de hoy -y de nuevo bajo mi punto de vista- demasiado alto en el desarrollo de software, y por supuesto debe reducirse a toda costa si queremos hablar de desarrollo seguro. Mientras no consigamos minimizar ese porcentaje de errores residuales, estaremos hablando de un problema serio, inimaginable en otros productos de uso masivo y diario.

¿Cómo evitar los problemas anteriores? No vamos a descubrir nada nuevo, obviamente, pero con algo tan sencillo como aplicar lo que ya sabemos, podríamos reducir, en un porcentaje muy significativo, el número de problemas de seguridad de las aplicaciones. En primer lugar, requerimos de formación e información; parece vergonzoso que en muchas facultades y escuelas de informática se hagan pocas referencias a la seguridad (si nuestra especialidad es Software, sustituyan el “pocas” por “ninguna”). Siendo así, ¿qué esperamos? Ni cultura de seguridad, ni conocimiento técnico, por supuesto. Y cuando hablamos de la dirección de la empresa, peor aún: la falta de cultura de la seguridad hace -no siempre, afortunadamente- que no se vean los beneficios que genera un desarrollo seguro. Si todos fuéramos conscientes de tales beneficios, otro gallo nos cantaría.

Finalmente, y hablando ya del error residual, creo que un factor decisivo para reducir el porcentaje de fallos es aplicar técnicas de ingeniería al desarrollo, algo que en la práctica se hace más bien poco (por mucho que en la carrera nos lo hayan explicado N veces). ¿Por qué? Eso sería seguramente material para muchos otros posts, más polémicos que este :)

La fiabilidad del proveedor de seguridad

12 de noviembre de 2008 Por

Por todos es conocido el hecho de que el mejor producto que pueda fabricarse, o servicio que pueda proveerse, necesita de una gestión de marketing para su promoción en el mercado al que va dirigido; por bueno que sea, un producto o servicio no se vende si no se da a conocer. La labor del personal de este departamento, tantas veces infravalorada por otras áreas de la empresa es la que da vida a la misma, mediante la promoción de productos y servicios para la obtención de contratos y pedidos por parte de los clientes. Esta tarea es casi siempre callada y confidencial, con el objeto de evitar que otros competidores puedan estar informados de las posibilidades de negocio de la compañía, y sólo cuando una contratación se produce, se anuncia, anuncio que casi nunca transmite de manera evidente el esfuerzo que ha requerido la venta, y más aún en el caso de nuevos clientes.

Sin embargo, en todos los sectores existen factores que el personal de Marketing no ignora y que son decisivos a la hora de valorar las posibilidades de obtener un contrato con un cliente. En el caso que nos ocupa, los servicios de seguridad, hay una serie de componentes que facilitan o complican la presentación de ofertas y sus posibilidades de éxito, y que posteriormente serán los que condicionen la satisfacción del cliente y su fidelidad.

Inicialmente, el cliente valorará el producto o servicio ofrecido, y verá si satisface sus necesidades. En caso de ser así, pasará a valorar al proveedor que se lo ofrece, para lo cual evaluará la infraestructura de soporte de la que el proveedor dispone, las ventajas particulares que le aportaría dicho proveedor frente a otros (valor añadido), y considerará el nivel de satisfacción que otras empresas o clientes usuarios del mismo servicio puedan aportarle como referencia. En definitiva, lo que está haciendo es contrastar la fiabilidad del proveedor antes de realizar la contratación.

Es aquí donde la gestión interna del proveedor, su estructura, su eficacia y su coste van a jugar un papel importante para que el posible cliente juzgue conveniente o no depositar su confianza en él. Además, la información que un cliente satisfecho o insatisfecho puede aportar en estos casos es clave para la obtención de nuevos contratos, y podemos decir que en ese instante, se está valorando sobre todo la fiabilidad y actitud del personal que presta el servicio, mas que la marca o nombre de la empresa proveedora.

Entrando en materia, en lo que concierne a servicios de gestión y seguridad de la información, la actitud de los empleados que prestan el servicio, la calidad de los procesos que intervienen en el control de problemas y solución de los mismos, el tiempo de respuesta y duración de los incidentes, así como la posible repetición o desaparición de estos, son factores clave a la hora de valorar los servicios de un proveedor, y serán transmitidos por el cliente “experto” al “futurible” de una forma positiva o negativa, de acuerdo a su situación y nivel de satisfacción con dicho proveedor.

Por ello, el personal de soporte resulta, más en ocasiones que otras personas igualmente vitales pero menos visibles, un elemento crucial en el posible éxito o fracaso del área de servicios de una empresa, tanto por parte del proveedor de dichos servicios (fundamental) como por parte del equipo interno del cliente. Al fin y al cabo, ambos van a menudo de la mano, y el entendimiento y colaboración entre ambas partes llevará al éxito o fracaso del servicio, con independencia del nivel de gravedad de los incidentes que se produzcan; al respecto, suele ser más lesiva una permanencia repetitiva de incidencias de bajo nivel a la que nadie presta la debida atención, pero que comprometen a empleados del cliente, que un incidente de nivel alto solucionado con prontitud, ya que siempre pesará más el día a día que la situación excepcional, sin negar la importancia que tal hecho tenga.

Para que el equipo de soporte alcance el nivel de prestaciones y desempeño que de él se espera, será también necesario organizar internamente el equipo, definiendo roles y responsabilidades (job descriptions), medios de medición de cumplimiento, etc., pero también facilitando herramientas eficaces y claras a los responsables del servicio, de modo que cada cuál sepa qué debe hacer en cada caso, y cuales son las soluciones que puede aportar. Para ello, métodos, procedimientos y políticas serán fundamentales, no bastando con redactarlas y publicarlas sino que será necesario un entrenamiento y puesta al día periódicamente, para alcanzar una alta fiabilidad. En este asunto, el trabajo planificado, los controles de errores, la inspección y test preventivos son fundamentales, pero también la permanencia del personal en su puesto (baja rotación), preservando la experiencia y el conocimiento necesario, tanto sobre su entorno de trabajo como sobre el de los clientes a los cuales presta el servicio. Todo ello proporcionará un importante incremento en la eficacia del servicio.

Es pues necesario recalcar que la labor de venta de un servicio y la contratación del mismo no son artes que una empresa pueda desarrollar sin tener una base de soporte bien asentada y un personal eficaz y responsable que conozca la importancia de su trabajo y lo crucial de sus relaciones con los clientes. La seguridad de los servicios, como en tantos otros negocios, no es solamente un tema técnico sino que está influenciada por un factor humano que los condiciona enormemente.

En 37 años como proveedor y cliente de servicios de seguridad y gestión de la información, he visto toda clase de problemas, graves y menos graves, resueltos con prontitud o con dificultad, pero siempre el factor de confianza en el equipo humano que daba el soporte ha sido crucial en la toma de decisiones posteriores y en la valoración de nuevos contratos. Formación y titulación de los técnicos son factores que generalmente no están al alcance del posible cliente, pero eficacia, disponibilidad y confianza son términos que se manejan con claridad a la hora de que un responsable de contratar un servicio haga una propuesta a la dirección de su empresa. Para ello, siempre contrastará otras experiencias antes de decidir y por ello, de nuevo el personal que presta el servicio es una de las claves de éxito.