30 noviembre 2007

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

28 noviembre 2007

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

19 noviembre 2007

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

09 noviembre 2007

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.

05 noviembre 2007

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.