Siguiendo la línea de artículos anteriores “Qué es SSE y cómo se relaciona con SASE” y “Tecnologías de protección SSE: ZTNA, ATP, RBI, DLP, UEBA y CASB”, relacionados con la tecnología SSE, procederemos a mostrar algunas de las posibilidades prácticas reales para las que se utilizan este tipo de tecnologías.
Os recuerdo que este tipo de plataformas de protección descifran todo el tráfico por defecto, para poder llegar al máximo control de las comunicaciones, por lo que son conscientes de cualquier flujo de información entre aplicativos pudiendo comprender los comportamientos de todas las plataformas de nube soportadas.
¿Por dónde empezar?
- Definición de accesos a recursos
Primero se deberá definir teóricamente qué accesos son necesarios, tanto a recursos internos como externos, para establecer una base de reglas de acceso.
Como inicio, lo habitual es realizar un estudio tanto de los usuarios o grupos que deben acceder a recursos internos, así como de los que tienen que acceder a ciertos recursos externos, para la posterior configuración de Zero Trust.
- Definición de accesos de navegación
En cuanto a la navegación web, se deberá estudiar inicialmente las categorías de páginas web que son aceptables y las que no lo son debido a su riesgo, para la realización de un control de dichos accesos, evitando así el riesgo parcialmente o por completo en cada caso particular.
- Protección ante amenazas
Igualmente es necesaria la detección de descargas de ficheros maliciosos o inyecciones de código dirigidas al navegador, política que se establecerá inmediatamente antes de permitir cualquier acceso.
- Control de acceso granular a aplicaciones
Una vez realizado lo anterior, se complementará con la detección de comportamiento de aplicaciones, en las que se procede a analizar los casos en los que se debería prohibir el acceso a ciertas aplicaciones, pero también en determinados casos se puede permitir únicamente cierto comportamiento dentro del aplicativo, generalmente aplicativos SaaS.
Para poder elegir qué plataformas de nube son aptas para su uso corporativo, existe dependiendo de la plataforma SSE utilizada, una base de datos de características y categorización de cada aplicación, evitando tener que hacer una tediosa investigación manual en busca del nivel de cumplimiento normativo y riesgo de cada una de las aplicaciones a incluir en la política de acceso corporativa, mejorando así la toma de decisiones.
- Casos prácticos (Acceso granular a un recurso)
Un ejemplo práctico sería permitir el uso de LinkedIn únicamente como “sólo lectura” para los usuarios en general, pero permitir el acceso total al departamento de recursos humanos o marketing para que puedan publicar contenido, hacer búsquedas, etc.
En caso de un grupo de usuarios que deba formarse, también se le permitiría el acceso a la web de formación de LinkedIn.
Por tanto, el comportamiento puede ser controlado con un gran nivel de precisión.
- Limitación básica de envío de datos a repositorios de datos
Combinando esta precisión con el conocimiento de la instancia del servicio Cloud que se está utilizando corporativamente, se puede llegar a cosas tan interesantes como lo siguiente:
Permitir la lectura o escritura en el SharePoint corporativo, pero permitir únicamente la lectura en SharePoint de terceros, lo cual, en conjunción con una regla de prohibición de acceso a repositorios de ficheros externos no corporativos como Dropbox, drive, correo personal, etc., se conseguiría controlar en gran parte el envío de datos corporativos al exterior.
- Control de fuga de información
Ahondando más en este caso, incluyendo la detección de fuga de información DLP, ya sea basada en reglas implementadas en producto o clasificación aportada por un producto de terceros, tal como el provisto por Office 365 / Azure llamado AIP, se puede llegar a unos niveles muy interesantes de control.
Siguiendo con el ejemplo anterior, podríamos permitir el envío de ficheros a repositorios de ficheros de terceros en lugar de bloquearlo por completo, pero podríamos controlar a qué repositorios e instancias se podrían enviar dichos ficheros detectando si son corporativas o no, en combinación con el etiquetado DLP, tendríamos un ejemplo interesante:
Permitiríamos la descarga desde ciertos repositorios de terceros considerados seguros, por ejemplo, OneDrive.
Permitiríamos el envío de datos corporativos al SharePoint de la compañía en general, que es el uso habitual permitido. En caso de que los datos corporativos sean de carácter sensible, se permitiría la subida únicamente a las carpetas permitidas para dicho tipo de información en el SharePoint corporativo, evitando la desorganización de la información fuera de sus ubicaciones establecidas.
En el caso de que la información esté relacionada con cierto cliente, se permitirá el envío de datos relacionados con este a la instancia del cliente en SharePoint o One Drive, siempre que esta sea de un nivel de confidencialidad público o protegido, pero nunca para la información de carácter restringido o confidencial, que no podrá viajar fuera de los repositorios corporativos.
En este punto tendríamos una política en la que podríamos controlar el flujo de información sensible a través de las aplicaciones de la organización, así como envío a entornos de terceros de un modo seguro.
- Control del nivel de seguridad del endpoint (Security Posture)
Pero aún podríamos ir más allá. En este momento, estamos obviando que las máquinas desde dónde se realiza este tipo de accesos y transferencias de información pueden ser o no seguras.
Para garantizar que la información sensible no viaje a dispositivos inseguros, existe la posibilidad de realizar un “Posture Checking” o verificación local de requerimientos de máquina en el momento de login, previo a cualquier acceso.
En esta verificación, se puede determinar, por ejemplo, si la máquina está en dominio corporativo, tiene el antimalware instalado y actualizado, si el disco está cifrado, si cumple ciertas configuraciones de buenas prácticas (como por ejemplo el que no tenga activado el RDP para acceso remoto), que tenga activo el smb signing o que sólo pueda utilizar versiones modernas de SMB, así como un sinfín de controles, pudiendo categorizar la máquina como corporativa o adecuada para cierto nivel de accesos o como no corporativa, así como diferentes niveles intermedios.
En el caso anterior, imaginemos que restringimos el acceso de descarga de la información sensible corporativa únicamente a máquinas que cumplan ese “Posture Checking Corporativo” y que por tanto tengan el disco duro cifrado, lo cual ayudaría a garantizar la confidencialidad e integridad de los datos, allí donde estén.
En este punto, ya nos es posible controlar el flujo de datos sensibles tanto a nivel interno como externo allí dónde se encuentre el dato, así como obtener protección contra amenazas en ficheros tanto internamente dentro de una nube concreta como en el tránsito de información hacia otras ubicaciones de un modo seguro.
- Acceso condicional basado en comportamiento de riesgo del usuario (UEBA)
Aún podríamos mejorar el caso anterior, si nos basamos en el comportamiento del usuario, para determinar si es un usuario confiable o no confiable.
Las plataformas SSE pueden disponer de un “carné por puntos” para cada usuario, añadiendo o quitando puntos según los comportamientos de riesgo del usuario, para poder determinar un umbral de puntos a partir del cual se considere que el usuario está cometiendo demasiadas actividades de riesgo, categorizando así a los usuarios basados en su nivel de riesgo real.
Cuando el usuario realice ciertos comportamientos de riesgo, ya sean detectados mediante control estático de estos (como por ejemplo un envío de información a países no confiables) o mediante la detección dinámica a través del estudio de la línea base de comportamiento y análisis basado en IA, finalmente se traducirá en una pérdida del crédito del usuario, hasta alcanzar un nivel por debajo de un cierto umbral acordado como de riesgo.
En dicho momento se puede restringir el acceso al usuario a dicha información sensible hasta que no hable con un responsable, pudiendo así restablecer su crédito. De ese modo se podrían llevar a cabo una serie de acciones de concienciación relacionadas con el comportamiento detectado.
Si el comportamiento de riesgo persiste o empeora, podría llegarse a bloquear todo acceso disponible automáticamente, excepto por ejemplo el acceso a una url de la herramienta de ticketing, mostrando un popup con un mensaje explicativo, el cual dispondrá de un enlace a dicha herramienta para que reporte su caso y que este sea estudiado en detalle.
Como se puede observar, las combinaciones y posibilidades son infinitas y se pueden adaptar a cada caso particular.
- Posibilidades de actuación
En cuanto al comportamiento ante un caso, no sólo es aceptar, bloquear o lanzar un mensaje, también es posible que en determinados casos de emergencia, dónde un usuario no puede acceder a un recurso (como por ejemplo a una web no permitida), es posible realizar un bypass temporal, preguntando el motivo al usuario para que posteriormente un aprobador revise si el acceso solicitado fue lícito o no o incluso se podría llegar a establecer un flujo de aprobación para el acceso a un recurso o recursos determinados.
Empezar a implementar SSE: ¿Cuál es el siguiente paso?
Pensando en el control centralizado que permiten las herramientas SASE – SSE, la independencia de la ubicación dónde se esté para mantener un nivel uniforme de seguridad, nivel de acceso y visibilidad centralizada, es evidente que estamos tratando con una tecnología básica en el momento actual y futuro, en el que cada vez tenemos más complejidad y capas de seguridad.
Otro punto esencial de las tecnologías de protección actuales es que estas permitan la máxima interoperabilidad posible entre plataformas para poder intercambiar telemetría de amenazas y poder proporcionar una protección de conjunto mucho más eficaz. Algunos fabricantes se han tomado esto como máxima, facilitando al máximo la integración con terceras soluciones, pudiendo realizar diseños de seguridad que se aprovechen de las capacidades de todas las tecnologías aplicadas uniformemente en todas las plataformas existentes.
En este punto, pienso que la pregunta no es si mi organización va a disponer de dicha tecnología, sino de cuándo va a poder disponer de ella para comenzar a beneficiarse de todas las posibilidades que esta aporta.
En Open3s llevamos más de 15 años aportando valor y ayudando a nuestros clientes a evolucionar sus infraestructuras entendiendo sus necesidades, no sólo desde un punto de vista operativo sino también de impacto en sus procesos y aplicaciones de negocio, así como de su seguridad, ahora también en la seguridad del Cloud. Si quieres saber más, contacta con nosotros.
Autor: Abel Robledo, Cybersecurity Team Leader en Open3s.
