0
0
Nos últimos anos, o mundo da segurança de aplicativos viu o aumento da tecnologia de autoproteção de aplicativos em tempo de execução (RASP). Conforme descrito pelo Gartner, o RASP é uma tecnologia de segurança integrada a um aplicativo ou seu ambiente de tempo de execução, capaz de controlar e prevenir ataques em tempo real. Infelizmente, muitas empresas de firewall de aplicativos da Web (WAF) viram uma oportunidade de aproveitar o termo. Eles introduziram agentes “semelhantes a RASP” na camada de rede, que não está abraçando totalmente a definição de tecnologia RASP.
Em contraste, a tecnologia RASP genuína opera na camada de aplicativo, onde tem contexto completo do usuário, da lógica do aplicativo e das informações de domínio. Esse contexto permite que um RASP tome decisões informadas sobre a segurança do aplicativo e evite explorações antes que elas possam causar danos. Como resultado, um verdadeiro RASP deve ter zero falsos positivos e latência reduzida, proporcionando um aumento imediato no desempenho. O verdadeiro RASP requer uma lista de regras imutáveis que usam o contexto para entender quando uma nova vulnerabilidade é introduzida e agir de acordo. Essa imutabilidade é possível quando as regras são incorporadas à base de código na camada de aplicativo e não exigem alterações depois de implantadas.
Três áreas onde o RASP deu errado
1. O problema do cachorro latindo: a maioria dos alertas são falsos positivos
O problema com os WAFs é que eles funcionam na camada de rede, um indicador atrasado da execução do aplicativo. A falta de contexto resultante leva a altas taxas de falso-positivos, longos tempos de espera e baixo desempenho, já que os WAFs só podem adivinhar sobre a natureza de uma vulnerabilidade com base no que foram expostos anteriormente.
Imagine um cão de guarda no quintal latindo sempre que ouve um barulho além da cerca. Esses ruídos podem ser a aproximação de um intruso, mas também podem ser carros passando. O cão de guarda não pode medir com precisão a diferença, de modo que a gravidade de qualquer ruído é perdida, tornando impossível para as pessoas dentro da casa saberem quais alertas são genuínos e quais são falsos positivos. Esse cenário é essencialmente a capacidade da oferta RASP padrão.
2. O problema dos bandidos 999: apenas capaz de testar uma amostra
Acredite ou não, alguns fornecedores dizem para você executar sua solução de segurança apenas em ambientes de produção se você proteger apenas um tamanho de amostra. Isso significa que ele puxa uma amostra – talvez uma em cada 1.000 solicitações – e testa essa amostra enquanto captura o que acontece para o próximo 999. Ou seja, se você é um bom ator, sua assinatura será verificada. Mas, independentemente de os seguintes atores do 999 terem ou não más intenções, eles passarão. Essa falta de consistência ocorre porque os RASPs baseados em WAF não podem lidar com os requisitos de desempenho de ter que testar todas as solicitações.
3. O problema “Demora muito tempo”: a latência afeta o desempenho
Sempre que você tem um RASC baseado em WAF, você experimenta maior latência, uma vez que ele não pode influenciar a base de código do aplicativo de forma alguma. Enquanto isso, os RASPs amplamente disponíveis precisam enviar cargas inteiras de texto para o analisador da Web e, em seguida, esperar que ele seja enviado de volta, o que pode levar muito tempo. E se seus clientes estão esperando que os pagamentos sejam aprovados, eles podem desistir e procurar seus concorrentes.
Melhorar esse processo é semelhante à otimização de código. Ao criar uma lista, os desenvolvedores a configuram para adicionar novos itens ao início de uma lista em vez do fim. Essa otimização impede que a VM recrie toda a lista sempre que um novo item for adicionado, impedindo o aumento da latência à medida que a lista cresce. Os engenheiros do compilador abordaram esses problemas implementando a compilação just-in-time (JIT) no início dos anos 2000, que otimiza automaticamente o código com base nas nuances da linguagem dada.
Por que a definição de RASP foi tão diluída?
O desenvolvimento da tecnologia RASP requer uma combinação de engenharia de segurança e habilidades de engenharia de software. Para ser eficaz, o desenvolvedor RASP deve entender profundamente a arquitetura do aplicativo e as nuances da linguagem de programação que está sendo usada. Isso requer experiência de domínio que é rara entre os profissionais de segurança.
O verdadeiro RASP otimiza o código para desempenho e segurança
Como a maioria das plataformas RASP se comporta como WAFs, há uma enorme sobrecarga envolvida, o que requer executá-las no modo de amostra. Em contraste, um RASP genuíno executa a proteção real no tempo de execução.
Essas operações existem na memória, o que é muito eficiente, e como isso existe no mesmo espaço que seus aplicativos, elas são muito eficientes. Ao executar a proteção no tempo de execução, não há necessidade de limitar a taxa ou executar a proteção em tamanhos de amostra, pois a operação real leva apenas alguns milissegundos.
Independentemente de quaisquer alterações feitas no aplicativo, a segurança de alto desempenho permanece constante. Essa filosofia se alinha com a filosofia de infraestrutura como código, na qual você define o estado desejado de sua infraestrutura e, não importa o que aconteça no ambiente, o estado da infraestrutura permanece o mesmo.
O RASP, por definição, é paralelo a muitos princípios de infraestrutura como código. Esse paralelo é possível devido à profunda consciência contextual do aplicativo e da linguagem em que ele é construído. Como a infraestrutura como código, uma abordagem genuína do RASP pode e deve fazer uso da imutabilidade para garantir que as regras sejam aplicadas independentemente das alterações na base de código.
A imutabilidade é possível executando uma verificação na saída de uma função na primeira vez que ela é chamada e alternando qualquer funcionalidade não íntegra com funcionalidade protegida, garantindo que o aplicativo esteja sempre íntegro enquanto é executado.
Essa abordagem permite que a segurança seja independente de implantação e não requer alterações de código no código do aplicativo, no ajuste ou na espera de janelas de implantação.
Ao executar a proteção em tempo de execução, a aplicação de patches resulta com proteção imediata em todas as instâncias em execução do aplicativo, elimina-se a necessidade de falsos positivos constantes e elimina o risco de explorações futuras.
O RASP pode e deve ser mantido em um padrão mais alto
Em suma, o RASP deve ser mantido em um padrão mais alto. Quando feito isso, é possível proteger milhares de aplicativos, reduzindo o custo total de propriedade de seus WAFs e ajudando a evitar o esgotamento em suas equipes de segurança.
FONTE: DARK READING