Bem-vindo ao nosso blogue.

GHENT, 14 de novembro de 2023

A Aikido Security, o primeiro aplicativo de segurança de software para desenvolvedores para empresas SaaS em crescimento, anuncia hoje que levantou € 5 milhões em uma rodada de sementes co-liderada pela Notion Capital e Connect Ventures; com investimento do Inovia Capital Precede Fund I, liderado pelos parceiros Raif Jacobs e o ex-CFO do Google Patrick Pichette; bem como uma lista impressionante de investidores anjos, incluindo Christina Cacioppo, CEO da Vanta.

O investimento será canalizado para o desenvolvimento da funcionalidade do software, em especial para garantir que a experiência do utilizador e a auto-triagem do Aikido são as melhores da sua classe, mantendo ao mesmo tempo a simplicidade do produto; para a contratação de pessoal para as equipas de produto, desenvolvimento, marketing e vendas; e para o aumento da base de clientes do Aikido, com especial incidência na solidificação e expansão da sua já forte posição na Europa e na América do Norte.

Como explica o CEO e CTO da Aikido, Willem Delbare, "as empresas de SaaS que estão a construir a sua plataforma, muitas vezes "protegem" o seu novo software instalando inúmeras ferramentas dispersas. Isto pode gerar muito ruído para os programadores e lançar uma miríade de "falsos positivos" díspares, que requerem atenção, mas não representam uma ameaça real. Isto representa um enorme fardo para o pessoal que gere a segurança da plataforma. O problema só é exacerbado pelo crescimento - que pode acontecer rapidamente no SaaS - criando enormes dores de cabeça para o pessoal responsável pela segurança."

A Delbare continua : "Em alternativa, se as startups optarem por não instalar estas ferramentas, podem adotar soluções de software de segurança dispendiosas que apenas cobrem alguns factores da segurança das aplicações. As empresas ficam então com enormes lacunas na segurança do seu software, apesar do seu investimento. Devido ao seu custo, os scanners de vulnerabilidades são maioritariamente adaptados às grandes empresas, ficando as PME e as empresas de média dimensão sem uma solução viável para a segurança da sua plataforma em crescimento."

A Aikido tem a missão de simplificar a segurança SaaS com a sua ferramenta tudo-em-um que consolida várias funcionalidades de segurança de aplicações. Em vez de soluções desarticuladas, esta abordagem unificada aumenta o controlo e reduz significativamente os falsos positivos. Até à data, a empresa poupou mais de 1500 dias de trabalho aos programadores que, de outra forma, seriam gastos em falsos positivos. O Aikido classifica as vulnerabilidades por gravidade, garantindo que os problemas críticos são tratados em primeiro lugar. Além disso, todos os dados de segurança permanecem na plataforma, garantindo a segurança independentemente das mudanças de pessoal e ajudando na continuidade do negócio.

Delbare continua: "Ao longo da minha carreira, criei várias empresas de SaaS e perdi centenas de horas a juntar uma manta de retalhos de ferramentas necessárias para proteger uma nova plataforma. Quando criei a Aikido, vi uma forma melhor de identificar violações críticas e, ao mesmo tempo, reduzir os "não problemas" que fazem perder tempo aos engenheiros. Somos a única empresa na Europa a fazer isto, demonstrando uma energia renovada para as empresas em fase de arranque no continente. Os nossos clientes incluem agora startups, bem como empresas que cresceram para mais de 300 programadores - o que resultou em mais de 1000 instalações totais em apenas um ano - uma raridade no mundo das novas soluções SaaS. Olhando para o futuro, queremos superar os nossos concorrentes, oferecendo uma solução adaptada àqueles que ainda não encontraram um produto que satisfaça as suas necessidades."

Kamil MieczakowskiPartner da Notion Capital, afirma: "À medida que aumenta a pressão sobre as pequenas e médias empresas para demonstrarem níveis cada vez maiores de ciber-resiliência, o panorama das ferramentas de segurança disponíveis continua a apresentar desafios, caracterizados pela fragmentação, complexidade e custo. O Aikido fornece uma solução de ponta a ponta poderosa e fácil de utilizar para a segurança do código e da nuvem, permitindo que qualquer empresa se proteja a si própria e aos seus clientes através de uma única ferramenta capaz de transformar cada programador num perito em segurança. Apesar de ter apenas um ano de existência, a empresa já está a crescer rapidamente e estamos entusiasmados por apoiá-la nesta trajetória emocionante, juntamente com os nossos amigos da Connect Ventures e um grupo incrível de investidores-anjo e consultores."

Pietro Bezzacofundador e sócio-gerente da Connect Ventures, afirma: "Neste novo mundo do software b2b, as empresas procuram produtos SaaS que combinem eficácia com eficiência, relação qualidade-preço, simplicidade e concentração. Estamos na era do Great Bundle. Impulsionados pela necessidade de eficiência, os clientes estão a consolidar software de solução pontual em conjuntos de software de pilha completa. A plataforma tudo-em-um da Aikido para a segurança do software enquadra-se extremamente bem neste novo quadro. Não podíamos estar mais entusiasmados por apoiar Willem, Roeland e Felix na democratização do acesso às melhores ferramentas de segurança para todas as empresas, independentemente do seu tamanho e orçamento."

O Aikido oferece a forma mais rápida para uma empresa SaaS em crescimento proteger a sua plataforma. A aplicação permite uma integração rápida e orientada para o cliente, com uma visualização instantânea de todas as vulnerabilidades críticas a resolver - normalmente em apenas alguns minutos - dando aos utilizadores tempo para se concentrarem nas funções essenciais da empresa. Com uma redução de ruído de nível mundial, o Aikido é capaz de reduzir enormemente o número de falsos positivos. Adopta uma abordagem "shift left", cujo objetivo é evitar que os problemas de segurança entrem no código, o que significa que, se algo correr mal durante o processo de desenvolvimento, pode ser corrigido antes de ocorrer qualquer violação ou de o código chegar à produção.

Concebido para empresas SaaS, o Aikido é um componente crucial para cumprir as normas críticas de conformidade da indústria, incluindo SOC2, ISO 27001, CIS, HIPAA e a futura Diretiva Europeia NIS 2.

Acerca do Aikido Security
O Aikido é uma solução tudo-em-um que reúne vários aspectos da segurança das aplicações numa plataforma intuitiva. Esta abordagem inclusiva proporciona um maior controlo aos utilizadores finais, reduzindo drasticamente o número de falsos positivos durante as verificações de segurança. A Aikido foi fundada por Willem Delbare (ex-fundador da Teamleader e Officient), Roeland Delrue (ex-Showpad) e Felix Garriau (ex-Nexworks) e é apoiada pela Notion Capital, Connect Ventures e Syndicate One.

Temos o orgulho de anunciar que a Aikido Security obteve recentemente a certificação ISO 27001:2022. Este é um grande marco para nós e demonstra o nosso compromisso com a segurança da informação.

O que é a norma ISO 27001:2022?

A ISO 27001 é uma norma reconhecida mundialmente para o estabelecimento e certificação de um Sistema de Gestão de Segurança da Informação (ISMS). A versão 2022 desta certificação garante que a Aikido Security está alinhada com as melhores práticas actuais na gestão da segurança da informação. Escolhemos especificamente a versão 2022 (em vez das versões 2013 e 2017), uma vez que esta nova versão se centra mais na codificação segura, na deteção de ameaças, etc. Estes são itens que consideramos importantes e relevantes para uma empresa de software.

A obtenção da conformidade com a norma ISO 27001:2022 é um feito significativo para a Aikido Security. Sublinha a nossa dedicação em fornecer soluções seguras e fiáveis aos nossos clientes.
Willem Delbare, CEO da Aikido Security

O que motivou o Aikido a procurar a certificação ISO 27001?

Somos uma empresa desafiante no sector da segurança e uma das primeiras coisas que pedimos aos novos clientes é que nos dêem acesso de leitura à sua base de código. Isso é muito importante. E nós compreendemos - e concordamos - que é uma grande coisa.

Para que os clientes nos confiem confortavelmente a sua base de código, têm de confiar em nós como empresa e no nosso produto. A conformidade com a norma ISO27001 é um enorme passo em frente na construção e comprovação dessa confiança.

O que aprendemos no caminho para a conformidade com a ISO 27001

Numa futura publicação no blogue, apresentarei as minhas principais aprendizagens, mas quero aproveitar esta oportunidade para partilhar algumas ideias breves sobre a nossa viagem.

O nosso percurso ISO 27001:2022

Concluímos todo o processo em cerca de seis meses. Tínhamos implementado anteriormente o SOC 2, pelo que já dispúnhamos de muitas políticas, documentos e melhores práticas. Isto permitiu-nos reutilizar e aplicar muito disso à nossa ISO.

Porque acreditamos firmemente na utilização da ferramenta certa para o trabalho, aproveitámos a oportunidade para adotar uma abordagem moderna e utilizámos o Vanta, que automatiza muito do trabalho necessário para obter a ISO 27001.

A obtenção da ISO 27001:2022 exige paciência e empenho. É essencial rodear-se de parceiros fiáveis e reunir conhecimentos antecipadamente.
Roeland Delrue, COO & CRO da Aikido Security

O processo de alto nível

1. Auditoria interna (pré-auditoria)

Pode pensar na auditoria interna como um "ensaio geral" ou "auditoria simulada", para se certificar de que está pronto para efetuar as auditorias "reais". A auditoria interna certifica-se de que não lhe escapou nada de óbvio que não possa corrigir nas fases posteriores.

Dica rápida: Utilize um bom pré-auditor interno ou externo. Isto ajuda-o realmente a preparar-se corretamente. A menos que tenha experiência relevante e comprovada em ISO, é provavelmente melhor contratar um pré-auditor externo. Tirar partido da sua experiência revelar-se-á muito valioso.

2. Auditoria da fase 1

A fase 1 é, em grande medida, uma "auditoria de mesa" ou uma análise da documentação
Esta auditoria consiste numa análise exaustiva da documentação. Um auditor externo da ISO 27001 analisa as políticas e os procedimentos para garantir que cumprem os requisitos da norma ISO e do Sistema de Gestão da Segurança da Informação (SGSI) da própria organização.

3. Auditoria da fase 2

A fase 2 é uma auditoria completa do sistema com muitos testes de controlo
O auditor efectua testes para verificar se o Sistema de Gestão da Segurança da Informação (SGSI) foi corretamente concebido e implementado e se está a funcionar corretamente. O auditor também avalia a justiça e a adequação dos controlos da organização para determinar se os controlos foram implementados e estão a funcionar eficazmente para cumprir os requisitos da norma ISO 27001.

4. Certificação

Depois de ter remediado ou elaborado um plano de ação para as suas não-conformidades, está pronto para a validação. As não-conformidades da ISO 27001 são categorizadas como menores, maiores ou oportunidades de melhoria (OFIs). É claro que é fundamental mostrar que você corrigiu ou pode mostrar claramente que está no caminho certo para corrigir todas as não-conformidades maiores.

E depois... está na hora de receber o vosso certificado 🎉🥳

Quanto tempo é necessário para estar em conformidade com a norma ISO 27001?

Não é possível fazê-lo em menos de dois meses. E isso pressupõe que tem tudo pronto para o fazer, incluindo um pentest e um auditor.

Mesmo assim, poderá necessitar de alguns meses para se certificar de que se depara com eventos de segurança da informação suficientes, uma vez que alguns processos só podem ter lugar quando ocorre um determinado evento (por exemplo, a integração ou a saída de um empregado).

Também tem de mostrar que pode remediar as não-conformidades e demonstrar que é capaz de recolher provas. Este processo envolve a identificação do evento, o registo e a classificação do mesmo e a documentação exaustiva do evento de segurança da informação.

Quanto custa tornar-se compatível com a norma ISO 27001?

Dependendo da profundidade da pré-auditoria e do pentest, todo o processo custará normalmente entre 20 000 e 50 000 USD.
Terá de pagar o seguinte:

• Pré-auditor
• Pentest (pode ser aproveitado de outras acções de conformidade, por exemplo, se já estiver a fazer um para o SOC 2)
• Licença da plataforma de conformidade (recomendamos vivamente a sua utilização)
• Auditor
• Licenças de scanner de vulnerabilidades e/ou malware (por exemplo, Aikido Security)

O custo depende muito de vários factores, sendo os principais os seguintes:

• A dimensão da sua empresa (se tiver muitos empregados, processos, escritórios, programadores,... os custos de auditoria aumentam drasticamente)
• Custo do pentest (3 a 30 mil dólares, dependendo do tipo de pentest efectuado e de quem o realiza)
• Profundidade das auditorias
• Plataforma de conformidade (por exemplo, Vanta)

Gestão da vulnerabilidade técnica ISO 27001:2022

No seu próprio caminho para a certificação ISO27001:2022? A Aikido Security preenche todas as necessidades de gestão de vulnerabilidades técnicas para aplicações ISO 27001:2022. Também sincronizamos com Plataformas de Monitorização de Conformidade (como o Vanta) para garantir que a sua informação de vulnerabilidade está sempre actualizada. Isto significa que pode confiar numa avaliação de risco precisa e numa correção eficiente.

Solicitar o nosso relatório

Não hesite em solicitar o nosso próprio relatório ISO 27001:2022 diretamente no nosso centro de confiança.

A perder o sono a imaginar maus actores a infiltrarem-se no código da sua nova e fantástica empresa? Agora já não! A Aikido Security projetou a segurança de startups para ser acessível, eficiente e atender às necessidades dos CTOs. Vamos dar uma olhada em como a Aikido transformou a postura de segurança da StoryChief.

Adoramos ouvir as experiências dos nossos clientes e parceiros, especialmente no que diz respeito à segurança de startups. Falámos recentemente com o cofundador e CTO da StoryChief, Gregory Claeyssens, e ficámos entusiasmados por ouvir a sua história de sucesso com a Aikido Security. Neste caso de cliente, vamos analisar essa conversa para mostrar como o Aikido melhorou a postura de segurança do StoryChief. E, ao fazê-lo, como permitiu a Gregory algum equilíbrio entre trabalho e vida pessoal - também conhecido como dormir melhor à noite! (CTOs, apostamos que isso soa bem!)

💡 BTW, não se esqueça de descarregar o nosso caso de cliente StoryChief/Aikido no final desta publicação do blogue.

O que é o StoryChief?

Fundada em 2017 e sediada em Ghent, na Bélgica, a StoryChief é uma startup que oferece uma solução de marketing de conteúdos fácil de utilizar e tudo-em-um. A StoryChief permite que as agências de marketing e as equipas de conteúdos simplifiquem a sua produção e gestão de conteúdos. Ou, como diz a StoryChief, "acabar com o caos dos conteúdos".

A plataforma colaborativa e intuitiva da StoryChief inclui planeamento de conteúdos, distribuição, programação e ferramentas de escrita com IA. Ganhou uma atenção significativa. Notavelmente, o StoryChief levantou US $ 5.7 milhões em financiamento. Isso é uma prova de sua abordagem inovadora para fornecer soluções abrangentes de marketing de conteúdo. Atualmente, a StoryChief tem uma grande equipa de desenvolvimento dedicada. E, de forma envolvente, o seu logótipo é uma preguiça simpática!

💡 Saiba mais sobre a StoryChief e o que ela oferece visitando o seu sítio Web: https://www.storychief.io.

Desafios de segurança das empresas em fase de arranque

À medida que a StoryChief crescia, a gestão da segurança da sua base de código, repositórios e infra-estruturas tornava-se cada vez mais complexa. Gregory e a sua equipa viram-se numa posição difícil para se manterem à frente de potenciais vulnerabilidades de segurança.

Estar atrás da curva de segurança: A gestão da sua postura de segurança tornou-se cada vez mais preocupante. Gregory receava que pudesse estar a perder ou a ignorar algo crucial. Isso levou a stress e preocupações desnecessárias.

Utilização de ferramentas de segurança incompletas e dispendiosas: A StoryChief utilizava ferramentas de segurança que proporcionavam alguma paz de espírito. Mas havia dois obstáculos principais com elas. Elas não atendiam ao conjunto completo de requisitos de segurança de Gregory e não visavam as necessidades do CTO. Além disso, houve uma mudança inesperada no preço do principal fornecedor de ferramentas de segurança.

Sobrecarga de notificações: As notificações devem ser úteis e relevantes. No entanto, a utilização de várias ferramentas de segurança conduziu a uma sobrecarga de notificações. Isto conduziu a três resultados:

1. Algumas notificações careciam de informações contextuais e de exatidão,
2. Um número avassalador de notificações tornou-se ruído branco e, por conseguinte, ignorável (simplesmente não tinham valor).

Em suma, a ineficiência drenou recursos e tempo valiosos. Mas, apesar destes ventos contrários, Gregory geriu a segurança de forma eficaz e não registou nenhum incidente de segurança grave. No entanto, sentiu-se inquieto devido às limitações e aos custos das ferramentas existentes. Posteriormente, isto levou-o a procurar uma solução melhor.

Como a Aikido Security ajudou a melhorar a postura de segurança do StoryChief

A jornada da StoryChief para uma melhor postura de segurança levou-os à Aikido Security, que também permitiu à StoryChief fazer a transição de uma abordagem de segurança reactiva para uma proactiva.

Sem etiqueta de preço desagradável: A segurança das empresas em fase de arranque deve ser acessível e o Aikido tem um preço amigo das empresas em fase de arranque. Isto ofereceu à StoryChief uma solução económica. Ao mesmo tempo, a Aikido aumentou a sua confiança na sua postura de segurança graças aos dois benefícios seguintes.

Eu sou um CTO, não um engenheiro de segurança: As várias ferramentas que a StoryChief estava a utilizar destinavam-se principalmente a engenheiros de segurança. No entanto, ao contrário dessas ferramentas, o Aikido adapta as suas funcionalidades e regras às necessidades específicas dos CTO e dos programadores. O Aikido também fornece um fluxo contínuo de novas regras e funcionalidades especificamente concebidas para ajudar os CTO.

Diga-me quando é importante e relevante: Um dos principais pontos fortes do Aikido e da USP é a redução de falsos positivos. Os alertas direcionados do Aikido, por conseguinte, fornecem à StoryChief informações reais e acionáveis, em vez de notificações esmagadoras e ignoráveis.

Responsabilidade partilhada: Além disso, as notificações do Aikido são automaticamente partilhadas com a equipa de desenvolvimento através do Slack, promovendo a transparência e a responsabilidade partilhada pela segurança. Desta forma, o Aikido também proporcionou um resultado de trabalho em equipa. Ajudou Gregory a atingir o seu objetivo de criar um esforço mais centrado na equipa para gerir a postura de segurança.

StoryChief CTO resume o impacto do Aikido

"O Aikido era exatamente o que eu procurava há muito tempo - a combinação de funcionalidades, o facto de se centrar nas empresas em fase de arranque e o preço de entrada. O Aikido sensibilizou a equipa para as questões de segurança. Criou um sentido de responsabilidade partilhada, envolvendo todos na manutenção da nossa postura de segurança."

O Aikido como seguro de segurança para empresas em fase de arranque

Aikido Security é como uma apólice de seguro para a segurança do StoryChief. Oferece orçamento e precisão. Aikido também oferece um foco claro no que realmente importa para Gregory e sua equipa. Com o Aikido, a StoryChief não só melhorou a sua postura de segurança, como também capacitou a equipa do CTO para assumir a responsabilidade e trabalhar de forma transparente. O Aikido fornece a consolidação ordenada e a priorização das informações necessárias para tratar de questões de segurança.

Mais importante ainda, deu a Gregory um elevado nível de confiança na segurança do produto:

"Há sempre vulnerabilidades - é normal - mas com o Aikido pelo menos eu sei! Tenho uma ideia muito boa da nossa postura de segurança".

Descarregar o caso de cliente da StoryChief

Faça o download da sua própria cópia do caso de cliente do StoryChief X Aikido Security:

É muito provável que já tenha ouvido falar de "CVE", que significa Common Vulnerabilities and Exposures (vulnerabilidades e exposições comuns). Os CVEs são listados numa enorme base de dados que regista os problemas de segurança informática conhecidos. Isto permite um acesso e uma referência fáceis. Assim, se ouvir alguém falar de um CVE - ou de um registo CVE - isso significa que a falha de segurança é conhecida e já foi catalogada.

O objetivo do rastreio de CVEs é o seguinte: a partilha e a catalogação de falhas de segurança conhecidas permite que o pessoal da cibersegurança dê prioridade e lide com as vulnerabilidades, tornando a nuvem, o código e qualquer outro sistema de TI mais seguro.

Basicamente, o sistema CVE proporciona uma linguagem comum e um ponto de referência. Mas - e este é o grande "mas" - tenha em conta que o meu problema pode não ser o seu problema!

Quem mantém a base de dados CVE?

A corporação MITRE supervisiona o sistema CVE e todos os registos CVE são gratuitos para pesquisa e utilização pelo público. A Cybersecurity and Infrastructure Security Agency (CISA) ajuda a fornecer financiamento. As entradas CVE são curtas e simples - não há dados técnicos profundos aqui. As entradas CVE também não comentam as correcções, os riscos e os impactos. Os pormenores mais importantes são registados noutras bases de dados. Alguns exemplos incluem a Base de Dados Nacional de Vulnerabilidades dos EUA (NVD) e a Base de Dados de Notas de Vulnerabilidade CERT/CC.

Qual é o aspeto de uma ID CVE?

Um ID CVE é como um número de série. Quando se olha para uma entrada CVE, vê-se o ID CVE, que tem o seguinte aspeto: "CVE-YYYY-#####".

O que inclui um registo CVE?

Um registo CVE inclui as seguintes informações:

• ID CVE
• Descrição
• Referências
• Atribuição de CNA
• Data de criação do registo

Os registos CVE também incluem alguns elementos antigos, que não são relevantes para as novas entradas: fase, votos, comentários, propostas.

Como é que encontram vulnerabilidades e exposições?

Qualquer pessoa pode comunicá-los, desde uma empresa de tecnologia a um utilizador curioso. Algumas até oferecem prémios para quem encontrar e comunicar estes problemas. Se se tratar de software de código aberto, o que importa é o apoio da comunidade.

Quando uma vulnerabilidade é comunicada, um CNA atribui-lhe um ID CVE, escreve uma breve descrição e acrescenta algumas referências. Depois, é publicado no sítio Web do CVE. Por vezes, até obtêm uma ID antes de o problema se tornar público. Mantém os maus da fita à distância.

Agora, nem todas as edições recebem um CVE. Claro que há regras! Aplicam-se três critérios principais:

1. Independentemente corrigível. Isto significa que a falha é corrigível, independente e irrelevante para outros erros.
2. Reconhecido pelo fornecedor. Isto significa que o fornecedor reconhece que a falha existe e que pode afetar negativamente a segurança. Outra opção é ter um relatório de vulnerabilidade compartilhado que inclua uma descrição do impacto negativo do bug e como ele viola a política de segurança do sistema.
3. Afecta apenas uma base de código. Se afetar mais do que um produto, estes recebem CVEs separados. A ideia é criar registos CVE com o máximo de isolamento possível.

Como posso encontrar registos CVE?

Em primeiro lugar, as informações do CVE são gratuitas e estão à disposição do público. Por isso, é uma boa notícia.

A forma mais fácil de encontrar os CVEs mais recentes é seguir @CVEnew no X. Este feed está constantemente a ser atualizado com tweets sobre vários CVEs novos todos os dias. Ainda ontem dei uma olhada e havia mais de 80 novos CVEs! Se o seguires, o teu feed estará cheio deles!

E que tal uma forma mais completa de encontrar registos CVE anteriores? Se quiser todos os registos desde 1999 ou de um determinado ano, ou mesmo pesquisar por tópico, basta ir a CVE.org/Downloads. Os ficheiros em massa estão agora no formato JSON 5.0 e podem ser descarregados através de um repositório GitHub. (Nota: o sistema de arquivo anterior ficará indisponível em 1 de janeiro de 2024).

A CVEdetails.com tem uma versão em linha da base de dados fácil de utilizar - com actualizações diárias!

Como fazer corresponder as suas bibliotecas ao CVE correto?

Ao analisar uma vulnerabilidade, pretende obter o CVE correto. Para se certificar de que tem o CVE correto, a melhor prática é verificar o número da versão e o nome do pacote. Existem muitas ferramentas, como o Trivy, que fazem isso automaticamente para você. (O Aikido utiliza o Trivy para algumas destas funcionalidades).

Sistema comum de pontuação de vulnerabilidades - CVSS

O NVD e outros utilizam o Common Vulnerability Scoring System (CVSS), que determina a gravidade de uma vulnerabilidade ou exposição. É como um boletim de notas para problemas de segurança, variando de 0,0 (nada de mais) a 10,0 (grande problema). Assim, cada entrada CVE tem uma pontuação CVSS.

Como é calculada uma pontuação CVSS?

A pontuação CVSS é calculada através de uma fórmula baseada em métricas de vulnerabilidade. Uma pontuação CVSS resulta de pontuações destas três áreas: Base, Temporal e Ambiental. A pontuação Base é obrigatória e o ponto de partida e tem subescores de impacto e explorabilidade. Depois, a pontuação Temporal pode ser calculada a partir da Base. A seguir, a pontuação Ambiental pode ser calculada a partir da Temporal. Estes cálculos conduzem à pontuação CVSS global.

Algo para os geeks das fórmulas! Veja como funciona o sistema de pontuação e a calculadora CVSS. Descubra quais são os cálculos e que métricas precisas criam cada pontuação. Vetor de ataque! Anexar complexidade! Muita diversão!

O que é a escala de pontuação CVSS?

A escala de pontuação CVSS atual (v3.1) inclui cinco categorias:

• 9.0 - 10.0 = Crítico
• 7,0 - 8,9 = Elevado
• 4,0 - 6,9 = Médio
• 0,1 - 3,9 = Baixo
• 0,0 = Nenhum

Descarregue uma cópia do guia do utilizador do sistema de pontuação CVSS completo.

Como posso encontrar uma pontuação CVSS para um registo CVE?

Isto é fácil! Quando estiver na base de dados em linha, cada página de registo CVE tem uma ligação para a pontuação CVSS do NVD. Basta clicar e pronto! Por exemplo, utilizando o CVE-2023-40033 referido anteriormente neste post, quando clicamos em "CVSS scores" (canto superior direito do registo) ficamos a saber que esta vulnerabilidade tem uma pontuação de 7.1 (Alta).

O que é uma CWE?

A Common Weakness Enumeration, ou CWE, é uma lista de pontos fracos comuns de software e hardware. A CWE é um recurso desenvolvido pela comunidade e fornece padronização para o tipo e o escopo dos pontos fracos.

Citando o MITRE, "o principal objetivo do CWE é acabar com as vulnerabilidades na fonte... para eliminar os erros mais comuns antes de os produtos serem entregues". O CWE também oferece aos programadores uma estrutura para discussão e ação contra as ameaças à segurança, ao mesmo tempo que mapeia as bases de dados de vulnerabilidades (por exemplo, CVE).

Em que é que isso difere do CVE? O CWE concentra-se na fraqueza subjacente que pode levar a uma vulnerabilidade. Entretanto, o CVE descreve as vulnerabilidades reais. Tal como o CVE, o CWE também tem uma pontuação de gravidade através do CWSS e do CWRAF.

Veja as 25 CWEs mais perigosas para 2023.

O que posso fazer para manter uma postura de segurança forte?

Não siga cegamente as pontuações CVSS para definir as suas prioridades de segurança

Todos os CVEs são um problema para si? Não. São informações, mas como muitas informações, nem todos os CVEs serão relevantes para o seu contexto. E, mesmo para aqueles que parecem ser, há muitas situações em que mesmo os CVE com pontuações CVSS elevadas podem não ser relevantes ou um risco para si:

1. Nível de impacto nos negócios: Uma vulnerabilidade, apesar de ter uma pontuação CVSS elevada, não representa um risco significativo para as operações comerciais específicas da organização, para os dados dos clientes ou para o sistema crítico. Ou, uma avaliação de risco ou outra ferramenta determina que outros factores (por exemplo, uma função não é acessível) superam a pontuação CVSS em importância.
2. Sistemas únicos: Ao utilizar software personalizado ou exclusivo, as pontuações CVSS podem não refletir com precisão o risco real associado às vulnerabilidades em sistemas específicos.
3. Limitações de recursos: Adoraria corrigir todas as vulnerabilidades CVSS com pontuação elevada, mas tem de ser realista. Estabeleça prioridades antes de investir toneladas de recursos em algo que não é rentável.
4. Já está protegido: É possível que já tenha defesas sólidas implementadas. Mesmo que uma vulnerabilidade obtenha uma pontuação elevada, poderá decidir que não vale a pena se já tiver salvaguardas que a mantenham sob controlo.
5. Sensibilização para as CWEs: Estar ciente das CWEs que podem afetar o que está a entregar.

Obter um scanner de vulnerabilidades

Também estão a surgir novas plataformas que o ajudam a detetar tendências emergentes - veja o Fletch, que é especializado na velocidade de consciencialização e contextualização de ameaças. O Nessus verifica mais de 59.000 CVEs. O Nexpose utiliza o seu próprio sistema de pontuação que tem em conta a idade das vulnerabilidades e o tipo de correcções e soluções já implementadas. O Nmap e o OpenVAS são scanners de vulnerabilidades de código aberto.

Entretanto, porque não testar o Aikido Security para monitorizar e melhorar a sua postura geral de segurança? Experimente o Aikido gratuitamente!

Antecipar-se à CurVE

O problema dos CVE é que se referem ao PASSADO, ou seja, a vulnerabilidades e exposições que já aconteceram. Isto significa que, por vezes, os maus actores têm tempo para causar danos antes de termos tempo para reagir. Para além de utilizar um scanner de vulnerabilidades, certifique-se de que toma medidas para gerir o seu risco. Estas podem incluir a garantia de que os patches estão actualizados e a realização de testes de penetração.

TL;DR sec fornece uma boa análise da cadeia de fornecimento de software e, mais importante, como proteger cada fase.

Além disso, gostamos de manter os utilizadores do Aikido (gratuitos e pagantes) e os nossos seguidores do LinkedIn informados com publicações relevantes no LI. Por exemplo, aqui está um post recente que colocámos sobre o CVE-2023-4911 - o (não tão engraçado) bug Looney Tunables.

Verifique o seu código para detetar as explorações mais comuns

Utilize as referências de conformidade OWASP Top 10 e CIS para verificar o seu código. Estas ferramentas padrão ajudam-no a lidar com os pontos fracos mais comuns (OWASP) e as configurações de base para a cibersegurança (CIS).

Veja como pontua diretamente no Aikido: Relatório CIS / Relatório OWASP Top 10

Atualmente, as organizações enfrentam a tarefa urgente de lidar com os riscos de software e hardware desactualizados, à medida que as ciberameaças se tornam mais sofisticadas. Detetar e tratar os sistemas em fim de vida (EOL) é cada vez mais vital para manter a segurança.

A deteção de fim de vida útil identifica software ou hardware que os fornecedores já não suportam, tornando-os susceptíveis a vulnerabilidades de segurança. Ignorar estes componentes desactualizados pode levar a graves violações de segurança, problemas de conformidade e interrupções operacionais.

Felizmente, ferramentas avançadas agora simplificam a deteção de EOL, ajudando as organizações a manter uma segurança forte. Vamos explorar as principais ferramentas de deteção de EOL para 2025, guiando-o através das complexidades do gerenciamento de EOL.

Compreender a deteção do fim da vida (EOL)

A deteção de fim de vida útil centra-se na identificação de software ou hardware que os fornecedores já não suportam. Sem actualizações do fornecedor, estes sistemas tornam-se vulneráveis a novas ameaças de segurança e incompatibilidades.

A manutenção da segurança e da conformidade na infraestrutura de TI exige uma deteção eficaz da EOL. Os componentes desactualizados podem tornar-se riscos de segurança significativos devido à falta de actualizações que resolvam vulnerabilidades conhecidas. Os atacantes visam frequentemente estes sistemas, explorando falhas para obterem acesso não autorizado ou interromperem as operações.

Além disso, a utilização de software ou hardware não suportado pode levar a violações de conformidade, uma vez que muitos regulamentos exigem sistemas actualizados. Ignorar os componentes EOL pode resultar em multas, danos à reputação e perda de confiança.

A deteção eficaz da EOL implica:

• Descoberta abrangente de activos: Identificação de todo o software e hardware em toda a organização, incluindo dispositivos locais, na nuvem e de terminais.
• Monitorização contínua: Verificação regular da existência de componentes desactualizados ou sem suporte, uma vez que as datas de EOL podem diferir consoante o fornecedor e o produto.
• Avaliação dos riscos: Avaliar o impacto dos componentes EOL na segurança, tendo em conta factores como a criticidade e a sensibilidade dos dados.
• Planeamento da correção: Criação de uma estratégia para migrar, atualizar ou retirar sistemas EOL, estabelecendo prioridades com base no risco e nas necessidades comerciais.

A implementação de uma estratégia sólida de deteção de EOL ajuda as organizações a gerir os riscos de componentes desactualizados, melhorando a segurança e garantindo a conformidade. Ferramentas como o Aikido Security oferecem deteção automática de EOL, integrando-se com os sistemas de segurança existentes para fornecer proteção contínua.

Principais ferramentas de deteção de fim de vida útil para 2025

Para escolher as ferramentas de deteção de fim de vida adequadas, é necessário identificar soluções que ofereçam uma gestão de activos robusta e informações sobre o estado do ciclo de vida do software. As seguintes ferramentas simplificam os processos e minimizam os riscos de uma tecnologia desactualizada.

1. Segurança do Aikido

O Aikido Security integra-se perfeitamente nos pipelines de desenvolvimento, fornecendo uma análise precisa do código e dos contentores para identificar componentes que se aproximam ou atingem o fim da vida útil. Projetado para ambientes nativos da nuvem, ele minimiza a interrupção e fornece informações cruciais sobre o ciclo de vida.

2. Tenable.io

Tenable.io oferece monitoramento abrangente de ativos, verificando continuamente a infraestrutura de TI para software desatualizado. Ele fornece uma visão centralizada dos ciclos de vida do software, facilitando o gerenciamento proativo de ativos sem suporte. Esta ferramenta é eficaz para organizações com ambientes extensos no local e na nuvem.

3. NinjaOne RMM

O NinjaOne RMM automatiza a deteção de sistemas operativos em fim de vida e de aplicações de terceiros. A sua plataforma centraliza a gestão de activos de TI, melhorando a eficiência na identificação e tratamento de componentes desactualizados. As caraterísticas intuitivas dos relatórios simplificam a gestão do ciclo de vida.

4. Qualys

Qualys fornece uma abordagem baseada na nuvem para identificar sistemas e aplicações não suportados. As suas capacidades de scanning asseguram uma cobertura abrangente, oferecendo insights acionáveis para remediação. Integra-se facilmente nas estruturas de segurança existentes, melhorando a gestão do ciclo de vida.

Ferramentas de deteção de EOL de código aberto

Soluções de código aberto como o OpenVAS oferecem informações valiosas sobre os ciclos de vida do software, identificando componentes não suportados em diversos sistemas. A sua adaptabilidade torna-o um ativo valioso para organizações com necessidades únicas.

O endoflife.date compila datas EOL e ciclos de vida de suporte para vários produtos de software, com uma API para fácil integração, garantindo o acesso atempado a informações sobre o ciclo de vida.

Estas ferramentas permitem coletivamente às organizações gerir com precisão a deteção do fim de vida útil. A escolha da ferramenta certa aumenta a segurança e mantém a conformidade, protegendo o seu ambiente de riscos tecnológicos desactualizados.

Como escolher a ferramenta de deteção de EOL correta

A escolha da ferramenta de deteção de fim de vida útil correta requer a compreensão das necessidades e da infraestrutura da sua organização. Considere a escala e a complexidade da sua rede. Os sistemas de maior dimensão podem necessitar de soluções abrangentes para o seguimento de activos complexos, enquanto as redes mais pequenas podem beneficiar de ferramentas simplificadas com precisão direcionada.

Dê prioridade a ferramentas que se integrem nos sistemas de segurança e de gestão de TI existentes, assegurando um fluxo de informações sem problemas e reforçando as medidas de segurança actuais. As ferramentas que suportam configurações de API flexíveis permitem soluções personalizadas que se adaptam aos requisitos operacionais.

A automatização é crucial. As ferramentas que automatizam a deteção de componentes não suportados e facilitam uma rápida correção aumentam a eficiência operacional, reduzindo a intervenção manual e permitindo que as equipas de segurança se concentrem em iniciativas estratégicas.

Factores-chave para avaliar as ferramentas de deteção de EOL

Ao avaliar as ferramentas, considere estes aspectos para uma cobertura abrangente e uma gestão eficaz:

• Visibilidade holística dos activos: Escolha ferramentas que monitorizem várias plataformas, incluindo sistemas locais, na nuvem e de terminais, garantindo que todos os componentes são incluídos na gestão do ciclo de vida.
• Precisão na identificação: Opte por soluções que identifiquem com precisão os sistemas e o software EOL, reduzindo os falsos positivos e concentrando-se nas vulnerabilidades reais.
• Análise de risco abrangente: Selecione ferramentas que forneçam informações pormenorizadas sobre componentes não suportados e riscos associados, facilitando a atribuição eficiente de prioridades às vulnerabilidades.

A concentração nestes critérios ajuda a selecionar uma solução que satisfaz as necessidades imediatas e se adapta ao crescimento futuro, garantindo uma segurança e conformidade sustentadas à medida que a tecnologia evolui.

Implementação de uma estratégia eficaz de deteção de EOL

Criar uma estratégia sólida de deteção de EOL é fundamental para proteger a infraestrutura de TI. Comece por compilar um catálogo detalhado de todos os activos tecnológicos, actualizando-o regularmente para gerir eficazmente os desafios do ciclo de vida.

Avaliar de forma consistente o panorama tecnológico para identificar componentes não suportados. Programar avaliações automatizadas para garantir uma cobertura abrangente, concentrando-se na identificação de elementos actuais e futuros sem suporte para intervenções atempadas.

Melhores práticas para gerir os riscos de EOL

A gestão dos riscos de EOL requer um plano detalhado para a transição de sistemas desactualizados, tendo em conta os prazos e os recursos para actualizações ou substituições.

Para os sistemas que devem permanecer activos apesar de não serem suportados, reforce a segurança através de medidas provisórias como a restrição do acesso ou a aplicação de melhorias temporárias de segurança até que seja viável uma solução permanente.

O sucesso da gestão da EOL também depende da colaboração entre as equipas de TI e de segurança. Coordenar esforços para avaliar e abordar os riscos com base na vulnerabilidade e importância de cada sistema, garantindo uma correção atempada e eficaz.

O futuro da deteção do fim da vida

O futuro da deteção do fim de vida útil será fortemente influenciado pela inteligência artificial e pelos algoritmos de previsão. Estas tecnologias irão melhorar a identificação proactiva de componentes que se aproximam da obsolescência, oferecendo informações que permitem às organizações prepararem-se em conformidade. A IA pode prever tendências que indicam potenciais riscos do ciclo de vida, proporcionando uma vantagem sobre os métodos tradicionais.

À medida que as infra-estruturas digitais se tornam mais complexas, a correção automatizada tornar-se-á crucial. Simplificará a identificação de componentes EOL e permitirá actualizações ou substituições contínuas, permitindo às equipas de TI gerir eficazmente vastas redes.

As metodologias nativas da nuvem adaptarão a deteção de EOL às pilhas de TI modernas, tirando partido da escalabilidade e adaptabilidade da nuvem para a gestão do ciclo de vida. À medida que as organizações utilizam cada vez mais tecnologias de nuvem, a integração da deteção de EOL nestes ambientes tornar-se-á uma vantagem fundamental.

Tendências emergentes na gestão da EOL

A incorporação de avaliações de EOL no início do desenvolvimento está a tornar-se uma norma, integrando avaliações do ciclo de vida nos processos DevOps e CI/CD para abordar os riscos durante a criação de software. A avaliação de riscos em tempo real também está a tornar-se essencial, utilizando a monitorização avançada para obter informações contínuas sobre os activos de TI, de modo a resolver rapidamente os problemas do ciclo de vida.

As plataformas integradas que combinam a deteção do fim de vida útil com uma gestão abrangente dos riscos estão a ganhar força. Estas soluções simplificam os processos e aumentam a segurança, combinando a gestão do ciclo de vida com a atenuação dos riscos, obtendo resultados eficientes e exactos na resolução dos desafios do ciclo de vida e da segurança.

Superar os desafios da deteção de EOL

As organizações debatem-se frequentemente com a gestão da deteção de fim de vida útil devido à existência de TI sombra e de sistemas antigos que funcionam sem supervisão, criando lacunas de segurança. Sem uma visibilidade clara, os componentes ocultos podem escapar à deteção, aumentando a exposição à vulnerabilidade.

A natureza dinâmica dos ambientes de TI modernos complica a priorização dos riscos de EOL. As grandes organizações têm de navegar em inventários de activos em constante mudança, o que dificulta a concentração em vulnerabilidades críticas. É necessária uma estrutura estratégica para priorizar os riscos de forma eficaz.

As restrições de recursos complicam ainda mais o equilíbrio entre a deteção de EOL e outras tarefas de segurança. As equipas de segurança, muitas vezes sobrecarregadas, têm de gerir a deteção de EOL juntamente com outras prioridades, o que exige uma distribuição eficiente dos recursos.

Estratégias para uma deteção eficaz da EOL em grande escala

Para enfrentar estes desafios, as organizações podem utilizar estratégias para melhorar a eficiência da deteção de EOL. A automatização pode simplificar a análise e a elaboração de relatórios, libertando o pessoal de segurança para se concentrar em tarefas estratégicas e garantindo uma monitorização completa.

A incorporação de conhecimentos sobre a EOL nas estruturas existentes de gestão de serviços de TI e de emissão de bilhetes cria uma abordagem coesa de gestão do ciclo de vida, facilitando uma ação atempada sobre os riscos e aumentando a responsabilidade.

A contratação de fornecedores de serviços de segurança geridos pode aumentar a gestão do risco EOL, oferecendo conhecimentos especializados e recursos para soluções personalizadas para questões complexas do ciclo de vida. A utilização de conhecimentos externos reforça as capacidades internas, garantindo estratégias abrangentes de deteção de fim de vida útil.

À medida que a tecnologia continua a evoluir, a deteção eficaz do fim de vida útil continua a ser um componente de segurança essencial. Ao utilizar as ferramentas corretas e as melhores práticas, as organizações podem gerir as complexidades da EOL, garantindo a segurança e a conformidade da infraestrutura de TI. Simplifique a sua segurança e agilize a deteção de EOL com a avaliação gratuita do Aikido hoje mesmo, e concentre-se em criar um software excelente.

Isolámos as 3 principais vulnerabilidades críticas de segurança das aplicações Web que os utilizadores do Aikido enfrentam. Este guia descreve o que são, porque são tão comuns e como corrigi-las - juntamente com algumas vulnerabilidades arriscadas que não podíamos ignorar.

Se os resolver cedo e de forma eficaz, já estará muito à frente na luta para manter a sua aplicação Web segura contra o cibercrime.

1. Vulnerabilidades de código mais comuns e críticas (SAST)

O teste estático de segurança de aplicações (SAST) é um método de teste que analisa o código-fonte em busca de vulnerabilidades no início do ciclo de desenvolvimento. É chamado um método de caixa branca porque o funcionamento da aplicação é conhecido pelo testador.

Ataques de injeção NoSQL (vulnerabilidade de código: SAST)

A injeção NoSQL pode levar à fuga de dados, a bases de dados corrompidas e até ao comprometimento total do sistema. Infelizmente, trata-se de uma vulnerabilidade crítica de segurança das aplicações Web e vimos muitas contas de utilizadores do Aikido expostas a esta vulnerabilidade.

O que é a injeção NoSQL?

A injeção NoSQL é um tipo de ataque em que os hackers utilizam código malicioso para manipular ou obter acesso não autorizado a uma base de dados NoSQL. Ao contrário das injecções SQL, que visam bases de dados SQL, as injecções NoSQL exploram vulnerabilidades em bases de dados NoSQL como o MongoDB. Podem levar a fugas de dados, corrupção ou mesmo controlo total sobre a base de dados.

Porque é que esta vulnerabilidade é tão comum?

A injeção NoSQL é comum, em parte devido à crescente popularidade das bases de dados NoSQL, especialmente o MongoDB. Estas bases de dados oferecem vantagens em termos de desempenho, mas apresentam desafios de segurança únicos.

Para além disso, as bases de dados NoSQL são flexíveis na medida em que aceitam vários formatos como XML e JSON. Esta flexibilidade é óptima, mas pode levar a vulnerabilidades de segurança das aplicações Web, uma vez que as verificações de segurança padrão podem não detetar entradas maliciosas adaptadas a estes formatos.

E a vasta gama de bases de dados NoSQL, cada uma com a sua própria sintaxe e estrutura, também dificulta a criação de salvaguardas universais. Os profissionais de segurança têm de compreender os pormenores específicos de cada base de dados, o que aumenta a complexidade do processo de prevenção.

Pior ainda, e ao contrário das injecções SQL tradicionais, as injecções NoSQL podem ocorrer em diferentes partes de uma aplicação. Isto torna-as ainda mais difíceis de detetar.

Como é que se pode corrigir facilmente esta vulnerabilidade?

Utilize a validação de entrada e as consultas parametrizadas. A validação de entrada garante que as entradas do utilizador correspondem aos tipos e formatos esperados, rejeitando valores não seguros. As consultas parametrizadas impedem a incorporação de entradas não validadas.

Em geral, implemente sempre caraterísticas de segurança da base de dados, como a autenticação e a encriptação. Mantenha-se atualizado com os patches mais recentes. E certifique-se de que efectua auditorias regulares ao código e às configurações para identificar e corrigir esta e outras vulnerabilidades.

Segundo classificado: Deixar funções de depuração perigosas no código (vulnerabilidade do código: SAST)

As funções de depuração expostas permitem um reconhecimento que ajuda os atacantes a explorar os sistemas - por vezes com riscos de segurança significativos.

O que são funções de depuração perigosas?

Funções de depuração como phpinfo() podem expor informações sensíveis sobre seu servidor e ambiente. Isso inclui a versão do PHP, detalhes do sistema operacional, informações do servidor e até mesmo variáveis de ambiente que podem conter chaves secretas (embora nós definitivamente não recomendamos colocar chaves secretas lá em primeiro lugar!)

Como resultado, a deteção da estrutura do seu sistema de ficheiros através destas funções de depuração pode permitir que os piratas informáticos efectuem ataques de passagem de diretórios se o seu site estiver vulnerável. Expor o phpinfo() por si só não é necessariamente um risco elevado, mas pode facilitar um pouco as coisas para os atacantes. O princípio é claro: quanto menos informações específicas os hackers tiverem sobre o seu sistema, melhor.

Porque é que esta vulnerabilidade é tão comum?

Esta vulnerabilidade de segurança das aplicações Web ocorre frequentemente porque os programadores utilizam estas funções para depuração e, por vezes, até as colocam em produção para resolução de problemas. Lançamentos apressados, falta de revisão do código e subestimação dos riscos contribuem para que estas funções sejam deixadas expostas.

Como é que se pode corrigir facilmente esta vulnerabilidade?

• Revisão do código: verifique regularmente o seu código para identificar e remover funções de depuração antes de o implementar na produção.
• Ferramentas automatizadas de verificação de vulnerabilidades: utilize uma ferramenta, como o Aikido, que possa detetar funções de depuração perigosas.
• Configurações específicas do ambiente: certifique-se de que desactiva as funções de depuração no ambiente de produção.

2. Vulnerabilidade mais comum e crítica da DAST

O teste dinâmico de segurança de aplicações (DAST) é uma técnica de teste que identifica vulnerabilidades em aplicações em execução. É chamado um método de caixa preta porque se concentra apenas no comportamento observável. O DAST mostra-lhe como o sistema pode parecer a um atacante.

Esquecer os principais cabeçalhos de segurança: HSTS e CSP (vulnerabilidade da nuvem: DAST)

A falta de uma implementação correta do HSTS e do CSP deixa as aplicações Web vulneráveis a ataques importantes como o XSS e a divulgação de informações.

O que é o CSP?

A Política de Segurança de Conteúdo (CSP) é um mecanismo de segurança que ajuda a derrotar vários ataques baseados no browser, como o cross-site scripting e o clickjacking. Fá-lo restringindo comportamentos de risco em páginas Web, tais como JavaScript em linha e funções eval() não seguras. O CSP impõe padrões mais seguros para manter a integridade e a confidencialidade do conteúdo. A principal vantagem é a proteção contra a injeção maliciosa de scripts.

Porque é que esta vulnerabilidade DAST é tão comum?

É muito comum negligenciar o HSTS e o CSP, especialmente o CSP, e os programadores dão frequentemente prioridade à funcionalidade em detrimento destes cabeçalhos.

Deveria planear a CSP no início do desenvolvimento, mas esta é frequentemente negligenciada. E quando os programadores tentam implementá-la ou adaptá-la mais tarde, isso causa conflitos, pelo que saltam completamente a CSP para prosseguir com outro trabalho. Isto deixa as aplicações desprotegidas e sujeitas a uma série de vulnerabilidades de segurança das aplicações Web.

Como é que se pode corrigir facilmente esta vulnerabilidade DAST?

• Implementar HSTS para forçar ligações apenas HTTPS. Ativar no servidor através de ficheiros de configuração ou de um WAF.
• Defina e aplique uma CSP rigorosa adaptada à sua aplicação, restringindo práticas pouco seguras como scripts em linha. Teste cuidadosamente a compatibilidade.
• Monitorizar e atualizar continuamente os cabeçalhos à medida que a aplicação evolui para manter a proteção.

3. Vulnerabilidade mais comum e crítica da nuvem (CSPM)

As ferramentas de gestão da postura de segurança na nuvem (CSPM) monitorizam continuamente os ambientes baseados na nuvem para garantir a conformidade com as normas de segurança e as melhores práticas. As ferramentas CSPM procuram configurações incorrectas de segurança e têm como objetivo atenuar os riscos.

Deixando as funções EC2 IAM vulneráveis a ataques SSRF (nuvem: CSPM)

As funções de IAM do EC2 aberto frequentemente podem permitir que os invasores se movam lateralmente e obtenham acesso não autorizado em ambientes de nuvem. O impacto potencial desse tipo de ataque pode ser devastador.

O que são funções de IAM do EC2?

As funções EC2 IAM (Identity and Access Management) no Amazon Web Services (AWS) delegam permissões para determinar as acções permitidas em recursos específicos. Permitem que as instâncias EC2 interajam de forma segura com outros serviços AWS sem terem de armazenar credenciais diretamente nas próprias instâncias.

O que é um ataque SSRF?

Um ataque de falsificação de pedidos do lado do servidor (SSRF) é quando um atacante força o servidor a efetuar pedidos a recursos internos como se fosse o próprio servidor a pedir. O atacante pode potencialmente aceder a sistemas não autorizados desta forma, contornar controlos ou mesmo executar comandos. Veja este exemplo assustador de como um ataque SSRF tomou conta da nuvem de uma startup através de um simples formulário para enviar um e-mail.

Porque é que esta vulnerabilidade CSPM é tão comum?

As funções IAM do EC2 são normalmente deixadas vulneráveis a ataques SSRF devido a configurações incorrectas de segurança ou funções demasiado permissivas. Fazer malabarismos com permissões complexas na nuvem é difícil e alguns programadores podem não compreender totalmente os riscos. Além disso, querer que os serviços funcionem bem em conjunto pode muitas vezes levar as equipas a conceder mais acesso do que o realmente necessário.

Como é que se pode corrigir facilmente esta vulnerabilidade do CSPM?

Existem algumas formas sólidas de lidar com as funções do EC2 e mitigar as vulnerabilidades de segurança das aplicações Web SSRF. Em primeiro lugar, siga o princípio do menor privilégio - permita apenas o acesso exato que é absolutamente necessário e nada mais. As funções demasiado permissivas estão a pedir problemas.

De seguida, utilize as ferramentas integradas do AWS, como grupos de segurança e ACLs de rede, para bloquear o tráfego e reduzir as potenciais aberturas para ataques SSRF. Quanto mais puder limitar o acesso, melhor.

Também é importante rever e auditar regularmente as funções para detetar qualquer acesso desnecessário que possa estar a surgir ao longo do tempo à medida que as coisas mudam. Mantenha-se a par de tudo.

E, por último, implemente ferramentas de segurança AWS focadas especificamente na deteção e prevenção de ataques SSRF antes que causem danos. Quanto mais camadas de proteção, mais seguro estará.

Vice-campeão: Tempos de execução lambda em nuvem desatualizados (nuvem: CSPM)

Quando estes ambientes de tempo de execução ficam desactualizados, podem expor as funções lambda aos atacantes.

O que são tempos de execução lambda desactualizados?

Os tempos de execução lambda desatualizados referem-se ao uso de versões mais antigas de linguagens de programação ou ambientes em funções sem servidor (lambdas). Esses tempos de execução desatualizados podem não ter os patches de segurança ou atualizações de recursos mais recentes, expondo potencialmente os aplicativos a vulnerabilidades de segurança de aplicativos Web conhecidas.

Porque é que esta vulnerabilidade CSPM é tão comum?

A vulnerabilidade resulta frequentemente de uma mentalidade de "definir e esquecer". Os programadores podem implementar lambdas com um tempo de execução específico e negligenciar a sua atualização à medida que são lançadas novas versões. Eles também podem cometer o erro de assumir que os provedores de nuvem cuidam de toda a manutenção. Embora o AWS e o Google Cloud Functions façam a manutenção dos tempos de execução com pequenos patches do sistema operacional, eles não farão grandes atualizações de linguagem. Além de tudo isso, a complexidade de gerenciar vários lambdas facilita que tempos de execução desatualizados caiam nas fendas e criem riscos extras.

Como é que se pode corrigir facilmente esta vulnerabilidade do CSPM?

Pode atenuar o risco seguindo três regras simples:

• Rever regularmente quais os tempos de execução utilizados e verificar se existem actualizações.
• Actualize para as versões suportadas mais recentes com patches de segurança.
• Utilizar ferramentas de automatização para gerir e atualizar os tempos de execução sempre que possível.

Vulnerabilidades de segurança das aplicações Web e melhores práticas

Compreender estas vulnerabilidades de segurança das aplicações Web é essencial para a segurança do sistema, mas lembre-se de seguir as melhores práticas de segurança. Mantenha-se atualizado, aplique as correcções adequadas e mantenha uma monitorização regular para manter o seu ambiente seguro e protegido.

Analise o seu ambiente com o Aikido agora mesmo para descobrir se está exposto a alguma destas vulnerabilidades.

Confira a lista de verificação de segurança do CTO de SaaS 2024 da Aikido para obter conselhos concisos sobre mais de 40 maneiras de melhorar a segurança de seu pessoal, processos, código, infraestrutura e muito mais.