Por que o DevSecOps deve lutar por Medidas de Execução Eficazes
This post is also available in:
Inglês 
Francês 
Alemão 
Italiano 
Espanhol 
Russo
Uma conversa com potenciais clientes ensina mais do que ler uma pesquisa de mercado. Contatos recentes com clientes (infelizmente, ainda virtuais) deixaram bem claro: as empresas precisam de segurança eficaz.
1. Definindo o que é segurança eficaz
Não precisamos reinventar a roda o tempo todo. O desenvolvimento de aplicações modernas, as arquiteturas de entrega e as estruturas possibilitam a flexibilidade máxima das equipes de R&D. Além disso, serviços, módulos e funções prontos para uso estão disponíveis para uma integração simples. Porém, existe uma questão que pode complicar tudo: a necessidade de proteger a disponibilidade da aplicação, bem como a integridade e a confidencialidade de seus dados.
A aquisição de soluções seguras é fácil, basta comprar qualquer tecnologia que trate das ameaças. O gerenciamento é que fica mais complicado. Em primeiro lugar, as vantagens promovem o equilíbrio entre segurança e produtividade para equipes de desenvolvimento. Com isso em mente, as empresas conseguem ciclos de liberação mais rápidos e tempo para comercializar novos recursos a um custo reduzido, dando mais influência à equipe de Desenvolvimento e entrega de aplicações (AD&D) sobre decisões relativas à segurança. A segurança eficaz precisa fazer parte da sua cartilha. Em outras palavras, não quebre nada e não introduza interrupções ou lentidão.
2. A segurança “eficaz” precisa detectar
Existem estratégias diferentes para integrar tecnologias de proteção de aplicações no pipeline de CI/CD. Cada uma delas tenta aumentar a velocidade e minimizar os impactos sobre o ambiente, sejam eles latência, pegada de recursos ou custos da carga de trabalho. Na maioria dos casos, as estratégias “dev-friendly” têm pelo menos uma ou duas deficiências:
i. A solução não cobre toda a superfície de ataque
ii. A solução não aplica a execução de segurança de maneira ativa
i. Hoje, as ameaças às aplicações vão além da exploração de vulnerabilidades de código e lógica, que já são mais do que suficientes para se analisar e enfrentar. Acompanhar as vulnerabilidades conhecidas, os protocolos de autenticação e autorização mais recentes e as diferentes formas de hackeá-los já é uma tarefa e tanto.
Hoje, as aplicações – principalmente em ambientes de desenvolvimento modernos – fazem uso extensivo de APIs para compartilhar e consumir dados confidenciais, que são vulneráveis e exigem uma tecnologia cirúrgica dedicada para garantir que não haja abuso de token, utilização excessiva ou roubo de dados usando injeções.
Além da segurança de API, muitos serviços dependem da integração ou da veiculação de bots e precisam fazer uma distinção clara entre os bots bons e os mal-intencionados. Visando ser aceita pelo AD&D, a tecnologia RASP (Runtime Application Self Protection) é vulnerável a alguns ataques. A negação de serviço é apenas um exemplo.
ii. Do ponto de vista de um DevOps, a aplicação de uma execução de segurança é arriscada. Ela pode afetar a experiência do usuário ou até mesmo interromper o fluxo, causando erros de tempo de execução. O ciclo de vida do desenvolvimento de software (SDLC) tem muitos pontos cegos na segurança, especialmente nas arquiteturas híbridas e com várias nuvens de hoje. Justamente por isso, muitas tecnologias trazem alertas, o que é ótimo.
3. A segurança “eficaz” precisa proteger
Há uma certa fadiga de ferramentas que fornecem apenas visibilidade. Testes de segurança automatizados, scanners de vulnerabilidades de servidores da Web, sistemas operacionais e até imagens de contêineres não são suficientes para a execução real, fazendo o desenvolvedor dar alguns passos para trás para corrigir. Quando alguns alertas chegam em massa, fica muito mais difícil priorizar e abordar todos eles.
Uma versão lançada é caso encerrado para as equipes de desenvolvimento até o momento em que um membro da equipe de segurança diz para você corrigir uma vulnerabilidade. Se puder detectá-la, bloqueie. Lembre-se de detectar todos os tipos de ameaças. Ninguém quer várias soluções pontuais, porque isso não gera, necessariamente, uma postura de segurança mais robusta.
4. A segurança “eficaz” precisa continuar eficaz
A natureza dinâmica de um SDLC ágil, com mudanças frequentes e atualizações diárias no aplicativo, pode tornar as políticas de segurança menos precisas a cada dia. Este processo não é escalável e exige um FTE para trabalhar em atualizações de regras, listas de permissões e processamento de exceções.
Leia mais sobre a Segurança “dev-friendly” da Radware e o Mecanismo automático de geração e otimização de políticas.
