Cinco armadilhas comuns na proteção de aplicações
This post is also available in:
Inglês 
Francês 
Alemão 
Italiano 
Espanhol 
Russo
Todos os anos, as empresas gastam muito dinheiro com as tecnologias de segurança mais recentes para proteger a confidencialidade dos dados e a experiência do usuário. Os CISOs buscam machine learning, automação, orquestração de análise e resposta de eventos e confiam nos provedores de nuvem pública e em seu integrador de sistema. No entanto, ainda ocorrem violações de dados.
1ª armadilha – “Eu pensei que um WAF fosse suficiente”
Ignorar as ameaças adicionais às aplicações foi além das explorações, aproveitando os 10 principais riscos às aplicações da web listados pelo OWASP. Sim, injeções, script entre sites, CSRF, sequestro de sessão e envenenamento de cookies e similares ainda são muito válidos, especialmente quando há tantos sistemas legados sem patch por aí. As equipes de desenvolvimento estão colocando mais ênfase na agilidade do que na segurança. No entanto, a superfície de ataque e, portanto, a exposição aos riscos é muito maior hoje.
Outras três ameaças a serem enfrentadas:
1. Bots ruins – um quarto do tráfego da Internet é gerado por bots maliciosos [CB1]. Com a carga nas redes e tentativas persistentes de assumir contas de usuário, manipular transações online e extrair dados confidenciais, as organizações não podem confiar apenas em seu firewall de aplicações da web, ou pior, perder tempo criando scripts feitos sob medida, e começar a pensar numa tecnologia dedicada de gerenciamento de bot. Isso permite que bots bons entrem e os prejudiciais sejam afastados.
2. Proteção das APIs – sistemas e aplicações interconectados que trocam dados por meio de APIs. Normalmente, elas são confiáveis e, portanto, podem ser facilmente ignoradas. O roubo de dados por meio de APIs desprotegidas já chegou aos noticiários várias vezes (PaneraBread, Venmo, Boots e mais). As organizações nem sempre conhecem todas as APIs que possuem, que tipo de dados estão processando e quem pode acessá-los. Elas precisam de uma boa ferramenta para descobrir, classificar e proteger todos os seus endpoints de API.
3. Negação de serviço – . há muito tempo que isso era um problema das operadoras de rede. Servidores da Web e ativos digitais agora são frequentemente alvos de adversários dispostos a interromper o serviço ou derrubar um site. Faz todo o sentido integrar a proteção DDoS de alto volume como parte da estratégia de segurança da aplicação.
2ª armadilha – “Fiquei tentado a agrupar meu WAF com o serviço CDN”
Sim, faz todo o sentido. Se você se preocupa mais com o desempenho do que com os dados confidenciais do cliente, esse pode ser o caminho a seguir. Mas se você se preocupa realmente com a proteção dos dados da empresa e do usuário, então precisa repensar esse comprometimento. Pela natureza da arquitetura, WAF na borda da rede não vê o tráfego por aplicação e, portanto, não pode aplicar quaisquer mecanismos de aprendizagem, detecção de anomalias e segurança positiva que resultem em nenhuma proteção de zero-day (dia zero). É provável que essas aplicações vazem dados, pois não são protegidas contra técnicas de ataque desconhecidas.
Em ambientes de nuvem pública, a lacuna é ainda maior, pois a tecnologia WAF fornecida pelo provedor de IaaS, um fornecedor não especializado, geralmente tem uma classificação baixa nos relatórios dos analistas. Veja mais em nosso blog anterior
3ª armadilha – “Posso aplicar a mesma segurança em todas as plataformas”
Esta é certamente uma dor real. Com o desejo de executar a mesma política de segurança de aplicações em todos os ambientes, data center(s), nuvem privada, Azure, AWS, GCP e Alibaba ou Tencent, as empresas são forçadas a fazer uma troca. O motivo é que cada ambiente e cada provedor exigem ajustes, como permissões de acesso, proteção de infraestrutura, mecanismos de autenticação e autorização, controles de tráfego de bot, ferramentas de segurança de API no back-end e muito mais.
Se alguém escolher a consistência (como um serviço gerenciado baseado em nuvem), a experiência do usuário (latência) e a segurança (consulte o item 2 acima) serão comprometidos. A escolha da otimização da segurança resultará em um esforço para adaptar as soluções certas para cada ambiente e, em seguida, dedicar tempo e recursos para atualizá-las constantemente e aplicar a política de segurança que o CISO gosta de implementar.
Esta situação infeliz leva a outra postura de segurança estilo queijo suíço, onde as possíveis consequências podem ser adivinhadas / descobertas / previstas com antecedência. Aqui estão algumas práticas recomendadas.
[Gostou dessa publicação? Inscreva-se agora para receber o conteúdo mais recente da Radware na sua caixa de entrada toda semana, além de acesso exclusivo ao conteúdo premium da Radware.]
4ª armadilha – “Eu pensei que poderia lidar com todas as exceções sozinho”
Os firewalls de aplicativos da Web sofrem historicamente de má reputação e por um bom motivo. Muitas regras legítimas foram bloqueadas por regras e configurações que não estavam de acordo com os requisitos de negócios. Quando isso acontece, o custo pode ser devastador, uma experiência ruim do usuário leva a uma postura negativa em relação à marca e diminui as taxas de conversão. O TCO de gerenciar um WAF internamente pode ser muito alto devido a essa sobrecarga de trabalho necessária e é um assunto para especialistas, especialmente quando avaliamos todas as ameaças de segurança mencionadas acima. O profissional menos experiente não verá os diversos alertas provenientes de diferentes soluções pontuais. A estratégia de segurança de aplicações consolidada gerenciada por especialistas com automação avançada e análises acionáveis reduz substancialmente o TCO enquanto fornece segurança com velocidade.
[Você também pode se interessar por: Como obter proteção da aplicação por trás do AWS/Azure CDN]
5ª armadilha – “Achei que o DevOps iria ouvir”
Alguns ataques não são bem-sucedidos devido a uma postura de segurança fraca e desconexa devido a processos interrompidos e conflitos internos. A dinâmica do desenvolvimento de aplicações e das práticas de segurança de hoje é tal que as soluções de segurança e, principalmente, a equipe, não conseguem acompanhar. Do ponto de vista do desenvolvedor, há muitos recursos disponíveis para projetar o pipeline de CI/CD perfeito com ferramentas automatizadas de provisionamento, teste e orquestração. Agilidade significa avançar com a próxima versão, próximo patch, próxima correção de bug, não desacelerando para inspecionar cada transação e cada módulo. Como a produtividade sempre vem em primeiro lugar, a segurança deve atuar junto. No entanto, esse é um equilíbrio delicado que cada organização administra de maneira diferente. Conforme o DevOps vai ganhando mais influência nas decisões relacionadas à segurança, a equipe de segurança da informação deve levar em consideração que uma solução de segurança de aplicação deve fazer muito mais do que apenas bloquear ataques, ela deve se integrar bem ao ecossistema SDLC e ser adaptável, ajustar a política sempre que uma mudança na aplicação for introduzida. Ela também deve possibilitar ao DevOps a visibilidade necessária das métricas de desempenho e automação em todos os ambientes. Assim, consertamos o processo e todos ficam felizes.
Evitar essas armadilhas resultará em uma estratégia de segurança da aplicação, que é:
• Consistente
• Transparente
• Adaptativa
• Eficaz
