Já em preview privado a algumas semanas, hoje a Microsoft liberou para o público (GA) as alterações do Defender for Cloud para a postura de segurança.

Porque renomear de Secure Score para Secure Posture?

Dizer que você está 100% seguro não quer dizer que realmente não corre risco, e dizer que você possui uma postura 100% segura não quer dizer que não tem vulnerabilidades.

Vamos usar como analogia um motorista e seu veiculo. Esse motorista é cuidadoso e tem todas as manutenções em dia. Ele dirige com prudencia e raramente cometeria uma infração. Porem quantas vezes já não vimos alguem perder o controle porque um pneu furou, um buraco ou deslizamento na pista, defeito no motor, quebra de roda ou eixo, falha no freio e até um mal estar súbito?

Ou seja, sua POSTURA DE SEGURANÇA indica que você segue as recomendações para evitar ter problemas conhecidos, mas um brecha de segurança de um sistema operacional, aplicativo ou device não é um item que você tem como prever, apenas remediar…

Então renomear o “Secure Score” para “Secure Posture” mostra que você segue e tem os itens SOB O SEU CONTROLE remediados e  controlados. Mas você ainda está sujeito aos problemas externos, vide os exemplo recenter de vulnerabilidades do iOS, Log4j, SolarWinds, Mikrotik, etc.

Agora o Secure Posture inclui AWS e GCP

Anteriormente já era possivel ingressar com contas AWS e GCP mas elas não refletiam no Score e nem permitiam aplicar as regras de compliance. Assim, era necessário que olhasse separadamente e extraisse dados em mais de uma plataformas para gerar um report de compliance único.

O que mudou é que o Secure Posture mostra todas as Clouds integradas e você verá isso ao entrar no Defender for Cloud a partir de hoje!

Quais as politicas e regras avaliadas?

Esse é um item bem interessante, pois as regras de compliance que você já aplicou ao Azure serão automaticamente duplicadas para representar a mesma postura de segurança no AWS.

Veja abaixo que os mesmos conjuntos de regras aplicadas nas subscrições Azure agora estão aplicadas e adaptadas ao AWS.

Porem é importante ressaltar que apenas de ser possivel exportar os relatórios de compliance não é possivel gerar os reports de auditoria (Audit reports). O motivo é que os relatórios de auditoria é baseado em regras de segurança do datacenter e não apenas do que é serviços, ou seja controle do provedor e do cliente. Por conta disso, cada provedor precisa ter seus próprios relatórios atestando a segurança lógica e física da infraestrutura.

Onboarding de contas AWS

Fazer o onboarding da conta AWS não é um processo trivial pois envolve criar um objeto no CloudWatch e configurar permissões. Mas fazer o processo pelo Azure é simples e ele possui o passo a passo do que deve ser feito e valida ao final.

Ao adicionar uma conta AWS será possivel escolher avaliar apenas a postura ou instalar automaticamente o Azure Arc nas VMs e capturar os logs com o Log Analytics.

Importante lembrar que você poderá usar as politicas e iniciativas do Azure agora no AWS, então os mesmos requisitos customizados que você possua será avaliado nos dois ambientes.

Conclusão

Para clientes com ambiente multicloud agora será possivel ter uma visualização unica da postura baseada nas regras customizadas ou regulamentares únicas.

Anuncio oficial: Security posture management and server protection for AWS and GCP are now generally available - Microsoft Tech Community

Outra feature que estava em private preview para MVPs e parceiros e agora se tornou público é o recurso de mapeamento dos alertas e huntng queries do Sentinel com a matriz de cobertura do MITRE.

Esse recurso não gera um custo já que ele é um dashboard que demonstra a matriz ao inves da lista de itens.

Como MITRE é mapeado atualmente

Hoje os alertas e hunting queries já trazem as técnicas MITRE que estão sendo abordadas como mostra a imagem abaixo:

Podemos observar que as táticas e técnicas já são mapeadas tanto no cabeçalho quando em cada um dos itens de pesquisa ativa do Sentinel.

Mas esses dados estão desestruturados e é necessário clicar para fazer um filtro das vulnerabilidades com o mapa de cobertura do MITRE, muito usado hoje.

Como o MITRE será mapeado agora com o Preview

Os mesmos dados da consulta acima, agora podem ser visto diretamente no mapa de cobertura MITRE:

Com esse mapa ficará muito mais fácil categorizar os diferentes tipos de vulnerabilidades que preciso me proteger já que ele me traz a possibilidade nos detalhes de abrir as queries que geraram os diferentes pontos de atenção!

Alem disso, tambem é possivel com a opção Simulated mapear quantos diferentes tipos de vulnerabilidades eu tenho cobertura, mesmo que não tenha resultado na query hoje.

Esse efeito de simulação é muito interessante pois me permite saber se o Sentinel tem o necessário para cobrir todos os pontos que me interessam e me permitirá ter uma visão gerencial incluindo as hunting queries que eu mesmo crie.

Anuncio do Public Preview: What’s Next in Microsoft Sentinel? - Microsoft Tech Community e documentação View MITRE coverage for your organization from Microsoft Sentinel | Microsoft Docs

Um dos programas que a Microsoft disponibiliza a MVPs e parceiros é participar de previews privados para funcionalidades de Cloud Security.

Um destes recursos liberados para Public Preview recentemente foi o Log Search and Restore onde pode-se estender o tempo de log do Analytics alem de utilizar o próprio Sentinel para ler os dados destes logs armazenados.

Limitação Atual

Na versão GA o Sentinel guarda os logs por até 2 anos, sendo que pela interface visual é possivel configurar 90 dias e via PowerShell para até 755 dias.

Alem disso, ao configurar para 2 anos o log acaba gerando um custo mais alto por estar vinculado ao preço de armazenamento do Log Analytics que é por Giga.

Novos Limites e Custo

Neste Preview o log agora poderá ser guardado por 7 anos (2520 dias) alem de ter um custo menor que será divulgado no GA, porem muito menor que o atual.

Assim como no GA atual, a alteração pode ser feita via PowerShell para os 7 anos.

Mas para ajudar, vc pode usar o aplicativo disponibilizado no GitHub onde poderá escolher as tabelas e o tempo de arquivo para operação. Ou seja você pode colocar a tabela de alertas por 5 anos e a tabela de incidentes por 2 anos.

Link para o aplicativo de configuração: Azure-Sentinel/Tools/Archive-Log-Tool/ArchiveLogsTool-PowerShell at master · Azure/Azure-Sentinel · GitHub

Usando o Recurso

Vou demonstrar com prints abaixo do meu Preview como fiz o processo de Restore, Search e o resultado final.

Executando um Restore com o nome da tabela que desejo, a data inicial e final:

Na sequencia executei uma consulta abordando o tempo que configurei do Restore da tabela SecurityEvents com o nome do meu servidor:

Por fim, o resultado é uma nova Custom Table no Log Analytics com o nome indicado acima e os mais de 3 anos de eventos restaurados!!!

Anuncio do Preview: What's New: Search, Basic Ingestion, Archive, and Data Restoration are Now in Public Preview - Microsoft Tech Community