Consultores

Antes de nada, déjenme decirles que esta entrada no está particularmente relacionada con la seguridad; es algo que escribí hace bastante tiempo y que quedó en el olvido. Adelantaré, también, que he sido técnico, en sus diferentes variantes, durante aproximadamente seis años; he llevado móvil de guardia y me han llamado a las tres de la mañana por algo que podía esperar al día siguiente; he soportado a usuarios irritantes, he hecho intervenciones de madrugada y he sufrido incompetencias diversas, además de la mía propia. Por razones variadas e interés, hace algún tiempo cambié el mono de técnico por el de consultoría “barra” auditoría, y aquí estoy. Sirva esto como “disclaimer” previo.

Lo que vengo a responder con esta entrada es a esa sensibilidad bastante acentuada, sobre todo en entornos técnicos, que existe contra la tarea de los consultores; la típica ceja levantada “a lo Sobera” y esa cara de incredulidad que una parte del personal técnico pone cuando le presentan un proyecto de consultoría. Estoy seguro que muchos de ustedes conocen algún chiste sobre consultores. Yo me acuerdo particularmente de aquel del consultor que después de utilizar mil y una sofisticadas herramientas para decirle al pastor cuántas ovejas tiene, éste le ofrece que escoja una como recompensa y el consultor elige al perro en lugar de la oveja, demostrando no conocer en absoluto “el negocio” del cliente. El chiste es bueno, aunque la moraleja sea incorrecta. Seguramente, si ustedes son técnicos, sabrán aún más chistes. De eso precisamente quería hablar: de consultores (no de chistes).

La principal crítica que mucha gente le hace a los consultores es que éstos, tras el cobro de una hipotética cuantiosa suma, simplemente trasladan a dirección lo que el empleado “raso” ya sabe: que hay desorganización, que hay que cambiar esto o aquello o que hay que contratar más gente, entre otras propuestas. Pues ni sí, ni no, pero más “no” que “sí”. Y eso es de lo que viene a hablar este post.

Comenzaré diciendo que a nadie se le escapa que cuando se lleva a cabo una consultoría, parte de los problemas detectados son conocidos por el personal, ya que son muchas veces quienes más los sufren. En algunas ocasiones, como consultor y/o auditor, es más que evidente que las personas te “utilizan” como método de amplificación de sus problemas departamentales: recursos técnicos, personal, manera de hacer las cosas, etc.; eso no es nada malo, siempre que sepa uno discriminar entre una queja justificada y una injustificada. Esta es, sin duda, una de las tareas del consultor: informar de los problemas que parte del personal ya conoce, o al menos percibe. La cuestión que surge entonces es: ¿porqué no podría ser ese mismo personal el que realizase esa tarea de “informador”?

Por una parte, se me ocurre que existe una cuestión básica de estructura corporativa. Saltarse la jerarquía interna puede ser sencillo si se trata de una empresa pequeña, o una grande que posee buenos medios de comunicación, una gestión realmente eficiente de Recursos Humanos, y además, hay muy “buen rollo” (eso es importante). Y aún así, como trabajador y si no es una cuestión de problemas con tu responsable, desaconsejaría este tipo de actuaciones por los problemas que puede traer; el “buen rollo” dura poco si cargas contra la gestión de tu jefe; eso puede traer con facilidad malas relaciones, reticencias y “piques” internos, desconfianza, etc. Y si hablábamos de una empresa pequeña o bien gestionada, imaginen una en la que hay poca flexibilidad y la comunicación entre distintos niveles directivos es rígida y poco eficiente. Dicho de otra forma: el consultor no está restringido por esa estructura interna, y menos cuando viene directamente respaldado (como suele o debería ser) por dirección. Puede hablar con quien quiera, y puede ser franco en sus análisis y conclusiones, sin miedo a que se tomen represalias contra él. Y esto es precisamente una de las virtudes que debe tener cualquier consultor/auditor: independencia.

Por otro lado, y esta es una de esas cosas que no se ven, una persona interna afectada directamente por un determinado problema posee de manera involuntaria e inconsciente un componente importante de subjetividad que con toda probabilidad va a influir en la crítica que hace, algo que una persona externa al departamento, sea una entidad independiente o personal de auditoría interno, no tendrá. Quizá tenga razón y es cierto que exista —por ejemplo— un problema de personal, pero quizá no hagan falta dos personas como él sugiere o pretende que se contraten, sino una persona y una mejora de la gestión interna del departamento. Existen multitud de situaciones en las que cada una de las personas de un departamento aporta su granito de arena al problema; quizá su forma de trabajar, planificar el tiempo o gestionar a su equipo sea parte de la cuestión, y es difícil que vaya a ver eso. En este caso, los análisis del consultor serán más o menos acertados, pero no estarán influidos por cuestiones que le afecten directamente.

Por último, pero no por ello menos importante, un consultor tiene la experiencia de su más o menos dilatada carrera, en la que ha visto muchos más casos que el que tiene delante en ese momento. Por ello es capaz no sólo de abstraerse de los problemas concretos y particulares que observa, y ver el bosque en lugar de únicamente los árboles, sino de aportar soluciones que ha podido comprobar que funcionan en otras organizaciones.

Pero aparte de estos temas, que considero que son más que suficientes, hay todavía un aspecto que es también responsabilidad del consultor: analizar aquellos problemas que el personal interno no conoce o no quiere conocer, bien por “conflicto de intereses”, por comodidad o vayan ustedes a saber qué. Y me refiero a la reticencia y resistencia de las personas y organizaciones a cambiar de forma de trabajar; es complicado que detectemos un problema, y además seamos capaces de identificar (y sobre todo admitir) nuestra parte de culpa en él, si su modificación nos repercute en una forma de hacer las cosas con la que nos sentimos cómodos; se trata de una vertiente distinta de aquello de la paja en el ojo ajeno y la viga en el propio. Los cambios introducen una molestia, una perturbación en nuestra rutina diaria, que aunque a la larga puedan ser buenos, no son bienvenidos. Y en ese punto el análisis de una persona ajena al problema es necesario, porque no tendrá que escoger entre las molestias de cambiar de forma de trabajar y las mejoras que eso le supone a la organización. En definitiva, y sin entrar en cuestiones filosóficas, a menudo vemos lo que queremos ver, tanto queriendo y sin querer; las personas estamos tan metidas en nuestra rutina diaria que nos cuesta ver qué hacemos mal y además, asumirlo y cambiar nuestra forma de trabajar.

En la línea de la crítica de que al consultor se le paga por decir algo que ya se sabe, hay que añadir que el consultor no sólo “dice”, sino que lleva detrás un trabajo bastante más elaborado, en el que se encarga de mantener unas reuniones, analizar la información recabada y generar unos informes, algo que lleva tiempo. En realidad, gran parte de las personas que son críticas con la tarea de los consultores se negarían a realizar esa tarea, porque no les gusta, les supondría enfrentamientos con personal interno, y porque eso les supondría una carga de trabajo adicional. Seguramente muchos sabemos cómo cambiar un tubo fluorescente fundido, pero cuando eso pasa en el trabajo, salvo raras excepciones (o necesidades de orden mayor), no lo hacemos; llamamos al electricista. Al fin y al cabo, ese no es nuestro trabajo, no nos gusta, no queremos problemas con el de riesgos laborales, y si al final hay algo más que un tubo fundido, no sabremos qué hacer.

Es así de simple, más o menos.

Errores comunes en la Implantación de un SGSI

Implantar un Sistema de Gestión de Seguridad de la información se está convirtiendo cada vez más en un objetivo para los departamentos TIC de las empresas. Los que nos dedicamos a hacer consultoría para la implantación de esos SGSI vamos poco a poco viendo que los problemas que nos encontramos en un cliente se repiten, al menos parcialmente, en el siguiente, y que los clientes asumen erróneamente afirmaciones para nada ciertas lo que hace que cuando se tropiezan con la realidad, haya alguna sorpresa.

Plantearé hoy tres de los errores más comunes asumidos por algunas de las empresas que deciden implantar un SGSI:

‘CONTRATO A UNA CONSULTORA Y ELLOS LO HACEN TODO’

Esta suposición no es válida en la implantación de ningún Sistema de Gestión, pero menos si cabe en un SGSI. Como en cualquier proyecto de similares características, es imprescindible la colaboración de muchos miembros de la plantilla de la empresa para arrancar y llevar a buen puerto el diseño y la implantación de un Sistema de Gestión que trata de protegerla información crítica para el negocio, ya que hay muchos departamentos y perfiles que trabajan a diario con esa información que se busca proteger; al fin y al cabo, son ellos los que mejor conocen la organización. Por ello, para que la empresa consultora pueda hacer un buen análisis de riesgos va a requerir colaboración por parte del cliente para identificar los riesgos, analizarlos y valorarlos, seleccionar las opciones para su tratamiento, y para implantar el plan de tratamiento de riesgos con el que se pretende mitigar el nivel de riesgo detectado. Tampoco hay que dejar de lado que la organización ya dispondrá en muchas ocasiones de controles de seguridad que en ocasiones serán suficientes, y en otras será necesario ampliar.

Si bien los consultores deben invertir muchas horas en darle forma el sistema, la organización debe invertir bastantes horas en proporcionarles la información que necesitan para hacer un buen diseño y en ejecutar las tareas que se identifiquen como necesarias para llevar a cabo su implantación. Hay casos en los que también se contrata a la consultora externa la implantación de los controles seleccionados pero suelen ser los menos, así que en la mayoría de los casos es la organización la que debe ir implantando la lista de controles seleccionados y no implantados inicialmente. Esta lista puede ser muy corta pero también muy larga, depende de la situación de partida de la organización desde el punto de vista de la seguridad.

Sin embargo, antes de pasar al siguiente error, tampoco es bueno pecar de pesimista: no hay que olvidar que la implantación de un SGSI en ocasiones (no siempre) no es otra cosa que la documentación y procedimentación de controles, tareas, rutinas, formas de trabajar que la organización ya conoce, en definitiva, la formalización de un sistema de gestión con el que hace tiempo que “se siente a gusto”. Dicho de otra forma, y aunque les parezca obvio, el trabajo que tendrá que abordar la empresa en el momento de la implantación del SGSI será inversamente proporcional al trabajo que hasta ese momento haya realizado en la gestión de su seguridad. En ocasiones ese esfuerzo será significativo, y en otras, más bien poco.

‘ESTE PROYECTO SÓLO CONCIERNE AL ÁREA TIC’

Otro gran y común error. Ya que como hemos comentado, se trata de proteger la información crítica para el negocio, en el proyecto se deben ver involucradas personas de muchas áreas: Departamento TIC (por su puesto) pero también RR.HH, Departamento financiero, Departamento legal, Departamento de Marketing y todos aquellos que trabajan con esa información crítica para el negocio que se va a proteger. Todos deben ser conscientes de qué papel juegan ellos en el SGSI implantado, cómo de crítica es para el negocio la información con la que trabajan a diario y de qué modo debe cambiar su forma de manejarla para garantizar que se encuentra debidamente protegida. Por supuesto, se les debe preguntar, explicar y escuchar, antes de decidir los controles que se van a implantar y que les va a afectar, ya que de lo contrario se corre el riesgo de que perciban las nuevas normativas o políticas que se van a definir en materia por ejemplo de contraseñas, control de acceso, destrucción de información, uso del correo electrónico, instalación de software, etc, como un mero capricho del área TIC a las que no encuentran ningún sentido y que simplemente perciben como muy engorrosas.

‘SE VAN LOS AUDITORES Y YA HEMOS TERMINADO’

Normalmente, cuando se van los auditores también se van los consultores externos y eso significa que la empresa se queda con su certificado y ‘sola ante el peligro’; en unas organizaciones, eso supondrá que ha llegado la hora de la verdad: de comprobar cómo de bien planteado está el SGSI y de ver si es operativo. En otras, ese ‘peligro’ no será tal; la obtención del certificado no significará otra cosa que el premio y la aprobación externa de un sistema de gestión de la seguridad que la organización ya había asumido como propio, como ventajoso y positivo para su negocio antes siquiera de plantearse la obtención del sello de una entidad acreditada.

Obviamente, siempre será responsabilidad de los consultores haberse asegurado de que el SGSI diseñado, bien a partir de un sistema de gestión ya en funcionamiento, bien a partir de la nada, es adecuado para la empresa en la que se ha implantado. Eso significa que debe ser fácilmente operable, acorde al tamaño de la organización, de su presupuesto y de los recursos que se pueden asignar a su mantenimiento.

Muchas veces, cuando se parte de una organización casi ‘virgen’ en la gestión de la seguridad de la información, se puede pecar de querer diseñar un super-SGSI, sin tener en cuenta que tras el proceso de implantación, las personas que se han visto involucradas recuperan sus tareas diarias, y la prioridad del SGSI baja unos cuantos niveles respecto a estas otras tareas. Obviamente la existencia de un SGSI en una organización sin una gestión de la seguridad previa requerirá un esfuerzo: mantener al día su inventario de activos, hacer un seguimiento de las no conformidades, obtener los datos para medir la eficacia de los procesos, analizar la información que de ellos se desprende, mantener al día los documentos y registros, es decir, ejecutar todas las tareas que implica un SGSI. En cualquier caso, el reto de lograr un SGSI bien diseñado será lograr que, cuando no lo están ya, los procesos que conlleva se integren de manera lo más transparente posible en el funcionamiento de la organización. A veces, este es casi el punto de partida; en otros casos, la meta está un poco más lejana.

Con esta entrada no pretendo desanimar a nadie, ni mucho menos, sólo señalar aspectos obvios: que la implantación, y sobre todo el mantenimiento de un SGSI es una tarea continua, del día a día, en la que se deben involucrar a varias personas de la organización, se le debe dotar de los recursos y presupuesto necesario, y que debe contar con el apoyo de la alta dirección para tener garantizado su éxito. Nada, desde luego, diferente de lo que cualquiera podría esperar de un sistema de gestión, sea cual sea.

WWW. Una ventana al mundo, una ventana para los intrusos

A menudo las organizaciones securizan su dominio protegible implantando una serie de controles tecnológicos que permiten impedir o en todo caso minimizar el impacto de actividades ilícitas por parte de terceras personal, o incluso las realizadas por el propio personal corporativo. Instalación de cortafuegos perimetrales, software de detección y eliminación de malware, proxys, sistemas de detección de intrusos y un largo etcétera, serían algunas de las medidas empleadas.

En este momento el responsable de TI de la organización siente una falsa sensación de seguridad, ya que descuida, entre otras cosas, las posibles vulnerabilidades latentes en el software de los servicios de DMZ. Normalmente estos servicios perimetrales (servidores de correo, DNS…) se sustentan en software de amplia distribución y con un soporte de actualizaciones de seguridad pero, ¿qué ocurre con la pagina web corporativa? Estos sites que ofrecen la imagen y la marca de la organización al resto del mundo son desarrollados de forma personalizada, sin un soporte, muchas veces, de actualizaciones de seguridad. Si quieres que corrija estos errores, paga el esfuerzo que requiere ese desarrollo adicional. Sí, esta frase es bastante común, dado que este tipo de situaciones no se contemplaron en el alcance del proyecto, ni se requirió que el desarrollo siguiera un marco de trabajo de desarrollo seguro.

En bastantes de las auditorias y test de intrusión de aplicativos web que S2 Grupo ha realizado, no sólo se obtuvo el control del site auditado (acceso a insertar modificar o eliminar el contenido de la web), sino que se pudo obtener numerosa información confidencial (credenciales de acceso a zonas privadas, números de cuenta bancarias, cuantas de correo electrónico, documentos confidenciales de la organización…), sin comentar la posibilidad de realizar ataques de phishing y robo de sesiones. Todo ello tan sólo a través de la página web de la corporación, esa ventana al mundo accesible desde el sitio más recóndito del planeta.

Para hacerse una idea de los potenciales puntos de entrada que un intruso tendría a través de la web basta con tener en cuenta el conjunto de parámetros POST y GET de los posibles recursos dinámicos (jsp, asp, php, cgi’s…), así como cookies o cualquier otro tipo de información que sea enviada desde el cliente para que el servidor la procese. En un site de tamaño medio donde su funcionalidad sea informativa y presente una zona privada, el total de puntos de entrada del atacante es inmenso.

He aquí el papel relevante que juega la seguridad en este tipo de servicios, y que en general se tiene totalmente descuidados. Pero, ¿cómo es posible mitigar estos riesgos? Pues aplicando principalmente dos estrategias:

  • Usar un Framework de desarrollo seguro que se integre en el ciclo de vida de desarrollo del software.
  • Realizar auditorias de seguridad, preferiblemente con test de penetración, cuyo alcance abarque tanto el análisis de las vulnerabilidades de la web como los permisos de la base de datos que la sustenta (en caso de que use, claro). Este último punto es de vital importancia porque en numerosas ocasiones los permisos del usuario de la BD que la aplicación utiliza son inadecuados, permitiendo obtener información que no tendría porqué ser accesible. Recordar que siempre hay que aplicar la máxima del mínimo privilegio.

A todo esto cabe añadir que las aplicaciones en general tienden cada vez mas a desplegar su interfaz gráfico hacia la web, e incluso programas típicos de edición de texto como Microsoft Word tienen sus homólogos en la web (ver Google Docs). Dado el auge de esta tendencia y la escasa preocupación por la seguridad de estos servicios, nos lleva hacia un panorama desolador e inseguro, haciendo necesaria la aplicación de controles preventivos y reactivos, que mitiguen estas amenazas para las organizaciones y usuarios particulares.

Pero, ¿quién tiene la responsabilidad de que estos fallos permitan al intruso acceder a la información confidencial? Indudablemente para mí, el programador web, que a menudo es contratado sin experiencia, no solo en seguridad sino en cuanto a skill de programación se refiere, por empresas que lo único que quieren es obtener un producto en poco tiempo, bonito y que cumpla las especificaciones requeridas por el cliente; preocupándose por la funcionalidad y descuidado el rendimiento y la seguridad de su plataforma. ¿Sería conveniente aplicar algún tipo de castigo? Una de las medidas que el equipo de auditoria del ACE Team de Microsoft aplica sobre sus proyectos de desarrollo es penalizar a los jefes de proyecto y programadores que desarrollen de forma insegura, reduciendo el presupuesto de sus proyectos según el número y grado de vulnerabilidades encontradas. Sería una opción a considerar.

Al respecto, y en la línea de lo comentado, la encuesta de esta semana es la siguiente:

[poll id=”10″]

* * *

(N.d.E.) En relación con la encuesta anterior, cuyo resultado les muestro debajo, ha quedado claro (siempre teniendo en cuenta el ámbito en el que nos movemos y el público de este blog) que en general, la preocupación por los datos gestionados por las (empresas propietarias de las) redes sociales es legítima y compartida por gran parte de nuestros lectores.

[poll id=”8″]

Destructoras de medios

NIST-SP 800-88 [pdf], Guidelines for media sanitization, define cuatro tipos de “sanitización” (perdón por la traducción inventada, pero no quería decir “saneamiento” o algo así) de medios: la eliminación (no hacemos nada especial, simplemente nos deshacemos de la información, por ejemplo dejando el papel en un contenedor para reciclar), la limpieza (borrado de datos básico), el purgado (borrado avanzado) y la destrucción.

Centrándonos en el último de los anteriores tipos, las destructoras de medios físicos (papel, discos duros, tarjetas de crédito, DVDs…) constituyen un control de seguridad básico a día de hoy en organizaciones de todo tipo: desde una PYME o un autónomo, a las grandes multinacionales. Y es que, conforme la información adquiere cada vez más valor para nosotros, obviamente más preocupados estamos porque los soportes que contienen esta información no lleguen a manos ajenas.

Para la información en formato papel o plástico (esto incluye los diskettes, discos compactos y DVDs, entre otros), hoy en día casi todos disponemos de destructoras en nuestra oficina o incluso en nuestras casas (existen destructoras de papel por menos de cincuenta euros para uso doméstico… eso sí, ni se os ocurra meter ahí un DVD para destruir). A nivel profesional, es muy importante disponer de una destructura de este tipo, de gran capacidad y de corte fino o cruzado (las domésticas suelen tener el corte de papel más grueso, por lo que el documento es más fácil de recuperar; incluso en el caso de hojas de cálculo, es trivial por la coincidencia de los cortes con las filas y columnas).

Las alternativas a estas destructoras de medios suelen pasar, en especial en el caso del papel, por la contratación de servicios externos de recogida y destrucción: periódicamente nos dejan en la oficina una especie de buzones cerrados y precintados en los que depositamos toda la documentación sensible, y que posteriormente son recogidos y destruidos por la empresa que nos presta el servicio. A título personal (insisto, personal, así que por favor, que nadie que trabaje en este tipo de empresas ponga el grito en el cielo) siempre he preferido una salvaguarda que me garantice directa y técnicamente la destrucción de los medios que una salvaguarda que me garantice esto mismo de forma contractual. Llamadme desconfiado, pero es mi opinión.

El caso de destrucción de discos suele ser más peliagudo que el de otros medios; como todos sabemos, para eliminar la información de discos duros existen diferentes mecanismos: desde el borrado o la sobreescritura convencionales (con los problemas que esto implica, y que ya sabemos) hasta la desmagnetización o la destrucción física de los discos, métodos con más garantías pero que, por contra, no permiten la reutilización del medio. Poca gente dispone de destructoras de discos duros (haberlas haylas, pero son caras), por lo que al final en muchos casos se suele optar por diferentes métodos para proteger la información:

  • Formateo. Obviamente, aproximación incorrecta y que permite una recuperación relativamente sencilla de los datos.
  • Borrado seguro. Eliminación de los datos siguiendo algoritmos de borrado seguro, basados en secuencias concretas de sobreescritura de los sectores. Aproximación segura pero costosa en tiempo, por la lentitud de los algoritmos.
  • Destrucción “manual”. Simplemente desensamblamos el disco, destruímos la electrónica, lijamos (por poner un ejemplo bruto) los platos y los partimos en N trozos. Aproximación segura para el 99.999% de los mortales :)

Sea como sea, es crítico destruir convenientemente cualquier soporte de información; pero no únicamente destruirlo, sino también mantener su seguridad durante su tiempo de vida. Ya hemos hablado del cifrado de medios y de los problemas que podemos tener si “perdemos” un pendrive USB; si el soporte a desechar está cifrado, no tenemos por qué perder tiempo en su destrucción o purgado… pero por desgracia no siempre es posible cifrar todo.

De charlas va el tema

A continuación les muestro las presentaciones de dos charlas realizadas por Antonio Villalón, la primera de ellas ayer mismo en la jornada “La Seguridad y Fiabilidad Informática Factor Clave para el Crecimiento de las Empresas” organizada por el Instituto Tecnológico de Informática de la Universidad Politécnica de Valencia, y la segunda el pasado 18 de diciembre, en el ciclo de charlas técnicas del chapter ISACA de Valencia. Espero que les resulten interesantes. En cualquier caso, buen fin de semana a todos.

[Read more…]

Security Art Work

Como sabrán si visitan blogs de manera asidua, cualquier blog que se precie está obligado a dedicar una parte de sus entradas a mirarse el ombligo, o si quieren llamarlo así, a publicar “metaentradas”, cuya única finalidad es hablar del propio blog. Puesto que en los casi 2 años que llevamos de vida apenas nos hemos dado palmaditas en la espalda, y aprovechando la actualización e instalación del WordPress y diversos plugins, he creído conveniente aprovechar esta entrada para que Security Art Work hable de sí mismo.

En cifras, desde el pasado 25 de abril de 2007 llevamos publicadas un total de 220 entradas, sin contar la presente, que han recibido un total de 284 comentarios, es decir una media de 1.29 comentarios por entrada, valor que, todo sea dicho, es francamente mejorable. Si nos vamos a las estadísticas, aunque durante su comienzo los números fueron bastante modestos, lo cierto es que durante los últimos meses Security Art Work ha experimentado un apreciado incremento de suscriptores y visitantes, especialmente a raíz de la aparición en portada de menéame de la entrada sobre la rotura de WPA/WPA2 anunciada por Elcomsoft; tampoco crean que estamos hablando de un aumento impresionante, tal y como verán en las gráficas de debajo.

A partir de los datos de Feedburner (i.e. Google), la gráfica de suscriptores es la siguiente (la caída a mediados de enero fue provocada por un error de Google en la migración de feeds a sus sistemas):

Suscriptores

Mientras que esta es la gráfica de visitas, sacada de Google Analytics:

analytics

Esos son los números de Security Art Work. Como editor y principal colaborador del blog, mi opinión es que el margen de mejora tanto de visitantes/lectores, incluso manteniendo las cifras en una escala “modesta”, es todavía inmenso, y lo mismo puede decirse de la frecuencia de publicación del blog; cada tres días aproximadamente ha habido una nueva entrada, y aunque puede verse como el vaso medio lleno, me permitirán que me quede con el vaso medio vacío. Al fin y al cabo, ya saben que como dijo Antonio Mingote, un pesimista no es otra cosa que un optimista bien informado.

Para acabar, les dejo con una encuesta, que actualizaré cada jueves y a la que podrán acceder a través de la entrada en cuestión y a través de la columna de la derecha. Naturalmente, tras esta breve pausa retomamos nuestra programación habitual, más y mejor si cabe.


[poll id=”3″]

BlackBerry (in)security?

Durante las últimas semanas se ha venido hablando acerca de la “adicción” del presidente electo de los Estados Unidos, Barack Obama, a su BlackBerry, y la negativa de la NSA (National Security Agency) a que siga utilizándola durante su mandato; según se ha publicado, parece que Obama llegó a declarar que le tendrían que arrancar su BlackBerry de las manos -imagino que en tono coloquial, dicho sea de paso-, ya que el servicio secreto de los Estados Unidos considera inseguras las comunicaciones realizadas mediante BlackBerry.

El de Obama no es el único caso en el que el uso de estos dispositivos se prohíbe de forma tajante a aquellos que puedan manejar información altamente confidencial; hace algo menos de dos años, el gobierno francés prohibió también a sus altos funcionarios el uso de BlackBerries, por el mismo motivo (un tema del que también se hicieron eco muchos medios). Pero… ¿es esta medida justificada, o por el contrario podemos considerarla desproporcionada?

Bajo mi punto de vista -ojo, y no soy ni de lejos un experto en la seguridad de BlackBerry-, cuando la NSA suena, agua lleva; dicho de otra forma: si el presidente no puede utilizarla por motivos de seguridad, por algo será. Pero de ahí a considerar la seguridad de BlackBerry como algo prohibitivo para el resto de mortales -que por suerte o desgracia no solemos manejar información crítica para la estabilidad mundial- hay un abismo; configurando adecuadamente diferentes parámetros del dispositivo, se puede conseguir un nivel de seguridad más que aceptable para el 99.999% de las personas que lo usan.

Así, el hecho de que Obama no pueda manejar su BlackBerry por motivos de seguridad, no implica que el resto del mundo deba hacer lo mismo; al final, como siempre, se trata de una cuestión de riesgos a asumir: el servicio secreto no asume ese riesgo en el caso de comunicaciones secretas, lo que no implica ni de lejos que el Departamento de Seguridad de la mayoría de organizaciones deba recomendar no asumirlo. Especialmente, si tenemos en cuenta las necesidades de movilidad del negocio, y las alternativas a BlackBerry que existen en la actualidad; una de ellas, aprobada oficialmente por la NSA para transmisión de datos clasificados, es Sectera Edge, de General Dynamics. Eso sí, preparemos una buena cantidad de dólares (o de euros) si queremos comprarla: casi 3.000 euros por unidad… Como casi siempre, una cuestión de dinero.

Si como consultor me preguntaran acerca de la seguridad de BlackBerry para las comunicaciones de Barack Obama, seguramente recomendaría no utilizar este dispositivo; si me preguntaran acerca de la seguridad de BlackBerry para las comunicaciones del Director General de Plásticos Cremallera o Piruletas de Motilla del Palancar, probablemente recomendaría su uso siempre que se apliquen las medidas de seguridad habituales (configuración correcta, actualización, etc.). Seguramente, la competencia de ninguna de estas dos empresas tiene la capacidad ni los recursos para interceptar y descifrar las comunicaciones de ambos directores generales.

¿Cómo determinar si el uso de BlackBerry es un riesgo inaceptable para nuestra organización, o si por el contrario vale la pena asumirlo y no aplicar alternativas tan caras? Sin duda, podríamos hablar de análisis de riesgos, estudios, estadísticas… para llegar a una u otra conclusión, pero en este caso, y siempre IMHO, hay una primera aproximación muy útil: si una persona necesita más de dos guardaespaldas de forma simultánea, quizás debamos plantearnos alternativas a BlackBerry. Otro ejemplo de convergencia de la seguridad :)

Seguridad y riesgos en las TIC (III)

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.

¡Esto es un escándalo!

Hoy he desayunado leyendo la última entrada de Enrique Dans en su blog, llamada “Trucos para quien depende de Gmail“. En la línea de sus aportaciones habituales, con las que se puede estar más o menos de acuerdo, Enrique aboga por el uso de Gmail para el usuario corporativo, diciendo que:

En las empresas, Gmail ha provocado más de una discusión: no son pocos los directivos y trabajadores que, hartos de las limitaciones de su correo corporativo (de tamaño, usabilidad, acceso remoto, etc.) deciden un día redireccionarlo a una cuenta de Gmail y gestionarlo desde ahí, lo que provoca no pocos escándalos entre responsables de tecnología preocupados por la seguridad y la confidencialidad (escándalos, desde mi punto de vista, completamente estériles e injustificados… desde mi experiencia, es una práctica que recomiendo a cualquiera: Google siempre será capaz de gestionar tu correo mejor de como lo gestiona tu empresa, que no se dedica a esos menesteres como actividad principal).

Creo que no hay nada que añadir al respecto; se siente uno como una pequeña rata de laboratorio paranoica, aunque le queda el consuelo de saber que no lo es. Es razonable que algunas personas piensen, por ejemplo, que la LOPD es excesiva, pero el Reino Unido está empeñada en darnos la razón a los que decimos que no lo es, cuando millones de datos van y “se pierden”. También es razonable pensar que los webmails de Hotmail, Gmail o Yahoo! son sistemas seguros, pero casos como el de Sarah Palin nos dan la razón de que no lo es. Tampoco hay que olvidar las repercusiones de la LOPD en este tipo de servicios; el correo electrónico hoy en día no es sólo un sistema de comunicación electrónica: es también (y cada vez más) un repositorio de documentación. Documentación que incluye datos de carácter personal, informes confidenciales, contratos, ofertas, y muchos otros contenidos de todo tipo. Entiendo la motivación de Enrique Dans, pero es obvio que no la comparto y para ser sincero, me parece una insensatez y jamás la recomendaría a nadie, por muchas razones.

Para acabar con esto, me resulta curioso la mención de que Google gestionará tu correo mejor de lo que lo gestiona tu empresa, cuando un servidor de correo de tamaño medio no es algo tan difícil de gestionar, pero dejémoslo ahí. Si van a la entrada original, encontrarán opiniones a favor y en contra. Aquí (y allí) tienen la mía, ahora háganse la suya.

* * *

En relación con la anterior entrada, el “problema LOPD” de los Palotes de Chiclana, admito que no he dado demasiado tiempo para posibles respuestas, pero creo que el problema no era demasiado complejo. Primero he de decir que la recepcionista, María Antonia Ruíz Pérez, es empleada de Palotes, para no complicar las cosas, y no meternos en rollos de encargados del tratamiento y similares. Y en segundo lugar tengo que decir que el problema admite diversas interpretaciones, y probablemente tenga más de una solución válida; yo personalmente no me siento legitimado para decir que una solución es más correcta que otra, por lo que deberán considerar esta “solución” como mi opinión personal, y en este caso coincido con Javier Cao. Si hubiese alguna discrepancia o error con lo que sigue, les ruego que me lo digan.

Como indicaba Javier, existe una resolución específica en relación con el control de acceso a edificios, la 1/1996 [pdf], que en su norma quinta, “Cancelación de los datos”, especifica que “Los datos de carácter personal deberán ser destruidos cuando haya transcurrido el plazo de un mes, contado a partir del momento en que fueron recabados“. Aunque ésta hace referencia a la LORTAD, y existe una cierta concurrencia de instrucciones con la 1/2006 sobre videovigilancia (pdf) (ver Félix Haro), no se encuentra derogada, y ha sido referenciada en resoluciones de la AEPD posteriores a la LOPD.

Por tanto, tenemos que disponemos de un fichero con una finalidad muy clara (control de acceso) y para el que existe una directiva específica de la AEPD, y al que queremos darle otra finalidad adicional (confirmación de la firma del compromiso de confidencialidad), pero cuyos plazos de conservación son claramente incompatibles. Yo, como Javier, me inclino por un segundo fichero, dado que al mantener el mismo fichero con ambas finalidades, estaríamos incumpliendo la citada directiva. Y esa es, en mi modesta opinión, la solución más apropiada.

En cualquier caso, se admiten correcciones, recursos, y quejas; sólo me queda dar gracias a los participantes y aunque no hay premio, quizá un día les pueda invitar a una cerveza.

Irresponsabilidad Corporativa y Mal Gobierno

Ahora que está tan de moda la Responsabilidad Corporativa y el Buen Gobierno (ver la reciente entrada de José Rosell), parece que los eventos que estamos viviendo a nivel mundial se empeñan en demostrarnos que éstas brillan por su ausencia, o que al menos se están entendiendo más como una moda o una cuestión de imagen de cara a la galería, que como un compromiso real. Sólo así se entienden hechos como el desplome financiero de grandes (y hasta hace poco, reputadísimas) entidades financieras que han incurrido en situaciones de riesgo operacional tan irracionales como irresponsables, o problemas como los que está sufriendo Islandia. Estos acontecimientos hacen cada vez más patente la necesidad de supervisión y control interno real en las organizaciones, y remarcan la necesidad (y al mismo tiempo, su insuficiencia) de la existencia de leyes como la SOX; evidentemente mejorables, pero imprescindibles.

Aunque también habría que implantar controles relacionados con la Responsabilidad Moral o Ética para algunas de estas empresas y sus directivos, pero para esto, así a bote pronto, me cuesta más plantearme el diseño de los controles. Discúlpenme, pero necesitaba desahogarme.