Añadir seguridad a una solución en el final del ciclo de diseño y desarrollo suele resultar en costosos sacrificios de reestructuración y usabilidad que restan capacidad y experiencia de usuario a la solución. Diseñar soluciones 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 cualificado y con experiencia. Los principios de diseño de seguridad, como los que se siguen, guían las prácticas de pensamiento arquitectónico.

El proceso de diseño debe comenzar con el uso del pensamiento de diseño empresarial para centrarse en los resultados de usuario requeridos para las partes interesadas en el riesgo, el cumplimiento y la seguridad, tanto internas como externas a una organización. Los stakeholders externos incluyen clientes, gobiernos y reguladores. Los stakeholders internos incluyen quienes 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 implementación de la nube. A continuación, se completa la definición de características, como la resiliencia, el rendimiento y la escalabilidad, para los servicios de seguridad.

Después de la definición de los requisitos y la arquitectura, puede llevarse a cabo la ingeniería de la funcionalidad y la infraestructura de seguridad, incluido el seguimiento del principio Seguridad por defecto.

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

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

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

Para implementar el principio de menor privilegio, 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 datos de riesgo de sus recursos digitales para descubrir nuevas perspectivas de riesgo a nivel empresarial que le ayuden 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 de 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 según el cual un usuario o un software deben verificarse constantemente para evaluar si siguen teniendo un contexto seguro. La intención de la verificación continua es encontrar los problemas y vulnerabilidades de seguridad lo antes posible e idealmente lo hacen los  actores de amenazas.

La verificación continua confirma que las entidades son quienes dicen ser mediante retos como una solicitud de autenticación de segundo factor. Una carga de trabajo puede requerir una actualización para soportar la verificación continua de usuarios y software mediante soluciones que utilicen una Zero Trust Network Architecture (ZTNA). Las organizaciones centradas en ofrecer las mejores experiencias de usuario dudan en interrumpir al usuario con solicitudes innecesarias; sin embargo, este nivel de garantía de identidad es crítico para zero trust.

Es posible que un actor de amenazas ya haya vulnerado una organización. Si una organización solo busca amenazas en los límites externos y no aquellas que han utilizado un mecanismo válido para eludir los controles de seguridad, es posible que no detecte una violación de seguridad hasta mucho tiempo después. Asumir la vulneración es el principio por el que una organización asume que un actor de amenazas ha producido una vulneración.

El enfoque requiere que la gestión de amenazas añada detección interna proactiva, búsqueda de señales de alerta temprana, búsqueda de amenazas y uso de manuales 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 seguir siendo seguro.

La defensa en profundidad es el principio según el cual un sistema tiene varias capas de defensa, de modo que si una capa falla, otra sigue en pie para proteger los datos sensibles 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 las vulnerabilidades, las vías o los métodos, a veces denominados vectores de ataque, que los actores de amenazas pueden utilizar para obtener acceso no autorizado a la red o a los datos sensibles, o para llevar a cabo un ciberataque. A medida que las organizaciones adoptan cada vez más servicios en la nube y modelos de trabajo híbridos (on-premises/desde casa), sus redes y las superficies de ataque asociadas son cada día mayores y más complejas.

Minimizar la superficie de ataque es el principio según el cual un sistema debe reducir el alcance de los vectores de ataque, de forma que se reduzcan las posibles vías de acceso de un actor de amenaza. 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 en las instalaciones 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 del software, la habilitación de recursos no utilizados, la TI invisible y el software sin datos.

2. La superficie de ataque expone los activos y la información que normalmente solo pueden acceder los usuarios con acceso autorizado a la oficina física o a los dispositivos de endpoint de la organización. Esto incluye ataques de usuarios internos negligentes, 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 esperanza de engañar a los usuarios para que conecten los dispositivos a sus ordenadores 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 sensibles 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 controles, como claves de cifrado, o tener derechos para realizar acciones altamente privilegiadas, como transferir grandes sumas de dinero. Incluso cuando un sistema controla a los usuarios, pueden abusar de sus derechos, lo que puede tener consecuencias catastróficas para la empresa.

La separación de funciones es el principio según el cual los usuarios con un acceso poderoso a los datos o las acciones necesitan más de un usuario para completar la acción. Proporciona a una organización la capacidad de dividir las funciones administrativas entre individuos 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 para que ningún administrador tenga conocimiento de toda la clave. En las transacciones comerciales, la aplicación puede requerir que la persona que solicita una transacción tenga uno o más aprobadores para que la complete.

Para algunos sectores, un regulador puede exigir la separación de funciones para funciones poderosas como parte de la orientación regulatoria. La separación de funciones ayuda a las empresas a cumplir la normativa gubernamental 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 insegura, 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 en un estado seguro listos para usar. 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 puede realizar 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 comprueba constantemente, desde el desarrollo del sistema hasta el sistema en funcionamiento. La intención del cumplimiento continuo es encontrar los problemas y vulnerabilidades de seguridad antes de que lo hagan los actores de amenazas.

Lo ideal es que las comprobaciones de cumplimiento estén totalmente automatizadas y abarquen todas las configuraciones de seguridad, incluyendo la plataforma en la nube, la plataforma de contenedores, el middleware y las imágenes informáticas, como los servidores virtuales y los contenedores. Con las imágenes informáticas, un mejor enfoque puede ser utilizar la infraestructura como código (IaC) para reemplazar toda la imagen con regularidad.

Las responsabilidades compartidas para la prestación de servicios 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 el funcionamiento de los servicios de seguridad. Sin claridad, pueden existir lagunas 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 de NIST de cloud computing es el diferente alcance de responsabilidades según el modelo de servicio en la nube, como IaaS, PaaS, SaaS o nube distribuida. Los servicios de seguridad forman parte de las responsabilidades compartidas. Por ejemplo, las responsabilidades compartidas de IBM Cloud incluyen la gestión de identidad y accesos, así como el cumplimiento de seguridad y normativas. Las responsabilidades compartidas para estas categorías varían en función del modelo de servicio en nube.
   

• Plataforma computacional: el alojamiento de una carga de trabajo puede ser una o más plataformas computacionales, como servidores físicos, servidores virtuales, plataformas de contenedores y sin servidor. Cada plataforma computacional 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 de la plataforma, excepto del hardware físico y la integración de la red.
   

• Proveedor de servicios en la nube: las responsabilidades también cambian en función del proveedor de servicios en la nube. Por ejemplo, la plataforma kubernetes de cada proveedor de servicios en la nube es diferente (a menos que esté utilizando Red Hat OpenShift), ya que cada una consta de un conjunto diferente de paquetes de código abierto seleccionados.

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

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

Para el modelo de servicio 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 la seguridad. En este caso, el proveedor de SaaS tiene la mayor parte de las responsabilidades de las operaciones de seguridad.

Sin responsabilidades documentadas, es posible que no haya propietarios asignados para diseñar, crear y ejecutar componentes de seguridad que dependan 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 de plano de control acordada para ofrecer una gestión y supervisión coherentes de la seguridad y el cumplimiento.

En una empresa que tiene cargas de trabajo en un centro de datos on-premises, el plano de control puede residir en un centro de datos on-premises para ser resiliente a un fallo de un proveedor de servicios en la nube. Sin embargo, un servicio de seguridad on-premises no tiene por qué ser capaz de gestionar por completo la plataforma en la nube. Por lo tanto, diseñe una arquitectura de plano de control para informar sobre 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. Puede que el plano de control de seguridad tenga que estar disponible, incluso si se ha producido un fallo 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 asegurarse de que la solución cumple con la estrategia de la organización.

La seguridad no consiste principalmente en implementar 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 con el fin de identificar los controles de seguridad para proteger los datos en tránsito, en reposo y en uso.

Los arquitectos deben identificar los 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. A continuación, se examinan los flujos de datos internos de la aplicación utilizando un diagrama que describa los componentes funcionales, como un diagrama de componentes.

A medida que los arquitectos pasan a la fase de implementación, examinan los flujos de datos entre los componentes implementados en la infraestructura de nube mediante un diagrama de arquitectura de nube. IBM ha creado 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 el modelado 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 normativo.

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

Un sistema debe cumplir 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 forma más eficaz:

1. Crear un marco de cumplimiento único con trazabilidad hasta las fuentes originales.
2. Asignar los requisitos del marco de cumplimiento a un conjunto de capacidades de entrega
3. Garantizar las capacidades de cumplimiento en todas las etapas de diseño, construcción, prueba y operación.
4. Continuar cumpliendo con los requisitos en producción.

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

A menudo es necesario garantizar que los datos de un cliente, línea de negocio o entorno no se filtran a otro. Es necesario separar la ejecución de la carga de trabajo y el almacenamiento de los 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 forzar la separación del proceso 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, pruebas y producción
3. Clientes: por ejemplo, cliente A frente a cliente B
4. Ubicación: por ejemplo, Reino Unido frente a Estados Unidos

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

1. Cuenta empresarial
2. Cuenta en la nube
3. Grupo de recursos
4. Nube privada virtual
5. Dominio de ejecución: por ejemplo, una imagen de contenedor o 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 el tema de la separación de datos está el 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 de blog “Addressing Regulations and Driving Innovation with Sovereign Cloud“ ofrece un debate sobre una jerarquía de las necesidades de soberanía de los datos.

El modelado de amenazas suele considerarse 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 propósito: identificar las amenazas para su supervisión en un sistema de vigilancia de amenazas. El arquitecto de seguridad debe trabajar para identificar una lista prioritaria 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 completaron las actividades en cuestión de días u horas y no requerían niveles de servicio estrictos. Con la automatización de la infraestructura como código (IaC), la pérdida de un servicio de seguridad centralizado, como la gestión de secretos o 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. Horas de servicio
2. Tiempos de respuesta a incidentes, problemas y cambios
3. Habilidades y experiencia del personal de operaciones
4. Procedimientos probados y detallados para cumplir con los requisitos del servicio
5. Automatización para adaptarse a los requisitos del servicio

Si el equipo de operaciones de seguridad internas no puede cumplir con las exigencias de una carga de trabajo nativa de la nube, considere si un proveedor de servicios de seguridad gestionados es adecuado.

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

Las viejas formas de trabajar significaban que la seguridad era una ocurrencia tardía, lo que dificultaba la configuración de la seguridad y la aplicación de parches, ya que no se realizaba al principio del ciclo de vida del desarrollo. Con las prácticas de trabajo de DevOps, los estándares de compilación de seguridad deben:

1. Incluirse en los entornos de desarrollo y pruebas.
2. Ser coherente desde el desarrollo inicial hasta la producción completa.
3. Someterse a pruebas continuas para garantizar el cumplimiento continuo.

Los procesos de compilación deben evitar la implementación insegura de una carga de trabajo en todas las fases de desarrollo y operación para garantizar que la seguridad no sea una idea de última hora.