He estado analizando varias suites de prevención de pérdida/fuga de datos pero, en su documentación, no puedo encontrar cómo tratan HTTPS.
Uno de los 'vectores de fuga' es el envío de información a aplicaciones web a través de HTTPS. En cuyo caso, la única forma de detectar la fuga sería descifrarla.
Pero, para hacer eso, tendría que hacerse pasar por el servidor remoto, utilizando certificados falsos, como un ataque de hombre en el medio. Para evitar que los usuarios sospechen o se quejen, supongo que la corporación debe insertar su certificado como una CA válida en los navegadores de los dispositivos propiedad de la empresa.
Mis preguntas son:
- ¿Alguien tiene experiencia de primera mano en este tipo de escenario? ¿Puedes decirnos cómo lo implementaste?
- ¿Estoy en lo cierto o existe otra forma de administrar HTTPS (por ejemplo, detectar los datos en uso a nivel de escritorio con un agente)?
Respuesta1
Eso no es "como" un ataque de hombre en el medio, ES un ataque de hombre en el medio.
Lo implementa utilizando un servidor proxy que sustituirá su propio certificado por el certificado remoto. En el proceso, su navegador arrojará errores indicando que el certificado no es válido. Ese es el punto detrás de HTTPS y la certificación. Entonces, si tienes un usuario inteligente, sabrá que estás interceptando la información.
Puedes usar proxies que simplemente registran la actividad de una persona para poder registrar lo que está sucediendo y dónde está navegando, pero en realidad, si estás implementando medidas draconianas para evitar laposibilidadque alguien está robando su información, probablemente esté creando un lugar de trabajo que fomente el tipo de actitud que justifica, para el empleado, hacer esto en primer lugar. Y también tendrás que tener políticas de despido de RRHH para teléfonos móviles (grabando con cámaras), unidades USB y tal vez asegurarte de que no memoricen cosas también.
De todos modos, no existe una manera "simple" de romper el monitoreo HTTPS sin que se descubra alguna forma a menos que simplemente bloquee el acceso saliente a ese puerto con una regla de firewall o un filtro de proxy. De lo contrario, todo el objetivo de HTTPS no tiene sentido.
Respuesta2
Pero, para hacer eso, tendría que hacerse pasar por el servidor remoto, utilizando certificados falsos.
Sí, no sólo necesitaría un certificado firmado por una autoridad aceptable para el cliente, sino que también necesitaría envenenar el DNS del cliente o redirigir el flujo de paquetes IP.
Sospecho que puede ser técnicamente posible implementar un proxy HTTPS que generaría un certificado sobre la marcha firmado por una CA local y representaría las solicitudes usando eso, pero es muy difícil.
Si le preocupa la filtración de datos a través de HTTPS, simplemente no permita que sus usuarios accedan a HTTPS.
No resuelve el problema de que escriban cosas en trozos de papel.
La única solución práctica es mantener un buen registro de auditoría, preferiblemente con tarros de miel.
Respuesta3
El problema de https se resuelve con el tipo de solución MiM. Por lo general, significa que un proxy está capturando sesiones https salientes y las entrega al usuario firmadas por su propio certificado SSL, mientras conduce las comunicaciones https hacia el mundo exterior por sí solo.
La solución gratuita myDLP puede hacer eso usando su propia configuración de squid, y las soluciones más complejas, como Websense y Symantec, iirc hacen lo mismo, aunque un poco más potente (equilibrio de carga entre dichos servidores proxy, gestión detallada de certificados, etc.). )