Arquitectura de seguridad para la nube híbrida

Capítulo 4. Requisitos y limitaciones

Este trabajo se ha traducido utilizando IA. Agradecemos tus opiniones y comentarios: [e-mail]

Requisitos para un sistema de información dan una especificación o descripción de las capacidades funcionales que debe ofrecer un sistema, junto con las características o cualidades que debe adoptar. Las exigencias externas e internas impuestas a un sistema convierten los requisitos en restricciones.

La gente suele utilizar indistintamente requisitos no funcionales, características arquitectónicas y cualidades. Todos ellos se refieren al mismo tipo de requisitos que definen el enfoque de la entrega del sistema. Hablaremos de ello más adelante en este capítulo.

La documentación de requisitos adopta distintas formas, según el tipo de requisito y los tipos de métodos de desarrollo y entrega. En este capítulo, hablaremos de las distintas técnicas y nos centraremos en las más adecuadas para la definición de requisitos de seguridad.

Por último, veremos cómo la trazabilidad de los requisitos a través de la documentación de la arquitectura, la documentación operativa y las pruebas es esencial para proporcionar confianza en la entrega y el funcionamiento de los requisitos.

Artefactos del capítulo

El objetivo principal de este capítulo de es debatir la definición y documentación de los requisitos de seguridad de un sistema. En la Figura 4-1 se destacan, con texto blanco en un recuadro sombreado en negro, en la parte superior del diagrama de dependencia de artefactos, los requisitos y restricciones que proceden del contexto externo e interno de la organización. En el dominio de los requisitos, destacamos los artefactos para la definición de requisitos funcionales y no funcionales, con la matriz de trazabilidad de requisitos resaltada en la parte inferior derecha.

Figura 4-1. Diagrama de dependencia de artefactos del capítulo Requisitos y limitaciones

Vamos a empezar con un debate sobre algunos conceptos acerca de los requisitos que enmarcarán el debate sobre los artefactos utilizados para describir los requisitos.

Conceptos de requisitos

Los requisitos describen lo que debe ofrecer un sistema de información y orientan el desarrollo de una arquitectura de soluciones. Especifican la funcionalidad, las características de la arquitectura y las limitaciones de un sistema. Analicemos esto con un poco más de detalle.

Requisitos funcionales

Funcional los requisitos describen lo que debe proporcionar un sistema de información. En otras palabras, definen los aspectos funcionales del sistema de información tal y como lo entrega el software. Los requisitos funcionales describen la secuencia de actividades, cuándo empiezan y terminan, las entradas y salidas, y el comportamiento y procesamiento de los datos.

La segunda característica de los requisitos funcionales es que describen la funcionalidad principal que proporciona el sistema, como hacer un pedido de un producto por Internet. Para la seguridad, podría tratarse de describir la secuencia de pasos para que un cliente inicie sesión en una tienda online, pero no la secuencia de inicio de sesión para el administrador del sistema, que es un requisito no funcional. Sin embargo, las técnicas y los artefactos utilizados para describir los requisitos pueden ser los mismos para ambos.

La seguridad puede aportar perspectivas adicionales a tener en cuenta al describir los requisitos funcionales. ¿Cuáles son las decisiones que afectan a la seguridad del sistema? ¿Cómo registramos las actividades para proporcionar una pista de auditoría? ¿Cómo monitoreamos las actividades que pueden ser una amenaza para el sistema?

Como arquitecto, quizá pienses que la recopilación de requisitos es tarea de un analista de negocio o de un consultor de seguridad. Aunque otra persona reúna esos requisitos, tú serás responsable de la arquitectura de seguridad y, por tanto, tienes que asegurarte de que recibes requisitos completos y de alta calidad.

Cuando tengas el contexto completo, deberás ser capaz de cuestionar y modificar los requisitos no relacionados con la seguridad, ya que pueden tener un impacto negativo en otras características del sistema. Ejemplos de ello podrían ser si la aplicación utiliza la autenticación multifactor para el inicio de sesión y si es obligatoria para autenticar determinadas transacciones.

Requisitos no funcionales

No funcionales Los requisitos describen cómo debe proporcionar el sistema de información la funcionalidad requerida. A menudo se describen como las características de arquitectura del sistema e incluyen seguridad, privacidad, escalabilidad, disponibilidad, recuperabilidad, usabilidad y muchas otras características.

Verás que muchos requisitos no funcionales se aplican al sistema en su conjunto y no a partes concretas del mismo. El requisito no funcional de la Tabla 4-1 muestra un requisito que se aplica a todo el sistema.

Tabla 4-1. Requisitos no funcionales de todo el sistema

ID	Requisito
NFR_SEC_AU_001	Cada 30 días DEBE producirse un cambio de todas las credenciales de autenticación utilizadas en la comunicación entre sistemas.

Muchos requisitos no funcionales se incluyen en marcos de control, políticas de seguridad y prácticas. Puedes acabar teniendo cientos de estos requisitos detallados para toda la empresa.

Sin embargo, otros requisitos no funcionales serán específicos de la prestación de una capacidad de tu arquitectura de soluciones. El requisito no funcional de la Tabla 4-2 muestra un requisito que se aplica a un componente específico de un sistema .

Tabla 4-2. Requisito no funcional de capacidad única

ID	Requisito
NFR_SEC_FW_001	El cortafuegos de perímetro DEBE soportar una tasa máxima de transacciones de aplicaciones de 1.000 conexiones activas y 10 MB/s de salida.

Características, cualidades o requisitos no funcionales

Las organizaciones utilizan distintos términos para describir los requisitos no funcionales, como características arquitectónicas o propiedades de calidad.

En el Capítulo 4 de Fundamentos de la Arquitectura del Software, Richards y Ford defienden el uso de el término características arquitectónicas porque el término requisitos no funcionales es autodenigrante. En otras palabras, podría sugerir que los requisitos no funcionales no son tan importantes como los funcionales. Esto dista mucho de la realidad, ya que utilizar requisitos no funcionales para describir la implementación de requisitos funcionales es igual de importante.

La norma ISO/IEC 25010:2023 sobre ingeniería de sistemas y de software utiliza el término propiedades de calidad del producto, que consta de ocho categorías de características:

• Idoneidad funcional

• Eficacia de rendimiento

• Compatibilidad

• Usabilidad

• Fiabilidad

• Seguridad

• Mantenibilidad

• Portabilidad

La categoría de seguridad contiene subcaracterísticas como confidencialidad, integridad, disponibilidad, no repudio, responsabilidad y autenticidad. Esto debería parecerte una lista familiar. Sin embargo, las ocho categorías que utilizan son un pequeño subconjunto de lo que entra en el ámbito de los requisitos no funcionales.

Nos quedamos con el término requisitos no funcionales, ya que las características arquitectónicas parecen implicar que no son requisitos, y las cualidades descritas por la norma ISO 25010:2023 son sólo una pequeña parte del ámbito de los requisitos no funcionales. Ten en cuenta que cuando leas distintas publicaciones, pueden referirse a los requisitos no funcionales utilizando términos diferentes.

Analicemos ahora algunas categorías de requisitos no funcionales (o características arquitectónicas) que son importantes para el pensamiento arquitectónico del diseño seguro:

Seguridad

La seguridad se expresa normalmente como el requisito de proteger los datos de la pérdida de confidencialidad, integridad y disponibilidad. Se podría decir que la seguridad es más bien una familia de características arquitectónicas. A partir de ellas, puedes derivar otros requisitos. La protección frente a la pérdida de confidencialidad requiere identificación y autenticación para respaldar la responsabilidad.

Muchos de estos requisitos proceden de las políticas, normas y directrices de la organización, pero las normas externas del sector específicas de la aplicación pueden añadir requisitos adicionales. Por ejemplo, una organización puede exigir el uso de al menos seguridad de la capa de transporte (TLS) 1.2, pero la norma externa exige TLS 1.3, lo que puede limitar los componentes tecnológicos utilizados en la solución.

Reúne las políticas, normas y directrices aplicables al inicio de un proyecto e identifica los requisitos de control que puedan causarte problemas de cumplimiento. Añádelos a tu lista de riesgos o problemas para la gestión de tu proyecto. Más adelante, en el Capítulo 10, hablaremos de la gestión de los riesgos y problemas del proyecto.

Privacidad

Con la privacidad habilitada en, un individuo o grupo puede protegerse a sí mismo o a la información sobre sí mismo para controlar qué información se expone públicamente. El ámbito de la seguridad, que abarca conceptos como la divulgación adecuada de la información, está en cierto modo interconectado con la privacidad.

Como se ha comentado en el Capítulo 3, es importante tener en cuenta la privacidad para proteger la información personal sensible. Puede haber leyes o reglamentos, como el GDPR, de los que se deriven requisitos.

Escalabilidad

Escalabilidad es la capacidad de un sistema de información para aumentar su capacidad de cálculo, almacenamiento y red. Si el sistema no escala, puede provocar una pérdida de disponibilidad. Es una consideración importante para un arquitecto que desarrolle una solución para un servicio de seguridad. Si un servicio de seguridad no puede escalarse para satisfacer el crecimiento de los clientes, podría producirse una interrupción del sistema global.

Por ejemplo, el diseño de un sistema de gestión de accesos privilegiados puede ser para la recuperación poco frecuente de contraseñas al arrancar un servidor. La frecuencia aumenta mucho en un entorno de contenedores y, a menos que el servicio se escale, puede causar una denegación de servicio, afectando a la disponibilidad del servicio. Necesitas diseñar la escalabilidad desde el principio, junto con una planificación continua por parte del equipo de operaciones de seguridad. La inclusión de la gestión del rendimiento y la capacidad se convierte en una parte importante de la solución para una solución de gestión de acceso privilegiado.

Disponibilidad

Disponibilidad se centra en mantener disponible un sistema de información. Con el paso a las aplicaciones nativas de la nube, que requieren una disponibilidad continua de los servicios de seguridad, esto adquiere mayor importancia para el diseño de los servicios de seguridad.

En el pasado, podíamos haber reiniciado un servidor cifrado cada pocos meses. La pérdida de un servidor de gestión de claves no habría tenido un impacto inmediato y se podría reprogramar el reinicio de un servidor. En un entorno de contenedores que se reinicia cada pocos minutos o segundos, una clave necesaria para el arranque del contenedor se convierte en crítica. La pérdida de un gestor de claves tendría un impacto inmediato.

Por esta razón, los servicios de seguridad a menudo necesitan tener características de disponibilidad superiores a las de las aplicaciones a las que dan soporte. Puede que tengas que plantearte mantener disponible un servicio de seguridad incluso después de que se hayan producido múltiples fallos en la infraestructura. El equipo de operaciones de seguridad puede necesitar pasar de un soporte de guardia con tiempos de respuesta de horas a un soporte 24×7 con tiempos de respuesta de minutos.

Recuperabilidad

Recuperabilidad es la capacidad de recuperar datos, servicios y operaciones rápidamente tras la interrupción de un servicio. Ya hemos hablado de lo críticos que se vuelven los servicios de seguridad en el debate sobre escalabilidad y disponibilidad. De ello se deduce que la recuperación del servicio es crítica, especialmente debido al cambio en la arquitectura informática hacia aplicaciones de contenedores nativas de la nube.

En la recuperación de un centro de datos, a menudo será necesario que los servicios de seguridad sean prioritarios para la recuperación, a fin de permitir la posterior recuperación de las aplicaciones. Asegúrate de que las copias de seguridad son completas, los datos están sincronizados y la recuperación se prueba regularmente para garantizar que satisfaces las necesidades de las aplicaciones dependientes.

Hay dos medidas clave para la recuperación: objetivo de punto de recuperación (RPO) y objetivo de tiempo de recuperación (RTO). El RPO es el alcance de la pérdida de datos cuando se produce un fallo en un sistema de información. Lo ideal es que no haya ninguna, pero cuando se copian los datos a un sitio remoto con una latencia significativa, puede que no sea posible utilizar la replicación síncrona de datos y que la replicación asíncrona provoque una pérdida de datos. Considera cómo gestionar la pérdida de datos.

El RTO representa el tiempo necesario para recuperarse de un fallo. Si la aplicación tiene que recuperarse en 30 minutos, los servicios de seguridad dependientes pueden tener sólo 10 minutos para recuperarse, dejando 20 minutos para que la aplicación se recupere. Esto puede requerir la mejora de las características de disponibilidad para manejar los fallos de múltiples componentes y aumentar la resistencia de los servicios de seguridad.

Dejar las llaves dentro del coche

En la recuperación de servicios de seguridad, debes tener en cuenta la secuencia de recuperación. La recuperación de claves puede no ser posible a menos que el almacenamiento ya haya completado el descifrado. Por ejemplo, podría ser que el reinicio del cortafuegos no pudiera tener lugar, ya que permite la comunicación con el HSM necesaria para descifrar el disco de arranque del cortafuegos. Si no existe un método diferente para recuperar las claves, no podemos resolver esta dependencia circular. Esto es el escenario de las llaves encerradas en el coche, en el que no puedes abrir el coche porque las llaves están encerradas dentro. Hay que tener la misma consideración con la gestión de secretos y la gestión de certificados.

Usabilidad

Usabilidad es la facilidad con la que un usuario u operador interactúa con un sistema de información. En el caso de la seguridad, es especialmente importante, porque si la barrera a la usabilidad es demasiado grande, los usuarios intentarán sortear el control de seguridad que se les interponga.

Por ejemplo, las normas para la reutilización de una contraseña han aumentado en sofisticación a lo largo de los años, a medida que los usuarios encuentran la forma de facilitar el recuerdo de sus contraseñas. Otro ejemplo son los engorrosos procesos de verificación de identidad que hacen que los usuarios proporcionen información falsa para eludir los controles.

Cuando añadas seguridad, piensa si promoverá comportamientos que añadan vulnerabilidades adicionales o elusión de controles.

Características de la arquitectura del software

No hemos intentado enumerar todas las categorías de requisitos no funcionales. Echa un vistazo al Capítulo 4 de Fundamentos de la Arquitectura de Software para un debate más extenso sobre las características de la arquitectura y las diferentes categorías de características de la arquitectura (también conocidas como requisitos no funcionales).

A menudo se describe la seguridad como un requisito no funcional, pero en realidad, la seguridad también se especifica mediante requisitos funcionales. Una secuencia de inicio de sesión para una aplicación requerirá una funcionalidad que identifique y autentique al usuario antes de acceder a la aplicación. En la Tabla 4-3 se muestra un ejemplo de requisito no funcional asociado al requisito funcional para el inicio de sesión de un usuario.

Tabla 4-3. Requisitos no funcionales

ID	Requisito
NFR_SEC_IA_001	La secuencia de inicio de sesión NO DEBE tardar más de 30 segundos en completarse si el 70% de los usuarios inician una secuencia de inicio de sesión entre las 8:30 y las 9:30 horas de un día laborable.

Puede resultar aún más confuso porque un requisito de seguridad puede ser tanto funcional como no funcional, dependiendo del contexto. La diferencia clave es que un requisito funcional se refiere a la funcionalidad principal de la aplicación, mientras que los requisitos no funcionales se refieren a cómo se lleva a cabo la prestación de la funcionalidad.

Por ejemplo, el requisito de identificación y autenticación de un cliente es un requisito funcional para la interfaz de usuario de una tienda online, mientras que el requisito de identificación y autenticación de todas las conexiones internas de sistema a sistema es un requisito no funcional. Con el primer requisito, el sistema no puede cumplir la funcionalidad principal del sistema sin él, pero con el segundo requisito, el sistema puede cumplir todos los requisitos funcionales con conexiones no autenticadas de sistema a sistema .

Restricciones

Muchos requisitos de se convierten en restricciones para la arquitectura de la solución. Empieza por considerar las leyes, reglamentos y normas externas, ya que se convierten en requisitos obligatorios para tu solución. A continuación, tendrás en cuenta estas limitaciones mediante el proceso normal de recopilación de requisitos.

Sin embargo, hay muchas otras limitaciones creadas por el entorno informático actual y los componentes de software seleccionados que pueden ser menos obvias y cuesta trabajo descubrir. Entre ellas se incluyen las siguientes cuatro áreas importantes:

Versiones de software

Dependencias de la versión del software provienen de los sistemas operativos subyacentes y del middleware. Puedes entrar en un "abrazo mortal" en el que tu software de aplicación sólo sea compatible con una antigua biblioteca no soportada y sea imposible una actualización porque la empresa que suministró el software ya no existe. Esto tiene como consecuencia que la actualización del resto del software que depende de la biblioteca no soportada no es posible. Las vulnerabilidades de seguridad aumentarán entonces con el tiempo y puede que necesites encontrar controles de seguridad adicionales para mitigar el riesgo.

Cuando diseñes un sistema que tenga componentes de software predefinidos, asegúrate de que las dependencias de todos los componentes de software se alinean en cuanto a sus versiones y componentes de software dependientes.

Protocolos de seguridad

Aunque existan versiones compatibles de componentes de software, los protocolos pueden no estar alineados. Por ejemplo, el protocolo TLS, utilizado para el cifrado a nivel de sesión, ha recibido actualizaciones para abordar vulnerabilidades recientemente identificadas. Aunque tus normas de seguridad exijan TLS 1.3, puede que el software sólo admita TLS v1.2 e inferiores. Podría resultar aún más difícil si el software de interconexión amortiza protocolos o cifrados más antiguos y no admite TLS v1.2, por lo que no pueden integrarse.

Tendrás que realizar una comprobación de los puntos de integración para asegurarte de que los protocolos de software están alineados. Puede que tengas que registrar los riesgos de los protocolos más antiguos con vulnerabilidades y las medidas de mitigación aplicadas para evitar la explotación de posibles vulnerabilidades. En este caso, puedes envolver el TLS en una red privada virtual (VPN) de Seguridad del Protocolo de Internet (IPsec) o cifrar la carga útil dentro de la sesión TLS.

Versiones API

Con el uso de las API REST en muchos servicios en la nube hace necesario el control de versiones para el desarrollo de nuevas capacidades y la eliminación de vulnerabilidades. El software que se integra con las API necesita actualizaciones para admitir las nuevas API a medida que se produce la amortización de las antiguas. No tienes más remedio que hacer estos cambios, ya que el cambio de versiones no está bajo tu control.

Si tus servicios de seguridad dependen de API en la nube para aplicar controles de seguridad, asegúrate de haber pensado en el soporte continuo para actualizar a nuevas API. Esta consideración sobre el soporte continuo existe en todos los servicios de seguridad y es un riesgo importante que requerirá trabajo adicional durante el desarrollo de la arquitectura de tu solución.

Incompatibilidad del agente

La seguridad requiere muchos agentes de software diferentes para detectar amenazas, comprobar el cumplimiento o realizar la configuración. Las incompatibilidades de versión pueden hacer que no puedas instalar los agentes en una versión antigua del sistema operativo. Ésta es una consideración importante durante la selección del producto.

Otro reto es el uso de dispositivos de seguridad que no admiten agentes de seguridad, como los agentes de detección y respuesta empresarial (EDR) de . Estos dispositivos de seguridad se convierten entonces en un riesgo, ya que no se pueden monitorizar las amenazas. A menudo, estos dispositivos son sólo una versión de Linux que soportaría los agentes, pero los proveedores no quieren permitirlo para sus fines de soporte. Puede que tengas que aplicar controles compensatorios.

Como puedes ver en este debate, hay muchas limitaciones que se derivan del entorno informático actual y de los componentes de software seleccionados como parte del proceso de pensamiento arquitectónico. Estas investigaciones pueden dar lugar a nuevos requisitos o actualizaciones de los riesgos, problemas, suposiciones y dependencias del proyecto que trataremos de gestionar en el Capítulo 9.

El siguiente paso es considerar cómo podemos garantizar la calidad de los requisitos que documentamos .

Especificar los requisitos de calidad

En tenemos que asegurarnos de que la definición de los requisitos de calidad forma parte de nuestro proceso de pensamiento arquitectónico. Un enfoque consiste en utilizar el marco SMART de. SMART significa hacer que los requisitos sean específicos, medibles, alcanzables, relevantes y limitados en el tiempo:¹

Específico

Los requisitos deben especificar claramente las necesidades de la empresa. Deben ser claros, coherentes, sencillos, inequívocos y con un nivel de detalle adecuado. Un buen punto de partida es utilizar las Cinco W: preguntar quién, qué, cuándo, dónde y por qué. Pueden ayudarte a definir el problema con mayor claridad para que puedas ser más específico en la definición de tus requisitos.

Mensurable

La construcción de los requisitos debe ser tal que sea posible verificar su aplicación. Los requisitos no funcionales a menudo deben ser cuantificables y permitir medir el progreso hacia su consecución. Pregúntate a ti mismo: ¿Puedes crear una prueba para el requisito? Parte de la verificación se realiza mediante la trazabilidad de los requisitos, incluidas las pruebas, de las que hablaremos más adelante en este capítulo.

Alcanzable

El requisito debe ser técnicamente factible y posible dentro de las limitaciones de la arquitectura de tu solución. Pide a expertos en la materia de la solución tecnológica específica que revisen los requisitos. Comprueba si se ha cumplido con éxito el requisito con anterioridad. Si no es así, ¿hasta qué punto estás seguro de que es realizable? Tal vez debas registrar un riesgo o suposición en el registro RAID del proyecto para hacer un seguimiento de cualquier preocupación. Hablaremos de este artefacto en el Capítulo 10.

Relevante²

Los requisitos deben alinearse con los objetivos empresariales generales y dar lugar a un resultado valioso. Estos requisitos pueden referirse a la funcionalidad principal o a las necesidades de seguridad y cumplimiento esenciales para llevar a cabo el negocio. Ten cuidado de no añadir requisitos de seguridad que estén fuera de las necesidades de la empresa o no se ajusten a la tolerancia al riesgo de la organización.

Con límite de tiempo³

El requisito debe especificar claramente cuándo debe estar implantada la capacidad para garantizar la alineación del equipo del proyecto. ¿Debe estar implantado el sistema de detección de amenazas incluso para el inicio de la prueba de concepto, o puede esperar hasta seis meses después de que el sistema haya entrado en producción? Los plazos pueden necesitar una justificación documentada mediante un registro de decisiones arquitectónicas. Hablaremos de cómo documentar un registro de decisiones arquitectónicas en el Capítulo 9.

Hemos especificado criterios específicos, medibles y relevantes como obligatorios, ya que todos los requisitos deben cumplirlos. Mientras que los criterios alcanzables y limitados en el tiempo utilizan el debería, ya que pueden depender de la definición posterior de las dependencias, prioridades y riesgos generales del proyecto global. Considerar los requisitos en su conjunto puede permitir una mejor evaluación de estos criterios.

Veamos un par de ejemplos, empezando por un requisito mal especificado de la Tabla 4-4.

Tabla 4-4. Requisito mal especificado

ID	Requisito
REQ_1	Debe lanzarse inmediatamente una alerta con el equipo pertinente para el ransomware.

No es específico, ya que no especifica quién debe dar la alerta. ¿Cómo de rápido es de inmediato? No sabemos quién es el "equipo pertinente". ¿Qué significa "para el ransomware"? No se puede medir porque no es suficientemente específico. No tenemos ni idea de si es alcanzable o relevante, porque no está bien especificado. No incluye el tiempo. No cumple ninguno de los criterios de calidad.

También hemos demostrado cómo no etiquetar un requisito. Utilizar la etiqueta REQ_1 no nos da una idea de a qué dominio pertenece el requisito, y utilizar 1 en lugar de 001 dificulta la clasificación.

Entonces hemos creado un requisito bien especificado en la Tabla 4-5.⁴

Tabla 4-5. Requisito bien especificado

ID	Requisito
NFR_SEC_TD_001	El sistema de detección de amenazas DEBE estar en funcionamiento antes de que el sistema contenga datos del cliente para emitir una alerta al centro de operaciones de seguridad (SOC) en un plazo de 15 minutos sobre la detección de patrones de eventos que puedan indicar un posible ransomware.

El requisito nos indica el componente que emite la alerta y quién la recibirá. Es más específico en el sentido de que se trata de la detección de patrones de eventos que podrían indicar un posible ransomware. Los patrones formarán parte de la especificación detallada. Es temporal, al definir cuándo debe estar en marcha la detección de amenazas. Es cuantificable, ya que en los 15 minutos siguientes a la detección, es necesario que salte la alerta. El requisito es relevante dada su amenaza, que es un riesgo real para la organización.

El tiempo que se tarda en detectar la amenaza es difícil de especificar, y definir requisitos adicionales que especifiquen los tipos de detección de ataques es una mejora. No podemos saber si es alcanzable, ya que no tenemos el contexto del proyecto. Es una gran mejora respecto al primer requisito.

Observarás que el requisito tiene una construcción de frases compleja. No todos los requisitos cumplirán todos estos criterios, pero proporcionan una lista de comprobación de calidad para ver si se te ha pasado documentar distintos aspectos de una solución. La aplicación de los criterios puede variar según los distintos requisitos. Por ejemplo, la expresión del criterio de limitación temporal puede estar en un único requisito que luego se aplique a varios requisitos que especifiquen la funcionalidad.

También hemos etiquetado los requisitos con un formato mejor. NFR significa Requisito No Funcional, SEC es para el grupo de requisitos de seguridad, TD es para Detección de Amenazas, y 001 es un número clasificable.

Ahora que tenemos claros los requisitos, ¿cómo podríamos priorizarlos en?

Priorizar requisitos

En a menudo acabamos con una larga lista de requisitos para la arquitectura de la solución. Mientras que la aplicación de algunos requisitos es inmediata, para otros, la prioridad de aplicación puede ser dentro de un plazo determinado.

Para un proyecto mínimo viable (MVP) de, debemos proporcionar un nombre de usuario y una contraseña para la identificación y la autenticación, y podríamos ofrecer autenticación multifactor si hay tiempo suficiente. Otro ejemplo es que, con un número reducido de consumidores del servicio, podríamos decidir que debemos ofrecer un RTO de 48 horas para empezar y podríamos ofrecer un RTO de 4 horas si hemos tenido tiempo suficiente para implementarlo.

Una técnica muy utilizada para priorizar requisitos es el método MoSCoW, donde las mayúsculas representan:

Debetener

El proyecto implementará el requisito. La finalización del proyecto no puede tener lugar sin la entrega de los requisitos categorizados como Deben.

Deberíahaber

El proyecto intentará aplicar el requisito dentro del plazo dado, pero puede que no tenga tiempo de hacerlo.

Podríahaber

El proyecto podría implementar el requisito, pero no necesariamente lo hará. Lo más probable es que la aplicación del requisito no se produzca.

Tendríao no tendría⁵

Esto podría significar que el proyecto incluiría el requisito si hubiera tiempo, pero no es crítico. Una alternativa es especificar a veces que un proyecto no implementará un requisito. Tal vez porque el requisito introduciría un coste o una complejidad adicionales y debe excluirse explícitamente de una solución para garantizar que no se aplique.

Pongamos algunos ejemplos de requisitos priorizados basados en dos sprints de un proyecto, como se muestra en la Tabla 4-6.

Tabla 4-6. Requisitos prioritarios

Referencia	Sprint 1	Sprint 2	Requisito
REQ_SEC_1	DEBE	DEBE	Todos los usuarios DEBEN ser identificados y autentificados antes de darles acceso al sistema.
REQ_SEC_2	DEBERÍA	DEBE	Todos los usuarios DEBEN ser autenticados mediante autenticación multifactor.
REQ_SEC_3	PUEDE	DEBERÍA	Todos los usuarios DEBEN recibir un aviso legal sobre el uso no autorizado del sistema.

La tabla muestra tres requisitos relacionados con la identificación y autenticación de un usuario por un sistema de aplicación escalonada. Siempre debe haber identificación y autenticación, con la autenticación multifactor a continuación y un aviso legal más tarde.

Ahora que tenemos una forma de evaluar la calidad de los requisitos y una forma de priorizarlos, pasemos a la especificación de los requisitos, empezando por los requisitos funcionales .

Especificar los requisitos funcionales

En hay muchas formas diferentes de especificar los requisitos funcionales. Escribir requisitos funcionales puede ser tan sencillo como algo que el sistema proporcionará, como en la Tabla 4-7.

Tabla 4-7. Ejemplo de descripción de un caso de uso

ID	Requisito
FR_SEC_IA_001	El sistema identificará y autenticará a un usuario mediante un nombre de usuario y una contraseña.

Sin embargo, esto no describe la secuencia de actividades ni los actores que participan en ellas. En esta sección, vamos a presentar una selección de diferentes técnicas, mostrar el artefacto y discutir su uso en el contexto de la especificación de requisitos funcionales.

Discutiremos las siguientes técnicas:

• Casos prácticos

• Mapas de viaje

• Historias de usuarios

• Esquemas de los carriles de natación

• Matrices de separación de funciones

Los casos de uso, una técnica desarrollada en los años 80 por Ivar Jacobson, que más tarde codificó el Lenguaje Unificado de Modelado (UML), serán nuestro punto de partida.

Casos prácticos

Un caso de uso es una descripción de las interacciones del sistema por parte de los actores humanos y del sistema. Identificaremos los casos de uso como parte de la definición del diagrama de contexto del sistema en el Capítulo 5. Necesitan una descripción más detallada mediante el uso de un diagrama de casos de uso UML y descripciones de casos de uso.

Podemos utilizar un diagrama de casos de uso UML para visualizar el comportamiento de un sistema con una caja que represente el límite del sistema o subsistema, personas que representen a los actores humanos y del sistema, y los casos de uso dentro de la caja. Hemos tomado un subconjunto de los actores y casos de uso del caso práctico para mostrar un diagrama de casos de uso en la Figura 4-2.

Figura 4-2. Diagrama de casos de uso UML del caso práctico

El diagrama muestra la implicación de los actores en cada caso de uso, pero necesitamos algunos detalles más sobre el caso de uso. Podemos documentarlos como una descripción informal o en una plantilla prescrita, como la que se muestra en la Tabla 4-8.

Tabla 4-8. Descripción del caso de uso del estudio de caso

Nombre del caso de uso:	Registro de conductores
Descripción:	Registrar los datos del conductor y los vehículos que posee
Actores:	Conductor
Condiciones previas:	El conductor no debe estar ya registrado
Flujo:	Registra un nombre de usuario y una contraseña para el portal Se envía un correo electrónico de validación al conductor El conductor hace clic en el enlace para validar el correo electrónico El conductor se conecta de nuevo El conductor registra nombre, dirección y teléfono móvil El conductor matricula los vehículos de su propiedad El conductor registra una tarjeta de pago para cobrar la tasa Salir del portal
Postcondiciones:	Ninguno
Excepciones	En el paso 1, si el conductor ya se ha registrado, la interfaz de usuario dirá "no se puede registrar" y enviará un correo electrónico al propietario informándole del registro duplicado y guiándole para que restablezca la contraseña.
Requisitos:	Se comprobará si el nombre de usuario se parece a una dirección de correo electrónico. La contraseña se comprobará para verificar que no es trivial.

Cada caso de uso describe un conjunto de actividades con condiciones previas y posteriores. Para los casos de uso no técnicos, los analistas o consultores empresariales pueden definirlos para que los arquitectos y desarrolladores los pongan en práctica.

Una descripción de casos de uso para la interacción del sistema

Hemos utilizado una descripción textual del caso de uso, pero también podemos utilizar diagramas de secuencia o de colaboración para describir mejor la interacción entre los actores del sistema y el sistema (o subsistema). Incluimos un análisis de estos artefactos en el Capítulo 6.

Hay muchos casos de uso de seguridad por definir en cada sistema, desde el inicio de sesión en la aplicación del usuario final hasta la notificación de un incidente de seguridad. Debes garantizar la identificación de los actores relevantes para la seguridad y documentar sus casos de uso.

Más detalles UML

Para una descripción más detallada de los diagramas de casos de uso, lee el capítulo 18 de la Guía del usuario del Lenguaje Unificado de Modelado (Addison-Wesley Professional) de Grady Booch, James Rumbaugh e IvarJacobson.

Como ya hemos comentado, los casos de uso son interacciones con un sistema. Resulta difícil evitar considerar una solución como parte de la definición del requisito. En la Tabla 4-7, el requisito ya ha definido la necesidad de un nombre de usuario y una contraseña. ¿Qué pasa con un sistema de identificación y autenticación sin contraseña? Habría sido mejor exigir la autenticación multifactor como cualidad y dejar la solución al arquitecto.

Como resultado, en los últimos 20 años se han desarrollado técnicas centradas en el usuario final. Vamos a continuar con una técnica centrada en las necesidades de un usuario, la definición de un mapa de viaje .

Mapas de viaje

Nosotros hablamos del pensamiento de diseño en el Capítulo 2. Se trata de un enfoque centrado en el ser humano para comprender a las personas (otro término para referirse a los actores) a través de sus necesidades, puntos de dolor y objetivos. Una técnica para comprender mejor a las personas consiste en elaborar un mapa de viaje para definir sus acciones, pensamientos y sentimientos al interactuar con un servicio o producto. Es una herramienta más personal para ponerte en la posición de un usuario o cliente y comprender sus pensamientos y emociones.

El mapa de viaje se crea normalmente en un taller, utilizando pegatinas en una pared para describir las fases, los pasos, las sensaciones y los puntos de dolor. En la Figura 4-3 mostramos un ejemplo de hoja de ruta para el estudio de caso .

Figura 4-3. Mapa de viaje del estudio de caso

Un mapa de viaje también se denomina viaje del usuario o mapa de escenarios, con ligeras diferencias entre los distintos formatos. Nosotros utilizamos el formato de mapa de escenarios "to-be" del método "Enterprise Design Thinking" de IBM .

Esta técnica es buena para mostrar el recorrido de extremo a extremo y meterse en la cabeza del conductor para comprender sus pensamientos y sentimientos. Sin embargo, un mapa de viaje no ofrece suficientes detalles para pasar al desarrollo de la solución y se necesita una técnica adicional para descomponer el problema. Ahora hablaremos del uso de historias de usuario para la siguiente fase del desarrollo.

Historias de usuarios

En el desarrollo ágil de , los requisitos funcionales suelen especificarse como una historia de usuario. Es un concepto que procede de la metodología eXtreme Programming como forma de mejorar la calidad del software y responder mejor a los requisitos cambiantes de los clientes. Los usuarios expresan sus requisitos y valores mediante historias de usuario. Los usuarios son los especificados como actores humanos en el diagrama de contexto del sistema del Capítulo 5 y como personas en el pensamiento de diseño de . Proporciona un mecanismo de comunicación entre el equipo de desarrollo y el cliente sobre la especificación de la solución.

Desarrollamos historias de usuario y las colocamos en un catálogo de historias llamado un backlog del producto. Basándonos en la prioridad, en cada sprint o iteración, movemos las historias de usuario al backlog del sprint. El enfoque MoSCoW a la priorización, comentado anteriormente, es una forma de decidir qué historias se incorporan al backlog del sprint.

Una historia de usuario se escribe normalmente en tres partes:

Como <role> quiero <a feature/function> para que yo <business reason/benefit>.

Esto cubre tres elementos de las cinco W para hacer específico un requisito: quién, qué y por qué. Normalmente, añadirás información de fondo que proporcione contexto al requisito y pruebas que determinen su cumplimiento.

Pongamos un ejemplo de historia de usuario para un informe de cumplimiento, como se muestra en la Tabla 4-9.

Tabla 4-9. Ejemplo de historia de usuario

Historia de usuario	Como especialista en cumplimiento, quiero poder obtener un informe de cumplimiento que contenga gráficos de tendencias para diferentes perspectivas , de modo que pueda identificar a las partes interesadas con las que tengo que trabajar para cerrar las brechas de cumplimiento.
Contexto	Esto viene del equipo de cumplimiento, que lo ha estado haciendo manualmente con hojas de cálculo y lo necesita automatizado.
Pruebas de aceptación	Pruébalo con informes de tendencias para una línea de negocio, aplicación, plataforma tecnológica y país. Pruébalo con informes de tendencias semanales, mensuales, trimestrales y anuales.

No todos los usuarios quieren introducir un nombre de usuario y una contraseña, y a veces, con los requisitos de seguridad, es más apropiado cambiar el quiero por estoy obligado, y luego eliminar la cláusula para que. El principio básico que hay que recordar es que la historia de usuario debe ser para un rol de usuario concreto. No empieces una historia de usuario con "Como usuario"; hay que identificar a un usuario concreto.

Nos referimos a las historias de usuario más grandes que pueden llevar más de un sprint como una epopeya. A menudo necesitan un mayor refinamiento en muchas historias de usuario y son una señal de que es necesario seguir trabajando para descomponer el problema. Por ello, algunas herramientas definen una epopeya como un grupo de historias de usuario en lugar de una gran historia de usuario. Merece la pena ponerse de acuerdo sobre lo que significa una epopeya dentro del equipo con el que trabajas.

Un tema es una colección de historias de usuario y epopeyas relacionadas, organizadas en un grupo. Por ejemplo, un tema llamado "informes de cumplimiento" podría incluir historias y epopeyas para cada informe individual.

Los desarrolladores pueden olvidarse fácilmente de los usuarios responsables de la seguridad y el cumplimiento cuando desarrollan una aplicación. Por eso es importante definir a estos actores (o usuarios) en el diagrama de contexto del sistema que trataremos en el Capítulo 5, ya que es un buen recordatorio de que los usuarios no son sólo los de la aplicación empresarial principal. El sistema de información global también tiene que satisfacer las necesidades de muchos otros usuarios, como el "Equipo de Cumplimiento". En este caso, debemos tener en cuenta que una de las funciones principales de la aplicación es cumplir requisitos normativos externos.

Detalle de otras Historias de Usuario

Encontrarás más detalles sobre la aplicación de las historias de usuario en Historias de usuario aplicadas: For Agile Software Development (Addison-Wesley Professional), de Mike Cohn.

En este punto, tenemos una forma de especificar el recorrido del usuario de extremo a extremo y los requisitos funcionales mediante historias de usuario. Nos falta una forma de especificar los distintos usuarios, cómo interactúan y describir la separación de funciones. Por tanto, volvemos a una técnica que existe desde hace mucho más tiempo: un diagrama swimlane .

Diagramas de los carriles de natación

En hay muchos diagramas diferentes que describen el flujo de un proceso o la secuencia de actividades realizadas por un actor o usuario. Existen diagramas de flujo y diagramas de actividad UML que describen los pasos de un proceso, pero ninguno de ellos muestra claramente las funciones sin añadir una tabla que describa la secuencia de actividades.

Por tanto, utilizamos diagramas de líneas de nado para describir los pasos de un proceso, siendo cada "línea de nado" una fila o columna que representa las actividades de un actor. El diagrama permite mostrar quién realiza qué pasos, el traspaso entre actores y los puntos de decisión. El diagrama también puede mostrar cómo mantener la separación de funciones. En la Figura 4-4 se muestra un ejemplo de diagrama swimlane.

Figura 4-4. Diagrama de la línea de nado

Hemos utilizado un conjunto sencillo de partes del diagrama; encontrarás diagramas más complejos, pero es probable que utilices estas partes la mayoría de las veces. Hablemos de las partes:

Actor

Estos son los actores, personas o usuarios que intervienen en la ejecución del proceso. En un sistema puede haber actores humanos y actores del sistema.

Swimlane

Un swimlane es una fila o columna que contiene las actividades realizadas por un actor. Se parecen a los carriles de natación de una piscina, en los que los nadadores permanecen dentro de su propio carril, de donde procede el nombre del diagrama.

Terminator

Un terminador es el inicio o final del proceso descrito.

Paso del proceso

Un paso del proceso es una actividad realizada por un actor.

Decisión

Una decisión se produce cuando alguien hace una elección en el proceso. Normalmente es una decisión bidireccional, como una decisión sí/no u OK/no OK, pero podrías dibujar el diagrama con más de dos opciones. Cuando haya una decisión política, deberá producirse la escritura de un registro de eventos en un registro.

Subproceso

Un paso de proceso individual de puede resultar demasiado complejo para un único diagrama y un subproceso separado (o diagrama de líneas de nado) describirá el paso con más detalle.

Números de paso

Este numera los pasos y es una forma útil de referenciar los pasos del proceso. Es una convención que los diagramas swimlane vayan siempre de izquierda a derecha o de arriba abajo, ya que representan la ejecución de un proceso a lo largo del tiempo.

El diagrama de calles de nado por sí solo no suele proporcionar una descripción suficiente, por lo que necesitamos una descripción textual en una tabla. La Tabla 4-10 proporciona un breve ejemplo con los dos primeros pasos de la Figura 4-4 cumplimentados.

Tabla 4-10. Descripción del diagrama de carriles de natación

Actividad	Actor	Título	Descripción
1.	Solicitar acceso privilegiado	Empleado	El empleado comienza abriendo la página web de la herramienta de solicitud IAM y cumplimenta una solicitud de acceso privilegiado. La solicitud incluye el ID necesario y una justificación empresarial para obtener ese nivel de acceso. Debe estar vinculada a un incidente, problema o ticket de cambio.
2.	Decisión	Director	El encargado revisa la solicitud del empleado y comprueba que hay justificación suficiente para el acceso y que los permisos solicitados son adecuados para las actividades.
n.	etc.	etc.	etc.

Observa que la tabla incluye el número de la actividad, el actor y el título, además de una descripción. Si quieres utilizar un diagrama de flujo o un diagrama de actividades UML, esta tabla puede registrar los actores en lugar de utilizar swimlanes.

Para la siguiente etapa, debemos asegurarnos de que un actor no recibe derechos inadecuados para realizar un paso del proceso. Lo hacemos con una matriz de separación de funciones.

Matrices de separación de funciones

En el Capítulo 3, hablamos de la separación de funciones como un principio rector importante. Hay muchos procesos relevantes para la seguridad en los que un usuario no debe realizar una combinación de actividades y necesitan seguir el principio de separación de funciones.

Por ejemplo, un usuario que solicite acceso de usuario privilegiado no debería poder aprobar su acceso ni tener la capacidad de emitir su propio acceso privilegiado. Utilizamos una matriz de separación de funciones para representar lo que pueden y no pueden hacer. La Figura 4-5 es un ejemplo del diagrama de vías de acceso de la Figura 4-4.

Figura 4-5. Matriz de separación de funciones

Las partes del diagrama son

Paso del proceso

Estos son todos los pasos del proceso en el diagrama de líneas de nado.

Papel

Es el número del rol, indicado por la clave, que realiza un paso del proceso.

ID

El ID es el número del paso del proceso utilizado en el diagrama de calles. El ID aparece tanto vertical como horizontalmente en la matriz.

Matriz de riesgos

En el centro de la tabla hay una matriz de 7 × 7 que muestra qué pasos del proceso puede/no puede realizar conjuntamente un rol. Cuando una combinación de pasos del proceso supone un riesgo elevado, una "X" marca una combinación de actividades que un rol no debe realizar conjuntamente. Cuando un "*" indica que la combinación es de bajo riesgo, la función debe evitarla. No es un obstáculo y el rol podría realizar la combinación si no hubiera otra opción. Una marca indica una combinación de actividades que puede realizar la misma persona.

Entonces, ¿cómo funcionan los artefactos de requisitos funcionales con el estudio de caso que estamos utilizando?

Caso práctico: Definición del proceso

En la Figura 4-3, creamos una hoja de ruta para un conductor, pero ésta es demasiado de alto nivel y no tiene detalles para proporcionar requisitos funcionales para el sistema. La primera actividad relevante para la seguridad en la hoja de ruta es el registro de la cuenta del conductor.

Hemos utilizado un diagrama swimlane para describir el proceso de registro de la cuenta de conductor, como se muestra en la Figura 4-6. Estamos utilizando una forma vertical del diagrama para poder mostrar todos los pasos del proceso en una página vertical sin descomponerlo en diagramas swimlane adicionales.

En este ejemplo, hay un único actor humano y dos actores del sistema. Hemos identificado dos componentes técnicos entre los dos actores del sistema y hemos iniciado el proceso de pensamiento arquitectónico. No tenemos múltiples actores humanos, así que no necesitamos un análisis detallado de separación de funciones.

El proveedor de identidad y el proveedor de correo electrónico podrían ser dos servicios en la nube diferentes. Podríamos tener el requisito de que el proveedor de identidad tome todas las decisiones relacionadas con la identidad y no el proveedor de correo electrónico. Podría ser que hayamos ganado mayor confianza en el proveedor de identidad y no queramos repartir la lógica empresarial de las decisiones relacionadas con la identidad entre varios servicios. Un registro de decisión arquitectónica debe documentar que sólo el proveedor de identidad tomará estas decisiones. En este caso, podemos ver en el diagrama swimlane que el proveedor de correo electrónico sólo envía correos electrónicos y realiza decisiones de lógica empresarial.

Éste es un ejemplo de un proceso empresarial que toma decisiones que afectan a la seguridad. No es necesario crear un diagrama swimlane para cada proceso. Te sugerimos que documentes cualquier proceso implicado en la toma de una decisión de seguridad utilizando un diagrama swimlane para tener clara la secuencia de actividades y decisiones de seguridad. En el Capítulo 11 mostraremos más detalles sobre la descomposición de procesos y cómo documentar la escritura de eventos de seguridad en un registro de auditoría.

Figura 4-6. Diagrama del swimlane de registro de la cuenta del conductor

Lista de comprobación de la garantía de calidad de los requisitos funcionales

• Utiliza el diagrama de contexto del sistema, tratado en el Capítulo 5, para identificar los casos de uso que requieren una mayor especificación.

• Revisa el descubrimiento de requisitos empresariales, como el mapa de viaje y las historias de usuario, para identificar actividades o historias que tengan incluidos controles de seguridad.

• Elabora actividades de refuerzo de la seguridad utilizando diagramas swimlane y matrices de separación de funciones.

• Asegúrate de que el propietario del proceso empresarial conserva la propiedad de la definición del proceso empresarial (no el arquitecto de seguridad).

Pasemos ahora a la especificación de los requisitos no funcionales .

Especificación de requisitos no funcionales

En hemos hablado antes de cómo los requisitos no funcionales describen cómo debe ofrecer funcionalidad el sistema de información. Luego hablamos de algunas categorías de requisitos no funcionales, de cómo medir su calidad y de cómo priorizarlos. Entonces, ¿de dónde proceden estos requisitos y cuál es la mejor forma de registrarlos?

Fuentes de requisitos no funcionales

En el Capítulo 3, hablamos de las fuentes externas y internas de los requisitos. Las leyes y reglamentos externos y las buenas prácticas del sector o de organizaciones expertas permiten a una organización desarrollar sus políticas, normas y directrices internas. De estos documentos, un arquitecto necesita extraer los requisitos no funcionales relevantes. Estos requisitos no funcionales suelen ser limitaciones para tu proyecto, ya que pueden reducir la elección de la solución de seguridad. La Figura 4-7 muestra cómo los contextos externo, interno y del proyecto informan la arquitectura de la solución que contiene los controles de seguridad.

Ya hablamos del contexto externo e interno en el Capítulo 3. Una vez que existe un proyecto, ahora tenemos un contexto de proyecto que nos proporciona requisitos adicionales con los que trabajar, incluidos los objetivos y el alcance del proyecto. Los recursos, las competencias, las herramientas, las normas, el presupuesto y el plazo influyen en la solución que estamos considerando.

Figura 4-7. Contexto externo, interno y del proyecto

El contexto del proyecto tiene en cuenta el triángulo de gestión de proyectos con el equilibrio de coste y tiempo con alcance, calidad y riesgo, como se muestra en la Figura 4-8. Sin embargo, el diagrama no debe centrarse sólo en el alcance y la calidad, sino también considerar el equilibrio entre coste y tiempo con cualidades como la seguridad, la resistencia y la disponibilidad.

Figura 4-8. Triángulo de la gestión de proyectos

Este equilibrio es algo que debes tener en cuenta al especificar los requisitos, ya que cumplirlos todos puede no ser viable en términos de coste o tiempo. Puede que tengas que buscar controles de seguridad alternativos que tengan un coste menor y unaimplantación más rápida.

No todos los requisitos son explícitos, por lo que derivamos requisitos no funcionales implícitos de otras fuentes, como las aplicaciones o cargas de trabajo que los servicios de seguridad están protegiendo. Si una aplicación tiene un RTO de ocho horas, los servicios de seguridad pueden necesitar estar disponibles en mucho menos tiempo en caso de una interrupción de gran impacto. O si una aplicación necesita que el 80% de los usuarios inicien sesión en poco tiempo, el servicio de seguridad que la soporta tendrá que escalar para satisfacer las necesidades de la aplicación. Esto dará lugar a un conjunto de requisitos no funcionales para la seguridad relacionados con la disponibilidad y la resistencia.

Dependiendo de la entrega de las capacidades de seguridad, puede que no tengas el control de las características de funcionalidad y arquitectura del servicio de seguridad. También se convierten en una limitación con la que tienes que trabajar.

Dependencias de requisitos no funcionales

Tú puedes tener el control de la implementación de los requisitos de seguridad a través del proyecto que controlas o puedes tener dependencias de servicios de seguridad prestados en otros lugares. Para los servicios de seguridad prestados fuera de tu proyecto, tendrás que evaluar si esas cargas de trabajo pueden utilizar los servicios de seguridad para cumplir los requisitos no funcionales del proyecto.

Por ejemplo, si la aplicación utiliza una tecnología específica, ¿el servicio de seguridad también la soporta? Si no es así, ¿habrá que cambiar la carga de trabajo, o tendrás que llenar ese vacío? Un buen punto de partida es obtener una lista de los componentes de software clave, sus versiones de software y las plataformas en las que se ejecutan. El diagrama de la pila de responsabilidad compartida que tratamos en el Capítulo 7 ayuda en el análisis, ya que puedes utilizarlo para pensar en las distintas capas de la solución para cada plataforma.

Identificar las versiones de software

En el pensamiento arquitectónico on-premises, la comprobación de las versiones de software de puede haberse producido más tarde en el proceso. Hemos descubierto que esto ocurre antes en el proceso de la nube híbrida, con versiones de software que requieren cambios importantes en la arquitectura y las operaciones.

Por ejemplo, la solución podría requerir una versión de software o una función que el CSP no admite, lo que daría lugar a la necesidad de sustituir un servicio en la nube por software en un servidor virtual. En ese caso, es probable que aumente el coste y se ponga en duda la viabilidad del proyecto. En consecuencia, el proyecto puede decidir utilizar un servicio alternativo.

Incluso si la solución ya es un software en lugar de un servicio, podría ocurrir que tuvieras que cambiar el software de seguridad de un proveedor a otro. Cuanto antes realices una comprobación de la versión del software, menos probable será la sorpresa de un cambio importante en los componentes del software en una fase posterior.

Deberías trabajar con cada uno de los componentes clave del software, examinando qué servicios de seguridad necesitan integración y evaluando su compatibilidad. Algunas preguntas que podrías hacerte son

• ¿Cuáles son los sistemas operativos, y son compatibles herramientas de seguridad como el antivirus y la detección y respuesta en el punto final (EDR)?

• ¿Requiere la herramienta de mensajería el cifrado de la carga útil dentro de la sesión de red cifrada, y existe un servicio de seguridad que lo soporte?

• ¿Necesita la base de datos un monitoreo de la actividad para detectar el uso indebido de los datos por parte de un empleado o de un actor externo que suponga una amenaza? ¿Existe una solución compatible?

Podría haber incluso más restricciones para los servicios en la nube en cuanto a los servicios utilizados en las cargas de trabajo, como las bases de datos, y los servicios de seguridad, como el control de acceso, que el proveedor de servicios en la nube es .

Documentar requisitos no funcionales

En hemos hablado de dónde proceden los requisitos no funcionales y de la derivación de requisitos de la tecnología dependiente. Anteriormente, en este capítulo, también hemos hablado de la derivación y creación de requisitos de calidad mediante SMART. Ahora necesitamos una lista de requisitos que podamos utilizar para demostrar el cumplimiento de las políticas y de cualquier otro requisito que proceda de distintas fuentes. Sería sencillo si pudiéramos tener un único documento con todos los requisitos enumerados, pero no es así como funciona normalmente.

Creemos que la mejor forma de enfocar esto es crear una hoja de cálculo o una tabla con todos los requisitos e ignorar inicialmente la calidad de los requisitos de origen. A continuación, clasifícalos utilizando las categorías no funcionales, y para los requisitos de seguridad, utiliza los dominios de seguridad, como se explica en "Técnica: Arquitectura de Seguridad Empresarial". A continuación, inserta el requisito original con una referencia al documento fuente, seguido de la solución propuesta y el propietario del servicio del requisito, como se muestra en la Tabla 4-11.

Tabla 4-11. Ejemplo de asignación de implementación de control

NFR	Dominio	Categoría	Prio	Requisito	Ref. Ext.	Solución	Propietario del servicio
SEC	IAM	PAM_003	DEBE	Es necesario recuperar rápidamente las contraseñas privilegiadas.	EXT_REF_nn	El alojamiento del servicio de gestión de acceso privilegiado (PAM) estará en componentes de infraestructura independientes de la infraestructura central y estará disponible durante un ataque DDoS mediante un servicio VPN remoto de cristal roto.	Responsable de operaciones de seguridad

Esto te da un formato que está bien si tienes un solo proyecto, pero si diriges un programa con muchos proyectos o una organización con muchos proyectos, crear una lista de requisitos de todas las fuentes diferentes supondrá mucho esfuerzo duplicado. En este caso, merece la pena mejorar la calidad del catálogo de requisitos. Repasemos algunas técnicas para mejorar los requisitos.

Mejorar la especificación de requisitos

Es posible que acabe extrayendo requisitos de distintas fuentes, lo que dará lugar a una variedad de formatos y calidades diferentes. Si revisas los requisitos de control del NIST SP 800-53r5 Controles de seguridad y privacidad para sistemas de información y organizaciones, los requisitos son neutrales en cuanto a política, tecnología y sector, lo que mucha gente no entendería, y hay parámetros que deben completarse.

A menudo, los requisitos reunidos se beneficiarán de una reescritura en un conjunto coherente que la gente pueda entender sin dar lugar a interpretaciones incoherentes. Así podrás utilizar los requisitos de alta calidad muchas veces en distintos proyectos o contextos.

Hemos desarrollado un conjunto útil de enfoques para la derivación de un catálogo de requisitos de seguridad coherente y de alta calidad para su uso repetido. Utiliza cada técnica de forma iterativa para derivar los requisitos necesarios y utilízalos en el orden que mejor te convenga.

Mientras lo haces, asegúrate de mantener una correspondencia entre el nuevo requisito y el requisito original. A medida que hagas cambios, vuelve a comprobar la correspondencia con el requisito original para asegurarte de que sigue siendo válida. Si reformulas, divides o fusionas requisitos, podrían desincronizarse con los requisitos originales.

Empecemos por clasificar los requisitos en función del dominio y luego de la categoría para agrupar los requisitos relacionados. A continuación, procesa los requisitos de la siguiente manera:

Reordena

Aunque has clasificado los requisitos en grupos de tipos comunes de requisitos, a menudo sólo tienen sentido en una secuencia determinada. Por ejemplo, puede que tengas dos requisitos: el primero requiere la autenticación mediante la autenticación multifactor, y el segundo requiere la identificación y autenticación antes de que un usuario acceda a un sistema. Estos dos requisitos deben intercambiarse para que uno pueda basarse en el siguiente.

Dividir

Puede que descubras que puedes dividir un requisito en varios requisitos. Un requisito con "y" en la frase es una indicación de un requisito que puede que necesites dividir. Por ejemplo, toma el siguiente requisito AC-2 a. del NIST SP 800-53r5. La primera parte es un requisito de documentación, y la segunda podría ser un requisito de un control técnico aplicado mediante herramientas. Dividir el requisito en dos permite asignarlo a diferentes equipos para una clara rendición de cuentas, si es necesario:

AC-2 a. Definir y documentar los tipos de cuentas permitidas y específicamente prohibidas para su uso en el sistema.

Fusiona

Una vez que hayas reordenado y descompuesto, puede que encuentres dos requisitos que en realidad son el mismo requisito. En este punto, puedes fusionarlos en un requisito común. Busca cualquier sutileza en la redacción de los dos requisitos antes de fusionarlos y compáralos con los requisitos de origen.

Recategoriza

A veces un requisito puede asignarse a la categoría equivocada y necesitar una reasignación. Por ejemplo, NIST SP 800-53r5 establece que muchas familias de control requieren el desarrollo de una política, que suele redactarse independientemente del equipo responsable de implementar el requisito.⁶ Es probable que tengas un equipo responsable de todo el desarrollo de políticas. Estos requisitos necesitarán una recategorización a un dominio y categoría diferentes para mejorar la alineación con el responsable.

Subcategoriza

En puedes acabar con una larga lista de requisitos que has reordenado, dividido y fusionado. Puede que notes que los requisitos se agrupan en temas comunes. Agrupar los requisitos en más subcategorías puede facilitar su gestión.

Dimensiones

Los requisitos deben ser lo más neutrales posible para que, a medida que cambien el contexto y la tecnología, puedas aplicarlos al ámbito adecuado sin cambiar los requisitos. Sin embargo, es necesario cierto contexto. Por ejemplo, tomemos el requisito SI-3 a. del NIST SP 800-53r5. Dice que se implemente el mecanismo de protección del código a la entrada y salida del sistema. Podrías entender que esto significa sólo implementar un control en un servidor, pero la implementación de este control está en muchos límites de control:

SI-3 a. Implementar [Selección (una o más): basado en firma; no basado en firma] mecanismos de protección contra código malicioso en los puntos de entrada y salida del sistema para detectar y erradicar el código malicioso;

En la discusión para el control, dice: "Los puntos de entrada y salida del sistema incluyen cortafuegos, servidores de acceso remoto, estaciones de trabajo, servidores de correo electrónico, servidores web, servidores proxy, ordenadores portátiles y dispositivos móviles". Este requisito necesita que estas múltiples dimensiones se documenten explícitamente con el requisito. De lo contrario, la gente puede malinterpretar el alcance previsto.

Como se aplica a todos los requisitos relacionados con el código malicioso, te sugerimos que mantengas las dimensiones del requisito en una lista independiente del requisito para hacer referencia a varios requisitos. Cuando cambien las dimensiones, sólo tendrás que actualizarlas una vez.

Parametriza

Requisito SI-3 a. ese que utilizamos en el ejemplo anterior tiene parámetros que hay que rellenar para el tipo de capacidad de detección de código malicioso. Al igual que con las dimensiones, te sugerimos que mantengas esta lista externa al requisito para que puedas aplicar los mismos parámetros a más de un requisito si es necesario.

No alinear

La industria de la seguridad crea montones de nuevos términos para nuevas capacidades y, por desgracia, esos términos pueden acabar en requisitos. Por ejemplo, el término protección inteligente⁷ utilizado por varios ISV no nos dice de qué requisito se trata. ¿Se trata de protección de marcas basada en IA o de tecnología de protección contra malware?

Un requisito no debe encerrar a ninguna organización en un único producto. Tendrás que detectarlos y sustituirlos por un requisito que no esté alineado con las ofertas de marca. Puede que tengas que definir tus propios términos y crear un glosario para proporcionar una descripción de los términos en el contexto de tu organización.

Veamos un ejemplo para que te hagas una idea de las mejoras que se obtienen al mejorar la especificación de un catálogo de requisitos para su uso en todos los proyectos.

Caso práctico: Especificación de un Catálogo de Requisitos

En hablamos de la especificación de los requisitos funcionales mediante un flujo de procesos y de la mejora de la calidad de los requisitos. En un proyecto en el que los requisitos no se reutilizan, justificar un esfuerzo significativo para mejorarlos es poco probable.

Cuando es necesario reutilizar el mismo conjunto de requisitos en varios proyectos, mejorar su calidad reduce el tiempo dedicado a discutir el significado de unos requisitos de mala calidad. Además, con requisitos dispersos en distintos documentos de seguridad, es difícil, sin una lista única en la que trabajar, demostrar su cumplimiento. En estos casos, un único catálogo de requisitos es valioso.

Autoridad de Diseño Técnico o Consejo de Arquitectura

Hablamos de la creación de documentos para su uso en toda una organización para muchos proyectos. Para ello, necesitamos una Autoridad de Diseño Técnico (ADT) en la que los líderes técnicos de toda la organización, con distintas habilidades y experiencia, se reúnan para evaluar, asesorar y acordar las buenas prácticas. Un catálogo de requisitos es uno de esos artefactos que acordarán utilizar en toda la organización. La Norma TOGAF de The Open Group es un buen punto de partida para comprender la gobernanza de la arquitectura y los papeles y funciones de una junta de arquitectura o TDA.

Identificar los requisitos de seguridad

El estudio de caso nos pide que documentemos los 10 ó 20 requisitos principales para su aplicación como parte del MVP. Se sugiere que utilicemos el Marco de Ciberseguridad del NIST (CSF) como punto de partida para los requisitos. Como ejemplo, empecemos a construir los requisitos para la gestión de vulnerabilidades a partir del marco, como se muestra en la Tabla 4-12.

Tabla 4-12. NIST CSF-gestión de vulnerabilidades

Función	Categoría	Subcategoría	Referencias informativas
PROTEGER (PR)	Procesos y Procedimientos de Protección de la Información (PR.IP): Se mantienen y utilizan políticas de seguridad (que abordan la finalidad, el alcance, las funciones, las responsabilidades, el compromiso de la dirección y la coordinación entre las entidades organizativas), procesos y procedimientos para gestionar la protección de los sistemas y activos de información.	PR.IP-12: Se desarrolla e implementa un plan de gestión de la vulnerabilidad	CIS CSC 4, 18, 20 COBIT 5 BAI03.10, DSS05.01, DSS05.02 ISO/IEC 27001:2013 A.12.6.1, A.14.2.3, A.16.1.3, A.18.2.2, A.18.2.3 NIST SP 800-53 Rev. 4 RA-3, RA-5, SI-2
DETECTAR (DE)	Monitoreo Continuo de la Seguridad (DE.CM): El sistema de información y los activos son monitoreados para identificar eventos de ciberseguridad y verificar la efectividad de las medidas de protección.	DE.CM-8: Se realizan exploraciones de vulnerabilidad	CIS CSC 4, 20 COBIT 5 BAI03.10, DSS05.01 ISA 62443-2-1:2009 4.2.3.1, 4.2.3.7 ISO/IEC 27001:2013 A.12.6.1 NIST SP 800-53 Rev. 4 RA-5

Dos subcategorías dentro del CSF del NIST, cada una de las cuales sirve a diferentes "funciones", conducen a los requisitos. Las organizaciones suelen integrar estos requisitos en un servicio de gestión de vulnerabilidades. Ten en cuenta que no existe una correspondencia unívoca entre los servicios de seguridad y las funciones del CSF del NIST, lo que demuestra que no puedes utilizar las funciones del CSF para describir los servicios de seguridad.

Las subcategorías definen los "bloques de construcción" de la seguridad en el CSF del NIST, pero son insuficientes como requisitos, dejando muchas preguntas sin respuesta y abiertas a la interpretación. Son buenas para una lista de comprobación de alto nivel, pero no para la especificación de los requisitos de seguridad necesarios para una demostración de conformidad. Por ejemplo, no dicen nada sobre las dimensiones que hemos discutido anteriormente. No tienen parámetros que especifiquen la frecuencia de la exploración de vulnerabilidades o el tiempo necesario para eliminar una vulnerabilidad.

Elaborar requisitos de seguridad

Cada de las subcategorías tiene referencias a NIST SP 800-53r5, Controles de Seguridad y Privacidad para Sistemas de Información y Organizaciones. Es un catálogo de controles de que proporciona un conjunto más completo de requisitos de control con los que trabajar.

En NIST SP 800-53r5, el primer requisito para el monitoreo y escaneo de vulnerabilidades es RA-5 (a), como se muestra en la Tabla 4-13.

Tabla 4-13. NIST SP 800-53r5 monitoreo y escaneo de vulnerabilidades

ID	Requisito
RA-5 (a)	Monitorear y escanear en busca de vulnerabilidades en el sistema y en las aplicaciones alojadas [Asignación: frecuencia definida por la organización y/o aleatoriamente de acuerdo con el proceso definido por la organización] y cuando se identifiquen y notifiquen nuevas vulnerabilidades que puedan afectar al sistema;

Aunque es más completo, el RA-5 (a) tiene muchos requisitos de control, dimensiones y parámetros en la misma frase. He aquí la lista de lo que encontramos:

• Una herramienta de exploración de vulnerabilidades para identificar vulnerabilidades-DE.CM-8 en NIST CSF

• Un proceso de gestión de vulnerabilidades-PR.IP-12 en NIST CSF

• Un parámetro para la frecuencia de exploración según la política

• Una dimensión para escanear "sistema y aplicaciones alojadas"

• Un nuevo requisito para notificar al servicio de gestión de vulnerabilidades cuando nuevos datos de inteligencia hayan identificado vulnerabilidades o amenazas de vulnerabilidades en el sistema.⁸

No podemos dejar el RA-5 (a) como un requisito integrado y multidimensional para demostrar eficazmente el cumplimiento y tener que reescribirlo en componentes separados.

Reescribir los requisitos de seguridad

Integrar múltiples requisitos, parámetros y dimensiones en un requisito de control dificulta la asignación de responsabilidades y la medición del cumplimiento. Descomponer el requisito de control RA-5 (a) en requisitos, dimensiones y parámetros discretos, como se muestra en la Tabla 4-14, es la mejor forma de reescribirlo.

Tabla 4-14. Requisitos de gestión de vulnerabilidades reescritos

Tema	ID	Descripción	Mapa de control
Controlar Requisitos	VM-01	Definir y aplicar procesos y procedimientos de gestión de amenazas y vulnerabilidades.	NIST SP 800-53 RA-5 (a) NIST CSF PR.IP-12
	VM-02	La exploración de vulnerabilidades DEBE realizarse con una frecuencia {VM-P-01,02,03,04} para los tipos de componentes del sistema {VM-D-01}.	NIST SP 800-53 RA-5 (a) NIST CSF DE.CM-8
	TIM-01	Notificar al servicio de Gestión de Vulnerabilidades una posible vulnerabilidad de un componente del sistema DEBE realizarse dentro de {TIM-P-01}.	NIST SP 800-53 RA-5 (a)
Control Dimensiones	VM-D-01	Componentes de red, servidores (físicos y virtuales), contenedores, plataforma en la nube, plataforma de contenedores, aplicación	NIST SP 800-53 RA-5 (a)
Controlar Parámetros	VM-P-01	no menos de semanalmente	NIST SP 800-53 RA-5 (a)
	VM-P-02	tras un cambio significativo de los componentes del sistema	NIST SP800-53 RA-5 (a)
	VM-P-03	en un plazo de 24 horas tras la notificación de la posible vulnerabilidad de un componente del sistema	NIST SP 800-53 RA-5 (a)
	VM-P-04	durante las pruebas de penetración	NIST SP800-53 CA-8
	TIM-P-01	en 24 horas	NIST SP 800-53 RA-5 (a)
Clave	VM = Gestión de vulnerabilidades TIM = Monitorización de Inteligencia de Amenazas {} = Sustitución de parámetros/dimensiones

Empezamos creando el requisito VM-01 para procesos y procedimientos, que es un requisito fundamental necesario para todos los servicios y solicitado en la asignación RA-5 (a). A continuación, RA-5 (a) exige un requisito de control, VM-02, para el escaneado de vulnerabilidades y, después, un requisito derivado, TIM-01, para que el servicio de monitoreo de inteligencia sobre amenazas les notifique las posibles vulnerabilidades. El requisito de control TIM-01, que no se menciona explícitamente en ningún requisito de gestión de vulnerabilidades o de inteligencia sobre amenazas, determina de forma crítica el éxito de la entrega del requisito de control VM-01.

Faltan las dimensiones o el alcance del servicio. RA-5 (a) habla de un "sistema y aplicaciones alojadas", pero eso es incompleto y depende de los componentes tecnológicos utilizados en el entorno. Cuando leemos RA-5 (a), podríamos pensar que sólo necesitamos realizar un escaneado de vulnerabilidades de los servidores y las aplicaciones, pero esto no incluye las vulnerabilidades de la red, la plataforma en la nube, los contenedores y la plataforma de contenedores. Añadir la dimensión VM-D-01 mejoró el alcance del escaneado de vulnerabilidades.

Desajuste familia de control/dominio

Tú te habrás dado cuenta de que las familias y dominios de control del NIST CSF y el SP 800-53 no se alinean totalmente con los requisitos, dimensiones y parámetros de seguridad resultantes. Hemos derivado un nuevo requisito para el Monitoreo de Inteligencia de Amenazas y descubierto un nuevo requisito para la Gestión de Vulnerabilidades relacionado con las pruebas de penetración. El resultado es que no puedes asignar la responsabilidad de los procesos de seguridad y la prestación de servicios simplemente asignando la propiedad de las familias o dominios de control a estos marcos.

Faltan los parámetros del servicio. No se define con qué frecuencia deben ejecutarse los escaneos ni con qué rapidez debe notificarse a los propietarios de las vulnerabilidades. ¿Cuál es el tiempo de almacenamiento de los registros de vulnerabilidades? Muchos de estos parámetros podrían proceder de una política, pero si no se especifican allí, no está claro cuándo hemos cumplido los requisitos. Añadir los parámetros VM-P-01, VM-P-02, VM-P-03 y TIM-P-01 ha mejorado la comprensión de los requisitos.

Añadimos un parámetro VM-P-04 porque descubrimos que el requisito CA-8 requiere la capacidad de realizar análisis de vulnerabilidades para pruebas de penetración. Este requisito debe documentarse porque puede cambiar el número de actores humanos admitidos y requerir un aumento de la capacidad del servicio de seguridad.

Lista de comprobación de la garantía de calidad de los requisitos no funcionales

• Ten en cuenta todas las fuentes de: contexto externo, contexto interno y contexto del proyecto.

• Identifica los componentes de aplicaciones y servicios dependientes y utilízalos para determinar los requisitos de integración de la seguridad, incluidos:

  • Dependencias de la versión del software

  • Requisitos de seguridad específicos de la carga de trabajo

  • Requisitos de capacidad

• Evalúa la calidad de cada requisito utilizando SMART

• Evalúa la prioridad de cada requisito utilizando el MoSCoW

• Asegúrate de que el requisito incluye:

  • Una etiqueta que proporciona un identificador único

  • Una etiqueta que identifique su procedencia

  • Dimensiones que definen el ámbito

  • Parámetros que definen los aspectos variables

• Intenta equilibrar el coste, el alcance/calidad/riesgo y el tiempo en la especificación de requisitos.

Hasta ahora, hemos hablado de establecer un catálogo de requisitos para una carga de trabajo o aplicación. Pero, ¿cómo podemos utilizar este catálogo para asegurarnos de que la implementación y el funcionamiento de la seguridad se ajustan a los requisitos? Hablaremos de ello en la siguiente sección .

Trazabilidad de los requisitos

Una vez que hemos documentado los requisitos e identificado la solución, tenemos que garantizar la documentación de la solución tanto a nivel lógico como prescrito, la finalización de las pruebas y la disponibilidad de la documentación operativa. Para ello, creamos una correspondencia entre los requisitos y la documentación específica, como se muestra en la Tabla 4-15.

Tabla 4-15. Matriz de trazabilidad de requisitos

ID	Requisito	HLDa	LLDb	Plan de pruebas	Documentación
SEC_IAM_PAM_003	El tiempo de respuesta del sistema en todas las etapas de recuperación de una credencial privilegiada DEBE ser inferior a 5 segundos para cargar una página, incluso si la infraestructura de los sistemas centrales está sometida a una carga extrema.	4.2 Gestión de Acceso Privilegiado (PAM)	11.3 Gestión de Acceso Privilegiado (PAM)	6.5 Prueba unitaria 7.8 Prueba de integración 9.7 Prueba de resistencia	Manual de Operaciones-5.6 Proceso VPN de rotura de cristales en caso de emergencia
a Diseño de alto nivel b Diseño de bajo nivel

La tabla tiene una columna para cada fase de la documentación de la arquitectura de la solución, incluidas las pruebas y las operaciones. Tu tabla puede contener más columnas para tu proyecto, pero éstas son las mínimas que esperaríamos.

Así podremos estar más seguros de la arquitectura documentada de la solución y de la implementación y el funcionamiento de las capacidades para mantener la seguridad. Hablaremos más sobre el desarrollo de los artefactos de diseño y funcionamiento en la documentación de diseño dentro de los Capítulos 6 y 8, las pruebas necesarias en el Capítulo 10 y la documentación de funcionamiento en el Capítulo 11.

Requisitos de indexación Referencias

Hemos dado a cada requisito un código de identidad único para utilizarlo como referencia. Un enfoque útil para validar la inclusión de todos los requisitos en un documento de diseño es incluir el identificador dentro de una frase, como [SEC_IAM_PAM_003], y luego marcarla como entrada para un índice. A continuación, puedes encontrar dónde la especificación de diseño documentó un requisito y garantizar la cobertura de todos los requisitos revisando el índice para comprobar si está completo.

Terminemos con un resumen de este capítulo.

Resumen

Algunos autores han expresado la opinión de que documentar los requisitos ya no es necesario en un entorno de trabajo Ágil. Espero que hayamos demostrado el valor de dedicar esfuerzos a documentar tanto los procesos funcionales como los no funcionales. Puedes escalar el nivel de documentación para adaptarlo al tamaño de la organización y del proyecto. Hemos indicado cómo hacerlo para las organizaciones más grandes y destacado algunas formas de reducir el trabajo para proyectos más pequeños.

Los requisitos de seguridad no son sólo requisitos no funcionales, sino que, cuando constituyen la función principal del sistema, se convierten en requisitos funcionales.

Los requisitos funcionales suelen seguir un proceso iterativo que puede comenzar con un mapa de viaje para identificar historias de usuario que puedan contener decisiones de control. Las historias de usuario proporcionan el siguiente nivel de descomposición en un entorno Ágil, pero para algunos procesos son insuficientes, y ahí es donde ayudan los diagramas de líneas de flotación y la matriz de separación de funciones.

Los requisitos no funcionales necesitan una definición clara, y hablamos de los distintos enfoques para mejorar la calidad y establecer prioridades. Demostramos los retos que plantea la integración de los marcos de control y los requisitos del proyecto mediante una serie de mejoras en la definición de los requisitos del caso práctico.

Hemos llegado al final de la discusión sobre la documentación de requisitos y restricciones, pero no al final de la utilización de los requisitos para definir la seguridad de la arquitectura de una solución. Esto debería prepararte para los capítulos siguientes, en los que empezaremos por definir los límites del sistema, los actores que interactúan con él y los datos que requieren protección .

Ejercicios

1. Un requisito funcional ______. Selecciona todo lo que corresponda.

   1. Describe la funcionalidad principal de la solución

   2. Define cómo debe entregarse el sistema

   3. Define lo que debe ofrecer el sistema

   4. No define ningún requisito de seguridad

2. ¿Qué términos se utilizan para los requisitos que describen cómo debe proporcionar el sistema de información la funcionalidad requerida? Selecciona todos los que corresponda.

   1. Requisitos no funcionales

   2. Características arquitectónicas

   3. Características no funcionales

   4. Propiedades de calidad del producto

3. ¿Cuál de las siguientes afirmaciones es cierta sobre los requisitos de los servicios de seguridad?

   1. Las aplicaciones deben recuperarse antes que los servicios de seguridad durante la recuperación de desastres.

   2. Pasar de cargas de trabajo cliente-servidor a cargas de trabajo contenedor no requiere un cambio en los servicios de seguridad.

   3. Al pasar a la nube, no es necesario ajustar la forma en que se realizan las operaciones de seguridad.

   4. La pérdida de disponibilidad de los servicios de seguridad puede tener un impacto casi inmediato en la disponibilidad de la carga de trabajo.

4. ¿A qué se refiere "dejar las llaves dentro del coche"? Selecciona todo lo que corresponda.

   1. Tus llaves pueden quedarse encerradas en el coche accidentalmente si no se detecta la proximidad de la llave dentro del coche.

   2. La recuperación de claves puede no ser posible a menos que el almacenamiento ya haya completado el descifrado.

   3. Las claves de encriptación se bloquean accidentalmente dentro de una caja fuerte física.

   4. El reinicio del cortafuegos no puede tener lugar, ya que permite la comunicación con el módulo de seguridad de hardware (HSM) necesario para desencriptar el disco de arranque del cortafuegos.

5. ¿Cuáles son las cualidades que se sugiere buscar en los requisitos de seguridad?

   1. Quién, Qué, Cuándo, Dónde y Por qué

   2. Debo tener, Debería tener, Podría tener y No tendré

   3. Específicos, Mensurables, Alcanzables, Pertinentes y Limitados en el tiempo

   4. Trazables, comprobables y oportunos

6. ¿Cuál es la mejor técnica de definición de requisitos funcionales para identificar los requisitos funcionales del usuario final? Selecciona todas las que procedan.

   1. Casos prácticos

   2. Un mapa de viaje

   3. Esquemas de los carriles de natación

   4. Historias de usuarios

7. ¿Cuál es la mejor técnica de definición de requisitos funcionales para la definición formal de la secuencia de actividades de refuerzo de la seguridad que tienen lugar entre distintos usuarios finales?

   1. Casos prácticos

   2. Mapa del viaje

   3. Esquemas de los carriles de natación

   4. Historias de usuarios

8. ¿Qué factores debe tener en cuenta el triángulo de gestión del proyecto a la hora de equilibrar el alcance, el coste y el tiempo? Selecciona todos los que corresponda.

   1. Habilidades

   2. Calidad

   3. Viabilidad

   4. Riesgo

9. ¿Cuáles son las principales razones por las que realizas una comprobación de la versión del software al principio del proceso de requisitos para la nube híbrida? Selecciona todas las que corresponda.

   1. La incompatibilidad de versiones puede requerir un cambio arquitectónico importante.

   2. Es posible que un servicio en la nube no admita la versión de software requerida.

   3. Es posible que la solución de gestión de eventos e información de seguridad (SIEM) no haya sido probada para procesar esa versión específica de software.

   4. El producto de seguridad no es compatible con ninguna versión del sistema operativo utilizado.

10. En el proceso de mejora de las especificaciones de requisitos, ¿qué pasos se utilizan para considerar el alcance de los requisitos?

    1. Dividir

    2. Dimensiones

    3. Fusiona

    4. Parametriza

¹ Hay muchas definiciones diferentes de lo que significa SMART. Hemos elegido esta definición porque creemos que ofrece la mejor calidad en cuanto a requisitos de seguridad y cumplimiento.

² A veces, la R de SMART se define como razonable. El criterio consiste en validar que el requisito dispone de los recursos adecuados para ofrecer la solución. Nosotros no lo utilizamos, ya que los plazos razonables se incluyen en el criterio de plazos y luego se comprueba la razonabilidad del requisito global como parte de la priorización de requisitos.

³ A veces, la T de SMART es trazabilidad. Trazabilidad de requisitos a través de la especificación de requisitos, la arquitectura de la solución, la implementación y las pruebas está más relacionada con garantizar la calidad de la implementación de los requisitos que con la calidad del propio requisito escrito. Hablaremos de la trazabilidad de los requisitos más adelante en este capítulo.

⁴ Estamos seguros de que podrías mejorar el requisito, si te dieran más contexto y tiempo.

⁵ Los autores prefieren el uso de no se implementará, ya que es probable que los requisitos que no se implementen por tener una prioridad menor se clasifiquen como Podría tener. A veces puede que necesites especificar que un requisito no se implementará porque conoces a alguien que quiere el requisito fuera del proyecto inmediato y quieres dejar claro que el requisito no debe implementarse.

⁶ Éste es un ejemplo de por qué no es eficaz utilizar la rendición de cuentas basada en una familia de control dentro de un marco de control. Hay muchos otros ejemplos, pero éste es el más obvio.

⁷ Esto no tiene nada que ver con la utilización del enfoque SMART para mejorar la calidad de los requisitos.

⁸ Podría tratarse de una nueva vulnerabilidad de software notificada en la base de datos CVE o de una amenaza de inteligencia sobre el aprovechamiento de una vulnerabilidad. Lo ideal sería añadir un requisito para el parcheado automático de un producto de software.