Evitando vazamento de dados com o Microsoft Purview

22 novembro 2022 msincic Cloud computing, Microsoft Defender, Microsoft 365, Office 365, Office Communications, Segurança
Durante o Microsoft Ignite After Party tive a oportunidade de apresentar novas funcionalidades do Purview que foram lançadas em GA. Aqui abrangemos 4 diferentes funcionalidades que tiveram lançamento, GA ou melhorarias: Data Classification – Classificadores treináveis (Trainable classifiers) e Lista de Dados exatos (EDM) Data Connectors – Conexão com WhatsApp, Google, Workspace, ServiceNow e outros Communication Compliance – Recurso para fazer revisão de possiveis ameaças tanto de DLP quanto abusos Insider Risk Management – Já tratado em outras palestras, mas permite detectar atividades suspeitas em detalhes (https://www.marcelosincic.com.br/post/detectando-atividades-suspeitas-com-o-irm-inside-risk-management.aspx)

Manutenção de Incidentes no Microsoft Sentinel

13 setembro 2022 msincic Azure Sentinel, Cloud computing, Cybersecurity, Governança, Microsoft Sentinel, Microsoft Azure, Segurança
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. 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. 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. Agora seu dashboard de atendimento no SOC terá uma visão muito melhor, sem a necessidade de agregar mais de uma ferramenta.

Entregando Alertas do Sentinel no Teams

29 agosto 2022 msincic Segurança, Azure Sentinel, Cybersecurity, Cloud computing, Microsoft Sentinel
Uma funcionalidade simples e muito funcional do Sentinel na integração com playbooks é a entrega como uma mensagem de chat no Teams. O exemplo abaixo demonstra como os alertas são entregues ao Teams com os detalhes do alerta que foi disparado. Criando o Logic Apps e Regra de Automação Quando são instalados os conectores do Sentinel automaticamente é criado um Logic Apps para automação, sem ter tasks configurados exceto a primeira que é o gatilho de incidente. Esse será o playbook que a todos os alertas habilitados é configurado como forma de resposta padrão. Ao editar o playbook entre no objeto For each que é o loop para possibilitar que vários incidentes sejam disparados e não só o primeiro. Isso pode acontecer em ambientes onde uma situação criou mais de um incidentes e a falta deste loop não dispararia para todos os que ocorressem. Note que o loop do For each lê os dados do incidente e os envia para o email com as propriedades abaixo para titulo, destinatario e texto enviado. No caso abaixo deletei o objeto padrão que era email e troquei pelo objeto Post message in a chat or channel que permite enviar a mensagem tanto para um usuário unico como para um grupo ou canal do Teams: O passo seguinte é criar no Sentinel a regra de disparo para o playbook de notificação. Veja que o nome é parecido por minha opção mas poderá usar qualquer outro nome, que poderá facilitar no momento de relacionar os alertas com a chamada de automação. Habilitando as Regras Analíticas para Envio no Teams Entre nas opções de Analytics do Sentinel, habilite as regras que deseja ser alertado e as edite. Nas opções da regra poderá editar a resposta automática de automação que criamos no passo anterior para que o playbook seja executado. Ao editar as regras pode-se criar novas respostas de automação sem ter que criar antes em Automation como fiz anteriormente, apesar de achar que isso pode gerar multiplos objetos orfãos posteriormente. Mas se desejar criar uma nova resposta, poderá clicar no botão Add new e nomear a automação e indicar qual dos playbooks será executado: Pronto, agora você irá receber os detalhes de incidentes diretamente pelo canal ou chat do Teams!

Lançamento do System Center 2022–Ainda Vale a Pena? Será descontinuado?

07 abril 2022 msincic Cloud computing, Azure OMS, Azure, Configuration Manager, Data Protection Manager, Log Analytics, Governança, Microsoft Azure, Operations Manager, Orchestrator, Service Manager, System Center, Virtual Machine Manager, Azure Stack
A primeira vez que recebi o premio de MVP foi na categoria System Center, que depois alterou para Cloud and Datacenter Management (CDM). Com o crescimento exponencial das clouds publicas os ambientes on-premises passaram a ser integrados também aos recursos disponíveis em cloud publica e/ou migrados. Então recebo constantemente a pergunta “O System Center vai morrer?” e até afirmações “System Center foi descontinuado”. Com o lançamento do System Center 2022 em 1o de Abril voltamos estas perguntas https://cloudblogs.microsoft.com/windowsserver/2022/04/01/system-center-2022-is-now-generally-available?WT.mc_id=AZ-MVP-4029139 Sendo assim vamos a algumas questões e usarei uma apresentação que fiz no MVPConf. O que levou a essas conclusões? Atualizações semestrais foram descontinuadas (1801, 1909, etc), as atualizações seguiram o modelo anterior de Update Rollups a cada 12 a 18 meses e novas versões a cada 3 ou 4 anos Configuration Manager teve sua ultima versão 2012 R2 como a ultima que fazia parte da suíte System Center e passou a ser Enpoint Manager na familia do Intune Service Manager teve um comunicado do time de produtos em 2018 onde afirmavam que o produto não seria descontinuado Operations Manager não tinha uma integração com o Azure Monitor Virtual Machine Manager não dava suporte a recursos novos do Hyper-V e suporte limitado ao Azure Orchestrator com poucos pacotes de integração para 3rd partners Configuration e Endpoint Data Protection Manager Foi deslocado da família System Center para a família Endpoint Management Integração com Intune e novos recursos do Azure como Analytics (Log e Desktop) Possibilidade de utilizar roles diretamente na web (CMG) Licenciamento foi integrado nas licenças de Microsoft 365, Enterprise Mobility Suite (EMS), Intune add-on e CoreCal Bridge Conclusão: O produto não foi descontinuado nem se tornou uma nova família para se “desprender”, e sim um reposicionamento para o time de gerenciamento de Windows. Operations Manager Os Management Packs foram todos atualizados para os produtos novos (Windows Server 2019, Exchange, SharePoint, etc) Foi disponibilizado um Management Pack para Azure que permite fazer toda a monitoração e dashboards, recebeu integração com o Log Analytics, que alimenta os dados para uso no Azure Monitor Reduz custos e tem melhor performance nos alertas para servidores on-premisse, quando o ambiente é integrado com o Azure Monitor Projeto Aquila permitirá usar o SCOM como SaaS (fonte: ZDNET e Directions) Conclusão: Continua como uma ferramenta importante para ambientes on-premisse. Para ambiente cloud o Azure Monitor e outros são indicados. Virtual Machine Manager Está sendo atualizado com os recursos novos do Windows 2019, mas o timeline entre novos recursos do Windows e a inclusão seguem os Update Rollups, de 12 a 18 meses Ainda é muito importante por conta de recursos em Cluster de Hyper-V e monitoração para quem utiliza Windows Admin Center vem incluindo diversos dos recursos que o VMM possui, mas os wizards do VMM são superiores Conclusão: Para grandes Clusters o VMM é indispensável, mas para gerenciamento de servidores Hyper-V segregados o Admin Center é uma boa opção. Data Protection Manager Manteve as características principais de backup apenas de produtos Microsoft on-premisse (SQL, Hyper-V, Exchange, etc) e VMWare. Não tem previsão de inclusão para produtos de terceiros Não suporta serviços do Azure, cada serviço do Azure possui ferramentas próprias de backup. Aceita agentes em Azure VMs, porem deve-se levar em conta custo de download Possui a versão gratuita Microsoft Azure Recovery System (MARS) que é um subset do DPM sem suporte a fitas Conclusão: Para ambientes Microsoft on-premisse ou Azure VMs para discos locais ou fitas ainda é importante, mas ambientes Azure utilizar os recursos nativos de cada serviço. Service Manager Portal de autoatendimento agora em HTML 5 Suporta integração com BMC, ServiceNow e outros, mas alguns conectores são pagos (3rd SW) Manteve-se fiel ao modelo ITIL v3 A construção de workflows foi melhorada incluindo uma interface mais amigável e mais recursos de integração com o Orchestrator Conclusão: É uma ferramenta da suíte que recebeu poucos avanços e manteve sua dependência do Orchestrator, que torna mais complexa a administração. Mas como faz parte da suíte é financeiramente justificável no conjunto. Orchestrator Os Integration Packs foram todos atualizados para os produtos novos (Windows Server 2019, Exchange, SharePoint, etc) Integration Packs de 3rd SW nem todos possuem atualizações, na maioria são pagos Agora suportando PowerShell v4 permite que se crie novas funcionalidades por código, o que remove as limitações dos Integration Packs Conclusão: Continua como uma ferramenta importante para ambientes on-premisse. Para ambiente cloud o Azure Monitor e outros são indicados. Alternativas ao System Center Com os avanços das ferramentas integradas como Hybrid usando Azure Arc e Azure Automation, você poderá estender os mesmos recursos nos servidores on-premises equivalentes ao System Center.