Respuesta

Historia de la cuestión:
En los últimos años ha aumentado el número de ataques a sistemas de información, y los requisitos para la protección de datos se han endurecido por ley. Las empresas requieren un enfoque integral y continuo sobre cuestiones de seguridad en todas las etapas del ciclo de vida del producto.

Problema:
Los requisitos no funcionales de seguridad a menudo se formulan de manera vaga o se copian de estándares sin adaptarse a la especificidad del proyecto. Esto lleva a altos riesgos, repeticiones o tareas incumplibles para el equipo de TI.

Solución:
El analista debe:

1. Comprender el entorno normativo (por ejemplo, GDPR, Ley Federal 152, ISO/IEC 27001) y adaptarlo a las necesidades del proyecto.
2. Durante las entrevistas con expertos en seguridad de la información, registrar amenazas y requisitos específicos (cifrado, auditoría, control de acceso).
3. Descomponer los requisitos en un formato conveniente para arquitectos y desarrolladores (criterios de seguridad claros, políticas de contraseñas, requisitos de registro y reporte).
4. Alinear las medidas técnicas con el equipo para implementarlas sin bloquear los procesos.

Características clave:

• Interacción obligatoria con expertos en seguridad
• Traducción de requisitos normativos en tareas técnicamente realizables
• Mantener la documentación actualizada

Preguntas capciosas.

¿Se puede confiar completamente en las listas de verificación de seguridad de la información al formular requisitos?

Las listas de verificación son útiles como punto de partida, pero no cubren todas las particularidades empresariales. Los requisitos de seguridad deben discutirse individualmente para cada proyecto.

¿Es obligatoria la auditoría de seguridad para todas las partes del sistema?

Algunos módulos pueden no procesar datos sensibles o ser internos. Sin embargo, el análisis de riesgos es obligatorio para toda la solución. Se implementa el principio de acceso mínimo necesario.

¿Vale la pena intentar implementar los requisitos de seguridad al 100%?

En general, se implementan las medidas más críticas que correspondan a la clasificación de datos y al nivel de amenazas. "La seguridad absoluta" es un mito; los compromisos son inevitables, es importante gestionar los riesgos.

Errores típicos y anti-patrones

• Copia formal de requisitos sin considerar la especificidad
• Insuficiente detalle (por ejemplo, "usar cifrado" sin definir estándares)
• Falta de revisión regular de seguridad ante cambios en el sistema

Ejemplo de la vida real

Caso negativo: Los requisitos de seguridad se redujeron al punto "cumplimiento con el estándar ISO" y se olvidaron de la configuración del cifrado del canal de transmisión de datos. Resultado: incidente, multa. Ventajas: Se elaboró rápidamente la documentación. Desventajas: Vulnerabilidad real y problemas durante la auditoría.

Caso positivo: El analista involucró a un especialista en seguridad de la información, realizó una sesión de análisis de amenazas, y documentó los requisitos en forma de criterios de aceptación. Todas las medidas fueron acordadas y realizables. Ventajas: Se implementó la protección, se superó exitosamente la auditoría. Desventajas: Se necesitó más tiempo y esfuerzo para la alineación.