HEIST é um risco ou uma ameaça?

Lori Mac VittieEngenheiro Emérito e Evangelista-Chefe | F5

Os profissionais de segurança têm a responsabilidade de entender a diferença entre riscos e ameaças e agir de acordo. Para quem não é especialista (ou seja, a maioria de nós), pode parecer que não há diferença entre os dois. Afinal, eles não são semanticamente equivalentes? Não usamos esses termos de forma intercambiável para descrever vulnerabilidades, ataques DDoS e a mais recente exploração de dia zero?

Talvez, mas os profissionais de segurança costumam ser muito mais precisos do que isso, principalmente porque, se não fossem, seus orçamentos superariam os de toda a área de TI enquanto travam uma guerra digital contra o arsenal cada vez maior de ferramentas, técnicas e tecnologias usadas para vencer suas defesas. Isso porque nem todas as ameaças apresentam o mesmo risco.

O risco é uma medida calculada que envolve diversos fatores, incluindo a probabilidade de ocorrência e o impacto caso seja explorado. Todos sabemos que poderíamos ser atropelados por um ônibus e sofrer consequências graves ao atravessar a rua hoje, mas a probabilidade de isso acontecer é tão baixa que a maioria de nós considera esse risco muito pequeno (se é que chega a ser registrado em nossa escala de risco). Por outro lado, usar saltos de três polegadas sem solado antiderrapante em pleno inverno de Wisconsin implica uma alta probabilidade de queda com consequências desfavoráveis; portanto, pessoalmente, considero isso um risco bastante elevado durante os meses de inverno.

Isso é risco.

Ameaças são outra coisa. Algo que não podemos controlar, como o clima, os itinerários dos ônibus ou a decisão de um invasor de lançar hoje um ataque volumétrico contra o nosso site.

Um dos objetivos dos profissionais de segurança e de suas organizações é minimizar os riscos, mitigando ameaças e reduzindo a probabilidade de exploração de uma vulnerabilidade. Se estiver fazendo 20 graus abaixo de zero e a entrada da garagem estiver coberta de gelo, uso botas sem salto e com solado antiderrapante. A ameaça é mitigada (mas não eliminada) e, assim, o risco é reduzido. Se uma nova vulnerabilidade for descoberta de repente, preciso avaliar o risco que essa nova ameaça representa para a minha organização.

Na verdade, essa metodologia de avaliação de riscos é tão amplamente aceita que o setor a descreve matematicamente:

A(tivo) + V(ulnerabilidade) + A(meaça) = R(isco)

Isso permite que cada organização não apenas atribua pesos aos fatores individuais de acordo com seus requisitos de negócios e sua tolerância a riscos, mas também aja de forma consistente. Isso pode evitar reações impulsivas e motivadas pelo pânico quando novas vulnerabilidades são anunciadas, especialmente se o risco avaliado estiver dentro dos limites de tolerância da organização.

E quanto ao HEIST?

O que nos leva ao HEIST, sigla de HTTP Encrypted Information can be Stolen through TCP-Windows (informações criptografadas por HTTP podem ser roubadas por meio de janelas TCP). HEIST é obviamente muito mais fácil de dizer e soa como algo saído de Missão: Impossível, não é? Essa vulnerabilidade foi apresentada na BlackHat e, ainda hoje, continua circulando pela Internet em artigos da Ars Technica e do Engadget. Até o momento, ela não foi detectada em uso real. Não é uma vulnerabilidade simples de explorar, e pesquisadores — incluindo os nossos — observam que explorar o HEIST não é uma tarefa trivial. Trata-se de um ataque complexo de canal lateral que combina o comportamento da API do navegador (observando o funcionamento normal do TCP por meio de uma API do navegador capaz de medir o tempo das respostas), o comportamento de aplicações web, a compactação de conteúdo, o TCP e a criptografia.

Esse ataque pode gerar tráfego intenso na rede caso seja necessário concluir várias solicitações, mas se enquadra melhor na categoria dos ataques “ruidosos”. Ambas as características são pouco atraentes para agentes mal-intencionados que não querem chamar a atenção. Ainda assim, se explorado com sucesso, os invasores poderiam combiná-lo com BREACH ou CRIME para descriptografar cargas úteis e acertar o proverbial prêmio máximo digital, expondo dados pessoais e empresariais confidenciais (talvez críticos). Nesse caso, provavelmente não se importariam com o quanto chamariam a atenção se conseguissem obter Informações de Identificação Pessoal (PII) — o prêmio máximo digital.

Isso é uma ameaça. Ela pode ser usada para exfiltrar dados. Isso é chamado de violação de dados e é Algo Muito Ruim™. A questão é: quando essa ameaça se torna um risco real?

Bem, hoje (quando escrevi isto, para ser mais preciso), essa ameaça não era concreta. Ou seja, ainda não havia sido observada em situações reais. Mas isso não significa que ela não esteja ocorrendo na prática; significa apenas que ainda não foi detectada. Ainda. Hoje. Neste exato momento.

Já está de cabeça girando? Agora você sabe por que os profissionais de segurança sempre parecem estar com um ar atordoado. É porque eles precisam lidar o tempo todo com esse tipo de raciocínio e tomada de decisão.

Então, a questão passa a ser: se essa ameaça se tornar existencial, qual será o risco? Para responder, é preciso determinar qual seria o impacto caso a vulnerabilidade fosse explorada. Se alguém conseguir extrair dados do seu aplicativo ou site, qual será o impacto? Qual será o custo para você? Não se esqueça de incluir o impacto sobre a marca, pois isso faz parte da equação — cada vez mais complexa. O custo da mitigação também. A equação muda quando o custo da mitigação é alto em comparação com uma solução de impacto relativamente baixo. Se for necessário mexer em todos os servidores web do data center (e da nuvem) para alterar uma única configuração e mitigar a ameaça, isso exigirá muito tempo (e, consequentemente, dinheiro) para lidar com algo que talvez represente uma ameaça existencial. Se o risco for baixo, é provável que você adote uma compreensível postura de “esperar para ver”, em vez de sair correndo só porque alguém gritou “lobo”.

Se a mitigação tiver um impacto relativamente baixo em termos de custos de implementação — por exemplo, um script simples que confunda o invasor variando o tamanho dos dados retornados e, assim, dificulte a execução do HEIST —, talvez valha a pena seguir em frente e implementá-la. Afinal, o custo de reduzir ainda mais o risco seria mínimo e quase certamente muito menor do que as consequências caso esse HEIST venha a ser realizado no futuro.

Um constante ato de (re)equilíbrio

A realidade é que a segurança é uma batalha constante para minimizar riscos por meio da mitigação de ameaças, ao mesmo tempo que se navega pelo campo minado político presente na maioria das organizações de TI. Com muita frequência, os profissionais de segurança decidem não se empenhar na implementação nem mesmo de medidas simples de mitigação para ameaças cuja probabilidade de risco varia, porque a TI opera em silos funcionais.

Eles esperam até que o risco aumente e os force a reagir, em vez de mitigar a ameaça de forma proativa. Por exemplo, muitas das vulnerabilidades mais comentadas nos últimos dois anos estavam relacionadas a aplicações. Para mitigá-las, é necessário implantar soluções no caminho dos dados, antes da aplicação, pois o local mais eficiente e eficaz para isso continua sendo o ponto em que as aplicações são finalmente agregadas para fins de escalabilidade e entrega. No entanto, esse ponto estratégico de controle é gerenciado pelas equipes de entrega de aplicações, e não pelas equipes de segurança. O esforço necessário para mitigar essas ameaças antecipadamente supera o risco. Como a capacidade dos dois grupos de chegar a um meio-termo, por assim dizer, continua sendo um desafio constante para as organizações, a redução proativa dos riscos e a mitigação das ameaças na camada de aplicação simplesmente não acontecem.

No momento, o HEIST provavelmente é considerado um risco baixo para a maioria das organizações. Mas não se engane: ele é uma ameaça e, portanto, merece ser considerado agora, quando todos já fomos alertados sobre sua existência, antes que seja colocado em prática. É necessária uma coordenação entre as equipes para que soluções de segurança “sem servidor”, como esta mitigação para o HEIST, possam ser implantadas antes que a ameaça se torne existencial e o risco de exploração leve todos a uma corrida frenética de atividades e implementações dispendiosas para enfrentá-la.

Sobre o autor

Lori Mac VittieEngenheiro Emérito e Evangelista-Chefe | F5

Lori MacVittie é engenheira distinta e evangelista-chefe no Escritório do CTO da F5, com ampla experiência em entrega de aplicações, estratégia de automação e infraestrutura. Ela é conhecida por transformar complexidade em clareza, seja definindo diretrizes para agentes de IA, analisando arquiteturas multinuvem frágeis ou investigando os limites de sistemas escaláveis. Ela acumula mais de trinta anos de experiência no setor, abrangendo desenvolvimento de aplicações, arquitetura de TI e operações de redes e sistemas. Antes de ingressar na F5, atuou como editora de tecnologia e recebeu diversos prêmios. MacVittie tem mestrado em Ciência da Computação e é uma autora prolífica, com publicações que abrangem segurança, nuvem e arquitetura empresarial. Ela também é uma entusiasta de jogos de tabuleiro e videogames, além de ter opiniões assumidamente fortes sobre queijos.

Mais publicações de Lori Mac Vittie