Plan de continuidad de negocio

6 de abril de 2009 Por

La semana pasada cogí el autobús de línea para ir a visitar un cliente, vehículos que vienen equipados con diversos sistemas informáticos que generan o cancelan los billetes electrónicos. En concreto, este autobús tenía una canceladora automática de bonos de transporte y una impresora de los billetes individuales, pero sin embargo ninguno de los dos sistemas funcionaba, y estaban completamente “muertos”.

La empresa de transporte dispone de un plan para estas ocasiones, con el cual se asegura que las “cosas” sigan funcionando. En este caso, el conductor dispone de una troqueladora manual de bonos, y de un taco de billetes preimpresos, preparados para una situación como la que nos ocupaba. Esto implica que una caída total de los elementos informáticos no impide que se puedan cobrar los viajes del autobús.

Hay que admitir que a la vista de la situación, tampoco es que fuera todo sobre ruedas; al conductor se le veía bastante sofocado con el problema, y en cada parada le costaba algo más cobrar los tickets y cancelar los bonos, pero en fin, el “negocio” siguió funcionando. También hubo un momento en el que tuvo que revisar los números de los tickets y revisar la caja que tenia. Finalmente, probablemente a título personal y ante la presión, decidió optar por una estrategia más radical y no aceptar pasajeros nuevos. Esto puede considerarse como una opción válida, al encontrarse el sistema bajo mínimos, y teniendo en cuenta que aunque no abrir las puertas es una pérdida de nuevos clientes, el retraso que en cada parada se acumulaba incidía también en la calidad del servicio y la percepción por parte de los clientes “captados”.

Este sencillo ejemplo es una muestra de que mecanismos manuales como “los de siempre” pueden ser un plan B efectivo que supla la falta de disponibilidad temporal o fallos de las infraestructuras tecnológicas, aunque como sucedía en este caso el personal debe conocer los procedimientos, y estar formado en ellos. Cualquiera de nosotros puede observar cómo las cada día más fiables y sofisticadas tecnologías nos hacen también cada vez mas dependientes, lo cual no debe hacernos olvidar que prácticamente cualquier cosa en la vida puede fallar, algo que el responsable del negocio debe tener previsto y preparar a la organización para ello.

Por último, es obvio que yo era uno de los clientes “captados”, pero mientras el resto del autobús estaba bastante molesto con la situación, yo estaba disfrutando del viaje, analizando el incidente y la ejecución del plan de continuidad del autobús.

El incidente (misconfused)

2 de abril de 2009 Por

(La entrada de hoy es la segunda colaboración de Francisco Benet, un amigo de algunos de nosotros —y familia de algún otro— que tiene gran experiencia en la gestión e integración de sistemas, protección de datos de carácter personal y evaluación de soluciones de integración de software y hardware, entre otros aspectos. Esperamos que les guste.)

Hace algo más de un lustro me enfrente a una situación un tanto extraña en el área de Sistemas de la organización para la que trabajaba, y que les describo a continuación (NOTA: parte de la situación descrita es ficción, para dar dramatismo y mayor realidad a la historia; no crean todo lo que leen).

[Read more…]

Consultores

31 de marzo de 2009 Por

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

29 de marzo de 2009 Por

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

26 de marzo de 2009 Por

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″]

Yo, Bicho.

24 de marzo de 2009 Por

Algunos me llaman Kido, otros Disken, aunque puede que el nombre que me haya hecho más popular sea Conficker. En realidad no importa, sólo son nombres que me dan aquellos que me buscan para destruirme. Mi auténtico nombre es algo que, como mi creador, permanece oculto.

Soy un bicho, y esta es mi historia.

Nací hace algunos meses en un garaje de algún lugar del mundo, tras bastantes horas de esfuerzo. Allí mi creador me explicó lo que sería mi misión, y me transmitió el secreto que me permitiría avanzar entre los enemigos. “Busca el 445” me dijo, ese era el camino.

Una vez en la red, me apresuré a buscar ese 445 que me iba a permitir explorar este mundo que se abría ante mi. Desgraciadamente hoy en día los 445 no se exhiben así como así, sino que se encuentran bien guardaditos, al menos de puertas hacia fuera. Tenía que haber otra manera de pasar esas malditas puertas. Tras un par de vueltas a la cabeza y un par de copas en el bar de Blaster (sí, ese que montó tras retirarse) conocí a un bicho que aseguraba conocer el secreto para que Internet Explorer le abriera las puertas. No tenía nada que perder, así que decidí colaborar con él. Nos metimos en un disfraz de JPG y me dijo que me estuviera quieto y callado, y nos apresuramos a reenviarnos a tantos buzones de correo como pudieramos, con la esperanza de que alguno de ellos no se percatara de la trampa hasta que fuera demasiado tarde.

Pasadas unas cuantas horas y visitar algunos usuarios domésticos, alguien nos descarga desde su buzón de GMail, y al abrir la imagen… mi compañero cumple su palabra, me saca del disfraz y me libera para que prosiga con mi misión.

Miro a mi alrededor y efectivamente he pasado una de las puertas, estoy en un equipo edición profesional, y me pregunto como es posible que en estas empresas permitan que los usuarios consulten el correo de GMail o cualquier otro webmail público sin ningún tipo de restricción. Mejor para mí, ya estoy dentro…

Desde aquí puedo ver un montón de 445’s de equipos que tampoco tienen activados los cortafuegos personales. Me pregunto si tiene alguna utilidad que entre equipos de usuario este puerto sea accesible, además de servirme a mi para mis planes, o si la palabra “segmentación” y “filtrado” le dice algo a esta gente. Intento avanzar de equipo a equipo, consiguiéndolo en la mayor parte de ellos; a los usuarios (y a algunos administradores) no les gusta eso de aplicar parches de seguridad, de lo contrario ni siquiera hubiera podido pasar del Internet Explorer. El caso es que tengo un montón de equipos en los que andar a mis anchas.

En muchos de ellos están también aquellos que buscan destruirme, pero no me conocen, no saben cómo soy, y somos demasiados procesos como para que se den cuenta del tipo de acciones que estoy realizando.
Me copio en disco, bien escondido, y también en tantos dispositivos USB como encuentro, así si soy destruido mientras prosigo con mi misión, otro ocupará mi lugar.

Parece que finalmente he sido descubierto. Tanto andar a mis anchas de un lado para otro hace que todo vaya más lento; quizá la próxima vez debería ser más sigiloso. Han venido unos tipos y han capturado a varios de los nuestros, me preocupa que puedan interrogarlos y conseguir averiguar todo lo que saben sobre la misión. Mis peores temores se han hecho realidad, estos tipos de antes han debido avisar a aquellos que quieren destruirnos, porque ahora de repente nos reconocen, y saben cómo y dónde nos escondemos. Intentamos huir pero el 445 ya no me muestra el camino, no tengo escapatoria. Poco a poco, todos los compañeros caen, tras varios días de intensa batalla.

Parece que mi corta vida ha llegado a su fin, pero esto no va a quedar así. Volveré… Y estaré siempre un paso por delante de ti.

Ley Nokia

23 de marzo de 2009 Por

Hace ya unos días apareció en prensa una noticia que me parece interesante comentar. El titular es bastante efectista: “Los jefes podrán controlar el correo electrónico de los empleados (…)”.

La noticia recoge la aprobación en Finlandia de la conocida como “Ley Nokia”, debido a que fue esta empresa la que desde hace un par de años ha estado presionando al gobierno finés para que se modificara la ley de protección de las comunicaciones electrónicas, y que así una empresa u organismo público pudiese investigar el uso que del correo electrónico hacen sus empleados. El revuelo consiguiente es comprensible, tanto en un sentido como en otro, y es fácil encontrar opiniones que justifican la medida y otras que piden el boicot a la marca y que nadie se vuelva a comprar un Nokia en su vida…

En este país tenemos ya alguna sentencia del Tribunal Supremo que ha unificado doctrina al respecto, y que por un lado reconoce el derecho a la privacidad del trabajador en el uso de los recursos corporativos que una empresa pone a disposición de sus empleados, y admite un uso privado “racional” de los mismos, como no podía ser de otra forma. ¿O es que no puede uno/a llamar a su pareja con el teléfono de la oficina? Lo que ya no está tan claro es que lo hagas si tu pareja está en Buenos Aires pasando unos días de vacaciones y te tires 40 minutos hablando… de ahí lo de “racional”. Trasladen todo esto al uso del correo electrónico, el uso de Internet, el uso del PC que uno tiene asignado, etc.

Pero por otro lado, la sentencia reconoce el derecho del empleador, en consonancia con el artículo 20.3 del Estatuto de los Trabajadores, a controlar el uso que de dichos recursos hacen sus empleados, aunque con unas determinadas premisas:

  • Que el ejercicio de esa potestad de vigilancia se lleve a cabo respetando la dignidad del trabajador y su intimidad, teniendo en cuenta que se debe tolerar el uso personal racional y moderado de los recursos corporativos.
  • Que el empleador defina previamente las “reglas del juego”; es decir, qué se puede y qué no se puede hacer con ellos.
  • Que informe de las medidas y herramientas de control y auditoría que se van a utilizar.

Y es ahí donde normalmente, por mi experiencia, las empresas fallan. Muchas veces se han definido las reglas de uso de esos medios, y se han implantado herramientas de filtrado de contenidos, pero… ¿se ha informado de ello convenientemente a los empleados? Normalmente no. Como mucho, en algunos casos, esas normativas de uso, que raramente han sido aprobadas de manera formal por la dirección, que se han elaborado con la mejor de las intenciones desde el área TIC pero no se han consensuado con RRHH, y que están perdidas en algún apartado escondido de la intranet corporativa, nunca llegan a sus destinatarios (sólo en extraños casos en los que el empleado acaba aterrizando por allí y las lee, si es que está muy aburrido).

Sólo cuando detectan que se están produciendo más accesos a Facebook que a la intranet corporativa, o cuando el acceso a determinados sitios web ha propagado por la red corporativa algún tipo de malware es cuando se pone el grito en el cielo y se pretenden tomar medidas incluso disciplinarias, pudiendo incurrir en situaciones que, por no haber hecho las cosas bien, podrían provocar que —si me permiten la expresión— el tiro les acabe saliendo por la culata.

Como tantas otras cosas, es un tema cultural. Tiene que existir un acuerdo y un compromiso entre las partes (empleador y empleados) que contemple el uso personal de los recursos corporativos, pero que a la vez imponga ciertas condiciones a su uso. ¿Por qué no se incluye en el manual de acogida de los nuevos empleados esas normativas, como sí se hace por ejemplo con la normativa relacionada con Prevención de Riesgos Laborales?

La motivación de Nokia como empresa impulsando la aprobación de esa modificación legal en Finlandia no es poder cotillear el correo de sus empleados para “marujear”, sino que responde a haber sufrido varios presuntos casos de espionaje industrial aparentemente relacionados con la fuga de información confidencial a través del correo electrónico (y además, la modificación legal no permite acceder al contenido de los correos, sino tan solo a su remitente, destinatarios, tipo y tamaño de los ficheros anexados).

Porque no nos engañemos, que todos hemos sido cocineros antes que frailes. ¿O es que nadie se ha llevado alguna vez, digamos… “documentación de trabajo” de alguna empresa en la que trabajó? Lo que entronca con el uso de los dispositivos tipo USB, el acceso a los webmail, etc., pero eso ya sería tema para otro post.

Errores en la web

19 de marzo de 2009 Por

(La entrada de hoy es la primera —pero no última— colaboración de Francisco Benet, un amigo de algunos de nosotros —y familia de algún otro— que tiene gran experiencia en la gestión e integración de sistemas, protección de datos de carácter personal y evaluación de soluciones de integración de software y hardware, entre otros aspectos. Esperamos que les guste.)

Habitualmente estamos acostumbrados a hablar de firewalls, defensa en profundidad y perimetral, detectores de intrusión y otros tantos artilugios tecnológicos que nos van a ayudar a mejorar la seguridad de nuestros sistemas. Pero nos dejamos por el camino puntos que son al menos igual de importantes; que no sustituyen pero se complementan entre ellos: la seguridad del código.

[Read more…]

Destructoras de medios

16 de marzo de 2009 Por

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.

Copias de Seguridad: TSM

12 de marzo de 2009 Por

Con este post pretendo crear una serie de entradas relacionadas con las copias de seguridad, que estoy completamente convencido que es uno de los pilares básicos en la seguridad de cualquier organización. Hablaremos de los distintos software de backups, de las diversas tecnologías hardware, de las copias Offsite, de los backups DE sistemas virtualizados y de los backups EN sistemas virtualizados (Virtual Tape Library). En fin, haremos un pequeño repaso de cómo está actualmente este mundo y espero que sirva al lector para reflexionar y analizar si su sistema de backups está funcionando como debería.

He perdido la cuenta de las veces que una copia de seguridad ha salvado mi puesto de trabajo. La verdad es que gran parte de mi vida laboral ha estado bastante relacionada con los backups, llevo siendo “responsable/encargado/enmarronado” de este tema desde hace unos 15 años y en varias empresas. Empiezo a pensar que yo me lo busco…..

Cierto es también que es un tema que me apasiona, pero es muy sufrido. Hay un gran trabajo de análisis, configuración y optimización de toda la infraestructura hasta que el sistema queda medianamente estable, y aun así nunca te sentirás tranquilo. Pero, como en casi todo este sector, el éxito está en minimizar lo máximo posible lo que yo llamo el “Efecto Uy“. ¿Quién no ha vivido alguna vez un… “¡Uy, pues la copia se hizo!”, “Uy, ¿cómo es que no se hace copia de este directorio?” ?

De todos los software de copias de seguridad que he tocado y créanme, son muchos, me quedo con el TSM (Tivoli Storage Manager) de IBM. Por experiencia, es el que más reduce dicho efecto y el que optimiza al máximo los recursos. Cierto es también que está pensado para un entorno de Backup medio-grande, y que las licencias no son nada baratas. Eso sí, cuando está completamente desplegado y funcionando empiezas a descansar por las noches.

Existen cinco características de este sistema que yo destacaría frente a otros productos, que son:

— Usa un “pool” de disco intermedio para las copias de los nodos, es decir, no copia directamente a cinta sino que va almacenando en disco los datos. Cuando este pool de disco llega a un límite, va volcando información a cinta mientras sigue llenándose el disco con más copias. Este es un sistema que ahorra muchísimo tiempo.

— Siempre hace copias incrementales. El sistema sólo hace una copia total la primera vez, a partir de ahí se basa en incrementales y en versiones de archivos que caducan según se parametrice. Esta característica junto con la del pool de disco logra que en unas horas se puedan hacer copias de decenas de nodos.

— Dispone de un módulo de Gestión de Recuperación de Desastres, donde la misma aplicación (si previamente le has enseñado bien) te dirá lo que tienes que hacer y cómo lo tienes que hacer en una situación de contingencia.

— La gestión de los cartuchos es automática. Olvídate de etiquetar cartuchos y saber qué tipo de copias contiene cada uno. Para el TSM no hay cartuchos sino un espacio de almacenamiento que la propia aplicación fragmenta según necesidades en bloques que copia en los cartuchos. Desde el punto de vista de seguridad esto es fundamental, puesto que no hay forma de extraer datos de un cartucho por separado, no sirve de nada si no tienes la Base de Datos de la aplicación.

— Los nodos son independientes del servidor. Aquí, es el cliente quien se pone en contacto con el servidor y le manda los archivos a copiar. Tiene dos ventajas, la primera es que reparte la carga de proceso entre todas las máquinas y la segunda es que es muy difícil que todos los servicios de planificación de todos los nodos fallen en el mismo momento. Es decir, la probabilidad que una noche fallen todas las copias es casi nula.

Por supuesto que la mayoría de aplicaciones de Backup del mercado son bastante válidas: el Symantec NetBackup y BackupExec, el Acronis, el ARC, etc. Lo principal es elegir el adecuado a la infraestructura que se disponga (número de servidores, tipo de red, tipo de servidor, SAN, NAS, cantidad de datos, ventana disponible,…) y, por supuesto, una vez se ha elegido la aplicación hay que exprimirla a fondo, puesto que hay decenas de características que no usamos en nuestras aplicaciones por desconocimiento de la misma y que nos podrían ahorrar muchos disgustos o una inmediata actualización del currículo…

* * *

(N.d.E.) La encuesta de esta semana, y a pesar de mi escasa inventiva un jueves a estas horas de la tarde, está relacionada con la privacidad en las redes sociales, y recoge algunas críticas y opiniones que éstas despiertan cuando se habla del tema de los datos de carácter personal. Espero que les resulte interesante:

[poll id=”8″]

En relación con la encuesta de la semana pasada, aunque hubo poca participación, parece que los usuarios se decantan por admitir que la basura que generan es suya únicamente dentro de su casa, aunque rebuscar en ella fuera despierte algunas reticencias de privacidad. Los resultados son los siguientes:

[poll id=”7″]

Nada más; pasen un buen fin de semana y si deciden pasarse por Valencia, tráiganse puestas las ganas de fiesta.