La seguridad por diseño en proyectos tecnológicos consiste en tomar decisiones de protección antes de que una solución quede contratada, desarrollada o integrada. No es una revisión final para “aprobar seguridad”, sino una forma de definir desde el inicio qué datos utilizará el proyecto, qué dependencias creará, quién podrá administrarlo y qué evidencia permitirá aceptarlo.
Para una empresa chilena, este enfoque reduce una dificultad frecuente: descubrir controles ausentes cuando el presupuesto ya está comprometido, la fecha de salida es inamovible y corregir exige rediseñar. La conversación útil comienza cuando todavía existen alternativas.
La seguridad empieza con el propósito del proyecto
Antes de escoger controles, el equipo necesita entender el resultado de negocio. Conviene identificar qué proceso cambiará, qué información ingresará o generará la solución, con cuáles sistemas se conectará y qué impacto tendría una indisponibilidad, alteración o divulgación. La clasificación de la información ayuda a que estas respuestas modifiquen decisiones concretas sobre acceso, almacenamiento, intercambio y conservación.
NIST Cybersecurity Framework 2.0 sitúa el gobierno y la comprensión del riesgo antes de las actividades de protección. Aplicado a un proyecto, esto implica asignar responsables y criterios de aceptación, no delegar toda la seguridad al área técnica. El dueño del proceso aporta el impacto; Tecnología explica arquitectura y operación; Seguridad plantea escenarios y verificaciones; Compras y Legal convierten requisitos en compromisos cuando participa un proveedor.
Definir resultados, no una lista genérica
Un requisito como “cumplir buenas prácticas” es difícil de comprobar. Resulta más útil describir resultados observables: las cuentas administrativas están separadas de las cuentas de uso diario; los accesos se revocan al terminar una función; los registros permiten reconstruir acciones críticas; la información sensible viaja y se almacena protegida; una restauración puede ejecutarse dentro de los objetivos definidos.
Cada resultado debe tener un responsable, una evidencia y un momento de validación. Algunas verificaciones ocurren en el diseño, otras durante pruebas y otras al preparar la operación. Así, seguridad deja de ser una opinión tardía y se convierte en una condición trazable del proyecto.
Incorporar seguridad al trabajo del proyecto
NIST SP 800-218 propone integrar prácticas de desarrollo seguro al ciclo de vida, en lugar de tratarlas como una fase aislada. Aunque su foco es software, la lógica también ayuda a ordenar proyectos que configuran o adquieren tecnología: preparar a las personas y procesos, proteger los componentes, producir una solución con prácticas definidas y responder a vulnerabilidades.
Esto no exige transformar cada iniciativa en un programa documental. Un proyecto pequeño puede mantener un registro breve de decisiones, responsables y pruebas. Uno crítico puede requerir modelado de amenazas, revisión de arquitectura, análisis de componentes, pruebas especializadas y un plan formal de remediación. La profundidad cambia según exposición e impacto; el principio es que las decisiones no desaparezcan entre correos y reuniones.
Comprar tecnología también requiere diseño
Cuando la solución es de un tercero, la empresa no diseña el producto, pero sí diseña su forma de selección, configuración, integración y uso. La guía de CISA para elegir tecnologías seguras y verificables recomienda que las organizaciones compradoras evalúen características de seguridad y la posibilidad de verificar su funcionamiento.
Importa conocer opciones de autenticación, registros disponibles, gestión de vulnerabilidades, actualizaciones, exportación de datos, subcontratistas y condiciones de salida. El artículo sobre evaluación del riesgo de proveedores tecnológicos desarrolla la supervisión durante la relación; en el proyecto, la tarea específica es convertir esas necesidades en criterios de selección y aceptación antes de depender de la solución.
Crear puertas de decisión verificables
Un proyecto debería detenerse en puntos breves y conocidos: aprobación del diseño, autorización para conectar datos reales, aceptación técnica y paso a producción. En cada puerta se revisan solo las evidencias necesarias para esa decisión. Los hallazgos deben quedar resueltos, compensados o aceptados por quien tenga autoridad, con plazo y responsable.
También se necesita un criterio para cambios. Una nueva integración, el uso de datos más sensibles o la exposición a internet puede invalidar la evaluación original. La trazabilidad permite reconocer cuándo volver a revisar, sin repetir todo el proceso ante ajustes menores.
Preparar la operación antes del lanzamiento
La salida a producción no termina el proyecto de seguridad. Deben quedar definidos el dueño del servicio, las rutas de escalamiento, el tratamiento de vulnerabilidades, las revisiones de acceso, los respaldos, los registros y las condiciones para retirar la solución. Un control que depende de una persona del equipo de implementación puede desaparecer cuando esa persona vuelve a sus funciones habituales.
La asesoría estratégica de ciberseguridad puede ayudar a integrar estos criterios con prioridades, gobierno y riesgo empresarial. Una auditoría de seguridad puede contrastar posteriormente si los requisitos, configuraciones y evidencias acordados siguen operando. El objetivo es simple: que una decisión temprana evite una corrección costosa y deje controles que puedan sostenerse después del proyecto.
Fuentes consultadas
- NIST Cybersecurity Framework 2.0.
- NIST SP 800-218: Secure Software Development Framework 1.1.
- CISA: Choosing Secure and Verifiable Technologies.
