Nas últimas semanas, fiz dois webinars divertidos relacionados a operações de segurança, e houve muitas perguntas e respostas divertidas. Às vezes, as perguntas abaixo são ligeiramente editadas para maior clareza, erros de digitação, etc.
Para diversão extra, mandei o ChatGPT responder a algumas delas, para ver se ele pode me substituir 🙂
Então, primeiro, o webinar da ISACA “Modernize seu SOC para o futuro” focados em nossa visão de Operações de Segurança Autônoma.
P: Se não for chamado de SOC, gostaria de compartilhar o nome que você deu à equipe? [this question is related to the fact that at Google, there is no team called “SOC”]
R: A discussão sobre nomear o centro de operações de segurança vem de um debate mais longo sobre se o SOC inclui apenas os analistas assistindo às telas ou a infraestrutura e os processos para produção de alertas, pesquisa de ameaças, criação de detecção etc. Como resultado, algumas organizações assumem que SOC significa apenas um conteúdo de equipe assistindo as telas e eles não querem chamar sua equipe combinada/integrada com o mesmo nome
Os nomes que encontrei são apenas detecção e equipe de resposta, equipe D&R, etc com algumas opções de nomes exclusivas do Google. Por favor, não diga “equipe XDR”, se possível 🙂
P: O “SOC moderno” parece ótimo no papel, mas é mais difícil encontrar analistas que tenham as habilidades necessárias para focar nas ameaças quando você precisa lidar com desgaste. O que você pode propor para encontrar pessoas qualificadas para essas funções mais rapidamente?
R: De fato, os desafios de usar os analistas para criar conteúdo de detecção e perseguir ameaças implicam que eles tenham as habilidades para estudar as ameaças e criar conteúdo de detecção. Algumas pessoas assumem que esse problema é resolvido principalmente pela contratação, mas, em nossa opinião, é resolvido pela motivação, treinamento, retenção e, talvez por último, pela contratação.
Certamente não estamos sugerindo que você demita seus analistas de SOC e contrate alguns míticos engenheiros de segurança full-stack (ou robôs, aliás). O que você faz é começar a selecionar, treinar e motivar seus analistas a explorar além de passar os alertas. Mais detalhes sobre isso são fornecidos em o documento ASO original.
P: Você poderia explicar um pouco mais sobre a biblioteca de casos de uso?
R: Quando nos referimos à biblioteca de casos de uso no contexto do SOC, queremos dizer uma coleção de suas regras, playbooks e outros conteúdos de detecção, com seus processos associados. Pense nisso, uma biblioteca de livros é uma coleção de conteúdo para as pessoas lerem, enquanto uma biblioteca de casos de uso é uma coleção de conteúdo de casos de uso para as ferramentas de detecção executarem. Essa biblioteca vem com seus próprios fluxos de trabalho de processamento, como criação de caso de uso, ajuste e modificação e desativação.
Detalhes sobre isso podem ser encontrados neste “Como criar e manter casos de uso de monitoramento de segurança para seu SIEM” Artigo do Gartner (desculpe pelo acesso pago, os analistas precisam comer)
P: Por favor, expanda a Caça às Ameaças com exemplos, algum risco?
A: Eu adiaria para coisas que outros escreveram e para alguns de minha própria escrita do passado para definir a caça às ameaças. Aqui eu diria que apenas procurar por indicadores pode ser parte da caça, mas não é tudo, com certeza.
Para mim, a parte mais interessante da sua pergunta é sobre os riscos da caça às ameaças. Durante o webinar, minha resposta centrou-se no fato de que, embora não haja riscos de caça, pode haver riscos associados de descobrir algo com o qual você não sabe como lidar. Embora possamos brincar o quanto quisermos sobre pedir ajuda neste caso (“ligue para o Mandiant!”), Esse é o conselho absolutamente correto nesta situação.
Ver “Meu artigo “Como caçar ameaças à segurança” é publicado” e veja também “A caça às ameaças não é para todos.” E também “Cuidado: SOCs de nível de palhaço ainda abundam” para conselhos sobre quando NÃO caçar.
PS E se você não confia nos humanos, aqui está a resposta do seu simpático robô da vizinhança, ChatGPT da OpenAI
P: Quais são as linhas de base da implementação de SOC/SIEM? Existe algum padrão para SIEM/SOC?
R: São essencialmente quatro perguntas, cada uma bastante complicada. Eles são definitivamente documentos de orientação do setor sobre a implementação do SIEM (pesquise no Google, não tenho uma lista de favoritos de alguma forma) e escrevi uma boa parte deles enquanto estava no Gartner. No entanto, as diferenças entre as organizações geram diferenças em como elas implementam ferramentas SIEM e administram suas equipes SOC. Provavelmente, o mais próximo da orientação SOC padrão é o “11 Estratégias de um Centro de Operações de Segurança Cibernética de Classe Mundial” livro, que foi recentemente atualizado
Além disso, e especialmente se você não puder acessar o conteúdo do Gartner, o Google é seu amigo.
P: A equipe do SOC deve ser composta por uma equipe multilíngue para lidar com a diversidade global de ameaças?
R: Minha resposta a esta pergunta será determinada pelo fato de você tratar sua equipe de inteligência de ameaças como parte do SOC. Em outros lugares, a equipe de inteligência de ameaças é um par do SOC, e não parte dele. Se você planeja formar uma grande equipe de pesquisa, provavelmente precisará de talentos multilíngues. Porém, para um SOC mais tradicional isso parece excessivo.
Ver “Sobre o modelo Tri-Team de SOC, CIRT, “Threat Something” para detalhes.
P: Você acredita em exemplos de treinamento interdepartamental de analista de negócios a analista de SOC?
R: Acredito que literalmente qualquer experiência pode levar alguém a ser um grande profissional de segurança e talvez possa apontar exemplos de cada um. Então, definitivamente um analista de negócios pode se tornar um analista SOC.
Em outros aspectos, esta é uma pergunta difícil, pois dependeria muito da pessoa. Claro, alguns dos melhores analistas de segurança em particular e profissionais de segurança em geral vêm de todos os tipos de experiências, incluindo algumas que são muito incomuns – como música ou física. No entanto, essa pessoa definitivamente terá que aprender muito sobre segurança da informação, tecnologia e prática, etc, e cobrir os domínios técnicos e não técnicos da segurança.
P: Qual é o problema mais comum encontrado quando você tem o SOC gerenciado por um fornecedor terceirizado?
A: Isso é algo que eu mencionei muitas vezes dentro minha escrita anterior do analista. O problema mais comum entre um cliente e o provedor de serviços gerenciados é um incompatibilidade de expectativas. Quando os clientes abordam um terceiro para serviços de segurança gerenciados e sua expectativa é que “eles pagariam dinheiro” e “eles obteriam segurança”, o desastre é quase certo. Um modelo mais saudável que resolve esse problema é pensar em seu trabalho com esse terceiro como operação conjunta (“JointOps” alguém?) Seu SOC, em vez de usar a temida “palavra” – terceirização.
Vamos ver o que a IA pensa:
Agora, as perguntas abaixo são do webinar BlackHat “Modernização do SOC: para onde vamos a partir daqui?”
P: Com o desenvolvimento ágil de aplicativos em uma grande organização, existem dicas para integrar melhor esses aplicativos de nuvem nativos, pipelines etc. com o SOC?
R: eu tenho uma apresentação inteira em grande parte sobre isso e embora não entre em todos os detalhes, gostaria de apontar para você lá. Definitivamente, é necessário mais trabalho nisso, pois vejo muitos que lutam com “DevOps rápido, encontram segurança lenta” em várias formas dessa doença.
P: Você acha que o “SOC” inclui recursos de desenvolvimento ou é uma função mais investigativa ou … alguma recomendação para pequenas e médias empresas com recursos limitados de “SOC”?
R: Este tópico surge muito e eu diria que existem empresas que tratam seu SOC apenas como a equipe assistindo as telas enquanto eles têm mais componentes de engenharia fora do SOC. Talvez você possa chamá-lo um modelo mais tradicional.
No entanto, na minha opinião, um SOC moderno integra fortemente analistas de segurança com pessoas que desenvolvem detecções. Em última análise, este modelo evolui mais de perto para o nosso operação estilo ASO Onde eles são as mesmas pessoas
P: Com a ascensão do SOAR/XDR/etc. e outras ferramentas, você ainda vê o SIEM como o principal mecanismo ou sistema operacional do SOC?
R: Esta é uma pergunta fascinante que tem muitas nuances em resposta. A resposta curta é que ainda vejo alguns recursos de análise de log (como SIEM) como o centro de muitas equipes de SOC.
No entanto, eu insistiria nisso como antes? Não, neste ponto já vi o suficiente das equipes SOC centradas em EDR (por exemplo) que realmente usam suas ferramentas de endpoint como um console principal e tratam a análise de log como auxiliar.
Também vi organizações que centralizam seu SOC em sua ferramenta SOAR, que acessa dados de SIEM ou EDR, mas, em última análise, os analistas vivem dentro do console SOAR a maior parte do tempo.
No futuro, isso pode muito bem ser reequilibrado. É muito possível que estejamos no pico de EDR e, à medida que os serviços nativos da nuvem forem adotados mais amplamente, a importância do endpoint diminuiria novamente, mas a importância dos logs – e isso provavelmente significa que o SIEM – aumentará.
Ver “Você pode fazer um SOC sem SIEM?” para mais detalhes.
P: No ambiente misto de nuvem e no local, você acha que faz sentido instalar o agente de análise de comportamento do usuário no laptop?
R: Na minha experiência, o monitoramento de funcionários baseado em endpoint aborda casos de uso especiais que algumas organizações podem ter, enquanto muitas não. Portanto, eu diria que as ferramentas de monitoramento de usuários baseadas em endpoints permanecem populares em organizações selecionadas, como aquelas que dão grande importância a ameaças internas. Para eles, instalar os agentes para um monitoramento mais profundo dos funcionários faz sentido para os outros, não tenho tanta certeza…
P: Considerando seu comentário sobre SOCs centrados em EDR, você acha que os SOCs deveriam migrar para serem mais centrados na identidade à medida que os clientes migram para os serviços de nuvem/SaaS?
R: Meus ex-colegas do Gartner apenas cunhou o termo ITDR que significa detecção e resposta de encadeamento de identidade. Embora possamos debater se um novo acrônimo é necessário aqui, isso não é discutível: os ambientes de nuvem dão maior importância a esse tipo de monitoramento e detecção.
No entanto, muito do monitoramento centrado na identidade é, de fato, um recurso muito tradicional do SIEM e UEBA (agora parte do SIEM). de volta quase 20 anos…
P: A principal tendência aqui é usar um SOC baseado em instalações para monitorar/gerenciar mais recursos de nuvem ou enviar mais funções de SOC para a nuvem?
Um poço, “Hoje, você realmente quer um SIEM SaaS!”– então eu acredito muito na maioria das tecnologias SOC sendo baseadas em nuvem e nativas em nuvem. Como dizemos em nosso papel ASO original , implantar ferramentas como SIM baseado em nuvem e EDR baseado em nuvem torna-se quase a única opção para muitas organizações. Se eu tiver uma equipe limitada, prefiro que essa equipe use as ferramentas e forneça valor de segurança em vez de manter e gerenciar a ferramenta.
Apreciar!
Perguntas e respostas combinadas do webinar SOC: de EDR a ITDR e ASO… e ChatGPT foi publicado originalmente em Anton em Segurança no Medium, onde as pessoas continuam a conversa destacando e respondendo a esta história.
*** Este é um blog distribuído pela Security Bloggers Network de Histórias de Anton Chuvakin no Mediumautoria de Anton Chuvakin. Leia a postagem original em: https://medium.com/anton-on-security/combined-soc-webinar-qa-from-edr-to-itdr-and-aso-95ecec02782?source=rss-11065c9e943e——2