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.

Instancia Reservada no Azure–Mudanças Importantes

10 setembro 2019 msincic Azure, Microsoft Azure, Windows Azure
A algum tempo que já temos disponivel o recurso de comprar antecipadamente uma instância de maquina virtual, chamado de Reserved Instance. Basicamente o processo se mantem (http://www.marcelosincic.com.br/post/Reducao-de-Custos-com-Azure-Reserved-Instance.aspx) mas temos algumas novidades e alertas: Alteração do tipo de VM Outros recursos que podem ser reservados Mudança na forma de cobrança O que não está incluido em uma reserva Possibilidade de Alteração da Instância (perfil de VM) Essa mudança é importante, pois na primeira versão (link acima) não era possivel mudar o tipo de VM. O processo para mudar era pedir o reembolso da instância já paga (lembrar que existia um penalty) e refazer com outro tipo de VM da mesma familia, como por exemplo de D2 para D4. Para isso basta utilizar o botão Exchange em uma reserva e será possivel escolher o novo tipo de VM como abaixo sem o penalty dos aproximadamente 12% do cancelamento. Porem, obviamente que o custo de uma D2 é diferente de uma D4 e para isso temos uma tabela que pode ser usada no calculo para saber o valor da diferença que será pago quando trocar entre os tipos de VM em https://docs.microsoft.com/en-us/azure/virtual-machines/windows/reserved-vm-instance-size-flexibility?wt.mc_id=4029139  Outros Tipos de Recursos Alem das VMs Na versão inicial as RIs eram apenas VMs, mas agora é possivel fazer com diversos tipos de serviços. Atualmente segue a lista dos que são suportados:   Reserved Virtual Machine Instance Azure Cosmos DB reserved capacity SQL Database reserved vCore SQL Data Warehouse App Service stamp fee Essa lista é alterada conforme novos recursos podem ser agregados e está disponivel em https://docs.microsoft.com/en-us/azure/billing/billing-save-compute-costs-reservations?wt.mc_id=4029139 Importante: Veja o tópico abaixo sobre o que é incluido ou não no RI. Forma de Pagamento Mensal Até 8/Setembro/19 só era possivel o pagamento antecipado a partir de créditos do Enterprise Agreeement ou pagamento em cartão de crédito. Agora é possivel o pagamento mensal, ou seja todos os meses irá consumir o valor com desconto igual ao anual como se fosse uma subscrição mensal e não anual. O melhor para entender é que o compromisso continua anual, mas pago mensal ao invés de upfront. As outras regras continuam as mesmas, penalty em caso de cancelamento, mudança do tipo de VM ou serviço, etc. Para os que já tem reservas será necessário aguardar o prazo da compra, uma vez que foi pago antecipado e por isso haveria a cobrança da taxa de cancelamento. https://docs.microsoft.com/en-us/azure/billing/billing-monthly-payments-reservations?wt.mc_id=4029139 Importante: O pagamento mensal não mudou a forma de reserva ser anual, ou seja haverá o penalty em caso de cancelamento. Recursos Cobrados em Separado Uma confusão muito comum nos clientes que compraram RIs é o fato de continuar havendo outras cobranças para as VMs e recursos aparecendo em seus extratos. O que precisa estar claro é que reservas se referem apenas aos recursos computacionais e não os recursos agregados como licenças, armazenamento e trafego de rede. Por exemplo, no tipo de reserva para VMs que são as mais comum: Incluido no RI: CPU, memória e alocação Não incluido no RI: Armazenamento (storage), tráfego de rede (network) e licenciamento do SO se não foi utilizado o AHUB O motivo é que estes recursos não incluidos fazem parte da subscrição e são compartilhados ou opcionais (como é o caso da licença do Windows ou SQL) e não haveria como limitar ao uso apenas daquelas reservas especificas, alem de serem voláteis diferente do tipo de uma VM por exemplo. Conclusão Com os novos recursos que podem ser reservados, flexibilidade na alteração, a nova forma de cobrança e o entendimento correto pode-se gerar uma economia substancial para aqueles que migraram serviços.

Azure Virtual Datacenter (VDC) Parte II-Conceitos Básicos

18 março 2019 msincic Active Directory, Azure Stack, Cloud computing, Microsoft Azure, Windows Azure Pack
No post anterior falamos sobre a migração para Cloud http://www.marcelosincic.com.br/post/Azure-Virtual-Datacenter-(VDC)-Parte-I-Migracao-AS-IS-e-TO-BE.aspx  Neste post vamos entender os conceitos básicos, que são representados por esse diagrama: Cada parte representa um dos pilares que sustentam um Datacenter Virtual: Encriptação – Todos os dados trafegados dentro de um datacenter onde vários clientes se hospedam precisam ser protegidos de forma que um não tenha acesso aos dados de outros. Isso envolve criptografia de comunicação, discos e trafégo Identity – Um modelo consistente de identidade onde os clientes consigam se logar e ver seus objetos com todos os recursos disponiveis. No caso do Azure isso é feito pelo Active Directory multi-tenant (multi locatário). Como já conhecido no mercado sistemas de diretório permitem que multiplas empresas estejam hospedadas e compartilhem o modelo de banco de dados e autenticação com total isolamento Software-Defined Networks – Como hospedar vários clientes se todos querem ter o mesmo range de IP e se comunicam pelos mesmos conjuntos de cabos? Esse é o desafio das SDNs, permitir trafego isolado. No passado faziamos isso com o recurso de VLAN mas era limitado a 65535. Hoje isso é feito de forma lógica por usar recursos como o NVRE e outros onde os pacotes de rede são tageados (marcados) a quem pertence, similar ao que a VLAN fazia mas sem o limite de 32 bits. Isso permite que multiplos clientes tenha o mesmo range de IP 10.0.0.0/24, já que cada rede virtual recebe um diferente TAG nos pacotes, com a criptografia e identidade garantindo a confiabilidade na entrega dos pacotes de dados Compliance – De nada adiantaria se ao migrar para um datacenter público você ficasse preso a padrões que só funcionam lá. As clouds publicas precisam adotar os padrões de mercado para as redes se comunicarem. Isso não quer dizer que a forma como o Machine Learning da Microsoft é codificado é igual ao Machine Learning da AWS, mas sim que a parte básica segue padrões de interoperabilidade. Por exemplo, uma VMs na AWS pode se comunicar por IP com uma VM no Azure ou no Google Cloud, pois todas usam os mesmos protocolos, mesmo que um provedor tenha serviços agregados diferentes. O mesmo vale para uma aplicação em Moodle ou SAP, se está no Azure ou AWS não importa pois seguem os padrões de rede e comunicação (interchange) identicos. Por conta do compliance que posso deixar metade dos meus servidores local e os outros espalhados em 3 diferentes datacenter publicos e todos se comunicando normalmente. Logging, Audit e Report – Ao migrar de uma nuvem privada (local) para uma pública preciso saber os custos e ter certeza que meus dados estão seguros e acessados só pelos meus usuários. Aqui não estamos tratando de log, auditoria e reports para o cliente e sim a infra interna para que o provedor tenha certeza que não há vazamento de dados, quem fez cada operação e reportar isso quando necessário. Por isso os cockpits de provedores de cloud pública são gigantescos. Precisam controlar e serem capazas de se refazer em qualquer tipo de falha que ocorra. Os primeiros datacenters surgiram do conceito de hosting, ou seja você tirava os servidores do seu rack em casa para levar ao provedor onde a eletrica, links e segurança fisica ficam por conta deles. Nesse modelo toda a responsabilidade de comunicação, segurança lógica e relatórios é sua. No modelo público uma boa parte dos recursos são alocados para controlar os recursos, por exemplo ao criar o antigo Microsoft Azure Pack (atualmente descontinuado) várias VMs eram criadas com o objetivo de fornecer os itens de controle. Conclusão Nesse segundo post falamos sobre os componentes básicos que formam uma cloud pública. Sinta-se seguro ao colocar seus dados nesses provedores, eles são preparados para garantir o isolamento e segurança dos seus dados.

Disponivel para Compra o Azure Reserved Instance

20 novembro 2017 msincic Azure, Microsoft Azure
Em um post no inicio do mês comentamos sobre o Azure Reserved Instance em http://www.marcelosincic.com.br/post/Reducao-de-Custos-com-Azure-Reserved-Instance.aspx Agora já está disponivel para compra e tambem na calculadora do Azure (Azure Pricing Calculator) para estimar a economia tanto apenas a VM quanto com o AHUB. Para relembrar, o AHUB é o recurso que permite economia por utilizar as licenças já adquiridas que tenha Software Assurance http://www.marcelosincic.com.br/post/Software-Asset-Management-(SAM)-Convertendo-Licenciamento-para-Azure.aspx Utilizando a Calculadora Acesse a calculadora de custos do Azure e ao acrescentar uma VM verá a opção de incluir o AHUB e tambem o RI de 1 ou 3 anos. Abaixo seguem as imagens demonstrando como escolher e a redução possivel onde de $102 para uma VM normal, caimos para $58 em uma VM RI de 3 anos e juntando o AHUB para U$ 24!!!!! E por ultimo com a opção de AHUB: Comprando Reserved Instance no Portal do Azure A compra do RI pelo portal exige que primeiro seja ativada a oferta na assinatura. É importante que assinaturas de beneficio MSDN ou EA Dev/test não possuem o RI pois já tem um custo de 40 a 60% menor nas VMs. Resumindo: Agora podemos ter uma VM com mais de 80% de desconto juntando as ofertas de RI e AHUB!!!

Site para Teste de Rede com Azure

14 abril 2017 msincic Azure, Cloud computing, Windows Azure
Muito comum quando estamos em projetos com Azure termos o questionamento sobre os custos e recursos disponiveis fora do Brasil versus latencia. Para equalizar este tipo de situação, podemos usar o site http://www.azurespeed.com/ Alem do teste de latência podemos fazer testes de download e upload, ranges de IP usados por cada datacenter e outras informações bem interessantes.

Novo Azure AD Connect

29 junho 2015 msincic Microsoft Azure, Active Directory, Windows Azure
Na semana passada a Microsoft liberou a nova ferramenta para sincronização de AD local com o Azure AD. Essa nova ferramenta tem as mesmas funcionalidades das anteriores DirSync e ADDSync, mas acrescesta facilidade na administração do serviço e acesso aos conectores. Para baixar e ver detalhes: https://azure.microsoft.com/en-gb/documentation/articles/active-directory-aadconnect/ Instalação e Upgrade do Dirsync Para quem já tem o Dirsync ou o ADDSync instalado o Azure AD Connect irá fazer o upgrade e solicitar apenas a credencial do Azure para configurar, mas após o upgrade é possivel alterar facilmente as configurações. A sequencia abaixo mostra o upgrade, sendo bem simples pedindo apenas as contas online e on-premisse:     Configuração Pós-Instalação A interface do Azure AD Connect é realizada com ferramentas gráficas acessiveis pelo Menu Iniciar: A ferramenta que torna mais fácil configurar como comentado no inicio do artigo é o Synchronization Service, onde ao abrir já é possivel ver os conectores habilitados, o estado da sincronização, log das ultimas sincronizações e utilitários na lateral: Por exemplo, para sincronizar manualmente basta clicar sobre uma das conexões e escolher como quer sincronizar (Connectors –> Run): Visualização, Atualização e Criação de Conectores Ao clicar em qualquer um dos conectores abre-se um wizard onde podemos alterar os conectores básicos ou criar novos conectores. O wizard é muito simples e funcional, como mostram as imagens abaixo utilizando o Properties: E para criar novos conectores, ao clicar em Create temos criar os diversos tipos de conectores on-premisse ou online utilizando o wizard das imagens acima. Vale a pena fazer o upgrade para quem tem o Dirsync e o AADSync, pois esta nova ferramenta é muito completa e simples facilitando o acesso aos configurações, alterações e log das operações.