Protegendo a economia digital das ameaças modernas utilizando o BIG-IP Application Security Manager (ASM)

A Internet é responsável por grande parte da atividade econômica, operações financeiras, comércio e pela forma como nos comunicamos com tudo e todos hoje em dia. Sendo assim, é inevitável que se torne uma espécie de campo de batalha cibernético com a finalidade de atingir o estilo de vida moderno. O impacto causado pela indisponibilidade ou a violação de um serviço online hoje em dia pode ser responsável por prejuízos diretos às corporações, além de danos irreparáveis para as marcas envolvidas.

Saber como se proteger, por meio da adoção de ferramentas adequadas e outros procedimentos, tornou-se crucial para poder se desenvolver no meio digital. Ferramentas como os firewalls de aplicação (WAF), técnicas modernas de programação segura, apontamentos do OWASP quanto às vulnerabilidades as quais as aplicações estão mais sujeitas, estão entre os vários assuntos aqui abordados. Além, é claro, do BIG-IP ASM, que foi o produto do segmento de WAF escolhido como referência para ter suas funcionalidades discutidas por esse artigo.

WAF

Em um cenário em que aplicações online se tornaram um dos mais importantes alvos de ameaças cibernéticas é que o WAF (Web Application Firewall) surge como uma poderosa arma para proteger as corporações e suas atividades online. Ele pode ser apresentado como uma aplicação ou um equipamento de rede capaz de inspecionar e aplicar uma série de regras sobre os protocolos de comunicação das aplicações, sejam eles HTTP, DNS ou outros. Essas regras servem para proteger as aplicações de ataques conhecidos como cross-site scripting (XSS), SQL injection, ataques de dia zero, além de detectar assinaturas de uma série de outros ataques conhecidos e anomalias comportamentais. Lembrando que as funcionalidades e tipos de proteção disponíveis podem variar entre produtos, fabricantes e versões utilizadas.

Programação Segura

Há um consenso geralmente aceito de que aplicações são desenvolvidas com bugs. Nem mesmo investimentos pesados em práticas seguras de programação é capaz de mitigar 100% a possibilidade de erro humano. Fora isso, ainda é necessário considerar que nem todos os problemas podem ser resolvidos somente com práticas de programação, pois defeitos podem existir no servidor de aplicação, sistema operacional de servidores ou bibliotecas de terceiros utilizadas nas aplicações.

Uma vez que uma vulnerabilidade é descoberta em uma aplicação, a solução do problema pode conflitar com processos em andamento em uma fábrica de software e impactar diretamente em prazos e custos operacionais. Até que decisões sejam tomadas e as respectivas atividades concluídas, o funcionamento da aplicação permanecerá representando um risco.

Por esse motivo os especialistas responsáveis pela segurança ficam sem poder reagir às vulnerabilidades. Além de que, sem uma solução de WAF, não é possível saber da ocorrência de ameaças ainda mais quando se trata de tráfego SSL/TLS. Além disso, o WAF pode ser utilizado como uma mitigação temporária enquanto o desenvolvimento atua na correção da aplicação, devolvendo o controle de acesso ao time de segurança.

OWASP Top 10

O OWASP é uma organização internacional aberta dedicada em apoiar as empresas a produzir sistemas mais confiáveis por meio de ferramentas, documentação, fóruns e outras iniciativas. Ela divulga de tempos em tempos um documento chamado OWASP Top 10, que é uma base de conhecimento sobre segurança que classifica as 10 maiores vulnerabilidades que afetam as aplicações no mundo todo. Esse documento serve de base de conhecimento para decisões de implementação em aplicações e sistemas de defesa, como os WAFs.

A versão atual foi lançada em 2013, a anterior foi em 2010, e eles já estiveram coletando informação para o lançamento da próxima versão, a qual tem seu lançamento esperado para agora em 2016, ou mais tardar em 2017. Atualmente as principais vulnerabilidades classificadas pela OWASP são:

1. Injection: A possibilidade de inserção de dados maliciosos para um interpretador como parte de um comando ou consulta às bases de dados;
2. Broken Authentication and Session Management: Comprometimento de senhas ou outras informações sobre sessões que permitem assumir a identidade de outros usuários;
3. Cross-Site Scripting (XSS): Inserção de scripts maliciosos que poderão ser executados no navegador de outros usuários;
4. Insecure Direct Object References: A exposição de informação relevante sobre a aplicação, como arquivos, diretórios ou chaves de bancos de dados, os quais podem ser manipulados para modificar o comportamento da aplicação;
5. Security Misconfiguration: Configurações de aplicações que permitem acesso não autorizado, como usuários senhas padrão, bem como a falta de atualização ou correções;
6. Sensitive Data Exposure: A falta de proteção de informações sensíveis, como cartões de crédito ou documentos pessoais que podem ser utilizados em diversos tipos de fraudes;
7. Missing Function Level Access Control: A falta de validações internas de permissões antes da execução de tarefas em sistemas. São casos em que a aplicação esconde o botão de acesso a um recurso na tela, porém não revalida a permissão quando ele é acessado, permitindo que um usuário com conhecimento da aplicação tenha acesso a recursos não permitidos;
8. Cross-Site Request Forgery (CSRF): A possibilidade de uma aplicação maliciosa induzir o usuário a executar tarefas em outros sites usando as próprias credenciais de acesso;
9. Using Known Vulnerable Components: Uso de bibliotecas ou módulos com vulnerabilidades conhecidas;
10. Unvalidated Redirects and Forwards: A não validação de redirecionamentos.

BIG-IP Application Security Manager (ASM)

O Application Security Manager (ASM) é um produto da família BIG-IP da F5 que exerce a função de WAF. É uma poderosa ferramenta que permite às empresas se protegerem contra as vulnerabilidades do OWASP Top 10, vulnerabilidades de aplicação, ataques de dia zero e outras anomalias, como DoS ou ataques brute-force. Além disso, ele habilita conformidade com padrões regulatórios como o FFIEC, HIPAA, e PCI-DSS.

Outra funcionalidade importante do ASM é sua integração com ferramentas de análises de vulnerabilidade, como o WhiteHat Sentinel, o Trustwave App Scanner, o IBM Rational AppScan e o QualysGuard Web Application Scanning; o que vai permitir a mitigação imediata de vulnerabilidades reais detectadas nas aplicações, o que é conhecido como virtual patching.

O ASM trabalha com dois modelos de segurança conhecidos como segurança positiva e segurança negativa, os quais compreendem grupos diferentes de regras e são explicados abaixo:

Modelo de segurança positiva

O modelo de segurança positiva começa bloqueando tudo e passa a permitir somente o tráfego conhecido, onde cada regra incluída passa a permitir mais tráfego. As regras desse modelo são compostas pelos elementos File Types, URLs, Parameters, Cookies, Headers, e Redirection Domains que regulam as interações entre usuários e aplicações, onde:

• File Types: São referências aos tipos de arquivos através das suas extensões, como por exemplo .php, .aspx, gif ou outras;
• URLs: São os caminhos de objetos da aplicação, como o /home.aspx ou o /login.php. O elemento URL também permite configurar uma cadeia de caminhos chamados flows, que determina sequências válidas de navegação;
• Parameters: São os parâmetros utilizados nos métodos GET (query string) e POST. Nesse elemento os dados enviados às aplicações podem ser validados quanto ao tipo e conteúdo. Eles podem ser globais, por URL ou fazer parte de um fluxo de navegação;
• Cookies: São dados definidos pelo servidor que devem persistir no navegador do usuário. Cookies podem ser validados quando de sua modificação pelo usuário;
• Headers: São os parâmetros de controle trocados entre o browser e o servidor. Podem ter seus valores validados ou ativar perfis de conteúdo por URL;
• Redirection Domains: São os domínios que são validados durante redirecionamentos realizados por respostas da família 300 do protocolo HTTP.

Os elementos do modelo de segurança positiva podem ser atribuídos explicitamente, as explicit entities, ou indiretamente como wildcard entities. Wildcards são entidades definidas parcialmente ou como curinga, e que atuam como alternativas àquelas que são diretamente atribuídas. A correspondência de regras respeita a seguinte ordem:

1. Explícitas;
2. Atribuídas parcialmente (ex. “pa*word”);
3. Atribuições curinga (ex: “*”).

Modelo de segurança negativa

Já o modelo de segurança negativa considera que todo o tráfego é permitido a menos que um dado ou padrão de comportamento explicitamente configurado como proibido seja detectado, no qual cada regra incluída endurece mais a política e bloqueia mais tráfego. Entre os elementos de configuração desse modelo de segurança destacamos Attack Signatures, Login Enforcement, Anomaly Detection e DoS.

Attack Signatures são padrões de tráfego que correspondem a ataques conhecidos. Elas são verificadas em cada transação realizada a fim de detectar dados maliciosos no tráfego, funcionando como uma espécie de IPS. Sua base precisa ser atualizada frequentemente a fim de garantir que ela atenda as novas vulnerabilidades que são descobertas.

O Login Enforcement é uma funcionalidade que permite que determinada área no servidor somente tenha acesso permitido mediante a realização de uma transação bem-sucedida de login pelo usuário. Ela é ativada por meio do cadastramento de uma tela ou transação de login e ativa diversos controles de segurança relacionadas à sessão do usuário, como rastreio e bloqueio de requisições por usuário e a referência a ele nos eventos que forem gerados.

Anomaly Detection são análises comportamentais voltadas a detectar clientes da aplicação que não se comportem como usuários comuns ou que prejudiquem o despenho e a segurança da aplicação. Temos entre os elementos de Anomaly Detection:

• Brute Force Attack Prevention: Previne a quebra da segurança da aplicação por meio de tentativas exaustivas de descobrir o login e/ou a senha de um usuário;
• Web Scraping: São um conjunto de medidas a fim de prevenir que um volume de informações seja obtido da aplicação por acessos robotizados;
• DoS Protection: Recurso utilizado a fim de impedir que os recursos computacionais de uma aplicação fiquem indisponível para atender o usuário legítimo causada por sobrecarga de acesso.

As mitigações disponíveis para os elementos do tipo Anomaly Detection citados acima são:

• Client Side Integrity Defense: Injeta um código javascript para determinar se o cliente da aplicação é um navegador da internet real;
• CAPTCHA Challenge: Envia um desafio de tipo pergunta e resposta para certificar que se trata de um usuário humano;
• Rate Limit: Aplica uma redução de desempenho bloqueando aleatoriamente algumas requisições vindo do cliente detectado como ofensor;
• Drop IP: Bloqueia totalmente o cliente detectado como ofensor.

Ainda em Anomaly Detection temos seguintes elementos:

• Geolocation Enforcement: Permite configurar países que podem ou não ter acesso à aplicação;
• IP Address Exceptions: Permite incluir endereços que são tratados como exceção nas regras de segurança de aplicação.

Tipos de implementação

Os tipos de implementação se dividem basicamente entre manual e automático, além de opções que definem a sua abrangência. No modo manual temos disponível o Rapid Deployment Template e os Application-Ready Templates:

• Rapid Deployment Template: É um modelo de configuração simplificado que reduz significativamente a quantidade de falsos positivos gerados, permitindo assim um tempo menor de avaliação da política para um mais rápido endurecimento das regras;
• Application-Ready Templates: É um conjunto de regras desenhadas especificamente para determinadas aplicações disponíveis no mercado. Uma política que utiliza esses templates já possuem os seus elementos pré-configurados, o que praticamente dispensa o período de avaliação e permite um endurecimento de regras ainda mais rápido e preciso.

Independente do template utilizado, o modo manual gera sugestões de aprendizado para exceções de eventuais falsos positivos (Traffic Learning) ou elementos que podem ter seu comportamento endurecidos nas políticas (Enforcement Readiness). A avaliação desses itens são parte crucial da rotina de administração das políticas do ASM.

Já o modo automático vai aceitar automaticamente as sugestões, como seriam feitas no modo manual, seguindo um conjunto de parâmetros que envolvem número de requisições, sessões únicas e de intervalo de tempo, a fim de realizar o trabalho que seria feito pelo administrador do ASM. A fim de completar a rotina de trabalho, o modo automático também possui um mecanismo de detecção de alterações na aplicação, com a finalidade de afrouxar automaticamente a regra que se refira a elementos que possam ter sido alterados.

Aprendizado de regras

É recomendado que haja um período de avaliação das regras para que a política possa ser refinada, seja ele manualmente ou automaticamente, a fim de reduzir falsos positivos. Essas atividades consistem em endurecer algumas regras, preencher elementos de modelo de segurança positivo e incluir algumas exceções necessárias. É nesse momento, por exemplo, em que sites voltados para países de língua latina vão poder adicionar exceção para metacaracteres e caracteres ASCII altos (acima de 127) de forma a permitir o uso de acentuação na aplicação. Durante essa fase a política fica em modo transparente (Enforcement Mode: Transparent).

Passados alguns dias, tempo esse que vai depender do volume de tráfego da aplicação, já é possível chegar em um nível razoável de refinamento da política. Esse momento acontece geralmente quando o volume de sugestões de aprendizado, que realmente apontam para falsos positivos, cai substancialmente. Quando isso acontece as regras podem ser endurecidas e a política pode ser retirada do modo transparente para passar a bloquear as requisições (Enforcement Mode: Blocking). Lembrando que o modo de bloqueio sozinho não ativa todas as proteções, é necessário também que os elementos configurados e as assinaturas sejam retiradas do modo de demonstração (Staging) para que o ASM passe a proteger ativamente a aplicação.

Uma vez que as políticas são endurecidas e passam a bloquear requisições de fato, isso não quer dizer que o trabalho acabou. O sistema vai continuar descobrindo novos elementos e sugerindo alterações de regras, isso acontece o tempo todo para todas as regras que tiverem com a opção Learn habilitada. Caso não seja possível incluir essas atividades na rotina de segurança, é imprescindível considerar o uso do modo de aprendizado automático. A diferença nesse caso é que o modo automático vai tomar decisões baseadas em estatísticas, que são totalmente configuráveis e relativamente fáceis de entender, enquanto um operador humano poderia ter em mente também o comportamento da aplicação e as regras de negócio envolvidas.

Rotina de Administração

Como citado anteriormente, existe uma rotina a ser seguida na administração do ASM. As principais atividades dessa rotina são a manutenção dos logs de requisições, de aprendizado de tráfego (Traffic Learning) e a efetivação de regras (Enforcement Readiness).

Os logs de requisições fornecem informações valiosas para avaliação de ameaças e análises de problemas em aplicações, porém eles podem causar prejuízo ao desempenho se o volume de eventos for muito grande e se não forem limpos regularmente. Para o armazenamento de grandes volumes por tempo indeterminado é recomendada a utilização de uma área de armazenamento externa. Na interface do BIG-IP, esses alertas devem ser analisados e, independentemente de qualquer ação tomada, eles devem ser excluídos, caso contrário os perfis de log devem permanecer desativados no longo prazo.

Na área de aprendizado de tráfego ficam todos os eventos gerados por elementos de configuração que possuem a opção de aprendizado ativada. Nessa área é possível decidir se o evento de fato representou um falso positivo que deve ser mitigado através da revisão dos parâmetros do evento, geralmente uma informação mais resumida que a do log de requisição. Dependendo do elemento pode existir mais de uma opção de mitigação possível, cabendo ao administrador selecionar qual corresponde melhor ao comportamento da aplicação.

Já quanto a área de efetivação de regras, é nela que o ASM classifica os itens em cada elemento de configuração como estando prontos para sofrer um endurecimento de regra ou que possuam sugestões de aprendizado a serem avaliadas. O endurecimento de regras pode ser realizado em massa ou por item diretamente nessa área, sem que seja necessário navegar em cada elemento manualmente e verificar seu estado. As regras que são mostradas nessa área como prontas para serem ativadas são aquelas que estão a algum tempo sem produzir nenhum alerta, logo correm o menor risco de produzir falsos positivos.

 

Apresentamos aqui os firewalls de aplicação (WAF), como funcionam e a organização OWASP. Estudamos o caso do BIG-IP ASM, uma poderosa ferramenta desse segmento, bem como citamos algumas de suas funcionalidades e rotinas de operação.

Não foi objetivo desse artigo servir de referência para configuração, pois poderia limitar o universo de versões e técnicas as quais ele se aplica, mas de somente revisar as funcionalidades presentes na maior parte das versões em uso hoje em dia.