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

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:

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.

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.

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…

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

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.

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

El otro día, mirando los archivos que tengo en el ordenador de casa encontré algunos proyectos antiguos en Visual Basic que diseñé hace algunos años. En aquella época trabajaba en una empresa muy pequeña (dos desarrolladores, un administrador de sistemas y “el jefe”), para nosotros todo lo que hacíamos era la mejor opción y los clientes quedaban bastantes satisfechos con nuestro trabajo. Los desarrollos los hacíamos con Visual Basic 6.0 contra bases de datos Microsoft Access y en el mejor de los casos SQL Server 2000; todo Microsoft, por supuesto.

Con los conocimientos de seguridad que he ido adquiriendo a lo largo de mi vida laboral me doy cuenta de que los proyectos que diseñábamos de manera tan “perfecta” tenían… ¡más vulnerabilidades que código escrito!, y que si un usuario malintencionado se hubiera entretenido en explotarlas hubiera destrozado el sistema en cuestión de segundos. Pensando en todo esto me pregunto: ¿Por qué diseñabámos así? ¿No teníamos los conocimientos necesarios? La respuesta es que en ningún momento del desarrollo nos planteábamos la posibilidad de que existieran usuarios malintencionados, o en otras palabras, asumíamos que “los usuarios de nuestra aplicación son demasiado torpes como para hacer esas cosas”. Obviamente, no puedes confiar en que los usuarios de tus aplicaciones vayan a ser “buenos” y no salirse del camino que les dibujas, porque si encuentras uno curioso, puedes llevarte más de una sorpresa desagradable.

En los últimos tiempos han venido surgiendo noticias en medios generales en relación a las “investigaciones” que diferentes ayuntamientos realizan o se plantean realizar para detectar y multar a ciudadanos que no reciclan su basura; la idea es simple: se revisan las bolsas del contenedor en busca de aquellas que contienen residuos de varios tipos (es decir, las correspondientes a los que no reciclan), y en esas mismas bolsas se busca información que pueda dar indicios sobre el vecino que no ha reciclado (recibos del banco con datos personales, facturas, publicidad…). Una vez localizado dicho vecino, se le multa.

Este tipo de noticias plantean serias dudas en materias de seguridad; en primer lugar, tenemos un problema legal: ¿quién está legitimado para buscar en mi basura? Según unos, nadie (mi basura es mía y sólo yo puedo mirarla), y según otros (los ayuntamientos), una vez se deposita la bolsa en el contenedor, la basura ya no es nuestra, sino que es pública (o algo así). Personalmente no entro a valorar este aspecto legal (lo desconozco, y aprovecho para pedir, si alguien entre nuestros lectores conoce el tema, más información al respecto), pero sí que me preocupa la posible violación de la confidencialidad que se produce al revisar basuras ajenas (dicen por ahí que es posible conocer a cualquier persona analizando su basura). Por lo que a mí respecta, trato siempre de destruir o separar cualquier cosa que permita detectar al “propietario” (en este caso yo) de la basura, sobre todo, y para matar varios pájaros de un tiro, los papeles que amablemente me envían los bancos para recordarme la enorme cantidad de dinero que tengo en mis cuentas en Suiza, los pocos recibos que tengo que pagar al mes con todo ese dinero, y la ridícula hipoteca en la que me metí hace un tiempo :)