Uma vez nunca é suficiente: a necessidade de realizar Pentests contínuos

 Se você pesquisar no Google “Com que frequência devo fazer testes de penetração?”, a primeira resposta que aparece é “uma vez por ano”. De fato, mesmo os padrões líderes do setor, como o PCI-DSS, determinam que o teste de penetração externo seja realizado anualmente (ou após alterações significativas na infraestrutura ou nos aplicativos), enquanto o teste de penetração interno ocorre anualmente, com testes de segmentação ocorrendo a cada seis meses.


No entanto, os cibercriminosos de hoje não trabalham em horários anuais. Eles não esperam até que o tempo de teste da caneta chegue e as vulnerabilidades encontradas sejam corrigidas. Eles atacam rápido, atacam com força e usam ferramentas avançadas e automatizadas com inteligência artificial para explorar vulnerabilidades que muitas organizações nem sabem que existem, muito menos que existem em suas próprias redes . O Gartner chama essas ameaças de “ameaças de alto impulso ” e recomenda que as organizações em risco adotem uma abordagem mais simplificada à segurança cibernética – incluindo testes de caneta.


Enfrentar os desafios dos cibercriminosos ágeis requer uma abordagem muito mais ágil para testes de caneta. Veja por que e o que pode ser feito:


A necessidade de ciclos mais rápidos

Os padrões estão alcançando o ritmo do cibercrime. De acordo com o NIST Cyber ​​Security Framework (CSF), as organizações devem verificar se corrigiram vulnerabilidades após cada atualização do sistema ou implantação de patches. No entanto, na prática, isso não acontece com frequência. A razão? Economia simples. O teste de caneta tradicional consome muitos recursos e, portanto, é caro. Pen testers qualificados estão em alta demanda e cobram muito por seus serviços. Um único teste de caneta pode facilmente custar dezenas de milhares de dólares para apenas uma parte do ambiente de TI de destino. Poucas organizações têm esse tipo de orçamento – e certamente não o tipo de orçamento necessário para dimensionar testes de caneta em todo o ambiente na frequência necessária para garantir que as redes permaneçam seguras à medida que novos sistemas, usuários e aplicativos são atualizados ou adicionados.


A necessidade de automação

A atitude tradicional em relação ao teste de caneta manual é como a abordagem tradicional à navegação de direção: nada pode substituir a sofisticação e o conhecimento acumulado de um ser humano. Um motorista de táxi sempre vencerá o Google Maps, e um profissional de teste de caneta treinado encontrará vulnerabilidades e ataques que os testes automatizados podem perder ou identificará respostas que parecem legítimas para software automatizado, mas na verdade são uma ameaça.


A verdade é que, caso a caso, isso pode ser verdade . Mas com ferramentas e serviços prontos para uso como RaaS (Ransomware as a Service) ou MaaS (Malware as a Service) que usam recursos de IA/ML para aumentar a eficiência do ataque – você precisaria de um exército de pen testers para realmente atender às desafios das ameaças cibernéticas de hoje. E depois de encontrá-los, treiná-los e empregá-los – os ciberataques simplesmente aumentariam seus esforços de automação e você precisaria recrutar outro exército . Não é um modelo sustentável de segurança cibernética, claramente.


Da mesma forma, a adoção em larga escala de metodologias de desenvolvimento ágil se traduziu em lançamentos de software cada vez mais frequentes. Como os ambientes estão em constante evolução, os resultados dos testes de penetração realizados em versões mais antigas ou de pré-lançamento rapidamente se tornam obsoletos. E o ágil frequentemente depende de código aberto e outros pedaços de código prontos – que são altamente propensos a vulnerabilidades.


Por todas essas razões, as partes interessadas em testes de caneta estão cada vez mais se voltando para a automação, com o objetivo de obter uma validação de segurança contínua .


A necessidade de continuidade

Metodologias tradicionais de pen testing – tanto manuais quanto automatizadas – fornecem um instantâneo de sua postura de segurança de rede ou aplicativo. No entanto, conforme discutido acima, os ambientes são altamente dinâmicos, tornando a superfície de ataque um trabalho constante em andamento. Quando uma nova API é conectada, um novo servidor adicionado ou uma nova versão lançada – esse instantâneo não é mais válido, mesmo que a próxima rodada de testes de caneta seja daqui a um ano.


Para combater isso, as organizações estão migrando para um modelo de teste de penetração contínuo . Em vez de apenas um teste por ano, essas organizações adotam ferramentas e metodologias que podem testar seu ambiente continuamente. Como os agentes de ameaças visam as organizações continuamente para descobrir e explorar novas vulnerabilidades, não há alternativa para adotar uma abordagem mais proativa para descobrir e remediar vulnerabilidades. As avaliações de segurança point-in-time tradicionais simplesmente não conseguem acompanhar.


A linha de fundo

As ameaças cibernéticas tornaram-se mais ágeis, mais escaláveis ​​e infinitamente mais perigosas. O teste de caneta manual e periódico tradicional simplesmente não pode oferecer às organizações a segurança de que necessitam para sobreviver. Somente um modelo automatizado e contínuo pode proteger redes e aplicativos em constante mudança – ajudando as empresas que os adotam a permanecerem seguras, em conformidade e lucrativas.

0 Comentários

Red Hat contrata um engenheiro de software cego para melhorar a acessibilidade no desktop Linux

A Red Hat está contratando um engenheiro de software cego para ajudar nos refinamentos de acessibilidade no GNOME, Fedora e RHEL. A acessibilidade em um desktop Linux não é um dos pontos mais fortes a serem destacados. No entanto, o GNOME, um dos melhores ambientes de desktop , conseguiu se sair melhor comparativamente (acho). Em uma postagem no blog de Christian Fredrik Schaller (Diretor de Desktop/Gráficos, Red Hat), ele menciona que eles estão fazendo sérios esforços para melhorar a acessibilidade. Começando com a contratação de Lukas Tyrychtr pela Red Hat , que é um engenheiro de software cego para liderar o esforço para melhorar o Red Hat Enterprise Linux e o Fedora Workstation em termos de acessibilidade. Entre os detaques Estado de acessibilidade no GNOME Enquanto eu mencionei que o GNOME conseguiu ter um suporte de acessibilidade decente no passado, Christian menciona o que aconteceu ao longo dos anos: O primeiro esforço conjunto para oferecer suporte à acessibilidade no Linux