5 errores más frecuentes en proyectos de seguridad de la información

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

Leer más...

De Don Quijote a Oficial de Seguridad

Este post surge a raíz del testimonio más frecuente de aquellos que tienen a cargo áreas de seguridad, donde el común denominador es la decepción por no lograr el nivel de seguridad que ellos consideran que deben tener sus Organizaciones.

Del párrafo anterior surgen algunos aspectos importantes, uno relacionado con el "nivel de seguridad que ellos esperan" y lo otro referido a "sus Organizaciones".

Es muy común que quien se desempeña en un área de seguridad, o mejor dicho en temas de seguridad, aunque no tenga un área (que no es un tema menor), suela decepcionarse ante algunas cuestiones que se presentan en la Organización, donde pueden llegar incluso hasta enfrentarse con los usuarios y ponerse en el rol de "autorizo o no autorizo" lo que podría confundirlos en una lectura rápida con un Dueño de Datos :P

Podría ser un factor común en estas personas el hecho de llevar adelante iniciativas de seguridad no porque sean requeridas desde los negocios o en el mejor de los casos desde la Alta Dirección, sino porque o el departamento de sistemas decide encarar un determinado tema, o ellos desde el área de seguridad consideran que la seguridad en la Organización debería ser otra.

Si uno busca casos exitosos de gobierno de la seguridad es muy probable que los encuentre en aquellas organizaciones que consideran a la seguridad un aspecto fundamental y por tal motivo la Alta Dirección se encuentra involucrada. También es probable que en estas empresas nos encontremos con un Oficial de Seguridad, mientras que en las otras nos encontremos con "Don Quijote" luchando contra los molinos de viento.

Y aquí es donde queríamos llegar, aquellos "Don Quijote" que niegan accesos, bajan servicios, desinstalan programas, en definitiva cubren una serie de roles, menos el del Oficial de Seguridad. Ahora bien, ¿qué debería hacer un Oficial de Seguridad? en principio podríamos decir que su función principal es acompañar al negocio identificando los riesgos asociados a la actividad que se lleve a cabo, ofreciendo recomendaciones para el tratamiento oportuno de los mismos y en todo caso realizando el advisor necesario para que aquel que tome las decisiones cuente con toda la información requerida. Como se puede identificar, el rol es principalmente de asesor, de acompañamiento al negocio.

Teniendo en cuenta esto último, podríamos decir que entonces las distintas medidas de seguridad que se implementen, de acuerdo al tratamiento oportuno de los riesgos, no las estaría determinando el Oficial de Seguridad, sino el Dueño de los Datos involucrados. Lo que si estaría haciendo el Oficial de Seguridad es describir las alternativas que se podrían implementar con el objetivo de dar el tratamiento requerido por el Dueño de Datos. Nuevamente en un rol de asesoramiento a quien toma las decisiones. Finalmente producto de las decisiones de quien está a cargo de la gestión del riesgo, se realizarán las acciones que se consideren oportunas. Si en todo caso, la decisión ha sido asumir el riesgo identificado, es el Oficial de Seguridad quien deberá documentar la situación obteniendo la conformidad del Dueño de Datos, pero no para librar una batalla y convencerlo de que podría estar equivocado, sino para documentar el caso y continuar con sus otras actividades.

Si retornamos al escenario inicial donde la persona de seguridad estaba luchando contra la Organización, en este caso el Oficial de Seguridad ha documentado una decisión de negocio y continuará con sus actividades, dado que ha cumplido su rol de asesor para la toma de decisiones. En todo caso si la decisión por parte del Dueño de Datos ha sido errónea, la Organización pagará por tal equivocación y el Oficial de Seguridad deberá demostrar su "Debida Diligencia" habiendo realizado el "advisor" a quien ha tomado las decisiones, incluso evidenciando su disconformidad con las mismas.

Obviamente la Organización debería tener un grado de madurez en el cual se interpreten los distintos roles y las limitaciones de cada uno, dado que en otro escenario se intentaría culpar al Oficial de Seguridad por la equivocación del Dueño de Datos. Este tipo de organizaciones podría corresponder con aquellas donde el interés por la seguridad no cuenta con el apoyo de la Alta Dirección, sino que las iniciativas son generadas desde distintas áreas de staff.

Es aquí donde se podría identificar quizás el desafío más importante para un Oficial de Seguridad, y no es el hecho de capacitar a los usuarios, lograr que los desarrolladores contemplen cuestiones de seguridad, o que las áreas de IT documenten su trabajo. El desafío principal que podría enfrentar un Oficial de Seguridad es despertar el interés y compromiso por la Seguridad de la Información en la Alta Dirección o el Management de la Organización. Logrando esto último, todo lo anterior se podría realizar sin mayor conflicto, simplemente porque lo exige la Dirección.

Para lograr el establecimiento del escenario descripto, se deben conjugar una serie de cuestiones, tanto de las características personales y las competencias de quienes ocupen los distintos roles, como también de aquellas cuestiones culturales propias de la Organización.

Finalmente cabe destacar que los distintos roles descritos corresponden a lo establecido por las buenas prácticas y lo que se recomienda para el establecimiento del Gobierno de la Seguridad de la Información, donde dicho Gobierno claramente no depende de una persona o de un rol, sino de las distintas decisiones que tome el negocio, con el acompañamiento de los especialistas, pero limitando claramente la responsabilidad por el resultado final que determinará el grado de exposición de la Organización.

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

Contribución por Mariano M. del Río

Leer más...