Las funciones y prácticas de SAMM

SAMM, en su versión 2, reparte el trabajo de seguridad del software en cinco funciones de negocio: Governance, Design, Implementation, Verification y Operations. Cada función tiene tres prácticas, quince en total. Cada práctica se divide en dos flujos, A y B, que miran dos lados del mismo trabajo, y cada flujo tiene tres niveles de madurez, del más sencillo al más exigente.

La estructura fija es lo que da valor al modelo: cualquier organización responde las mismas preguntas sobre las mismas prácticas, sea cual sea su tecnología. Y el modelo no pide llegar al nivel tres en todo; cada organización fija su objetivo por práctica según lo que protege y lo que puede sostener.

Abre el laboratorio y lee samm-modelo.txt para tener a mano los nombres.

Clasificar es el primer uso práctico del modelo: cada actividad del programa, hecha o propuesta, se asigna a la práctica que mejor la describe. Sin esa asignación no hay forma de saber qué función se está reforzando y cuál se queda igual. La regla es mirar el objetivo de la actividad, no la herramienta que usa: un mismo tablero puede servir para medir el programa o para seguir defectos, y son prácticas distintas.

En programa-2026.txt hay una propuesta para 2027 que nadie clasificó. Léela y busca en samm-modelo.txt la práctica cuya descripción encaja con lo que hace.

Es frecuente que un programa diga «Verification está cubierta» porque corre análisis estático y dinámico. Esas herramientas viven en una sola de las tres prácticas de la función. Las otras dos miran cosas que ninguna herramienta automática revisa por sí sola: si los controles que se exigieron funcionan como se pidió, y si la arquitectura aguanta las amenazas que se identificaron.

Cruza las actividades vigentes de programa-2026.txt con las tres prácticas de Verification del modelo.

ISO/IEC 27034 es una norma de varias partes sobre seguridad de aplicaciones; la primera, de 2011, da la visión general y los conceptos. Su idea central sirve aunque no se adopte la norma entera: la organización mantiene un marco común con sus políticas, procesos y controles de aplicación, y cada aplicación toma de ahí lo que le corresponde según el riesgo que se le asigna. Se aplica igual a lo que se desarrolla en casa, a lo que se compra y a lo que se encarga fuera.

Lo valioso de ese reparto es que el control se decide una vez, en el marco, y no se reinventa en cada proyecto. Y que dejar un control fuera es una decisión escrita, no un olvido.

Lee catalogo-controles.txt: dice que cada aplicación toma los controles de su nivel objetivo y de todos los inferiores, y que solo puede dejar uno fuera con una justificación aprobada. Después lee seleccion-portal-acudientes.txt. El portal tiene nivel objetivo alto, así que le tocan los doce controles salvo los que justifique.