Agregar seguridad a una solución en una etapa tardía del ciclo de vida de diseño y desarrollo suele dar como resultado costosas repeticiones de trabajos y sacrificios de usabilidad que afectan la capacidad de la solución y la experiencia del usuario. Diseñar soluciones para que sean seguras desde el principio ayuda a garantizar un equilibrio adecuado de usabilidad, interoperabilidad, resiliencia y seguridad para la solución final.

Seguridad por diseño es el principio de que las prácticas de diseño, desarrollo y entrega de un proyecto deben incluir prácticas de seguridad y cumplimiento entregadas por un equipo calificado y con experiencia. Los principios de diseño de seguridad, como los que siguen, guían las prácticas de pensamiento arquitectónico.

El proceso de diseño debe comenzar con el uso del design thinking empresarial para centrarse en los resultados de usuario requeridos para los stakeholders de riesgo, cumplimiento y seguridad, tanto internos como externos a una organización. Los stakeholders externos incluyen clientes, gobiernos y entes reguladores. Los stakeholders internos incluyen aquellos que gestionan el riesgo, el cumplimiento y la seguridad.

El proceso de diseño continúa con el pensamiento arquitectónico para definir las características de la arquitectura, la decisión arquitectónica, la arquitectura funcional y el modelo de despliegue en la nube. Luego, se completa la definición de características, como resiliencia, rendimiento y escalabilidad, para los servicios de seguridad.

Tras la definición de los requisitos y la arquitectura, se puede llevar a cabo la ingeniería de la funcionalidad de seguridad e infraestructura, siguiendo el principio de seguridad por defecto.

IBM tiene un enfoque de larga data de la seguridad y la privacidad por diseño utilizado en el desarrollo de productos. Es útil revisar el IBM Redpaper publicado sobre Seguridad en el desarrollo: la infraestructura de ingeniería segura de IBM

Cuando los usuarios o el software con un sistema tienen privilegios excesivos, existe el riesgo de uso indebido, ya sea accidental o deliberadamente. Los actores de amenazas pueden comprometer las cuentas privilegiadas de los usuarios internos y usar los derechos para atravesar la red y los sistemas.

El privilegio mínimo es el principio que establece que el sistema debe otorgar a los usuarios o al software las capacidades mínimas necesarias para llevar a cabo la tarea prevista. El sistema debe implementar esto desde el nivel más alto en una aplicación hasta una conexión individual entre dos componentes de software.

Para implementar el principio de privilegio mínimo, debe comprender los activos en su entorno de TI dinámico. El acceso privilegiado no es solo un problema de personas; es necesario saber qué aplicaciones tienen acceso a qué datos. El proceso de descubrimiento, clasificación y evaluación de riesgos es continuo. Reúna los datos de riesgo de sus recursos digitales para descubrir nuevos insights sobre los riesgos a nivel empresarial que le ayude a establecer las políticas adecuadas.

Un usuario o software puede tener un contexto seguro en el punto de identificación y autenticación inicial para una sesión, pero un actor de amenazas puede comprometer la sesión activa y usarla para comprometer aún más un sistema.

La verificación continua es el principio de que un usuario o software debe verificar constantemente para evaluar si todavía tiene un contexto seguro. La intención de la verificación continua es encontrar problemas de seguridad y vulnerabilidades lo antes posible e idealmente lo hacen los actores de amenazas.

La verificación continua confirma que las entidades son quiénes, o qué, afirman estar utilizando desafíos, como una solicitud de autenticación de segundo factor. Es posible que sea necesario actualizar la carga de trabajo para permitir la verificación continua de los usuarios y el software mediante soluciones que utilicen una arquitectura de red de confianza cero (ZTNA). Las organizaciones centradas en ofrecer las mejores experiencias de usuario de su clase dudan en interrumpir al usuario con solicitudes innecesarias; sin embargo, este nivel de garantía de identidad es crítico para la confianza cero.

Es posible que un actor de amenazas ya haya vulnerado una organización. Si una organización solo busca amenazas en el límite externo y no amenazas que hayan utilizado un mecanismo válido para eludir el control del límite, es posible que no descubra una violación durante mucho tiempo. El principio de asumir una violación de seguridad implica que una organización da por sentado que un actor de amenazas ha vulnerado su seguridad.

El enfoque requiere que la gestión de amenazas agregue detección proactiva interna, búsqueda de señales de alerta temprana, caza de amenazas y uso de runbooks probados. La detección y la respuesta deben estar estrechamente integradas con las capas de insights y aplicación, compartiendo contexto y ajustando dinámicamente las políticas de control de acceso en respuesta a las amenazas identificadas.

Un sistema de información tendrá vulnerabilidades en el software, el firmware y el hardware. Las configuraciones y el software cambiarán, y aparecerán nuevas vulnerabilidades. Si una capa de defensa es vulnerable, el sistema debe permanecer seguro.

La defensa en profundidad es el principio según el cual un sistema cuenta con múltiples capas de defensa, de modo que si una capa falla, otra capa sigue en su lugar para proteger los datos confidenciales del sistema. El uso de un enfoque por capas en una estrategia de seguridad garantiza que una organización pueda detener a un atacante en una capa posterior cuando se vulnera una capa de defensa.

La estrategia y arquitectura de seguridad empresarial deben incluir medidas que ofrezcan protección en las capas posteriores del modelo tradicional de computación en red. En general, una organización necesita planificar la seguridad desde lo más básico (seguridad a nivel de sistema) hasta lo más complejo (seguridad a nivel de transmisión).

La superficie de ataque de una organización es la suma de vulnerabilidades, vías o métodos, a veces llamados vectores de ataque, que los actores de amenazas pueden usar para obtener acceso no autorizado a la red o a datos confidenciales, o para llevar a cabo un ataque cibernético. A medida que las organizaciones adoptan cada vez más servicios en la nube y modelos de trabajo híbridos (on premises/trabajo desde casa), sus redes y superficies de ataque asociadas son cada día más grandes y complejas.

Minimizar la superficie de ataque es el principio según el cual un sistema debe reducir el alcance de los vectores de ataque para disminuir las posibles formas en que un actor de amenazas puede obtener acceso. Los expertos en seguridad dividen la superficie de ataque en tres subsuperficies: la superficie de ataque digital, la superficie de ataque física y la superficie de ataque de ingeniería social.

1. La superficie de ataque digital expone potencialmente la infraestructura on premises y en la nube de la organización a cualquier actor de amenazas con conexión a Internet. Los vectores de ataque comunes incluyen el acceso a la red, las vulnerabilidades de software, la habilitación de recursos no utilizados, la TI en la sombra y el software sin datos.

2. La superficie de ataque física expone los activos y la información a los que normalmente solo pueden acceder los usuarios con acceso autorizado a la oficina física o los dispositivos endpoint de la organización. Esto incluye ataques de usuarios internos maliciosos, robo de dispositivos y "baiting", un ataque en el que los actores de amenazas dejan unidades USB infectadas con malware en lugares públicos con la expectativa de engañar a los usuarios para que conecten los dispositivos a sus computadoras y descarguen malware involuntariamente.

3. La superficie de ataque de ingeniería social manipula a las personas para que compartan información que no deberían compartir, descarguen software que no deberían descargar, visiten sitios web que no deberían visitar, envíen dinero a delincuentes o cometan otros errores que comprometan sus activos o seguridad personales u organizacionales.

Una organización debe evaluar el riesgo para los datos confidenciales que procesa el sistema examinando cada una de estas superficies de ataque.

Los usuarios podrían tener acceso a datos altamente confidenciales que permitan eludir los controles, como las claves de cifrado, o tener los derechos para realizar acciones altamente privilegiadas, como transferir grandes sumas de dinero. Incluso cuando un sistema monitorea a los usuarios, pueden abusar de sus derechos y tener consecuencias de negocio catastróficas.

La separación de funciones es el principio según el cual los usuarios con un acceso privilegiado a los datos o a las acciones requieren más de un usuario para completar la acción. Proporciona a una organización la capacidad de dividir las funciones administrativas entre personas sin superponer responsabilidades, de modo que un usuario no tenga autoridad ilimitada.

Con actividades como la gestión de claves de cifrado, la organización requerirá que los administradores de claves de cifrado gestionen diferentes partes de una clave, de modo que ningún administrador tenga conocimiento de la clave completa. Con las transacciones de negocio, la aplicación puede requerir que una persona que solicita una transacción tenga uno o más aprobadores para que se complete.

Para algunas industrias, un ente regulador puede requerir la separación de tareas para funciones poderosas como parte de la orientación regulatoria. La separación de tareas ayuda a las empresas a cumplir con las regulaciones del gobierno y simplifica la gestión de las autoridades.

Los productos o servicios contienen muchos puntos diferentes de configuración y existe el deseo de que su uso sea lo más fácil posible. Como resultado, el producto tiene una configuración de seguridad deficiente, como puertos de red abiertos o contraseñas fáciles de recordar.

La seguridad por defecto es el principio según el cual una organización recibe productos o servicios configurados de forma segura desde el primer momento. Los productos están configurados para proteger contra las amenazas y vulnerabilidades más frecuentes sin que los usuarios finales tengan que tomar medidas adicionales para protegerlos.

Un sistema puede estar configurado de forma segura al principio, pero un desarrollador puede realizar posteriormente un cambio que modifique la configuración o un actor de amenazas realiza un cambio a través de una vulnerabilidad que comprometa el sistema.

El cumplimiento continuo es el principio de que la configuración de seguridad del sistema se verifica constantemente, comenzando con el desarrollo del sistema hasta el sistema en ejecución continua. La intención del cumplimiento continuo es encontrar problemas de seguridad y vulnerabilidades antes de que lo hagan los actores de amenazas.

Idealmente, las comprobaciones de cumplimiento son automatizadas y cubren todas las configuraciones de seguridad, incluyendo la plataforma en la nube, la plataforma de contenedores, middleware e imágenes de cómputo como servidores virtuales y contenedores. Con imágenes de cómputo, un mejor enfoque puede ser usar infraestructura como código (IaC) para reemplazar la imagen completa de manera regular.

Las responsabilidades compartidas para la entrega de seguridad y cumplimiento en un entorno de nube híbrida dependen de los modelos de servicio, las plataformas informáticas y los proveedores de servicios en la nube utilizados por la carga de trabajo o la aplicación. Un arquitecto de seguridad debe documentar y comunicar las responsabilidades que cubren el diseño, la construcción y la ejecución de los servicios de seguridad. Sin claridad, pueden existir brechas en la seguridad de la solución.

Cada dimensión tiene un impacto diferente en las responsabilidades compartidas:

• Modelo de servicio en la nube: la definición del NIST de computación en la nube, los diferentes ámbitos de responsabilidad en función del modelo de servicio en la nube, como IaaS, PaaS, SaaS o nube distribuida. Los servicios de seguridad son parte de las responsabilidades compartidas. Por ejemplo, las responsabilidades compartidas de IBM Cloud incluyen la gestión de identidad y acceso, así como el cumplimiento de seguridad y normativas. Las responsabilidades compartidas para estas categorías varían según el modelo de servicio en la nube.
   

• Plataforma computacional: el alojamiento de una carga de trabajo puede ser una o más plataformas computacionales, como servidores bare metal, servidores virtuales, plataformas de contenedores y sin servidor. Cada plataforma informática tiene un conjunto diferente de responsabilidades compartidas. Por ejemplo, los servidores bare metal requieren que el propietario de la carga de trabajo sea responsable de todos los controles de seguridad en la plataforma, excepto el hardware físico y la integración de la red.
   

• Proveedor de servicios en la nube: las responsabilidades también varían en función del proveedor de servicios en la nube. Por ejemplo, la plataforma Kubernetes de cada proveedor de servicio en la nube es diferente (a menos que se utilice Red Hat OpenShift), ya que cada una consta de un conjunto diferente de paquetes de código abierto curados.

Entonces, ¿por qué debería preocuparse un arquitecto de seguridad por las diferencias en la propiedad de los servicios? El equipo que proporciona las operaciones de seguridad puede tener servicios de seguridad predefinidos para respaldar el funcionamiento del servicio. Los servicios de seguridad pueden ser parte de la plataforma en la nube o pueden estar on premises y requerir una amplia integración.

Por ejemplo, un equipo de operaciones de seguridad interna puede utilizar una tecnología diferente de un integrador de sistemas global (GSI) como IBM Consulting. Para el equipo de seguridad interno, su plano de control que aloja los servicios de seguridad puede estar on premises, mientras que el GSI puede estar utilizando servicio en la nube proporcionados por otro proveedor de servicios en la nube.

Para el modelo en la nube de software como servicio (SaaS), solo la administración de seguridad de las aplicaciones está disponible para el consumidor del servicio en la nube. La seguridad suele estar integrada en la aplicación como parte del servicio, con un alcance limitado para controlar la configuración de seguridad. En este caso, el proveedor de SaaS tiene la mayoría de las responsabilidades de las operaciones de seguridad.

Sin responsabilidades documentadas, es posible que no haya propietarios asignados para diseñar, construir y ejecutar componentes de seguridad que dependen de la ejecución de la carga de trabajo. Comprender las responsabilidades compartidas de los servicios de seguridad permite que la arquitectura de la solución satisfaga las necesidades operativas y evita una reelaboración de la solución en una etapa posterior del proyecto.

Los servicios de seguridad en una arquitectura de nube híbrida utilizan diferentes modelos de servicios en la nube, plataformas informáticas y proveedores de servicios en la nube. Estos servicios necesitan una arquitectura acordada de plano de control para proporcionar una gestión y supervisión coherente de la seguridad y el cumplimiento.

En una empresa que tiene cargas de trabajo en un centro de datos local, el plano de control puede residir en un centro de datos local para ser resistente a una falla de un proveedor de servicios en la nube. Sin embargo, un servicio de seguridad on premises no necesariamente tendrá la capacidad de gestionar completamente la plataforma en la nube. Por lo tanto, diseñe una arquitectura de plano de control para informar el estado de seguridad e identificar riesgos en los diferentes proveedores de servicios en la nube.

En el caso de las organizaciones nativas de la nube, el alojamiento del plano de control podría realizarse en otra nube, en un punto de presencia (POP) o en un centro de datos de coubicación. Es posible que sea necesario que el plano de control de seguridad esté disponible, incluso si se ha producido una falla en un proveedor de servicios en la nube.

Como arquitecto de seguridad, es importante documentar y acordar una decisión arquitectónica para garantizar la alineación en la arquitectura del plano de control de seguridad en toda la organización. Tome esta decisión al principio del proyecto para garantizar que la solución cumpla con la estrategia de la organización.

La seguridad no consiste principalmente en desplegar capacidades de seguridad, sino en proteger los datos y procesos empresariales frente a las amenazas. Utilice un enfoque sistemático para rastrear los flujos de datos a través del sistema e identificar los controles de seguridad necesarios para proteger los datos en tránsito, en reposo y en uso.

Los arquitectos deben identificar datos sensibles para su protección comenzando con un diagrama de contexto del sistema para identificar el límite del sistema y las interacciones externas que inician los flujos de datos a través del sistema. Luego, los flujos de datos internos de la aplicación se examinan utilizando un diagrama para describir los componentes funcionales, como un diagrama de componentes.

A medida que los arquitectos se desplazan hacia la implementación, examinan los flujos de datos entre los componentes desplegados en la infraestructura de la nube utilizando un diagrama de arquitectura de la nube. IBM creó un lenguaje de diseño de diagramas técnicos que permite un diseño independiente de un proveedor de servicios en la nube.

Para identificar las amenazas a estos flujos de datos, utilice modelos de amenazas tanto para los componentes funcionales de la carga de trabajo como para la infraestructura de la carga de trabajo.

En conjunto, estas técnicas y artefactos ofrecen un enfoque repetible y coherente del pensamiento arquitectónico para la seguridad y el cumplimiento.

Al procesar los datos más sensibles, considere otra capa de protección mediante el uso de computación confidencial y cifrado homomórfico.

Un sistema debe cumplir con muchos requisitos de control diferentes y la lista puede volverse larga y difícil de gestionar. En lugar de trabajar con muchos requisitos individuales, trabaje con procesos, servicios o capacidades que agrupen los requisitos en capacidades de entrega. Por ejemplo, la gestión del ciclo de vida de las identidades o la detección de componentes no autorizados son posibles capacidades de entrega.

Siga estos pasos para gestionar el cumplimiento de manera más eficaz:

1. Cree un marco de cumplimiento único con trazabilidad hasta las fuentes originales.
2. Asigne los requisitos del marco de cumplimiento a un conjunto de capacidades de entrega.
3. Garantice capacidades conformes a la normativa en todas las etapas de diseño, construcción, prueba y operación.
4. Continúe cumpliendo con los requisitos en producción.

El arquitecto de seguridad debe garantizar que las capacidades de seguridad tengan objetivos de nivel de servicio (SLO) asociados, acuerdos de responsabilidades, etc.

A menudo existe la necesidad de garantizar que los datos de un cliente, línea de negocio o entorno no se filtren a otro. La separación debe tener lugar para la ejecución de la carga de trabajo y el almacenamiento de datos. Podría ser tan simple como una tabla diferente en una base de datos o servidores físicos separados.

La nube híbrida ofrece muchas opciones para imponer la separación del procesamiento de datos. La separación debe tener lugar entre:

1. Cargas de trabajo o aplicaciones: por ejemplo, contabilidad frente a recursos humanos
2. Entornos: por ejemplo, desarrollo, prueba y producción
3. Clientes: por ejemplo, cliente A frente a cliente B
4. Ubicación: por ejemplo, Reino Unido frente a Estados Unidos

Hay muchas opciones diferentes para la segregación dentro de un entorno de nube híbrida que ofrecen diferentes capacidades y garantías:

1. Cuenta Enterprise
2. Cuenta en la nube
3. Grupo de recursos
4. Nube privada virtual
5. Dominio de ejecución: por ejemplo, un contenedor o imagen de servidor
6. Proyecto
7. Dominio de gestión de claves
8. Dispositivos físicos

Las políticas de la organización deben definir qué tipo de separación es adecuada para la carga de trabajo que procesa los datos. Por ejemplo, la política puede exigir que el alojamiento de los datos de los clientes de producción no se realice en un entorno que no sea de producción. El nivel mínimo de separación necesario es una cuenta en la nube diferente, ya que ahí es donde se lleva a cabo la gestión de la identidad y el acceso.

Relacionado con la separación de datos está el tema de la soberanía de los datos. Ciertos países están imponiendo restricciones sobre dónde puede tener lugar el procesamiento y el acceso a los datos. La entrada en el blog “Abordar las regulaciones y la innovación con la nube soberana“ proporciona un análisis sobre una jerarquía de las necesidades de soberanía de datos.

El modelado de amenazas se suele considerar una técnica para identificar y validar los controles de seguridad de los datos que circulan por un sistema.

Sin embargo, el modelado de amenazas tiene un segundo objetivo: identificar amenazas para su supervisión en un sistema de supervisión de amenazas. El arquitecto de seguridad debe trabajar para identificar una lista priorizada de amenazas. Luego define los casos de uso necesarios para la capacidad de detección de amenazas. Implemente y pruebe los casos de uso de detección con runbooks de respuesta a incidentes para permitir una respuesta eficaz a las amenazas.

Garantice la trazabilidad documentada entre las amenazas, los casos de uso de detección de amenazas y los runbooks de respuesta a incidentes para garantizar el diseño y la entrega completos del proyecto.

Con los centros de datos on premises del pasado, los equipos de operaciones de seguridad completaban las actividades en cuestión de días u horas y no requerían niveles de servicio estrictos. Con la automatización de infraestructura como código (IaC), la pérdida de un servicio de seguridad centralizado, como secretos o gestión de certificados, tiene un impacto inmediato en la disponibilidad de una aplicación. Por lo tanto, los servicios de seguridad requieren niveles de servicio y una arquitectura para cumplir con los requisitos de disponibilidad.

Defina para cada capacidad o servicio de seguridad:

1. Horario de servicio
2. Tiempos de respuesta ante incidentes, problemas y cambios
3. Habilidades y experiencia del personal de operaciones
4. Procedimientos detallados y probados para cumplir con los requisitos del servicio
5. Automatización para satisfacer los requerimientos de servicio

Si el equipo de operaciones de seguridad interna no puede satisfacer las demandas de una carga de trabajo nativa de la nube, considere si es adecuado contratar a un proveedor de servicios de seguridad gestionados.

Si lo piensa, muchos servicios de seguridad hoy necesitan resiliencia y niveles de servicio al menos tan buenos como la carga de trabajo que admiten.

Las antiguas formas de trabajar hacían que la seguridad fuera una cuestión secundaria, lo que dificultaba la configuración de la seguridad y la aplicación de parches, ya que no se abordaba en las primeras fases del ciclo de vida del desarrollo. Con las prácticas de trabajo de DevOps, los estándares de creación de seguridad deben:

1. Incluirse en los entornos de desarrollo y prueba.
2. Ser coherentes desde el desarrollo inicial hasta la producción completa.
3. Probarse continuamente para el cumplimiento continuo.

Los procesos de compilación deben evitar el despliegue inseguro de una carga de trabajo en todas las etapas del desarrollo y operación para garantizar que la seguridad no sea una ocurrencia secundaria.