Apuntes técnicos

La verdad es que últimamente el trabajo me consume bastante tiempo, y no puedo dedicarle tanto como me gustaría al blog. Así que hoy, en lugar de postear algo muy denso, me voy a limitar a dejar un par de referencias técnicas que me parecen bastante interesantes:

• La primera es esta, una seria y bastante profunda descripción de tecnologías anti-malware. Muy aconsejable para todo aquél que quiera profundizar a un nivel medianamente serio sobre el estado del arte en este mundo.
• La segunda, que no tiene nada que ver con la anterior, es esta otra. Es un documento que diserta sobre qué criterios utilizar a la hora de seleccionar un producto VPN SSL. Obviando la parte comercial del documento, que le hace perder puntos, me parece una reflexión interesante, aunque no sea excesivamente profunda, sobre temas en los que pensar antes de elegir un producto que implementa una tecnología, desde mi punto de vista, muy interesante y con mucho futuro.

Y por esta semana, eso es todo. Que paseis un buen fin de semana...

Calidad, interna o externa?

Cada vez es más frecuente, sobre todo a raíz de la expansión de la ISO 9001, oir hablar de la calidad como la satisfacción de las expectativas del cliente. En resumen, de que los parámetros de calidad se determinen externamente. Es suficiente este acercamiento? Desde mi punto de vista, no.

Está claro que uno de los objetivos básicos de cualquier negocio es el de satisfacer las necesidades del cliente. Pero... qué necesidades? Con un ejemplo creo que se puede entender fácilmente. Imaginemos a un fabricante de coches. Y a un cliente que lo que quiere es un coche bonito estéticamente, en el que la música se escuche con mucha potencia y que tenga asientos cómodos de materiales nobles. Le estaremos dando un buen coche si cumplimos con sus requisitos? El cliente no ha dicho nada sobre potencia del motor, consumo, número de plazas... Una berlina de alta gama con un buen equipo de sonido puede satisfacer sus necesidades, pero también lo podría hacer un compacto "tuneado". O por qué no un buggy convenientemente personalizado?

El problema de fondo, exagerado en el ejemplo, es la definición de requisitos. Qué características tiene mi producto, y qué necesidades del cliente debe satisfacer? En teoría pueden parecer dos preguntas sencillas de responder, pero la práctica nos dice que en muchos casos no es así. Sobre todo, si estamos hablando de servicios. Porque un producto, ya sea coche, tuerca u ordenador (y en este último caso no está tan claro) está bastante claro qué hace, para qué sirve, y qué problemas soluciona. Pero... y un servicio? ¿Podemos dar un servicio de CAU contratando una empresa de teleoperadoras? Qué necesidades del cliente satisface una consultoría? ¿Sabe realmente el cliente lo que quiere conseguir con una consultoría? Y si no lo tiene claro... cómo podemos ofrecer un servicio "de calidad"?

Yo creo que la calidad tiene dos vertientes, interna y externa. Acepto que haya que cumplir con los requisitos de los clientes, pero sin olvidar los propios. Creo que la base de la calidad bien entendida debe ser cumplir COMO MÍNIMO los requisitos propios, que al fin y al cabo somos los que conocemos nuestro propio negocio. Establecer unos "baselines" de calidad en los productos y servicios que ofrecemos. Y a partir de ahí, podemos empezar a pensar en satisfacer, además, los requisitos del cliente. Y de paso ayudar al cliente a que reflexione acerca de si las necesidades que él quiere satisfacer realmente se satisfacen con el producto o servicio que va a comprar, y si realmente tiene que contemplar sólo esos requisitos, o alguno más. No sea que la solución apropiada para el cliente del coche sea instalar un home-cinema...

La idea de que la calidad tiene que empezar "por uno mismo" no es en absoluto extraña. Si hablamos de servicios, probablemente todos seremos conscientes de que la forma de poder ofrecer un buen servicio es acotarlo. El primer paso será definir nuestro catálogo de servicios. A alguien le suena? Tendremos que parametrizar qué ofrecemos, qué características tiene, para qué sirve... En resumidas cuentas, qué necesidades satisface, y a qué nivel. Tendremos que ser capaces de identificar los SLAs que puede cumplir nuestro servicio. Qué minimos podemos ofrecer, cuál va a ser nuestra "baseline" de calidad. Y a partir de ahí, analizar en qué medida podemos "mejorar" nuestro servicio para cumplir con las exigencias del cliente... si es que son mayores que las de referencia.

Y si alguien quiere volver a releer el post, aquí tiene una pregunta final: ¿Qué pasa si cambiamos el término calidad por el término seguridad? Todo se puede mirar desde distintos puntos de vista...

Riesgo de negocio o riesgo IT?

Las tendencias en los últimos tiempos hablan de acercar la perspectiva de negocio y la perspectiva IT, en pos del famoso "alineamiento" entre ambos mundos. Sin embargo, si podemos sacar un pero a estas tendencias son que habitualmente planteaban ese acercamiento desde la perspectiva IT. Por eso me ha gustado este artículo (lo siento, tiene mucha publicidad), ya que plantea un acercamiento entre ambos mundos desde el punto de vista de los riesgos de negocio.

En concreto, el artículo anima a los gerentes de negocio a entender los riesgos IT como riesgos de negocio, y evaluar sus consecuencias desde este punto de vista. En concreto, el artículo plantea esta reflexión en base a cuatro objetivos de negocio:

• Disponibilidad: Disponibilidad de los procesos de negocio ligada a la disponibilidad y recuperación ante incidentes de los sistemas IT.
• Acceso: Permitir accesos a la información y los sistemas en base a las necesidades del puesto, y bloquearlos a todos aquellos que no lo necesiten.
• Exactitud: Los sistemas IT deben proporcionar toda la información que se precise en el momento y forma oportunos, con el fin de garantizar el cumplimiento de los requisitos de negocio que se definan.
• Agilidad: Los sistemas IT deben permitir y adaptarse a los cambios de negocio que pueda sufrir la organización.

El artículo plantea la necesidad de que los gerentes de negocio adquieran las herramientas necesarias para gestionar los riesgos IT, con el fin de que sean capaces de determinar los riesgos que desean asumir y los que deben reducir. Para ello, propone tres líneas de acción:

• Un sólido modelo de activos que interrelacione procesos, activos IT, personas y controles.
• Una estructura de gobierno de riesgos que contemple la gestión de riesgos IT como parte integral de la misma.
• Una cultura de gestión de riesgos que alcance a toda la organización.

El artículo concluye resaltando la necesidad de integrar cuanto antes la gestión de riesgos IT dentro de la gestión de riesgos de negocio, ya que "los peores riesgos son aquellos que nunca se consideran".

Realmente me ha parecido un artículo muy interesante, tanto por el punto de vista que refleja como por la concretitud de los consejos que da. ¿Sabrán las empresas poner em práctica estos consejos? ¿Echais de menos alguna línea de acción que os parezca necesaria incluir? Sería interesante contar con la opinión de alguien que viera el artículo desde el punto de vista de los gerentes de negocio...

La función de seguridad

Cuando una referencia es buena, no es necesario comentarla demasiado. Ese es el caso de este post, en el que el autor describe cómo se puede articular la función de seguridad. Inicialmente describe su composición, posteriormente analiza sus posibles ubicaciones en el organigrama y finalmente estudia las ventajas e inconvenientes de su desarrollo en modo centralizado o distribuído. La verdad es que el análisis es muy completo, y creo que sólo es necesario hacer una puntualización.

La puntualización es, sencillamente, el título del artículo. En él se hace referencia a la función de seguridad informática, aunque en el desarrollo del mismo en muchos casos se excede este alcance. Este es un aspecto que a mí, personalmente, me fastidia bastante. Es cierto que la seguridad de la información recae en buena medida en el ámbito informático, pero si realmente se desarrolla por completo esta función, una parte importante de su actividad debería desarrollarse también fuera de él. Por eso en el título de mi post me he "comido" la última palabra. Porque en caso contrario los conflictos de intereses no sólo se producirían dentro del área de sistemas, sino sobre todo en el exterior, ya que desde un área técnica se deberían realizar prescripciones de aspectos que en absoluto tienen que ver con los ámbitos técnicos.

Abaratar costes... a qué precio?

Es curioso cómo el tema de los costes, que a priori puede parecer uno de los aspectos más objetivos, matemáticos y cuantificables en una empresa, puede dar pie a tal variedad de interpretaciones y puntos de vista, a veces incluso contrarios, cuando los datos de partida deberían ser siempre los mismos. Esto es lo primero que me vino a la cabeza cuando leí esta noticia, hace ya unos días, sobre la posibilidad que ofrecen algunas empresas de que los empleados compren y mantengan sus propios PCs.

La verdad es que la idea, desde el punto de vista de la seguridad, me parece demasiado atrevida. Pero ni siquiera hace falta recurrir a estos argumentos para cuestionarla, basta con pensar un poco en costes indirectos. Es cierto que si los propios empleados compran y mantienen sus equipos, no hay que dedicar ni un céntimo del presupuesto corporativo para atención al usuario ni para adquisición y/o mantenimiento de equipos. Ahora bien, si la condición indispensable (tal y como afirma el artículo) es migrar las aplicaciones a un entorno web... qué coste tienen estos proyectos? Probablemente sea significativo. Ciertamente es un coste puntual, pero puede que no sea despreciable, y que la rentabilidad del cambio de estrategia se retrase unos años.

Además del coste de la migración... ¿Qué garantías de rendimiento puede ofrecer la compañía? En general, el uso de los equipos es un factor determinante para el rendimiento del personal, y por el momento a nadie se le exigen conocimientos de administración de sistemas para acceder a un puesto que no sea de este área. Si los equipos funcionan mal, la única forma de asegurar que los empleados pueden arreglarlos (y que sigan siendo productivos) es habilitar un programa de formación técnica para todos los empleados. Y eso tiene un coste.

Por otra parte... qué aplicaciones van a utilizar los usuarios para desarrollar su trabajo? Son todas freeware? Y si no es así, quién corre con los gastos derivados de las licencias? La empresa o el empleado? Hay muchos programas informáticos cuyo coste en licencias no es precisamente bajo. Y no todos los productos son capaces de funcionar vía web.

Por otra parte, una vez que todos los equipos están accediendo a los sistemas de la organización, hay que asegurar la interoperabilidad. Y si el entorno es heterogéneo, puede ser algo complicado...

Ya desde el punto de vista de la seguridad... qué políticas de usuario puede aplicar la compañía? Se puede forzar una longitud mínima de contraseña, por ejemplo, si el usuario puede administrar su propia máquina? Se puede forzar la navegación a través de proxy, si el usuario puede modificar su configuración de red? Porque debe poder hacerlo, si queremos que administre su propio equipo...

En resumidas cuentas, creo que la iniciativa en términos generales es bastante desacertada. Sobre todo, porque no se tienen en cuenta costes indirectos derivados de esa decisión, ni perjuicios colaterales que puedan surgir. Y desde el punto de vista de la seguridad, difícilmente se pueden establecer muchos controles corporativos si los usuarios tienen que tener por propia política de empresa la capacidad de saltárselos. Que de proponer un abanico de opciones para elegir el equipo de trabajo, a dar una libertad completa en su selección, el salto es enorme. Y no tiene red.

Seguridad o Gestión de la Seguridad?

Con la creciente popularidad de las normas ISO de la familia 27000 y el auge que está cobrando la gestión de la seguridad de la información en muchos ámbitos, parece como si se hubiera desatado una obsesión general por gestionar la seguridad. El problema es que en muchos casos se está empezando a confundir la gestión con la seguridad, y en algunos incluso olvidándose esta última.

La gestión de la seguridad es, en principio, el nivel más avanzado en relación a la seguridad. Pero para llegar a este nivel es obviamente necesario haber superado los anteriores. Para gestionar la seguridad antes debemos tener seguridad. Parece una obviedad, pero la realidad es que no siempre se tiene en cuenta. No debemos tener en cuenta que el objetivo no es la gestión, sino la seguridad, y que la gestión es sencillamente una vía para mantener y mejorar sistemáticamente la seguridad. Es la vía más avanzada, y para llegar a ella tendremos que haber superado las anteriores. Si no, el batacazo será estrepitoso, y tarde o temprano llegará.

Vamos a por un ejemplo, que probablemente sea la forma más sencilla de verlo: Un antivirus. Qué pretendemos conseguir con él? Estar libres de virus, para no sufrir los efectos dañinos que pueden ocasionar si nos infectamos. Querríamos detectar y eliminar todos los virus que lleguen a nuestro PC. Dónde está la seguridad y dónde la gestión de la seguridad en relación a este antivirus?

Imaginemos una empresa que tiene un parque de PCs en el que todos los equipos tienen su antivirus totalmente actualizado, con un motor de detección que combina heurística avanzada y nuevas firmas que se publican diariamente, que detecta todo tipo de malware, que escanea automáticamente todo el parque de PCs, ... Tenemos el mejor antivirus posible, y con la mejor instalación y configuración posible. Eso es seguridad. Independientemente de que la configuración esté o no documentada, de que se revise periódicamente o de que monitoricemos la tasa de actualización de los antivirus.

Ahora pensemos en otra empresa con un antivirus del montón, sin heurística, de un fabricante que publica nuevas firmas de vez en cuando, que sólo está instalado en los PCs más nuevos de la empresa, ... Tenemos un antivirus mediocre con una instalación y configuración mediocre. Tenemos seguridad? No mucha. Sin embargo, esta empresa tiene totalmente documentada su política de antivirus, la dirección la revisa anualmente, tiene indicadores que le permiten conocer el % de ordenadores con el antivirus actualizado, mide como incidentes de seguridad todas las infecciones detectadas y no eliminadas, ... Tiene una muy buena gestión de la seguridad en relación al antivirus. Se ve la diferencia?

Evidentemente, he simplificado mucho las cosas. En el primer caso la seguridad de la empresa en relación a los virus es muy buena... en ese momento. Si no hay una gestión asociada, ese nivel de seguridad no se podrá mantener. Habrá que hacer un seguimiento de la situación si queremos seguir garantizando ese nivel de seguridad. Y en el segundo caso, si la gestión de la seguridad es muy buena, habrá seguimiento del estado, revisiones periódicas y auditorías que nos digan que nuestra protección frente a virus no es muy buena, y se establecerán medidas correctoras para solucionar estas carencias, de forma que a medio plazo probablemente se podría alcanzar una situación aceptable. Las cosas nunca son blancas o negras, y en este caso tampoco iba a ser menos. Sin embargo, creo que el ejemplo ha servido para aclarar las diferencias.

Esta dicotomía no tiene por qué ser grave, ya que es muy habitual que ambas tendencias, mejor o peor llevadas, tiendan a converger. Esa es su evolución natural. El problema puede surgir cuando se introducen factores que pueden hacer que cambie el rumbo de esa convergencia natural. Y uno de esos factores puede ser la certificación de sistemas de gestión. Si la obtención de un certificado que avala un sistema de gestión se considera algo positivo, puede que la empresa centre sus esfuerzos en la gestión, y tienda a olvidarse de la seguridad. Incluso puede llegar a romper esa convergencia natural, y primar la gestión sobre la seguridad. No es algo nuevo, esto ya ha ocurrido en muchos casos en relación a los sistemas de gestión de la calidad (recordais?). Y creo que este es el momento de empezar a recordar estos peligros, antes de que la seguridad corra el peligro de convertirse en la secuela de la "decepción de la calidad". Todavía estamos a tiempo de paranos a pensar, y una reflexión a tiempo siempre sirve de ayuda...