Por Dileep Mishra
21 de julio de 2020
Uno de nuestros clientes experimentó recientemente un ataque DDoS. O algo parecido. Pensaron que se trataba de un ataque y estuvieron a punto de invocar el servicio de mitigación de DDoS, pero esperaron porque no estaban 100% seguros y creían que podría haber sido una interrupción de corriente.
¿Le suena familiar? Si es así, no es el único. Existen muchas soluciones de mitigación de DDoS disponibles en el mercado, y la mayoría ofrece una increíble variedad de opciones. Desde opciones en las instalaciones hasta en la nube, en serie o en derivación (out-of-path), soluciones puntuales especializadas o integradas todo en uno, autogestionadas y completamente gestionadas, de un solo subproceso o procesos redundantes con derivación, hay más versiones disponibles de las que la mayoría de los clientes pueden intentar analizar.
Explorar lo que es mejor para su infraestructura podría ser un ejercicio interminable porque su CISO podría tener diferentes prioridades que su arquitecto de seguridad (que obviamente piensa de manera diferente que su gerente del centro de operaciones de seguridad, que a su vez se preocupa por cosas diferentes que la persona a cargo de las compras). Llegar a un consenso puede ser difícil. Y su proveedor no lo hace más fácil con seis propuestas de precios diferentes, todas similares, pero con variaciones muy leves, suficientes como para confundirlo a usted y a sus colegas por completo. Usted empieza a pensar que tal vez sea mejor seguir con lo que ya ha implementado su proveedor actual de mitigación de DDoS, a pesar de que realmente no funcione.
He visto a tantos de mis compañeros y clientes exagerar con el diseño de su solución de mitigación de DDoS que a menudo me dan ganas de gritar: "¡no, por favor no, esto realmente nunca funcionará para usted!" Se ve bien en el papel; pero, ¿tiene los recursos operativos para que realmente funcione?
No siempre lo más complejo es lo mejor
Por lo general, cuantas más opciones tenga en su diseño, más compleja será la operación de su solución. Por lo tanto, esa caja redundante en las instalaciones, esa fuente automática de amenazas o esa opción de depuración en la nube de alta capacidad, todas tienen una complejidad adicional.
La sabiduría convencional nos dice que, si agrega automatización o un elemento completamente gestionado por su proveedor, será más simple. Sin embargo, lo que está haciendo es simplemente transferir la complejidad a otra persona, que puede o no estar preparada para tomar decisiones por usted, cuando llegue el momento crucial. Lamentablemente, nadie en el mercado tiene una cobertura de ataques simple e integral, por lo que debe decidir qué funciona mejor para sus necesidades.
No digo que la complejidad sea mala, solo que una solución compleja de mitigación de DDoS es como un avión de combate, y necesita pilotos de combate bien entrenados para operarla. No espere que vuele sola.
La opción de doble proveedor puede no valer la pena
Si es un banco o una gran institución financiera, es probable que tenga una política de doble proveedor. ¿Qué podría salir mal? Tiene dos proveedores de mitigación de DDoS; por lo tanto, si uno no puede detener un ataque, el otro debería poder... ¿verdad?
Posiblemente, las personas a las que se les ocurrió la política de doble proveedor nunca han trabajado en la sala de emergencias de un hospital. Estar bajo un ataque DDoS, es como estar sufriendo un ataque cardíaco e ir a la sala de emergencia del hospital. Lo que quiere en ese momento es un solo hospital, una recepción y un equipo de médicos y enfermeras. El tiempo y la disponibilidad de un equipo médico es más importante que el equipo disponible. Del mismo modo que no compra dos pólizas de seguro médico diferentes pensando que en caso de tener un ataque cardíaco, una de ellas vendrá a su rescate. Debe elegir una póliza, un médico de atención primaria y un hospital.
Una solución de mitigación de DDoS es como un servicio de emergencia, y es probable que una solución de un solo proveedor detecte y mitigue el ataque, mientras le sujeta la mano.
La redundancia es buena, pero cubrir todos los escenarios puede no valer la pena
Uno de los aspectos clave del diseño para la mitigación de DDoS es la redundancia. La mayoría de los clientes están acostumbrados a comprar dos dispositivos de mitigación de DDoS para su data center. Algunos también compran un interruptor de derivación en caso de que los dispositivos fallen. Además, algunos clientes tienen una solución híbrida donde tienen la opción de invocar el servicio Cloud DDoS si el volumen del ataque es muy grande.
Dado que el aspecto clave de la mitigación de DDoS es la detección precisa y la mitigación rápida; en algunos escenarios, el diseño de la solución puede generar mucha confusión cuando realmente está bajo ataque. No hay una talla única para todos, pero si tiene una gran cantidad de redundancia incorporada, debe tener documentación precisa y útil que la acompañe. De lo contrario, su equipo no sabrá qué botones operar cuando esté bajo ataque.
Solo informe vs. bloqueo en serie
Algunas soluciones de mitigación de DDoS vienen con las opciones de Solo informe o En derivación. La idea es que le avisen cuando ocurre un ataque, pero también tiene la opción de actuar después de haber hecho un análisis.
Esto suena muy bien en el papel, pero nunca he visto este concepto funcionar en acción. La mayoría de las veces, si está en modo Solo informe, ni siquiera se entera de que hubo un ataque. Si bien existe cierto riesgo de falsos positivos, es mejor que esté en modo de bloqueo (o en serie). De lo contrario, ¿qué sentido tendría una solución de mitigación de DDoS? Es como tener a un hospital en modo de Solo informe: sí, avíseme si tuve un ataque cardíaco.
Cantidad de políticas de seguridad
Ya sea que se trate de un dispositivo de mitigación de DDoS en las instalaciones o un servicio basado en la nube, tiene la opción de diseñar su política de seguridad tan simple o tan compleja como quiere que sea. Solo porque hay 100 médicos para elegir en el hospital, no significa que quiera tenerlos a su disposición a todos al mismo tiempo.
Como regla general, es mejor tener algún tipo de política de seguridad global que se use como una política general y entre 10 y 20 políticas individuales, cada una correspondiente a un conjunto similar de aplicaciones. Esto le brinda el equilibrio adecuado entre segregar sus aplicaciones y mantener un conjunto de políticas entendibles.
Comments