Como parte de la estrategia de defensa en profundidad, muchas organizaciones están expandiendo su uso de encriptación. Mientras que la encriptación puede proveer protección de accesos no autorizados y reducir la probabilidad de robo de información, es muy difícil implementar sistemas y procesos que puedan proveer una seguridad razonable de confidencialidad en implementaciones en el mundo real. En años recientes, muchos productos de software han empezado a ofrecer capacidades de encriptación incorporado que son más amigables y más manejables. Cuando se trata de herramientas de comunicación encriptada especialmente diseñados o estándar basado en la encriptación de sistema a sistema, el nivel de madurez es usualmente alto. Pero muchas organizaciones no están preparadas para los riesgos o escollos en la administración de la encriptación por usuarios finales (usuario a usuario).
El llamado para Encriptación
Espionaje industrial, piratas de la nación-estado y crimen organizado son preocupaciones aun para las organizaciones más pequeñas. Esto no ha disminuido la tasa de captura de datos y el compartir con los socios, reguladores y clientes. Las organizaciones ahora comparten regularmente grandes cantidades de información propietaria y de empleados, o clientes, información personal identificable. Un aumento en la concientización por la junta de directores y una mayor presión regulatoria están dando lugar a un mayor enfoque y financiación para la protección de los datos.1
La mayoría de las organización hoy se sienten confortables en desplegar encriptación en tránsito. Los equipos de seguridad pueden vender fácilmente la necesidad de la capa de transporte de seguridad (Transport Layer Security) (TLS) – aplicaciones Web seguras o empujar para el uso de protocolos seguros, como ser Protocolo de Transferencia de Archivos Seguro (Secure File Transfer Protocol) (SFTP) y Secure Shell (SSH). Desafortunadamente, existen muchos flujos de transferencia de datos fuera del control de TI que deben cumplir con requerimientos impuestos externamente. Como resultado, datos críticos o alto riesgo aun viajan por correo y adjuntos. Más y más, usuarios también están utilizando almacenaje en la nube autorizada y no autorizada como también servicios de intercambio de archivos. Porque es imposible identificar y controlar todos estos escenarios, muchas organizaciones responden por implementar herramientas de encriptación administradas por el usuario final, esperando que los usuarios serán lo suficiente responsables para integrar la encriptación en los procesos existentes (ej. Una solicitud de TI para encriptar antes de enviar un correo). Sin embargo, este enfoque esencialmente delega la responsabilidad de seguridad a usuarios desinteresados que buscan el paso de la menor resistencia.2
Bienvenido a la Jungla
En teoría, encriptación es solo cuestión de aplicar un poco de matemática a bits de datos antes y después de enviar un archivo o mensaje. Sin embargo, hay un vasto ecosistema de tecnologías de encriptación, algoritmos, configuraciones, herramientas y formatos de archivos. Para complicar las cosas, las herramientas de encriptación de los usuarios finales son notoriamente poco amigables desde la perspectiva del usuario final.3 La administración y la transferencia de las llaves de encriptación y/o contraseñas y asegurando el almacenaje seguro son requisitos de enormes proporciones para imponerle a los usuarios finales. Incluso si las mejores herramientas menores y entrenamiento son implementadas, aún existe el tema de compatibilidad con los socios. Si un socio está en una plataforma diferente, el despliegue de esa plataforma requiere inversión adicional y esfuerzos para implementar. Dado que las organizaciones tienen múltiples socios, la sobrecarga de comprar y soportar múltiples herramientas puede escalar rápidamente.
La falta de proveer soporte a las herramientas que los usuarios internos necesitan para mantener contentos a sus socios de negocio va a resultar en que los usuarios finales busquen soluciones creativas y soluciones alternas.
Además de proveer las herramientas “correctas”, también es importante bloquear soluciones de encriptación no autorizadas. Las Listas blancas (Whitelisting) son parte de la solución, pero el usuario de hoy día es muy probable que vaya en busca de soluciones en la nube, y esto puede terminar en algún sitio web no fidedigno. Esto es problemático porque el uso de un sitio no puede ser monitoreado o controlado. Además, los servicios pueden que no estén asegurados en forma adecuada o pueden ser simplemente maliciosos. Por ejemplo, esa herramienta puede ofrecer encriptar archivos subidos, pero pueden, no intencionalmente o a propósito, retener una copia original del archivo no encriptado. Las intenciones de los usuarios en mejorar la seguridad, puede, desafortunadamente, resultar en la exposición de datos.
Aun dentro de una lista de aplicaciones aprobadas, existen muchas herramientas que pueden proveer alguna forma de encriptación como una función adicional. Por ejemplo, muchas herramientas de compresión permiten una forma ampliamente aceptada pero lamentablemente anticuada y débil encriptación de extensión.zip (véase el recuadro). El permitir o alentar a los usuarios a utilizar este tipo de herramientas es poco aconsejable. Utilizar encriptación débil o anticuada no provee un valor de seguridad real, y el utilizar estas herramientas podrían impactar negativamente la reputación de una organización porque los socios pueden percibir una falta de conocimiento o deseo de invertir en seguridad.
El caso del archivo ZIP
Un primer intento en muchas organizaciones de proveer facilidades de encriptación es de apalancar el formato .zip. Los Sistemas Operativos comunes soportan la apertura de archivos .zip protegidos con contraseñas, pero este soporte es típicamente limitado a una forma de encriptación anticuado y débil. Algunas herramientas de terceros pueden encriptar archivos .zip con una encriptación robusta, pero su compatibilidad con la parte receptora no está garantizada. Aun si ambos socios puedan usar la configuración de encriptación robusta, no hay seguridad que los usuarios escogerán los ajustes correctos o establecerán una contraseña robusta ya que la mayoría de las herramientas de compresión están enfocadas en usuarios únicos y les falta la habilidad de administrativamente forzar que configuraciones son posibles.
Incluso cuando Funciona
Mientras que una organización pueda implementar herramientas que cubran sus necesidades y son compatibles con los socios, aun no se encuentra del todo libre. La mayoría de las herramientas no son soluciones de fin a fin, lo cual aumenta las posibilidades para errores humanos en el proceso. Otras herramientas pueden que no están listas para la empresa y puede que no permitan que las empresas des-habiliten parámetros de encriptación inapropiados. Cuando una organización implementa herramientas, debe asegurarse que el equipo de seguridad podrá mantener supervisión y el control de los algoritmos, longitud de la llave y cualquier otra variable. Por ejemplo si los archivos Abiertos XML de Office (OOXML) (Formato de Microsoft Office 2007) están siendo utilizados, es posible de controlar la longitud de las contraseñas, complejidad y algoritmos centralmente a través de la Política de Grupo/Herramienta de Personalización de Office.4 Estandarizar usando OOXML puede efectuarse, pero, desafortunadamente, los valores por defecto no son seguros fuera de la caja. No hay garantía que las configuraciones de las organizaciones asociadas cumplan adecuadamente las normas de una empresa y los ambientes de sus socios de auditoria pueden no ser prácticos. Además, una empresa no puede estar segura que los filtros u otras herramientas no bloquearan los archivos en su recorrido, ya que el malware macro de Office es una amenaza muy conocida.
Encriptación no es un sustituto para el Control de AccesoEncriptación y sistemas de control de acceso ambos proveen confidencialidad. Dos diferencias clave son: el control de acceso permite cambiar el derecho de acceso en el tiempo y la autorización está separada de los datos mismos. Un archivo encriptado, en esencia incorpora la autenticación y autorización dentro de sí mismo. Sin algunos sistemas adicionales, no hay manera de revocar más tarde el acceso una vez que alguien más tiene la contraseña o la llave; no es posible recuperar un archivo digital. Además, a diferencia de los controles de acceso, no hay manera de implementar límite de tasa (ej. Denegando solicitudes por cortos periodos de tiempo) en ataques de fuerza bruta para adivinar las contraseñas. Erróneamente, algunas veces se usa encriptación en vez de control de acceso. En tales casos, la solución adecuada es probablemente alguna forma de administración de derechos digitales (DRM) o administración de derechos de la información (IRM). Con IRM, existe la posibilidad de incluir una llamada de vuelta al servidor que pueda descontinuar el acceso aun si la contraseña adecuada es provista, habilitando la administración de control de acceso central aun fuera de las fronteras de una organización. En adición, en el caso de compartir archivos en forma extra-organizacional, la encriptación por sí sola no limita el re-uso o un mayor intercambio porque el receptor puede simplemente des-encriptar y descartar el archivo encriptado o compartir la contraseña de des-encriptación. Para información altamente confidencial, cuartos de datos seguros virtuales pueden ser apropiados.5 En cualquier caso, encriptación y DRM no son reemplazo para otro uso y controles de manejo como ser acuerdos legales (ej. Acuerdos de no divulgación) o visible y filigrana digital. El proveer de un documento encriptado por si solo usualmente no suele obligar legalmente a la otra parte de forma alguna. |
Aun si los temas de implementaciones técnicas y de compatibilidad han sido abordados, es importante también considerar los procesos operacionales. Por ejemplo, en el caso de los archivos OOXML, el usuario puede guardar una copia encriptada en un directorio con el original y luego accidentalmente adjuntar la versión no encriptada (usuarios son notoriamente conocidos como malos en nombrar archivos, y tampoco la extensión del archivo ni su icono cambian cuando un archivo OOXML es encriptado). Usuarios astutos pueden también eludir la Política de Grupo enviando por correo el archivo original para ser utilizado en casa a través de una copia personal del Office sin restricciones, lo cual resulta en una transmisión no deseada externa y no encriptada.
En la mayoría de los casos, para la encriptación administrada por el usuario final, la encriptación simétrica basada en contraseñas es preferida ya que evita la complejidad de administrar llaves/ certificados. Sin embargo, el reto de comunicar en forma segura la contraseña aún se mantiene. Es posible implementar una herramienta o servicio para compartir, pero, nuevamente, existe el tema de soporte y compatibilidad. Como resultado, se debe confiar en los usuarios para comunicar de forma segura la contraseña compartida a través de otro canal (ej. Llamar para proveer las contraseñas de adjuntos de los correos). Sin embargo esto se torna difícil de administrar (¿que contraseña va con que correo?), y una contraseña compleja, larga y aleatoria será difícil de dictar verbalmente de un usuario a otro.
Un objetivo clave de encriptación es de proteger el archivo aun cuando un acceso directo es posible o si la transferencia es interceptada, así que los usuarios deben ser educados en el riesgo de la segregación insuficiente del contenido y contraseña encriptada. Nunca es aceptable simplemente enviar la contraseña en otro correo. También el Servicio de Mensajes Cortos (SMS) no debe ser considerado como un canal separado ya que muchos usuarios tienen correo en sus teléfonos, y malware telefónico fácilmente puede acceder al correo y mensajes SMS. El malware puede detectar adjuntos encriptados y luego escanear todos los correos para crear un diccionario basado en palabras únicas o combinación de frases para probar como posibles contraseñas. El ataque puede ser optimizado buscando palabras que no existen en el diccionario o frases claves (ej. “La contraseña es”).
Consecuencias No Deseadas
Existen desventajas potenciales a considerar cuando se está implementando encriptación administrada por el usuario final. Inspección del contenido es requerido para detectar y prevenir ataques (ej. Antivirus, filtros spam) y prevenir robo de datos (prevención de pérdida de datos [DLP]). Generalmente, las herramientas no proveen una administración centralizada o monitoreo, depósito de llaves/contraseñas, o cualquier tipo de conexión con las herramientas de análisis de seguridad. Si un sistema DLP no tiene la manera de aprender la contraseña/llave, no puede des-encriptar y leer el archivo. La herramienta DLP por defecto bloqueara un archivo encriptado de salida.
En el lado de recepción, los filtros de correo no pueden inspeccionar un adjunto para virus macro si no logran des-encriptar el archivo. Como resultado, usuarios finales ahora tienen que tomar decisiones más difíciles de las cuales puede que no entiendan todas sus consecuencias.
Otra consecuencia inesperada de empoderar a los usuarios de utilizar encriptación es el riesgo de auto infligir negación de servicio (DoS). DoS es discutido tradicionalmente en el contexto de servidores, pero un archivo que no puede ser des—encriptado es otra forma de ataque de negación—considere a los criminales utilizando CryptoLocker y sus variantes.6 Un usuario muy celoso de la seguridad puede encriptar todos sus archivos. Eso va resultar en un montón de contraseñas para recordar. El usuario puede utilizar un administrador de contraseñas, pero esas herramientas también tienden a no contar con características de depósito, Si ese usuario deja la compañía, nadie más tendrá acceso a esos documentos encriptados.
También hay consecuencias que resultan al permitir encriptación administrada por usuarios finales que puede que no sea evidente en forma inmediata. Por ejemplo, ¿cómo funciona el uso del factor de encriptación de correo electrónico con los requisitos de retención legal u otros procesos de archivo similares? ¿Cómo impactara a la gestión de contenido y a la habilidad de efectuar búsquedas en datos? Encriptación también impacta la compresión de archivos que puede ser un problema para los adjuntos, considerando las restricciones de tamaño. Consideraciones especiales pueden necesitarse para los respaldos y procedimientos de replicación cuando se está utilizando un montón de encriptación al nivel de archivos.
Las Ventajas de Centralización
Tradicionalmente, los departamentos de TI han tratado de encontrar características de encriptación en herramientas ya implementadas, o han implementado una o dos herramientas de encriptación de usuario final específica común entre socios claves. En años reciente, sin embargo, soluciones de encriptación Gateway/proxy se han convertido en una opción viable.
Similar al cambio de los clientes de escritorio para aplicaciones Web, la encriptación Gateway centraliza el proceso de encriptación y permite el monitoreo y el control mejorado por TI. Muy parecido como otro proxy, el tráfico viaja en línea y la encriptación/des-encriptación puede ser aplicada en forma transparente y automatizada.
Con una implementación centralizada, se vuelve más fácil establecer conexiones con otros socios que implementan soluciones centralizadas, aun de diferentes proveedores. El intercambio de llaves y certificados se puede dejar a los especialistas y las transmisiones pueden usar protocolos basados en estándar. La toma de decisiones en protocolos ya no se deja a los usuarios, permitiendo a los departamentos de TI trabajar juntos en configuraciones aceptables o para emplear negociaciones máquina a máquina para asegurar que solo sean permitidas configuraciones de encriptación compatibles. Aun si el receptor no esté en la misma plataforma, puede ser posible crear inteligentemente al usuario/organización, apalancar una plataforma IRM o utilizar un servicio de alojamiento de archivos seguro (por lo menos control de acceso).
La carga de trabajo del usuario puede reducirse a solo hacer clic en un botón o insertando una palabra clave (ej. “Encriptar”) en la línea de asunto de un correo. Organizaciones podrían implementar también un portal Web o una herramienta de dragar y soltar para preparar el archivo y depositar la llave/contraseña. DLP o filtros de correo pueden estar disponibles para detectar de forma inteligente cuando la encriptación debiese proveerse en caso que el usuario se olvide o puede redirigir a los usuarios cuando se bloquee la transmisión.7 Para el receptor, el archivo puede ser des-encriptado en una manera automática descentralizada, permitiendo de este modo la inspección y la zona de pruebas que ocurra entre la desencriptación y acceso por el usuario final.
Limite a la Encriptación Autorizada
Una vez que una solución centralizada o administrada por el usuario ha sido implementada, es necesario tomar ciertos pasos para bloquear la encriptación no autorizada y archivo encriptado ingresando por canales no autorizados. Esto ayuda a bloquear algoritmos de encriptación anticuados y prevenir intrusos internos maliciosos y hackers de utilizar encriptación para ex filtrar datos. Esto es similar al tipo de inspección y bloqueo ya común para las transacciones seguras de la Web.8 Las reglas de Sistemas DLP deben ser configuradas para bloquear cualquier encriptación que no se pueda inspeccionar y/o está viajando a través de un servicio no aprobado, puerto o destino.
Además, se recomienda monitorear el software y procesos en sistemas de usuarios finales para asegurar que ningún software de encriptación no autorizado es instalado o está siendo utilizado. Si tal software es encontrado, una investigación puede determinar si hay una necesidad de negocio legitima y ver si es posible convertir ese flujo de trabajo a uno diferente, una herramienta de encriptación autorizada. Por el creciente uso de la nube, el tráfico de la Web debiese ser revisado para bloquear sitios web no autorizados y servicios que los usuarios han utilizado, o intente de utilizar, para encriptar o des-encriptar datos.
¿Quién es el Dueño de los datos?
Encriptación se piensa típicamente como una comunicación segura entre dos o más individuos, y solo esas personas involucradas con la transferencia. Sin embargo, en un escenario de negocios, es más probable que dos organizaciones, en vez de los usuarios individuales, debiesen ser considerado los dueños. Muchos protocolos de encriptación de mensajes y herramientas independientes de la encriptación de archivos son fundamentalmente diseñadas para escenarios de uso personal. Sin embargo, en un ambiente corporativo es usualmente necesario tener alguna forma de depósito de llaves o la capacidad de ver la versión no encriptada de los datos por otros fuera de la transacción, tales como equipos legales o de seguridad (o por lo menos sus herramientas automatizadas).
Cuando uno está evaluando software de encriptación y sistemas, es importante considerar como las herramientas impactaran los accesos de datos legítimos de la organización. Si las herramientas están listas para la empresa, estas se integraran con el DLP e IDS de algún modo, tal como la comunicación de texto plano, transfiriendo las llaves o coordinando con agentes de software local antes de encriptar. Tales sistemas deben también administrar de forma segura todas las llaves/contraseñas para evitar el mal uso y la orientación de los hackers, y también debe incluir los flujos de trabajo aprobados y el registro según lo apropiado.
Comunicaciones personales pueden y deben aun confiar en tecnologías robustas de encriptación de puerta trasera libre para prevenir espionaje. En empresas, la propiedad fundamental significa que los usuarios deben entender y aceptar que la comunicación está siendo asegurada entre empresas, no personas.
Asegurarse del Entendimiento y Concientización del Usuario
Aun con una solución transparente, educación apropiada en responsabilidades de encriptación y capacidades es crucial. Los usuarios deben entender que encriptación es más que la protección de contraseñas, y no toda encriptación es igual. DLP e inteligencia artificial (AI) nunca podrá capturar todos los casos donde la encriptación es requerida así que es mejor entrenar a los usuarios para que inicien la encriptación en forma manual; esto le proveerá a los usuarios con paz mental.
También, reforzamiento y re-educación debe ser entregado en forma periódica. Las políticas también son importantes para asegurar claridad. La empresa debe definir claramente las herramientas de configuración aprobadas, procedimientos y consecuencias para que no exista ambigüedad entre usuarios. Por ejemplo, los usuarios debiesen ser prohibidos de mandar datos encriptados a la casa (ej. Ninguna copia personal de respaldo encriptados). La política de seguridad debe aclarar que la administración se reserve el derecho, donde es permitido por ley, para inspeccionar y desencriptar toda las comunicaciones y archivos para seguridad, legal y otras razones aplicables.
Conclusión
Las organizaciones deben estar conscientes de las retos y riesgos asociados de poner la encriptación en las manos de los usuarios. Más allá de la búsqueda y la configuración de la tecnología correcta, las empresas deben asegurar que los procesos estén bien definidos y hay usuarios suficientemente entrenados. Una solución centralizada puede reducir costos y esfuerzo de apoyo, al tiempo que agiliza los procesos y permite una mejor integración con la tecnología DLP. En cualquier caso, la encriptación debe ser controlada y limitada o va crear un punto ciego de seguridad.
Notas
1 NYSE Governance Services and Veracode, A 2015 Survey: Cybersecurity In The Boardroom, 2015, https://www.nyse.com/publicdocs/VERACODE_Survey_Report.pdf
2 Besnard, D.; B. Arief; “Computer Security Impaired by Legitimate Users,” Computers & Security, vol. 23, iss. 3, 2004, p. 253-264
3 Whitten, A.; J. D. Tygar; “Why Johnny Can’t Encrypt: A Usability Evaluation of PGP 5.0,” USENIX Security Symposium, 1999, p. 169-184, https://www.usenix.org/legacy/events/sec99/full_papers/whitten/whitten_html/
4 Microsoft Technet, “Group Policy and Office Customization Tool Settings in Office 2010 for OpenDocument and Office Open XML Formats,” 2016, https://technet.microsoft.com/pt-br/library/dd723552(v=office.14).aspx
5 Pang, A.; D. Stanton; T. Nagle; “Managing Cyber-Security Risks in M&A,” Financier Worldwide, July 2014, www.financierworldwide.com/managing-cyber-security-risks-in-ma
6 US Federal Bureau of Investigation, “Criminals Continue to Defraud and Extort Funds From Victims Using Cryptowall Ransomware Schemes,” Internet Crime Complaint Center (IC3), 23 June 2015, www.ic3.gov/media/2015/150623.aspx
7 Microsoft, “Conditions and Exceptions for Transport Rules,” Microsoft Developer Network, 2010, https://msdn.microsoft.com/en-us/library/ff628740(v=exchsrvcs.149).aspx#Attachments
8 Lyngaas, S.; “Decrypting Outbound Data: A Key to Security,” FCW, 11 August 2015, https://fcw.com/articles/2015/08/11/ssl-encryption.aspx
Eric H. Goldman, CISA, Security+
Es un profesional de seguridad de la información con experiencia en servicios financieros y de manufactura. El se enfoca en factores humanos y la interacción hombre-máquina en el ámbito de la seguridad de la información. El puede ser contactado en: Eric.Goldman@owasp.org