Conversando con...

Hernán Conosciuto, arquitecto especialista en seguridad de Red Hat

La automatización para combatir el ransomware

[15/09/2021] ¿Qué hacer si una empresa es víctima del ransomware? Las clásicas alternativas no son muchas: pactar con los ciberdelincuentes, o no hacerlo y esperar que haya un backup lo suficientemente reciente como para no sentir el golpe. Red Hat propone otra cosa: automatizar la respuesta.

Si los sistemas de seguridad pueden detectar los inicios de un ransomware, se puede activar una serie de respuestas que permitan dejar en mejor posición a la firma ante un ataque; e incluso remediar los daños de manera rápida utilizando la misma lógica de automatización. Conversamos con Hernán Conosciuto, arquitecto especialista en seguridad de Red Hat, sobre este enfoque para enfrentar a los cibercriminales.

Se supone que cuando una ha sufrido un ataque ya no hay mucho que hacer sino pactar con el atacante, pero ustedes proponen la automatización, incluso luego del ataque.

Nosotros planteamos dos aristas grandes de la automatización en cuanto a la seguridad. Una es el tema de la reacción ante un posible ataque. Lo que nosotros vemos y experimentamos es comparable con un incendio: si aíslo rápidamente el foco del incendio, cuanto más rápido lo haga menos daño tendré dentro. Lo que sucede hoy en día es que las compañías, como los bancos, tienen muchos buenos sistemas de detección de ataque, análisis de comportamiento y otros, que generan una alerta. El tema es que ante la alerta en el 99% de los casos la acción es humana, es un equipo que recibe la alerta y actúa en consecuencia.

Ese tiempo que se demora la persona es el tiempo que usa un ransomware para encriptar y pedir rescate por los servidores. No es que la persona sea lenta, es que el ransomware es muy rápido. Hubo una evolución tremenda en el malware porque hay detrás un negocio muy grande.

Entonces, lo que nosotros planteamos es que si tienes algo que genere un evento, planteamos automatizar la acción; es decir, que el evento dispare la acción. A lo sumo se tendrá un falso positivo y tendremos que pedir perdón, pero lo importante es que no tengamos que pagar rescate.

El segundo punto es ¿qué pasa si ya tuve un daño? Yo actué rápido, pero en ese tiempo perdí dos o tres servidores. Ahí tiene que ver el tema del disaster recovery, la recuperación. Ante ese problema, tengo que recuperar rápido; es decir, tengo que instalar una máquina virtual nueva, instalar un software en el caso de que sea una base de datos, configurar la base de datos tal cual la tenía, 'restorear' el último backup que tengo de esa base de datos, y tratar de aplicar los logs que fueron dándose hasta antes del ataque para tratar de no perder ninguna transacción.

Todos estos pasos que planteo los tengo que hacer a mano. La operación tiene que seguir. En ese estrés ocasionado por hacer todos estos procesos, al que se le suma el estrés de haber pasado por un ataque a la seguridad, las llamadas del CIO que quiere saber por qué paso esto, las llamadas del director de la empresa, y el estrés por tener que hacer todo esto desde casa donde los niños pueden estar corriendo, estoy a muy poco de romper otro equipo. Esto es real, he visto 'restorear' una base de datos con un archivo que estaba corrupto, y terminó rompiéndose otra base de datos porque parte de los archivos apuntaban a otra base de datos y nunca se había validado el 'restore' de esa base.

Lo que nosotros planteamos es tener todo ese proceso automatizado y probado. Que la persona sea el disparador y a lo sumo va a tener que elegir qué backup usar, cuántos logs va a aplicar, hasta qué hora y ver cómo corre este proceso, pero no tendrá que poner los dedos en el teclado.

¿En cuánto tiempo un ataque puede apropiarse de todas las máquinas? ¿Debe haber entonces primero una herramienta que detecte el ransomware de manera anticipada?

Hay una revista de ciberseguridad del año 2019 que señalaba que el promedio que le lleva a un ransomware es de tres segundos. Cuando vi eso me llamó la atención e investigué. Y esto tiene que ver con la evolución del proceso, en un momento se dieron cuenta que si tengo un archivo de 100 gigas no tengo que encriptar los 100 gigas, solo encripto los primeros bytes y automáticamente las personas no van a poder acceder a ese archivo. Eso hace que sea tan veloz el ransomware.

Un cliente nos dijo que no se dieron cuenta de que tenían un ransomware hasta que quisieron loguearse. Generalmente es un proceso que trata de acceder a un servidor y se queda hibernando hasta el momento en el que pueda crecer en cuanto a privilegios, o que pueda llegar a hacer un daño mayor.

El año pasado, en plena pandemia, los objetivos más buscados por los cibercriminales fueron el sector público y los bancos. Los bancos es lógico; pero ¿por qué sector público? Por que a cuanto más usuarios afecto, más alto es el precio que puedo pedir por el rescate. Si afecto a un banco, afecto a los usuarios de ese banco; si afecto al Ministerio de Salud, afecto a todos los ciudadanos de ese país.

La prevención es importante, pero no es todo. Todos están previniendo, todos vemos cómo nos podemos cuidar hacia afuera, eso cambió. Primero, no puedo pensar que voy a tener una prevención que funcione al 100%, lo importante es tener una respuesta del vendor, que en 24 horas pueda tener un fix y aplicarlo. Pero también es importante que si no tiene el fix actúe en consecuencia. Entonces, la prevención es buena, pero la reacción también es importante.

Y, segundo, hay mucho 'fuego amigo'. Uno piensa ¿cómo prevengo los ataques? Y armo una gran muralla para que los de afuera no me ataquen, pero ¿qué pasa con los que tengo adentro? ¿Qué pasa con los empleados que están en mi red y usan celulares y usan iOS y Android, tabletas? Uno de esos equipos puede tener un malware dentro y puede estar dentro de mi red.

Entonces, es tan importante prevenir, como tener un procedimiento para actuar y tener un procedimiento de recuperación.

En el caso nuestro, el Red Hat Ansible Automation Platform me permite verificar si, por ejemplo, he instalado un servicio de FTP o un compilador, encontrar qué esta mal y bajo el servicio de FTP, desinstalo el compilador, cierro el puerto de FTP, desinstalo el servidor de FTP, y volver a poner el equipo en el estado que yo quería.

¿Las automatizaciones son estándares, hay mejores prácticas, o cada empresa puede reaccionar a su manera?

Creo que si bien hay buenas prácticas -y nuestra plataforma de automatización permite hablar con servidores, servidores bare metal, virtualizados y dispositivos de red-, cada empresa debe tener una customización. Hay empresas que si tienen un servidor que está actuando mal lo van a apagar, pero no todas pueden actuar de esa manera. He hablado con empresas de telecomunicaciones y me dicen que no pueden apagar un servidor, entonces cada empresa tiene que armar su procedimiento, porque cada empresa sabe lo que debe hacer: apagar la máquina, aislarla del firewall o simplemente cortar la relación de esa máquina con mi backend, por ejemplo. O revisar cada paquete que sale de esa máquina, pero eso es muy costoso y por eso no lo puedo tener habilitado para todas las máquinas de la empresa.

¿Qué tan receptivas son las organizaciones ahora?

En general, la gente está bastante interesada en el tema. Cuando hablo de almacenamiento o nube a la gente le interesa, cuando hablo de seguridad les interesa a todos. Quien no ha sufrido con la seguridad de alguna forma, sabe que va a tener que pasar por ese sabor amargo. Así que en ese sentido son receptivas; hay una palabra muy usada que es 'cambio cultural' que afecta a la ciberseguridad.

Cuando hablo de ciberseguridad comienzo hablando de los cambios culturales. Hace años el responsable de la seguridad era TI, los demás eran empleados de la empresa que no tenían responsabilidad. Eso cambió, mucho. Hoy los responsables somos todos. Cuando Red Hat me dio la notebook para trabajar me hizo firmar un acuerdo donde yo me hago responsable de instalarle todas las herramientas que me da Red Hat, desde encriptar el disco hasta el antivirus, y si algo falta puede haber hasta una desvinculación por no cumplir ese acuerdo, porque no estoy cuidando la información de la empresa.

Eso fue cambiando, TI pasó a ser el que controla y rige las normas, pero todos tenemos que acatarlo. Ya se está empezando a sentir ese cambio, lo mismo que la educación de los usuarios. Antes el usuario era el 'enemigo' -dicho de una forma muy fea- en TI porque tocaba algo y había problemas, pero la verdad es que tiene que ser mi aliado, además de compañero de trabajo. Hay que educarlo.

Llegamos a ustedes gracias a:


BrandPosts Qué es BrandPost

Más »
×
Los artículos publicados en esta sección -BrandPosts- son escritos y editados por los proveedores o miembros de la comunidad TI. BrandPosts crea una oportunidad para que un patrocinador proporcione información y comentarios desde su punto de vista, directamente a la audiencia de CTO Perú. El equipo editorial de CTO Perú no participa en la redacción o edición de estos BrandPosts.

Casos de éxito

Más »