20 abril 2012

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?

--------------------------------------------------------

Contribución por Maríano M. del Río

4 comments :

Wasesores dijo...

Gran artículo y grandes verdades. Plas, plas, plas,...
 
Salu2 desde Wasesores.com

M43 dijo...

Muy buen artículo.
En mi organización se cometen los 5 errores juntos!!!!

Rocral dijo...

La mayoria de esos errores son imputables a directa o indirectamente a los analistas funcionales (o de negocio, etc.)
Si comparais los requisitos de las ofertas de trabajo de AF de España con las de USA, UK o Alemania, vereis que en España se les exige conocer la tecnologia (ej. cobol, j2ee, struts,...) y se habla poco de los conocimientos sobre diseño lógico y de negocio implicados, de hecho  muchas  ofertas USA,uk,D,... NO INCLUYEN NINGUN REQUISITO TECNOLOGICO.
Personalmente creo que aquí se le da demasiada importancia a la tecnologia implicada y por eso muchos perfiles AF no tienen los recursos personales para hacerse cargo de llenar el hueco entre los stakeholders, la estrategia de la empresa, el  sector, el ámbito aplicativo, y la solución técnica.
De ahí vienen afirmaciones tan sorprendentes como:
- Hubo falta de compromiso de la dirección con el proyecto.
- Nos han caido "malos usuarios".
- Los consultores asumieron decisiones que no les correspondian.
- El cliente no sabe lo que quiere.
Y si no me creeis, preguntaros por ejemplo cuantos analistas funcionales que conozcais tienen pajolera idea de contabilidad? Y como es posible eso si cualquier aplicación de negocio, por el mero hecho de registrar operaciones de negocio, implica movimientos contables para los que la aplicación deberia proporcionar datos "semilla" tambien conocidos como eventos contables?
Yo he vivido el caso de un ERP construido a medida para una multinacional en BCN en el que descubrí cuando se estaba implantando que el sistema logística-almacenes-pedidos-facturación NO EMITIA eventos contables. Los analistas no cayeron en la cuenta, mientras que el cliente no podia creerlo.

Florencio Cano dijo...

En mi opinión, las organizaciones, en cuanto a seguridad, en ocasiones se centran demasiado en la parte organizativa mientras que otras organizaciones se centran demasiado en la parte técnica. Solo con comités y procedimientos documentados no puede implementarse seguridad mientras que con una solución puramente técnica tampoco si no está alineada con el negocio y no resuelve el riesgo fundamental.

Yo creo que un error importante es no haber hecho previamente un análisis de riesgos mínimo y dejarse llevar por donde creemos que existe el problema o por "consultores" de baja calidad que son más bien distribuidores de software o hardware y lo único que quieren es "encasquetarnos" su solución sin un análisis previo.