Hay una forma muy costosa de hacer seguridad: incorporarla cuando la solución ya está prácticamente terminada.
El producto está definido. La arquitectura fue aprobada. El proveedor ya fue seleccionado. El desarrollo avanzó. Las integraciones están construidas. La fecha de salida está comprometida. Y entonces aparece seguridad.
En ese momento, cualquier hallazgo se siente como freno. Cualquier control se percibe como obstáculo. Cualquier observación parece una amenaza al calendario. Y cualquier riesgo detectado tarde se convierte en una negociación incómoda entre salir rápido, aceptar excepciones o rediseñar bajo presión.
En banca digital, ese modelo es peligroso.
La seguridad no debería entrar al final para bloquear. Debería entrar desde el diseño para reducir fragilidad, evitar retrabajo y construir confianza desde la arquitectura.
La idea de fondo es simple: la seguridad reduce más riesgo cuando se diseña antes de producción, no cuando intenta corregir una solución ya comprometida.
¿Qué es seguridad desde el diseño en banca digital?#
Seguridad desde el diseño es integrar criterios de ciberseguridad, riesgo, privacidad, compliance, evidencia y operación desde las primeras decisiones de una solución. En banca digital, significa que arquitectura y CISO trabajan juntos para identificar amenazas, definir controles proporcionales, proteger datos, diseñar trazabilidad y reducir exposición antes de producción.
El error: usar seguridad como revisión final#
Una revisión final de seguridad puede encontrar vulnerabilidades, pero llega tarde para influir con eficiencia en las decisiones que más importan.
Puede detectar que el modelo de identidad no escala, que los permisos son demasiado amplios, que los datos sensibles viajan sin clasificación, que el proveedor no tiene controles suficientes, que los logs no sirven para investigar, que las APIs no resisten abuso automatizado o que no existe evidencia adecuada para auditoría.
El problema es que, al final del proyecto, corregir ya cuesta más.
Corregir tarde implica renegociar alcance, retrasar fechas, aceptar excepciones, generar controles manuales, acumular deuda técnica o salir a producción con riesgo residual poco entendido.
La seguridad tardía no solo encuentra problemas; muchas veces descubre decisiones que ya fueron tomadas sin ver el riesgo.
Ese es el punto que arquitectura y CISO deben cambiar.
Seguridad desde el diseño no significa decir “no” antes#
Un mal entendimiento de seguridad desde el diseño es pensar que significa endurecer todo desde el inicio o bloquear cualquier iniciativa que no cumpla al cien por ciento una lista ideal de controles.
La seguridad desde el diseño ayuda a entender el riesgo, no a paralizar la ejecución. Se definen controles proporcionales, no se convierte cada solución en una fortaleza imposible de operar. Esto ayuda a tomar decisiones informadas, no a reemplazar el criterio de negocio, arquitectura o riesgo.
En una institución financiera, no todos los sistemas requieren el mismo nivel de control. No es igual una página informativa que un canal transaccional. No es igual un dashboard interno que una API pública. No es igual un proceso manual de backoffice que una decisión automatizada de crédito. No es igual un dato operativo que un dato personal sensible.
La seguridad desde el diseño requiere clasificación, contexto y criterio.
Su pregunta central no es:
¿Cómo bloqueo esto?
Su pregunta correcta es:
¿Qué nivel de protección, evidencia y resiliencia necesita esta capacidad para operar con confianza?
La alianza entre CISO y arquitectura#
El Chief Information Security Officer (CISO) y arquitectura deberían trabajar juntos desde el inicio de las iniciativas relevantes.
Arquitectura aporta visión estructural: capacidades, dominios, flujos, aplicaciones, integraciones, datos, infraestructura, nube, APIs, patrones, decisiones y dependencias.
El CISO aporta visión de riesgo: amenazas, exposición, controles, políticas, monitoreo, respuesta, cumplimiento, privacidad, continuidad y evidencia.
Cuando estas visiones se integran, el diseño mejora. Cuando se separan, aparecen antipatrones: patrones arquitectónicos sin criterios de seguridad, controles imposibles de implementar, excepciones repetidas, modelos de identidad inconsistentes, APIs expuestas sin protección contra abuso, datos sensibles sin clasificación, logging insuficiente, monitoreo débil y compliance reconstruyendo evidencia al final.
Seguridad desde el diseño no significa que el CISO diseñe toda la arquitectura. Significa que las decisiones arquitectónicas incorporen criterios de seguridad desde el inicio.
The Open Group, mediante TOGAF Standard, ayuda a entender la arquitectura empresarial como una disciplina que conecta estrategia, capacidades, procesos, información, aplicaciones y tecnología. Esa mirada es útil para que la seguridad deje de verse como una capa posterior y se incorpore como parte de las capacidades que la organización necesita operar.
Caso aplicado: un nuevo flujo de alta digital#
Imaginemos una institución financiera que quiere lanzar un flujo de alta digital para nuevos clientes.
El equipo de producto quiere reducir fricción. Negocio quiere elevar conversión. Tecnología busca reutilizar componentes existentes. Un proveedor externo ofrece validación documental. Riesgo pide controles antifraude. Compliance necesita evidencia. Seguridad exige protección de datos personales. Operaciones debe soportar excepciones y atención a clientes.
Si seguridad entra al final, probablemente revisará una solución ya armada: APIs expuestas, datos en tránsito, almacenamiento de documentos, integraciones con terceros, permisos, logs, consentimiento, trazabilidad, retención y monitoreo.
Si seguridad entra desde el diseño, la conversación cambia.
Desde el inicio se pueden definir datos mínimos necesarios, clasificación de información, modelo de consentimiento, autenticación, autorización, protección contra automatización, controles antifraude, segregación de roles, evidencias, trazabilidad de decisiones, criterios de monitoreo, gestión de terceros y escenarios de falla.
El resultado no es una solución más lenta. Es una solución menos frágil.
Diseñar seguridad temprano permite reducir retrabajo, excepciones y riesgo residual antes de comprometer producción.
Threat modeling: pensar escenarios antes de construir#
El threat modeling, o modelado de amenazas, es una práctica especialmente útil para seguridad desde el diseño.
No se trata de llenar formatos por cumplir. Se trata de pensar, antes de construir, qué puede salir mal, qué activo se quiere proteger, quién podría abusar del sistema, qué flujo es sensible, qué dependencia es crítica y qué control sería proporcional.
En banca digital, el threat modeling puede ayudar a identificar escenarios como abuso de APIs, enumeración o listado de clientes, manipulación de parámetros, robo de sesión, uso indebido de credenciales, exposición de datos personales, bypass de validaciones, dependencia de terceros, fraude transaccional, errores de autorización o logging insuficiente.
La pregunta no es solo “¿qué vulnerabilidad existe?”. La pregunta es más amplia:
¿Qué escenario de abuso o falla podría afectar al cliente, la operación, el cumplimiento o la confianza?
El National Institute of Standards and Technology (NIST), en The NIST Cybersecurity Framework (CSF) 2.0, organiza la gestión de ciberseguridad alrededor de funciones como gobernar, identificar, proteger, detectar, responder y recuperar. Esa estructura refuerza una idea importante: la seguridad no se limita a prevenir; también debe gobernarse, detectarse, responderse y recuperarse.
OWASP ASVS: convertir seguridad en requisitos verificables#
Una dificultad común es que “seguridad” se vuelve una palabra demasiado amplia.
Para aterrizarla, marcos como OWASP Application Security Verification Standard (ASVS) son útiles. OWASP ASVS proporciona una base para probar controles técnicos de seguridad en aplicaciones y una lista de requisitos para desarrollo seguro.
Esto ayuda a transformar conversaciones genéricas en requisitos concretos: autenticación, manejo de sesiones, control de acceso, validación de entrada, criptografía, manejo de errores, logging, protección de datos, configuración segura, APIs y servicios.
En banca digital, esto es valioso porque evita que la seguridad dependa únicamente del criterio individual de cada proyecto. Permite definir estándares reutilizables, niveles de exigencia y criterios mínimos según criticidad.
La seguridad desde el diseño necesita requisitos verificables, no solo buenas intenciones.
Compliance desde el diseño: evidencia que nace de la operación#
Compliance no debería aparecer al final para pedir capturas, formatos o aprobaciones retrospectivas.
En una institución financiera, muchas obligaciones pueden diseñarse desde el inicio como capacidades: trazabilidad de accesos, bitácoras, segregación de funciones, retención, cifrado, control de cambios, monitoreo, evidencias de pruebas, aprobaciones, clasificación de datos, gestión de terceros y seguimiento de excepciones.
La evidencia más fuerte no es la que se arma después. Es la que se produce naturalmente porque la operación está bien diseñada.
Aquí ISO ayuda como referencia. ISO/IEC 27001:2022 define requisitos para establecer, implementar, mantener y mejorar un sistema de gestión de seguridad de la información. Su valor no está en producir documentos, sino en conectar riesgos, controles, responsabilidades, operación, evaluación y mejora continua.
En banca digital, compliance desde el diseño reduce fricción porque convierte obligaciones en requerimientos arquitectónicos y operativos desde etapas tempranas.
Seguridad en APIs, nube y terceros#
La seguridad desde el diseño es especialmente importante en tres frentes: APIs, nube y terceros.
En APIs, deben definirse autenticación, autorización, scopes, rate limiting, protección contra abuso automatizado, validación de entrada, manejo de errores, logging, monitoreo y versionamiento.
En nube, deben diseñarse identidades, redes, cifrado, llaves, secretos, políticas, hardening, monitoreo, segregación, respaldos, continuidad y guardrails. La nube no es insegura por naturaleza, pero puede volverse riesgosa si se opera sin patrones y gobierno.
En terceros, deben evaluarse criticidad, datos compartidos, controles, integración, notificación de incidentes, continuidad, evidencias, monitoreo, dependencia operativa y plan de salida.
La seguridad desde el diseño evita que estos temas aparezcan como hallazgos tardíos. Los convierte en decisiones visibles.
Guardrails, barreras de seguridad: habilitar velocidad con límites claros#
Un buen modelo de seguridad no debería depender solo de revisiones manuales.
Los guardrails ayudan a que los equipos construyan dentro de límites seguros: políticas cloud, plantillas de infraestructura, patrones de API, controles de pipeline, escaneo de secretos, análisis de dependencias, revisiones de contenedores, configuraciones base, librerías aprobadas, monitoreo mínimo y criterios de despliegue.
La diferencia entre control y guardrail es importante.
Un control puede detectar una desviación. Un guardrail ayuda a evitar que la desviación ocurra o se vuelva recurrente.
Los guardrails bien diseñados no frenan la velocidad; reducen la improvisación que luego destruye la velocidad.
Qué debería definirse antes de producción#
Antes de producción, una solución relevante en banca digital debería tener claridad en varios puntos.
- Primero, activos críticos: datos, procesos, APIs, identidades, documentos, transacciones y evidencias.
- Segundo, amenazas principales: abuso, fraude, fuga, error operativo, indisponibilidad, terceros o elevación de privilegios.
- Tercero, controles mínimos: identidad, autorización, cifrado, logging, monitoreo, protección de APIs, gestión de secretos, retención y segregación.
- Cuarto, responsabilidad: quién opera, quién monitorea, quién aprueba excepciones y quién acepta riesgo residual.
- Quinto, evidencia: qué se registra, dónde queda, quién la consulta y cómo se conserva.
- Sexto, respuesta: qué alertas existen, qué runbooks aplican y cómo se escala un incidente.
Esta claridad permite que seguridad no sea una revisión tardía, sino parte del diseño.
Antipatrones de seguridad desde el diseño#
Algunos antipatrones aparecen con frecuencia:
- seguridad revisando solo al final;
- threat modeling convertido en formato sin discusión;
- compliance pidiendo evidencia que la arquitectura no genera;
- controles definidos sin dueño operativo;
- APIs públicas sin protección contra abuso;
- permisos amplios para salir rápido;
- logs insuficientes para investigar;
- excepciones sin fecha de expiración;
- terceros integrados sin criticidad clara;
- cloud sin guardrails mínimos.
Estos antipatrones no son solo problemas técnicos. Son síntomas de una organización que diseña seguridad tarde.
Mi postura: seguridad debe entrar cuando todavía puede cambiar decisiones#
Una revisión de seguridad tiene más valor cuando todavía puede influir en el diseño.
Si llega cuando todo está construido, su poder real se reduce a bloquear, aceptar riesgo o pedir correcciones bajo presión. Eso desgasta a todos: seguridad parece freno, tecnología siente retrabajo, negocio presiona fechas, compliance pide evidencia y riesgo recibe excepciones.
Si llega temprano, puede orientar decisiones: elegir mejor patrón, limitar exposición, reducir datos innecesarios, definir evidencias, seleccionar controles proporcionales, evitar dependencias peligrosas y preparar operación.
La seguridad desde el diseño no elimina el riesgo; evita que el riesgo se descubra demasiado tarde.
Reflexión de arquitectura: seguridad es estructura, no adorno#
Como arquitecto, veo la seguridad como una propiedad estructural de la solución.
No debería aparecer como anexo. No debería depender de buena voluntad. No debería variar radicalmente por proyecto. No debería descubrirse en la revisión final.
Una arquitectura segura muestra cómo se protegen datos, identidades, integraciones, APIs, secretos, plataformas, trazas, decisiones y operaciones.
También muestra cómo se detecta una anomalía, cómo se responde, cómo se evidencia y cómo se recupera.
Cuando seguridad está bien integrada, la arquitectura no solo explica cómo funciona una solución. Explica cómo se protege, cómo se gobierna y cómo se sostiene.
Reflexión CTO: la confianza se construye antes de producción#
Desde una mirada CTO, seguridad desde el diseño es una inversión en velocidad sostenible.
Una organización que descubre riesgos al final vivirá entre urgencias, excepciones y retrabajo. Una organización que integra seguridad desde el diseño puede moverse más rápido porque reduce incertidumbre antes de comprometer producción.
La confianza no aparece mágicamente el día del go-live. Se construye en cada decisión previa: qué datos usar, qué controles aplicar, qué proveedor integrar, qué patrón reutilizar, qué riesgo aceptar, qué evidencia conservar y qué operación sostener.
En banca digital, producir rápido no basta. Hay que producir con capacidad de defender lo que se construye.
Esa defensa no es solo jurídica o documental. Es arquitectónica, operativa y técnica.
Conclusión: reducir riesgo antes de que sea deuda#
Seguridad desde el diseño no es un eslogan. Es una forma más madura de construir tecnología en instituciones financieras.
Implica que CISO y arquitectura trabajen juntos desde el inicio para entender riesgos, modelar amenazas, definir controles, proteger datos, diseñar evidencias, integrar compliance y preparar operación.
El objetivo no es frenar innovación. Es evitar que la innovación llegue a producción cargada de fragilidad.
Cuando la seguridad se incorpora tarde, el riesgo ya está embebido en la solución. Cuando se incorpora desde el diseño, el riesgo puede reducirse antes de convertirse en deuda.
En banca digital, esa diferencia importa.
La confianza se diseña antes de producción.
Glosario breve#
Seguridad desde el diseño
Enfoque que integra controles, análisis de riesgos, protección de datos, monitoreo, evidencia y criterios de seguridad desde las primeras decisiones de una solución.
CISO — Chief Information Security Officer
Ejecutivo responsable de liderar la estrategia de seguridad de la información y ciberseguridad de una organización.
Threat modeling
Práctica para identificar amenazas, escenarios de ataque, activos críticos, riesgos y controles necesarios durante el diseño de una solución.
DevSecOps
Enfoque que integra seguridad dentro del ciclo de desarrollo, integración, despliegue y operación de software.
ASVS — Application Security Verification Standard
Estándar de OWASP que proporciona una base de requisitos para verificar controles técnicos de seguridad en aplicaciones web y servicios.
NIST CSF — NIST Cybersecurity Framework
Marco del National Institute of Standards and Technology para gestionar riesgos de ciberseguridad mediante funciones como gobernar, identificar, proteger, detectar, responder y recuperar.
ISO/IEC 27001
Estándar internacional para sistemas de gestión de seguridad de la información. Ayuda a estructurar políticas, riesgos, controles, responsabilidades y mejora continua.
SIEM — Security Information and Event Management
Capacidad o plataforma para recolectar, correlacionar y analizar eventos de seguridad con fines de detección, investigación y respuesta.
Guardrails
Controles, políticas o límites preventivos que ayudan a que los equipos construyan dentro de parámetros seguros y gobernados, especialmente en cloud y plataformas digitales.
TOGAF — The Open Group Architecture Framework
Estándar de arquitectura empresarial desarrollado por The Open Group. Ayuda a conectar estrategia, capacidades, procesos, información, aplicaciones y tecnología.
Referencias#
National Institute of Standards and Technology (NIST), The NIST Cybersecurity Framework (CSF) 2.0 — Estados Unidos, referencia de adopción internacional para gestión de riesgos de ciberseguridad
https://www.nist.gov/publications/nist-cybersecurity-framework-csf-20National Institute of Standards and Technology (NIST), The NIST Cybersecurity Framework (CSF) 2.0 PDF
https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.29.pdfOWASP, Application Security Verification Standard (ASVS) — alcance global para verificación de controles técnicos de seguridad en aplicaciones
https://owasp.org/www-project-application-security-verification-standard/OWASP, Application Security Verification Standard (ASVS) GitHub Repository
https://github.com/OWASP/ASVSISO, ISO/IEC 27001:2022 — Information security management systems — alcance global para sistemas de gestión de seguridad de la información
https://www.iso.org/standard/27001The Open Group, The TOGAF Standard — alcance global para arquitectura empresarial
https://www.opengroup.org/togafComisión Nacional Bancaria y de Valores (CNBV), Sitio institucional — México
https://www.gob.mx/cnbvBanco de México, Seguridad de la información — México
https://www.banxico.org.mx/sistema-financiero/seguridad-informacion-banco.html