Seguridad contra Seguridad

Los que nos dedicamos a Seguridad siempre hemos oído (y asumido como propio) aquello del equilibrio entre seguridad y funcionalidad: debemos conseguir una seguridad aceptable para los procesos corporativos de nuestra organización, pero al mismo tiempo sin degradar el correcto funcionamiento de dichos procesos y permitiendo que el negocio continúe; y todo esto, por supuesto, en base a los recursos de los que dispongamos y a la estrategia corporativa. Dicho de otra forma, si mi seguridad se basa en mantener siempre los sistemas críticos apagados o las puertas de mi oficina comercial cerradas permanentemente, lo más probable es que sea el más seguro… de la cola del paro.

No obstante, conforme la seguridad se ha convertido en una materia multidisciplinar en las organizaciones, en las que ya no hablamos sólo de seguridad sino que ampliamos el concepto a protección del negocio, y tocamos ramas tan dispares (¿o no?) como la seguridad legal, la continuidad del negocio, la seguridad física o la seguridad lógica, nos encontramos con que en ocasiones no sólo debemos mantener el equilibrio del que hablábamos antes (seguridad vs. funcionalidad, seguridad vs. coste) sino que además debemos anteponer en ocasiones una visión de esa seguridad frente a otras.

Imaginemos que nuestra compañía organiza unas sesiones comerciales para presentar sus nuevos productos, sesiones a las que va a acudir algún que otro VIP. Cuando desde Seguridad se solicita a Protocolo la relación de personas que van a asistir, para determinar qué medidas de protección es necesario adoptar, Protocolo nos dice que por la LOPD no puede facilitarnos esta relación (o sí que puede, pero tardará N días, cuando la sesión es dentro de N-1 días). ¿Qué hacemos? Aparte de iniciar los trámites necesarios para que no vuelva a ocurrir, tenemos dos opciones: si queremos proteger adecuadamente a las personas que acuden al evento, debemos conseguir esa lista por algún medio, y si queremos cumplir con la ley, no podemos conseguirla… En cualquier caso, el problema tiene mala solución, ¿verdad?

A diario en nuestro trabajo podemos encontrar ejemplos como el anterior. Ya no sólo se trata de garantizar la seguridad global de la organización, sino que en ocasiones se trata de anteponer una visión de la seguridad a otras; como hemos dicho, los riesgos que debemos evaluar sobrepasan muchas veces el habitual “seguridad vs. funcionalidad”. Sólo un detalle: tengamos en cuenta que la protección de personas siempre suele ser el elemento más crítico en cualquier organización (por si sirve de pista para solucionar el problema anterior ;).

Ah, podemos enlazar esta entrada con la serie acerca de Problemas LOPD, en este mismo blog… ¿o no es lo mismo?

Vodafone les desea feliz navidad (y S2 Grupo feliz año)

No, no me he equivocado. Esta mañana leía en un foro lo siguiente, con fecha del pasado 22/12 21:40h:

Durante la tarde de hoy observo una incidencia en Mi Vodafone. Tengo 3 líneas que gestionar una de contrato y 2 de prepago, el caso es he observado de cada vez que accedo a la sección “mis datos” y nombre del “titular de la línea” me sale una persona distinta, me explico conecto y en alguna de las lineas me sale un nombre, nif, dirección, teléfono de contacto y dirección que nada tienen que ver conmigo, me desconecto y vuelvo a conectarme y vuelven a salirme los datos de otras personas, nunca son los mismos. Cada vez que me conecto veo los datos de otras personas en lugar de los mios. ¿Es esto normal? ¿Están a salvo nuestros datos en manos de Vodafone? [gsmspain.com]

Al parecer, este problema afectaba únicamente a los clientes de prepago, y aunque no he indagado demasiado en el error, también existía alguna relación entre el usuario que el cliente veía cuando accedía, y las fechas de alta de la tarjeta o el programa de puntos de ambos. Vodafone dió de baja el acceso a dicha sección de la web a partir de las 12h del día siguiente, un poco tarde en mi opinión para un operador nacional de móvil de estas dimensiones. A pesar de ello, hasta ayer 29 los medios de comunicación no se hicieron eco del problema, y todo gracias a la denuncia interpuesta por Facua contra Vodafone ante la AEPD. Sin mayores reflexiones, sirva este último caso como colofón a un año que nos ha traído la entrada en vigor de un nuevo reglamento y un buen montón de fugas, pérdidas, robos, evaporaciones, transmutaciones y venta de datos de carácter personal, algunas públicas, otras (¿muchas?) no. Y discúlpenme que no ponga los enlaces, pero es que son muchos.

* * *

No podíamos acabar el año sin dar respuesta al tercer problema LOPD, aunque lo cierto es que todos los participantes habéis acertado de pleno y no creo que pueda añadir demasiado. Más allá de las medidas que Atmedsa debe implantar en relación con sus propios trabajadores, la idea era centrarse en la relación responsable – encargado del tratamiento.

La verdad es que, si les gustan los puzzles, la situación en la que Atmedsa y Plásticos Cremallera están es un bonito rompecabezas que incluso es parcialmente regularizable. ¿Se han planteado que Plásticos Cremallera, contra todo pronóstico, podría actuar de Encargado del Tratamiento de los datos responsabilidad de Atmedsa, dando servicios de soporte informático? Entre otras muchas cosas, deberían firmar un contrato de acceso a datos y Cremallera disponer de un Documento de Seguridad como Encargado del Tratamiento. Claro que el tema de las llaves del armario no hay manera de regularizarlo.

No obstante, el señor Botón y su amigo, que se dedica “a eso de la LOPD”, son partidarios de las soluciones sencillas. De la navaja de Occam y del Principio KISS (Keep It Simple, Stupid) que tanto le gusta a Tanenbaum. Y por eso se dan cuenta de que convertir a Plásticos Cremallera en Encargado del Tratamiento de Atmedsa, es, aparte de una estupidez, y perdónenme el lenguaje, un marrón considerable teniendo en cuenta el nivel de los datos que el servicio médico gestiona.

Así pues, en la línea de las soluciones indicadas, es imperativo que el servicio médico tenga en exclusiva las llaves del armario, y recomendable que los equipos informáticos sean proporcionados por Atmedsa. Vuelve a ser imperativo que el soporte técnico de los equipos (copias, registro de acceso, cifrado, etc.), independientemente de quien lo proporcione, no lo preste técnicos de Plásticos Cremallera, sino personal de Atmedsa o una tercera empresa contratada por ésta (desde el punto de vista de cumplimiento, ese es ya su problema y no el de Plásticos Cremallera). Es recomendable que se disponga de segmentación en la red, tanto para evitar el acceso al equipo del servicio médico por parte del personal de Plásticos Cremallera (esto debe ser preocupación de la empresa del servicio médico) como para impedir que el personal médico tenga acceso a la red corporativa (y esto, preocupación de Cremallera). En este caso en particular, la solución ideal podría ser en mi opinión una ADSL directa al equipo del médico sin ningún tipo de conexión con la red corporativa, pero por supuesto eso tiene un coste (tanto económico como de gestión, y en este caso yo deshabilitaría lógicamente cualquier punto de red a menos de 5 metros del router ADSL). Y creo que, aunque no haya añadido nada, eso es más o menos todo; ¿qué les parece?

Ahora, déjennos que tomemos las uvas, pensemos un poco y el año que viene venimos con más problemas. Total, es pasado mañana. Así pues, feliz año a todos, con puente o sin él.

La norma ISO 28012:2008

Dentro de la familia de normas ISO 28000, relativas a seguridad en la cadena de suministro, y de especial relevancia en el tema de protección de infraestructuras críticas nacionales que ya hemos comentado en algún post dentro de este mismo blog, ISO acaba de publicar la norma ISO 28012:2008, Metodologías para el Análisis de Riesgos en la Cadena de Suministro Portuaria.

Esta norma, no certificable -para eso está ISO 28001-, define como su nombre indica los métodos a seguir para realizar un análisis de riesgos focalizado en el suministro a través de puertos. Para ello, define una clasificación de activos muy distinta a lo que hasta ahora conocíamos (por ejemplo, a través de MAGERIT), y es que la norma se basa no en lo que los activos son (sistemas, información, personas…), sino en lo que los activos valen para la organización (algo completamente coherente, dicho sea de paso). Así, tanto los impactos sobre el negocio de la pérdida o degradación de un activo se calculan en base a esta premisa, y por tanto el riesgo que la organización soporta viene directamente derivado del valor de cada activo concreto para el negocio.

ISO 28012:2008 clasifica el valor de los activos en cinco niveles, del 1 (valor más bajo) al 5 (máximo valor), y determina los riesgos para el negocio en base a esos valores. Por tanto, un activo de valor 1 puede degradarse -o perderse- por una amenaza determinada sin que el impacto asociado cause daño en la organización, mientras que esa misma amenaza sobre un activo de valor 5 constituye un riesgo no asumible y que por tanto debe ser mitigado.

Realmente, esta aproximación es similar en resultados a la aproximación clásica de cualquier metodología de análisis de riesgos; lo realmente curioso es que al valorar los activos -de todo tipo-, la norma establece valores de mercancías transportadas en barco (en base al precio global del contenedor y del impacto de su pérdida), pero también establece “valores” para otros activos relevantes en la cadena de suministro, como son las personas encargadas de garantizar que dicha cadena es correcta y completa.

Sin entrar a juzgar la ética de valorar a las personas con un determinado nivel, y considerar su pérdida como algo asumible o no para el negocio, hemos realizado un “simulacro” de análisis según esta norma, y siguiendo sus indicaciones al pie de la letra podemos determinar que las personas más prescindibles para la cadena de suministro portuario son los keypiggers, una figura hasta ahora considerada clave en cualquier autoridad portuaria y cuyo cometido es registrar por triplicado las entradas y salidas de mercancías, buques y personas al recinto portuario. Y realmente, fijándonos con un poco de atención en las funciones de dicha figura, podemos determinar que desde hace años está realizando un trabajo completamente redundante, ya que el control de contenedores y buques se realiza de forma automática en cualquier puerto moderno, mediante tecnologías como RFID, mientras que el control de personas se realiza a través de la Policía Portuaria, que tiene delegada dicha función por Real Decreto desde 1.966.

De esta forma, algo tan sencillo como la publicación -y aplicación- de una norma de seguridad, va a ahorrar a los puertos de todo el mundo una enorme cantidad de dinero, simplemente prescindiendo de la figura del keypigger, considerada clave hasta el momento y que se ha demostrado poco o nada relevante en la realidad (y que por tanto, con toda probabilidad, va a ser la figura a desestimar en cualquier puerto). Y lo más sorprendente es que, después del keypigger, seguramente vendrán más.

Como vemos, esta norma ha entrado muy fuerte en el panorama de la seguridad, ya que su publicación y aplicación ha detectado de forma directa un gasto sin sentido desde hace años y cuya anulación va a suponer a las autoridades portuarias de todo el mundo un gran ahorro. Esto demuestra, una vez más, dos cosas: por un lado, la enorme utilidad de una norma bien aplicada, y por otro, el grado de pasividad que hemos adquirido con el tiempo, ya que hemos sido incapaces de detectar esta situación hasta que ISO nos ha abierto los ojos. En fin, ver para creer…

PD. Como muchos de mis compañeros ya no me consideran tan técnico como antes -ellos sabrán- aquí va una prueba que demuestra lo contrario: este paper que he enviado a USENIX, acerca del impacto de las simetrías en el cifrado. Disfrutadlo :)

La medida más importante de seguridad

Hace unos días en una reunión con la familia lejana, comenté que me dedicaba a temas de seguridad, y como suele ser habitual, los interesados tardaron poco en preguntar que les recomendaba para sus equipos caseros personales. Entonces tuve que ver cual era la medida de seguridad más importante que les iba a recomendar.

Dado que todos los presentes eran usuarios de Microsoft, lo primero que se me vino a la cabeza fue el “escudito” que Microsoft incluye en sus sistemas operativos de escritorio. Seguro que muchos de ustedes lo han visto alguna vez en la esquina derecha de la pantalla, y que de una manera semafórica le indica al usuario si su sistema es “seguro” (verde), “no es seguro del todo” (amarillo), o “no es seguro” (rojo). Hay que que reconocer que aunque sea una simplificación y las cosas no tiendan a ser tan simples, a un usuario doméstico puede ayudarle bastante. Las tres cosas que este sistema comprueba en un Windows XP son las siguientes:

– Firewall: Seguridad perimetral, si el sistema tiene activado el firewall y está protegido de ataques externos.

– Antivirus: En este caso, el sistema garantiza que existe un antivirus y que se encuentra actualizado, con lo que con suerte estamos protegidos frente a virus conocidos y software malicioso.

– Actualizaciones automáticas: Garantizan que el sistema esta actualizado, al menos el sistema operativo. Por desgracia no comprueba otras aplicaciones frecuentemente utilizadas, entre ellas navegadores y otras aplicaciones vulnerables a la asalvajada Internet, pero como suele decirse, más vale algo que nada. No obstante, no deja de ser curioso que Windows pueda “hablar” con los antivirus y comprobar su nivel de actualización, pero no sea capaz de comprobar el estado de actualización de programas populares de otros fabricantes (Apple, Adobe, Firefox, OpenOffice, etc.), algo que apunta más a cuestiones de protección de negocio que de dificultad técnica.

Por supuesto, todos estos controles y medidas son muy importantes, pero no considera la medida más importante de seguridad en —al menos— cualquier entorno doméstico, que es la que trasladé a mi audiencia: realizar copias de seguridad. Esto proteje los datos no sólo frente a amenazas cibernéticas, sino frente a desastres físicos, fallos manuales y muchas otras circunstancias indeseables. Excepto suplantación de identidad y robo de información, cualquier otro problema se soluciona con las copias de seguridad.

Estoy seguro de que a estas alturas, la mayor parte de ustedes están pensando en lo obvio que resulta lo que les estoy diciendo. Probablemente mi familia estaba pensando lo mismo. Sin embargo, también estoy seguro de que la mayor parte ustedes están pensando que no tienen copia de seguridad de sus equipos personales, o que ésta se remite a varios meses, siendo optimistas; es una tarea molesta, algo tediosa y no muy habitual para la gran mayoría de la gente. Pero es sin ningún género de duda la más importante.

Así que si tengo que dar una sola recomendación, esta es: ¡Copiad malditos! ¡Copiad!

SQL Injection

—Buenos días, Maestro, hoy vengo a traerte una ofrenda.
—Vaya, una tira cómica de xkcd… son un tanto curiosas.

exploits of a mom

—Sí, ésta la he encontrado en esta noticia de abril sobre un ataque de inyección de SQL. Me ha hecho gracia y se me ha ocurrido traerla como excusa para ver si eres capaz de decirme algo nuevo sobre un tema tan conocido ([1] [2] [3]) y que, sin embargo, sigue dándonos sustos tan a menudo.
—Pues precisamente acabo de leer hace nada otra noticia sobre un ataque a los servidores de MS SQL Server a través del IE7, que parece tener relación. Mira, aquí está. Aunque sé que no hace falta, te traduzco libremente algunas frases:

“[…] otra vulnerabilidad zero-day en un producto de MS. Esta vez es el SQL Server […] el bug de SQL permitiría la ejecución de código malicioso a un usuario autenticado mediante una conexión directa a la BD o también a través de una inyección SQL en una aplicación Web vulnerable […]”

—En la noticia de abril también se habla de inyección de SQL, aprovechando una funcionalidad del Microsoft Internet Information Server (IIS) que llama comandos genéricos, que sólo tiene SQL Server.
—Sí, recuerdo el caso. La vulnerabilidad es una funcionalidad de SQL Server, y eso es lo que permitió que el ataque fuera genérico y por tanto, masivo. Pero la puerta de entrada son las vulnerabilidades en las aplicaciones Web que había en los servidores. El revuelo en ambos casos viene porque la funcionalidad genérica en un caso y el bug en el otro son en productos de Microsoft y permiten ataques genéricos.
—Esto es un sinvivir.
—Claro, el problema es que el software sobre el que descansan nuestras aplicaciones es muy complejo y una vulnerabilidad se cuela con cierta facilidad. Es más, te diría que pasa poco para lo que podría pasar.
—Y, maestro, ¿qué hacemos? Si cambiamos de SGBD (Sistema de Gestión de Base de Datos), tendremos otras vulnerabilidades. No creo que Microsoft sea especialmente peor que los demás.
—Pues no. Lo que pasa es que, muchas veces, no se presta la atención debida a las aplicaciones que se construyen sobre el software de base y no podemos esperar que éste sea invulnerable a cualquier ataque. Además, la entrada se produce porque las aplicaciones Web no están bien diseñadas y programadas. Es decir, que nos dejamos las puertas abiertas. Por ejemplo, todavía no se siguen las reglas básicas para evitar los ataques de inyección de SQL, que, como bien sabes, son…
—Si, claro: “No utilizarás accesos a la BD en tus aplicaciones con privilegios mayores que lo mínimo imprescindible“, “No usarás sentencias SQL dinámicas con variables, sino queries parametrizadas“, “Usarás procedimientos almacenados con cuidado“, “No usaras nombres dinámicos de tablas, salvo en caso de extrema necesidad“…
—Cuando estas cosas hacen falta, vale la pena replantearse el diseño de la funcionalidad que quieres conseguir.
—Y con eso, ¿nos evitamos el riesgo?
—Lo reducimos, lo reducimos. Ya sabes que la seguridad absoluta no existe. Como decía Einstein, sólo hay dos cosas infinitas: el Universo y la estupidez humana… y, de lo primero, no estaba seguro.

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

(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

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

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)

()

—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

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.