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

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.

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:

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

(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.

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.

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.

(…)

—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.

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.

—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.