Utilizando o Sysmon para monitorar atividades do Windows

Confesso a vocês que quando escrevi o ultimo artigo, referente a logs do Windows cuja monitoração é obrigatória para garantir ambientes seguros - e que pode ser conferido aqui - não imaginei tamanha repercussão.

Bom conteúdo? Sim, mas uma boa dose de sorte também contribuiu. Tenho certeza disso ...

Foram dezenas de artigos interessantes, sempre focados em entregar conteúdo. E de repente alguns deles ... boooom!!!! Explode!!!

Os feedbacks foram incríveis e confesso que isso me gera certa satisfação com a sensação de estar no caminho certo.

Talvez eu tenha conquistado um pouco mais de leitores e finalmente ultrapassado a barreira de 5 leitores fieis ... 😄😄😄

No artigo passado, menciono uma ferramenta que é bastante eficiente na monitoração de atividades de sistemas operacionais Microsoft: O Sysmon.

Utilizarei as próximas linhas para falar um pouco mais sobre essa ferramenta e os eventos que merecem atenção especial.

Vamos lá ...

O Sysmon é um utilitário gratuito da Microsoft que monitora a atividade do sistema e o registra em um log de eventos do Windows, também chamado de "Sysmon".

No entanto, há alguma sobreposição entre o log do Sysmon e o log de segurança do Windows.  Assim, recomendo utilizar o Sysmon para monitorar os eventos que tratarei aqui, pois a qualidade dos dados me parece melhor.

Criação de processo (Event ID 1) - O log de segurança do Windows informará quando um processo EXE for iniciado e fornecerá seu nome e caminho. Mas os invasores podem criar um programa mal-intencionado com o mesmo nome de uma ferramenta legítima, como por exemplo c:\windows\notepad.exe, ou modificar um programa existente para executar ações ilícitas. Para pegá-los, você precisa de um hash do conteúdo do arquivo, que o log de segurança não fornece, mas o Sysmon sim. 

Hash é um resumo matemático exclusivo do fluxo de bits do arquivo, portanto, a substituição ou a alteração do arquivo resultará em um hash diferente. Na internet existe diversos aplicativos para analise de hash. Analisando o hash de um arquivo através de um desses aplicativos, você pode determinar facilmente se o arquivo foi alterado ou substituído por um código malicioso.

Conexões de rede (Event ID 3) - O monitoramento das conexões de rede também pode ajudar a identificar invasores, pois obviamente, o volume de dados trafegado será muito alto. É fundamental estabelecer linhas de base das atividades normais. De posse dessa linha de base, fica fácil identificar comportamentos anormais e conexões suspeitas. 

Tanto o log de segurança do Windows quanto o Sysmon permitem coletar eventos de conexão de rede, mas somente o Sysmon vincula cada conexão a um processo por meio dos campos ProcessID e ProcessGUID, além de fornecer os endereços IP de origem e destino, números de porta e status IPv6.

Alterações no registro (Event ID de 12 a 14) - Depois que os invasores inserem seu código malicioso em uma estação de trabalho por meio de um e-mail de phishing, programa ou arquivo infectado ou qualquer outro método, eles desejam que o código malicioso seja executado mesmo após a reinicialização da estação de trabalho.

A maneira mais comum de alcançar essa persistência é através da alteração do registro do Windows. É possível acompanhar isso através do log de segurança do Windows, mas o Sysmon fornece mais contexto, incluindo detalhes importantes como quem fez a alteração, qual computador foi utilizado, quando aconteceu, o ID do processo e o novo nome de qualquer chave ou valor renomeado.

Criação de arquivo (Event ID 11) - O log de segurança do Windows é capaz de informar que um novo arquivo foi criado ou sobrescrito em uma determinada pasta, mas não fornece o nome desse novo arquivo. O Sysmon faz isso, facilitando a identificação e a investigação de eventos suspeitos de criação de arquivos para que você possa bloquear os ataques mais rapidamente. 

Monitore com atenção os locais designados a inicialização automática, como a pasta "Inicializar", bem como os diretórios temporários e de download, nos quais o malware geralmente aparece durante a infecção inicial. 

Carregamentos de driver e imagem (Event ID 6 e 7) - Além de fornecer o hash para o processo EXE iniciado conforme explicado acima, o Sysmon também controla as cargas de driver de dispositivo e DLL, que os invasores também usam. Ele informa inclusive se o arquivo é assinado, quem o assinou e se a assinatura é válida.

Criação de encadeamento remoto (Event ID 8) - Ferramentas sofisticadas de invasão podem injetar uma DLL em um processo em execução e, em seguida, acionar essa DLL em outro contexto. Embora esse recurso tenha usos legítimos, como depuração, você precisa saber quando isso ocorre em ambiente produtivo.

Raw Access Read (Event ID 9) - O evento RawAccessRead detecta quando um processo realiza operações de leitura da unidade usando a denotação “\\. \”. 

Essa técnica é utilizada por malwares para exfiltração de dados bloqueados para leitura, bem como para evitar ferramentas de auditoria de acesso a arquivos. O evento indica o processo de origem e o dispositivo de destino.

Criação e conexão de pipes nomeados (Event IDs 17 e 18) - Alguns softwares mal-intencionados se comunicam com componentes diferentes por meio de um canal de comunicação no Windows chamado pipes nomeados. Por isso é importante monitorar tais eventos.

Atividade do evento WMI (Event ID 19) - O malware pode ser executado registrando-se um filtro de eventos do Windows Management Instrumentation (WMI). Este evento registra o namespace WMI, o nome do filtro e a expressão de filtro.

Criação de fluxo de arquivos nomeados (Event ID 15) - Esse evento ajuda a detectar variantes de malware que eliminam seus executáveis ​​ou configurações por meio de downloads do navegador.

Alteração de horário de criação de arquivo (Event ID 2) - Para evitar alguns tipos de monitoramento de integridade de arquivo, os invasores podem alterar os tempos de criação de arquivo. 

Por exemplo, eles criarão um arquivo, mas alterarão imediatamente o tempo de criação para que ele não apareça em uma lista de arquivos criados recentemente. 

E o Sysmon vai pegar isso com maestria!!!

Como instalar o SYSMON?

Para instalar o Sysmon, baixe o executável do site da Microsoft (clicando aqui). Descompacte o arquivo e em seguida, execute o seguinte comando:

Sysmon -i

Para controlar quais eventos devem ser registrados, especifique as configurações apropriadas em um arquivo de configuração XML e em seguida, execute o comando abaixo:

Sysmon –c config.xml

Alguns dos eventos listados acima geram falsos positivos. Para minimizar isso e tornar a monitoração mais efetiva, você pode especificar uma lista de arquivos EXE que o Sysmon deverá excluir do monitoramento. 

Para obter um modelo de arquivo de configuração que pode representar um excelente ponto de partida para o monitoramento de alterações do sistema, visite https://github.com/SwiftOnSecurity/sysmon-config.

Protegendo o Sysmon

Sim, também é necessário proteger o Sysmon ... 😕😕😕pois é mais fácil manipular o Sysmon do que o log de segurança do Windows.

Mas nem tudo são dores. Felizmente, existem algumas técnicas que podem minimizar esse risco. 

Primeiro, você pode ocultar o Sysmon alterando o nome do driver (use a tag DriverName no arquivo de configuração) e alterando o nome do serviço (renomeie o executável antes de instalá-lo).

No entanto, ainda existem métodos que os hackers podem usar para encontrar o Sysmon, então você também precisa monitorar ataques nele. 

Felizmente, o Sysmon é capaz de rastrear alterações em si mesmo usando os seguintes eventos:

Event ID 4 - Exibe informações sobre mudanças de estado do serviço Sysmon (iniciar ou parar).

Event ID 16 - Informações sobre alteração de estado de configuração do Sysmon, incluindo o hash do arquivo de configuração.

Você também pode configurar uma tarefa agendada por meio de GPO que periodicamente execute o comando abaixo para impor a configuração apropriada (substitua “\\server\share” pelo caminho correto em seu ambiente):

\\server\share\sysmon -i -accepteula -c \\server\share\sysmon.xml if errorlevel 1 \\server\share\sysmon -c \\server\share\sysmon.xml

Há também ferramentas de terceiros que podem redefinir automaticamente a configuração  do Sysmon após alterações impróprias.

Por hoje é só ... no próximo artigo, tentarei jogar um pouco de luz sobre monitoração do Windows Powershell.

Abraço e até a próxima!!!

Logs do Windows cuja monitoração é fundamental para garantir ambientes seguros.

Ando meio atrasado com as publicações técnicas, é verdade.

A correria está absurda, mas acho sempre melhor assim.

Depois de 22 anos atuando em empresas de diversos portes e segmentos, me pareceu natural empreender e para isso estou à frente da IT-Techs Consultoria e Treinamentos (www.it-techs.com.br).

Confesso à vocês que hoje trabalho muito mais, por enquanto ganho muitíssimo menos, mas me é gratificante fazer algo em que acredito agregar valor para meus clientes, parceiros e alunos. Não sei se isso está relacionado ao tal do propósito, mas é legal.

Firmamos parceria com a Quest, SonicWall e TrendMicro ... tem sido bom demais!!!

Ainda assim, continuo e continuarei com os treinamentos que ministro como MCT. É uma outra forma de impactar diretamente a vida das pessoas. No final do dia, isso tem sido muito importante pra mim.

No pouco tempo que tenho, estudo. Estudo muito, leio muito, enfim ... e algo tem me decepcionado um pouco.

Principalmente aqui no Linkedin, vejo algumas publicações técnicas que falam, falam e não dizem NADA!!!

Sou extremamente rigoroso comigo mesmo, e os feedbacks que recebo me levam a crer que estou no caminho certo, mas sei que posso melhorar muito ainda.

No artigo de hoje, com forte viés à segurança da informação, tratarei sobre logs do Windows que são sistematicamente ignorados pela maioria dos administradores, mas que são fundamentais monitorar.

Monitorá-los pode fazer toda a diferença entre ter ou não uma dor de cabeça imensa.

Mas antes inicio com uma questão: Porque monitorar estações de trabalho?

A maioria dos ataques iniciam nas estações de trabalho dos usuários.

Por quê? 

Fundamentalmente porque em sua grande maioria, as estações de trabalho, ao contrário dos servidores, são utilizadas por usuários não técnicos, que acabam se tornando presas fáceis para os atacantes.

O Relatório de Investigações de Violação da Verizon publicado em 2017, afirma que 1 a cada 14 usuários foram induzidos a clicar em links maliciosos ou abrir um anexo infectado, e parte deles foram enganados mais de uma vez. Pode parecer pouco, mas não é.

Usuários de estações de trabalho frequentemente são vítimas de downloads efetuados a partir de sites que lhes parecem confiáveis, inserem inconscientemente dispositivos USB contendo ransomware ou outros malwares e cometem outros erros críticos que permitem aos atacantes acessar a rede corporativa.

É fácil simplesmente colocar toda a culpa nos usuários, mas o fato é que os ataques estão ficando cada vez mais sofisticados e se ocorrem, em certo grau é responsabilidade do ainda  pouco investimento das corporações e do baixo conhecimento técnico de alguns profissionais. 

Pensem que para aprimorar seus métodos de ataques, hackers vasculham as redes sociais para obter informações sobre seus alvos preferenciais e criar e-mails de phishing cada vez mais convincentes, ou  escondem malwares em arquivos para download que parecem serem realmente legítimos.

Até mesmo experientes profissionais de TI às vezes são enganados.

Por outro lado, as estações de trabalho dos usuários são particularmente vulneráveis, por diversas razões.

Primeiro, pela inexistência de um programa de conscientização eficaz e constante no que se refere à segurança da informação.

Posso ainda citar a ausência de uma política de gerenciamento e aplicação de atualizações realmente eficaz.

Existe também o fato de que muitos ataques dependem de ações interativas de usuários locais, que são o cenário mais comum em estações de trabalho.

Sem contar que a maioria dos ataques exploram arquivos maliciosos e conteúdos da internet, e as estações de trabalho entram em contato com muito mais arquivos da Internet do que os servidores.

Por fim, muitas vulnerabilidades envolvem aplicativos baseados em GUI de terceiros usados em estações de trabalho, como por exemplo extensões de navegadores da Internet. Manter esses aplicativos adequadamente corrigidos continua a ser um ponto fraco em muitas organizações.

E essas são apenas algumas razões ...

A combinação de usuários não técnicos e estações de trabalho vulneráveis ​​é irresistível para hackers. Assim, nós administradores temos que fazer da segurança do endpoint uma prioridade.

A chave para pegar ataques o mais cedo possível e interrompê-los antes que um dano real seja causado é monitorar adequadamente as estações de trabalho. Mas qual é a melhor maneira de fazer isso?

Com o elevado número de estações de trabalho e a grande quantidade de logs gerados em cada uma delas, existem alguns desafios reais envolvidos na coleta, arquivamento, monitoramento, pesquisa e analise deles.

Existem soluções simplesmente maravilhosas como o Quest InTrust que pode nos ajudar a fortalecer a segurança de endpoints, mas aqui tratarei sobre logs isolados do Windows.

O que monitorar?

Quando nos focamos em segurança, o monitoramento efetivo do log se segurança do Windows torna-se mandatório. Esse é o principal registro de atividades relacionadas à segurança e muitos eventos de segurança importantes são registrados apenas lá.

Nesse log encontramos e devemos dar atenção aos seguintes eventos:

Enumeração de usuário e grupo local (eventos 4798 e 4799) - Códigos mal intencionados geralmente enumeram as contas de usuários e grupos locais nas estações de trabalho para localizar credenciais úteis. 

Monitorar os eventos 4798 e 4799 pode ajudá-lo a identificar códigos maliciosos antes de ocorrer a movimentação lateral para outros sistemas utilizando as credenciais que foi colhida.

Maiores informações sobre o ventos 4798 pode ser obtida em https://docs.microsoft.com/pt-br/windows/security/threat-protection/auditing/event-4798.

Maiores informações sobre o ventos 4799 pode ser obtida em https://docs.microsoft.com/pt-br/windows/security/threat-protection/auditing/event-4799.

Criação de conta local e alterações de grupos (eventos 4720, 4722 - 4726, 4738, 4740, 4767, 4780, 4781, 4794, 5376 e 5377) -  Os invasores também costumam criar ou modificar contas locais e grupos locais (especialmente o grupo de administradores locais), então você deve se manter atento a esses eventos.

O log cujo event ID é o 4720, indica a criação de uma conta de usuário. Maiores informações podem ser obtidas em https://docs.microsoft.com/pt-br/windows/security/threat-protection/auditing/event-4720.

O log cujo event ID é o 4722, indica que uma conta de usuário foi habilitada. Se o log anterior já deve nos acender um alerta, esse também não deve ser desprezado. Maiores informações podem ser obtidas em https://docs.microsoft.com/pt-br/windows/security/threat-protection/auditing/event-4722.

O log cujo event ID é o 4723, indica uma tentativa de alteração de senha. Maiores informações podem ser obtidas em https://docs.microsoft.com/pt-br/windows/security/threat-protection/auditing/event-4723.

O log cujo event ID é o 4724, indica que um usuário tentou alterar a senha de outro. Critico, não??? Maiores informações podem ser obtidas em https://docs.microsoft.com/pt-br/windows/security/threat-protection/auditing/event-4724.

O log cujo event ID é o 4725, indica que uma conta de usuário foi desabilitada. Inicialmente, isso pode passar batido para muitos, mas quando trata-se de segurança, pode ser indicativo de um problema maior. Maiores informações podem ser obtidas em https://docs.microsoft.com/pt-br/windows/security/threat-protection/auditing/event-4725.

O log cujo event ID é o 4726, indica que uma conta de usuário foi excluída. Maiores informações podem ser obtidas em https://docs.microsoft.com/pt-br/windows/security/threat-protection/auditing/event-4726.

Alterações em contas de usuáros são gravadas no log cujo ID é o 4738. Maiores informações podem ser obtidas em https://docs.microsoft.com/pt-br/windows/security/threat-protection/auditing/event-4738.

Eventos do tipo 4740 indicam que um conta de usuário foi bloqueada. Um bloqueio de conta pode ser gerado por inúmeras tentativas de logon com senha incorreta, portanto é fundamental monitorar. Maiores informações estão disponíveis em https://docs.microsoft.com/pt-br/windows/security/threat-protection/auditing/event-4740.

Eventos do tipo 4767 indicam que um conta de usuário foi desbloqueada. Maiores informações estão disponíveis em https://docs.microsoft.com/pt-br/windows/security/threat-protection/auditing/event-4767.

Eventos do tipo 4780 indicam a definição de ACL em contas que são membros de grupos de administradores. É necessário monitorar esse evento e investigar porque a ACL do objeto foi alterada. Maiores informações estão disponíveis em https://docs.microsoft.com/pt-br/windows/security/threat-protection/auditing/event-4780.

Eventos do tipo 4781 são gerados toda vez que um nome de conta de usuário ou computador (atributo sAMAccountName ) é alterado. Vale a pena investigar a razão da alteração. Maiores informações disponíveis em https://docs.microsoft.com/pt-br/windows/security/threat-protection/auditing/event-4781.

Quando criamos um domínio do Active Directory, é mandatório definir uma senha para o Directory Services Restore Mode (DSRM). Quando ocorre uma tentativa de definir a senha do DSRM, um evento do tipo 4794 é gerado. Maiores informações estão disponíveis em https://docs.microsoft.com/pt-br/windows/security/threat-protection/auditing/event-4794.

Usuários normalmente efetuam logon em suas estações de trabalho usando uma conta de domínio. Tentativas bem ou mal sucedidas de fazer login usando uma conta local podem ser um excelente indicador de ataques. O evento 4624 registra todos os tipos de tentativas de logon incluindo os logons do domínio, mas é fácil filtrá-los porque nesses casos, o nome de domínio é o nome do computador. Maiores informações podem ser obtidas em https://docs.microsoft.com/pt-br/windows/security/threat-protection/auditing/event-4624.

Já o evento 4648 indica que um processo tentou efetuar logon especificando explicitamente credenciais de outra conta. 

Isso ocorre legitimamente com tarefas agendadas ou ao usar o comando “RUNAS”, por exemplo.

Como a maioria das tarefas agendadas não são executadas em estações de trabalho, esse evento pode indicar um processo malicioso tentando iniciar outro processo com credenciais específicas ou um invasor mapeando uma unidade de outro computador usando credenciais previamente coletadas. Maiores informações estão disponíveis em https://docs.microsoft.com/pt-br/windows/security/threat-protection/auditing/event-4648

Dificilmente um usuário permanece dias conectado a uma estação sem efetuar um bloqueio ou desbloqueio da estação. Além de monitorar os eventos de logon e logoff, é necessário monitorar eventos do tipo 4800, 4801, 4802 e 4803 que indicam quando a console da estação de trabalho foi bloqueada e desbloqueada. Qualquer atividade em uma estação de trabalho enquanto ela estiver bloqueada exige uma investigação aprofundada.

Já mencionei sobre a não recomendação de se desativar o firewall do Windows. Aí você administrador define todas as configurações padrões para seu ambiente, ativa o firewall pra galera, mas e aí? Você está monitorando as alterações que podem ocorrer no firewall do Windows?

Alterações nas configurações do firewall geram eventos cujos IDs vão de 4944 a 4958. Dependendo de como o sistema operacional foi configurado, os aplicativos podem adicionar automaticamente exceções ao firewall do Windows durante a instalação, principalmente quando o usuário tem autoridade administrativa local. Essas exceções não precisam ser deliberadamente maliciosas para criar falhas graves de segurança. Se você confia e utiliza o firewall do Windows como um controle de segurança, precisa saber sobre quaisquer alterações em sua configuração, concordam?

Conexões de dispositivo plug-and-play (evento 6416, somente Windows 10 e Windows 2016) - O malware pode entrar em uma estação de trabalho por meio de drives USB ou outros dispositivos plug-and-play. É importante auditar as conexões de todos esses dispositivos e o evento 6416 indica o reconhecimento de novos dispositivos pelo sistema operacional.

Muitos outros eventos importantes podem ser obtidos no log de segurança do Windows, mas recomendo obtê-los através do Sysmon vez porque a qualidade dos dados me parece melhor. 

Esses eventos incluem:

• Criação de processo

• Conexões de rede

• Alterações no registro

• Criação de arquivos

Informações sobre o Sysmon podem ser obtidas em https://docs.microsoft.com/en-us/sysinternals/downloads/sysmon.

Acima mencionei sobre a ferramenta da Quest denominada InTrust que certamente nos ajuda a monitorar tais eventos de forma bastante adequada.

Entretanto, é possível configurar qualquer ferramenta de monitoração para monitorar os eventos específicos aqui mencionados.

Bom ... é isso. O negócio é tentar entregar uma informação de qualidade e de alguma forma tentar contribuir para o enriquecimento da comunidade técnica.

Abraço e até a próxima!!!

Protegendo conteúdo com AD RMS - Parte III

Continuando a série de artigos sobre proteção de conteúdo utilizando o AD RMS, hoje tratarei sobre o Azure RMS.

Em alguns cenários, uma empresa pode não possuir recursos suficientes para implementar uma infraestrutura local do AD RMS e nesses casos sim, é possível ter o serviços de RMS na nuvem.

A implementação do AD RMS em uma infraestrutura de rede local e em uma única floresta do AD DS certamente ajuda a proteger informações sensíveis, mas pode ser ineficiente em cenários em que o conteúdo protegido pelo AD RMS deve ser compartilhado entre organizações selecionadas ou com pessoas de fora da organização. 

Além de estabelecer relações de confiança ou utilizar uma conta da Microsoft, é possível utilizar os recursos do AD RMS em nuvem pública no Azure, dispensando a implementação e o gerenciamento de uma infraestrutura local para o AD RMS.

Usando o Azure RMS, pode-se atribuir políticas e restrições de uso a documentos e compartilhá-los com outras organizações que também assinam o serviço do Azure.

Como o Azure RMS se integra a todos os serviços e aplicativos do Office 365, você pode usar todos os recursos do RMS da nuvem e do ambiente local. 

O Azure RMS está disponível nas assinaturas do Office 365 Enterprise E3 e do Office 365 ProPlus. Também é possível comprá-lo como um serviço separado e utiliza-lo com sua nuvem ou recursos locais. 

O Azure RMS fornece as seguintes funcionalidades: 

Integração do Gerenciamento de Direitos de Informação (IRM) com o Office => Todos os aplicativos do Office implantados localmente podem utilizar o Azure RMS para ajudar na proteção de conteúdo.

Integração do Exchange Online IRM => O Azure RMS oferece a capacidade de ajudar a proteger e consumir mensagens de e-mail no Outlook Web ou no Outlook. Também é possível consumir mensagens protegidas por IRM por meio do Exchange ActiveSync em dispositivos como o Windows 10 Mobile ou dispositivos baseados em iOS. Além disso, os administradores podem usar as regras de proteção do Outlook e as regras de transporte do Exchange para proteção e descriptografia, para evitar o vazamento de dados.

Integração de IRM do SharePoint Online => Utilizando o Azure RMS, os administradores podem configurar a proteção automática de IRM de documentos em bibliotecas do SharePoint.

Infraestrutura de classificação de arquivos do Windows Server (FCI) => Se o computador executar o Windows Server e tiver o recurso Gerenciador de recursos de servidor de arquivos (FSRM), você terá FCI. O FSRM pode digitalizar arquivos no servidor e executar uma ação configurada. Por exemplo, você pode marcar arquivos confidenciais como sensitive. Após classificar um arquivo ou pasta, você pode executar outra tarefa FSRM para aplicar um modelo do Azure RMS para o arquivo ou pasta, com base na classificação. Assim, se o FSRM encontrar uma pasta denominada “folha de pagamento” e classificá-la como sensitive, você poderá fazer com que o FSRM aplique um modelo do Azure RMS para corresponder ao tipo de dados. Nesse caso, você pode usar um modelo que limita o acesso ao arquivo ao departamento de folha de pagamento.

Benefícios organizacionais

As funcionalidades do Azure RMS oferecem vários benefícios para as organizações, incluindo:

Ajudar as organizações a cumprir metas de conformidade => O Azure RMS é certificado para vários programas da indústria, incluindo a lei de portabilidade e responsabilidade de seguro de saúde (HIPAA) e o nível 1 de segurança de dados da indústria de cartões de pagamento (PCI) Standard (DSS). Muitas organizações são necessárias para armazenar dados confidenciais com criptografia e podem usar o Azure RMS para fazer isso.

Reduzir de vazamento de dados => Em muitas organizações, os usuários podem divulgar dados corporativos sem autorização. Por exemplo, uma organização pode estar se preparando para anunciar um novo produto e essa informação pode ser vazada por meios diversos, de forma intencional ou não. O Azure RMS ajuda a minimizar o vazamento de dados, dificultando a transferência de informações para funcionários de fora da organização sem serem rastreadas. Diferentemente do AD RMS, que é implantado localmente, o Azure RMS fornece a você a capacidade de rastrear geograficamente o local em que um arquivo é usado.

Permite o compartilhamento de dados confidenciais com parceiros de organizações externas => Como o Azure RMS permite uma colaboração praticamente perfeita com usuários fora da sua organização, as organizações podem aprimorar a segurança para colaboração e compartilhamento de dados.

Em https://docs.microsoft.com/pt-br/azure/information-protection/compare-on-premise é possível consultar com exatidão as diferenças entre as versões do AD RMS.

Abraço e até a próxima publicação!!!

Protegendo conteúdo com AD RMS - Parte II

Na parte I (que pode ser acessada clicando aqui) dessa série de artigos sobre o AD RMS apresentei o produto e expus alguns cenários onde essa ferramenta pode ser útil.

Nesse artigo, tentarei explicar o funcionamento do AD RMS. Vamos lá ...

Como funciona o AD RMS?

Quando um usuário protege o conteúdo de um arquivo ou tenta acessar conteúdo protegido pelo AD RMS, várias tarefas são executadas em segundo plano, de forma invisível aos olhos.

Para diagnóstico e solução de problemas, é importante entender como o AD RMS funciona. Embora não esteja diretamente relacionado aos Serviços de Certificados do Active Directory (AD CS), o AD RMS usa certificados e recursos de criptografia de forma bastante intensa.

Basicamente, o AD RMS funciona da seguinte maneira:

1 - A primeira vez que um autor configura a proteção de direitos para um documento, um certificado de licenciante para cliente é solicitado ao servidor AD RMS. O cliente localiza o servidor AD RMS através do uso ponto de conexão de serviço (SCP) no AD DS.

2 - Após isso, o servidor emite um certificado de licenciador do cliente para o cliente, a menos que este seja membro da lista de exclusões do AD RMS.

3 - Após receber o certificado de licenciante do servidor AD RMS, o autor poderá configurar direitos de uso no documento. Essa configuração pode ser efetuada manualmente ou utilizando modelos pré-definidos.

4. Quando o autor configura os direitos de uso, o aplicativo habilitado para AD RMS criptografa o arquivo com uma chave simétrica que é gerada no dispositivo do cliente. Quando a proteção do AD RMS é aplicada ao documento, o documento está realmente criptografado.

5. Essa chave simétrica é criptografada utilizando a chave pública do servidor AD RMS que o autor está acessando. Essa chave simétrica criptografada é distribuída para o servidor AD RMS e armazenada nele. Como ele é criptografado com a chave pública do servidor, ele só pode ser descriptografado usando a chave privada do servidor.

6. O autor do conteúdo protegido por AD RMS distribui o arquivo ao destinatário. O destinatário do arquivo pode abri-lo utilizando um aplicativo associado à extensão do arquivo ou navegador do AD RMS. Não é possível abrir conteúdo protegido pelo AD RMS, a menos que o aplicativo ou navegador suporte o AD RMS. Se o destinatário não tiver um certificado de conta no dispositivo atual, será emitido um para o usuário neste momento. O aplicativo ou navegador transmite uma solicitação ao servidor AD RMS do autor para a emissão de uma licença de uso.

7. O servidor AD RMS determina se o destinatário está autorizado a acessar o conteúdo protegido. Se o destinatário estiver autorizado, o servidor AD RMS emitirá a respectiva licença de uso.

8. O servidor AD RMS, em seguida, descriptografa a chave simétrica que foi criptografada na etapa 5 usando sua chave privada.

9. O servidor AD RMS criptografa novamente a chave simétrica usando a chave pública do destinatário e, em seguida, adiciona a chave de sessão criptografada à licença de uso. A licença de uso e a chave simétrica criptografada são então distribuídas para o destinatário. O destinatário usa sua chave privada para descriptografar a chave simétrica. Depois disso, a chave simétrica é usada para descriptografar conteúdo protegido por AD RMS.

Complexo, né? Pois é ... mas esse é só o começo.

Para entender como o AD RMS funciona, também é necessário estar familiarizado com seus diferentes certificados e tipos de licença. Cada certificado e licença funciona de maneira diferente. Alguns certificados, como certificados de licenciante de servidor, são extremamente importantes e você deve fazer backup regularmente deles.

Certificado de licenciante para servidor

O certificado de licenciante para servidor é gerado na criação do cluster AD RMS e possui validade de 250 anos. Esse certificado permite que um cluster AD RMS emita:

• Certificados de licenciante de servidor para outros servidores no cluster.

• Certificados de Conta de Direitos (RACs) para clientes.

• Certificados de licenciante para clientes.

• Licenças de publicação (PLs).

• Licenças de uso.

• Modelos de política de direitos.

A chave pública do certificado de licenciante servidor criptografa a chave de conteúdo em um PL. Isso permite que um servidor AD RMS extraia a chave de conteúdo e emita licenças de usuário final em relação à chave de publicação

Certificado de máquina AD RMS

O certificado de máquina do AD RMS é usado para identificar um computador ou dispositivo confiável. A chave pública do certificado de máquina criptografa a chave privada do RAC. A chave privada da máquina descriptografa RACs.

RAC

O RAC identifica um usuário específico. O período de validade padrão para um RAC é de 365 dias e podem ser emitidos somente para usuários do AD DS que possuem endereços de e-mail associados a suas contas. 

Um RAC é emitido na primeira vez que um usuário tenta acessar conteúdo protegido pelo AD RMS ou executar uma tarefa do AD RMS, como por exemplo, a criação de um documento protegido. O período de validade padrão pode ser ajustado conforme a necessidade.

Um RAC temporário tem um período de validade de 15 minutos e é emitido quando um usuário acessa o conteúdo protegido pelo AD RMS a partir de um computador que não é membro da mesma floresta que o cluster AD RMS ou a floresta confiável. O período de validade padrão para RACs temporários também pode ser ajustado conforme a necessidade.

Certificado de licenciante para cliente

Esse certificado permite que um usuário publique conteúdo protegido pelo AD RMS quando o computador cliente não estiver conectado à mesma rede que o cluster do AD RMS. A chave pública do certificado de licenciante cliente criptografa a chave de conteúdo simétrica e a inclui no PL por ela emitido. 

A chave privada do certificado de licenciante cliente assina quaisquer PLs emitidos quando o cliente não está conectado ao cluster do AD RMS.

Os certificados de licenciante de cliente estão vinculados ao RAC de um usuário específico. 

Se outro usuário que não tenha sido emitido um RAC tentar publicar conteúdo protegido pelo AD RMS do mesmo cliente, ele não poderá fazê-lo até que o cliente esteja conectado ao cluster do AD RMS e possa emitir um RAC para esse usuário.

PL

Um PL determina os direitos que se aplicam ao conteúdo protegido pelo AD RMS. Por exemplo, o PL determina se um usuário pode editar, imprimir ou salvar um documento. 

O PL contém a chave de conteúdo, que é criptografada usando a chave pública do serviço de licenciamento. Também contém a URL e a assinatura digital do servidor AD RMS.

Licença de usuário final

É necessária uma licença de usuário final para consumo de conteúdo protegido pelo AD RMS. O servidor AD RMS emite uma licença de usuário final por usuário e por documento. Licenças de usuário final são armazenadas em cache por padrão.

Bom ... por hoje é só e tudo isso.

Retornarei muito em breve com mais informações, até que possamos efetivamente fazer a instalação e configuração da ferramenta.

Gostou??? Compartilhe e me ajude a disseminar o conhecimento.

Abraços e até a próxima publicação.

Protegendo conteúdo com o AD RMS - Parte I

Trabalhando diariamente das 08:00 às 23:00 hs, acabei negligenciando temporariamente as atividades aqui do blog. 

Ministrei muito recentemente 120 horas de curso da formação MCSA em Windows Server 2016 e confesso que foi muito bom!!!

É a sensação de estar cumprindo meu dever, totalmente de acordo com o que acredito ser minha vocação, transmitindo conhecimento e impactando diretamente a vida de dezenas de pessoas que desejam alavancar suas carreiras, buscar aprovação nos exames oficiais de certificação ou simplesmente aprender mais.

E em cada treinamento, um ponto que noto cada vez mais interesse é sobre segurança da informação e consequente proteção de conteúdo. Como proteger informações contra acesso não autorizado, evitar vazamentos e consequentemente garantir conformidade com leis, normas e regulamentações vigentes ou prestes a entrar em vigor?

Pois é ... esse é um dos maiores problemas enfrentados diariamente por administradores de redes e analistas de segurança em todos os cantos do mundo.

Nativamente, o Windows Server fornece alguns recursos, como por exemplo as permissões de arquivo NTFS que podem ser utilizadas para determinar quem possui acesso aos arquivos. Um problema notório das permissões de arquivos e pastas é que após um arquivo ser copiado para outro local (como uma unidade USB), as permissões originais não se aplicam mais. Um arquivo que tenha sido copiado herdará as permissões do dispositivo de destino. Após um arquivo com um atributo do tipo "somente leitura" ser copiado, ele poderá ser editado e ter as permissões de arquivo e pasta alteradas.

Existe também o Encrypting File System (EFS) que pode ser implementado para controlar melhor a privacidade dos dados e ajudar a proteger o arquivo permanentemente. Entretanto, não será nada fácil compartilhar esses arquivos com outros usuários que realmente devam possuir acesso.

Assim, lhes apresentarei nos próximos artigos o Active Directory Rights Management Services ou simplesmente "AD RMS".

Com o AD RMS, é possível proteger um arquivo em qualquer local, independente das permissões de arquivo e pasta que concedem acesso e permitir que somente os usuários explicitamente autorizados a abrir um arquivo possam exibir o conteúdo, além de permitir controlar ações de arquivos, tais como copiar, imprimir e encaminhar entre outras possibilidades.

Além disso, o AD RMS integra-se a determinados produtos Microsoft, incluindo o Windows Server, Exchange Server, SharePoint Server e o Microsoft Office, além de serviços online, como o Office 365.

Mas antes de me aprofundar em aspectos fundamentalmente técnicos, vamos a alguns possíveis cenários onde essa solução atenderia bem a determinados requisitos de segurança:

Cenário 01 => Um diretor executivo copia uma planilha que contém informações extremamente sensíveis, como por exemplo os pacotes de remuneração dos demais executivos da organização, de uma pasta protegida em um servidor de arquivos para seu pendrive pessoal para que possa trabalhar nesse documento a partir de outro local. Durante o deslocamento para sua casa, ele perde o pendrive e alguém, sem nenhum vinculo com a organização encontra o dispositivo. 

Sem o uso do AD RMS, quem encontrar a unidade USB poderá abrir o arquivo e consequentemente ter acesso ao seu conteúdo, colocando em risco inclusive a integridade física dos demais executivos da companhia. Com o AD RMS, adicionamos mais um camada de proteção, visando garantir que usuários não autorizados simplesmente não abram o arquivo.

Cenário 2 => Um documento interno pode ser visualizado por um determinado grupo de pessoas mas essas pessoas não devem ser capazes de editar ou imprimir o documento.

Com o AD RMS, você pode configurar essas permissões com base em contas existentes no Active Directory ou para usuários que estão fora da organização, identificando-os através do uso de contas Microsoft.

Cenário 3 => Funcionários da organização não devem ter acesso para encaminhar mensagens de e-mail confidenciais que tenham sido atribuídas a uma classificação específica. 

Com o AD RMS, pode-se habilitar um remetente para atribuir uma classificação específica a uma nova mensagem de e-mail, e essa classificação ajudará a garantir que o destinatário não possa encaminhar a mensagem a quem quer que seja.

Instalado como uma role do Windows Server, o AD RMS exige a utilização de um servidor SQL Server ou o Windows Internal Database (WID) e possui os seguintes componentes:

Cluster do AD RMS => É criado na implantação do primeiro servidor AD RMS.

Servidor AD RMS => O servidor AD RMS deve ser membro de um domínio do AD DS. Na instalação do AD RMS, as informações sobre o local do cluster são publicadas no Active Directory em um local conhecido como Service Connection Point (SCP). Os computadores membros do domínio consultam o SCP para determinar o local dos serviços do AD RMS. O AD RMS pode ser instalado através do Server Manager nos sistemas operacionais Windows Server 2016, Windows Server 2012 e Windows Server 2008.

Cliente do AD RMS => O cliente do AD RMS é incorporado aos sistemas operacionais Windows 10, Windows 8,1, Windows 8, Windows 7 e Windows Vista e permite que aplicativos habilitados para AD RMS apliquem a funcionalidade definida por um modelo do AD RMS. Sem o cliente AD RMS, os aplicativos habilitados para AD RMS não podem interagir com conteúdo protegido pelo AD RMS.

Aplicativos habilitados para AD RMS => Os aplicativos habilitados para AD RMS permitem que os usuários criem e consumam conteúdo protegido. Além disso, a Microsoft fornece um kit de desenvolvimento de software (SDK) do AD RMS para permitir que desenvolvedores de aplicativos suportem a proteção de conteúdo do AD RMS.

Bom ... Agora que já dei o gostinho da ferramenta, encerro por aqui esse artigo. 

Para que não fique extremamente longo e de difícil leitura, segmentarei esse tema em diversas partes.

Enquanto isso, compartilhem esse conteúdo para que mais e mais pessoas tenham acesso ao conhecimento.

Abraços e até a próxima publicação, que será muito em breve.

Pré-requisitos do Windows Server 2019

Fonte: Google

Ano novo,  novas oportunidades e o velho desejo de contribuir com a comunidade técnica que não sai de mim.

Como já mencionei em alguns artigos, quanto mais eu aprendo mais eu ensino e sou demandado,  e mais eu aprendo, e esse circulo me é muito motivador.

Vem de encontro ao que acredito ser uma de minhas vocações.

Pra começar o ano a mil, a Microsoft disponibilizou ao grande publico um sistema operacional novo. 

Ele já estava disponível há alguns meses para os participantes do programa Windows Insider, mas como nem todos participam desse programa ... 😟😟😟

Depois de muito estudá-lo (na verdade nem acho que estudei tanto quanto deveria), no decorrer desse ano farei uma série de postagens sobre o mais novo sistema operacional da Microsoft: o Windows Server 2019.

Para avaliação, está disponível três versões desse sistema operacional:

1- Windows Server 2019 Essentials;

2- Windows Server 2019;

3- Microsoft Hyper-V Server 2019.

Para começarem seus testes e avaliações, recomendo que o download do produto seja efetuado clicando aqui. Segurança é tudo, e em tese, nada mais seguro que o site do fabricante.

Mas não adianta efetuarmos o download do produto, se não tivermos um hardware capaz de suportá-lo.

Assim, para essa primeira postagem sobre o Windows 2019, iniciarei pelos requisitos que devemos nos atentar para obtermos sucesso na instalação.

É importante salientar que os requisitos mínimos referem-se ao mínimo exigido para instalação e execução do sistema operacional, mas que cada recurso adicional que será instalado em cima desse sistema operacional possuem seus próprios requisitos. 

Logo, entendam que "requisito mínimo" é totalmente diferente dos requisitos reais exigidos por um ambiente produtivo, com minucias e particularidades diversas.

Para ambientes produtivos, é recomendado testes de carga, a fim de determinar os recursos de hardware ideais para cada ambiente.

Processador

O desempenho do processador depende não apenas do clock, mas também da quantidade de núcleos e da capacidade do cache. 

Os requisitos mínimos de processador do Windows 2019 são:

- Processador de 1,4 GHz;

- Compatível com conjunto de instruções x64;

- Suporte a NX e DEP;

- Suporte a CMPXCHG16b, LAHF/SAHF e PrefetchW;

- Suporte à conversão de endereços de segundo nível (EPT ou NPT).

Uma ferramenta que pode ser utilizada para confirmar se o processador utilizado possui os requisitos mínimos é o Coreinfo.

Memória

- 512 MB (2 GB para a opção de instalação Servidor com Experiência Desktop);

- Tipo ECC ou tecnologias semelhantes, para implantações de host físico.

Observações "importantíssimas"

Se tentar efetuar a instalação em uma máquina virtual com os requisitos mínimos de hardware com suporte (1 núcleo do processador e 512 MB de RAM) a instalação falhará.

É ... nem tudo são flores.

Para ter sucesso, é necessário alocar ao menos mais 800 MB de RAM para a máquina virtual. Uma vez que a instalação for concluída, pode-se alterar a alocação para até 512 MB de RAM.

Outro passo importante é interromper o processo de inicialização desta versão na máquina virtual pressionando SHIFT+F10. 

No prompt de comando que será aberto, utilize o Diskpart.exe para criar e formatar uma partição de instalação. 

Após isso, execute o comando Wpeutil createpagefile /path=C:\pf.sys (presumindo que a partição de instalação que você criou tenha sido C:). 

Feche o prompt de comando e prossiga com a instalação.

Disco

Computadores que executarão o Windows Server 2019 devem possuir um adaptador de armazenamento compatível com a especificação de arquitetura PCI Express. 

O Windows Server 2019 não suporta unidades de inicialização, paginação ou dados que sejam ATA, PATA, IDE ou EIDE.

Para a partição do sistema, o espaço mínimo necessário é de 32 GB para instalações do tipo Server Core. Para instalações que incluam o modo gráfico (Server GUI), necessário mais 4 GB.

Para computadores com mais de 16 GB de RAM, será necessário mais espaço em disco para arquivos de paginação, hibernação e despejo. 

Sobre os arquivos de paginação, cálculos e métricas recomendadas, escrevi um artigo bem legal disponível aqui.

Placa de rede

Minimamente, o servidor onde o Windows Server 2019 será instalado deverá possuir um adaptador Ethernet capaz de trafegar gigabit e que seja compatível com a especificação de arquitetura PCI Express.

Adaptadores de rede que ofereçam suporte à depuração de rede (KDNet) e que suporte Pre-boot Execution Environment (PXE) é útil mas não é um requisito mínimo.

Outros requisitos

- Unidade de DVD (caso pretenda instalar o sistema operacional usando mídia de DVD). Meio óbvio, né?

Já os itens a seguir não são rigorosamente exigidos, mas são necessários para determinados recursos:

- Sistema UEFI baseado em 2.3.1c e firmware que ofereça suporte à inicialização segura

Trusted Platform Module;

- Dispositivo gráfico e monitor capaz de Super VGA (1024 x 768) ou resolução superior;

- Teclado e mouse (não é por nada não, mas recomendo que se tenha ao menos um teclado);

- Acesso à Internet.

Observações

Um chip Trusted Platform Module (TPM) não é estritamente necessário para instalar o Windows Server 2019, mas é necessário para utilizar recursos Criptografia de Unidade de Disco BitLocker, por exemplo.

Se o computador usar TPM, ele deverá atender a estes requisitos:

Os TPMs baseados em hardware devem implementar a versão 2.0 da especificação de TPM;

Os TPMs que implementam a versão 2.0 devem ter um certificado EK previamente provisionado ao TPM pelo fornecedor de hardware ou ser capazes de serem recuperados pelo dispositivo durante a primeira inicialização;

Os TPMs que implementam a versão 2.0 devem acompanhar os bancos PCR SHA-256 e implementar os PCRs 0 a 23 para SHA-256. 

É aceitável enviar os TPMs com um único banco de PCR de alternância que pode ser usado para as medições de SHA-1 e SHA-256.

Uma opção de UEFI para desativar o TPM não é um requisito.

Ah vai ... nem são tantos requisitos assim. Todos, ou ao menos a grande maioria dos computadores mais novos já possuem esses recursos.

E aí, vai ficar parado???

Baixem o Windows 2019 e iniciem seus estudos.

Abraço e até a próxima.