Security Guardians: cómo escalar la seguridad
El problema de fondo
En casi todas las organizaciones el equipo de seguridad es, y seguirá siendo, pequeño en relación con el resto. Mientras tanto la empresa crece: más equipos de producto, más servicios, más agentes de IA y más integraciones entre sistemas, muchas veces aceleradas por adquisiciones. Si el modelo mental es que la seguridad «la hace el equipo de seguridad», ese equipo se convierte tarde o temprano en un cuello de botella, y la seguridad empieza a percibirse como lo que frena la entrega en lugar de lo que la protege.
La respuesta instintiva, sumar más personas al equipo central, no resuelve el problema de raíz, porque la brecha entre lo que la organización produce y lo que un equipo central puede revisar se agranda con cada nuevo equipo. Lo que sí escala es cambiar quién es dueño de la seguridad.
En BigCheese utilizamos esta estrategia que explicamos abajo, que está muy alineada a la culture of security de AWS, y justamente al programa de Security Guardians de AWS.
Culture of security vs. security culture
Vale la pena separar dos ideas que suelen confundirse. La security culture es la cultura del equipo de seguridad: sus prácticas, sus herramientas, su forma de trabajar. La culture of security, en cambio, es una propiedad de toda la organización: el grado en que cada equipo, de producto, de datos, de operaciones, asume la seguridad como parte de su trabajo y no como algo que delega.
El objetivo no es que todos se vuelvan expertos en seguridad, sino que la seguridad deje de ser responsabilidad exclusiva de un área. El equipo de seguridad pasa de ser el que hace a ser el que define el marco, provee herramientas y habilita; y cada equipo se vuelve dueño de la seguridad de lo que construye y opera. Es el mismo principio de responsabilidad compartida que ya aplicamos entre el proveedor cloud y nosotros, llevado hacia adentro de la organización.
Qué es un Security Guardian
Un Security Guardian es un integrante de un equipo de producto u operaciones que, de forma voluntaria, asume el rol de referente de seguridad dentro de su equipo. No deja de hacer su trabajo ni se transforma en auditor: funciona como una extensión del equipo de seguridad dentro de su propio equipo, el punto de contacto que acerca el contexto de seguridad a las decisiones del día a día y que, en el otro sentido, le lleva al equipo central el feedback de lo que pasa en la práctica. Este concepto incluso lo define AWS en su documentación oficial.
Su valor es doble. Hacia su equipo, baja la conciencia de seguridad al lugar donde se toman las decisiones técnicas, de modo que las buenas prácticas se discuten cuando todavía se pueden aplicar sin costo. Hacia el equipo de seguridad, cada Guardian es un sensor temprano: detecta fricciones, necesidades y riesgos mucho antes de que lleguen a una revisión formal, y permite que el equipo central escale su alcance sin escalar su tamaño.
Cómo armar el programa
Un programa de Guardians no se decreta, se construye. Conviene empezar por un grupo diverso de voluntarios que cubra distintos equipos y perfiles, en lugar de nombrar a dedo, porque el rol vive de la motivación genuina. Ese grupo inicial necesita un objetivo claro a nivel organización, algo que le dé sentido más allá de «ocuparse de seguridad», y un acompañamiento real del equipo central en forma de capacitación y mentoría para que puedan arrancar con confianza.
A partir de ahí, lo que sostiene el programa en el tiempo es la comunidad. Los Guardians necesitan un espacio donde compartir conocimiento de forma continua, resolver dudas y comparar experiencias entre equipos, de manera que el aprendizaje de uno se vuelva patrimonio de todos. Y necesitan que su trabajo se mida y se reconozca: tanto con señales cualitativas, como la calidad de las conversaciones de seguridad que habilitan, como con indicadores cuantitativos, y con un reconocimiento visible que valore el tiempo que dedican. Un canal de feedback abierto y permanente, en ambos sentidos, es lo que mantiene el modelo vivo y evita que degenere en un título vacío.
AWS de hecho propone cómo incluir los guardians en los equipos operativos en su documentación de Well-architected.
Cómo lo apoya la plataforma
La cultura es la parte difícil, pero sin las herramientas adecuadas los Guardians no pueden ejercer su rol. La clave es darles visibilidad sobre la seguridad de su propio equipo sin obligarlos a convertirse en especialistas. Consolidar los hallazgos de seguridad y los controles de compliance en un lugar común, por ejemplo con Security Hub y Security Lake, y luego presentar a cada Guardian la postura de su equipo o sus cuentas en un dashboard acotado a su ámbito, convierte una marea de alertas en algo accionable: cada quien ve lo suyo, con el contexto de su equipo.
Sobre esa base, el equipo central puede definir los controles y guardrails una sola vez y dejar que cada equipo los aplique, de modo que el Guardian trabaje dentro de un marco común en lugar de inventar criterios propios. La automatización ayuda a que el rol sea sostenible: enrutar los hallazgos al equipo correcto, abrir tickets automáticamente y recordar lo pendiente evita que la tarea dependa de la buena voluntad de revisar paneles. Así el Guardian dedica su tiempo a lo que de verdad requiere criterio, y no a tareas repetitivas que la plataforma puede resolver sola.
El rol del equipo central
En este modelo el equipo de seguridad no se achica ni pierde relevancia: cambia de función. Deja de ser el que revisa cada cambio y pasa a ser el que define el marco, construye las herramientas que los Guardians usan, forma a la comunidad y arbitra las decisiones difíciles. Dicho de otro modo, su éxito deja de medirse por cuántas revisiones hace y empieza a medirse por cuánta seguridad logra que ocurra sin su intervención directa.
Esa es la verdadera señal de madurez de una culture of security: cuando la mayoría de las buenas decisiones de seguridad se toman en los equipos, de forma cotidiana, y el equipo central puede enfocarse en el riesgo que realmente lo necesita.
