Halflings, Dragões e Ataques DDoS
Uma restrição muito comum em aplicativos hoje em dia é o orçamento. Os orçamentos de segurança podem estar crescendo, sim, mas não em uma taxa compatível com a abordagem estratégica de se tornar caro demais para ser hackeado.
Essa abordagem é semelhante ao Princípio Halfling-Dragão que afirma:
Se você se encontrar na companhia de um halfling e um dragão mal-humorado, lembre-se de que você não precisa correr mais rápido que o dragão; você simplesmente precisa correr mais rápido que o halfling.
A ideia é fazer com que seu próprio ambiente seja muito caro para atacar, forçando o dragão a voltar seus olhos famintos para seu concorrente, o halfling.
Agora, sem entrar no debate ético que deveria surgir, a noção de tornar seu ambiente caro demais para ser hackeado não é ruim.
O problema é que isso geralmente significa que é caro demais para você pagar também. Isso ocorre porque, de modo geral, o conselho sobre a execução de tal estratégia envolve comprar um monte de soluções e lançá-las como uma espécie de manopla medieval, colocando novas barreiras e forçando os invasores a executá-las para obter o que realmente desejam: seus dados. Isso torna o ataque caro para o invasor, pois o força a gastar tempo, energia e, finalmente, dinheiro enquanto tenta espalhar seus ataques para evitar a detecção. Isso é caro não apenas para o invasor, mas também para a empresa. Não apenas em termos de soluções (capex), mas operacionalmente (opex), pois cada solução deve ser gerenciada, atualizada, monitorada e, por fim, dimensionada.
Também está de dentro para fora. O que os invasores querem são seus dados, e ainda assim tendemos a construir nossas defesas e proteções começando no ponto mais distante dos dados, no perímetro da rede.
Então, como você pode tornar muito caro para eles obterem o que querem, sem tornar muito caro para você implementar?
Não há uma solução mágica para isso, mas existem algumas maneiras de manter seus custos baixos e, ao mesmo tempo, aumentar os custos de ataque.
1. Plataformas de Alavancagem
As plataformas são baseadas na ideia de compartilhar um ambiente comum. Eles reduzem custos da mesma forma que a virtualização e a conteinerização aumentam a eficiência dos recursos de computação. Um ADC, por exemplo, pode ser estendido com módulos para oferecer suporte a uma ampla variedade de funções de entrega, incluindo segurança. Muitas organizações já usam um ADC para garantir a disponibilidade com balanceamento de carga que pode dar suporte à implantação de WAF e outras funções relacionadas à segurança. Como uma solução holística, o ADC certo pode custar muito menos no total do que a soma de suas funções individuais como soluções pontuais.
Também vale a pena explorar os recursos do próprio balanceador de carga. Ao contrário do balanceamento de carga rudimentar, um ADC geralmente oferece uma série de botões e alavancas relacionados à segurança que podem ser empregados para tornar os ataques mais difíceis. Detecção de inundação SYN, criptografia de cookies, ofuscação de URL e filtragem de IP/porta geralmente estão disponíveis como parte de um serviço de balanceamento de carga. Aumentar a proteção mais próxima do aplicativo torna mais difícil o acesso do invasor.
2. Operacionalizar
Ainda não existe, para desgosto de alguns e alegria de outros, nenhuma “caixa de deus” conhecida que possa fornecer sozinha tudo o que você precisa para proteger e dimensionar aplicativos. Você vai precisar de múltiplas soluções (a chave é minimizar quantas plataformas usar, veja acima) e isso significa múltiplos consoles, paradigmas de gerenciamento e provavelmente pessoas. Tudo isso vai estourar seu orçamento.
A operacionalização, que permite a automação e a orquestração, pode reduzir os custos das soluções que você precisa implementar. Até mesmo recursos como dimensionamento automático para aproveitar recursos que você (provavelmente) já tem para aumentar a escala e forçar um invasor a responder da mesma forma podem aumentar os custos de ataque, mantendo os custos de defesa sob controle.
A operacionalização (DevOps, SDN, SDDC, SDx, nuvem privada, etc.) também aborda fontes de alto risco: erro humano e falta de processo. No último caso, você não pode automatizar um processo (que é a orquestração, a propósito) que não existe. E se você não tem um, você deveria ter. Ele garante que sejam tomadas as medidas necessárias para proteger e dimensionar os aplicativos quando eles entram em produção. O primeiro, erro humano, é um risco enorme, pois pode inadvertidamente abrir brechas na sua segurança, permitindo que bandidos entrem, seja diretamente ou por baixo dos panos durante a distração de um ataque DDoS volumétrico.
3. Nuvem como Escala
E quando você não puder mais fazer o dimensionamento automático ou sua largura de banda estiver sobrecarregada, sempre há a nuvem. A nuvem como escala (explosão de nuvem, se preferir) é uma excelente opção para permitir que você se defenda com eficiência, ao mesmo tempo em que aumenta os custos de ataque. Mudar a proteção e a limpeza de DDoS para a nuvem durante um ataque (ou quando ele começa) pode reduzir imediatamente o impacto local nos negócios (em medidas de produtividade e lucro), o que, de fato, significa uma defesa mais barata. Deixar que a nuvem, com sua escala (quase) infinita e grande quantidade de largura de banda, absorva um ataque custará muito menos a longo prazo para você, mas não para o invasor.
4. Seguro de dentro para fora
Como observado anteriormente, os invasores geralmente querem seus dados. Isso porque seus dados == $$ no mercado aberto e decadente. Portanto, concentre-se tanto (se não mais) em proteger seus dados quanto você faz em seu perímetro. Isso significa empregar todos os truques e técnicas possíveis para tornar muito caro para um invasor extrair valor de seus ataques (obtendo dados). Você faz isso por meio de vigilância constante, protegendo não apenas o que entra no aplicativo, mas também o que sai. Isso é proteção de solicitação e resposta.
A maioria (67%) dos entrevistados em nosso State of Application Delivery 2016 que têm um WAF implantado hoje estavam confiantes na capacidade de sua organização de resistir a um ataque de camada de aplicativo (solicitação-resposta). São coisas como SQLi e XSS, mas também segurança WebSocket e prevenção de sequestro de sessão e uma série de outros recursos que garantem que seja muito caro para um invasor obter acesso aos seus dados.
De fato, uma proteção mais consistente em todas as três superfícies de ataque (cliente, solicitação e resposta) está correlacionada a uma maior confiança na resistência a um ataque na camada de aplicativo. Essa não é uma função “edge”; é uma função centrada no aplicativo. Um que fica mais próximo do aplicativo do que da borda da rede, e seu objetivo não é impedir ataques de rede, mas os ataques que realmente extraem dados. Esse é o valor que os invasores estão procurando, e é o valor que você precisa tornar tão caro que os invasores desistam e vão para outro lugar.
Não há como tornar a segurança barata. Simplesmente não existe. Mas há maneiras de manter os custos baixos, de tornar o processo mais custoso para o invasor do que para você, sem deixá-lo sem dinheiro para proteger seus aplicativos. E se você fizer isso bem, e suas defesas forçarem os atacantes a consumir muitos de seus próprios recursos (e dinheiro), o dragão pode estar cansado demais (quebrado) para ir atrás dessa metade. E isso dará ao halfling uma chance de começar a construir suas próprias defesas.