Arquitectura de seguridad: principios básicos

Podemos entender a los principios de arquitectura de seguridad como las pautas generales o fundamentos a seguir para garantizar la seguridad de sistemas y redes, estos pueden ser considerados buenas prácticas y directrices que hoy en día se encuentran ampliamente aceptadas.

Establecer y seguir estos principios nos ayuda entonces a proteger los activos digitales, prevenir ciberataques y mantener la integridad, confidencialidad y disponibilidad de la información. Conforman una base sobre la cual se pueden construir estrategias adecuadas de seguridad, y al adherirse a ellos, las organizaciones fortalecen su postura de seguridad y reducen los riesgos.

Nada de esto podría ocurrir sin la figura principal que se encarga de planificar y diseñar la seguridad en dichos contextos: el arquitecto de seguridad.

Principios de arquitectura segura

Defensa en profundidad

El primero de los principios que mencionaremos en este post. Este consiste en crear una suerte de “carrera de obstáculos”, para dificultarle el trabajo al adversario. Si imaginamos un viejo modelo de seguridad como el castillo (es un ejemplo clásico), vemos que se diseñó con muros gruesos y altos para mantener a los “buenos” dentro y a los “malos” fuera.

Funcionaba bastante bien hasta que nos dimos cuenta de que los “buenos” a veces necesitaban salir, es así que tuvimos que añadir una puerta a esta estructura, que paradójicamente se convirtió en una vulnerabilidad. Para reforzarla, agregamos medidas adicionales, como cavar un foso alrededor de la estructura para que fuera aún más difícil de franquear e instalamos un puente levadizo sobre el foso, aumentando aún más la dificultad. Además, como si fuera poco, hasta llegamos a tener perros para proporcionar seguridad adicional. En este modelo, no se depende de un único mecanismo de seguridad para mantener seguro el sistema. Para aplicar este principio a un ejemplo de seguridad moderno, tenemos un usuario en una estación de trabajo cuyo flujo de datos atravesará una red para llegar a un servidor web, que luego llegará a un servidor de aplicaciones y, por último, a una base de datos.

Para implementar defensa en profundidad en este escenario podríamos incorporar la autenticación multifactor (MFA), y agregar para el dispositivo en sí (supongamos que es una laptop o smartphone) un software de gestión de dispositivos móviles (MDM) que garantiza que la política de seguridad se aplica en el dispositivo, incluidos los parches, contraseñas y otras medidas. También podríamos añadir un sistema Endpoint Detection and Response (EDR), un tipo de solución de última generación que proporciona capacidades de detección y respuesta para salvaguardar la plataforma contra múltiples tipos de amenazas, incluyendo malware. Desde el punto de vista de la red, podemos incluir un firewall para proteger el servidor web de amenazas externas y permitir selectivamente el tráfico de vuelta a estas zonas más sensibles. Además, podemos realizar análisis de vulnerabilidades en los servidores web y de aplicaciones para asegurarnos de que no son susceptibles de sufrir ataques. Por último, al requerir datos, les aplicamos cifrado, implementando controles de acceso para salvaguardarlos.

De este modo, hemos creado un sistema que se apoya en múltiples mecanismos de seguridad, de tal forma que si uno de ellos falla, el resto del sistema sigue funcionando, y no tenemos ningún punto único de fallo.

Principio del mínimo privilegio

El segundo principio que exploraremos es el principio del mínimo privilegio. Esencialmente, este establece que los derechos de acceso deben concederse solo a las personas que los necesiten, estén autorizadas, puedan justificar su acceso y solo durante el tiempo necesario. Por ejemplo, si consideramos tres usuarios, donde el primero no tiene una necesidad funcional, por lo que no le concedemos acceso, y los otros dos usuarios demuestran una necesidad legítima, y les proporcionamos el acceso adecuado. Incluso para estos, no les concedemos acceso indefinidamente, sino que reevaluamos periódicamente si el acceso sigue estando justificado, y de lo contrario, lo revocamos.

Otro aspecto de este principio es el refuerzo del sistema, más conocido como hardening. Si tenemos un servidor web que ejecuta HTTP por defecto, necesario para el tráfico web, y tiene habilitados los servicios FTP y SSH para la conectividad remota, debemos preguntarnos si realmente necesitamos estos servicios adicionales. Si no es así, deberíamos eliminarlos. Cada servicio que eliminamos reduce nuestra superficie de ataque.

Además, deberíamos eliminar los ID predeterminados innecesarios y cambiar las credenciales predeterminadas de los ID que conservamos. Por ejemplo, si el ID de administrador está configurado inicialmente como "admin", deberíamos sustituirlo por otro no conocido.

También es crucial cambiar las contraseñas por defecto, ya que no queremos que nuestro sistema tenga una configuración básica (vainilla) porque los actores maliciosos la pueden identificar y explotar más fácilmente. Más allá de esto, un proceso de recertificación anual (o incluso más frecuente) ayuda a hacer frente a la acumulación de privilegios. Durante la recertificación, revisamos todos los derechos de acceso de los usuarios para asegurarnos de que siguen estando justificados.

Al adherirnos al principio del mínimo privilegio, concedemos acceso solo a lo que es necesario durante el tiempo requerido, reforzamos los sistemas, eliminamos la acumulación, abandonamos la lógica de "por si acaso".

Separación de funciones

El tercer principio de seguridad a tener en cuenta es el concepto de separación de funciones, que garantiza no tener un punto de control centralizado. En su lugar, se crea un escenario en el que múltiples actores maliciosos deberían ponerse de acuerdo para comprometer el sistema. Un ejemplo del mundo físico podría ser el caso de dos personas y una puerta que tiene dos cerraduras; una tiene la llave de la primera cerradura, mientras que la otra tiene la llave de la segunda. Por separado, no pueden abrir la puerta, pero si colaboran, sí. En este escenario, no hay un único punto de control, lo que proporciona separación de funciones.

En el ámbito de la tecnología podemos aplicar esto a los procesos de aprobación de acceso. Por ejemplo, un usuario presenta una solicitud de acceso a una base de datos, y un aprobador la revisa y decide si la concede o deniega en función de una necesidad justificada por el negocio. Al garantizar que el solicitante y el aprobador son personas distintas, evitamos un único punto de control.
La separación de funciones requiere colaboración para comprometer el sistema, lo que se convierte en un reto cuando muchas personas tienen que trabajar juntas manteniendo el secreto.

Seguridad por diseño

El cuarto principio de seguridad que discutiremos es seguridad por diseño, lo que se refiere a que la seguridad no debe ser una ocurrencia tardía. De la misma forma que al diseñar un edificio en una zona sísmica que requiere resistir el movimiento, no se construye primero y luego se decide hacerlo a prueba de terremotos, sino que se incorpora el requerimiento desde el principio. En proyectos de tecnología normalmente empezamos con la fase de requisitos, pasamos al diseño, luego al código, instalamos el código escrito, lo probamos y, por último, lo desplegamos en producción.

Lo ideal sería alimentar este ciclo continuamente, manteniendo un proceso de desarrollo continuo, pero lo que no queremos es esperar a las últimas fases para abordar la seguridad una vez que la solución ya está fuera. La seguridad no puede ser un complemento al final, sino que debe estar presente a lo largo de todo el proceso, por lo que debemos examinar los aspectos de seguridad durante la fase de requisitos, e integrar la seguridad en el diseño, teniendo en cuenta los principios de desarrollo seguro en cada paso, garantizando una instalación segura, protegiendo los datos de prueba, y continuando con las pruebas en producción. Así, la seguridad no es algo que hagamos a última hora, sino algo que incorporamos de forma omnipresente.

Keep it Simple, Stupid

El quinto principio de que exploraremos es el conocido como K.I.S.S. por su sigla en inglés de “Keep it Simple, Stupid” (Mantenlo simple, estúpido). En otras palabras, no debemos complicar las cosas más de lo necesario, ya que facilitaríamos el trabajo a los atacantes y se las dificultaríamos a usuarios legítimos. Cuando diseñamos medidas de seguridad, a menudo agregamos complejidad para disuadir el acceso no autorizado, pero a veces deriva en un complejo laberinto que los usuarios deben atravesar, y que pueden desalentar el uso esperado, o fomentar eludir las medidas, que es un resultado que queremos evitar. Si hacemos que sea más difícil hacer lo correcto que lo incorrecto, la gente optará por el camino inadecuado, por lo que debemos hacer que el sistema sea seguro, pero también lo más sencillo posible para los usuarios legítimos.

Por ejemplo, si establecemos reglas de contraseñas (como combinación de letras mayúsculas y minúsculas, números, caracteres especiales y una longitud mínima) también exigimos a los usuarios que mantengan contraseñas diferentes para cada sistema y que las cambien periódicamente. Pero el conjunto de reglas crea un problema que hace que cuando los usuarios encuentran una contraseña que se ajusta a los criterios, la utilizan en varios sistemas y la anotan en algún sitio, reduciendo la seguridad, que es justamente lo que queremos evitar. Por eso decimos que la complejidad es enemiga de la seguridad, y queremos que el sistema sea lo suficientemente complejo como para disuadir a los atacantes, pero sencillo para los usuarios legítimos.

Debe tenerse en cuenta también que más allá de los principios a considerar, hay algunos a evitar por completo. El más importante es el de seguridad por oscuridad, que se refiere a confiar en el conocimiento secreto para la seguridad de un sistema. Lo que queremos en lugar de eso es un sistema abierto y observable. Esta idea se conoce como uno de los principios de Kerckhoff, que afirma que un sistema criptográfico debe seguir siendo seguro aunque se conozcan todos sus detalles, excepto la clave. Si la seguridad la proporciona una caja negra, no podemos ver cómo funciona, e incluso si el creador afirma que es irrompible y lo ha probado, significa que no ha encontrado la forma de romperlo, pero eso no significa que no pueda romperse. El mismo planteamiento lo aplicamos para asegurar redes, aplicaciones y sistemas.

El rol del arquitecto

Para poder implementar lo antedicho se requiere un rol con la responsabilidad y conocimiento adecuados para garantizar su concreción. Esto es tarea del arquitecto de ciberseguridad, y abarca no solo los aspectos técnicos, sino también la consideración de las necesidades y preocupaciones de las partes interesadas. Tanto en los sistemas físicos como en los informáticos, el arquitecto de ciberseguridad debe dar prioridad a la seguridad y la protección a la hora de diseñar la arquitectura. Al igual que un arquitecto que diseña un edificio incorpora medidas de seguridad como cerraduras resistentes, cámaras de vigilancia, detectores de humo y cortafuegos, el arquitecto de ciberseguridad debe implementar medidas para mitigar los riesgos y mejorar la seguridad general.

Cuando se trata de sistemas informáticos, el arquitecto de ciberseguridad usa diversas herramientas, que van desde diagramas que ofrecen contexto de la empresa y los sistemas, y diagramas de arquitectura de alto nivel para comprender la relación entre los componentes y los posibles puntos de fallas. Esta comprensión holística permite identificar vulnerabilidades y diseñar medidas de seguridad eficaces. Para garantizar la seguridad en todas las fases de un proyecto, los arquitectos de ciberseguridad se basan en una serie de conocimientos, marcos y modelos, y se apoyan en los principios anteriormente mencionados para establecer bases sólidas.

Es clave involucrar al arquitecto de ciberseguridad desde las primeras fases del proyecto, en lugar de intentar agregar la seguridad a posteriori, que muchas veces termina siendo “a martillazos limpios”. Al involucrarlos desde el principio, las organizaciones pueden abordar de forma proactiva los posibles retos de seguridad e integrarla con menos problemas en la arquitectura. Los ámbitos en los que operan los arquitectos de ciberseguridad son diversos y están en constante evolución. Abarcan la gestión de identidades y accesos, la seguridad de puntos finales, la seguridad de las redes, de las aplicaciones, la protección de datos, la gestión de eventos e información de seguridad y la respuesta a incidentes. Aprovechando su experiencia en estas áreas, pueden crear arquitecturas de seguridad que protejan a las organizaciones frente a las amenazas conocidas y emergentes.

Conclusiones

Al adoptar estos principios, evitando la seguridad por oscuridad, podremos establecer una arquitectura de ciberseguridad sólida. Para llevar adelante esta tarea es fundamental el papel de un arquitecto que facilite la creación de soluciones adecuadas. Al tener en cuenta las necesidades de cada una de las partes interesadas, integrar medidas de seguridad en la arquitectura y aprovechar los principios y marcos establecidos, las organizaciones pueden operar realmente con mayor confianza. Es claro entonces que la participación temprana y permanecer al tanto de la evolución de los temas de ciberseguridad es un componente clave que ayuda a que las organizaciones se mantengan realmente resilientes ante las amenazas.