[15/02/2021] La pandemia ha generado a muchas empresas la necesidad de contar con más aplicaciones basadas en la nube, puesto que muchos de nosotros ahora trabajamos de forma remota. En una encuesta de Menlo Security a 200 gerentes de TI, el 40% de los encuestados afirmó que, debido a esta tendencia, enfrentan crecientes amenazas de ataques a las aplicaciones en la nube y a la Internet de las cosas (IoT, por sus siglas en inglés).
Existen buenas y malas formas de realizar esta migración a la nube. Muchas de las trampas no son exactamente nuevas. En una reunión de Gartner 2019, por ejemplo, dos gerentes de TI declararon que sus implementaciones de Office 365 estaban estancadas debido a la necesidad para actualizar equipos previos. Ahora, la forma en que usamos -y compartimos- las computadoras de nuestro hogar han cambiado. Nuestras PC ya no son personales. Esa misma computadora puede soportar la escuela virtual de su hijo y las aplicaciones de su cónyuge también. Una encuesta de CyberArk descubrió que más de la mitad de los encuestados guarda sus contraseñas en los navegadores de sus PC corporativas. Sin duda, eso no es un buen augurio para ninguna política de seguridad.
Estos son los siete errores principales que afectan negativamente la seguridad y algunos consejos sobre cómo evitarlos.
1. Uso de VPN para acceso remoto
Con todos los trabajadores remotos, una VPN podría no ser la mejor respuesta para el acceso remoto. Mire lo que sucedió en diciembre del 2020 con el hack de FireEye. Aparentemente, una cuenta VPN comprometida fue el punto de entrada del hacker para robar sus herramientas. En el pasado, las VPN eran la forma preferida de proteger a los trabajadores remotos. Es mucho mejor reemplazar las VPN con redes de confianza cero, donde la identidad es el plano de control y proporciona el contexto de acceso. Además, debe asegurarse de tener políticas de seguridad de la información, basadas en el hogar, que se hayan redactado desde que comenzó la pandemia y que tengan en cuenta estas situaciones (como la PC doméstica multiusuario).
2. Configurar una inadecuada cartera de servicios de nube
Con esto me refiero a que se tiene que considerar varios factores. ¿Necesita nubes privadas para mantener los datos críticos de su empresa separados del resto del universo? ¿Tiene disponibles las versiones adecuadas del sistema para ejecutar aplicaciones específicas que dependen de ciertas configuraciones de Windows y Linux? ¿Tiene los tipos adecuados de conectores y protecciones de autenticación para poder mantenerse en ejecución con sus aplicaciones y equipos on premises que no va a trasladar? Si tiene una aplicación previa de mainframe, probablemente desee ejecutarla primero en una nube privada, y luego tratar de encontrar el ambiente adecuado que se acerque más a esta configuración de mainframe existente.
3. Su posición de seguridad no es la apropiada para la nube
Los errores comunes de seguridad en la nube incluyen contenedores de almacenamiento inseguros, derechos de acceso y parámetros de autenticación mal configurados, además de muchos puertos abiertos. Desea mantener una posición de seguridad constante, ya sea que se encuentre on premises o se conecte desde Timbuktú. Asimismo, antes de migrar una sola aplicación a la nube, deseará integrar la seguridad desde el principio. Johnson & Johnson hizo esto hace varios años cuando migraron la mayoría de sus cargas de trabajo a la nube y centralizó su modelo de seguridad. Existe ayuda disponible: Netflix acaba de lanzar una herramienta de código abierto que se llama ConsoleMe que puede administrar varias cuentas de Amazon Web Services (AWS) en una sola sesión de navegador.
4. No probar los planes de recuperación ante desastres
¿Cuándo fue la última vez que probó su plan de recuperación ante desastres (DR, por sus siglas en inglés)? Probablemente hace demasiado tiempo, especialmente si ya ha estado ocupado manteniéndose al día con los desafíos diarios de brindarle soporte a una fuerza laboral que se encuentra en el hogar. El hecho de que sus aplicaciones estén en la nube no significa que no dependan de servidores web y de bases de datos particulares y otros elementos de la infraestructura. Parte de cualquier buen plan de recuperación ante desastres es documentar estas dependencias y tener un manual que describa los flujos de trabajo más críticos.
Otra gran parte de cualquier plan de recuperación ante desastres es realizar pruebas continuas para detectar fallas parciales en la nube. Lo más probable es que tenga algunos cortes de energía. Incluso las nubes de Amazon, Google y Microsoft las experimentan de vez en cuando. Netflix fue uno de los primeros lugares en popularizar la ingeniería del caos general hace varios años con una herramienta llamada Chaos Monkey. Se diseñó para probar la infraestructura de AWS de la empresa mediante el apagado constante -y aleatorio- de varios servidores de producción.
Utilice estas lecciones y herramientas para desarrollar sus propias pruebas de fallas introducidas por el caos, particularmente con pruebas relacionadas con la seguridad que revelan las debilidades en su configuración de nube. El elemento clave es hacer esto de forma automática y continua para revelar cuellos de botella y fallas de infraestructura. Además de utilizar las herramientas de código abierto de Netflix, existen productos comerciales como Security Validation de Verodin/Mandiant, la simulación de ataque y robo de SafeBreach, herramientas de simulación de Cymulate y plataforma de optimización de seguridad de AttackIQ.
5. No optimizar la autenticación para una cartera principalmente de nube
Es posible que tenga una herramienta de administración de identidad y acceso, SIEM, CASB o de inicio de sesión único que compró en la era on premises, y ahora no es la mejor opción para sus necesidades de autenticación para un mundo donde predominan la nube y el acceso remoto. Asegúrese de examinar más de cerca estas herramientas para asegurarse de que puedan cubrir el tipo de ambiente de nube y toda su cartera de aplicaciones que protegerán sus sistemas en consecuencia. Por ejemplo, si bien los CASB son excelentes para administrar el acceso a aplicaciones en la nube, es posible que necesite uno que pueda funcionar con su aplicación personalizada interna particular, trabajar con autenticación basada en riesgos o protegerlo contra amenazas más sofisticadas y combinadas.
6. Un Active Directory desactualizado
"La identidad es ahora el nuevo perímetro y los datos fluyen por todas partes”, afirmaron David Mahdi y Steve Riley de Gartner en una presentación. "Debe brindar a las personas adecuadas, el acceso adecuado, a los recursos adecuados, en el momento adecuado, y por la razón adecuada”. Sin duda, estas son varias cosas que debe hacer bien. Esto significa que su Active Directory (AD) puede no reflejar la realidad, tanto de una lista de usuarios actuales y autorizados, como de aplicaciones y servidores actuales y autorizados. Es hora de sacar sus tijeras de podar. La migración a la nube será más sencilla si está trasladando la información más precisa.
7. No buscar ayuda
Muchos proveedores de servicios de seguridad administrados (MSSP, por sus siglas en inglés) se especializan en este tipo de migraciones, y no debería tener vergüenza de pedirles ayuda. Es posible que esté demasiado ocupado para prestar toda su atención a la migración y omitir algunos aspectos importantes sin querer. O en la prisa por mover todo a la nube, ha dejado abiertas algunas puertas traseras o ha introducido vulnerabilidades.
Basado en el artículo de David Strom (CSO) y editado por CIO Perú