En esta oportunidad quería compartir con ustedes distintas situaciones que se presentan con mucha frecuencia en proyectos de seguridad de la información y que sin ser el objetivo principal, desnudan la madurez en cuanto a los temas de seguridad de la información que tiene la Organización en la cual se está ejecutando el proyecto.
A lo largo de los 5 errores más frecuentes podremos encontrar problemas de base, que producto del avance de las distintas etapas se hacen cada vez más evidentes e incluso muchas veces son determinantes para el éxito o fracaso del proyecto en cuestión.
El orden de los errores es completamente arbitrario, no representa su importancia o impacto en la Organización.
Equivocar el interlocutor
En muchos casos el líder de proyecto corresponde a un área técnica y debe llevar adelante cuestiones que lo exceden en su posición y responsabilidad. Los requerimientos se traban, la información requerida se demora y ante la falta de apoyo finalmente alguien decide sobre los temas desconociendo la problemática.
Los recursos humanos no se asignan y si se hace, el proyecto se demora dado que hay que "poner en tema" al recurso asignado, que tampoco tiene la jerarquía necesaria para tomar decisiones.
Es un problema muy difícil de resolver si nuestro interlocutor no está en condiciones de obtener la información requerida, convocar a los referentes necesarios y/o tomar alguna decisión relevante en relación al proyecto. Pero si se presentara una situación similar podríamos estar ante una Organización no muy comprometida con los temas de seguridad de la información.
Creer que únicamente con productos se resuelven los problemas
Hay proyectos que se generan para desplegar un determinado producto, pero llegado el momento de la implementación comienzan a aparecer los problemas. O el producto no hace todo lo que queríamos, o requiere información que aún no hemos podido recolectar, o depende de procesos que la Organización aún no tiene implementados o con el nivel de madurez necesario.
Es muy frecuente escuchar acerca de proyectos de Data Loss Prevention (DLP) en Organizaciones que aún no tienen un inventario unificado de activos ni han clasificado su información. Finalmente para "justificar" el proyecto, la herramienta se implementa con funcionalidades mínimas para luego volver a generar algún proyecto que regularice la situación (que muchas veces no lo hace).
En organizaciones en las cuales se presente esta situación seguramente TI es la encargada de la mayoría de los temas referentes a seguridad de la información y las demás áreas no tienen ningún involucramiento al respecto. Si algo sucede en materia de seguridad "es culpa de TI".
Hacer las cosas para cumplir
Lamentablemente en reiteradas ocasiones se escucha que un determinado proyecto "se hace por PCI" o "porque me lo pide auditoria", cuando en realidad quizás no es necesario o surgió de una reunión entre gente que desconoce los problemas y el auditor confundiendo su rol hace consultoría. El resultado es conocido, surge un proyecto de remediación de un problema que quizás no existe.
Más allá de que sería ideal que los proyectos surjan de necesidades reales de la Organización, que correspondan con un objetivo claro y medible, es poco frecuente encontrarse con tal escenario. A veces se hacen para cumplir o para que los responsables de un determinado problema no asuman la responsabilidad de la falta de gestión.
En organizaciones donde se presenta el escenario comentado, es muy común encontrarse con líderes de proyecto que pretenden que el consultor tome decisiones que le corresponden a otros miembros de la Organización, que clasifique, analice, y termine decidiendo sobre temas que claramente lo exceden. Los tiempos se exceden, el proyecto cambia de alcance, queda empantanado en busca del verdadero problema o de alguien capaz de sacarlo adelante.
No acompañar al negocio
Si bien parece muy claro que TI debe brindar un servicio al negocio y acompañarlo para lograr el cumplimiento de los objetivos, es frecuente encontrarse con proyectos que no tienen ninguna relación con el rumbo que tiene el negocio. Negocios que están pensando en ir hacia la nube, en donde TI ejecuta proyectos de centralización de aplicaciones cliente/servidor o restricciones para el trabajo remoto, ambas cuestiones que muestran un camino completamente distinto entre el negocio y TI. Negocios que se despliegan sobre plataformas sociales y canales de comunicación 1 a 1 con el cliente, frente a proyectos que buscan restringir el uso de redes sociales. El resultado es conocido, siempre (o casi siempre) gana el negocio y aquello que se implementó para restringir pasa a "escuchar" sin ningún otro objetivo más que nutrir a una consola de un montón de información que nadie analizará.
No deja de ser un signo de problemas aún mayores dado que generalmente en ese tipo de organizaciones TI se considera dueña de los servidores y es frecuente que sea el usuario quien notifica los problemas dado que la "independencia" de gestión es absoluta.
Creer que los consultores conocen más la Organización que uno mismo
Si el consultor toma decisiones que debe tomar la Organización el proyecto presenta síntomas de fracaso. El valor agregado del consultor viene relacionado con la experiencia en otros proyectos, su formación, el hecho de mantenerse actualizado y de la dedicación a los temas relacionados con seguridad de la información. Ahora bien, eso no lo convierte en la persona adecuada para tomar decisiones que le corresponden a los miembros de la Organización, dado que ellos conocen el valor de la información involucrada, los objetivos de negocio de corto y mediano plazo, la historia asociada al proyecto, las idas y vueltas políticas, los intereses internos y todo aquello que es tan importante al momento de tomar decisiones.
En organizaciones en las cuales se lo espera al consultor como el gran salvador generalmente presentan más de uno de los errores que comentamos en este post y es muy probable que el resultado final de los proyectos sea un producto que nadie utilice o un proceso que luego de unos meses nadie recuerde.
Superman hay uno solo
En muchas oportunidades hemos comentado la importancia del involucramiento de los máximos referentes de la Organización en temas relacionados con seguridad de la información. Es una responsabilidad de la Dirección el estado de seguridad de su negocio, definir el nivel de protección adecuado para sus activos y asignar los recursos necesarios para lograrlo. Si esto no se presenta, es muy probable que alguien asuma una responsabilidad que lo excede y por consiguiente el propio desconocimiento del negocio haga que la estrategia de seguridad sea errónea.
El desafío para quienes deben gestionar la seguridad de la información es lograr el interés e involucramiento de los líderes, es allí en donde se debe invertir el mayor esfuerzo, para luego no dedicarle tanto tiempo y esfuerzo a reparar los errores producto de decisiones equivocadas, mal uso de los recursos y medidas desacertadas.
Los invito a realizar el ejercicio mental de pensar si estamos tomando las decisiones que están bajo nuestra responsabilidad o estamos asumiendo compromisos que realmente nos exceden.
¿Seguiremos tratando de convencer al DBA o al Desarrollador en vez de lograr el interés de la Dirección?
--------------------------------------------------------
