Monitoreo y filtrado de datos salientes arbitrarios

Primero debe decidir cómo identificará estos datos; probablemente este sea el problema más importante y no es necesariamente técnico.

• ¿Tiene el objetivo de etiquetar todos los documentos y archivos con una calificación? Esto funciona para organizaciones que etiquetan datos individuales, ya que la puerta de enlace solo busca la etiqueta y actúa en consecuencia.

• ¿Establece una lista negra de datos para bloquear? Por ejemplo, se pueden bloquear secuencias de 16 dígitos, ya que pueden ser números de tarjetas de crédito. Obtendrá falsos positivos, pero puede funcionar en algunos entornos.

Si tiene eso ordenado, el aspecto de la puerta de enlace es relativamente simple: obligue a todos los dispositivos a conectarse a través de un proxy que actúa como un punto final SSL. Como dijiste, esto es efectivamente un MITM. Muchos proxies, incluido el calamar, le permitirán prevenir o permitir el tráfico en función de varios criterios, pero en el espacio de FOSS es posible que su nivel de complejidad sea limitado. Sin embargo, esas dos opciones anteriores deberían funcionar.

Puede encontrar que intentar realizar un análisis profundo de los flujos de paquetes para hacer esto en tiempo real puede estar más allá del alcance de FOSS (Eche un vistazo a los cortafuegos de próxima generación como Palo Alto para algunas opciones aquí)

Parece que está buscando soluciones de prevención de pérdida de datos (DLP). Aunque hay muchas herramientas comerciales, recuerdo que Google, Snort y algunas otras organizaciones ofrecen capacidades de FOSS DLP.

Los proveedores comerciales de DLP como Symantec (Vontu) y Websense ofrecen soluciones completas. La última vez que lo comprobé, las soluciones FOSS DLP aún carecían de características / funcionalidad en comparación con las soluciones comerciales DLP.

HTH

No tengo conocimiento de ninguna solución FOSS que proporcione todas las funciones que está buscando. Incluso las soluciones comerciales de DLP no pueden echar un vistazo a las sesiones ssh (https es mucho más fácil, ya que solo se puede emplear una arquitectura proxy l7). El desafío es construir reglas significativas. Los dispositivos de red basados en firmas funcionan en l3 / l4 y no reconstruyen paquetes en conversaciones. Incluso entonces, los detectores de datos en movimiento solo de red se limitan a ver el tráfico de texto plano (con la excepción de un proxy l7 en línea para http / https / ftp) sin implementar algún tipo de solución de punto final también.

¿Puede explicar con un poco más de detalles qué tipo de datos está tratando de proteger? Es posible que un DLP basado en la red de FOSS basado en datos en movimiento no esté disponible, pero es posible que pueda aplicar protección a los datos en sí. De lo contrario, su desafío se convertirá en proteger los activos de información sin un presupuesto adecuado, que es casi decir que, en primer lugar, no vale la pena protegerlos.

SSL Bump , para integrarse en un proxy de Squid, puede descifrar sesiones SSL salientes, sujeto a algunas condiciones :

• Se debe agregar un certificado de CA específico al "almacén de confianza" de los clientes. SSL Bump funciona creando un certificado falso para el servidor de destino y realizando un ataque Man-in-the-middle .
• Los navegadores cliente deben estar convencidos de usar su proxy. Esto se puede aplicar a nivel de red, dependiendo del nivel de control que tenga sobre los firewalls y enrutadores.
• Esto rompe la autenticación del cliente basada en certificados. Los certificados de clientes son raros en la Web, pero algunos bancos emiten certificados para sus clientes.
• Los usuarios podrán verlo. La mayoría de los usuarios humanos tienden a reaccionar mal ante el descubrimiento de ese filtrado de sus conexiones supuestamente "seguras". Será mejor que les adviertas de forma proactiva. La transparencia es un gran activo para las relaciones entre empleadores y empleados.