O que o RASP deveria ter sido

O que o RASP deveria ter sido

O que RASP deveria ter sido PlatoBlockchain Data Intelligence. Pesquisa vertical. Ai.

Nos últimos anos, o segurança da aplicação mundo viu o surgimento de autoproteção do aplicativo em tempo de execução (RASP) tecnologia. Conforme descrito pelo Gartner, o RASP é uma tecnologia de segurança integrada a um aplicativo ou seu ambiente de execução, capaz de controlar e prevenir ataques em tempo real. Infelizmente, muitos Firewall de aplicativo da Web (WAF) as empresas viram uma oportunidade de alavancar o termo. Eles introduziram agentes “semelhantes a RASP” na camada de rede, que não está adotando totalmente a definição de tecnologia RASP.

Por outro lado, a tecnologia RASP genuína opera na camada do aplicativo, onde tem o contexto completo do usuário, da lógica do aplicativo e das informações do domínio. Esse contexto permite que um RASP tome decisões informadas sobre a segurança do aplicativo e evite explorações antes que possam causar danos. Como resultado, um verdadeiro RASP deve ter zero falsos positivos e latência reduzida, proporcionando um aumento imediato no desempenho. True 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 inseridas na base de código na camada do aplicativo e não requerem 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 de atraso da execução do aplicativo. A falta de contexto resultante leva a altas taxas de falsos positivos, longos tempos de espera e baixo desempenho, pois os WAFs só podem adivinhar 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 consegue aferir com precisão a diferença, pelo que se perde a severidade de um determinado ruído, impossibilitando que as pessoas dentro da casa saibam quais os alertas verdadeiros e quais os falsos positivos. Esse cenário é essencialmente a capacidade da oferta RASP padrão.

2. O problema dos 999 bandidos: 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 proteger apenas um tamanho de amostra. Isso significa que ele extrai uma amostra - talvez uma em cada 1,000 solicitações - e testa essa amostra enquanto captura o que acontece nas próximas 999. Ou seja, se você for um bom ator, sua assinatura será confirmada. Mas, independentemente de os 999 atores a seguir 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 conseguem lidar com os requisitos de desempenho de testar cada solicitação.

3. O problema “demora muito”: a latência afeta o desempenho

Sempre que você tem um RASP baseado em WAF, você experimenta um aumento da latência, já 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 de texto inteiras para seu analisador da Web e aguardar o envio de volta, o que pode levar muito tempo. E se seus clientes estiverem esperando os pagamentos serem concluídos, 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 final. Essa otimização evita que a VM reconstrua toda a lista sempre que um novo item é adicionado, evitando o aumento da latência à medida que a lista cresce. Os engenheiros do compilador resolveram 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 do idioma fornecido.

Por que a definição de RASP foi tão diluída?

O desenvolvimento da tecnologia RASP requer uma combinação de habilidades de engenharia de segurança e 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 conhecimento de domínio que é raro entre os profissionais de segurança.

True RASP otimiza o código para desempenho e segurança

Como a maioria das plataformas RASP se comporta como WAFs, há uma grande sobrecarga envolvida, que exige 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 existe no mesmo espaço que seus aplicativos, elas têm muito desempenho. Ao executar a proteção no tempo de execução, não há necessidade de limitar a taxa ou executar proteção em tamanhos de amostra porque 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 na qual ele é construído. Como infraestrutura como código, uma abordagem genuína para 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 em que ela é chamada e trocando qualquer funcionalidade não saudável por funcionalidade protegida, garantindo que o aplicativo esteja sempre íntegro enquanto é executado.

Essa abordagem permite que a segurança seja independente da implantação e não requer alterações de código no código do aplicativo, ajuste ou espera por janelas de implantação.

Ao executar a proteção no tempo de execução, corrigindo os resultados com proteção imediata em todas as instâncias em execução do aplicativo, elimina-se a necessidade de falsos positivos constantes e remove-se o risco de explorações futuras.

O RASP pode e deve ser mantido em um padrão mais elevado

Em suma, o RASP deve ser mantido em um padrão mais alto. Ao fazer isso, é possível proteger milhares de aplicativos, reduzindo o custo total de propriedade de seus WAFs e ajudando a evitar o esgotamento de suas equipes de segurança.

Carimbo de hora:

Mais de Leitura escura