Os profissionais de segurança têm a tarefa de entender a diferença entre riscos e ameaças e agir adequadamente. Para o leigo (a maioria de nós), a diferença entre os dois pode parecer inexistente. Afinal, eles não são semanticamente equivalentes? Não os usamos de forma intercambiável para descrever vulnerabilidades e ataques DDoS e o mais recente exploit de dia zero?
Poderíamos, mas os profissionais de segurança costumam ser muito mais precisos do que isso, principalmente porque, se não fossem, seus orçamentos ultrapassariam toda a TI, enquanto travavam uma guerra digital contra o crescente estoque de ferramentas, técnicas e tecnologia usadas para derrotar suas defesas. Isso ocorre porque nem todas as ameaças apresentam o mesmo risco.
Risco é uma medida calculada que envolve uma série de fatores, incluindo a probabilidade de ocorrência e o impacto se explorado. Todos nós sabemos que podemos ser atropelados por um ônibus e sofrer consequências terríveis ao atravessar a rua hoje, mas a probabilidade de isso acontecer é tão baixa que a maioria de nós considera esse risco muito baixo (se é que chega a ser medido em nosso medidor de risco). Por outro lado, usar saltos de 7,5 cm sem salto no meio do inverno de Wisconsin tem uma grande probabilidade de ocorrer uma queda com consequências desfavoráveis, então eu pessoalmente considero isso um risco bem alto nos meses de inverno.
Isso é risco.
Ameaças são outra coisa. Outra coisa que não podemos controlar, como o clima, as rotas de ônibus ou a decisão de um invasor de lançar um ataque volumétrico em nosso site hoje.
Um dos objetivos dos profissionais de segurança e suas organizações é minimizar os riscos mitigando ameaças e reduzindo a probabilidade de uma exploração. Se estiver 20 graus abaixo de zero e a entrada da garagem estiver coberta de gelo, eu uso botas baixas e bem pisadas. A ameaça é mitigada (mas não eliminada) e, portanto, o risco é reduzido. Se uma nova vulnerabilidade for descoberta de repente, tenho que decidir qual risco essa nova ameaça representa para minha organização.
Na verdade, isso é tão aceito como uma metodologia para avaliação de risco que a indústria o descreve matematicamente:
A(ativo) + V(ulnerabilidade) + T(ameaça) = R(isk)
Isso permite que organizações individuais não apenas ponderem fatores individuais de acordo com seus requisitos comerciais e tolerância a riscos, mas também ajam de forma consistente. Isso pode evitar reações impulsivas e de pânico quando novas vulnerabilidades são anunciadas, principalmente se o risco avaliado estiver abaixo das tolerâncias organizacionais.
O que nos leva ao HEIST, sigla para HTTP Encrypted Information can be Stolen through TCP-Windows. HEIST é obviamente muito mais fácil de dizer e soa como Missão Impossível, não é? Essa vulnerabilidade foi apresentada no BlackHat e está circulando pela Internet até agora em artigos no Ars Technica e no Engadget . Até agora, não foi avistado na natureza. Não é uma vulnerabilidade simples de explorar e pesquisadores — incluindo o nosso — observam que não é uma tarefa trivial explorar o HEIST. É um ataque complexo de canal lateral que combina o comportamento da API do navegador (ele observa a maneira como o TCP normalmente funciona com uma API do navegador que pode cronometrar as respostas), comportamento do aplicativo web, compactação de conteúdo, TCP e criptografia.
Este ataque pode ser pesado na rede se várias solicitações precisarem ser concluídas, mas é mais adequado na categoria “ruidoso”. Ambos não são atraentes para maus atores que não querem ser notados. E, ainda assim, se for explorado com sucesso, os invasores podem combiná-lo com BREACH ou CRIME para descriptografar cargas úteis e ganhar o prêmio máximo digital, expondo dados pessoais e comerciais confidenciais (talvez críticos). Nesse caso, eles provavelmente não se importariam com o quão barulhentos seriam se conseguissem obter Informações de Identificação Pessoal (PII), o prêmio máximo digital.
Isto é uma ameaça. Poderia ser usado para exfiltrar dados. Isso é chamado de violação e é uma coisa muito ruim™. A questão é: quando essa ameaça se torna um risco real?
Bem, hoje (quando escrevi isso, para ser mais preciso), essa ameaça não era existencial. Ou seja, não havia sido visto na natureza. Mas isso não significa que não esteja na natureza, significa apenas que não foi visto na natureza. Ainda. Hoje. Agora mesmo.
Já está com a cabeça girando? Agora você sabe por que os profissionais de segurança sempre parecem ter uma expressão atordoada no rosto. Porque eles têm que administrar esse tipo de processo de pensamento e tomada de decisão o tempo todo.
Então a questão é: se essa ameaça se torna existencial, qual é o risco? Para responder a isso, você precisa determinar qual seria o impacto se a vulnerabilidade fosse explorada. Se alguém conseguir exfiltrar dados do seu aplicativo, do seu site, qual será o impacto? Qual será o seu custo? Não se esqueça de incluir o impacto da marca, isso faz parte da equação (cada vez mais complexa). O mesmo acontece com o custo da mitigação. A equação muda quando o custo da mitigação é alto em comparação com uma solução de impacto relativamente baixo. Se você tiver que acessar todos os servidores web no data center (e na nuvem) para alterar apenas uma configuração para mitigar a ameaça, isso é muito tempo (e consequentemente dinheiro) para algo que pode ser existencialmente ameaçador. Se o risco for baixo, você provavelmente adotaria uma atitude compreensível de “esperar para ver” em vez de correr porque o menino gritou “lobo”.
Se a mitigação tiver um impacto relativamente baixo em termos de custos de implementação, digamos, um script simples que confunde o invasor ao variar o tamanho dos dados retornados e, assim, tornar o HEIST mais difícil de executar, você pode considerar seguir em frente e colocá-lo em prática. Afinal, o custo de reduzir ainda mais o risco foi mínimo e é quase certamente muito menor do que as consequências se o dito HEIST for realizado no futuro.
A realidade é que a segurança é uma batalha constante para minimizar riscos, mitigando ameaças e, ao mesmo tempo, atravessar o campo minado político que é a maioria das organizações de TI. Muitas vezes, os profissionais de segurança decidem não implementar nem mesmo medidas simples para ameaças com probabilidade flutuante de risco porque a TI existe em silos de funcionalidade.
Eles esperam até que o risco aumente e forçam uma reação, em vez de mitigar a ameaça proativamente. Por exemplo, muitos dos exploits mais comentados dos últimos dois anos foram focados em aplicativos. Para mitigá-los, as soluções precisam ser implantadas no caminho de dados, a montante do aplicativo, porque o local mais eficiente e eficaz para fazer isso continua sendo o ponto em que os aplicativos são finalmente agregados para escala e entrega. Mas esse ponto estratégico de controle é gerenciado por equipes de entrega de aplicativos, não por equipes de segurança. O esforço necessário para mitigar tais ameaças desde o início supera o risco. Como a capacidade dos dois grupos de se encontrarem em um meio termo, por assim dizer, continua sendo um desafio constante para as organizações, reduzir riscos e mitigar ameaças proativamente na camada de aplicação simplesmente não acontece.
O HEIST é, atualmente, provavelmente considerado de baixo risco para a maioria das organizações. Mas não se engane, é uma ameaça e, portanto, merece consideração agora, quando todos nós fomos notificados de sua existência antes de ser colocada em prática. A coordenação cruzada é necessária para que soluções de segurança "sem servidor" como esta mitigação para HEIST possam ser implantadas antes que a ameaça se torne existencial e o risco de exploração leve todos a um frenesi de atividades e implementações dispendiosas para lidar com isso.