Historia de la cuestión:
Los requisitos de seguridad de la información son una parte fundamental de los grandes proyectos de TI desde los tiempos en que comenzaron a aparecer los primeros estándares de auditoría de seguridad (por ejemplo, ISO 27001 o los requisitos de la Ley Federal 152 en Rusia). Sin un análisis claro y una formalización de los requisitos, la seguridad del sistema corre el riesgo de ser declarativa e impracticable.
Problema:
Los requisitos de seguridad a menudo se formulan de manera abstracta ("todo debe estar protegido"), no tienen en cuenta los procesos comerciales reales y la arquitectura, y no se desglosan por niveles: organizativo, tecnológico y de usuario. Además, los clientes y los desarrolladores pueden interpretar de manera diferente los mismos requisitos, lo que genera una discrepancia entre la viabilidad y la normativa.
Solución:
El analista de sistemas comienza estudiando los estándares corporativos, gubernamentales y sectoriales (por ejemplo: GOST, GDPR, PCI DSS, ISO 27001). Luego, junto con el arquitecto y los responsables de seguridad, identifica los procesos críticos para el negocio, los puntos de almacenamiento y transmisión de datos, las posibles amenazas, y define la lista de riesgos correspondientes. Con base en esto, el analista prepara una matriz detallada de requisitos sobre acceso, almacenamiento, registro, cifrado, así como escenarios de incidentes. Después de la aprobación, los formaliza en documentos, de tal manera que cada requisito pueda ser verificado mediante pruebas o durante una auditoría.
Características clave:
¿Por qué no se puede confiar solo en las medidas técnicas de seguridad de la información (antivirus, cortafuegos, SIEM)?
Porque la seguridad de la información es un proceso, no solo un conjunto de sistemas. Las procedimientos organizativos, el factor humano, las verificaciones regulares y la formación de usuarios desempeñan un papel crucial.
¿Se pueden considerar los requisitos cumplidos si el sistema solo ha pasado pruebas internas?
No, a menudo se requiere una auditoría externa, certificación y, en ocasiones, pruebas de estrés bajo la supervisión de un regulador para cumplir con las normativas.
¿Es suficiente simplemente incluir en el pliego de condiciones el requisito "el sistema debe estar protegido según la Ley Federal 152"?
No es suficiente: es necesario especificar medidas concretas (control de acceso, almacenamiento de registros de eventos, cifrado de datos), los lugares de su implementación y criterios de verificación.
Caso negativo: En un proyecto de banca en línea, el analista incluyó en el pliego de condiciones solo la frase general "se deben cumplir los requisitos de la Ley Federal 152". Los contratistas implementaron la autorización estándar y el certificado SSL, y en la etapa de auditoría externa se descubrió la falta de control sobre el almacenamiento de datos y un registro de autenticación no protegido.
Ventajas:
Desventajas:
Caso positivo:
Al inicio del proyecto, el analista de sistemas acordó con los responsables de seguridad y el cliente una lista de amenazas, desarrolló requisitos detallados sobre cifrado y auditoría para cada escenario, y definió a los responsables. Al final, el sistema pasó la auditoría sin observaciones.
Ventajas:
Desventajas: