Llegamos a ustedes gracias a:



Reportajes y análisis

Controles de seguridad que debería estar usando

Si almacena sus datos en la nube

[26/07/2017] Otro día, otra violación de datos debido a sistemas mal configurados basados en la nube. El último incidente, en el que hasta seis millones de detalles de clientes de Verizon en los Estados Unidos fueron expuestos, es otro recordatorio de que el proveedor y la organización comparten la responsabilidad de la seguridad en la nube.

Existe la idea errónea de que el proveedor de servicios en la nube se encarga de proteger el entorno de la nube. Esa es solo la mitad de la historia. Los proveedores de seguridad en la nube, como Amazon, Microsoft y Google, se ocupan de la seguridad de sus centros de datos físicos y del hardware del servidor en las que funcionan las máquinas virtuales; pero el cliente es responsable de proteger las máquinas virtuales y las aplicaciones. Los proveedores de la nube ofrecen una variedad de servicios y herramientas de seguridad para asegurar las cargas de trabajo de los clientes, pero el administrador debe implementar las defensas necesarias. No importa qué tipo de defensas de seguridad tiene el proveedor de la nube si es que los clientes no protegen sus propias redes, sus usuarios y aplicaciones.

Un proveedor de servicios de terceros manejó las operaciones de back-office y del centro de atención de Verizon, y almacenó todos los datos de llamadas, que incluían nombres, direcciones, números de teléfono y códigos PIN de las cuentas de todos los clientes de Verizon que llamaron al centro de atención durante los últimos seis meses; todo en un almacén de datos Simple Storage Service (S3) de Amazon Web Service (AWS). La recopilación de datos tenía como objeto ayudar a mejorar la experiencia del servicio al cliente, pero debido a que el S3 estaba configurado incorrectamente en cuanto al permiso de acceso externo, cualquier persona con suficiente paciencia para resolver la dirección web, habría podido descargar la información. Los estafadores que aprovecharon la oportunidad pudieron presentarse como cualquier cliente de Verizon en una llamada y obtener acceso a cuentas de clientes.

Este tipo de error es angustiantemente común. Una investigación reciente realizada por el equipo de Clouf Infrastructure Security de RedLock encontró que el 40% de las organizaciones han expuesto inadvertidamente al menos un servicio de la nube pública debido a una configuración incorrecta.

La mala configuración es un problema serio

Verizon es solo una de muchas organizaciones cuyos datos fueron expuestos en nubes públicas por error. Hace pocas semanas, los datos personales de más de tres millones de aficionados de lucha libre fueron expuestos en línea, porque World Wrestling Entertainment (WWE) tenía una base de datos sin cifrar en una instancia AWS S3 sin control de acceso ni protección por contraseña habilitada. En junio, el Comité Nacional Republicano confirmó información personal identificable de 198 millones de votantes registrados de Estados Unidos -que representaban aproximadamente el 60% de los votantes- que habían sido almacenados en texto sin formato en un servidor abierto de almacenamiento Amazon S3, propiedad de la firma de analítica Deep Root Analytics. El contratista de defensa Booz Allen Hamilton expuso 60 mil archivos pertenecientes al Pentágono, incluyendo archivos sensibles vinculados a un proyecto militar estadounidense y media docena de credenciales de seguridad sin cifrar, al almacenar los archivos en una instancia pública de S3.

"El problema no es que la nube sea insegura, sino que, en última instancia, los clientes son responsables de configurar de forma segura sus redes, aplicaciones y datos", señaló Varun Badhwar, CEO y cofundador del startup de seguridad en la nube, RedLock. "La infraestructura de la nube pública, como AWS, puede ser altamente segura si es configurada correctamente por las organizaciones que adopten tales servicios".

La empresa de seguridad en la nube Threat Stack, analizó 200 empresas que utilizaban AWS y encontró que el 73% tenía al menos una mala configuración de seguridad, como permitir que partes no autorizadas accedieran directamente a los datos, usar el objeto mal configurado como parte de un ataque mayor, y controlar todo el entorno registrándose en la consola AWS. Estas violaciones fueron el resultado de la negligencia básica de seguridad y las políticas de TI inexistentes, no del trabajo de adversarios maliciosos.

Independientemente de quién realice el aprovisionamiento -ya sea el administrador de TI, el desarrollador, ingeniero o equipo de seguridad- demasiadas personas no entienden completamente cómo configurar sus entornos en la nube. Las organizaciones ya no pueden tratar la nube pública como un lugar antiguo para almacenar información, sino que deben incorporar las siguientes medidas de seguridad para garantizar que sus entornos, aplicaciones y datos en la nube estén protegidos contra el acceso no autorizado.

1. Saber de qué es responsable

No todos los servicios en la nube son iguales, y el nivel de responsabilidad varía. Los proveedores de software como servicio (SaaS) se asegurarán de que sus aplicaciones estén protegidas, y de que los datos se transmitan y almacenen de forma segura; pero normalmente no ocurre con la infraestructura en la nube. Por ejemplo, la organización tiene plena responsabilidad sobre sus instancias AWS Elastic Compute Cloud (EC2), Amazon EBS y Amazon Virtual Private Cloud (VPC), incluyendo la configuración del sistema operativo, administración de aplicaciones y protección de datos.

En cambio, Amazon mantiene el sistema operativo y las aplicaciones de Simple Storage Service (S3), y la organización es responsable de administrar los datos, el control de acceso y las políticas de identidad. Amazon provee las herramientas para encriptar los datos para S3, pero depende de la organización habilitar la protección cuando entra y sale del servidor. Consulte con el proveedor para saber quién está a cargo de cada control de seguridad en la nube.

2. Controlar quién tiene acceso

CSI de RedLock encontró que el 31% de las bases de datos en la nube pública están abiertas a Internet. De hecho, el 93% de los recursos en entornos de nube públicas no restringían, en absoluto, el tráfico saliente. El 9% de las cargas de trabajo en la nube, que no era ni equilibradores de carga ni bastion hosts, aceptaban el tráfico de cualquier dirección IP en cualquier puerto, lo cual es una idea terrible. Solo los equilibradores de carga y los bastion hosts deben estar expuestos a Internet.

La violación de datos de Verizon ocurrió porque el bucket de S3 se estableció para permitir el acceso externo. Desafortunadamente, este es un error común. Threat Stack encontró que el 37% de las organizaciones en su investigación tenían buckets de S3 que otorgaban acceso a todos. Muchos administradores activan por error los permisos globales en sus servidores utilizando 0.0.0.0/0 en las subredes públicas. La conexión se deja abierta, regalando la capacidad de que todas las máquinas se conecten.

En el caso de AWS, los buckets de S3 nunca deben tener una política de acceso público.

Otro error común es dejar el SSH abierto, algo que el 73% de las organizaciones hicieron en el análisis de ThreatStack. ThreatStack también encontró que el 13% permitió las conexiones SSH directamente desde Internet, lo que significa que cualquier persona que pudiera averiguar la ubicación del servidor podía pasar por alto el firewall y acceder inmediatamente a los datos.

Los principales proveedores de la nube ofrecen herramientas de control de identidad y acceso; úselas. Sepa quién tiene acceso a qué datos y cuándo. Al crear políticas de control de acceso e identidad, conceda el conjunto mínimo de privilegios necesarios y otorgue permisos adicionales de manera temporal cuando sea necesario. Configure los grupos de seguridad para que tengan el enfoque más restringido posible, y utilice los IDs de grupos de seguridad de referencia siempre que sea posible.

Amazon VPC permite a los administradores crear una red lógicamente aislada dentro de la nube de AWS para lanzar servidores en redes virtuales. Esta es una forma de proteger el entorno de producción de los entornos de desarrollo y almacenamiento, y mantener los datos separados.

3. Proteger los datos

Otro error recurrente es dejar datos sin cifrar en la nube. CSI de RedLock encontró que el 82% de las bases de datos en la nube pública no están cifrados. La información de los votantes y los archivos sensibles del Pentágono quedaron expuestos, porque los datos no estaban encriptados y los servidores eran accesibles para partes no autorizadas. Almacenar datos sensibles en la nube sin poner en marcha controles adecuados para impedir el acceso al servidor y proteger los datos, es irresponsable y peligroso.

Siempre que sea posible, mantenga el control de las claves de cifrado. Si bien, es posible dar a los proveedores de servicios en la nube acceso a las claves, finalmente la responsabilidad de los datos recae en la organización.

"Es como confiarle las llaves de su casa a aquel que la va a remodelar", señaló Mark Hickman, COO de WinMagic. "Usted espera que todo salga bien, pero nunca puede estar 100% seguro de si están cerrando la puerta o del carácter de sus subcontratistas. Entonces, ¿por qué correr ese riesgo al darles acceso a sus llaves en primer lugar?"

Incluso cuando los proveedores de la nube ofrecen herramientas de cifrado y servicios de administración, demasiadas empresas no lo implementan. El cifrado es a prueba de fallas; incluso si falla una configuración de seguridad y los datos caen en manos de una parte no autorizada, los datos no pueden ser utilizados.

4. Asegurar las credenciales

Como demostró la violación de OneLogin, no es raro que las claves de acceso de AWS estén expuestas. Pueden ser expuestas en sus sitios web públicos, repositorios de código fuente, tableros desprotegidos de Kubernetes, y otros foros similares. Trate las llaves de acceso de AWS como las joyas de la corona más sensible, y eduque a los desarrolladores para evitar la filtración de tales claves en foros públicos.

Cree claves únicas para cada servicio externo y restrinja el acceso siguiendo el principio del privilegio mínimo. Asegúrese de que las claves no tengan permisos amplios, ya que en las manos equivocadas pueden utilizarse para acceder a los recursos y datos sensibles. Cree funciones de IAM para asignar privilegios específicos, como hacer llamadas API.

Asegúrese de rotar las claves con regularidad. RedLock encontró que el 63% de las claves de acceso no fueron rotadas en más de 90 días. Esto le da a los atacantes tiempo de interceptar las claves comprometidas e infiltrarse en entornos de la nube como usuarios privilegiados.

No utilice la cuenta de usuario root, ni siquiera para tareas administrativas. Utilice el usuario root para crear un nuevo usuario con privilegios asignados. Bloquee la cuenta de root (tal vez agregando autenticación de múltiples factores) y úsela solo para tareas de administración de cuentas y servicios muy específicas. Para todo lo demás, proporcione los permisos adecuados a los usuarios.

Compruebe las cuentas de usuario para encontrar aquellas que no están siendo utilizadas y deshabilitarlas. Si nadie está usando esas cuentas, no hay razón para darle a los atacantes rutas potenciales.

5. El alto nivel de seguridad sigue siendo importante

La defensa en profundidad es especialmente importante cuando se protegen los entornos en la nube, ya que garantiza que incluso si falla un control, existen otras funciones de seguridad que mantienen la aplicación, la red y los datos seguros.

La autenticación multifactor (MFA) proporciona una capa adicional de protección sobre el nombre de usuario y la contraseña, lo que dificulta el acceso de los atacantes. El MFA debe habilitarse para restringir el acceso a las consolas de administración, cuadros de mando y cuentas privilegiadas. Redlock descubrió que el 58% de las cuentas de root no tienen habilitada la autenticación de múltiples factores. ThreatStack encontró que el 62% de las organizaciones tenían al menos un usuario AWS sin autenticación multifactor.

6. Mejorar la visibilidad

Los principales proveedores de la nube ofrecen un cierto nivel de herramientas de registro, así que asegúrese de activar el registro y supervisión de seguridad para ver los intentos de acceso no autorizados y otros problemas. Amazon proporciona CloudTrail para auditar entornos AWS, pero demasiadas organizaciones terminan sin activar este servicio. Cuando está habilitado, CloudTrail mantiene un historial de todas las llamadas API de AWS, incluyendo la identidad del que llama de la API, la hora de la llamada, la dirección IP de origen, los parámetros de la solicitud y los elementos de respuesta devueltos por el servicio AWS. También se puede utilizar para el seguimiento de cambios, gestión de recursos, análisis de seguridad y auditorías de cumplimiento.

No permita que los errores acaben en una violación

Las violaciones de datos no siempre son causadas por atacantes externos; los datos sensibles pueden ser expuestos por errores humanos, también. Los errores -olvidarse de encender algo o pensar que algo se hizo, pero no verificarlo- pueden dejar la puerta abierta para los atacantes. Las organizaciones deben evaluar regularmente la seguridad de sus entornos en la nube, así como la de sus vendedores, proveedores y socios. Como demostró la violación de Verizon, el error del proveedor de terceros se convierte en el dolor de cabeza de la organización.

El modelo de seguridad compartida existe por una razón: independientemente de quién sea responsable de la seguridad de las cargas de trabajo de la nube, en última instancia la organización es responsable de lo que sucede con sus datos.