Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
As equipas do Centro de Operações de Segurança (SOC) utilizam soluções centralizadas de gestão de informações e eventos de segurança (SIEM) e orquestração de segurança, automatização e resposta (SOAR) para proteger o património digital cada vez mais descentralizado. Embora os SIEMs legados possam manter uma boa cobertura dos recursos no local, as arquiteturas no local podem não ter cobertura suficiente para recursos da cloud, como no Azure, Microsoft 365, AWS ou Google Cloud Platform (GCP). Por outro lado, Microsoft Sentinel podem ingerir dados de recursos no local e na cloud, garantindo cobertura sobre todo o património.
Este artigo aborda as razões para migrar a partir de um SIEM legado e descreve como planear as diferentes fases da migração.
Passos de migração
Neste guia, vai aprender a migrar o seu SIEM legado para Microsoft Sentinel. Siga o seu processo de migração através desta série de artigos, nos quais irá aprender a navegar em diferentes passos no processo.
Nota
Para um processo de migração guiado, adira ao Programa de Migração e Modernização do Microsoft Sentinel. O programa permite-lhe simplificar e acelerar a migração, incluindo orientações de melhores práticas, recursos e ajuda especializada em todas as fases. Para saber mais, contacte a equipa da sua conta.
O que é o Microsoft Sentinel?
Microsoft Sentinel é uma solução de orquestração, automatização e resposta (SOAR) dimensionável, nativa da cloud, de informações e eventos de segurança (SIEM). Microsoft Sentinel fornece análises de segurança inteligentes e informações sobre ameaças em toda a empresa. Microsoft Sentinel fornece uma solução única para deteção de ataques, visibilidade de ameaças, investigação proativa e resposta a ameaças. Saiba mais sobre Microsoft Sentinel.
Porquê migrar de um SIEM legado?
As equipas SOC enfrentam um conjunto de desafios ao gerir um SIEM legado:
- Resposta lenta a ameaças. Os SIEMs legados utilizam regras de correlação, que são difíceis de manter e ineficazes para identificar ameaças emergentes. Além disso, os analistas do SOC são confrontados com grandes quantidades de falsos positivos, muitos alertas de muitos componentes de segurança diferentes e volumes cada vez mais elevados de registos. A análise destes dados atrasa as equipas do SOC nos seus esforços para responder a ameaças críticas no ambiente.
- Desafios de dimensionamento. À medida que as taxas de ingestão de dados aumentam, as equipas SOC são desafiadas com o dimensionamento do SIEM. Em vez de se concentrarem na proteção da organização, as equipas do SOC têm de investir na configuração e manutenção da infraestrutura e estão vinculadas por limites de armazenamento ou consulta.
- Análise e resposta manuais. As equipas SOC precisam de analistas altamente qualificados para processar manualmente grandes quantidades de alertas. As equipas soc estão sobrecarregadas e novos analistas são difíceis de encontrar.
- Gestão complexa e ineficiente. Normalmente, as equipas SOC supervisionam a orquestração e a infraestrutura, gerem ligações entre o SIEM e várias origens de dados e executam atualizações e patches. Muitas vezes, estas tarefas são à custa da triagem e análise críticas.
Um SIEM nativo da cloud aborda estes desafios. Microsoft Sentinel recolhe dados automaticamente e em escala, deteta ameaças desconhecidas, investiga ameaças com inteligência artificial e responde rapidamente a incidentes com automatização incorporada.
Planear a migração
Durante a fase de planeamento, identifica os componentes SIEM existentes, os processos SOC existentes e cria e planeia novos casos de utilização. Um planeamento minucioso permite-lhe manter a proteção para os seus recursos baseados na cloud ( Microsoft Azure, AWS ou GCP) e para as suas soluções SaaS, como Microsoft Office 365.
Este diagrama descreve as fases de alto nível que uma migração típica inclui. Cada fase inclui objetivos claros, atividades-chave e resultados e materiais a entregar especificados.
As fases neste diagrama são uma orientação para como concluir um procedimento de migração típico. Uma migração real pode não incluir algumas fases ou pode incluir mais fases. Em vez de rever o conjunto completo de fases, os artigos neste guia analisam tarefas e passos específicos que são especialmente importantes para uma migração Microsoft Sentinel.
Considerações
Reveja estas considerações-chave para cada fase.
| Fase | Consideração |
|---|---|
| Descobrir | Identifique casos de utilização e prioridades de migração como parte desta fase. |
| Design | Defina uma estrutura e arquitetura detalhadas para a implementação Microsoft Sentinel. Irá utilizar estas informações para obter a aprovação dos intervenientes relevantes antes de iniciar a fase de implementação. |
| Implementar | À medida que implementa Microsoft Sentinel componentes de acordo com a fase de conceção e antes de converter toda a infraestrutura, considere se pode utilizar Microsoft Sentinel conteúdo inicial em vez de migrar todos os componentes. Pode começar a utilizar Microsoft Sentinel gradualmente, começando com um produto mínimo viável (MVP) para vários casos de utilização. À medida que adiciona mais casos de utilização, pode utilizar esta instância Microsoft Sentinel como um ambiente de teste de aceitação do utilizador (UAT) para validar os casos de utilização. |
| Operacionalizar | Migra os seus conteúdos e processos SOC para garantir que a experiência do analista existente não é interrompida. |
Identificar as suas prioridades de migração
Utilize estas perguntas para afixar as suas prioridades de migração:
- Quais são os componentes de infraestrutura, sistemas, aplicações e dados mais críticos na sua empresa?
- Quem são os intervenientes na migração? É provável que a migração SIEM toque em muitas áreas da sua empresa.
- O que impulsiona as suas prioridades? Por exemplo, maior risco comercial, requisitos de conformidade, prioridades empresariais, etc.
- Qual é o seu dimensionamento e linha cronológica de migração? Que fatores afetam as suas datas e prazos. Está a migrar um sistema legado completo?
- Tem as competências de que precisa? A sua equipa de segurança está preparada e pronta para a migração?
- Existem bloqueadores específicos na sua organização? Algum problema afeta o planeamento e o agendamento da migração? Por exemplo, problemas como requisitos de pessoal e formação, datas de licença, paragens difíceis, necessidades empresariais específicas, etc.
Antes de começar a migração, identifique os principais casos de utilização, regras de deteção, dados e automatização no SIEM atual. Aborde a migração como um processo gradual. Seja intencional e atencioso sobre o que migra primeiro, o que desprioritiza e o que realmente não precisa de ser migrado. A sua equipa pode ter um grande número de deteções e casos de utilização em execução no seu SIEM atual. Antes de iniciar a migração, decida quais são ativamente úteis para a sua empresa.
Identificar casos de utilização
Ao planear a fase de deteção, utilize a seguinte documentação de orientação para identificar os seus casos de utilização.
- Identifique e analise os seus casos de utilização atuais por ameaça, sistema operativo, produto, etc.
- Qual é o âmbito? Pretende migrar todos os casos de utilização ou utilizar alguns critérios de atribuição de prioridades?
- Identifique que recursos de segurança são mais críticos para a sua migração.
- Que casos de utilização são eficazes? Um bom ponto de partida é ver quais as deteções que produziram resultados no último ano (falso positivo versus taxa positiva).
- Quais são as prioridades empresariais que afetam a migração de casos de utilização? Quais são os maiores riscos para o seu negócio? Que tipo de problemas colocam a sua empresa mais em risco?
- Priorize por características de caso de utilização.
- Considere definir prioridades mais baixas e mais elevadas. Recomendamos que se concentre nas deteções que impõem 90% de verdadeiro positivo nos feeds de alerta. Casos de utilização que causam uma elevada taxa de falsos positivos podem ser uma prioridade mais baixa para a sua empresa.
- Selecione casos de utilização que justifiquem a migração de regras em termos de prioridade e eficácia empresariais:
- Reveja as regras que não acionaram alertas nos últimos 6 a 12 meses.
- Elimine ameaças de baixo nível ou alertas que ignora regularmente.
- Preparar um processo de validação. Defina cenários de teste e crie um script de teste.
- Pode aplicar uma metodologia para priorizar casos de utilização? Pode seguir uma metodologia como o MoSCoW para priorizar um conjunto mais magro de casos de utilização para migração.
Passo seguinte
Neste artigo, aprendeu a planear e a preparar a migração.