Entre en casi cualquier empresa de software y pregunte dónde vive su seguridad. La respuesta rara vez es una persona con un mandato claro. Es una hoja de cálculo con los hallazgos de la última prueba de penetración, una cola de tickets que alguien va resolviendo poco a poco y una casilla de cumplimiento que hay que marcar antes del lanzamiento. Nada de eso está mal, exactamente - solo que no es una estrategia de seguridad. Es un montón de cosas que pasaron y que ahora se saldan con retraso.
La diferencia importa porque el modelo de tickets tiene un techo. Solo puede reaccionar a lo que ya se ha encontrado, y trata la seguridad como un centro de costes cuyo único trabajo es cerrar huecos a posteriori. Una función, en cambio, es algo que diseñas, nombras, acotas, construyes y - clave - mides. No se llega a la segunda clase emitiendo tickets.
Por qué el modelo de tickets falla con retraso
Una acumulación de hallazgos de auditoría tranquiliza porque produce actividad: se abren tickets, se asignan, se cierran. Pero esa actividad mira hacia atrás. Limpia lo que la última auditoría se fijó en ver, que no es lo mismo que saber a qué podría llegar de verdad un atacante decidido. Las listas de hallazgos hablan del pasado. Un modelo de amenazas habla del presente - y del futuro que importa, que es aquel en el que tu producto cambia.
Peor aún: el modelo de tickets no tiene un responsable natural más allá de quien esté con el ratón en la mano cuando llega la siguiente auditoría. La seguridad se convierte en algo que es de todos, lo que en la práctica significa que no es de nadie. El equipo publica un cambio que ensancha en silencio una regla de acceso, y nadie lo nota hasta el siguiente análisis trimestral. El hallazgo se registra, el ciclo se repite y el sistema se desvía un poco más cada vez.
La responsabilidad vive en un responsable, no en una cola
El primer paso para convertir la seguridad en una función es darle un responsable con nombre y apellidos y con un mandato que sobreviva a un lanzamiento. No un departamento de seguridad que audita a distancia - sino una persona o un equipo cuya descripción del puesto incluya las palabras "secure by design" y que esté en la sala cuando se deciden la arquitectura y el alcance, no solo cuando se incumple una fecha. Cuando un desarrollador tiene una duda sobre una decisión de control de acceso, hay una única persona a la que acudir, y esa persona tiene autoridad para decir que no.
La propiedad es la diferencia entre una lista de verificación a la que se consulta y una lista a la que se culpa. Sobre el papel ambas son idénticas. La diferencia aparece la primera vez que alguien tiene que tomar una decisión de criterio bajo presión, y la respuesta a "¿quién decide?" es una persona, no una reunión.
Empiece por un modelo de amenazas, no por una lista de cumplimiento
Las listas de cumplimiento son techos disfrazados de suelos. Te dicen el mínimo que un auditor quiere ver, y a un atacante decidido tu auditor le da igual. Lo que de verdad predice cuánto daño puede hacer un atacante es un modelo de amenazas: un relato escrito de lo que un atacante querría de tu sistema, las rutas que podría tomar para conseguirlo y cuáles de esas rutas te harían más daño.
El modelo no es un documento que archivas una sola vez. Es un artefacto vivo que se actualiza cada vez que el sistema cambia de un modo que altera la superficie de ataque - un nuevo tipo de dato, una nueva integración, un nuevo rol. Si cambia una ruta, cambian también los controles que la protegen. Una lista responde a "¿qué estamos obligados a mostrar?" Un modelo de amenazas responde a la pregunta que de verdad te quita el sueño: "¿cuál es la peor forma en que esto puede fallar, y hemos decidido que ese riesgo es aceptable?"
El cumplimiento te dice qué comprobará un auditor. Un modelo de amenazas te dice qué intentará un atacante. Solo uno de los dos te protege.
Mida los controles, no la casilla
Un control que no puedes medir es una casilla. "La API exige autenticación" suena a afirmación y se comporta como una esperanza. La seguridad medida se ve distinta: ¿cuántas credenciales expuestas hay en el código y ese número está bajando? ¿Cuánto tarda en detectarse que una regla de acceso se ha ensanchado sin aprobación, y se puede empujar esa cifra de meses a minutos? ¿Qué porcentaje de secretos se rota con calendario, y cuál es la excepción más duradera?
Elegir las métricas es en sí parte del trabajo de diseño. Una función de seguridad se mide como se mide cualquier función: te pones de acuerdo en el resultado, lo instrumentas y miras la línea de tendencia entre versiones en lugar de un aprobado o suspenso binario de un solo día. Cuando la seguridad se mide, se convierte en algo que puedes dirigir, presupuestar y mejorar - que es exactamente lo que es una función, y lo que no es un ticket.
Ponga precio a la seguridad como a una función, no como a un impuesto
Los equipos que tratan la seguridad como un impuesto la exprimen en el último cinco por ciento del sprint, justo cuando la presión por publicar es máxima, lo que garantiza que reciba el trabajo menos pensado. Los equipos que la tratan como una función la acotan igual que cualquier otra capacidad: con una asignación explícita de tiempo, su propio responsable y un punto de revisión en el que se cuestiona su eficacia en lugar de darla por sentada. La diferencia no es el esfuerzo - es el punto del ciclo en el que ese esfuerzo se produce.
Esto también es una decisión de precio. Un socio que incluye la seguridad de propina no tiene incentivo para hacerla medible, porque su coste está escondido en un precio global y su calidad nunca se inspecciona. Un socio que trata la seguridad como una línea de trabajo acotada te da las dos cosas que el modelo de tickets nunca da: una partida visible de la que puedes exigirle cuentas y una manera de saber - mientras el trabajo ocurre, no después de un incidente - si estás recibiendo lo que pagas.
Preguntas para su próximo proveedor
¿Quién es responsable de la seguridad en tu equipo y esa persona está en la sala cuando se acuerda el alcance - o solo cuando algo se rompe? ¿Cómo es tu modelo de amenazas actual y cuándo se actualizó por última vez? Explícame un control de seguridad que midas entre versiones y qué muestra la línea de tendencia. Cuando pido una auditoría de seguridad, ¿quién sufre las consecuencias de los hallazgos - tú o yo? Si las respuestas son vagas, la seguridad es vaga, y los tickets serán tuyos.
La seguridad como función es la manera de que el software siga siendo algo que posees en lugar de algo por lo que solo eres responsable. En términos honestos no cuesta más - invierte el esfuerzo antes y de forma visible, donde se puede medir y dirigir, en lugar de tarde e invisible, donde solo se puede pagar. La prima que pagas no es por más seguridad. Es por saber, en cualquier momento, exactamente lo segura que estás.