Inteligência de dados generativa

Canto CISO: SBOMs malignos; Zero-Trust Pioneer derruba segurança na nuvem

Data:

Bem-vindo ao CISO Corner, o resumo semanal de artigos da Dark Reading adaptados especificamente para leitores de operações de segurança e líderes de segurança. Todas as semanas, ofereceremos artigos coletados em nossa operação de notícias, The Edge, DR Technology, DR Global e nossa seção de comentários. Temos o compromisso de trazer a você um conjunto diversificado de perspectivas para apoiar o trabalho de operacionalização de estratégias de segurança cibernética para líderes de organizações de todos os formatos e tamanhos.

Nesta edição do CISO Corner:

  • Kindervag diz: 5 duras verdades sobre o estado da segurança na nuvem em 2024

  • MITRE AT&CKED: O nome mais confiável da InfoSec cai para Ivanti Bugs

  • Lições para CISOs do LLM Top 10 da OWASP

  • Cyberattack Gold: SBOMs oferecem um censo fácil de software vulnerável

  • Global: Licenciado para faturar? Certificação e licenciamento do mandato das nações para profissionais de segurança cibernética

  • Johnson & Johnson Spin-Off CISO sobre Maximização da Segurança Cibernética

  • SolarWinds 2024: Para onde vão as divulgações cibernéticas a partir daqui?

5 duras verdades sobre o estado da segurança na nuvem em 2024

Por Ericka Chickowski, escritora colaboradora, Dark Reading

Dark Reading fala sobre segurança na nuvem com John Kindervag, o padrinho da confiança zero.

A maioria das organizações não está trabalhando totalmente práticas maduras de segurança na nuvem, apesar de quase metade das violações terem origem na nuvem e de quase 4.1 milhões de dólares perdidos devido a violações na nuvem no ano passado.

Isso é um grande problema, de acordo com o padrinho da segurança de confiança zero, John Kindervag, que conceituou e popularizou o modelo de segurança de confiança zero como analista da Forrester. Ele diz a Dark Reading que existem algumas verdades difíceis de enfrentar para mudar as coisas.

1. Você não fica mais seguro apenas indo para a nuvem: A nuvem não é intrinsecamente mais segura do que a maioria dos ambientes locais: os fornecedores de nuvem em hiperescala podem ser muito bons na proteção da infraestrutura, mas o controlo e a responsabilidade que têm sobre a postura de segurança dos seus clientes são muito limitados. E o modelo de responsabilidade compartilhada realmente não funciona.

2. Os controles de segurança nativos são difíceis de gerenciar em um mundo híbrido: A qualidade é inconsistente quando se trata de oferecer aos clientes mais controle sobre suas cargas de trabalho, identidades e visibilidade, mas os controles de segurança que podem ser gerenciados em todas as diversas nuvens são ilusórios.

3. A identidade não salvará sua nuvem: Com tanta ênfase colocada no gerenciamento de identidade na nuvem e atenção desproporcional no componente de identidade na confiança zero, é importante que as organizações entendam que a identidade é apenas parte de um café da manhã bem equilibrado para a confiança zero na nuvem.

4. Muitas empresas não sabem o que estão tentando proteger: Cada ativo, sistema ou processo acarretará seu próprio risco, mas as organizações não têm uma ideia clara do que está na nuvem ou do que está conectado à nuvem, muito menos do que precisa ser protegido.

5. Os incentivos ao desenvolvimento nativo da nuvem estão fora de sintonia: Muitas organizações simplesmente não têm as estruturas de incentivo adequadas para que os desenvolvedores promovam a segurança à medida que avançam — e, de fato, muitas têm incentivos perversos que acabam incentivando práticas inseguras. “Gosto de dizer que o pessoal dos aplicativos DevOps são os Ricky Bobbys da TI. Eles só querem ir rápido”, diz Kindervag.

Leia mais: 5 duras verdades sobre o estado da segurança na nuvem em 2024

Relacionado: Zero Trust assume o controle: 63% das organizações implementando globalmente

MITRE AT&CKED: O nome mais confiável da InfoSec cai para Ivanti Bugs

Por Nate Nelson, escritor colaborador, Dark Reading

A ironia é perdida por poucos, já que um ator de ameaça de um estado-nação usou oito técnicas do MITRE para violar o próprio MITRE – incluindo a exploração dos bugs do Ivanti que os invasores vêm atacando há meses.

Hackers estrangeiros de estados-nação usaram dispositivos de borda Ivanti vulneráveis para obter três meses de acesso “profundo” a uma das redes não confidenciais da MITRE Corp.

MITRE, administrador do onipresente glossário ATT&CK de técnicas de ataque cibernético comumente conhecidas, já passou 15 anos sem nenhum incidente grave. A maré foi interrompida em janeiro, quando, como tantas outras organizações, seus dispositivos de gateway Ivanti foram explorados.

A violação afetou o Ambiente de Experimentação, Pesquisa e Virtualização em Rede (NERVE), uma rede colaborativa não classificada que a organização usa para pesquisa, desenvolvimento e prototipagem. A extensão dos danos ao NERVE (trocadilho intencional) está sendo avaliada atualmente.

Quaisquer que fossem seus objetivos, os hackers tiveram tempo suficiente para realizá-los. Embora o compromisso tenha ocorrido em janeiro, o MITRE só conseguiu detectá-lo em abril, deixando um intervalo de um quarto de ano entre eles.

Leia mais: MITRE AT&CKED: O nome mais confiável da InfoSec cai para Ivanti Bugs

Relacionado: Principais técnicas MITRE ATT&CK e como se defender contra elas

Lições para CISOs do LLM Top 10 da OWASP

Comentário de Kevin Bocek, Diretor de Inovação, Venafi

É hora de começar a regulamentar os LLMs para garantir que eles sejam treinados com precisão e estejam prontos para lidar com negócios que possam afetar os resultados financeiros.

OWASP lançou recentemente sua lista dos 10 principais aplicativos de modelo de linguagem grande (LLM), de modo que desenvolvedores, designers, arquitetos e gerentes agora têm 10 áreas nas quais focar claramente quando se trata de questões de segurança.

Quase todos os As 10 principais ameaças de LLM centram-se em torno de um compromisso de autenticação para as identidades usadas nos modelos. Os diferentes métodos de ataque abrangem toda a gama, afetando não apenas as identidades das entradas do modelo, mas também as identidades dos próprios modelos, bem como suas saídas e ações. Isso tem um efeito indireto e exige autenticação nos processos de assinatura e criação de código para interromper a vulnerabilidade na origem.

Embora mais de metade dos 10 principais riscos sejam essencialmente mitigados e exijam o kill switch para a IA, as empresas terão de avaliar as suas opções ao implementar novos LLMs. Se existirem as ferramentas certas para autenticar os inputs e os modelos, bem como as ações dos modelos, as empresas estarão mais bem equipadas para aproveitar a ideia do interruptor de interrupção da IA ​​e evitar mais destruição.

Leia mais: Lições para CISOs do LLM Top 10 da OWASP

Relacionado: Bugcrowd anuncia classificações de vulnerabilidade para LLMs

Cyberattack Gold: SBOMs oferecem um censo fácil de software vulnerável

Por Rob Lemos, escritor colaborador, Dark Reading

Os invasores provavelmente usarão listas de materiais de software (SBOMs) para procurar software potencialmente vulnerável a falhas específicas de software.

As empresas governamentais e sensíveis à segurança exigem cada vez mais que os fabricantes de software lhes forneçam listas de materiais de software (SBOMs) para fazer face aos riscos da cadeia de abastecimento – mas isto está a criar uma nova categoria de preocupação.

Resumindo: um invasor que determina qual software uma empresa visada está executando pode recuperar o SBOM associado e analisar os componentes do aplicativo em busca de pontos fracos, tudo sem enviar um único pacote, diz Larry Pesce, diretor de pesquisa e análise de segurança de produtos da software empresa de segurança da cadeia de suprimentos Finite State.

Ele é um ex-testador de penetração há 20 anos e planeja alertar sobre o risco em uma apresentação sobre “SBOMs malignos” na Conferência RSA em maio. Ele mostrará que os SBOMs têm informações suficientes para permitir que os invasores pesquisar CVEs específicos em um banco de dados de SBOMs e encontre um aplicativo que provavelmente seja vulnerável. Ainda melhor para os invasores, os SBOMs também listarão outros componentes e utilitários no dispositivo que o invasor poderia usar para “viver da terra” após o comprometimento, diz ele.

Leia mais: Cyberattack Gold: SBOMs oferecem um censo fácil de software vulnerável

Relacionado: Southern Company constrói SBOM para subestação de energia elétrica

Global: Licenciado para faturar? Certificação e licenciamento do mandato das nações para profissionais de segurança cibernética

Por Robert Lemos, escritor colaborador, Dark Reading

Malásia, Singapura e Gana estão entre os primeiros países a aprovar leis que exigem segurança cibernética empresas — e em alguns casos, consultores individuais — para obter licenças para fazer negócios, mas as preocupações permanecem.

A Malásia juntou-se a pelo menos duas outras nações - Singapore e Gana — ao aprovar leis que exigem que os profissionais de segurança cibernética ou as suas empresas sejam certificados e licenciados para fornecer alguns serviços de segurança cibernética no seu país.

Embora os mandatos da legislação ainda não tenham sido determinados, “isto provavelmente se aplicará a prestadores de serviços que prestam serviços para proteger dispositivos de tecnologia de informação e comunicação de outra pessoa – [por exemplo] fornecedores de testes de penetração e centros de operações de segurança”, de acordo com a empresa sediada na Malásia. escritório de advocacia Christopher & Lee Ong.

O vizinho da Ásia-Pacífico, Singapura, já exigiu o licenciamento de prestadores de serviços de segurança cibernética (CSPs) nos últimos dois anos, e o Gana, país da África Ocidental, exige o licenciamento e a acreditação de profissionais de segurança cibernética. De forma mais ampla, governos como o da União Europeia normalizaram as certificações de segurança cibernética, enquanto outras agências — como o estado americano de Nova Iorque — exigem certificações e licenças para capacidades de segurança cibernética em indústrias específicas.

No entanto, alguns especialistas vêem consequências potencialmente perigosas destas medidas.

Leia mais: Licenciado para faturar? Certificação e licenciamento do mandato das nações para profissionais de segurança cibernética

Relacionado: Cingapura estabelece padrões elevados em preparação para segurança cibernética

CISO spin-off da J&J sobre maximização da segurança cibernética

Por Karen D. Schwartz, escritora colaboradora, Dark Reading

Como o CISO da Kenvue, uma empresa de saúde ao consumidor derivada da Johnson & Johnson, combinou ferramentas e novas ideias para desenvolver o programa de segurança.

Mike Wagner, da Johnson & Johnson, ajudou a moldar a abordagem e a pilha de segurança da empresa Fortune 100; agora, ele é o primeiro CISO do spinoff de saúde do consumidor da J&J, Kenvue, com a tarefa de criar uma arquitetura simplificada e econômica com segurança máxima.

Este artigo detalha as etapas pelas quais Wagner e sua equipe trabalharam, que incluem:

Defina funções principais: Arquitetos e engenheiros para implementação de ferramentas; especialistas em gerenciamento de identidade e acesso (IAM) para permitir autenticação segura; líderes de gerenciamento de risco alinhar a segurança com as prioridades de negócios; pessoal de operações de segurança para resposta a incidentes; e pessoal dedicado para cada função cibernética.

Incorpore aprendizado de máquina e IA: As tarefas incluem automatizar o IAM; simplificar a verificação de fornecedores; análise comportamental; e melhorar a detecção de ameaças.

Escolha quais ferramentas e processos manter e quais substituir: Embora a arquitetura de segurança cibernética da J&J seja uma colcha de retalhos de sistemas criados por décadas de aquisições; as tarefas aqui incluíram inventariar as ferramentas da J&J; mapeá-los para o modelo operacional do Kenvue; e identificar novas capacidades necessárias.

Wagner diz que há mais a fazer. Em seguida, planeia apoiar-se em estratégias de segurança modernas, incluindo a adoção de confiança zero e a melhoria dos controlos técnicos.

Leia mais: CISO spin-off da J&J sobre maximização da segurança cibernética

Relacionado: Uma espiada nas ferramentas de IA da Visa contra fraude

SolarWinds 2024: Para onde vão as divulgações cibernéticas a partir daqui?

Comentário de Tom Tovar, CEO e cocriador, Appdome

Obtenha conselhos atualizados sobre como, quando e onde devemos divulgar incidentes de segurança cibernética de acordo com a regra de quatro dias da SEC após a SolarWinds e junte-se à chamada para renovar a regra e remediá-la primeiro.

Num mundo pós-SolarWinds, devemos avançar para um porto seguro de remediação para riscos e incidentes de segurança cibernética. Especificamente, se alguma empresa corrigir as deficiências ou o ataque dentro do prazo de quatro dias, deverá ser capaz de (a) evitar uma reclamação de fraude (ou seja, não há nada para falar) ou (b) usar o processo padrão 10Q e 10K, incluindo a seção de Discussão e Análise Gerencial, para divulgar o incidente.

Em 30 de outubro, a SEC apresentou um denúncia de fraude contra SolarWinds e seu diretor de segurança da informação, alegando que, embora os funcionários e executivos da SolarWinds soubessem dos riscos, vulnerabilidades e ataques crescentes contra os produtos da SolarWinds ao longo do tempo, “as divulgações de riscos de segurança cibernética da SolarWinds não os divulgaram de forma alguma”.

Para ajudar a evitar problemas de responsabilidade nestas situações, um porto seguro de remediação permitiria às empresas um período completo de quatro dias para avaliar e responder a um incidente. Então, se for remediado, reserve um tempo para divulgar o incidente de maneira adequada. O resultado é mais ênfase na resposta cibernética e menos impacto nas ações públicas de uma empresa. Os 8K ainda podem ser usados ​​para incidentes de segurança cibernética não resolvidos.

Leia mais: SolarWinds 2024: Para onde vão as divulgações cibernéticas a partir daqui?

Relacionado: O que SolarWinds significa para DevSecOps

local_img

Inteligência mais recente

local_img