Certificação do Microsoft 365 – Guia de Provas de Exemplo

Visão Geral

Este guia foi criado para fornecer aos ISVs exemplos do tipo de evidência e nível de detalhe necessário para cada um dos controlos de Certificação do Microsoft 365. Quaisquer exemplos partilhados neste documento não representam a única prova que pode ser utilizada para demonstrar que os controlos estão a ser cumpridos, mas funcionam apenas como uma orientação para o tipo de provas necessárias.

Nota: as interfaces, capturas de ecrã e documentação utilizadas para satisfazer os requisitos variam consoante a utilização do produto, a configuração do sistema e os processos internos. Além disso, tenha em atenção que, quando for necessária a documentação da política ou do procedimento, o ISV será necessário para enviar os documentos REAIS e não capturas de ecrã, como talvez seja mostrado em alguns dos exemplos.

Existem duas secções na certificação que requerem submissões:

1. Submissão de Documento Inicial: um pequeno conjunto de documentos de alto nível necessários para analisar a sua avaliação.
2. Submissão de Provas: o conjunto completo de provas necessárias para cada controlo no âmbito da avaliação de certificação.

Structure

Este documento mapeia diretamente para controlos que serão apresentados durante a sua certificação no centro de parceiros. As orientações fornecidas neste documento são detalhadas da seguinte forma:

• Domínio de Segurança: os três domínios de segurança nos quais todos os controlos estão agrupados: Segurança da Aplicação, Segurança Operacional e Segurança e Privacidade de Dados.
• Controlo(s): = Descrição da Atividade de Avaliação – estes controlos e números associados (Não.) são retirados diretamente da Lista de Verificação de Certificação do Microsoft 365.
• Intenção: = A intenção do motivo pelo qual o controlo de segurança está incluído no programa e o risco específico que tem como objetivo mitigar. A esperança é que estas informações forneçam aos ISVs o raciocínio subjacente ao controlo para compreender melhor os tipos de provas que precisam de ser recolhidas e que ISVs devem prestar atenção e ter consciência e compreensão na produção das suas provas.
• Diretrizes de Evidência de Exemplo: = Dado para ajudar a orientar as Tarefas de Recolha de Provas na folha de cálculo lista de verificação de certificação do Microsoft 365, isto permite que os ISVs vejam claramente exemplos do tipo de evidência que pode ser utilizado pelo Analista de Certificação que irá utilizá-lo para determinar com confiança que um controlo está em vigor e mantido – não é de forma alguma exaustivo.
• Exemplo de Evidência: = Esta secção fornece capturas de ecrã de exemplo e imagens de possíveis provas capturadas em cada um dos controlos na folha de cálculo da Lista de Verificação de Certificação do Microsoft 365, especificamente para os Domínios de Segurança Operacional e Segurança de Dados e Segurança de Privacidade (Separadores na folha de cálculo). Tenha em atenção que qualquer informação com setas vermelhas e caixas nos exemplos é para ajudar a compreender melhor os requisitos necessários para cumprir qualquer controlo.

Domínio de Segurança: Segurança da Aplicação

Controlo 1 - Controlo 16:

Os controlos de domínio da Segurança da Aplicação podem ser satisfeitos com um relatório de teste de penetração emitido nos últimos 12 meses que mostra que a sua aplicação não tem vulnerabilidades pendentes. A única submissão necessária é um relatório limpo de uma empresa independente de renome.

Domínio de Segurança: Segurança Operacional/Desenvolvimento Seguro

O domínio de segurança "Segurança Operacional/Desenvolvimento seguro" foi concebido para garantir que os ISVs implementam um conjunto forte de técnicas de mitigação de segurança contra uma miríade de ameaças de grupos de atividade. Esta ação foi concebida para proteger o ambiente operativo e os processos de desenvolvimento de software para criar ambientes seguros.

Proteção Contra Software Maligno - Antivírus

Controlo n.º 1: forneça documentação de política que regule as práticas e procedimentos antivírus.

• Intenção: a intenção deste controlo é avaliar a compreensão de um ISV sobre os problemas que enfrentam ao considerar a ameaça de vírus informáticos. Ao estabelecer e utilizar as melhores práticas da indústria no desenvolvimento de uma política e processos antivírus, um ISV fornece um recurso adaptado à capacidade da sua organização de mitigar os riscos enfrentados pelo software maligno, enumerando as melhores práticas de deteção e eliminação de vírus, e fornece provas de que a política documentada fornece orientações de segurança sugeridas para a organização e seus funcionários. Ao documentar uma política e procedimento de como o ISV implementa decências antimalware, isto garante a implementação e manutenção consistentes desta tecnologia na redução do risco de software maligno para o ambiente.
• Diretrizes de Provas de Exemplo: forneça uma cópia da política Antivírus/Antimalware que detalha os processos e procedimentos implementados na sua infraestrutura para promover as melhores práticas de Antivírus/Software Maligno. Exemplo de Provas
• Exemplo de Prova:

Nota: Esta captura de ecrã mostra um documento de política/processo, a expetativa é que os ISVs partilhem a documentação de política/procedimento de suporte real e não apenas forneçam uma captura de ecrã.

Controlo n.º 2: forneça provas demonstráveis de que o software antivírus está em execução em todos os componentes do sistema de amostra.

• Intenção: é importante ter o Antivírus (AV) (ou defesas antimalware) em execução no seu ambiente para proteger contra riscos de cibersegurança que pode ou não ter em consideração, uma vez que os ataques potencialmente prejudiciais estão a aumentar, tanto em sofisticação como em números. Ter o AV implementado em todos os componentes do sistema que suportam a sua utilização ajudará a mitigar alguns dos riscos de introdução de antimalware no ambiente. Basta que um único ponto final seja desprotegido para fornecer potencialmente um vetor de ataque para um grupo de atividade obter uma posição de pé no ambiente. Por conseguinte, o AV deve ser utilizado como uma das várias camadas de defesa para proteger contra este tipo de ameaça.
• Exemplo de Diretrizes de Evidência: para provar que uma instância ativa do AV está em execução no ambiente avaliado. Forneça uma captura de ecrã para cada dispositivo no exemplo que suporte a utilização de antivírus, que mostra o processo antivírus em execução, o software antivírus está ativo ou, se tiver uma consola de gestão centralizada para antivírus, poderá conseguir demonstra-lo a partir dessa consola de gestão. Se estiver a utilizar a consola de gestão, certifique-se de que evidencia numa captura de ecrã que os dispositivos de exemplo estão ligados e a funcionar.
• Exemplo de Evidência 1: a captura de ecrã abaixo foi tirada do Centro de Segurança do Azure; mostra que foi implementada uma extensão antimalware na VM com o nome "MSPGPRODAZUR01".

• Exemplo de Evidência 2

A captura de ecrã abaixo foi obtida a partir de um dispositivo Windows 10, que mostra que a opção "Proteção em tempo real" está ativada para o nome de anfitrião "CLARANET-SBU-WM".

Controlo n.º 3: forneça provas de que as assinaturas antivírus estão atualizadas em todos os ambientes (dentro de 1 dia).

• Intenção: são identificados diariamente centenas de milhares de novos softwares malignos e aplicações potencialmente indesejadas (PUA). Para fornecer proteção adequada contra software maligno recentemente lançado, as assinaturas AV têm de ser atualizadas regularmente para ter em conta o software maligno recentemente lançado.
• Este controlo existe para garantir que o ISV tomou em consideração a segurança do ambiente e o efeito que o AV desatualizado pode ter na segurança.
• Diretrizes de Evidência de Exemplo: forneça ficheiros de registo antivírus de cada dispositivo de amostra, mostrando que as atualizações são aplicadas diariamente.
• Exemplo de Prova: a seguinte captura de ecrã mostra o Microsoft Defender a atualizar, pelo menos, diariamente, mostrando "Evento 2000, Windows Defender" que é a atualização. O nome do anfitrião é apresentado, mostrando que este foi retirado do sistema no âmbito "CLARANET-SBU-WM".

Nota: As provas fornecidas teriam de incluir uma exportação dos registos para mostrar atualizações diárias durante um período de tempo maior. Alguns produtos antivírus irão gerar ficheiros de registo de atualização, pelo que estes ficheiros devem ser fornecidos ou exportar os registos do Visualizador de Eventos.

Controlo n.º 4: forneça provas de que o antivírus está configurado para efetuar a análise no acesso ou análise periódica em todos os componentes do sistema de amostra.

Nota: Se a análise no acesso não estiver ativada, o mínimo de análise diária e alerting_ TEM de _be ativado.

• Intenção: a intenção deste controlo é garantir que o software maligno é rapidamente identificado para minimizar o efeito que isto pode ter no ambiente. Quando a análise no acesso é realizada e associada ao bloqueio automático de software maligno, isto ajudará a parar as infeções de software maligno conhecidas pelo software antivírus. Quando a análise no acesso não é desejável devido aos riscos de falsos positivos que causam falhas no serviço, os mecanismos de análise e alerta diários adequados têm de ser implementados para garantir uma resposta atempadamente a infeções de software maligno para minimizar os danos.
• Exemplo de Diretrizes de Provas: forneça uma captura de ecrã para cada dispositivo no exemplo que suporte antivírus, que mostra que o antivírus está em execução no dispositivo e está configurado para análise no acesso (análise em tempo real), OU forneça uma captura de ecrã que mostra que a análise periódica está ativada para análise diária, os alertas são configurados e a última data de análise para cada dispositivo no exemplo.
• Exemplo de Prova: a seguinte captura de ecrã mostra que a proteção em tempo real está ativada para o anfitrião, "CLARANET-SBU-WM".

Controlo n.º 5: forneça provas de que o antivírus está configurado para bloquear automaticamente software maligno ou quarentena e alertar em todos os componentes do sistema de exemplo.

• Intenção: A sofisticação do malware está sempre a evoluir, juntamente com os diferentes graus de devastação que podem trazer. A intenção deste controlo é impedir a execução de software maligno e, por conseguinte, impedi-lo de executar o payload potencialmente devastador ou se o bloqueio automático não for uma opção, limitar a quantidade de tempo que o software maligno pode causar estragos ao alertar e responder imediatamente à potencial infeção por malware.

• Exemplo de Diretrizes de Evidência: forneça uma captura de ecrã para cada dispositivo no exemplo que suporte antivírus, mostrando que o antivírus está em execução no computador e está configurado para bloquear automaticamente software maligno, alerta ou para quarentena e alerta.

• Exemplo de Prova 1: a seguinte captura de ecrã mostra que o anfitrião "CLARANET-SBU-WM" está configurado com proteção em tempo real ativada para o Antivírus do Microsoft Defender. Como diz a definição, esta ação localiza e impede que o software maligno seja instalado ou executado no dispositivo.

Controlo n.º 6: forneça provas de que as aplicações são aprovadas antes de serem implementadas.

• Intenção: com o controlo de aplicações, a organização aprovará cada aplicação/processo que tenha permissão para ser executado no sistema operativo. A intenção deste controlo é garantir que está em vigor um processo de aprovação para autorizar que aplicações/processos podem ser executados.

• Diretrizes de Provas de Exemplo: podem ser fornecidas provas que mostram que o processo de aprovação está a ser seguido. Isto pode ser fornecido com documentos assinados, controlo dentro de sistemas de controlo de alterações ou utilização de algo como o Azure DevOps ou JIRA para controlar estes pedidos e autorização.

• Exemplo de Prova: a seguinte captura de ecrã demonstra uma aprovação por gestão que cada aplicação autorizada a executar no ambiente segue um processo de aprovação. Este é um processo baseado em papel na Contoso, no entanto, podem ser utilizados outros mecanismos.

Controlo n.º 7: forneça provas de que existe e mantém uma lista completa dos pedidos aprovados com justificação comercial.

• Intenção: é importante que as organizações mantenham uma lista de todas as aplicações que foram aprovadas, juntamente com informações sobre o motivo pelo qual a aplicação/processo foi aprovado. Isto ajudará a garantir que a configuração permanece atualizada e pode ser revista numa linha de base para garantir que as aplicações/processos não autorizados não estão configurados.

• Diretrizes de Provas de Exemplo: forneça a lista documentada de aplicações/processos aprovados, juntamente com a justificação comercial.

• Exemplo de Prova: a seguinte captura de ecrã lista as aplicações aprovadas com justificação comercial.

Nota: Esta captura de ecrã mostra um documento, a expetativa é que os ISVs partilhem o documento de suporte real e não forneçam uma captura de ecrã.

Controlo n.º 8: forneça documentação de suporte que detalha que o software de controlo de aplicações está configurado para satisfazer mecanismos de controlo de aplicações específicos.

• Intenção: a configuração da tecnologia de controlo de aplicações deve ser documentada juntamente com um processo de manutenção da tecnologia, ou seja, adicionar e eliminar aplicações/processos. Como parte desta documentação, o tipo de mecanismo utilizado deve ser detalhado para cada aplicação/processo. Esta ação irá alimentar o controlo seguinte para garantir que a tecnologia está configurada conforme documentado.

• Diretrizes de Provas de Exemplo: forneça documentação de suporte que detalha como o controlo de aplicações foi configurado e como cada aplicação/processo foi configurado na tecnologia.

• Exemplo de Prova: a captura de ecrã seguinte lista o mecanismo de controlo utilizado para implementar o controlo de aplicação. Pode ver abaixo que 1 aplicação está a utilizar controlos de Certificado e as outras que utilizam o caminho do ficheiro.

Nota: Esta captura de ecrã mostra um documento, a expetativa é que os ISVs partilhem o documento de suporte real e não forneçam uma captura de ecrã.

Controlo n.º 9: forneça provas de que o controlo de aplicações está configurado como documentado a partir de todos os componentes do sistema de exemplo.

• Intenção: a intenção é validar que o controlo de aplicação está configurado no exemplo de acordo com a documentação.

• Diretrizes de Evidência de Exemplo: forneça uma captura de ecrã para cada dispositivo no exemplo para mostrar que tem controlos de aplicação configurados e ativados. Isto deve mostrar os nomes dos computadores, os grupos a que pertencem e as políticas de controlo de aplicações aplicadas a esses grupos e computadores.

• Exemplo de Evidência: a seguinte captura de ecrã mostra um objeto de Política de Grupo com Políticas de Restrição de Software ativadas.

Esta captura de ecrã seguinte mostra a configuração em linha com o controlo acima.

Esta captura de ecrã seguinte mostra o Ambiente do Microsoft 365 e os Computadores incluídos no âmbito que está a ser aplicado a este Objeto GPO "Definições do Computador de Domínio".

Esta captura de ecrã final mostra o servidor no âmbito "DBServer1" dentro da UO na captura de ecrã acima.

Gestão de Patches – Classificação de Riscos

A rápida identificação e remediação de vulnerabilidades de segurança ajuda a minimizar os riscos de um grupo de atividade que compromete o ambiente ou a aplicação. A gestão de patches é dividida em duas secções: classificação de riscos e aplicação de patches. Estes três controlos abrangem a identificação de vulnerabilidades de segurança e classificam-nas de acordo com o risco que representam.

Este grupo de controlo de segurança está no âmbito dos ambientes de alojamento PaaS (Plataforma como Serviço), uma vez que as bibliotecas de software de terceiros e a base de código de terceiros do suplemento têm de ser corrigidas com base na classificação de risco.

Controlo n.º 10: documentação da política de fornecimento que regula a forma como as novas vulnerabilidades de segurança são identificadas e atribuídas uma classificação de risco.

• Intenção: a intenção deste controlo é ter documentação de suporte para garantir que as vulnerabilidades de segurança são identificadas rapidamente para reduzir a janela de oportunidade que os grupos de atividade têm de explorar estas vulnerabilidades. É necessário implementar um mecanismo robusto para identificar vulnerabilidades que abrangem todos os componentes do sistema utilizados pelas organizações; por exemplo, sistemas operativos (Windows Server, Ubuntu, etc.), aplicações (Tomcat, MS Exchange, SolarWinds, etc.), dependências de código (AngularJS, jQuery, etc.). As organizações têm de garantir não só a identificação atempada de vulnerabilidades dentro do património, mas também classificar quaisquer vulnerabilidades em conformidade para garantir que a remediação é realizada dentro de um período de tempo adequado com base no risco que a vulnerabilidade apresenta.

Nota Mesmo que esteja a executar num ambiente puramente de Plataforma como Serviço, continua a ter a responsabilidade de identificar vulnerabilidades na sua base de código: ou seja, bibliotecas de terceiros.

• Diretrizes de Provas de Exemplo: forneça a documentação de suporte (não capturas de ecrã)

• Exemplo de Prova: esta captura de ecrã mostra um fragmento de uma política de classificação de risco.

Nota: Esta captura de ecrã mostra um documento de política/processo, a expetativa é que os ISVs partilhem a documentação de política/procedimento de suporte real e não forneçam uma screenshot._

Controlo n.º 11: forneça provas de como as novas vulnerabilidades de segurança são identificadas.

• Intenção: a intenção deste controlo é garantir que o processo está a ser seguido e é suficientemente robusto para identificar novas vulnerabilidades de segurança em todo o ambiente. Estes podem não ser apenas os Sistemas Operativos; pode incluir aplicações em execução no ambiente e quaisquer dependências de código.

• Diretrizes de Provas de Exemplo: as provas podem ser fornecidas através da apresentação de subscrições de listas de correio, da revisão manual das origens de segurança relativas a vulnerabilidades recentemente lançadas (teriam de ser devidamente controladas com carimbos de data/hora das atividades, ou seja, com o JIRA ou o Azure DevOps), ferramentas que localizam software desatualizado (por exemplo, pode ser o Snyk ao procurar bibliotecas de software desatualizadas, ou pode ser Nessus com análises autenticadas que identificam software desatualizado.).

Nota Se utilizar o Nessus, terá de ser executado regularmente para identificar vulnerabilidades rapidamente. Recomendamos pelo menos semanalmente.

• Exemplo de Provas: esta captura de ecrã demonstra que um grupo de correio está a ser utilizado para ser notificado sobre vulnerabilidades de segurança.

Controlo n.º 12: forneça provas que demonstrem que todas as vulnerabilidades recebem uma classificação de risco depois de identificadas.

• Intenção: a aplicação de patches tem de se basear no risco, quanto mais arriscada for a vulnerabilidade, mais rápida será a remediação. A classificação de risco de vulnerabilidades identificadas é parte integrante deste processo. A intenção deste controlo é garantir que existe um processo documentado de classificação de riscos que está a ser seguido para garantir que todas as vulnerabilidades identificadas são devidamente classificadas com base no risco. Normalmente, as organizações utilizam a classificação CVSS (Common Vulnerability Scoring System) fornecida por fornecedores ou investigadores de segurança. Recomenda-se que, se a organização depender do CVSS, seja incluído um mecanismo de nova classificação no processo para permitir que a organização altere a classificação com base numa avaliação de risco interna. Por vezes, a vulnerabilidade pode não ser aplicação devido à forma como a aplicação foi implementada no ambiente. Por exemplo, pode ser lançada uma vulnerabilidade java que afeta uma biblioteca específica que não é utilizada pela organização.

• Diretrizes de Evidência de Exemplo: forneça provas através de uma captura de ecrã ou de outros meios, por exemplo, DevOps/Jira, que demonstra que as vulnerabilidades estão a passar pelo processo de classificação de riscos e a ser atribuída uma classificação de risco adequada pela organização.

• Exemplo de Evidência: esta captura de ecrã mostra a classificação de risco que ocorre na coluna D e a nova classificação nas colunas F e G, caso a organização realize uma avaliação de risco e determine que o risco pode ser reduzido para uma versão anterior. Provas de reavaliação das avaliações de risco teriam de ser fornecidas como prova de apoio

Gestão de Patches – Aplicação de Patches

Os controlos abaixo destinam-se ao elemento de aplicação de patches para Gestão de Patches. Para manter um ambiente operativo seguro, as aplicações/suplementos e os sistemas de suporte têm de ser corrigidos adequadamente. Um período de tempo adequado entre a identificação (ou a versão pública) e a aplicação de patches tem de ser gerido para reduzir a janela de oportunidade para que uma vulnerabilidade seja explorada por um "grupo de atividades". A Certificação do Microsoft 365 não estipula uma "Janela de Aplicação de Patches", no entanto, os Analistas de Certificação irão rejeitar intervalos de tempo que não sejam razoáveis.

Este grupo de controlo de segurança está no âmbito dos ambientes de alojamento PaaS (Plataforma como Serviço), uma vez que as bibliotecas de software de terceiros e a base de código de terceiros do suplemento têm de ser corrigidas com base na classificação de risco.

Controlo n.º 13: forneça documentação de política para a aplicação de patches de componentes do sistema no âmbito que inclua um período de tempo mínimo adequado para a aplicação de patches para vulnerabilidades críticas, de alto e médio risco; e desativação de quaisquer sistemas operativos e software não suportados.

• Intenção: a gestão de patches é necessária por muitas arquiteturas de conformidade de segurança, ou seja, PCI-DSS, ISO 27001, NIST (SP) 800-53. A importância de uma boa gestão de patches não pode ser excessivamente sublinhada, pois pode corrigir problemas de segurança e funcionalidade no software, firmware e mitigar vulnerabilidades, o que ajuda na redução de oportunidades de exploração. O objetivo deste controlo é minimizar a janela de oportunidade que um grupo de atividade tem para explorar vulnerabilidades que possam existir no ambiente no âmbito.

• Diretrizes de Evidência de Exemplo: forneça uma cópia de todas as políticas e procedimentos que detalham o processo de gestão de patches. Isto deve incluir uma secção numa janela de aplicação de patches mínima e que os sistemas operativos e software não suportados não devem ser utilizados no ambiente.

• Exemplo de Prova: abaixo encontra-se um documento de política de exemplo.

Nota: Esta captura de ecrã mostra um documento de política/processo, a expetativa é que os ISVs partilhem a documentação de política/procedimento de suporte real e não forneçam simplesmente uma screenshot._

Controlo n.º 14: forneça provas de que todos os componentes do sistema de amostra estão a ser corrigidos.

Nota: Inclua quaisquer bibliotecas de software/terceiros.

• Intenção: a aplicação de patches às vulnerabilidades garante que os diferentes módulos que fazem parte da infraestrutura de tecnologias de informação (hardware, software e serviços) são mantidos atualizados e livres de vulnerabilidades conhecidas. A aplicação de patches tem de ser efetuada o mais rapidamente possível para minimizar o potencial de um incidente de segurança entre a divulgação de detalhes de vulnerabilidade e a aplicação de patches. Isto é ainda mais crítico onde a exploração de vulnerabilidades conhecidas por estarem na natureza.

• Diretrizes de Evidência de Exemplo: forneça uma captura de ecrã para cada dispositivo no exemplo e suporte de componentes de software que mostram que os patches estão instalados em conformidade com o processo de aplicação de patches documentado.

• Exemplo de Prova: a seguinte captura de ecrã mostra que o componente do sistema no âmbito "CLARANET-SBU-WM" está a realizar atualizações do Windows em conformidade com a política de aplicação de patches.

Nota: A aplicação de patches de todos os componentes do sistema no âmbito tem de ser uma prova. Isto inclui aspetos como; Atualizações do SO, Atualizações de Aplicações/Componentes (i.e__.,_ Apache Tomcat, OpenSSL, etc.), Dependências de Software (por exemplo, JQuery, AngularJS, etc.), etc.

Controlo n.º 15: forneça provas de que quaisquer sistemas operativos e componentes de software não suportados não são utilizados no ambiente.

• Intenção: o software que não está a ser mantido pelos fornecedores sofrerá, horas extraordinárias, de vulnerabilidades conhecidas que não são corrigidas. Por conseguinte, a utilização de sistemas operativos e componentes de software não suportados não pode ser utilizada em ambientes de produção.

• Diretrizes de Provas de Exemplo: forneça uma captura de ecrã para cada dispositivo no exemplo que mostra a versão do SO em execução (incluindo o nome do servidor na captura de ecrã). Além disso, forneça provas de que os componentes de software em execução no ambiente estão a executar versões suportadas. Isto pode ser feito ao fornecer a saída de relatórios internos de análise de vulnerabilidades (desde que a análise autenticada esteja incluída) e/ou a saída de ferramentas que verificam bibliotecas de terceiros, como o Snyk, Trivy ou Auditoria NPM. Se estiver em execução apenas no PaaS, apenas a aplicação de patches de biblioteca de terceiros tem de ser abrangida pelos grupos de controlo de aplicação de patches.

• Exemplo de Evidência: as seguintes evidências mostram que o componente de sistema no âmbito THOR está a executar software que é suportado pelo fornecedor, uma vez que o Nessus não sinalizou nenhum problema.

Nota: O relatório completo tem de ser partilhado com os Analistas de Certificação.

• Exemplo de Prova 2

Esta captura de ecrã mostra que o componente de sistema no âmbito "CLARANET-SBU-WM" está em execução numa versão suportada do Windows.

• Exemplo de Prova 3

A captura de ecrã seguinte é da saída Trivy , que o relatório completo não lista nenhuma aplicação não suportada.

Nota: O relatório completo tem de ser partilhado com os Analistas de Certificação.

Verificação de vulnerabilidade

Ao introduzir avaliações regulares de vulnerabilidades, as organizações podem detetar fraquezas e inseguranças nos seus ambientes, o que pode fornecer um ponto de entrada para um ator malicioso comprometer o ambiente. A análise de vulnerabilidades pode ajudar a identificar patches em falta ou configurações incorretas no ambiente. Ao realizar regularmente estas análises, uma organização pode fornecer uma remediação adequada para minimizar o risco de um compromisso devido a problemas que são normalmente recolhidos por estas ferramentas de análise de vulnerabilidades.

Controlo n.º 16: forneça os relatórios trimestrais de análise de vulnerabilidades da infraestrutura e da aplicação Web. A análise tem de ser realizada relativamente a toda a quantidade de espaço público (endereços IP e URLs) e aos intervalos de IP internos.

Nota: Isto TEM de incluir o âmbito completo do ambiente.

• Intenção: a análise de vulnerabilidades procura possíveis fraquezas num sistema informático, redes e aplicações Web de organizações para identificar buracos que possam potencialmente levar a falhas de segurança e à exposição de dados confidenciais. A análise de vulnerabilidades é frequentemente exigida pelas normas da indústria e regulamentos governamentais, por exemplo, o PCI DSS (Payment Card Industry Data Security Standard).

• Um relatório da Métrica de Segurança intitulado "Guia de Métricas de Segurança de 2020 para a Conformidade do PCI DSS" afirma que "em média, demorou 166 dias a partir do momento em que uma organização foi vista a ter vulnerabilidades para um atacante comprometer o sistema. Depois de comprometidos, os atacantes tiveram acesso a dados confidenciais durante uma média de 127 dias, pelo que este controlo visa identificar potenciais fraquezas de segurança no ambiente no âmbito.

• Exemplo de Diretrizes de Evidência: forneça os relatórios de análise completos para as análises de vulnerabilidades de cada trimestre que foram realizadas nos últimos 12 meses. Os relatórios devem indicar claramente os objetivos para validar que a quantidade total de espaço público está incluída e, quando aplicável, cada sub-rede interna. Indique TODOS os relatórios de análise para CADA trimestre.

• Exemplo de Prova: a Prova de Exemplo seria fornecer os relatórios de análise da ferramenta de análise que está a ser utilizada. Os relatórios de análise de cada trimestre devem ser fornecidos para revisão. A análise tem de incluir todos os componentes do sistema de ambientes, por isso; todas as sub-redes internas e todos os Endereços IP/URL públicos que estão disponíveis para o ambiente.

Controlo n.º 17: forneça provas de que a remediação de vulnerabilidades identificadas durante a análise de vulnerabilidades é corrigida de acordo com o período de aplicação de patches documentado.

• Intenção: a falha na identificação, gestão e remediação de vulnerabilidades e configurações incorretas rapidamente pode aumentar o risco de uma organização comprometer o que leva a potenciais violações de dados. Identificar e remediar corretamente problemas é visto como importante para a postura e o ambiente de segurança gerais de uma organização que está em conformidade com as melhores práticas de várias estruturas de segurança para; exemplo, ISO 27001 e PCI DSS.

• Diretrizes de Evidência de Exemplo: forneça artefactos adequados (ou seja, capturas de ecrã) que mostram que uma amostra das vulnerabilidades detetadas da análise de vulnerabilidades são remediadas em conformidade com as janelas de aplicação de patches já fornecidas no Controlo 13 acima.

• Exemplo de Evidência: a seguinte captura de ecrã mostra uma análise Nessus do ambiente no âmbito (uma única máquina neste exemplo com o nome "THOR") a mostrar vulnerabilidades no dia 2 de agosto de 2021.

A captura de ecrã seguinte mostra que os problemas foram resolvidos, 2 dias depois, que se encontra na janela de aplicação de patches definida na política de aplicação de patches.

Nota: Para este controlo, os Analistas de Certificação precisam de ver relatórios de análise de vulnerabilidades e remediação para cada trimestre nos últimos doze meses.

Firewalls

Muitas vezes, as firewalls fornecem um limite de segurança entre ambientes fidedignos (rede interna), não fidedignos (Internet) e semi-fidedignos (DMZ). Normalmente, esta será a primeira linha de defesa dentro de uma estratégia de segurança de defesa em profundidade de organizações, concebida para controlar fluxos de tráfego para serviços de entrada e saída e para bloquear tráfego indesejado. Estes dispositivos têm de ser fortemente controlados para garantir que funcionam eficazmente e estão livres de configurações incorretas que possam colocar o ambiente em risco.

Controlo n.º 18: forneça documentação de política que regule as práticas e procedimentos de gestão da firewall.

• Intenção: as firewalls são uma importante primeira linha de defesa numa estratégia de segurança em camadas (defesa em profundidade), protegendo ambientes contra zonas de rede menos fidedignas. Normalmente, as firewalls controlam os fluxos de tráfego com base em Endereços IP e protocolos/portas. Mais firewalls avançadas de funcionalidades também podem fornecer defesas de "camada de aplicação" adicionais ao inspecionar o tráfego da aplicação para proteger contra utilização indevida, vulnerabilidades e ameaças com base nas aplicações que estão a ser acedidas. Estas proteções são tão boas quanto a configuração da firewall, pelo que é necessário implementar políticas de firewall fortes e procedimentos de suporte para garantir que estão configuradas para fornecer uma proteção adequada dos recursos internos. Por exemplo, uma firewall com uma regra para permitir todo o tráfego de qualquer origem para qualquer destino está apenas a funcionar como um router.

• Exemplo de Diretrizes de Evidência: forneça a documentação completa de suporte da política/procedimento da firewall. Este documento deve abranger todos os pontos abaixo e quaisquer melhores práticas adicionais aplicáveis ao seu ambiente.

• Exemplo de Evidência: abaixo encontra-se um exemplo do tipo de documento de política de firewall de que precisamos (esta é uma demonstração e pode não estar concluída).

Controlo n.º 19: forneça provas demonstráveis de que as credenciais administrativas predefinidas são alteradas antes da instalação em ambientes de produção.

• Intenção: as organizações têm de estar atentas às credenciais administrativas predefinidas fornecidas pelo fornecedor que são configuradas durante a configuração do dispositivo ou software. As credenciais predefinidas são frequentemente disponibilizadas publicamente pelos fornecedores e podem proporcionar a um grupo de atividade externa a oportunidade de comprometer um ambiente. Por exemplo, uma pesquisa simples na Internet para as credenciais predefinidas do iDrac (Integrated Dell Remote Access Controller) irá realçar root::calvin como o nome de utilizador e a palavra-passe predefinidos. Isto dará a alguém acesso remoto à gestão remota do servidor. A intenção deste controlo é garantir que os ambientes não são suscetíveis a ataques através de credenciais de fornecedor predefinidas que não tenham sido alteradas durante a proteção do dispositivo/aplicação.

• Diretrizes de Provas de Exemplo

• Isto pode ser evidenciado numa sessão de partilha de ecrã em que o Analista de Certificação pode tentar autenticar-se nos dispositivos no âmbito com as credenciais predefinidas.

• Exemplo de Provas

A captura de ecrã abaixo mostra o que o Analista de Certificação veria a partir de um nome de utilizador/palavra-passe inválido de uma Firewall do WatchGuard.

Controlo 20: forneça provas demonstrativas de que as firewalls estão instaladas no limite do ambiente no âmbito e instaladas entre a rede de perímetro (também conhecida como DMZ, zona desmilitarizada e sub-rede filtrada) e redes fidedignas internas.

• Intenção: as firewalls permitem controlar o tráfego entre diferentes zonas de rede de diferentes níveis de segurança. Uma vez que todos os ambientes estão ligados à Internet, as firewalls têm de ser instaladas no limite, ou seja, entre a Internet e o ambiente no âmbito. Além disso, as firewalls têm de ser instaladas entre as redes DMZ (Zona Desmilitarizada) menos fidedignas e redes fidedignas internas. Normalmente, as DMZs são utilizadas para servir o tráfego da Internet e, por conseguinte, são alvo de ataques. Ao implementar uma rede de perímetro e utilizar uma firewall para controlar os fluxos de tráfego, um compromisso da DMZ não significa necessariamente um compromisso das redes fidedignas internas e dos dados empresariais/do cliente. Devem existir alertas e registos adequados para ajudar as organizações a identificar rapidamente um compromisso para minimizar a oportunidade de o grupo de atividade comprometer ainda mais as redes fidedignas internas. O objetivo deste controlo é garantir que existe um controlo adequado entre redes fidedignas e menos fidedignas.

• Diretrizes de Evidência de Exemplo: as provas devem ser fornecidas através de ficheiros de configuração da firewall ou capturas de ecrã que demonstrem que uma rede de perímetro está em vigor. Isto deve corresponder aos diagramas de arquitetura fornecidos que demonstram as diferentes redes que suportam o ambiente. Uma captura de ecrã das interfaces de rede na firewall, juntamente com o diagrama de rede já fornecido como parte da Submissão Inicial do Documento, deve fornecer estas provas.

• Exemplo de Prova: abaixo encontra-se uma captura de ecrã de uma firewall do WatchGuard que demonstra duas DMZs, uma é para os serviços de entrada (denominado DMZ), a outra está a servir a jumpbox (Anfitrião Bastian).

Controlo 21: forneça provas demonstráveis de que todos os acessos públicos terminam na zona desmilitarizada (DMZ).

• Intenção: os recursos acessíveis publicamente estão abertos a uma miríade de ataques. Tal como já foi abordado acima, a intenção de uma rede de perímetro é segmentar redes menos fidedignas de redes internas fidedignas que possam conter dados confidenciais. Uma rede de perímetro é considerada menos fidedigna, uma vez que existe um grande risco de os anfitriões acessíveis publicamente serem comprometidos por grupos de atividades externas. O acesso público deve terminar sempre nestas redes menos fidedignas, que são segmentadas adequadamente pela firewall para ajudar a proteger os recursos internos e os dados. O objetivo deste controlo é garantir que todos os acessos públicos terminem dentro destas DMZs menos fidedignas como se os recursos nas redes internas fidedignas fossem destinados ao público, um compromisso destes recursos fornece a um grupo de atividade uma posição de base na rede onde estão a ser mantidos dados confidenciais.

• Diretrizes de Provas de Exemplo

• As provas fornecidas podem ser configurações de firewall que mostram as regras de entrada e onde estas regras estão a terminar, quer através do encaminhamento de Endereços IP públicos para os recursos, quer ao fornecer o NAT (Tradução de Endereços de Rede) do tráfego de entrada.

• Exemplo de Provas

Na captura de ecrã abaixo, existem três regras de entrada, cada uma a mostrar as sub-redes NAT para 10.0.3.x e 10.0.4.x, que são as sub-redes DMZ

Controlo 22: forneça provas demonstráveis de que todo o tráfego permitido através da firewall passa por um processo de aprovação.

• Intenção: uma vez que as firewalls são uma barreira defensiva entre o tráfego não fidedigno e os recursos internos e entre redes de diferentes níveis de confiança, as firewalls têm de ser configuradas de forma segura e garantir que apenas o tráfego necessário para as operações empresariais está ativado. Ao permitir um fluxo de tráfego desnecessário ou um fluxo de tráfego excessivamente permissivo, isto pode introduzir pontos fracos na defesa no limite destas várias zonas de rede. Ao estabelecer um processo de aprovação robusto para todas as alterações da firewall, o risco de introdução de uma regra que introduz um risco significativo para o ambiente é reduzido. O Relatório de Investigação de Violação de Dados da Verizon de 2020 destaca que "Erros", que inclui configurações incorretas, é o único tipo de ação que está constantemente a aumentar de ano para ano.

• Exemplo de Diretrizes de Evidência: as provas podem estar na forma de documentação que mostra um pedido de alteração da firewall autorizado, que pode estar a minutos de uma reunião cab (Conselho do Assistente de Alterações) ou por um sistema de controlo de alterações que controla todas as alterações.

• Exemplo de Prova: a seguinte captura de ecrã mostra uma alteração da regra de firewall que está a ser pedida e autorizada através de um processo baseado em papel. Isto pode ser conseguido através de algo como DevOps ou Jira, por exemplo.

Controlo 23: forneça provas demonstráveis de que a base da regra de firewall está configurada para remover o tráfego não explicitamente definido.

• Intenção: a maioria das firewalls processará as regras numa abordagem de cima para baixo para tentar encontrar uma regra correspondente. Se uma regra corresponder, a ação dessa regra será aplicada e todo o processamento adicional das regras irá parar. Se não forem encontradas regras correspondentes, por predefinição, o tráfego é negado. A intenção deste controlo é que, se a firewall não remover o tráfego por predefinição se não for encontrada nenhuma regra correspondente, a base de regras tem de incluir uma regra "Negar Tudo" no final de TODAS as listas de firewall. Isto é para garantir que a firewall não está predefinida num estado de permissão predefinido ao processar as regras, permitindo assim o tráfego que não foi explicitamente definido.

• Exemplo de Diretrizes de Evidência: as provas podem ser fornecidas através da configuração da firewall ou capturas de ecrã que mostram todas as regras da firewall que mostram uma regra "Negar Tudo" no final ou, se a firewall deixar cair o tráfego que não corresponde a uma regra por predefinição, forneça uma captura de ecrã de todas as regras da firewall e uma ligação para os guias administrativos do fornecedor, realçando que, por predefinição, a firewall irá remover todo o tráfego não correspondido.

• Exemplo de Prova: abaixo encontra-se uma captura de ecrã da base de regras de firewall do WatchGuard que demonstra que não estão configuradas regras para permitir todo o tráfego. não existe nenhuma regra de negação no final porque o WatchGuard irá remover o tráfego que não corresponde por predefinição.

A seguinte ligação do Centro de Ajuda do WatchGuard; https://www.watchguard.com/help/docs/help-center/en-US/Content/en-US/Fireware/policies/policies_about_c.html inclui as seguintes informações:

Controlo 24: forneça provas demonstráveis de que a firewall suporta apenas criptografia forte em todas as interfaces administrativas não consola.

• Intenção: para mitigar ataques man-in-the-middle de tráfego administrativo, todas as interfaces administrativas não consola devem suportar apenas criptografia forte. A principal intenção deste controlo é proteger as credenciais administrativas, uma vez que a ligação não consola é configurada. Além disso, isto também pode ajudar a proteger contra escutas na ligação, tentando reproduzir funções administrativas para reconfigurar o dispositivo ou como parte do reconhecimento.

• Exemplo de Diretrizes de Evidência: indique a configuração da firewall, se a configuração fornecer a configuração criptográfica das interfaces administrativas não consola (nem todos os dispositivos irão incluí-lo como opções configuráveis). Se isto não estiver dentro da configuração, poderá conseguir emitir comandos para o dispositivo para apresentar o que está configurado para estas ligações. Alguns fornecedores podem publicar estas informações em artigos, pelo que esta também pode ser uma forma de evidenciar estas informações. Por fim, poderá ter de executar ferramentas para exportar a encriptação suportada.

• Exemplo de Evidência: a captura de ecrã abaixo mostra a saída de SSLScan na interface de Administrador Web da firewall do WatchGuard na porta TCP 8080. Isto mostra o TLS 1.2 ou superior com uma cifra de encriptação mínima de AES-128bit.

Nota: as firewalls do WatchGuard também suportam funções administrativas com SSH (Porta TCP 4118) e WatchGuard System Manager (Portas TCP 4105 & 4117). Também é necessário fornecer provas destas interfaces administrativas que não sejam da consola.

Controlo 25: forneça provas de que está a efetuar revisões de regras de firewall, pelo menos, a cada 6 meses.

• Intenção: ao longo do tempo, existe o risco de a configuração aumentar os componentes do sistema com o ambiente no âmbito. Isto pode, muitas vezes, introduzir inseguranças ou configurações incorretas que podem aumentar o risco de comprometimento para o ambiente. O rastejante de configuração pode ser introduzido por inúmeras razões, tais como alterações temporárias para ajudar na resolução de problemas, alterações temporárias para alterações funcionais ad-hoc, para introduzir correções rápidas a problemas que, por vezes, podem ser excessivamente permissivos devido às pressões da introdução de uma correção rápida. Por exemplo, pode introduzir uma regra de firewall temporária "Permitir Tudo" para ultrapassar um problema urgente. A intenção deste controlo é dupla, em primeiro lugar para identificar onde existem configurações incorretas que podem introduzir inseguranças e, em segundo lugar, para ajudar a identificar regras de firewall que já não são necessárias e, portanto, podem ser removidas, ou seja, se um serviço tiver sido descontinuado, mas a regra da firewall tiver sido deixada para trás.

• Exemplo de Diretrizes de Provas: as provas têm de ser capazes de demonstrar que as reuniões de revisão estão a ocorrer. Isto pode ser feito ao partilhar atas de reunião da revisão da firewall e quaisquer provas adicionais de controlo de alterações que mostrem quaisquer ações tomadas a partir da revisão. Certifique-se de que as datas estão presentes, pois precisamos de ver um mínimo de duas destas reuniões (ou seja, a cada seis meses)

• Exemplo de Provas: a seguinte captura de ecrã mostra provas de uma revisão da Firewall que ocorre em janeiro de 2021.

A seguinte captura de ecrã mostra provas de uma revisão da Firewall que ocorre em julho de 2021.

Firewalls – WAFs

é opcional implementar uma Firewall de Aplicações Web (WAF) na solução. Se for utilizada uma WAF, isto contará como créditos adicionais para a matriz de classificação no domínio de segurança "Segurança Operacional". As WAFs podem inspecionar o tráfego da Web para filtrar e monitorizar o tráfego da Web entre a Internet e as aplicações Web publicadas para identificar ataques específicos de aplicações Web. As aplicações Web podem sofrer de muitos ataques específicos a aplicações Web, como Injeção de SQL (SQLi), Scripting entre Sites (XSS), Falsificação de Pedidos entre Sites (CSRF/XSRF), etc. e AS WAFs foram concebidas para proteger contra estes tipos de payloads maliciosos para ajudar a proteger as aplicações Web contra ataques e potenciais compromissos.

Controlo 26: forneça provas de que a Firewall de Aplicações Web (WAF) está configurada para monitorizar, alertar e bloquear ativamente o tráfego malicioso.

• Intenção: este controlo está implementado para confirmar que a WAF está implementada para todas as ligações Web recebidas e que está configurada para bloquear ou alertar para tráfego malicioso. Para fornecer uma camada adicional de defesa para o tráfego da Web, as WAFs têm de ser configuradas para todas as ligações Web recebidas. Caso contrário, os grupos de atividades externas podem ignorar as WAFs concebidas para fornecer esta camada adicional de proteção. Se a WAF não estiver configurada para bloquear ativamente o tráfego malicioso, a WAF tem de ser capaz de fornecer um alerta imediato à equipa que possa reagir rapidamente ao potencial tráfego malicioso para ajudar a manter a segurança do ambiente e parar os ataques.

• Diretrizes de Evidência de Exemplo: forneça o resultado da configuração da WAF, que realça as ligações Web recebidas que estão a ser servidas e que a configuração bloqueia ativamente o tráfego malicioso ou está a monitorizar e a alertar. Em alternativa, as capturas de ecrã das definições específicas podem ser partilhadas para demonstrar que uma organização está a cumprir este controlo.

• Exemplo de Evidência: as seguintes capturas de ecrã mostram que a política WAF do Gateway de Aplicação do Azure de Produção da Contoso está ativada e que está configurada para o modo "Prevenção", o que irá diminuir ativamente o tráfego malicioso.

A captura de ecrã abaixo mostra a configuração do IP de Front-end

Nota: As provas devem demonstrar todos os IPs públicos utilizados pelo ambiente para garantir que todos os pontos de entrada são abrangidos, razão pela qual esta captura de ecrã também está incluída.

A captura de ecrã abaixo mostra as ligações Web recebidas com esta WAF.

A seguinte captura de ecrã mostra o Contoso_AppGW_CoreRules a mostrar que se destina ao serviço api.contoso.com.

Controlo 27: forneça provas demonstráveis de que a WAF suporta a descarga de SSL.

• Intenção: a capacidade de a WAF ser configurada para suportar a Descarga de SSL é importante. Caso contrário, a WAF não conseguirá inspecionar o tráfego HTTPS. Uma vez que estes ambientes precisam de suportar o tráfego HTTPS, esta é uma função crítica para a WAF para garantir que payloads maliciosos dentro do tráfego HTTPS podem ser identificados e parados.

• Diretrizes de Evidência de Exemplo: forneça provas de configuração através de uma exportação de configuração ou capturas de ecrã que mostram que a Descarga de SSL é suportada e configurada.

• Exemplo de Prova: no Gateway de Aplicação do Azure, configuração de uma Descarga de SSL ativada pelo Serviço de Escuta SSL, veja a descrição geral da terminação do TLS e do TLS ponto a ponto com o Gateway de Aplicação microsoft Docs página. A captura de ecrã seguinte mostra esta configuração para o Gateway de Aplicação do Azure de Produção da Contoso.

Controlo 28: "Forneça provas de que a WAF é protegida contra algumas ou todas as seguintes classes de vulnerabilidades de acordo com o Conjunto de Regras De Núcleo do OWASP (3.0 ou 3.1):

• problemas de protocolo e codificação,

• injeção de cabeçalhos, contrabando de pedidos e divisão de respostas,

• ataques de passagem de ficheiros e caminhos,

• ataques de inclusão remota de ficheiros (RFI),

• ataques de execução de código remoto,

• Ataques de injeção php,

• ataques de scripting entre sites,

• Ataques de injeção de SQL,

• ataques de fixação de sessão.

• Intenção: as WAFs têm de ser configuradas para identificar payloads de ataques para classes comuns de vulnerabilidades. Este controlo pretende garantir que a deteção adequada das classes de vulnerabilidade é abrangida ao tirar partido do Conjunto de Regras De Núcleo do OWASP.

• Exemplo de Diretrizes de Evidência: forneça provas de configuração através de uma exportação de configuração ou capturas de ecrã que demonstram que a maioria das classes de vulnerabilidade identificadas acima estão a ser abrangidas pela análise.

• Exemplo de Evidência: a captura de ecrã abaixo mostra que a política WAF do Gateway de Aplicação do Azure de Produção da Contoso está configurada para analisar a Versão 3.2 do Conjunto de Regras Principais do OWASP.

Alterar Controlo

Um processo de controlo de alterações estabelecido e compreendido é essencial para garantir que todas as alterações passam por um processo estruturado que é repetível. Ao garantir que todas as alterações passam por um processo estruturado, as organizações podem garantir que as alterações são geridas de forma eficaz, revistas pelo elemento da rede e testadas adequadamente antes de serem assinadas. Isto não só ajuda a minimizar o risco de indisponibilidade do sistema, como também ajuda a minimizar o risco de potenciais incidentes de segurança através da introdução de alterações inadequadas.

Controlo 29: forneça a documentação da política que rege os processos de controlo de alterações.

• Intenção: para manter um ambiente seguro e uma aplicação segura, tem de ser estabelecido um processo robusto de controlo de alterações para garantir que todas as alterações de infraestrutura e código são realizadas com uma forte supervisão e processos definidos. Isto garante que as alterações são documentadas, as implicações de segurança são consideradas, pensa-se que foi afetado pela segurança que a alteração terá, etc. A intenção é garantir que o processo de controlo de alterações está documentado para garantir que é tomada uma abordagem segura e consistente a todas as alterações no ambiente e nas práticas de desenvolvimento de aplicações.

• Diretrizes de Evidência de Exemplo: os procedimentos/políticas de controlo de alteração documentados devem ser partilhados com os Analistas de Certificação.

• Exemplo de Evidência: abaixo mostra o início de uma política de gestão de alterações de exemplo. Forneça as suas políticas e procedimentos completos como parte da avaliação.

Nota: Esta captura de ecrã mostra um documento de política/processo, a expetativa é que os ISVs partilhem a documentação de política/procedimento de suporte real e não apenas forneçam uma captura de ecrã.

Controlo 30: forneça provas de que os ambientes de desenvolvimento e teste impõem a separação de deveres do ambiente de produção.

• Intenção: a maioria dos ambientes de desenvolvimento/teste da organização não estão configurados com o mesmo vigor que os ambientes de produção e, portanto, são menos seguros. Além disso, os testes não devem ser realizados no ambiente de produção, uma vez que isto pode introduzir problemas de segurança ou pode ser prejudicial para a entrega de serviços para os clientes. Ao manter ambientes separados que impõem uma separação de deveres, as organizações podem garantir que as alterações estão a ser aplicadas aos ambientes corretos, reduzindo assim o risco de erros ao implementar alterações nos ambientes de produção quando se destinava ao ambiente de desenvolvimento/teste.

• Diretrizes de Evidência de Exemplo: podem ser fornecidas capturas de ecrã que demonstram diferentes ambientes que estão a ser utilizados para ambientes de desenvolvimento/teste e ambientes de produção. Normalmente, teria pessoas/equipas diferentes com acesso a cada ambiente ou, quando tal não é possível, os ambientes utilizariam diferentes serviços de autorização para garantir que os utilizadores não conseguem iniciar sessão erradamente no ambiente errado para aplicar alterações.

• Exemplo de Prova: a seguinte captura de ecrã mostra uma subscrição do Azure para o ambiente DE TESTE da Contoso.

Esta captura de ecrã seguinte mostra uma subscrição do Azure separada para o ambiente "PRODUÇÃO" da Contoso.

Controlo 31: forneça provas de que os dados de produção confidenciais não são utilizados nos ambientes de desenvolvimento ou teste.

• Intenção: tal como já foi abordado acima, as organizações não implementarão medidas de segurança de um ambiente de desenvolvimento/teste com o mesmo vigor que o ambiente de produção. Por conseguinte, ao utilizar dados de produção confidenciais nestes ambientes de desenvolvimento/teste, está a aumentar o risco de um compromisso e tem de evitar a utilização de dados confidenciais/dinâmicos nestes ambientes de desenvolvimento/teste.

Nota: Pode utilizar dados dinâmicos em ambientes de desenvolvimento/teste, desde que o desenvolvimento/teste esteja incluído no âmbito da avaliação para que a segurança possa ser avaliada em relação aos controlos de Certificação do Microsoft 365.

• Diretrizes de Evidência de Exemplo: as provas podem ser fornecidas ao partilhar capturas de ecrã da saída da mesma consulta SQL numa base de dados de produção (redigir informações confidenciais) e na base de dados de desenvolvimento/teste. O resultado dos mesmos comandos deve produzir conjuntos de dados diferentes. Quando os ficheiros estão a ser armazenados, a visualização do conteúdo das pastas em ambos os ambientes também deve demonstrar diferentes conjuntos de dados.

• Exemplo de Prova: a seguinte captura de ecrã mostra os 3 registos principais (para submissão de provas, forneça os 20 primeiros) da Base de Dados de Produção.

A captura de ecrã seguinte mostra a mesma consulta da Base de Dados de Desenvolvimento, que mostra registos diferentes.

Isto demonstra que os conjuntos de dados são diferentes.

Controlo 32: forneça provas de que os pedidos de alteração documentados contêm o impacto da alteração, os detalhes dos procedimentos de back-out e os testes a serem realizados.

• Intenção: A intenção deste controlo é garantir que o pensamento entrou na mudança que está a ser pedida. O impacto que a alteração tem na segurança do sistema/ambiente tem de ser considerado e claramente documentado, todos os procedimentos de back-out têm de ser documentados para ajudar na recuperação caso algo corresse mal e, por fim, os detalhes dos testes necessários para validar a alteração foram bem-sucedidos também têm de ser pensados e documentados.

• Diretrizes de Provas de Exemplo: as provas podem ser fornecidas ao exportar uma amostra de pedidos de alteração, ao fornecer pedidos de alteração em papel ou ao fornecer capturas de ecrã dos pedidos de alteração que mostram estes três detalhes contidos no pedido de alteração.

• Exemplo de Prova: a imagem abaixo mostra uma nova Vulnerabilidade de Scripting entre Sites (XSS) a ser atribuída e um documento para pedido de alteração.

Os bilhetes abaixo mostram as informações que foram definidas ou adicionadas ao bilhete na sua viagem para serem resolvidas.

Os dois bilhetes abaixo mostram o impacto da alteração no sistema e quaisquer procedimentos de recuo que possam ser necessários em caso de problema. Pode ver o impacto das alterações e os procedimentos de back-out passaram por um processo de aprovação e foram aprovados para testes.

No lado esquerdo do ecrã, pode ver que o teste das alterações foi aprovado, à direita vê que as alterações foram agora aprovadas e testadas.

Ao longo do processo, tenha em atenção que a pessoa que está a fazer o trabalho, a pessoa que o reporta e a pessoa que aprova o trabalho a fazer são pessoas diferentes.

O pedido acima mostra que as alterações foram agora aprovadas para implementação no ambiente de produção. A caixa do lado direito mostra que o teste funcionou e foi bem-sucedido e que as alterações foram agora implementadas no Ambiente Prod.

Controlo 33: forneça provas de que os pedidos de alteração são submetidos a um processo de autorização e fim de sessão.

• Intenção: tem de ser implementado um processo que proíba que as alterações sejam realizadas sem autorização adequada e termine sessão. A alteração tem de ser autorizada antes de ser implementada e a alteração tem de ser assinada depois de concluída. Isto garante que os pedidos de alteração foram devidamente revistos e que alguém na autoridade assinou a alteração.

• Diretrizes de Evidência de Exemplo: as provas podem ser fornecidas ao exportar uma amostra de pedidos de alteração, ao fornecer pedidos de alteração em papel ou ao fornecer capturas de ecrã dos pedidos de alteração que mostram que a alteração foi autorizada, antes da implementação, e que a alteração foi assinada depois de concluída.

• Exemplo de Prova: a captura de ecrã abaixo mostra um pedido Jira de exemplo que mostra que a alteração tem de ser autorizada antes de ser implementada e aprovada por outra pessoa que não o programador/requerente. Pode ver que as alterações aqui aprovadas por alguém com autoridade. A direita foi assinada pelo DP depois de concluída.

No pedido abaixo, pode ver que a alteração foi terminada depois de concluída e mostra a tarefa concluída e fechada.

Desenvolvimento/Implementação de Software Seguro

As organizações envolvidas em atividades de desenvolvimento de software são frequentemente confrontadas com prioridades concorrentes entre as pressões de segurança e TTM (Time to Market), no entanto, a implementação de atividades relacionadas com a segurança ao longo do ciclo de vida de desenvolvimento de software (SDLC) não só pode poupar dinheiro, como também poupar tempo. Quando a segurança é deixada como uma reflexão posterior, os problemas são geralmente identificados apenas durante a fase de teste do (DSLC), o que, muitas vezes, pode ser mais demorado e dispendioso de corrigir. A intenção desta secção de segurança é garantir que são seguidas práticas seguras de desenvolvimento de software para reduzir o risco de falhas de codificação introduzidas no software desenvolvido. Além disso, esta secção procura incluir alguns controlos para ajudar na implementação segura de software.

Controlo 34: forneça políticas e procedimentos que suportem desenvolvimento e implementação de software seguro, incluindo orientações de melhores práticas de codificação segura contra classes de vulnerabilidade comuns, como OWASP Top 10 ou SANS Top 25 CWE.

• Intenção: as organizações precisam de fazer tudo o que estiver ao seu alcance para garantir que o software é desenvolvido de forma segura e livre de vulnerabilidades. Num melhor esforço para o conseguir, deve ser estabelecido um ciclo de vida de desenvolvimento de software seguro robusto (SDLC) e melhores práticas de codificação segura para promover técnicas de codificação seguras e desenvolvimento seguro em todo o processo de desenvolvimento de software. A intenção é reduzir o número e a gravidade das vulnerabilidades no software.

• Diretrizes de Evidência de Exemplo: forneça a documentação documentada do SDLC e/ou suporte que demonstra que está a ser utilizado um ciclo de vida de desenvolvimento seguro e que são fornecidas orientações para todos os programadores promoverem melhores práticas de codificação segura. Veja o OWASP no SDLC e o OWASP Software Assurance Maturity Model (SAMM).

• Exemplo de Evidência: o seguinte é um extrato do Procedimento de Desenvolvimento de Software Seguro da Contoso, que demonstra práticas seguras de programação e codificação.

Nota: Estas capturas de ecrã mostram o documento de desenvolvimento de software seguro, a expectativa é que os ISVs partilhem a documentação de suporte real e não apenas forneçam uma captura de ecrã.

Controlo 35: forneça provas de que as alterações de código são submetidas a um processo de revisão e autorização por um segundo revisor.

• Intenção: a intenção deste controlo é efetuar uma revisão de código por outro programador para ajudar a identificar quaisquer erros de codificação que possam introduzir uma vulnerabilidade no software. A autorização deve ser estabelecida para garantir que as revisões de código são realizadas, os testes são realizados, etc. antes da implementação. O passo de autorização pode validar se foram seguidos os processos corretos que sustentam o SDLC definido acima.

• Diretrizes de Provas de Exemplo: forneça provas de que o código é submetido a uma revisão ponto a ponto e tem de ser autorizado antes de poder ser aplicado ao ambiente de produção. Estes elementos de prova podem ser através de uma exportação de bilhetes de alteração, demonstrando que foram realizadas revisões de código e as alterações autorizadas, ou podem ser através de software de revisão de código, como Crucible (https://www.atlassian.com/software/crucible).

• Exemplo de Provas

Segue-se um pedido de suporte que mostra que as alterações de código são submetidas a um processo de revisão e autorização por outra pessoa que não seja o programador original. Mostra que foi pedida uma revisão de código pelo detentor e que será atribuída a outra pessoa para a revisão do código.

A imagem abaixo mostra que a revisão de código foi atribuída a alguém que não seja o programador original, conforme mostrado pela secção realçada no lado direito da imagem abaixo. No lado esquerdo, pode ver que o código foi revisto e recebe o estado "REVISÃO DO CÓDIGO TRANSMITIDO" pelo revisor de código.

O pedido de suporte tem agora de ser aprovado por um gestor para que as alterações possam ser colocadas em sistemas de produção em direto.

A imagem acima mostra que o código revisto foi aprovado para ser implementado nos sistemas de produção em direto.

Assim que as alterações ao código tiverem sido efetuadas, a tarefa final termina a sessão, conforme mostrado na imagem acima.

Tenha em atenção que ao longo do processo existem três pessoas envolvidas, o programador original do código, o revisor de código e um gestor para dar aprovação e terminar sessão. Para cumprir os critérios para este controlo, seria uma expectativa que os seus pedidos de suporte seguissem este processo. No mínimo, três pessoas envolvidas no processo de controlo de alterações para as suas revisões de código.

Controlo 36: forneça provas de que os programadores são submetidos anualmente a uma formação segura de desenvolvimento de software.

• Intenção: existem melhores práticas e técnicas de codificação para todas as linguagens de programação para garantir que o código é desenvolvido de forma segura. Existem cursos de formação externos concebidos para ensinar aos programadores os diferentes tipos de classes de vulnerabilidades de software e as técnicas de codificação que podem ser utilizadas para parar a introdução destas vulnerabilidades no software. A intenção deste controlo é ensinar estas técnicas a todos os programadores e garantir que estas técnicas não são esquecidas ou que as técnicas mais recentes são aprendidas ao realizar isto anualmente.

• Diretrizes de Provas de Exemplo: forneça provas através de certificados se forem realizados por uma empresa de formação externa ou ao fornecer capturas de ecrã dos diários de formação ou de outros artefactos que demonstram que os programadores participaram na formação. Se esta formação for realizada através de recursos internos, forneça também provas do material de preparação.

• Exemplo de Prova: abaixo encontra-se o e-mail a pedir que a equipa do DevOps esteja inscrita na Formação Anual das Dez Principais Formações do OWASP

A documentação abaixo mostra que a formação foi pedida com justificação comercial e aprovação. Em seguida, segue-se capturas de ecrã tiradas da formação e um registo de conclusão que mostra que a pessoa terminou a formação anual.

Controlo 37: forneça provas de que os repositórios de código estão protegidos com a autenticação multifator (MFA).

• Intenção: se um grupo de atividades puder aceder e modificar a base de código de um software, pode introduzir vulnerabilidades, backdoors ou código malicioso na base de código e, portanto, na aplicação. Já houve vários casos disto, com provavelmente o mais divulgado a ser o ataque do Ransomware NotPetya, que alegadamente está infetado através de uma atualização comprometida do software fiscal ucraniano chamado M.E.Doc (veja O que não éPetya).

• Diretrizes de Provas de Exemplo: forneça provas através de capturas de ecrã do repositório de código que todos os utilizadores têm a MFA ativada.

• Exemplo de Evidência: a seguinte captura de ecrã mostra que a MFA está ativada em todos os 8 utilizadores do GitLab.

Controlo 38: forneça provas de que os controlos de acesso estão implementados para proteger os repositórios de código.

• Intenção: a partir do controlo anterior, os controlos de acesso devem ser implementados para limitar o acesso apenas a utilizadores individuais que estejam a trabalhar em projetos específicos. Ao limitar o acesso, está a limitar o risco de efetuar alterações não autorizadas e, assim, introduzir alterações de código inseguras. Deve ser tomada uma abordagem com menos privilégios para proteger o repositório de código.

• Diretrizes de Provas de Exemplo: forneça provas através de capturas de ecrã do repositório de código que o acesso está restrito a indivíduos necessários, incluindo privilégios diferentes.

• Exemplo de Prova: a seguinte captura de ecrã mostra os membros do projeto "Clientes" no GitLab, que é o "Portal do Cliente" da Contoso. Como pode ver na captura de ecrã, os utilizadores têm "Funções" diferentes para limitar o acesso ao projeto.

Gerenciamento de contas

As práticas de gestão de contas seguras são importantes, uma vez que as contas de utilizador constituem a base para permitir o acesso a sistemas de informação, ambientes de sistema e dados. As contas de utilizador têm de ser devidamente protegidas, uma vez que um compromisso das credenciais do utilizador pode fornecer não só um ponto de apoio no ambiente e acesso a dados confidenciais, mas também pode fornecer controlo administrativo sobre todo o ambiente ou sistemas chave se as credenciais do utilizador tiverem privilégios administrativos.

Controlo 39: forneça documentação de política que regule as práticas e procedimentos de gestão de contas.

• Intenção: as contas de utilizador continuam a ser alvo de grupos de atividades e, muitas vezes, serão a origem de um comprometimento de dados. Ao configurar contas excessivamente permissivas, as organizações não só aumentarão o conjunto de contas "privilegiadas" que podem ser utilizadas por um grupo de atividades para efetuar uma falha de segurança de dados, como também podem aumentar o risco de exploração bem-sucedida de uma vulnerabilidade que exigiria privilégios específicos para serem bem-sucedidas.

• A BeyondTrust produz anualmente um "Relatório de Vulnerabilidades da Microsoft" que analisa as vulnerabilidades de segurança da Microsoft relativamente ao ano anterior e detalha percentagens destas vulnerabilidades que dependem da conta de utilizador que tem direitos de administrador. Numa publicação de blogue recente "New Microsoft Vulnerabilities Report Reveals a 48% YoY Increase in Vulnerabilities & How They Could Be Mitigated with Least Privilege", 90% of Critical vulnerabilities in Internet Explorer, 85% of Critical vulnerabilities in Microsoft Edge and 100% of Critical vulnerabilities in Microsoft Outlook would have been mitigad by removeing admin vulnerabilities in Microsoft Edge and 100% of Critical vulnerabilities in Microsoft Outlook would have been mitigad by removeing admin vulnerabilities in Microsoft Edge. Para suportar a gestão segura de contas, as organizações precisam de garantir que as políticas de suporte e os procedimentos que promovem as melhores práticas de segurança estão implementados e seguidos para mitigar estas ameaças.

• Diretrizes de Provas de Exemplo: forneça as políticas documentadas e os documentos de procedimento que abrangem as práticas de gestão da conta. No mínimo, os tópicos abordados devem estar alinhados com os controlos na Certificação do Microsoft 365.

• Exemplo de Prova: a seguinte captura de ecrã mostra um exemplo de Política de Gestão de Contas para a Contoso.

Nota: Esta captura de ecrã mostra um documento de política/processo, a expetativa é que os ISVs partilhem a documentação de política/procedimento de suporte real e não apenas forneçam uma captura de ecrã.

Controlo 40: forneça provas de que as credenciais predefinidas estão desativadas, removidas ou alteradas nos componentes do sistema de exemplo.

• Intenção: embora isto esteja a tornar-se menos popular, ainda existem instâncias em que os grupos de atividade podem tirar partido das credenciais de utilizador predefinidas e bem documentadas para comprometer os componentes do sistema de produção. Um exemplo popular disto é com Dell iDRAC (Integrated Dell Remote Access Controller). Este sistema pode ser utilizado para gerir remotamente um Dell Server, que pode ser utilizado por um grupo de atividades para obter controlo sobre o sistema operativo do Servidor. A credencial predefinida de root::calvin está documentada e, muitas vezes, pode ser utilizada por grupos de atividades para obter acesso aos sistemas utilizados pelas organizações. A intenção deste controlo é garantir que estas credenciais predefinidas estão desativadas ou removidas

• Diretrizes de Evidência de Exemplo: existem várias formas de recolher provas para suportar este controlo. Capturas de ecrã de utilizadores configurados em todos os componentes do sistema podem ajudar, ou seja, capturas de ecrã dos ficheiros Linux /etc/shadow e /etc/passwd ajudarão a demonstrar se as contas foram desativadas. Tenha em atenção que o ficheiro /etc/shadow seria necessário para demonstrar que as contas estão verdadeiramente desativadas ao observar que o hash de palavra-passe começa com um caráter inválido, como '!' que indica que a palavra-passe é inutilizável. O conselho seria desativar apenas alguns carateres da palavra-passe e redigir o resto. Outras opções seriam para sessões de partilha de ecrã em que o avaliador conseguiu experimentar manualmente as credenciais predefinidas, por exemplo, no debate acima sobre Dell iDRAC, o avaliador tem de tentar autenticar-se em todas as interfaces iDRAC de Dell com as credenciais predefinidas.

• Exemplo de Prova: a seguinte captura de ecrã mostra as contas de utilizador configuradas para o componente de sistema no âmbito "CLARANET-SBU-WM". O mostra várias contas predefinidas; Administrador, DefaultAccount e Convidado, no entanto, as capturas de ecrã seguintes mostram que estas contas estão desativadas.

Esta captura de ecrã seguinte mostra que a conta de Administrador está desativada no componente de sistema no âmbito "CLARANET-SBU-WM".

Esta captura de ecrã seguinte mostra que a Conta de convidado está desativada no componente do sistema no âmbito "CLARANET-SBU-WM".

Esta captura de ecrã seguinte mostra que a DefaultAccount está desativada no componente do sistema no âmbito "CLARANET-SBU-WM".

Controlo 41: forneça provas de que a criação, modificação e eliminação da conta passam por um processo de aprovação estabelecido.

• Intenção: a intenção é ter um processo estabelecido para garantir que todas as atividades de gestão de contas são aprovadas, garantindo que os privilégios de conta mantêm os princípios de menor privilégio e que as atividades de gestão de contas podem ser devidamente revistas e controladas.

• Diretrizes de Provas de Exemplo: normalmente, as provas têm a forma de pedidos de pedidos de alteração, pedidos do ITSM (Gestão de Serviços de TI) ou documentação que mostra que os pedidos de criação, modificação ou eliminação de contas passaram por um processo de aprovação.

• Exemplo de Prova: as imagens abaixo mostram a criação de conta para um novo inicializador para a equipa do DevOps que tem de ter a definição de controlo de acesso baseado em funções com base nas permissões do ambiente de produção sem acesso ao ambiente de desenvolvimento e acesso padrão não privilegiado a tudo o resto.

A criação da conta passou pelo processo de aprovação e pelo processo de terminar sessão assim que a conta foi criada e o pedido de suporte fechado.

Controlo 42: forneça provas de que está em curso um processo para desativar ou eliminar contas não utilizadas no prazo de 3 meses.

• Intenção: por vezes, as contas inativas podem ficar comprometidas porque são alvo de ataques de força bruta que podem não ser sinalizados, uma vez que o utilizador não está a tentar iniciar sessão nas contas ou através de uma falha na base de dados de palavras-passe em que a palavra-passe de um utilizador foi reutilizada e está disponível numa captura de nome de utilizador/palavra-passe na Internet. As contas não utilizadas devem ser desativadas/removidas para reduzir a superfície de ataque que um grupo de atividade tem para realizar atividades de comprometimento de conta. Estas contas podem dever-se ao facto de um processo de abandono não estar a ser realizado corretamente, de um membro do pessoal que se depare com doença de longa duração ou de um membro do pessoal em licença de maternidade/paternidade. Ao implementar um processo trimestral para identificar estas contas, as organizações podem minimizar a superfície de ataque.

• Diretrizes de Provas de Exemplo: as provas devem ser duplas. Em primeiro lugar, uma captura de ecrã ou exportação de ficheiros a mostrar o "último início de sessão" de todas as contas de utilizador no ambiente no âmbito. Podem ser contas locais, bem como contas num serviço de diretório centralizado, como o ID do Microsoft Entra. Isto irá demonstrar que não existem contas com mais de 3 meses ativadas. Em segundo lugar, os elementos de prova do processo de revisão trimestral, que podem ser provas documentais da tarefa a ser concluída no ADO (Azure DevOps) ou em bilhetes JIRA, ou através de registos em papel que devem ser assinados.

• Exemplo de Prova: esta primeira captura de ecrã mostra o resultado do script que é executado trimestralmente para ver o último atributo de início de sessão para os utilizadores no ID do Microsoft Entra.

Como pode ver na captura de ecrã acima, dois utilizadores estão a mostrar como não têm sessão iniciada há algum tempo. As duas capturas de ecrã seguintes mostram que estes dois utilizadores estão desativados.

Controlo 43: forneça provas de que existe uma política de palavras-passe forte ou outras mitigações adequadas para proteger as credenciais do utilizador. O seguinte deve ser utilizado como uma orientação mínima:

• Comprimento mínimo da palavra-passe de 8 carateres

• Limiar de bloqueio de conta não superior a 10 tentativas

• Histórico de palavras-passe com um mínimo de 5 palavras-passe

• Imposição da utilização de palavra-passe segura

• Intenção: tal como já foi discutido, as credenciais do utilizador são frequentemente alvo de ataques por grupos de atividades que tentam obter acesso ao ambiente de uma organização. A intenção de uma política de palavras-passe forte é tentar forçar os utilizadores a escolher palavras-passe fortes para mitigar as hipóteses de os grupos de atividade serem capazes de os forçar de forma bruta. A intenção de adicionar "ou outras mitigações adequadas" é reconhecer que as organizações podem implementar outras medidas de segurança para ajudar a proteger as credenciais do utilizador com base em desenvolvimentos do setor, como "Publicação Especial NIST 800-63B".

• Exemplo de Diretrizes de Evidência: as provas para demonstrar uma política de palavras-passe fortes podem estar na forma de uma captura de ecrã de um Objeto de Política de Grupo de organizações ou das definições de Política de Segurança Local "Políticas de Conta à Política de Palavra-passe" e "Políticas de Conta à Política de Bloqueio de Conta". As provas dependem das tecnologias que estão a ser utilizadas; ou seja, para Linux, pode ser o ficheiro de configuração /etc/pam.d/common-password, para o BitBucket, a secção "Políticas de Autenticação" no Portal de Administração (https://support.atlassian.com/security-and-access-policies/docs/manage-your-password-policy/), etc.

• Exemplo de Prova: as provas abaixo mostram a política de palavra-passe configurada na "Política de Segurança Local" do componente de sistema no âmbito "CLARANET-SBU-WM".

A captura de ecrã abaixo mostra as definições de Bloqueio de Conta para uma Firewall do WatchGuard.

Segue-se um exemplo de um comprimento mínimo da frase de acesso para a Firewall WatchGaurd.

Controlo 44: forneça provas de que são emitidas contas de utilizador exclusivas a todos os utilizadores.

• Intenção: a intenção deste controlo é a responsabilidade. Ao emitir utilizadores com as suas próprias contas de utilizador exclusivas, os utilizadores serão responsáveis pelas suas ações, uma vez que a atividade do utilizador pode ser controlada por um utilizador individual.

• Exemplo de Diretrizes de Evidência: as provas seriam através de capturas de ecrã que mostram contas de utilizador configuradas nos componentes do sistema no âmbito, que podem incluir servidores, repositórios de código, plataformas de gestão da cloud, Active Directory, Firewalls, etc.

• Exemplo de Prova: a seguinte captura de ecrã mostra as contas de utilizador configuradas para o componente de sistema no âmbito "CLARANET-SBU-WM".

Esta captura de ecrã seguinte mostra que a conta de Administrador está desativada no componente de sistema no âmbito "CLARANET-SBU-WM".

Esta captura de ecrã seguinte mostra que a Conta de convidado está desativada no componente do sistema no âmbito "CLARANET-SBU-WM".

Esta captura de ecrã seguinte mostra que a DefaultAccount está desativada no componente do sistema no âmbito "CLARANET-SBU-WM".

Controlo 45: forneça provas de que os princípios de menor privilégio estão a ser seguidos no ambiente.

• Intenção: os utilizadores só devem receber os privilégios necessários para cumprir a função de trabalho. Isto é para limitar o risco de um utilizador aceder intencional ou não intencionalmente aos dados que não deve ou realizar um ato malicioso. Ao seguir este princípio, também reduz a potencial superfície de ataque (ou seja, contas com privilégios) que podem ser alvo de um grupo de atividades maliciosas.

• Diretrizes de Evidência de Exemplo: a maioria das organizações utilizará grupos para atribuir privilégios com base em equipas dentro da organização. As provas podem ser capturas de ecrã que mostram os vários grupos com privilégios e apenas as contas de utilizador das equipas que necessitam destes privilégios. Normalmente, seria criada uma cópia de segurança com políticas/processos de suporte que definem cada grupo definido com os privilégios necessários e justificação comercial e uma hierarquia de membros da equipa para validar que a associação ao grupo está configurada corretamente.

• Por exemplo: no Azure, o grupo Proprietários deve ser limitado, pelo que deve ser documentado e deve ter um número limitado de pessoas atribuídas a esse grupo. Outro exemplo pode ser um número limitado de funcionários com a capacidade de fazer alterações de código, um grupo pode ser configurado com este privilégio com os membros da equipa considerados como estando a precisar desta permissão configurada. Isto deve ser documentado para que o analista de certificação possa fazer referência cruzada ao documento com os grupos configurados, etc.

• Exemplo de Evidência: a seguinte captura de ecrã mostra que o ambiente está configurado com grupos atribuídos de acordo com a função de tarefa.

A captura de ecrã seguinte mostra que os utilizadores são alocados a grupos com base na respetiva função de tarefa.

Controlo 46: forneça provas de que está em curso um processo para proteger ou proteger as contas de serviço e que o processo está a ser seguido.

• Intenção: muitas vezes, as contas de serviço serão direcionadas por grupos de atividades, uma vez que são muitas vezes configuradas com privilégios elevados. Estas contas podem não seguir as políticas padrão de palavra-passe porque a expiração das palavras-passe da conta de serviço muitas vezes interrompe a funcionalidade. Por conseguinte, podem ser configuradas com palavras-passe fracas ou palavras-passe reutilizadas na organização. Outro problema potencial, particularmente num ambiente windows, pode ser o facto de o sistema operativo colocar em cache o hash de palavra-passe. Isto pode ser um grande problema se: a conta de serviço estiver configurada num serviço de diretório, uma vez que esta conta pode ser utilizada para aceder a vários sistemas com o nível de privilégios configurado ou a conta de serviço é local, a probabilidade é que a mesma conta/palavra-passe seja utilizada em vários sistemas no ambiente. Os problemas acima podem levar a que um grupo de atividade obtenha acesso a mais sistemas dentro do ambiente e pode levar a uma elevação adicional de privilégios e/ou movimento lateral. Por conseguinte, a intenção é garantir que as contas de serviço estão devidamente protegidas e protegidas para ajudar a protegê-las de serem assumidas por um grupo de atividade ou ao limitar o risco caso uma destas contas de serviço seja comprometida.

• Exemplo de Diretrizes de Evidência: existem muitos guias na Internet para ajudar a proteger as contas de serviço. As provas podem ser sob a forma de capturas de ecrã que demonstram como a organização implementou a proteção segura da conta. Alguns exemplos (a expectativa é que sejam utilizadas múltiplas técnicas) inclui:

• Restringir as contas a um conjunto de computadores no Active Directory,

• Definir a conta para que o início de sessão interativo não seja permitido,

• Definir uma palavra-passe extremamente complexa,

• Para o Active Directory, ative o sinalizador "A conta é confidencial e não pode ser delegada". Estas técnicas são abordadas no seguinte artigo "Segmentação e Active Directory Partilhado para um Ambiente de Dados de Titular de Cartões".

• Exemplo de Provas: existem várias formas de proteger uma conta de serviço, que dependerão de cada ambiente individual. Os mecanismos adequados para o seu ambiente, que são utilizados, seriam documentados no documento de política/procedimento da Gestão de Contas anteriormente, o que ajudará a rever estas provas. Seguem-se alguns dos mecanismos que podem ser utilizados:

A seguinte captura de ecrã mostra a opção "A conta é confidencial e ligar-se a ser delegada" está selecionada na conta de serviço "_Prod Conta de Serviço do SQL".

Esta captura de ecrã seguinte mostra que a conta de serviço "_Prod Conta de Serviço do SQL" está bloqueada no SQL Server e só pode iniciar sessão nesse servidor.

Esta captura de ecrã seguinte mostra que a conta de serviço "_Prod Conta de Serviço SQL" só tem permissão para iniciar sessão como um serviço.

Controlo 47: forneça provas de que a MFA está configurada para todas as ligações de acesso remoto e todas as interfaces administrativas não consola.

Termos definidos como:

• Acesso Remoto – normalmente, refere-se às tecnologias utilizadas para aceder ao ambiente de suporte. Por exemplo, VPN IPSec de Acesso Remoto, VPN SSL ou Jumpbox/Anfitrião Bastian.

• Interfaces Administrativas não consola – normalmente, isto refere-se às ligações administrativas de rede aos componentes do sistema. Isto pode ser através do Ambiente de Trabalho Remoto, SSH ou de uma interface Web.

• Intenção: a intenção deste controlo é fornecer mitigações contra contas privilegiadas de força bruta e contas com acesso seguro ao ambiente. Ao fornecer a autenticação multifator (MFA), uma palavra-passe comprometida ainda deve ser protegida contra um início de sessão com êxito, uma vez que o mecanismo MFA ainda deve ser protegido. Isto ajuda a garantir que todas as ações administrativas e de acesso são realizadas apenas por docentes autorizados e fidedignos.

• Diretrizes de Evidência de Exemplo: as provas têm de mostrar que a MFA está ativada em todas as tecnologias que se enquadram nas categorias acima. Isto pode ser através de uma captura de ecrã que mostra que a MFA está ativada ao nível do sistema. Ao nível do sistema, precisamos de provas de que está ativada para todos os utilizadores e não apenas um exemplo de uma conta com a MFA ativada. Quando a tecnologia é recuada para uma solução de MFA, precisamos das provas para demonstrar que está ativada e em utilização. O que significa isto é; em que a tecnologia está configurada para a Autenticação Radius, que aponta para um fornecedor de MFA, também tem de evidenciar que o Servidor Radius para o qual está a apontar é uma solução de MFA e que as contas estão configuradas para utilizá-lo.

• Exemplo de Prova 1: as seguintes capturas de ecrã mostram os realms de autenticação configurados no Pulse Secure, que é utilizado para o acesso remoto ao ambiente. A autenticação é suportada pelo Serviço SaaS Duo para Suporte da MFA.

Esta captura de ecrã demonstra que está ativado um servidor de autenticação adicional que está a apontar para "Duo-LDAP" para o realm de autenticação "Duo - Rota Predefinida".

Esta captura de ecrã final mostra a configuração do servidor de autenticação Duo-LDAP, que demonstra que está a apontar para o serviço Duo SaaS para MFA.

Exemplo de Prova 2: as capturas de ecrã seguintes mostram que todos os utilizadores do Azure têm a MFA ativada.

Nota: terá de fornecer provas de todas as ligações não consola para demonstrar que a MFA está ativada para as mesmas. Por exemplo, se fizer RDP ou SSH para servidores ou outros componentes do sistema (ou seja, Firewalls).

Controlo 48: forneça provas de que a encriptação forte está configurada para todas as ligações de acesso remoto e todas as interfaces administrativas não consola, incluindo o acesso a repositórios de código e interfaces de gestão da cloud.

Termos definidos como:

• Repositórios de Código – a base de código da aplicação tem de ser protegida contra modificações maliciosas que possam introduzir software maligno na aplicação. A MFA tem de ser configurada no repositório de código.

• Interfaces de Gestão da Cloud – onde alguns ou todos os ambientes estão alojados no Fornecedor de Serviços Cloud (CSP), a interface administrativa para a gestão da cloud está incluída aqui.

• Intenção: a intenção deste controlo é garantir que todo o tráfego administrativo é devidamente encriptado para proteger contra ataques man-in-the-middle.

• Exemplo de Diretrizes de Evidência: as provas podem ser fornecidas por capturas de ecrã que mostram as definições de encriptação para tecnologias de acesso remoto, interfaces RDP, SSH e Administrador Web. Para interfaces de Administração Web, pode ser utilizado o scanner qualys SSL Labs (se acessível publicamente, ou seja, interfaces de gestão da cloud, repositórios de código SaaS ou ligações VPN SSL).

• Exemplo de Evidência: a evidência abaixo mostra o nível de encriptação RDP em "Webserver01" a ser configurado com uma definição de "Nível Elevado". Como mostra o texto de ajuda, está a utilizar uma encriptação forte de 128 bits (que é o nível mais alto para o RdP do Microsoft Windows.

As provas abaixo também mostram que a segurança de transporte RDP está configurada para utilizar o TLS 1.0 no "Webserver01" (que é o mais alto para o Windows Server).

Controlo 49: forneça provas de que a MFA é utilizada para proteger o portal de administração que utiliza para gerir e manter todos os registos DNS (public domain name service).

• Intenção: se um grupo de atividades maliciosas conseguir obter acesso aos registos DNS Públicos, existe o risco de poderem modificar os URLs utilizados pela aplicação ou onde o ficheiro de manifesto está a apontar para introduzir código malicioso ou para direcionar o tráfego do utilizador para um ponto final sob o controlo de atores. Tal pode resultar na perda de dados do utilizador ou em infeções por malware/ransomware na base de utilizadores da aplicação.

• Exemplo de Diretrizes de Provas: forneça provas que demonstrem que os portais administrativos do DNS Público estão protegidos pela MFA. Mesmo que o DNS Público esteja alojado em servidores dentro do ambiente no âmbito (ou seja, controle e seja operado pela organização), ainda poderá existir um Portal de Administração onde o Nome de Domínio foi registado e os Registos DNS foram "Geridos" para apontar os Servidores DNS para a sua própria infraestrutura. Quando for este o caso, a MFA deve ser ativada na interface administrativa da entidade de registo de domínios se os registos DNS dos domínios puderem ser modificados. Deve ser fornecida uma captura de ecrã a mostrar que a interface administrativa está ativada para a MFA ao nível do sistema (ou seja, todas as contas com privilégios).

• Exemplo de Prova: a seguinte captura de ecrã mostra o contoso.com DNS é gerido no Microsoft Azure para Contoso Corporation.

Nota: Os endereços IP são endereços RFC 1918 privados e não são encaminhados publicamente. Isto é apenas para fins de demonstração.

As capturas de ecrã seguintes mostram que todos os utilizadores do Azure têm a MFA ativada.

Deteção e Prevenção de Intrusões (opcional)

Os Sistemas de Deteção e Prevenção de Intrusões (IDPS) no gateway podem fornecer uma camada adicional de proteção contra uma miríade de ameaças internas e baseadas na Internet. Estes sistemas podem ajudar a evitar que estas ameaças sejam bem-sucedidas e podem fornecer capacidades de alerta cruciais para alertar as organizações para tentativas de compromisso em direto para permitir que as organizações implementem estratégias defensivas adicionais para proteger ainda mais o ambiente contra estas ameaças ativas.

Esta secção destina-se a crédito adicional e, por conseguinte, é opcional. Não é um requisito. No entanto, se o concluir, a sua avaliação mostrará uma imagem mais completa do seu ambiente e dos controlos e padrões que implementou.

Controlo 50: forneça provas de que os Sistemas de Deteção e Prevenção de Intrusões (IDPS) estão implementados no perímetro dos ambientes no âmbito.

• Intenção: Embora algumas fontes descrevam ameaças internas como estando agora a ultrapassar ameaças por grupos de atividades externas, as ameaças internas também incluem negligência, com o erro humano a aumentar em percentagem ano após ano. A intenção de instalar o IDPS no perímetro dos ambientes no âmbito é que muitas vezes as ameaças externas podem ser detetadas através de mecanismos IDPS devido à natureza e técnicas utilizadas por estes tipos de ameaças.

• Diretrizes de Evidência de Exemplo: devem ser fornecidas provas que demonstrem que o IDPS está instalado no perímetro, que pode estar diretamente na Firewall se executar uma Firewall nextGen ou se puder ser através de Sensores IDPS de implementação que estão configurados nas portas de comutador espelhado para garantir que todo o tráfego é visto pelos sensores implementados. Se os Sensores IDPS estiverem a ser utilizados, poderão ser fornecidas provas adicionais para demonstrar que os sensores são capazes de ver todos os fluxos de tráfego externos.

• Exemplo de Prova: a captura de ecrã abaixo mostra que a funcionalidade IDPS está ativada na Firewall do WatchGuard.

A captura de ecrã adicional abaixo demonstra que o IDPS está ativado em todas as regras na configuração da Firewall do WatchGuard.

Controlo 51: forneça provas de que as assinaturas IDPS são mantidas atualizadas (no prazo de 24 horas).

• Intenção: existem vários modos de operação para iDPS, o mais comum é utilizar assinaturas para identificar o tráfego de ataque. À medida que os ataques evoluem e as vulnerabilidades mais recentes são identificadas, é importante que as assinaturas IDPS estejam atualizadas para fornecer proteção adequada. A intenção deste controlo é garantir que o IDPS está a ser mantido.

• Diretrizes de Provas de Exemplo: é provável que as provas estejam com uma captura de ecrã a mostrar que o IDPS está configurado para atualizar assinaturas pelo menos diariamente e a mostrar a última atualização.

• Exemplo de Provas: embora esta captura de ecrã não mostre que as assinaturas IDPS foram atualizadas nas últimas 24 horas, demonstra que a versão mais recente está instalada, que foi de há uma semana (Provas recolhidas no 18__thmaio). Isto, combinado com a captura de ecrã que se segue, mostra que as assinaturas estarão atualizadas num período de 24 horas.

Controlo 52: forneça provas de que o IDPS está configurado para suportar a inspeção TLS de todo o tráfego Web recebido.

• Intenção: uma vez que o IDPS depende de assinaturas, tem de conseguir inspecionar todos os fluxos de tráfego para identificar o tráfego de ataque. O tráfego TLS é encriptado e, por conseguinte, o IDPS não conseguirá inspecionar corretamente o tráfego. Isto é fundamental para o tráfego HTTPS, uma vez que existem inúmeras ameaças comuns aos serviços Web. A intenção deste controlo é garantir que os fluxos de tráfego encriptados também podem ser inspecionados para IDPS.

• Exemplo de Diretrizes de Evidência: as provas devem ser fornecidas através de capturas de ecrã, demonstrando que o tráfego TLS encriptado também está a ser inspecionado pela solução IDPS.

• Exemplo de Evidência: esta captura de ecrã mostra as regras HTTPS na Firewall

Esta captura de ecrã seguinte mostra que o IDPS está ativado nestas regras.

A captura de ecrã seguinte mostra que uma "Ação de Proxy" é aplicada à regra "Inbound_Bot_Traffic", que é utilizada para ativar a inspeção de conteúdo.

A seguinte captura de ecrã mostra que a inspeção de conteúdo está ativada.

Controlo 53: forneça provas de que o IDPS está configurado para monitorizar todos os fluxos de tráfego de entrada.

• Intenção: tal como já foi discutido, é importante que todos os fluxos de tráfego de entrada sejam monitorizados pelo IDPS para identificar qualquer forma de tráfego de ataque.

• Diretrizes de Evidência de Exemplo: devem ser fornecidas provas através de capturas de ecrã para demonstrar que todos os fluxos de tráfego de entrada são monitorizados. Isto pode estar a utilizar a firewall nextGen, a mostrar que todas as regras de entrada estão ativadas para IDPS ou pode ser através da utilização de Sensores IDPS e demonstração de que todo o tráfego está configurado para chegar ao Sensor IDPS.

• Exemplo de Prova: esta captura de ecrã mostra que o IDPS está configurado em todas as regras (políticas) da Firewall do WatchGuard.

Controlo 54: forneça provas de que o IDPS está configurado para monitorizar todos os fluxos de tráfego de saída.

• Intenção: tal como já foi discutido, é importante que todos os fluxos de tráfego de saída sejam monitorizados pelo IDPS para identificar qualquer forma de tráfego de ataque. Alguns sistemas IDPS também podem identificar potenciais falhas internas ao monitorizar todo o tráfego de saída. Isto pode ser feito ao identificar o tráfego destinado aos pontos finais "Comando e Controlo".

• Diretrizes de Provas de Exemplo: devem ser fornecidas provas através de capturas de ecrã para demonstrar que todos os fluxos de tráfego de saída são monitorizados. Isto pode estar a utilizar a firewall nextGen, a mostrar que todas as regras de saída estão ativadas para IDPS ou pode ser através da utilização de Sensores IDPS e demonstração de que todo o tráfego está configurado para chegar ao Sensor IDPS.

• Exemplo de Prova: esta captura de ecrã mostra que o IDPS está configurado em todas as regras (políticas) da Firewall do WatchGuard.

• Exemplo de Prova 2: o Azure oferece o IDPS através de aplicações de terceiros. No exemplo abaixo, a captura de pacotes do Netwatcher foi utilizada para capturar pacotes e utilizada juntamente com o Suricata, que é uma ferramenta Open-Source IDS.

Ao combinar a captura de pacotes fornecida pelo Observador de Rede e ferramentas de IDS open source, como o Suricata, pode efetuar a deteção de intrusões de rede para uma vasta gama de ameaças. A imagem abaixo mostra a interface Suricata.

As assinaturas são utilizadas para acionar alertas e estas podem ser instaladas e atualizadas facilmente. A imagem abaixo mostra um instantâneo de algumas assinaturas.

A imagem abaixo mostra como monitorizaria a configuração do IDPS do Software de terceiros netwatcher e Suricata com o SENTINEL SIEM/SOAR.

• Exemplo de Prova 3: a imagem abaixo mostra como adicionar uma assinatura de intrusão de substituição ou uma regra de desativação para deteção de intrusões com a CLI

A imagem abaixo mostra como listar todas as configurações de deteção de intrusões com a CLI

• Exemplo de Prova 4: o Azure começou recentemente a oferecer um IDPS com o nome Azure Firewall Premium, que permitirá a configuração de TLS, Informações sobre Ameaças, IDPS através de políticas. No entanto, tenha em atenção que ainda terá de utilizar o Front Door ou o gateway de aplicação para a descarga de tráfego de entrada por SSL, uma vez que o Azure Firewall Premium não suporta IDPS em ligações SSL de entrada.

No exemplo abaixo, as predefinições premium foram utilizadas para configurar regras de política e inspeção TLS, modo IDPS, as Informações sobre Ameaças foram todas ativadas juntamente com a proteção da Vnet.

Registo de Eventos de Segurança

O registo de eventos de segurança é parte integrante do programa de segurança de uma organização. O registo adequado de eventos de segurança associados a alertas ajustados e processos de revisão ajuda as organizações a identificar falhas ou tentativas de violação que podem ser utilizadas pela organização para melhorar estratégias de segurança defensivas e de segurança. Além disso, o registo adequado será fundamental para uma capacidade de resposta a incidentes de organizações que pode alimentar outras atividades, tais como ser capaz de identificar com precisão o que e quem os dados foram comprometidos, o período de comprometimento, fornecer relatórios de análise detalhados a agências governamentais, etc.

Controlo 55: forneça documentação de política para melhores práticas e procedimentos que regem o registo de eventos de segurança.

• Intenção: o registo de eventos de segurança é uma função importante do programa de segurança de qualquer organização. As políticas e procedimentos têm de estar em vigor para fornecer clareza e consistência para ajudar as organizações a implementar controlos de registo de acordo com as práticas recomendadas pelo fornecedor e pela indústria. Isto ajudará a garantir que os registos relevantes e detalhados são consumidos, que não são apenas úteis na identificação de eventos de segurança potenciais ou reais, mas também podem ajudar uma atividade de resposta a incidentes a identificar a extensão de uma falha de segurança.

• Diretrizes de Evidência de Exemplo: forneça às organizações documentos de política e procedimento documentados que abrangem as melhores práticas de registo de eventos de segurança.

• Exemplo de Prova: abaixo encontra-se um extrato da política/procedimento de registo.

Nota: Esta captura de ecrã mostra um documento de política/processo, a expetativa é que os ISVs partilhem a documentação de política/procedimento de suporte real e não apenas forneçam uma captura de ecrã.

Controlo 56: forneça provas detetáveis que mostram que o registo de eventos de segurança está configurado em todos os componentes do sistema de exemplo para registar os seguintes eventos:

• Acesso do utilizador aos componentes do sistema e à aplicação

• Todas as ações realizadas por um utilizador com privilégios elevados

• Tentativas de acesso lógico inválidas

• Criação ou modificação de conta privilegiada

• Adulteração do registo de eventos

• Desativar ferramentas de segurança, como antimalware ou registo de eventos

• Registo antimalware, como atualizações, deteção de software maligno e falhas de análise

• Eventos de IDPS e WAF, se configurados

• Intenção: para identificar falhas tentadas e reais, é importante que estejam a ser recolhidos registos de eventos de segurança adequados por todos os sistemas que constituem o ambiente. A intenção deste controlo é garantir que os tipos corretos de eventos de segurança estão a ser capturados, que podem, em seguida, alimentar os processos de revisão e alerta para ajudar a identificar e responder a estes eventos.

• Diretrizes de Evidência de Exemplo: as provas através de capturas de ecrã ou definições de configuração devem ser fornecidas em todos os dispositivos de exemplo e quaisquer componentes de sistema relevantes para demonstrar como o registo é configurado para garantir que estes tipos de eventos de segurança são capturados.

• Exemplo de Prova 1: a seguinte captura de ecrã mostra as definições de configuração de um dos dispositivos de exemplo denominados "VICTIM1-WINDOWS". As definições mostram várias definições de auditoria ativadas nas definições "Política de Segurança Local  Políticas Locais  Política de Auditoria".

Esta captura de ecrã seguinte mostra um evento em que um utilizador limpou um registo de eventos de um dos dispositivos de amostra denominado "VICTIM1-WINDOWS".

Esta captura de ecrã final mostra a mensagem de registo apresentada na solução de registo centralizada.

Nota: são necessárias capturas de ecrã em todos os componentes do sistema de exemplo ETÊM de evidenciar todos os eventos de segurança detalhados acima.

Controlo 57: Forneça provas de que os eventos de segurança registados contêm as seguintes informações mínimas:

• Usuário

• Tipo de evento

• Data e hora

• Indicadores de êxito ou falha

• Etiqueta que identifica o sistema afetado

• Intenção: os eventos de segurança registados têm de fornecer informações suficientes para ajudar a determinar se o tráfego de ataque foi bem-sucedido, que informações foram acedidas, a que nível, quem foi o responsável, de onde teve origem, etc.

• Exemplo de Diretrizes de Evidência: as provas devem mostrar exemplos de registos de todos os componentes do sistema que mostram estes tipos de eventos de segurança. Os registos devem incluir todas as informações listadas acima.

• Exemplo de Prova: a seguinte captura de ecrã mostra as informações dos eventos de segurança no Visualizador de Eventos do Windows do componente de sistema no âmbito "SEGSVR02".

Nota: são necessárias capturas de ecrã em todos os componentes do sistema de exemplo E TÊM de evidenciar todos os eventos de segurança detalhados no controlo acima. É provável que as provas recolhidas para o controlo acima também satisfaçam este controlo, fornecendo detalhes adequados das informações de registo fornecidas.

Controlo 58: forneça provas de que todos os componentes de sistema de exemplo são sincronizados com o tempo para os mesmos servidores primários e secundários.

• Intenção: um componente crítico do registo é garantir que os registos em todos os sistemas têm relógios do sistema que estão todos sincronizados. Isto é importante quando é necessária uma investigação para controlar um compromisso e/ou violação de dados. Controlar os eventos através de vários sistemas pode tornar-se quase impossível se os registos tiverem diferentes graus de carimbos de data/hora, uma vez que podem ser perdidos registos importantes e será difícil de controlar.

• Diretrizes de Evidência de Exemplo: idealmente, deve ser mantida uma topologia de sincronização de hora que mostra como o tempo é sincronizado em todo o património. Em seguida, as provas podem ser fornecidas através de capturas de ecrã das definições de sincronização de tempo nos componentes do sistema de exemplo. Isto deve mostrar que toda a sincronização de tempo é para o mesmo servidor primário (ou se no local secundário).

• Exemplo de Evidência: este diagrama mostra a topologia de sincronização de hora em utilização.

A captura de ecrã seguinte mostra o WatchGuard configurado como um Servidor NTP e a apontar para time.windows.com como a origem da hora.

Esta captura de ecrã final mostra o componente do sistema no âmbito, "CLARANET-SBU-WM" está configurado para o NTP apontar para o servidor primário que é a Firewall do WatchGuard (10.0.1.1).

Controlo 59: forneça provas detetáveis quando os sistemas destinados ao público estão a ser utilizados de que os registos de eventos de segurança estão a ser enviados para uma solução de registo centralizada que não está dentro da rede de perímetro.

• Intenção: a intenção com este controlo é garantir uma separação lógica ou física entre o DMZ e o ponto final de registo. Com a rede de perímetro voltada para o público, esta situação é exposta a grupos de atividades externas e, portanto, está em maior risco do que outros componentes no ambiente. Se um componente DMZ for comprometido, a integridade dos dados de registo tem de ser mantida para impedir não só o grupo de atividade de adulterar os registos para ocultar o compromisso, mas também para ajudar em qualquer trabalho de investigação forense que possa ser necessário. Ao iniciar sessão em sistemas fora da rede de perímetro, os controlos de segurança utilizados para restringir o tráfego da rede de perímetro para estes sistemas de segurança devem ajudar a protegê-los contra atividades maliciosas e tentativas de adulteração.

• Diretrizes de Provas de Exemplo: as provas devem ser fornecidas com capturas de ecrã ou definições de configuração, que demonstram que os registos estão configurados para serem enviados imediatamente (ou perto de imediatamente) para uma solução de registo centralizada que esteja fora do DMZ. Estamos à procura de envio quase imediato de registos porque quanto mais tempo os registos forem enviados para a solução de registo centralizado, mais tempo um ator de tratamento teria de adulterar os registos locais antes de o envio ocorrer.

• Exemplo de Prova: os sistemas DMZ da Contoso utilizam o NXLog para envio de ficheiros de registo. A seguinte captura de ecrã mostra o serviço "nxlog" em execução na jumpbox DMZ "DESKTOP-7S65PN", que é utilizada para gerir todos os servidores DMZ.

A seguinte captura de ecrã mostra um extrato do ficheiro nxlog.conf, que mostra que o destino é um recoletor de registos interno na Sub-rede da Aplicação em 10.0.1.250, que é utilizado para enviar para AlienVault.

O seguinte URL para NXLog (https://nxlog.co/documentation/nxlog-user-guide/modes.html) mostra que o envio de registos está em tempo real através do seguinte extrato:

Controlo 60: forneça provas demonstráveis para mostrar que a solução de registo centralizada está protegida contra adulteração não autorizada de dados de registo.

• Intenção: embora a separação lógica/física esteja frequentemente em vigor entre os dispositivos de registo e a solução de registo centralizada, continua a existir o risco de alguém tentar adulterar os registos para ocultar as suas atividades. O objetivo deste controlo é garantir que existem mecanismos de autorização adequados para limitar o número de utilizadores que podem realizar ações administrativas na solução de registo centralizada.

• Exemplo de Diretrizes de Evidência: normalmente, as provas seriam com capturas de ecrã que mostravam a configuração de autorização e autenticação da solução de registo centralizada, demonstrando que os utilizadores estão limitados aos que são necessários para a função/função da tarefa.

• Exemplo de Prova: o SOC externo da Contoso utiliza AlienVault como ferramentas SIEM centralizadas. AlienVault foi comprado pela AT&T em 2018 e agora passa pela USM Anywhere. A página Web seguinte (https://cybersecurity.att.com/documentation/usm-anywhere/deployment-guide/admin/usm-anywhere-data-security.htm) aborda como o USM Anywhere protege os dados contra adulteração não autorizada. A seguinte ligação (https://cybersecurity.att.com/documentation/usm-appliance/raw-logs/raw-log-management.htm) realça como o produto USM Anywhere também garante a integridade dos registos arquivados.

Nota: Se o SIEM for interno, terão de ser fornecidas provas para demonstrar que o acesso aos dados de registo está restringido a um número selecionado de utilizadores com base na necessidade de trabalho e que a própria plataforma está protegida contra adulteração (a maioria das soluções irá criar isto na funcionalidade da solução de registo).

Controlo 61: forneça provas demonstráveis de que um mínimo de 30 dias de dados de registo de eventos de segurança está imediatamente disponível, com 90 dias de registos de eventos de segurança retidos.

• Intenção: por vezes, existe uma diferença de tempo entre um evento de compromisso ou segurança e uma organização que o identifica. A intenção deste controlo é garantir que a organização tem acesso a dados históricos de eventos para ajudar na resposta ao incidente e em qualquer trabalho de investigação forense que possa ser necessário.

• Diretrizes de Provas de Exemplo: normalmente, as provas mostram as definições de configuração da solução de registo centralizada a mostrar durante quanto tempo os dados são mantidos. 30 dias de dados de registo de eventos de segurança têm de estar imediatamente disponíveis na solução. No entanto, quando os dados são arquivados, esta necessidade de demonstrar que o valor de 90 dias está disponível. Tal pode dever-se à apresentação de pastas de arquivo com datas de dados exportados.

• Exemplo de Prova 1: as capturas de ecrã seguintes mostram que estão disponíveis registos no valor de 30 dias no AlienVault.

Nota: uma vez que se trata de um documento destinado ao público, o número de série da firewall foi redigido. No entanto, não prevemos que os ISVs suportem quaisquer capturas de ecrã redigidas, a menos que contenha Informações Pessoais Identificáveis.

Esta captura de ecrã seguinte mostra que os registos estão disponíveis ao mostrar um extrato de registo que remonta há 5 meses.

Nota: uma vez que se trata de um documento destinado ao público, os Endereços IP Públicos foram redigidos. No entanto, não prevemos que os ISVs suportem quaisquer capturas de ecrã redigidas, a menos que contenham Informações Pessoais Identificáveis.

• Exemplo de Prova 2: a seguinte captura de ecrã mostra que os eventos de registo são mantidos durante 30 dias disponíveis em direto e 90 dias no armazenamento a frio no Azure.

Revisão do Registo de Eventos de Segurança

Rever os registos de segurança é uma função importante para ajudar as organizações a identificar eventos de segurança que podem indicar uma falha de segurança ou atividades de reconhecimento que podem ser uma indicação de algo que está para vir. Isto pode ser feito diariamente através de um processo manual ou através de uma solução SIEM (Gestão de Informações de Segurança e Eventos), que ajuda através da análise de registos de auditoria, à procura de correlações e anomalias que podem ser sinalizadas para uma inspeção manual.

Controlo 62: forneça documentação de política que regule as práticas e procedimentos de revisão de registos.

• Intenção: Um relatório da IBM intitulado "Custo de uma violação de dados Relatório 2020" destaca que o tempo médio de identificação e contenção de uma violação de dados pode demorar 280 dias, isto é maior quando a violação é realizada por um grupo de atividade maliciosa que é reportado como 315days. Com o custo médio de uma falha de segurança de dados em milhões de dólares, é fundamental que este ciclo de vida de violação de dados seja reduzido não só para minimizar a janela de exposição aos dados, mas também para reduzir o período de tempo que um grupo de atividade tem para exfiltrar dados do ambiente. Ao reduzir esta janela, as organizações podem reduzir o custo global de uma falha de segurança de dados.

• Ao implementar um processo robusto de revisão e alerta, as organizações estão mais bem equipadas para identificar as violações mais cedo no ciclo de vida da violação de dados para minimizar o seu impacto na organização. Além disso, um processo forte pode ajudar a identificar tentativas de violação, permitindo que as organizações reforcem os mecanismos defensivos de segurança para mitigar esta ameaça aumentada para reduzir ainda mais as hipóteses de um compromisso pela campanha de ataque.

• Diretrizes de Provas de Exemplo: forneça às organizações documentos de política e procedimento documentados que abrangem as melhores práticas de revisão de registos.

• Exemplo de Prova: abaixo encontra-se um extrato da política/procedimento de revisão de registos.

Nota: Esta captura de ecrã mostra um documento de política/processo, a expetativa é que os ISVs partilhem a documentação de política/procedimento de suporte real e não apenas forneçam uma captura de ecrã.

Controlo 63: forneça provas demonstráveis de que os registos são revistos diariamente por uma ferramenta humana ou automatizada para identificar potenciais eventos de segurança.

• Intenção: a intenção deste controlo é garantir que as revisões diárias de registos estão a ser realizadas. Isto é importante para identificar quaisquer anomalias que possam não ser detetas pelos scripts/consultas de alerta que estão configurados para fornecer alertas de eventos de segurança.

• Diretrizes de Provas de Exemplo: normalmente, as provas seriam fornecidas por captura de ecrã ou partilha de ecrã, o que demonstra que as revisões de registos estão a ser realizadas. Isto pode ser através de formulários que são preenchidos todos os dias, ou através de um pedido de suporte JIRA ou DevOps com comentários relevantes publicados para mostrar que é realizado diariamente. Por exemplo, pode ser criado um pedido de suporte de JIRA semanal "Revisão diária do Registo W/C 26 de junho de 2021", todos os dias em que alguém publica os resultados da revisão diária do registo. Se forem sinalizadas anomalias, isto pode ser documentado neste mesmo pedido para demonstrar o controlo seguinte num único JIRA.

• Se as ferramentas automatizadas estiverem a ser utilizadas, podem ser fornecidas provas de captura de ecrã para demonstrar a automatização configurada e para fornecer provas adicionais para mostrar que a automatização está em execução e alguém está a rever o resultado automatizado.

• Exemplo de Evidência: a Contoso utiliza um fornecedor SOC de terceiros, Claranet Cyber Security, para correlação de registos e revisões. O AlienVault é utilizado pelo fornecedor SOC, que tem as capacidades de fornecer análises de registo automatizadas para registos anómalos e eventos em cadeia que podem destacar um potencial evento de segurança. As três capturas de ecrã seguintes mostram regras de correlação no AlienVault.

Esta primeira captura de ecrã identifica onde um utilizador foi adicionado ao grupo "Admins de Domínio".

Esta captura de ecrã seguinte identifica onde várias tentativas de início de sessão falhadas são seguidas por um início de sessão bem-sucedido que pode realçar um ataque de força bruta bem-sucedido.

Esta captura de ecrã final identifica onde ocorreu uma alteração da política de palavra-passe ao definir a política, para que as palavras-passe da conta não expirem.

Esta captura de ecrã seguinte mostra que um pedido de suporte é gerado automaticamente na ferramenta ServiceNow do SOC, acionando a regra acima.

Controlo 64: forneça provas demonstrativas de que potenciais anomalias e eventos de segurança são investigados e remediados.

• Intenção: a intenção é que todas as anomalias identificadas durante o processo diário de revisão de registos sejam investigadas e seja executada a remediação ou ação adequadas. Normalmente, isto envolverá um processo de triagem para identificar se as anomalias requerem ação e, em seguida, poderá ter de invocar o processo de resposta a incidentes.

• Diretrizes de Evidência de Exemplo: as provas devem ser fornecidas com uma captura de ecrã que demonstra que as anomalias identificadas como parte da revisão diária de registos são seguidas. Como já foi abordado acima, isto pode ser através de bilhetes JIRA que mostram uma anomalia a ser sinalizada e, em seguida, detalhando que actividades foram realizadas posteriormente. Isto pode levar à criação de um pedido de suporte JIRA específico para controlar todas as atividades que estão a ser realizadas ou apenas pode ser documentado no pedido de revisão de registo diário. Se for necessária uma ação de resposta a incidentes, esta ação deve ser documentada como parte do processo de resposta a incidentes e devem ser fornecidas provas para o demonstrar.

• Exemplo de Prova: o exemplo de captura de ecrã seguinte mostra um alerta de segurança a ser monitorizado no ServiceNow pelo SOC claranet Cyber Security MDR (Managed Detection and Response).

Esta captura de ecrã seguinte mostra a confirmação de que esta situação foi resolvida por David Ashton @ Contoso através de uma atualização no portal de cliente do ServiceNow.

Alertas de Eventos de Segurança

Os eventos de segurança críticos têm de ser imediatamente investigados para minimizar o impacto nos dados e no ambiente operacional. Os alertas ajudam a destacar imediatamente potenciais falhas de segurança para os funcionários para garantir uma resposta atempadamente para que a organização possa conter o evento de segurança o mais rapidamente possível. Ao garantir que os alertas estão a funcionar de forma eficaz, as organizações podem minimizar o impacto de uma falha de segurança, reduzindo assim a possibilidade de uma grave violação que possa prejudicar a marca das organizações e impor perdas financeiras através de multas e danos reputacionais.

Controlo 65: forneça documentação de política que regule procedimentos e práticas de alerta de eventos de segurança.

• Intenção: os alertas devem ser utilizados para eventos de segurança importantes que requerem uma resposta imediata de uma organização, uma vez que existe o potencial de o evento ser indicativo de uma falha de segurança do ambiente e/ou de uma falha de segurança de dados. Deve ser documentado um processo forte em torno do processo de alerta para garantir que este processo é realizado de forma consistente e repetível. Esperamos que isto ajude a reduzir a linha cronológica do "ciclo de vida da violação de dados".

• Diretrizes de Provas de Exemplo: forneça às organizações documentos de política e procedimento documentados que abrangem as melhores práticas de alerta de eventos de segurança.

• Exemplo de Prova: abaixo encontra-se um extrato da política/procedimento de alerta de eventos de segurança. Forneça os documentos completos da política e do procedimento para suportar a sua avaliação.

Nota: Esta captura de ecrã mostra um documento de política/processo, a expetativa é que os ISVs partilhem a documentação de política/procedimento de suporte real e não apenas forneçam uma captura de ecrã.

Controlo 66: forneça provas demonstrativos de que os alertas são acionados para triagem imediata para os seguintes tipos de eventos de segurança:

• Criação ou modificações de conta com privilégios

• Eventos de vírus ou software maligno

• Adulteração do registo de eventos

• Eventos IDPS ou WAF, se configurados

• Intenção: acima encontram-se uma lista de alguns tipos de eventos de segurança que podem realçar um evento de segurança que pode apontar para uma falha de segurança do ambiente e/ou violação de dados.

• Diretrizes de Provas de Exemplo: devem ser fornecidas provas com capturas de ecrã da configuração de alertas E provas dos alertas que estão a ser recebidos. As capturas de ecrã de configuração devem mostrar a lógica que está a acionar os alertas e como os alertas são enviados. Os alertas podem ser enviados através de SMS, E-mail, canais do Teams, canais Slack, etc.

• Exemplo de Prova: a Contoso utiliza um SOC de terceiros fornecido pela Claranet Cyber Security. O exemplo seguinte mostra que os alertas no AlienVault, utilizados pelo SOC, estão configurados para enviar um alerta a um membro da Equipa SOC, Dan Turner na Claranet Cyber Security.

Esta captura de ecrã seguinte mostra um alerta a ser recebido pelo Dan.

Controlo 67: forneça provas demonstráveis que mostrem que os funcionários estão sempre disponíveis, todos os dias, para responder a alertas de segurança.

• Intenção: é importante que os alertas de segurança sejam triagemdas o mais rapidamente possível para limitar a exposição ao ambiente e/ou aos dados. O pessoal tem de estar sempre disponível para responder a alertas e fornecer trabalhos de investigação críticos se for identificada uma violação. Quanto mais rápido este processo começar, mais rápido o incidente de segurança pode ser contido para proteger os dados ou para limitar o impacto da falha.
• Exemplo de Diretrizes de Evidência: devem ser fornecidas provas que demonstrem que os membros do pessoal estão disponíveis 24 horas por dia para responder a alertas de segurança. Isto pode ser com uma rotação de chamada.
• Exemplo de Prova: a seguinte captura de ecrã mostra uma rotação de chamada para dezembro de 2020 para a Contoso. A equipa do SOC claranet Cyber Security alertaria os membros da equipa de serviço da Contoso.

Gestão de Riscos de Segurança de Informações

A Gestão de Riscos de Segurança de Informações é uma atividade importante que todas as organizações devem realizar, pelo menos, anualmente. As organizações têm de compreender as suas ameaças e riscos para mitigar eficazmente estas ameaças. Sem uma gestão de riscos eficaz, as organizações podem implementar melhores práticas de segurança em áreas que consideram importantes e, por conseguinte, investir recursos, tempo e dinheiro nestas áreas, quando outras ameaças são muito mais prováveis e, por conseguinte, devem ser mitigadas. A gestão de riscos eficaz ajudará as organizações a concentrarem-se nos riscos que representam a maior ameaça para a empresa. Isto deve ser realizado anualmente, uma vez que o panorama da segurança está em constante mudança e, por conseguinte, as ameaças e os riscos podem mudar as horas extraordinárias. Um bom exemplo disso pode ser visto com a COVID-19, que viu um aumento maciço de ataques de Phishing e a implementação em massa (e rápida) do trabalho remoto para centenas ou milhares de trabalhadores.

Controlo 68: forneça provas de que é estabelecido um processo formal de gestão de riscos de segurança de informações.

• Intenção: tal como abordámos acima, é importante um processo robusto de gestão de riscos de segurança de informações para ajudar as organizações a gerir os riscos de forma eficaz. Isto ajudará as organizações a planear mitigações eficazes contra ameaças ao ambiente.

é importante que a avaliação de riscos inclua o Risco de Segurança da Informação e não apenas riscos gerais de "negócio".

• Diretrizes de Provas de Exemplo: o processo de gestão da avaliação de riscos formalmente documentado deve ser fornecido.
• Exemplo de Prova: a seguinte prova é uma captura de ecrã de parte do processo de avaliação de riscos da Contoso.

Nota: Esta captura de ecrã mostra um documento de política/processo, a expetativa é que os ISVs partilhem a documentação de política/procedimento de suporte real e não apenas forneçam uma captura de ecrã.

Controlo 69: Forneça provas demonstráveis de que uma avaliação formal de riscos ocorre anualmente, no mínimo.

• Intenção: as ameaças de segurança estão em constante mudança com base nas alterações ao ambiente, nas alterações aos serviços oferecidos, nas influências externas, na evolução do panorama das ameaças de segurança, etc. As organizações têm de passar por este processo, pelo menos, anualmente. recomenda-se que este processo também seja realizado após alterações significativas, uma vez que as ameaças podem mudar.

• Exemplo de Diretrizes de Provas: as provas podem ser através do controlo de versões ou de provas datadas. Devem ser fornecidas provas que mostram a saída da avaliação de riscos de segurança de informações e NÃO as datas do próprio processo de avaliação de riscos de segurança de informações.

• Exemplo de Provas: esta captura de ecrã mostra uma reunião de avaliação de riscos agendada para cada seis meses.

Estas duas capturas de ecrã mostram as atas da reunião de duas reuniões de avaliação de riscos.

Controlo 70: forneça provas demonstráveis de que a avaliação de riscos de segurança de informações inclui ameaças, vulnerabilidades ou o equivalente.

• Intenção: as avaliações de riscos de segurança de informações devem ser realizadas contra ameaças contra o ambiente e os dados e contra possíveis vulnerabilidades que possam estar presentes. Isto ajudará as organizações a identificar a miríade de ameaças/vulnerabilidades que podem representar um risco significativo.
• Exemplo de Diretrizes de Evidência: as provas devem ser fornecidas através não só do processo de avaliação de riscos de segurança de informações já fornecido, mas também da saída da avaliação de riscos (através de um plano de tratamento de risco/registo de risco) que deve incluir riscos e vulnerabilidades.
• Exemplo de Prova: a seguinte captura de ecrã mostra o registo de riscos que demonstra ameaças e vulnerabilidades incluídas.

Nota: A documentação completa da avaliação de riscos deve ser fornecida em vez de uma captura de ecrã.

Controlo 71: forneça provas demonstráveis de que a avaliação de risco de segurança de informações inclui impacto, matriz de risco de probabilidade ou equivalente.

• Intenção: as avaliações de riscos de segurança de informações devem documentar as classificações de impacto e probabilidade. Normalmente, estas matrizes serão utilizadas para ajudar a identificar um valor de risco que pode ser utilizado pela organização para priorizar o tratamento de risco para ajudar a reduzir o valor de risco.
• Diretrizes de Evidência de Exemplo: as provas devem ser fornecidas através não só do processo de avaliação de riscos de segurança de informações já fornecido, mas também da saída da avaliação de riscos (através de um plano de tratamento de risco/registo de risco), que deve incluir classificações de impacto e probabilidade.
• Exemplo de Prova: a seguinte captura de ecrã mostra o registo de riscos que demonstra o impacto e as probabilidades estão incluídas.

Nota: O risco total assessment_ _document__ation deve ser fornecido em vez de uma captura de ecrã.

Controlo 72: Forneça provas demonstraveis de que a avaliação de riscos de segurança de informações inclui um registo de riscos e um plano de tratamento.

• Intenção: as organizações precisam de gerir os riscos de forma eficaz. Isto tem de ser devidamente controlado para fornecer um registo de um dos quatro tratamentos de risco que estão a ser aplicados. Os tratamentos de risco são:
• Evitar/Terminar : a empresa pode determinar que o custo de lidar com o risco é superior à receita gerada pelo serviço. Por conseguinte, a empresa pode optar por deixar de executar o serviço.
• Transferência/Partilha : a empresa pode optar por transferir o risco para terceiros ao mover o processamento para terceiros.
• Aceitar/Tolerar/Reter : a empresa pode decidir que o risco é aceitável. Isto depende muito do apetite de risco das empresas e pode variar consoante a organização.
• Tratar/Mitigar/Modificar : a empresa decide implementar controlos de mitigação para reduzir o risco a um nível aceitável.
• A intenção deste controlo é obter a garantia de que a organização está a realizar a avaliação de riscos e a agir em conformidade.
• Exemplo de Diretrizes de Evidência: o plano de tratamento de riscos/registo de risco (ou algo equivalente) deve ser fornecido para demonstrar que o processo de avaliação de riscos está a ser realizado corretamente.
• Exemplo de Prova: abaixo encontra-se um registo de risco para a Contoso.

Nota: A documentação completa da avaliação de riscos deve ser fornecida em vez de uma captura de ecrã.

A captura de ecrã seguinte demonstra um plano de tratamento de risco.

Resposta a Incidentes de Segurança

Uma Resposta a Incidentes de Segurança é importante para todas as organizações, uma vez que pode reduzir o tempo despendido por uma organização para conter um incidente de segurança e limitar o nível de exposição das organizações à transferência de dados não autorizada. Ao desenvolver um plano de resposta a incidentes de segurança abrangente e detalhado, esta exposição pode ser reduzida desde o momento da identificação até ao momento da contenção.

Um relatório da IBM intitulado "Custo de uma violação de dados Relatório 2020" destaca que, em média, o tempo necessário para conter uma violação foi de 73 dias. Além disso, o mesmo relatório identifica a maior poupança de custos para as organizações que sofreram uma falha de segurança, foi a preparação da resposta a incidentes, proporcionando uma poupança média de custos de 2.000.000 dólares.

As organizações devem seguir as melhores práticas de conformidade de segurança através de estruturas padrão da indústria, como ISO 27001, NIST, SOC 2, PCI DSS, etc.

Controlo 73: Indique o plano de resposta a incidentes de segurança (IRP).

• Intenção: Tal como já foi discutido, a intenção deste controlo é exigir um plano de resposta a incidentes formalmente documentado. Isto ajudará a gerir uma resposta a incidentes de segurança mais eficiente, o que pode, em última análise, limitar a exposição à perda de dados das organizações e reduzir os custos do compromisso.
• Exemplo de Diretrizes de Evidência: forneça a versão completa do plano/procedimento de resposta a incidentes. Isto deve incluir um processo de comunicações documentado que é abrangido no controlo seguinte.
• Exemplo de Provas: a captura de ecrã abaixo mostra o início do plano de resposta a incidentes da Contoso. Como parte da submissão de provas, tem de fornecer todo o plano de resposta a incidentes.

Nota: Esta captura de ecrã mostra um documento de política/processo, a expetativa é que os ISVs partilhem a documentação de política/procedimento de suporte real e não apenas forneçam uma captura de ecrã.

Controlo 74: Forneça provas demonstrativos de que o IRP de segurança inclui um processo de comunicação documentado para garantir uma notificação oportuna aos principais intervenientes, tais como marcas de pagamento e adquirentes, entidades reguladoras, autoridades de supervisão, diretores e clientes.

• Intenção: as organizações podem ter obrigações de notificação por violação com base no país/países em que operam (por exemplo, o Regulamento Geral sobre a Proteção de Dados; RGPD) ou com base na funcionalidade que está a ser oferecida (por exemplo, PCI DSS se os dados de pagamento forem processados). A falha da notificação atempadamente pode ter ramificações graves, portanto, para garantir que as obrigações de notificação são cumpridas, os planos de resposta a incidentes devem incluir um processo de comunicação, incluindo comunicação com todos os intervenientes, processos de comunicação multimédia e quem pode e não pode falar com os meios de comunicação.
• Diretrizes de Evidência de Exemplo: forneça a versão completa do plano/procedimento de resposta a incidentes que deve incluir uma secção que abranja o processo de comunicação.
• Exemplo de Prova: a seguinte captura de ecrã mostra uma extração do plano de resposta a incidentes que mostra o processo de comunicação.

Controlo 75: forneça provas demonstráveis de que todos os membros da equipa de resposta a incidentes concluíram a formação anual ou um exercício de topo de tabela.

• Intenção: tal como já foi discutido anteriormente, quanto mais tempo uma organização demorar a conter um compromisso, maior será o risco de transferência de dados por transferência de dados, o que pode resultar num maior volume de dados exfiltrados e quanto maior for o custo global do compromisso. é importante que as equipas de resposta a incidentes da organização estejam equipadas para responder a incidentes de segurança atempadamente. Ao realizar formação regular e realizar exercícios de tabletop, esta ação equipa-a para lidar com incidentes de segurança de forma rápida e eficiente.

• A recomendação é realizar a preparação de resposta a incidentes internos para a equipa de resposta a incidentes e realizar exercícios regulares de tabletop, que devem ligar à avaliação de riscos de segurança de informações para identificar os incidentes de segurança que são mais prováveis de ocorrer. Desta forma, a equipa saberá que passos tomar para conter e investigar rapidamente os incidentes de segurança mais prováveis.

• Exemplo de Diretrizes de Provas: devem ser fornecidas provas que demonstrem que a formação foi realizada com a partilha do conteúdo da formação e registos que mostram quem participou (que deve incluir toda a equipa de resposta a incidentes). Em alternativa, ou também registos que mostram que foi realizado um exercício de tabletop. Tudo isto deve ter sido concluído num período de 12 meses a partir do momento em que os elementos de prova são apresentados.

• Exemplo de Provas: a Contoso realizou um exercício de tabletop de resposta a incidentes com uma empresa de segurança externa denominada Claranet Cyber Security. Segue-se uma amostra do relatório gerado como parte da consultoria.

Nota: O relatório completo teria de ser partilhado. Este exercício também pode ser realizado internamente, uma vez que não existe nenhum requisito do Microsoft 365 para que tal seja realizado por uma empresa de terceiros.

Controlo 76: forneça provas demonstráveis para mostrar que o IRP de segurança é atualizado com base nas lições aprendidas ou nas alterações organizacionais.

• Intenção: ao longo do tempo, o plano de resposta a incidentes (IRP) deve evoluir com base em alterações organizacionais ou com base nas lições aprendidas ao decretar o IRP. As alterações ao ambiente operativo podem exigir alterações ao IRP, uma vez que as ameaças podem mudar ou os requisitos regulamentares podem mudar. Além disso, à medida que são realizados exercícios de tabletop e respostas reais a incidentes de segurança, isto pode muitas vezes identificar áreas do IRP que podem ser melhoradas. Isto tem de ser incorporado no plano e a intenção deste controlo é garantir que este processo está incluído no IRP.

• Diretrizes de Evidência de Exemplo: isto será muitas vezes evidenciado ao rever os resultados de incidentes de segurança ou exercícios de tabletop em que as lições aprendidas foram identificadas e resultaram numa atualização do IRP. O IRP deve manter um registo de alterações, que também deve referenciar as alterações que foram implementadas com base nas lições aprendidas ou nas alterações organizacionais.

• Exemplo de Prova: as seguintes capturas de ecrã são do IRP fornecido, que inclui uma secção sobre a atualização do IRP com base nas lições aprendidas e/ou nas alterações da organização.

O registo de alterações do IRP mostra uma atualização que está a ser feita na parte de trás do exercício de tabletop realizado em julho de 2021.

Domínio de Segurança: Segurança e Privacidade do Processamento de Dados

Este domínio de segurança está incluído para garantir que todos os dados consumidos do Microsoft 365 estão devidamente protegidos em trânsito e inativos. Este domínio também garante que as preocupações de privacidade dos consumidores (titulares dos dados) estão a ser satisfeitas pelo ISV, em conformidade com o Regulamento Geral sobre a Proteção de Dados (RGPD) que diz respeito à privacidade dos cidadãos da UE.

Dados em Trânsito

Devido aos requisitos de conectividade das aplicações/suplementos desenvolvidos do Microsoft 365, a comunicação ocorrerá através de redes públicas, nomeadamente a Internet. Por este motivo, os dados em trânsito têm de ser devidamente protegidos. Esta secção abrange a proteção das comunicações de dados através da Internet.

Controlo 1: forneça provas de que a configuração do TLS cumpre ou excede os requisitos de encriptação nos Requisitos de Configuração do Perfil TLS.

• Intenção: a intenção deste controlo é garantir que os Dados do Microsoft 365 que estão a ser consumidos pela sua organização sejam transmitidos de forma segura. A Configuração do Perfil TLS define requisitos específicos do TLS para ajudar a garantir que o tráfego é seguro contra ataques man-in-the-middle.

• Diretrizes de Evidência de Exemplo: a forma mais fácil de evidenciar isto é executar a ferramenta de Teste do Servidor SSL qualys em todos os serviços de escuta Web, incluindo qualquer que seja executado em portas não padrão.

• Lembre-se de marcar a opção "Não mostrar os resultados nos quadros", o que impede que o URL seja adicionado ao site.

• Também pode fornecer provas para demonstrar as verificações individuais nos Requisitos de Configuração do Perfil TLS. As definições de configuração podem ser utilizadas, juntamente com scripts e ferramentas de software para ajudar a fornecer provas de algumas das definições específicas, ou seja, a Compressão TLS está desativada.

• Exemplo de Prova: a captura de ecrã abaixo mostra os resultados do serviço de escuta na Web www.clara.net:443 .

Nota: os Analistas de Certificação irão rever a saída completa para confirmar que todos os requisitos dos Requisitos de Configuração do Perfil TLS são cumpridos (forneça capturas de ecrã da saída completa da análise). Depending_ _what provas foram fornecidas, os analistas podem executar a sua própria análise qualys.

• Exemplo de Prova 2: a seguinte captura de ecrã mostra que o TLS 1.2 está configurado no armazenamento.

Nota: Esta captura de ecrã por si só não seria capaz de satisfazer este requisito.

• Exemplo de Prova 3: as capturas de ecrã seguintes mostram que o TLS V1.3 só está ativado no servidor.

Este exemplo utiliza as Chaves de Registo para desativar ou ativar um protocolo ao ajustar os valores da seguinte forma:

Binário: 0 - desativado 1 - em

Hexadecimal: 0x00000000 - fora 0xffffffff - em

Nota : - Não utilize esta metodologia se não a compreender, uma vez que nós (Microsoft) não somos responsáveis por utilizar ou seguir este exemplo ou quaisquer efeitos que a sua utilização possa ter nos seus sistemas. está aqui apenas para ilustrar outra forma de mostrar se o TLS está ativado ou desativado.

Nota: estas capturas de ecrã por si só não seriam capazes de satisfazer este requisito.

Controlo 2: forneça provas de que a compressão TLS está desativada em todos os serviços destinados ao público que processam pedidos Web.

• Intenção: existe uma vulnerabilidade TLS específica, CRIME (CVE-2012-4929), que afeta a Compressão TLS. Por este motivo, as recomendações do setor são desativar esta funcionalidade.

• Diretrizes de Provas de Exemplo: isto pode ser uma prova através da ferramenta Qualys SSL Labs.

• Exemplo de Prova: a seguinte captura de ecrã mostra isto através da ferramenta Qualys SSL Labs.

Controlo 3: forneça provas de que a segurança de transporte estrita http do TLS está ativada e configurada para >= 15552000 em todos os sites.

• Intenção: HTTP Strict Transport Security (HSTS) é um mecanismo de segurança concebido para proteger sites contra ataques man-in-the-middle ao forçar ligações TLS através de um campo de cabeçalho de resposta HTTPS denominado "Strict-Transport-Security".

• Diretrizes de Provas de Exemplo: isto pode ser uma prova através da ferramenta Qualys SSL Labs ou de outras ferramentas e suplementos do browser.

• Exemplo de Prova: a seguinte captura de ecrã mostra-o através de um suplemento de browser denominado "Espião de Cabeçalho HTTP" para o site www.microsoft.com .

Dados inativos

Quando os dados consumidos a partir da plataforma do Microsoft 365 são armazenados por ISVs, os dados têm de ser devidamente protegidos. Esta secção abrange os requisitos de proteção dos dados armazenados em bases de dados e arquivos de ficheiros.

Controlo 4: forneça provas de que os dados inativos são encriptados inline com os requisitos do perfil de encriptação, utilizando algoritmos de encriptação como AES, Blowfish, TDES e tamanhos de chave de encriptação de 128 bits e 256 bits.

• Intenção: alguns algoritmos de encriptação mais antigos contêm algumas fraquezas criptográficas, o que aumenta as hipóteses de um grupo de atividade conseguir desencriptar os dados sem ter conhecimento da chave. Por este motivo, a intenção deste controlo é garantir que apenas os algoritmos de encriptação aceites pela indústria são utilizados para proteger dados armazenados do Microsoft 365.

• Diretrizes de Provas de Exemplo: as provas podem ser fornecidas através de capturas de ecrã, que mostram a encriptação que está a ser utilizada para proteger os dados do Microsoft 365 nas bases de dados e noutras localizações de armazenamento. As provas devem demonstrar que a configuração de encriptação está em conformidade com os Requisitos de Configuração do Perfil de Encriptação da Certificação do Microsoft 365.

• Exemplo de Prova: a seguinte captura de ecrã mostra que a Encriptação de Dados Transparente (Encriptação de Dados Transparente) está ativada na Base de Dados Contoso. A segunda captura de ecrã mostra a página de documentos da Microsoft "Encriptação de dados transparente para a Base de Dados SQL, o SQL Managed Instance e o Azure Synapse Analytics" a mostrar que a encriptação AES 256 é utilizada para a Encriptação de Dados Transparente do Azure.

• Exemplo de Prova 2: a seguinte captura de ecrã mostra o Armazenamento do Azure configurado com encriptação para blobs e ficheiros. A seguinte captura de ecrã mostra a página do Microsoft Docs "Encriptação do Armazenamento do Microsoft Azure para dados inativos" que mostra que o Armazenamento do Azure utiliza AES-256 para encriptação.

Controlo 5: forneça provas de que a função hash ou a autenticação de mensagens (HMAC-SHA1) só é utilizada para proteger dados inativos inline com requisitos de perfil de encriptação.

• Intenção: tal como acontece com os algoritmos de encriptação, algumas funções hash e algoritmos de autenticação de mensagens baseiam-se em algoritmos com fraquezas criptográficas. O objetivo deste controlo é garantir que os dados do Microsoft 365 são protegidos com funções hash fortes se o hash estiver a ser utilizado como um mecanismo de proteção de dados. Se isto não for utilizado pelo ambiente e/ou aplicação, é necessário fornecer provas que possam confirmar esta situação.

• Diretrizes de Evidência de Exemplo: as provas podem estar na forma de capturas de ecrã que mostram fragmentos de código onde a função de hash está a funcionar.

• Exemplo de Evidência: a Contoso utiliza a funcionalidade de hash na respetiva aplicação. A captura de ecrã abaixo demonstra que SHA256 é utilizado como parte da função hashing.

Controlo 6: forneça um inventário de todos os dados armazenados, incluindo a localização de armazenamento e a encriptação utilizadas para proteger os dados.

• Intenção: para proteger corretamente os dados, as organizações têm de estar cientes dos dados que o seu ambiente/sistema está a consumir e onde os dados estão a ser armazenados. Assim que isto estiver totalmente compreendido e documentado, as organizações podem implementar não só a proteção de dados adequada, como também podem consolidar onde os dados estão localizados para implementar a proteção de forma mais eficaz. Além disso, quando os dados são consolidados para o menor número possível de locais, é mais fácil implementar um controlo de acesso baseado em funções (controlo de acesso baseado em funções) adequado para limitar o acesso ao menor número de funcionários necessário.

• Diretrizes de Provas de Exemplo: as provas devem ser fornecidas através de um documento ou exportação de um sistema interno, ou seja, do SharePoint ou da Confluência, ao detalhar todos os dados consumidos, a todas as localizações de armazenamento e ao nível de encriptação implementado.

• Exemplo de Prova: a seguinte captura de ecrã mostra um exemplo do aspeto que um documento mostra os tipos de dados.

Retenção e descarte de dados

Quando os ISVs consomem e armazenam dados do Microsoft 365, isto estará em risco de um compromisso de dados caso um grupo de atividades comprometa o ambiente ISV. Para minimizar este risco, as organizações devem manter apenas os dados necessários para a entrega de serviços e não dados que "possam" ser utilizados no futuro. Além disso, os dados só devem ser mantidos durante o tempo necessário para fornecer os serviços para os que os dados foram capturados. A retenção de dados deve ser definida e comunicada com os utilizadores. Assim que os dados excederem o período de retenção definido, estes têm de ser eliminados de forma segura para que os dados não possam ser reconstruídos ou recuperados.

Controlo 7: forneça provas de que é formalmente estabelecido um período de retenção de dados aprovado e documentado.

• Intenção: uma política de retenção documentada e seguida é importante não só para cumprir algumas obrigações legais, como, por exemplo, legislação sobre privacidade de dados, como, mas não se limitando a, o Regulamento Geral sobre a Proteção de Dados (RGPD da UE) e a Lei de Proteção de Dados (DPA do Reino Unido 2018), mas também para limitar o risco de uma organização. Ao compreender os requisitos de dados das organizações e durante quanto tempo os dados são necessários para a empresa desempenhar as suas funções, as organizações podem garantir que os dados são eliminados corretamente assim que a sua utilidade expirar. Ao reduzir os volumes de dados armazenados, as organizações estão a reduzir a quantidade de dados que seriam expostos caso ocorra um comprometimento de dados. Isto irá limitar o impacto geral.

• Muitas vezes, as organizações armazenam dados simplesmente porque é "bom ter apenas no caso" no entanto, se a organização não precisar dos dados para executar o seu serviço ou função empresarial, os dados não devem ser armazenados, uma vez que isto está a aumentar os riscos das organizações desnecessariamente.

• Diretrizes de Evidência de Exemplo: forneça a política de retenção de dados completa que detalha claramente durante quanto tempo os dados (têm de abranger todos os tipos de dados) devem ser mantidos para que a empresa possa desempenhar as suas funções empresariais.

• Exemplo de Prova: a captura de ecrã abaixo mostra a política de retenção de dados da Contoso.

Nota: Esta captura de ecrã mostra um documento de política/processo, a expetativa é que os ISVs partilhem a documentação de política/procedimento de suporte real e não apenas forneçam uma captura de ecrã.

Controlo 8: forneça provas de que os dados retidos correspondem ao período de retenção definido.

• Intenção: a intenção deste controlo é simplesmente validar que os períodos de retenção de dados definidos estão a ser cumpridos. Tal como já foi discutido, as organizações podem ter a obrigação legal de cumprir esta situação, mas também ao manter os dados que são necessários e durante o tempo que for necessário ajudam a reduzir o risco para a organização caso ocorra uma falha de segurança de dados.

• Diretrizes de Provas de Exemplo: forneça provas de captura de ecrã (ou através de screenshare) que mostram que os dados armazenados (em todas as várias localizações de dados, ou seja, bases de dados, partilhas de ficheiros, arquivos, etc.) não excedem a política de retenção de dados definida. Os exemplos podem ser capturas de ecrã de registos de bases de dados com um campo de data, pesquisadas por ordem de registos mais antiga e/ou localizações de armazenamento de ficheiros que mostram carimbos de data/hora dentro do período de retenção.

Nota: Todos os dados pessoais/confidenciais do cliente devem ser redigidos na captura de ecrã.

• Exemplo de Prova: a seguinte evidência mostra uma consulta SQL que mostra o conteúdo da tabela da base de dados ordenada por ordem ascendente no campo "DATE_TRANSACTION" para mostrar os registos mais antigos na base de dados. Isto deve ter dois meses de idade, o que não excede o período de retenção definido.

Nota: Esta é uma base de dados de teste, pelo que não existem muitos dados históricos na mesma.

Controlo 9: forneça provas de que os processos estão em vigor para eliminar dados de forma segura após o respetivo período de retenção.

• Intenção: a intenção deste controlo é garantir que o mecanismo utilizado para eliminar dados que excedem o período de retenção está a fazê-lo de forma segura. Por vezes, os dados eliminados podem ser recuperados; Por conseguinte, o processo de eliminação tem de ser suficientemente robusto para garantir que os dados não podem ser recuperados depois de eliminados.

• Diretrizes de Evidência de Exemplo: se o processo de eliminação for feito através de programação, forneça uma captura de ecrã do script que é utilizado para efetuar esta ação. Se for executado com base numa agenda, forneça uma captura de ecrã a mostrar a agenda. Por exemplo, um script para eliminar ficheiros numa partilha de ficheiros pode ser configurado como uma tarefa CRON, captura de ecrã a mostrar a tarefa CRON que mostra a agenda e o script que é executado e fornecer o script que mostra o comando utilizado.

• Exemplo de Prova 1: este é um script simples que pode ser utilizado para eliminar todos os registos de dados retidos com base na data -WHERE DateAdd é -30 dias, o que removerá todos os registos retidos com mais de 30 dias após a data de retenção de dados selecionada. Tenha em atenção que vamos precisar do script, mas também provas de que a tarefa está a ser executada e os resultados.

• Exemplo de Prova 2: o seguinte foi retirado do Plano de Retenção de Dados da Contoso no Controlo 7 – isto mostra os procedimentos utilizados para a destruição de dados.

Nota: Esta captura de ecrã mostra um documento de política/processo, a expetativa é que os ISVs partilhem a documentação de política/procedimento de suporte real e não apenas forneçam uma captura de ecrã.

• Exemplo de Prova 3: neste exemplo, foi criado um Runbook e uma agenda correspondente no Azure para eliminar de forma segura os registos com uma data de fim criada a partir dos 30 dias após a expiração da política de retenção de registos de dados. Esta tarefa está definida para ser executada todos os meses no último dia do mês.

A janela abaixo mostra que o Runbook foi editado para localizar registos e tem comandos de eliminação que não estão visíveis como o script. Tenha em atenção que o URL completo e o nome de utilizador têm de estar visíveis para estas capturas de ecrã e os ISVs serão necessários para mostrar uma captura de ecrã de antes da contagem de registos de eliminação e uma captura de ecrã após a contagem de registos de eliminação. Estas capturas de ecrã são apenas exemplos das diferentes formas de abordagem.

Gestão de Acesso a Dados

O acesso a dados tem de ser limitado a tão poucas pessoas quanto necessário para reduzir as hipóteses de os dados serem comprometidos maliciosamente ou acidentalmente. O acesso a chaves de dados e encriptação deve ser limitado a utilizadores com uma necessidade de acesso empresarial legítima para cumprir a função de trabalho. Isto deve estar bem documentado e deve ser implementado um processo bem estabelecido para pedir acesso. O acesso a chaves de dados e encriptação deve seguir o princípio de menor privilégio.

Controle 10:P veja uma lista de todas as pessoas com acesso a dados ou chaves de encriptação, incluindo a justificação comercial.

• Intenção: as organizações devem limitar o acesso a dados e chaves de encriptação ao menor número possível de funcionários. A intenção deste controlo é garantir que o acesso dos funcionários aos dados e/ou às chaves de encriptação seja restringido aos funcionários com uma necessidade de negócio clara para esse acesso.

• Diretrizes de Provas de Exemplo: documentação ou capturas de ecrã de sistemas internos que documentam todos os funcionários com acesso a dados e/ou chaves de encriptação, juntamente com a justificação comercial do motivo pelo qual estas pessoas têm acesso devem ser fornecidas. Esta lista será utilizada pelo analista de certificação para exemplo de utilizadores para os próximos controlos.

• Exemplo de Prova: o documento seguinte mostra a lista documentada de utilizadores com acesso aos dados e a justificação comercial.

Controlo 11: forneça provas de que os indivíduos de amostra que têm acesso a dados ou chaves de encriptação foram formalmente aprovados, detalhando os privilégios necessários para a função de trabalho.

• Intenção: o processo para conceder acesso a dados e/ou chaves de encriptação tem de incluir aprovação, garantindo que o acesso de um indivíduo é necessário para a função de trabalho. Isto garante que os funcionários sem um motivo genuíno de acesso não recebem acesso desnecessário.

• Exemplo de Diretrizes de Evidência: normalmente, as provas fornecidas para o controlo anterior podem ajudar a suportar este controlo. Se não existir uma aprovação formal na documentação fornecida, as provas poderão consistir num pedido de alteração que está a ser gerado e aprovado para o acesso dentro de uma ferramenta como o Azure DevOps ou jira.

• Exemplo de Prova: este conjunto de imagens mostra Pedidos Jira criados e aprovados para a lista acima no Controlo 10 para conceder ou negar o acesso a dados confidenciais e/ou chaves de encriptação.

Esta imagem demonstra que foi criado um pedido em Jira para obter a aprovação de Sam Daily para Chaves de Encriptação no ambiente de back-end dos sistemas. Isto é feito como o passo seguinte para controlar 10 acima, onde foi obtida autorização escrita.

Isto mostra que o pedido para dar acesso ao Sam Daily foi aprovado por Jon Smith uma pessoa da administração que pode ser vista no controlo 10. (Tenha em atenção que a aprovação tem de ser proveniente de alguém com autoridade suficiente para permitir o pedido de alteração, não pode ser outro programador).

O acima mostra um fluxo de trabalho em Jira para este processo. Tenha em atenção que nada pode ser adicionado como Concluído, a menos que tenha passado pelo processo de aprovação que é automatizado, pelo que não pode ser transmitido.

O quadro do Project acima mostra agora que foi dada aprovação para o acesso do Sam Daily às chaves de encriptação. Abaixo do registo de tarefas pendentes mostra a aprovação do pedido de Sam Daily e a pessoa atribuída para fazer o trabalho.

Para cumprir os requisitos deste controlo, tem de mostrar todas estas capturas de ecrã ou semelhantes com uma explicação para demonstrar que cumpriu o requisito de controlo.

• Exemplo de Prova 2: no exemplo abaixo, foram pedidas permissões de acesso de administrador e controlo total para um utilizador para a base de dados de produção. O pedido foi enviado para aprovação, tal como pode ser visto à direita da imagem e este foi aprovado, como pode ver à esquerda.

Acima, pode ver que o acesso foi aprovado e assinado como concluído.

Controlo 12: forneça provas de que os indivíduos de amostra que têm acesso a dados ou chaves de encriptação têm apenas os privilégios incluídos na aprovação.

• Intenção: a intenção deste controlo é confirmar que o acesso à chave de dados e/ou encriptação está configurado de acordo com o documento.

• Exemplo de Diretrizes de Evidência: as provas podem ser fornecidas através de uma captura de ecrã que mostra os dados e/ou os privilégios de acesso da chave de encriptação concedidos aos indivíduos de amostra. As provas têm de abranger todas as localizações de dados.

• Exemplo de Prova: esta captura de ecrã mostra as permissões concedidas ao utilizador "João Silva", que seriam referenciadas de forma cruzada em relação ao pedido de aprovação para este mesmo utilizador, de acordo com as provas do controlo anterior.

Controlo 13: forneça uma lista de todos os terceiros com os quais os dados dos clientes são partilhados.

• Intenção: quando são utilizados terceiros para armazenamento ou processamento de dados do Microsoft 365, estas entidades podem representar um risco significativo. As organizações devem desenvolver um bom processo de gestão e diligência de terceiros para garantir que estes terceiros estão a armazenar/processar dados de forma segura e para garantir que respeitarão quaisquer obrigações legais que possam ter, por exemplo, como processador de dados ao abrigo do RGPD.

• As organizações devem manter uma lista de todos os terceiros com os quais partilham dados com alguns ou todos os seguintes:

• que serviço(s) estão a ser fornecidos,

• que dados são partilhados,

• por que motivo os dados são partilhados,

• informações de contacto da chave (ou seja, contacto principal, contacto de notificação de violação, DPO, etc.),

• renovação/expiração do contrato

• obrigações legais/de conformidade (ou seja, RGPD, HIPPA, PCI DSS, FedRamp, etc.)

• Diretrizes de Provas de Exemplo: forneça documentação que detalha todos os terceiros com os quais os dados do Microsoft 365 são partilhados.

Nota: Se terceiros não estiverem a ser utilizados, isto terá de ser confirmado por escrito (e-mail) por um membro da equipa de liderança sénior.

• Exemplo de Prova 1

• Exemplo de Prova 2: esta captura de ecrã mostra um exemplo de e-mail de um membro da equipa de liderança sénior a confirmar que não são utilizados terceiros para processar dados do Microsoft 365.

Controlo 14: forneça provas de que todos os terceiros que consomem dados de clientes têm contratos de partilha implementados.

• Intenção: onde os dados do Microsoft 365 são partilhados com terceiros, é importante que os dados estejam a ser processados de forma adequada e segura. Os contratos de partilha de dados têm de estar em vigor para garantir que terceiros processam os dados apenas conforme necessário e que compreendem as suas obrigações de segurança. A segurança de uma organização é tão forte quanto a ligação mais fraca. A intenção deste controlo é garantir que terceiros não se tornem um elo fraco das organizações.

• Exemplo de Diretrizes de Provas: partilhe os contratos de partilha de dados que estão em vigor com terceiros.

• Exemplo de Prova: a seguinte captura de ecrã mostra um contrato de partilha de dados de exemplo simplista.

Nota: O contrato completo deve ser partilhado e não uma captura de ecrã.

RGPD

A maioria das organizações irá processar dados que são potencialmente dados do Cidadão Europeu (titulares dos dados). Quando os dados de QUALQUER titular dos dados forem processados, as organizações terão de cumprir o Regulamento Geral sobre a Proteção de Dados (RGPD). Isto aplica-se aos Controladores de Dados (está a capturar diretamente esses dados) ou aos Processadores de Dados (está a processar estes dados em nome de um Controlador de Dados). Apesar de esta secção não abranger todo o regulamento, aborda alguns dos principais elementos do RGPD para ajudar a obter alguma garantia de que a organização está a levar o RGPD a sério.

Controlo 15: forneça um processo documentado de pedido de acesso a requerentes (SAR) e forneça provas que demonstrem que os titulares dos dados são capazes de gerar SARs.

• Intenção: o RGPD inclui obrigações específicas que têm de ser cumpridas pelas organizações que processam os dados dos titulares dos dados. A obrigação de as organizações gerirem pedidos de acesso a requerentes (SARs) é incluída no artigo 12.º que, nos termos do artigo 12.3.o, dá a um responsável pelo tratamento de dados um mês de receção da SAR para responder ao pedido. Uma extensão é permitida por mais dois meses, se necessário. Mesmo que a sua organização esteja a agir como Processador de Dados, isto continuará a ser necessário para ajudar os seus clientes (o Controlador de Dados) a cumprirem as suas obrigações de SARs.

• Exemplo de Diretrizes de Evidência: forneça o processo documentado para processar SARs.

• Exemplo de Prova: o exemplo seguinte mostra um processo documentado para o processamento de SARs.

Nota: Esta captura de ecrã mostra um documento de política/processo, a expetativa é que os ISVs partilhem a documentação de política/procedimento de suporte real e não apenas forneçam uma captura de ecrã.

Controlo 16: forneça provas de que é capaz de identificar todas as localizações dos dados dos titulares dos dados ao responder a uma SAR.

• Intenção: a intenção deste controlo é garantir que a organização tem um mecanismo robusto implementado para identificar todos os dados de todos os titulares dos dados. Este pode ser um processo manual porque todo o armazenamento de dados está bem documentado ou outras ferramentas podem ser utilizadas para garantir que todos os dados estão localizados como parte do processo de SARs.

• Exemplo de Diretrizes de Evidência: as provas podem ser fornecidas através de uma lista de todas as localizações de dados e de um processo documentado para procurar dados em todas as localizações de dados. Isto incluiria quaisquer comandos necessários para procurar dados, ou seja, se as localizações SQL estiverem incluídas, as instruções SQL específicas seriam detalhadas para garantir que os dados são encontrados corretamente.

• Exemplo de Prova: a seguinte captura de ecrã é um fragmento do procedimento da SAR acima que mostra como os dados serão encontrados.

As quatro imagens abaixo mostram como as localizações de dados ISV onde foram consultadas e, em seguida, o Explorador de armazenamento utilizado para desagregar os ficheiros ou blobs que precisavam de ser removidos do armazenamento para cumprir o pedido de SARs.

Esta consulta confirma as contas de armazenamento em utilização. Pode consultar e remover armazenamento, blobs e/ou ficheiros com o Explorador do Resource Graph (Kusto) ou o PowerShell (veja abaixo).

A imagem acima mostra os dados que foram encontrados no contentor de blobs para o cliente que precisa de ser removido e abaixo mostra a ação para eliminar ou eliminar de forma recuperável as informações no blob.

Controlo 17: forneça uma ligação para o aviso de privacidade que deve conter todos os elementos necessários da seguinte forma:

• Detalhes das empresas (Nome, Endereço, etc.).

• Detalha os tipos de dados pessoais que estão a ser processados.

• Detalha a legalidade do processamento de dados pessoais.

• Detalhes dos direitos do titular dos dados:

  • Direito de ser informado,
  • Direito de acesso pelo titular dos dados,
  • Direito de eliminação,
  • Direito à restrição do processamento,
  • Direito à portabilidade dos dados,
  • Da direita para o objeto,
  • Direitos relacionados com a tomada de decisões automatizada, incluindo a criação de perfis.

• Detalhes durante quanto tempo os dados pessoais serão mantidos.

• Intenção: o artigo 13.º do RGPD inclui informações específicas que têm de ser fornecidas aos titulares dos dados no momento em que os dados pessoais são obtidos. O objetivo deste controlo é garantir que o aviso de privacidade dos dados da organização fornece aos titulares dos dados algumas das informações principais incluídas no artigo 13.º.

• Diretrizes de Provas de Exemplo: normalmente, isto seria fornecido ao fornecer o aviso de privacidade dos dados. Os analistas de certificação irão analisá-lo para garantir que todas as informações fornecidas no controlo estão incluídas no aviso de privacidade dos dados.

• Exemplo de Provas

As imagens de um Aviso de Privacidade acima e adjacente mostram um exemplo de uma política de privacidade online com o artigo 13.º do RGPD incluído.

Segue-se uma Política de Proteção de Dados que pode ser utilizada em conjunto com o aviso de privacidade apresentado anteriormente.

A imagem acima do Azure mostra como o Azure foi configurado para cumprir os requisitos de conformidade do RGPD para os dados armazenados num ambiente de back-end. A política (que pode ser personalizada ou criada a partir do Azure Blueprints) permite que o ISV garanta que os dados do cliente são armazenados corretamente e que só são acessíveis pelas métricas e alertas definidos para garantir a conformidade e mostrará dados não conformes ou acesso do utilizador no dashboard do Gestor de Conformidade.

Manuais

Murdoch D. (2018) Blue Team Handbook: Incident Response Edition: Um guia de campo condensado para o Cyber Security Incident Responder. 2ª Edição, Publicador: CreateSpace Independent Publishing Platform.

Referências

• Relatório de Crime Cibernético de Fraude de Ação Disponível em: https://www.actionfraud.police.uk/ (Acedido a 02/08/21).
• A UE. (2021) Lista de Verificação do RGPD para controladores de dados Disponíveis em: https://gdpr.eu/checklist/ (Acedido a 02/01/21).
• Microsoft. (2018) Registo de Eventos (Windows Installer) Disponível em: Registo de Eventos (Windows Installer) (Acedido: 12/23/20).
• Tecnologias Positivas. (2020) How to approach secure software development Available at: https://www.ptsecurity.com/ww-en/analytics/knowledge-base/how-to-approach-secure-software-development/(Accessed: 21/12/20).
• Regulamento (UE) 2016/679 do Parlamento Europeu e do Conselho de 27 de abril de 2016 sobre a proteção de pessoas singulares no que diz respeito ao processamento de dados pessoais e à livre circulação desses dados, e revogação da Diretiva 95/46/CE (Regulamento Geral sobre a Proteção de Dados) (Texto com relevância do EEE) (2016) Disponível em: https://www.legislation.gov.uk/eur/2016/679/contents (Acedido: 01/11/2021).
• Métricas de Segurança. (2020) Guia de Métricas de Segurança para Conformidade do PCI DSS. Disponível em: https://info.securitymetrics.com/pci-guide-2020(Acedido: 06/01/21).
• Williams J. OWASP Risk Ranking Disponível em: https://owasp.org/www-community/OWASP_Risk_Rating_Methodology (Acedido: 12/08/20).
• Qualys. (2014) SSL Labs: New Grades for Trust (T) and Mismatch (M) Issues Available at: https://blog.qualys.com/product-tech/2014/06/17/ssl-labs-new-grades-for-trust-t-and-mismatch-m-issues (Accessed: 29/01/21).
• NIST SP800-61r2: Guia de Processamento de Incidentes de Segurança Informática Disponível em:https://csrc.nist.gov/publications/detail/sp/800-61/rev-2/final (Acedido a 24/01/21).

Imagens tiradas a partir de Documentos da Microsoft

• https://www.sans.org/information-security-policy/(Acedido a 02/18/21). em Obter análise comportamental e deteção de anomalias (Acedido a 02/16/21). em O que são Alertas do Azure Monitor? (Acedido a 02/17/21). em Obter análise comportamental e deteção de anomalias (Acedido a 22/02/21). em Gerir e responder a alertas de segurança no Microsoft Defender para Cloud (Acedido a 24/02/21). em Gerir e responder a alertas de segurança no Microsoft Defender para Cloud (Acedido a 24/02/21).
• https://microsoft.github.io/AzureTipsAndTricks/blog/tip272.html em O que é o Azure Information Protection? na encriptação de dados transparente para a Base de Dados SQL, o SQL Managed Instance e o Azure Synapse Analytics no Início Rápido: Criar uma atribuição de política para identificar recursos não conformes em Configurar a Proteção Avançada Contra Ameaças para a Base de Dados SQL do Azure