Comprender la arquitectura del sistema
Tan pronto como sea posible, posiblemente tan pronto como la fase de definición de la solución, obtenga y comprenda la arquitectura del sistema.
- ¿Cuáles son las aplicaciones y componentes de software utilizados en el sistema?
- ¿Cómo están conectadas o integradas las aplicaciones y los componentes?
- ¿Cuáles son los tipos y la sensibilidad de los datos almacenados en el sistema?
- ¿Quiénes son los usuarios finales del sistema y dónde se encuentran?
- ¿Cuáles son los escenarios de caso de uso esperados?
- ¿Cuáles son los requisitos no funcionales (NFRs)?
Conocer todos los componentes de software y cómo están integrados o conectados es crucial cuando planifica su arquitectura de red (especialmente el cortafuegos y la zona de seguridad de red), así como para determinar qué contramedidas de seguridad son necesarias. Conocer el tipo de datos y su sensibilidad te dirá qué tienes que asegurar y cuánto esfuerzo te llevará.
El desarrollo de la arquitectura del sistema está fuera del ámbito de este documento. Le rogamos encarecidamente, como profesional de la seguridad, que busque la arquitectura del sistema en su equipo de implementación y la comprenda.
Como parte de la definición de la arquitectura de sistemas, debe identificar los requisitos de seguridad. Esto puede ir desde la identificación de las normativas y estándares de seguridad que el sistema tiene que cumplir hasta el desarrollo del modelo de amenaza de seguridad.
Por ejemplo, las aplicaciones de su sistema tendrán que cumplir con los estándares de seguridad PCI (Payment Card Industry) si capturan, almacenan, procesan o transmiten tarjetas de crédito. Si su sistema acepta tarjetas de crédito, le recomendamos encarecidamente que lea la sección PCI DSS Strategy de este documento para comprender la estrategia en torno a la conformidad con PCI DSS.
En función del tipo de datos que procese o del entorno en el que trabaje, es posible que tenga que tener en cuenta otros requisitos normativos. Por ejemplo, los proyectos gubernamentales pueden tener que cumplir con la Ley Federal de Gestión de la Seguridad de la Información (FISMA). Los sistemas que capturan información de salud pueden tener que cumplir con la Ley de Portabilidad y Responsabilidad de Seguros de Salud (HIPAA). Entender y construir sus sistemas para que sean compatibles será significativamente más fácil que tratar de reajustar y abordar estas preocupaciones de seguridad cerca de su producción "entra en funcionamiento".
En la mayoría de los casos, también debe planificar el tiempo y los recursos del proyecto para incluir una auditoría del sistema antes de la producción.
También como parte de la definición del sistema, debe realizar un modelo de amenaza de seguridad para que el sistema comprenda, como mínimo, a los atacantes potenciales y en qué activos pueden estar interesados; y como resultado, las amenazas para las que necesita crear contramedidas. Por ejemplo, saber que los atacantes remotos pueden desear examinar de forma anónima las colas de mensajes de interoperatividad debe dictar la especificación de contramedidas como, por ejemplo, la autenticación de colas de mensajes. Debe asegurarse de que todos los requisitos de seguridad se tienen en cuenta en la arquitectura del sistema al principio del ciclo de vida del proyecto.