La medida más importante de seguridad

23 de diciembre de 2008 Por

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

18 de diciembre de 2008 Por

—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

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.