0
0
Sua empresa depende de software, e os atacantes sabem disso. Para evitar que seus aplicativos sejam usados contra você, você precisa de um programa de segurança de aplicativos (AppSec) que ofereça três coisas cruciais:
- Código seguro: Seu código deve ser livre de vulnerabilidades e bem defendido.
- Cadeia de suprimentos de software segura: Idem para suas bibliotecas, produtos e ferramentas de desenvolvimento.
- Operações seguras: Você deve detectar ataques e evitar explorações em produção.
Você pode escolher vários caminhos para chegar a esse nível de proteção. O caminho que você escolher depende de suas equipes, processos, tecnologia e cultura. Como todos eles trabalham juntos? Tenha em mente que um programa AppSec não é sobre eliminar o risco. Os negócios envolvem assumir riscos, e não há como erradicá-los completamente. Mas há uma grande diferença entre assumir riscos cegos sem saber o que pode dar errado vs. estar ciente da probabilidade de que um problema seja encontrado e explorado, bem como quão catastróficos (ou não) os resultados podem ser.
Quando se trata de decisões de risco, escolher uma estratégia para o seu programa AppSec é a mais importante que você enfrentará. A configuração de um programa AppSec é diferenciada e variada, mas considere qual dos três tipos gerais a seguir se adapta melhor à sua empresa. O caminho errado poderia deixá-lo com um peso enorme da dívida de segurança, ou mesmo possivelmente violado, porque o tempo foi desperdiçado perseguindo vulnerabilidades que não eram todos os riscos relevantes e reais que foram enterrados na pilha de “nunca chegou a isso”.
1. O Auditor: Caixa de Seleção AppSec
Nos programas “mínimos” do AppSec, pequenas equipes fazem apenas o que é exigido deles por padrões externos ou por seus clientes. O objetivo é simplesmente marcar as caixas para padrões de segurança de aplicativos como OWASP, PCI e NIST, todos os quais são, essencialmente, listas de verificação. Muitos tipos de empresas adotam essa estratégia — mais comumente, pequenas e médias empresas — mas as listas de verificação não lhes trazem segurança real.
Não é que os programas mínimos do AppSec nunca tenham sucesso. Eles podem, confiando em ferramentas gratuitas ou muito baratas, como OWASP ZAP e DependencyCheck, para avaliar o código. Um firewall de aplicativos da web em nuvem (WAF) barato para produção também pode estar na mistura. Mas essas ferramentas podem mostrar falsos negativos que perdem vulnerabilidades reais, dando às organizações uma falsa sensação de segurança. Tais ferramentas também tendem a lançar falsos positivos que levam ao desperdício de recursos e enormes atrasos em vez de remediação real.
Uma vantagem de ter um programa AppSec mínimo é que o orçamento para pessoas e ferramentas tende a ser pequeno. Mas como os programas mínimos do AppSec não oferecem uma compreensão clara do risco de negócios, as organizações estão subinvestindo em segurança corporativa com base em informações incompletas.
2. O Advogado: Adversial AppSec
Em programas AppSec conflituosas, a equipe de desenvolvimento tenta entregar o código o mais rápido possível enquanto a equipe de segurança em siloada luta pelo controle. O desenvolvimento se concentra em fornecer recursos, enquanto a equipe de segurança tenta adicionar mais atividades de segurança. As grandes empresas tendem a adotar essa abordagem, assim como setores críticos, como finanças, bancos, comércio eletrônico e seguros.
Essa abordagem requer uma grande equipe de segurança para executar todas as atividades. A maioria tem várias subequipes focadas em arquitetura, políticas, modelagem de ameaças, políticas, varredura estática, varredura dinâmica, WAFs, treinamento e muito mais. Os programas contraditórios sempre têm mais análises a fazer, mas as equipes de segurança na verdade não corrigem o código nesse tipo de programa. As organizações geralmente adotam programas de “campeão” para ajudar a fazer todo o trabalho. Mas sem uma linha de visão clara dos resultados desejados das atividades, grande parte do trabalho ocupado tem pouco ou nenhum efeito mensurável.
Dada uma equipe grande o suficiente e um grande orçamento, os programas contraditórios do AppSec podem ser eficazes. Mas a maioria dos programas luta para lidar com o volume de saída da ferramenta, especialmente à medida que as equipes de desenvolvimento aceleram suas versões de software. A maioria das vulnerabilidades acaba em uma pilha cada vez maior de problemas que não são classificados nem corrigidos. As equipes de desenvolvimento são confrontadas com atrasos e gargalos significativos devido a esses atrasos, que são combinados com testes de segurança e portões. A inovação sofre por causa desses atrasos, que causam frustração e forçam as equipes de desenvolvimento a buscar exceções e contornar a segurança.
3. O Desenvolvedor: Developer-Centric AppSec
Os programas AppSec centrados no desenvolvedor se esforçam para colocar a segurança dos aplicativos diretamente nas mãos das equipes de desenvolvimento de software como parte de seu trabalho regular. O objetivo: que as equipes finalmente estabeleçam um pipeline automatizado que garanta forte segurança em todo o ciclo de vida do desenvolvimento de software, começando com o desenvolvedor e entrando em produção. Esse tipo de programa é frequentemente chamado de “DevSecOps” ou “desloca à esquerda“.
Os programas DevSecOps usam a “grande maquinaria” do desenvolvimento de software para fazer o trabalho de segurança, em oposição a equipes AppSec menores e siloadas. Dado que os desenvolvedores não toleram a desaceleração dos pipelines ou a percoria tempo com falsos positivos, as equipes de desenvolvedores automatizam os testes de segurança em pipelines, usando ferramentas rápidas e altamente precisas que permitem loops rápidos de feedback de segurança e reduzem custos.
Os programas centrados no desenvolvedor empregam ferramentas interativas de teste de segurança de aplicativos (IAST) para executar simultaneamente testes de segurança e qualidade totalmente automatizados. Isso alinha os interesses de desenvolvimento e segurança, à medida que as equipes trabalham juntas para expandir a cobertura de testes e fortalecer o pipeline. A visibilidade dos ataques com autoproteção de aplicativos em tempo de execução (RASP) também fornece às equipes inteligência contra ameaças que informa as prioridades de segurança. A tecnologia RASP evita que as vulnerabilidades sejam exploradas, permitindo que as equipes respondam a novas vulnerabilidades sem ter que executar uma simulação de incêndio.
A abordagem centrada no desenvolvedor é ideal para projetos, independentemente do estágio na transformação de DevOps. Dito isto, essa abordagem pode não ser capaz de aproveitar os pipelines automatizados, a infraestrutura de testes de qualidade e a cultura DevOps se aplicada a projetos completamente tradicionais. Então, novamente, adotar uma abordagem de segurança centrada no desenvolvedor pode ser o catalisador perfeito para desencadear ou acelerar uma transformação de DevOps.
A segurança do software mudou
Inspirados por incidentes como SolarWinds, Log4Shell e Spring4Shell, os governos do mundo foram pressionados a fazer algo sobre a segurança dos aplicativos. Novos regulamentos e padrões do NIST, PCI e OWASP exigem uma abordagem mais sofisticada ao AppSec e evidências reais de que o que você está fazendo é realmente eficaz.
Aqueles que empregam um programa AppSec “mínima” ou “conversário” provavelmente terão que responder fazendo algumas alterações, incluindo:
- Modelagem de ameaças: Os dias das listas de verificação acabaram. Você precisará modelar seus aplicativos de ameaças e, em seguida, demonstrar que implementou controles decentes para cada um.
- AST: Também será esperado que você faça um trabalho muito mais completo de testar a segurança de seus aplicativos e APIs. Você terá que fornecer evidências de que está testando a eficácia de suas defesas e corrigindo quaisquer problemas encontrados.
- SBOMs: Para realmente lidar com seu uso de código aberto, você provavelmente precisará de sensores que relatem dados da biblioteca para um banco de dados sempre atualizado. Mas, enquanto isso, você também precisará gerar listas de materiais de software (SBOMs) para seus clientes.
Tenha em mente que, se você decidir mudar sua abordagem, transformar uma equipe de cada vez provavelmente é preferível a tentar mudar tudo de uma só vez.
A tendência para uma segurança de aplicativos mais transparente que vai além de simplesmente marcar caixas provavelmente não vai parar por aqui. O governo dos EUA, por exemplo, está avaliando um esquema de rotulagem de segurança de software para criar visibilidade e aumentar a segurança dos produtores. Resta saber se isso se torna realidade, mas uma coisa é segura dizer: agora é um bom momento para ter certeza de que você escolheu a estratégia certa para a segurança de aplicativos.
FONTE: DARK READING