lunes, 9 de mayo de 2016

Los grises que no deben ser grises

Inspirado en la invitación a participar como expositor en el Congreso de la VIII CONAI del año 2015, hace un tiempito atrás escribí un artículo sobre la Auditoría Interna y los Hackers donde básicamente daba mi visión sobre cómo los profesionales del hacking pueden aportar valor a los procesos de auditoría interna.  Particularmente basada mi postura en la colaboración entre “ambos mundos” en:
  • Evaluar los controles técnicos y estrategias de IT.
  • Evaluar los procesos y procedimientos de IT.
  • Evaluar las campañas de concientización y sus métricas.
 
También mencionaba, tanto en la charla como en el artículo, que al fin y al cabo se trata de trabajar en equipo y agregar valor a la empresa u organización que nos contrata.   Sin embargo, muchas personas, sobre todo de las áreas de auditoría, me comentaban que les cuesta mucho acercar posiciones y estrategias con Seguridad de la Información, más precisamente con los perfiles técnicos de esas áreas.


Por qué sucede esto normalmente?  Porque justamente, intentamos (de ambos lados) convencer a nuestros colegas de que trabajen de una determinada manera, sin comprender que la otra persona tiene otra visión, otra especialización y otros objetivos inherentes a sus funciones, a su propia formación y posiblemente a sus propios gustos personales afines al tema en cuestión.

Cómo subsanarlo? Intentar cambiar la visión y la especialización de un profesional de seguridad o de un auditor, es un camino largo, pero sobre todo, sin sentido.  Cada uno debe mantener su visión y su especialización para sumar valores, para no perder el foco, y para no dejar de hacer lo que cada uno eligió como carrera porque le gusta o lo motiva personalmente.   Entonces es simple: nos queda trabajar en los objetivos, establecer en conjunto cuáles son los puntos en los que puedan colaborar mutuamente y definir un esquema de trabajo basado en el análisis de riesgos.   

Aunque parece fácil, aquí se presenta otro nuevo problema, de esos que parecen insalvables: los auditores están acostumbrados a hablar en función de riesgos, pero las personas técnicas del mundo de la seguridad normalmente hablamos de vulnerabilidades, no de riesgos...

Existen muchos libros que hablan sobre riesgo tecnológico, sobre riesgo operacional, etc. pero claramente no es el tipo de literatura que una persona técnica especializada en seguridad quiera leer, como tampoco un libro sobre Pentesting en protocolos de Layer2 y Layer3 sea una literatura que un auditor quiera leer, es entonces que surge la necesidad de establecer mesas de debate para compartir y definir al menos dos caminos de trabajo:
  1. De vulnerabilidades a riesgos:  implica dejar que los profesionales hagan un trabajo de análisis de seguridad completo, detecten todas las vulnerabilidades posibles y luego debatir junto a los auditores internos el cómo los resultados de los hallazgos impactan sobre el análisis de riesgos de la organización.

    Por ejemplo: En el informe de seguridad podrían aparecer vulnerabilidades tipo uso de protocolos sin cifrado, contraseñas triviales, bases de datos sin control de acceso adecuado, etc. que podrían implicar el riesgo de fuga de información confidencial para la organización.
  2. De riesgos a vulnerabilidades: implica que previamente a un análisis de seguridad, el equipo de auditoria defina cuales son los riesgos principales que quiere saber si están controlados o no, y luego de debatirlo con el equipo de técnico de seguridad, éstos últimos comiencen sus pruebas con objetivos bien definidos.

    Por ejemplo: Si el objetivo es medir el riesgo de interrupción del proceso de facturación de la organización, el equipo de seguridad deberá buscar todas las vulnerabilidades asociadas a los sistemas de facturación, a las personas del sector, a los procesos relacionados, etc. que podrían permitir que un potencial atacante interno o externo evite que la organización facture por un tiempo determinado.

Definir modelos de colaboración entre las áreas no es sencillo, eso está claro, y la excusa más común que podemos escuchar dice: “es una zona gris, no está definido quien debe hacerse cargo de controlarlo, de detectarlo, etc.”.  Cuando a mí me dicen que un proceso no está controlado porque está en “una zona gris”, lo primero que pienso, es que si hay grises en las funciones de control de los riesgos de una organización, es porque las personas no fueron capaces de sentarse a tratar de arrimar posiciones, sino que cada una de las áreas involucradas intentó superponer su posición sobre la otra.

“El que quiere subir, inventa la escalera”. Proverbio Japones.

Gracias a la iaiperu.org por haberme invitado a la CONAI del 2015 y a escribir este post.

Claudio Caracciolo
Chief Security Ambassador at Eleven Paths
claudio.caracciolo@11paths.com
www.elevenpaths.com
@holesec

No hay comentarios.:

Publicar un comentario