MVP: System Center Cloud and Datacenter Management, MCT, MCSE, MCITP, MCPD, MCDBA
MVP Logo

Últimos posts

Categorias

Tags

Azure Monitor SCOM Managed Instance–System Center Operations Manager no Azure

Em abril deste ano com o lançamento da suite System Center 2022 escrevi se os produtos ainda eram importantes e seus correspondentes em serviços e soluções no Azure Marcelo de Moraes Sincic | Lançamento do System Center 2022–Ainda Vale a Pena? Será descontinuado? (marcelosincic.com.br)

Um destes produtos era o System Center Operations Manager (SCOM) que sempre foi uma ferramenta muito importante na monitoração de ambientes on-premisse.

Como já abordado em abril, o uso de Azure Arc e Azure Monitor pode ser utilizado para ambientes on-premisse mas dependem de internet, geração de alertas correspondentes escritos em KQL e consumindo créditos com a ingestão maciça de eventos do log.

Por exemplo, uma regra construida no SCOM onde relacionamos o log de um servidor com outro usando um Event ID sequencial para indicar uma cadeia de quebra ou então um mapa com objetos relacionados é muito mais complicado de ser construido no Azure Monitor exigindo conhecimento de Notebooks Jupyter e KQL.

O que é o Azure Monitor SCOM Managed Instance

Na prática a Microsoft não está lançando um produto novo ou feature nova mas sim transformando um PaaS um produto que ainda é muito importante para diversas corporações.

O diagrama abaixo disponivel em About Azure Monitor SCOM Managed Instance (preview) | Microsoft Learn deixa bem claro que a funcionalidade se inverte onde o SCOM agora é que está em cloud monitorando o ambiente on-premisse.

Screenshot showing architecture.

Fatores a serem considerados

Com esse novo recurso temos que questionar se irá ou não valer a pena migrar para o ambiente gerenciado e podemos usar estes fatores inicialmente:

Vantagens Desvantagens
  • Não ter que gerenciar os recursos agregados, que normalmente eram o mais “problemático” como o Reporting Services e SQL
  • Utilizar os mesmos Management Packs que o on-premisse
  • Facilidade na implementação e escalabilidade já que todo o processo criativo dos recursos é realizado pelo Azure
  • Licenciamento é o mesmo, aproveitando o investimento nas licenças CIS ou System Center Suite
  • Utilizar o SCOM monitorar as VMs locais no Azure e outras clouds, aproveitando o conhecimento já adquirido no om-premisse, sem a necessidade de enviar dados das Azure VM para o ambiente on-premisse
  • Integração simples com Power BI
  • Custo de ingestão de logs no Azure Monitor utilizando o Arc é maior que o custo de upload dos logs via VPN
  • Custo de infraestrutura no Azure para VMs, Load Balancing e tráfego de dados
  • Situação de link internet invertida, agora não é mais o SCOM que enviaria os dados para o Azure Monitor e sim os servidores on-premisse que enviarão dados para o SCOM, gerando alertas em cascata quando houver queda de link
  • Discovery para instalação automática não é suportado (1)
  • Não é possível ter Management Servers no ambiente on-premisse (2)

(1) Até o momento não disponivel no Preview

(2) Até o momento não é suportado, mas permite o uso de Gateway Server

Manutenção de Incidentes no Microsoft Sentinel

Um recurso que testamos no Private Preview e agora está em GA é a manutenção de incidentes, que envolve a deleção e criação.

Create and delete incidents in Microsoft Sentinel - Microsoft Tech Community

Deleção de Incidentes

Pode parecer em um primeiro momento que deletar um incidente no ambiente de SOC seja uma tarefa fora do padrão, pois poderia ser usado para esconder ou melhorar uma estatística (KPI) do time de atendimento.

Apesar de aparente contradição, esse recurso é importante pois nem sempre um incidente é encerrado ou tratado. Um exemplo comum é o Adaptative application que responde repetidamente a aplicações como o próprio Azure Arc ou Automation.

Em casos em que o incidente não foi efetivo e nem um falso positivo por não ter a ver com uma brecha de segurança efetiva, a deleção pode ser um recurso útil ao invés de você passar a ignorar o alerta. Afinal, um dia uma aplicação realmente suspeita irá rodar no servidor e por ter ignorado a regra de aplicações suspeitas você não irá saber.

image

Como pode ser visto acima, o recurso está bem visivel e acessível.

Observação: Incidentes gerados por integração com Microsoft 365 Defender não podem ser deletados, já que foram linkados.

Importante: Na tabela SecurityIncident estará registrado o incidente e quem o deletou. Não existe uma lixeira para recuperar o incidente, mas os alertas e o próprio incidente continuam registrados nas tabelas de log e você poderá eventualmente auditar os incidentes deletados para evitar manipulações indevidas.

Captura de tela 2022-09-13 095509

Criação Manual de Incidentes

Esse recurso era esperado a um tempo e nem precisa de muita explicação, afinal usávamos alertas customizados para criar incidentes customizados. Isso dava trabalho, já que era necessário identificar uma situação que pudesse gerar um incidente mas que não fosse mapeada. Por exemplo um evento especifico que geravamos manual e mapeavamos um alerta em KQL para criar um incidente de um caso especifico.

Mas isso nem sempre funcionava, por exemplo digamos que um usuário recebeu um phishing em seu email pessoal e abriu no computador da empresa e consequentemente não foi detectado pelo MDE. Neste caso registramos o incidente manualmente para constar nas atividades de SOC.

Outro caso muito comum são as atividades de chamados de programas que não puderam ser instalados, atividades que foram barradas e foi necessário criar algum tipo de mitigação, etc. Nestes casos hoje o SOC não tinha como registrar estes incidentes, normalmente oriundos do sistema de chamados.

O processo é bem simples, você irá utilizar o botão de criação de incidentes e informar todos os campos necessários e depois trabalhar com ele como faz com os outros incidentes.

image

Agora seu dashboard de atendimento no SOC terá uma visão muito melhor, sem a necessidade de agregar mais de uma ferramenta.

Detectando Atividades Suspeitas com o IRM - Inside Risk Management

Detectar atividades suspeitas trabalha com o comportamento dos usuários.
Esse comportamento não se limita ao DLP, mas abrange:
  • Regras de Proteção de Dados do MPIP (antigo Microsoft Information Protection)
  • Regras do MDE (Microsoft Defender Endpoint)
  • Regras do MDfC (Microsot Defender for Cloud Apps, antigo CASB)
  • Log de atividades do Office 365 e do Windows
Uma vez que eu capturo estes dados posso criar uma linha de tempo (baseline) para detectar:
  1. Comportamentos inesperados de uma pessoa em relação a sua própria atividade nos ultimos 30 a 90 dias
  2. Comportamento inesperado de uma entidade comparada ao baseline da empresa como um todo
Para isso são criados gatilhos que podem ser atividades como uma regra DLP, copia de arquivos em um pendrive, exfiltração via web, etc.
Apresentei todos estes recursos no webcast com a Thais Mafra. Assista e entenda melhor este recurso!

Microsoft Sentinel–Automações não são executadas

Um erro muito comum quando vejo as implementações de Sentinel em clientes é não executar as automações.

Para entender o problema, é interessante interligar com aplicações Power Platform como o Power Apps, onde o usuário precisa autorizar a conta do Office 365 para que o app execute. Isso é feito na primeira execução e o Power Apps ou Power Automate irá guardar o usuário da conexão.

O mesmo acontece com as automações do Sentinel, elas não estão necessariamente interligadas a uma Automation Account e com isso é necessário autenticar todas as conexões!

Como saber se tenho automações não autenticadas?

Abra o Sentinel e clique em Automações.

Ao abrir clique na opção que irá aparecer no topo da lista do lado direito “API Connections”.

Faça um filtro pelas automações que estão com erros.

PPV 
; : - 0 -535F 
麟 一 do $ n , • 一 dwpa " 一 凵 
SUO!PBUUO) IdV

Para as automações que estão com erro na conexão, abra suas propriedades e vá para a opção “Edit API Connection” e voilá achou o problema 😊