Halflings, dragones y ataques DDoS
Una limitación muy común en las aplicações hoy en día es el presupuesto. Los presupuestos de seguridad pueden estar creciendo, sí, pero no a un ritmo acorde con el enfoque estratégico de volverse demasiado costoso para ser hackeado.
Este enfoque es similar al Principio del Dragón-Medium que establece:
Si te encuentras en compañía de un mediano y un dragón malhumorado, recuerda que no tienes que correr más rápido que el dragón; simplemente tienes que correr más rápido que el mediano.
La idea es hacer que tu propio entorno sea demasiado costoso de atacar, forzando al dragón a volver su mirada hambrienta hacia tu competidor, el mediano.
Ahora bien, sin entrar en el debate ético que debería estar desarrollándose, la idea de hacer que un entorno sea demasiado costoso de piratear no es mala.
El problema es que muchas veces eso también significa que es demasiado caro para que tú puedas pagarlo. Esto se debe a que, en términos generales, el consejo para ejecutar una estrategia de este tipo implica comprar un montón de soluciones y lanzarlas como una especie de guante medieval, poniendo nuevas barreras y obligando a los atacantes a ejecutarlas para llegar a lo que realmente quieren: sus datos. Esto encarece el trabajo del atacante, obligándolo a gastar tiempo, energía y, en última instancia, dinero, mientras intenta distribuir sus ataques para evitar ser detectado. Esto es costoso no sólo para el atacante, sino también para la empresa. No sólo en términos de soluciones (capex), sino también a nivel operativo (opex), ya que cada solución debe ser gestionada, actualizada, monitoreada y, en última instancia, escalada.
También está al revés. Lo que quieren los atacantes son tus datos, y sin embargo, tendemos a construir nuestras defensas y protecciones comenzando en el punto más alejado de los datos, en el perímetro de la red.
Entonces, ¿cómo hacer que a ellos les resulte demasiado costoso obtener lo que quieren, sin que a usted le resulte demasiado costoso implementarlo?
No existe una solución milagrosa para esto, pero hay algunas formas de mantener bajos los costos y al mismo tiempo aumentar los costos de ataque.
1.Plataformas de apalancamiento
Las plataformas se basan en la idea de compartir un entorno común. Reducen costos de la misma manera que la virtualización y la contenerización aumentan la eficiencia de los recursos computacionales. Un ADC, por ejemplo, se puede ampliar con módulos para soportar una amplia variedad de funciones de entrega, incluida la seguridad. Muchas organizaciones ya utilizan un ADC para garantizar la disponibilidad con equilibrio de carga que puede soportar la implementación de WAF y otras funciones relacionadas con la seguridad. Como solución holística, el ADC adecuado puede costar mucho menos en total que la suma de sus funciones individuales como soluciones puntuales.
También vale la pena explorar las capacidades del propio equilibrador de carga. A diferencia del equilibrio de carga rudimentario, un ADC generalmente ofrece una serie de perillas y palancas relacionadas con la seguridad que pueden emplearse para dificultar los ataques. La detección de inundaciones SYN, el cifrado de cookies, la ofuscación de URL y el filtrado de IP/puerto suelen estar disponibles como parte de un servicio de equilibrio de carga. Aumentar la protección más cerca de la aplicación hace que sea más difícil para el atacante acceder a ella.
2.Operacionalizar
Para disgusto de algunos y deleite de otros, aún no se conoce ninguna “caja divina” que pueda proporcionar por sí sola todo lo necesario para proteger y escalar aplicações. Vas a necesitar múltiples soluciones (la clave es minimizar la cantidad de plataformas en uso, ver más arriba) y eso significa múltiples consolas, paradigmas de gestión y, probablemente, personas. Todo lo cual arruinará tu presupuesto.
La operacionalización, que permite la automatización y la orquestación, puede controlar los costos de las soluciones que debe tener implementadas. Incluso capacidades como el escalamiento automático para aprovechar recursos que (probablemente) ya tienes para escalar y forzar a un atacante a responder de la misma manera pueden aumentar los costos de atacar mientras se mantienen bajo control los costos de defensa.
La operacionalización (DevOps, SDN, SDDC, SDx, nube privada, etc.) también aborda fuentes de alto riesgo: error humano y falta de procesos. En este último caso, no se puede automatizar un proceso (eso es orquestación, por cierto) que no existe. Y si no tienes uno, deberías tenerlo. Asegura que se tomen los pasos necesarios para proteger y escalar las aplicaciones cuando pasan a producción. El primero, el error humano, es un riesgo enorme, ya que puede abrir inadvertidamente agujeros en su seguridad que permiten que los malos entren, ya sea directamente o de manera clandestina durante la distracción de un ataque DDoS volumétrico.
3.La nube como escala
Y cuando ya no puedes escalar automáticamente o tu ancho de banda está sobrepasado, siempre está la nube. La nube como escala (cloud bursting, si lo prefieres) es una excelente opción que te permite defenderte eficientemente mientras aumentas los costos de ataque. Cambiar la limpieza y protección contra DDoS a la nube durante un ataque (o cuando comienza) puede reducir inmediatamente el impacto local en el negocio (en medidas de productividad y ganancias), lo que, de hecho, significa una defensa menos costosa. Dejar que la nube, con su escala (casi) infinita y sus enormes cantidades de ancho de banda, absorba un ataque costará mucho menos a largo plazo para usted, pero no para el atacante.
4.Seguro de adentro hacia afuera
Como se señaló anteriormente, los atacantes generalmente quieren sus datos. Esto se debe a que sus datos == $$ en el sórdido mercado abierto. Por eso, céntrese tanto (o más) en proteger sus datos como lo hace en su perímetro. Esto significa emplear todos los trucos y técnicas posibles para hacer que resulte muy costoso para un atacante obtener valor de sus ataques (mediante el robo de datos). Esto se logra mediante una vigilancia constante, protegiendo no sólo lo que entra en la aplicación sino también lo que sale. Esa es la protección de solicitud y respuesta.
La mayoría (67%) de los encuestados en nuestro Informe sobre el estado de la entrega de aplicação 2016 que tienen implementado un WAF en la actualidad confiaban en la capacidad de su organización para resistir un ataque de capa de aplicação (solicitud-respuesta). Se trata de cosas como SQLi y XSS, pero también seguridad WebSocket y prevención de session hijacking y una gran cantidad de otras capacidades que garantizan que sea muy costoso para un atacante lograr acceder a sus datos.
De hecho, una protección más consistente en las tres superficies de ataque (cliente, solicitud y respuesta) se correlacionó con una mayor confianza en resistir un ataque a la capa de aplicação . Esa no es una función “de borde”; es una función centrada en la aplicación. Uno que se encuentra más cerca de la aplicación que del borde de la red, y su objetivo no es detener los ataques a la red, sino los ataques que realmente extraen los datos. Ese es el valor que buscan los atacantes, y es el valor que hay que hacer tan caro que los atacantes se den por vencidos y se vayan a otra parte.
No hay forma de hacer que la seguridad sea barata. Simplemente no existe. Pero hay formas de mantener bajos los costos, de hacer que sean más caros para el atacante que para usted, sin dejarlo demasiado arruinado para proteger sus aplicaciones. Y si lo haces bien, y tus defensas obligan a los atacantes a consumir demasiados de sus propios recursos (y dinero), el dragón podría estar demasiado cansado (en quiebra) para ir tras esa mitad. Y eso le dará al halfling la oportunidad de obtener una ventaja en sus propias defensas.