El parcheado de los sistemas informáticos es una de las medidas mas importantes de seguridad que deben seguirse e implantarse en cualquier organización. Recientemente hemos podido ver como grandes organizaciones gubernamentales han sufrido incidentes de seguridad por propagación de gusanos, que podían haberse evitado en gran parte de una manera sencilla simplemente aplicando los parches. Si están pensando lo mismo que yo, se preguntarán cómo es posible que cualquier usuario domestico mantenga actualizado su equipo siempre que sale una vulnerabilidad y en estas organizaciones no apliquen el parcheado de manera correcta.

Francamente, no tengo la respuesta a la pregunta, pero en esta entrada pretendo hablar de cuáles son los problemas a los que los administradores TIC se deben enfrentar cuando tratan de implantar políticas de parcheado. A estos problemas los voy a llamar “Los enemigos de los parches”, que les detallo a continuación:

En estos meses, en los que la crisis (o la desaceleración) planea sobre nuestras cabezas, y a diario vemos cómo empresas de todos los sectores realizan ajustes de plantilla, abren expedientes de regulación de empleo, o incluso echan el cierre, la seguridad juega un papel fundamental para garantizar que el negocio -o lo que quede de él- sobrevive a las vacas flacas… IMHO, la seguridad debe ser una de las cosas en las que el presupuesto de una organización no se reduzca, o se reduzca lo mínimo posible, para garantizar la protección del negocio; de todos es sabido que cuando las cosas van mal, la delincuencia aumenta, y por tanto debemos protegernos mejor. La probabilidad de que en esta época que corremos tengamos un empleado que nos roba información, a la competencia viéndonos como un enemigo a eliminar -en el sentido figurado-, o a una mafia tratando de hacernos un phishing, es muy alta, con lo cual no podemos descuidar nuestra seguridad; es más, yo trataría de incrementarla.

No obstante, cuando una empresa tiene que ajustar al máximo su presupuesto global, la partida destinada a seguridad tiende a reducirse a una mínima expresión. ¿Y qué es esa mínima expresión? Como siempre, depende… Volviendo al post de la Pirámide de Maslow de la Seguridad, la mínima expresión de la seguridad consistirá, posiblemente, en mantenerse en el nivel en el que nos encontrábamos con anterioridad. Nada de mejorar, nada de incrementar nuestros niveles… supervivencia pura y dura. Es más, en muchas ocasiones, si no retrocedemos en el nivel que teníamos, ya podemos estar contentos… Pero, ¿qué es preferible en estos tiempos, tratar de avanzar, o reforzar lo que hemos conseguido? Creo que depende de muchos factores, y en el equilibrio está la virtud… Bajo mi punto de vista, no tiene sentido tratar de avanzar si no podemos reforzar lo que vamos consiguiendo; así, la seguridad sería una especie de galería minera: mucho más importante que alargar el túnel es apuntalar lo que ya hemos avanzado, para evitar un derrumbe. Ojo, con esto no quiero decir -sigan leyendo- que no tratemos de mejorar permanentemente nuestra seguridad con la excusa de la crisis; simplemente que lo hagamos con cabeza (más de la habitual), sabiendo dónde invertimos nuestros recursos, y por supuesto -ahora más que nunca- sin dejar de mirar para atrás, garantizando que la galería está bien apuntalada. Innovemos y busquemos soluciones creativas a nuestros problemas.

No sé si son ustedes conscientes de que si han adquirido un móvil a través de una operadora de telefonía sujeto a un contrato de permanencia, una vez éste ha expirado la operadora de telefonía está obligada a proporcionarles el código de liberación; y les anticipo que si les dicen que el trámite de obtención de dicho código llevará de diez a quince días, mienten. El caso, y lo que es pertinente a esta entrada, es que el pasado sábado llame para realizar dicha gestión “en nombre” de mi pareja (les confieso que obtengo una extraña sensación de satisfacción “conversando” con los operadores telefónicos de los grandes proveedores de servicio como las telecos o energéticas). Lo que me llamó la atención y me dejó descolocado fue que, después de haberle dado a la operadora todos los datos correctamente, incluyendo DNI, nombre y apellidos, IMEI, número de teléfono, marca y modelo, y lugar y fecha aproximada de compra (algo, esto último, que no está escrito en ningún sitio), debió pensar que una voz de hombre no es propia de una mujer, y me pidió hablar con ella. Claro está que la operadora no tenía medio de saber que ella era quien decía ser, pero al parecer, eso la satisfizo, porque un par de minutos después, retomamos la conversación, asegurada ya la autenticidad de mi petición por una voz de mujer que podía ser la de cualquiera.

Los sistemas de decepción de intrusos siempre me han parecido muy interesantes de cara a garantizar la seguridad de una organización; si bien los más complejos, las honeynets, no suelen implantarse con frecuencia salvo en entornos grandes y/o especialmente concienciados en temas de seguridad (digamos que los beneficios obtenidos del sistema no suelen cubrir el coste asociado a la implantación y al mantenimiento del mismo), los sistemas sencillos, los honeypots, tienen, bajo mi punto de vista, una buena relación coste/beneficio.

Dentro de los honeypots, los sistemas más triviales son los honeytokens: elementos que simplemente por “tocarlos”, por acceder a ellos, generan una alarma que puede proporcionar información muy valiosa a la organización: intentos de intrusión, intentos de robo de información, etc. Este subconjunto es particularmente interesante, porque a cambio de una inversión mínima —existen honeytokens muy sencillos, y su mantenimiento una vez implantados es casi inexistente— obtenemos una información de alto valor.

Comenzaba el otro día Alberto su entrada sobre clasificación de la información comentando que éste suele ser un motivo habitual de incumplimiento. En efecto, cuando estamos trabajando en una organización y pedimos el procedimiento de clasificación y tratamiento de la información, en muchos casos nos miran con cara de póker y nos vienen a decir algo del tipo “¿Yesoqués?”.

Tener definido —e implantado— un procedimiento que nos diga cómo trabajar con la información corporativa es no sólo una buena práctica recogida en estándares como ISO 27.002 , sino en ocasiones incluso un requisito legal: la propia LOPD recoge restricciones diferentes en función del nivel de cada tratamiento declarado. No debemos olvidar que la información es sin duda uno de los activos más importantes de nuestra organización, y que muchos de los esfuerzos que a diario realizamos van orientados a proteger este activo, por lo que la clasificación y el tratamiento de la información son una pieza básica para garantizar la seguridad.

En las auditorías de seguridad de la información, al igual que en las de protección de datos personales, uno de los temas que es motivo frecuente de incumplimiento, es la carencia de un procedimiento de clasificación de la información y adicionalmente, la clasificación de los riesgos inherentes a aquella. ¿Cómo se entiende que una organización pueda controlar la información que gestiona (importante activo) sin establecer ciertas categorías en la misma y aplicar los debidos controles para su validación, protección y limitación de uso y acceso?

Unos ejemplos

El periódico que está sobre la mesa de recepción, no tiene clasificación alguna y es de acceso público, pero si casualmente hablase de la organización, probablemente se intentaría evitar su acceso (en caso negativo) o se pincharía en el tablón de anuncios (caso positivo); vemos que el contenido —la información— delimita la categoría del soporte. Un albarán de envío de materiales (pongamos una fábrica de tubos) a un cliente sólo mostrará la dirección social del cliente y la lista de productos, siendo por tanto una información confidencial, pero de bajo nivel de riesgo. Sin embargo, si el mismo albarán va valorado, mostrará precios aplicados al cliente así como posibles descuentos y formas de pago (no quisiera pensar que mostrase la cuenta bancaria), conteniendo de este modo información confidencial de un nivel superior en relación al caso anterior, dado que cualquiera que tuviera acceso a él, podría conocer detalles sobre los términos comerciales de acuerdos en precios, descuentos y formas de pago con el cliente. Esta información es sensible y muy apetecida por la competencia.

Cuando una organización sufre determinados incidentes de seguridad (por ejemplo, una intrusión), se plantea la realización de un análisis forense, en el que se tratan de obtener y presentar evidencias electrónicas del problema acaecido; adicionalmente, en ocasiones —no siempre, aunque si se ha producido un delito debería ser así—, es necesario efectuar una denuncia, y es entonces cuando surge la necesidad de realizar un peritaje informático por parte de un perito cualificado.

Un peritaje informático tiene como objeto dar respuesta técnica a una serie de cuestiones planteadas bien por una de las partes bien por el propio juez; dicha respuesta, por muy complejos que sean el desarrollo o las bases de la misma, debe ser concisa y sencilla (pensemos que la tienen que interpretar personas que no tienen por qué estar familiarizadas técnicamente con el objeto del informe). Así, siempre es conveniente incluir un apartado de “conclusiones” dentro de nuestro informe, en el que en base a todo lo desarrollado en el cuerpo del mismo, se muestren de forma resumida las respuestas a las cuestiones planteadas.

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.