Utilizando o Defender EASM e o Defender TI

01 novembro 2023 msincic Azure, Azure Sentinel, Cloud computing, Cybersecurity, Governança, Microsoft Defender, Segurança
Já comentei em posts passados sobre o MDTI (Microsoft Defender for Threat Intelligence) quando integrado com o Sentinel para detectar com KQL indicadores de ataque ou comprometimento (https://www.marcelosincic.com.br/post/Utilizando-os-IoCs-do-Microsoft-Defender-Threat-Intelligence.aspx). Desta vez vamos introduzir uma nova ferramenta que é o EASM (Defender External Attack Surface Management) onde ao indicar um “seed” que podem ser nomes de domínios, IPs de hosts ou DNS ele faz a procura por indicadores de possível ataque. Ele é abrangente por não apenas olhar os Threat Indicators na base do MDTI, mas incluir na analise os certificados vencidos, CVEs que estão expostos, técnicas OWASP, postura de segurança nas configurações e aderência ao GDPR. O melhor de tudo: O EASM É GRATUITO NOS PRIMEIROS 30 DIAS! Habilitando e Configuração Inicial O processo é muito simples, segue um passo a passo: Crie o recurso no Azure, onde informará subscrição, grupo de recursos e tags basicamente Entre nas configurações em “Discovery” e crie a raiz de procura (ou seed) com o “Discovery Group” Nas configurações da procura indique a periodicidade e o que quer procurar Aqui tem um ponto interessante, onde empresas e organizações conhecidas podem ser pré-carregadas na opção de “Import…” que são empresas já conhecidas por bases de internet comum Lembre-se de colocar exclusões caso possua servidores honeypot para não gerar alertas desnecessários Agora é só aguardar de 48 a 72 horas para que a descoberta gere os dados. Analisando os dados gerados No Overview já é possível detectar os diferentes itens que precisam ser observados na forma de listas em tabs. Nesta lista eu já detecto IPs suspeitos por ser utilizado em distribuição de malware na base do MDTI. Olhando ali descobrimos um IP antigo que utilizei em um servidor que hoje é um indicador de ataque: Aqui já pode ser visto um resumo e o indicativo de que um dos IPs é suspeito: O próprio EASM já carrega as informações indicando qual tipo de ataque este IP está sujeito e está registrado no MDTI: Abrindo as tabs de obervação do host podemos ver o que este host hospeda, certificados, reputação e todos os detalhes: Também já tenho uma visão de todos os certificados usados no host para os diferentes domínios, o que me permite detectar certificados internos e externos que estejam vencidos ou próximos de vencer: Neste exemplo descobri mais tarde investigando que um dos dominios hospedados no mesmo servidor estava com vulnerabilidades e sendo usado para distribuição de um site de videos. Alterei o host e removi o registro DNS que apontava para este host, que na verdade era apenas um registro de verify antigo e não estava mais ativo. Conclusão Com o uso do EASM podemos monitorar nossos recursos que estão expostos na internet e assim proteger a nós mesmos e aos nossos clientes!

Utilizando os IoCs do Microsoft Defender Threat Intelligence no Sentinel

03 setembro 2023 msincic Azure Sentinel, Cloud computing, Cybersecurity, Governança, Microsoft Azure, Microsoft Sentinel, Segurança, Windows Azure, Azure, Microsoft Defender
A alguns anos que a Microsoft adquiriu a RiskIQ e lançou recentemente o Microsoft Defender for Threat Intel (MDTI). O que é o MDTI? Já tratei algumas vezes sobre IoCs, ou indicadores de comprometimento em inglês, e como eles podem ser integrados como o caso do VirusTotal (Marcelo Sincic | Enriquecendo o Sentinel com dados do Virus Total). Nesse post vamos falar da solução do MDTI e como integrar a base dele ao Senitnel e utilizar para hunting e análise de incidentes e alertas em seu ambiente. Primeiramente é importante saber que o serviço MDTI é pago por usuário em um modelo de licenciamento por contrato, mas a base de dados pode ser importada para o Sentinel por meio de um conector. Conectando o Sentinel a base do MDTI Para isso você precisará instalar a solução Microsoft Defender for Threat Intel no Sentinel a paritr do Content Hub e depois configurar o Data Connector como abaixo: Uma vez configurado será feita a ingestão diária os dados do MDTI para a base Threat Intelligence do Sentinel: Importante lembrar que os IoCs ingeridos do MDTI irão se somar aos IoCs customizados ou importados de outras bases que você tenha configurado. Configurando as integrações de Log com TIs Ao instalar a solução e fazer a configuração do conector de dados, o passo seguinte é configurar e instalar as regras de cruzamento de dados utilizando o Analytics do Sentinel. São varias regras diferentes que você poderá utilizar que já estão prontas: Estas regras são compostas de consultas KQL que analisar um alerta e incidente para cruzar co ma base de IoCs importadas, resultando em um enriquecimento de dados ao validar que um determinado IP ou URL maliciosa foi acessada ou tentou acessar seu ambiente. Claro que isso pode ser feito manualmente, bastaria rodar uma query KQL manual ou customizada no Sentinel em hunting queries para cruzar IPs e URLs com os diferentes logs do Sentinel existentes. Um exemplo disso foi um recente cliente onde discutimos o cruzamento do log do Umbrella DNS com o MDTI para detectar sites maliciosos acessados pelos usuários. Visualizando os incidentes com os dados do MDTI Agora vem a parte prática. Tudo configurado você terá alertas e incidentes novos em seu ambiente: Vamos abrir os detalhes do primeiro e ver o IP que indica um ataque potencial: Uma vez que no proprio incidente já sei que o IP é considerado suspeito, podemos investigar os detalhes importados na base para visualizar os detalhes: E por fim, vou utilizar a interface do MDTI para consultar os dados do IP, lembrando que neste caso preciso ter uma licença de MDTI para ver os detalhes: Vamos agora fazer o mesmo processo com o segundo incidente de exemplo que tenho na minha lista e abrir os detalhes no MDTI: Conclusão O serviço Microsoft Defender for Threat Intel (MDTI) irá ajudá-lo a detectar diversas formas de ataques vindas de ofensores e grupos profissionais ou previamente identificados. Alem disso, sua base é rica em detalhes do tipo de ataque, alvos e grupos que atuam com aquele IoC especifico que foi utilizado para tentar acesso ao seu ambiente.

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

14 dezembro 2022 msincic Operations Manager, System Center, Windows Azure, Azure, Microsoft Azure, Cloud computing, Governance, Governança
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. 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

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.