Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
O domínio de segurança operacional garante que os ISVs implementem um forte conjunto de técnicas de mitigação de segurança contra uma infinidade de ameaças enfrentadas por agentes de ameaças. Isso foi projetado para proteger o ambiente operacional e os processos de desenvolvimento de software para criar ambientes seguros.
Treinamento de conscientização
O treinamento de conscientização de segurança é importante para as organizações, pois ajuda a minimizar os riscos decorrentes do erro humano, que está envolvido em mais de 90% das violações de segurança. Isso ajuda os funcionários a entender a importância das medidas e procedimentos de segurança. Quando o treinamento de conscientização de segurança é oferecido, ele reforça a importância de uma cultura de conscientização de segurança, onde os usuários sabem como reconhecer e responder a ameaças potenciais. Um programa eficaz de treinamento de conscientização de segurança deve incluir conteúdo que abranja uma ampla gama de tópicos e ameaças que os usuários podem enfrentar, como engenharia social, gerenciamento de senhas, privacidade e segurança física.
Controle nº 1
Forneça evidências de que:
A organização estabelece políticas e processos de treinamento de conscientização de segurança que exigem que todos os usuários dos sistemas no escopo (incluindo contratados) passem por treinamento:
Como parte do treinamento inicial para novos usuários, ou quando exigido por mudanças no sistema de informação/organização ou tendências do setor.
Pelo menos anualmente.
Você documenta e monitora o treinamento de conscientização sobre a segurança do sistema de informações e mantém registros de treinamento individuais em linha com o ponto A.
Intenção: treinamento para novos usuários
Este subponto se concentra no estabelecimento de um programa obrigatório de treinamento de conscientização de segurança projetado para todos os funcionários e para novos funcionários que ingressam na organização, independentemente de sua função. Isso inclui gerentes, executivos seniores e contratados. O programa de conscientização de segurança deve abranger um currículo abrangente projetado para transmitir conhecimento básico sobre os protocolos, políticas e práticas recomendadas de segurança da informação da organização para garantir que todos os membros da organização estejam alinhados com um conjunto unificado de padrões de segurança, criando um ambiente de segurança da informação resiliente.
Diretrizes: treinamento para novos usuários
A maioria das organizações utilizará uma combinação de treinamento de conscientização de segurança baseado em plataforma e documentação administrativa, como documentação de políticas e registros, para acompanhar a conclusão do treinamento para todos os funcionários da organização. As evidências fornecidas devem mostrar que os funcionários concluíram o treinamento, e isso deve ser respaldado por políticas/procedimentos de apoio descrevendo o requisito de conscientização de segurança.
Exemplo de evidência: treinamento para novos usuários
A captura de tela a seguir mostra a plataforma Confluence sendo usada para rastrear a integração de novos funcionários. Um tíquete JIRA foi gerado para o novo funcionário, incluindo sua atribuição, função, departamento, etc. Com o novo processo inicial, o treinamento de conscientização de segurança foi selecionado e atribuído ao funcionário, que precisa ser concluído até a data de vencimento de 28 de fevereiro de 2023.
A captura de tela mostra o certificado de conclusão gerado pelo Knowb4 após a conclusão bem-sucedida do treinamento de conscientização de segurança do funcionário. A data de conclusão é 21 de fevereiro de 2023, dentro do período atribuído.
Intenção: alterações no sistema de informações.
O objetivo deste subponto é garantir que o treinamento de conscientização de segurança adaptativa seja iniciado sempre que houver mudanças significativas nos sistemas de informação da organização. As modificações podem surgir devido a atualizações de software, alterações arquitetônicas ou novos requisitos regulamentares. A sessão de treinamento atualizada garante que todos os funcionários sejam informados sobre as novas mudanças e o impacto resultante nas medidas de segurança, permitindo que eles adaptem suas ações e decisões de acordo. Essa abordagem proativa é vital para proteger os ativos digitais da organização contra vulnerabilidades que podem surgir de alterações no sistema.
Diretrizes: mudanças no sistema de informação.
A maioria das organizações utilizará uma combinação de treinamento de conscientização de segurança baseado em plataforma e documentação administrativa, como documentação de políticas e registros para acompanhar a conclusão do treinamento para todos os funcionários. As evidências fornecidas devem demonstrar que vários funcionários concluíram o treinamento com base em diferentes mudanças nos sistemas da organização.
Exemplo de evidência: alterações no sistema de informação.
As próximas capturas de tela mostram a atribuição de treinamento de conscientização de segurança a vários funcionários e demonstram que ocorrem simulações de phishing.
A plataforma é usada para atribuir um novo treinamento sempre que ocorre uma alteração no sistema ou um teste é reprovado.
Intenção: frequência do treinamento de conscientização.
O objetivo deste subponto é definir uma frequência específica da organização para o treinamento periódico de conscientização de segurança. Isso pode ser agendado anualmente, semestralmente ou em um intervalo diferente determinado pela organização. Ao definir uma frequência, a organização garante que os usuários sejam atualizados regularmente sobre o cenário de ameaças em evolução, bem como sobre novas medidas e políticas de proteção. Essa abordagem pode ajudar a manter um alto nível de conscientização de segurança entre todos os usuários e reforçar os componentes de treinamento anteriores.
Diretrizes: frequência de treinamentos de conscientização.
A maioria das organizações terá documentação administrativa e/ou uma solução técnica para delinear/implementar o requisito e o procedimento para o treinamento de conscientização de segurança, bem como definir a frequência do treinamento. As evidências fornecidas devem demonstrar a conclusão de vários treinamentos de conscientização dentro do período definido e que existe um período definido por sua organização.
Exemplo de evidência: frequência de treinamento de conscientização.
As capturas de tela a seguir mostram instantâneos da documentação da política de conscientização de segurança e que ela existe e é mantida. A política exige que todos os funcionários da organização recebam treinamento de conscientização de segurança, conforme descrito na seção de escopo da política. O treinamento deve ser atribuído e concluído anualmente pelo departamento relevante.
De acordo com o documento de política, todos os funcionários da organização devem concluir três cursos (um treinamento e duas avaliações) anualmente e dentro de vinte dias após a atribuição. Os cursos devem ser enviados por e-mail e atribuídos através da KnowBe4.
O exemplo fornecido mostra apenas instantâneos da política. Observe que a expectativa é que o documento completo da política seja enviado.
A segunda captura de tela é a continuação da política e mostra a seção do documento que exige o requisito de treinamento anual e demonstra que a frequência de treinamento de conscientização definida pela organização é definida como anual.
As próximas duas capturas de tela demonstram a conclusão bem-sucedida das avaliações de treinamento mencionadas anteriormente. As capturas de tela foram tiradas de dois funcionários diferentes.
Intenção: documentação e monitoramento.
O objetivo deste subponto é criar, manter e monitorar registros meticulosos da participação de cada usuário no treinamento de conscientização de segurança. Esses registros devem ser retidos por um período definido pela organização. Essa documentação serve como uma trilha auditável para conformidade com regulamentos e políticas internas. O componente de monitoramento permite que a organização avalie a eficácia do treinamento, identificando áreas de melhoria e entendendo os níveis de engajamento do usuário. Ao reter esses registros por um período definido, a organização pode acompanhar a eficácia e a conformidade a longo prazo.
Diretrizes: documentação e monitoramento.
As evidências que podem ser fornecidas para o treinamento de conscientização de segurança dependerão de como o treinamento é implementado no nível da organização. Isso pode incluir se o treinamento é realizado por meio de uma plataforma ou realizado internamente com base em um processo interno. As evidências fornecidas devem mostrar que existem registros históricos de treinamento concluído para todos os usuários durante um período e como isso é rastreado.
Exemplo de evidência: documentação e monitoramento.
A próxima captura de tela mostra o registro histórico de treinamento de cada usuário, incluindo a data de ingresso, a conclusão do treinamento e quando o próximo treinamento está agendado. A avaliação deste documento é realizada periodicamente e pelo menos uma vez por ano para garantir que os registros de treinamento de conscientização de segurança para cada funcionário sejam mantidos atualizados.
Proteção contra malware/antimalware
O malware representa um risco significativo para as organizações, o que pode variar o impacto na segurança causado ao ambiente operacional, dependendo das características do malware. Os agentes de ameaças perceberam que o malware pode ser monetizado com sucesso, o que foi percebido por meio do crescimento de ataques de malware no estilo ransomware. O malware também pode ser usado para fornecer um ponto de entrada para um agente de ameaça comprometer um ambiente para roubar dados confidenciais, ou seja, Trojans/Rootkits de Acesso Remoto. As organizações, portanto, precisam implementar mecanismos adequados para se proteger contra essas ameaças. As defesas que podem ser usadas são antivírus (AV)/EDR (Detecção e Resposta de Ponto de Extremidade)/EDPR (Resposta de Detecção e Proteção de Ponto de Extremidade)/Verificação baseada em heurística usando IA (Inteligência Artificial). Se você implantou uma técnica diferente para reduzir o risco de malware, informe ao analista de certificação, que ficará feliz em explorar se isso atende à intenção ou não.
Controle nº 2
FALHA DIFÍCIL
Fornecer evidências de que:
- A solução antimalware da organização está ativa e habilitada em todos os componentes do sistema amostrados.
Se estiver usando uma solução antivírus tradicional, ela DEVE ser configurada:
A varredura ao acessar é ativada e as assinaturas são atualizadas em um dia.
Bloqueia/coloca automaticamente em quarentena malware ou alerta para triagem imediata quando é detectado malware.
OU, se estiver usando NGAV (Detecção e Resposta de Ponto de Extremidade/Antivírus de Próxima Geração), ele:
DEVE ser configurado:
Para executar a verificação periódica,
para gerar logs de auditoria e
manter-se atualizado continuamente e ter recursos de autoaprendizagem.
DEVE ser configurado:
para bloquear malware conhecido e
para identificar e bloquear novas variantes de malware com base em comportamentos de macro, além de ter recursos completos de lista segura.
Intenção: varredura ao acessar
Este subponto foi projetado para verificar se o software antimalware está instalado em todos os componentes do sistema de amostra e está executando ativamente a varredura ao acessar. O controle também exige que o banco de dados de assinatura da solução antimalware seja atualizado dentro de um período de um dia. Um banco de dados de assinaturas atualizado é crucial para identificar e mitigar as ameaças de malware mais recentes, garantindo assim que os componentes do sistema estejam adequadamente protegidos.
Diretrizes: varredura ao acessar
Para demonstrar que uma instância ativa do AV está em execução no ambiente avaliado, forneça uma captura de tela para cada dispositivo no conjunto de amostras acordado com seu analista que dá suporte ao uso de antimalware. A captura de tela deve mostrar que o antimalware está em execução e que o software antimalware está ativo. Se houver um console de gerenciamento centralizado para antimalware, as evidências do console de gerenciamento poderão ser fornecidas. Além disso, certifique-se de fornecer uma captura de tela que mostre que os dispositivos amostrados estão conectados e funcionando.
Exemplo de evidência: varredura ao acessar
A captura de tela a seguir foi tirada de um dispositivo Windows Server, mostrando que "Microsoft Defender" está habilitado para o nome de host "IaaS-Web-app".
A próxima captura de tela foi tirada de um dispositivo Windows Server, mostrando que a versão de inteligência de segurança do Microsoft Defender Antimalware atualizou o log do visualizador de eventos do Windows. Isso demonstra as assinaturas mais recentes para o nome do host "IaaS-Web-app".
Esta captura de tela foi tirada de um dispositivo Windows Server, mostrando as atualizações da Proteção Antimalware do Microsoft Defender. Isso mostra claramente as versões de definição de ameaça, a versão criada e a última atualização para demonstrar que as definições de malware estão atualizadas para o nome do host "IaaS-Web- app".
Intenção: bloqueios antimalware
A finalidade deste subponto é confirmar se o software antimalware está configurado para bloquear automaticamente o malware após a detecção ou gerar alertas e mover o malware detectado para uma área de quarentena segura. Isso pode garantir que uma ação imediata seja tomada quando uma ameaça for detectada, reduzindo a janela de vulnerabilidade e mantendo uma forte postura de segurança do sistema.
Diretrizes: bloqueios antimalware
Forneça uma captura de tela para cada dispositivo no exemplo que dá suporte ao uso de antimalware. A captura de tela deve mostrar que o antimalware está em execução e está configurado para bloquear automaticamente o malware, alertar ou colocar em quarentena e alertar.
Exemplo de evidência: bloqueios antimalware
A próxima captura de tela mostra que o host "IaaS-Web-app" está configurado com proteção em tempo real como ATIVADO para o Microsoft Defender Antimalware. Como diz a configuração, isso localiza e impede que o malware se instale ou seja executado no dispositivo.
Exemplo de evidência: Ubuntu Linux (ClamAV)
A captura de tela a seguir demonstra um exemplo de evidência aceitável para um sistema Ubuntu Linux executando o ClamAV. O exemplo mostra o serviço antimalware em execução, atualizações recentes de assinatura, configuração de verificação ao acessar e entradas de log demonstrando detecção de malware e correção automática.
Intenção: EDR/NGAV
Este subponto tem como objetivo verificar se o Endpoint Detection and Response (EDR) ou o Next-Generation Antivirus (NGAV) estão realizando ativamente verificações periódicas em todos os componentes do sistema amostrados; logs de auditoria são gerados para rastrear atividades e resultados de verificação; A solução de verificação é atualizada continuamente e possui recursos de autoaprendizagem para se adaptar a novos cenários de ameaças.
Diretrizes: EDR/NGAV
Forneça uma captura de tela de sua solução EDR/NGAV demonstrando que todos os agentes dos sistemas amostrados estão relatando e mostrando que seu status está ativo.
Exemplo de evidência: EDR/NGAV
A próxima captura de tela da solução OpenEDR mostra que a varredura em tempo real está ativada.
A próxima captura de tela mostra que os alertas são gerados com base em métricas de comportamento que foram obtidas em tempo real do agente instalado no nível do sistema.
A próxima captura de tela mostra que os alertas são gerados com base em métricas de comportamento que foram obtidas em tempo real do agente instalado no nível do sistema.
As próximas capturas de tela da solução OpenEDR demonstram a configuração e a geração de logs e alertas de auditoria. A segunda imagem mostra que a política está habilitada e os eventos estão configurados.
A próxima captura de tela da solução OpenEDR demonstra que a solução é mantida atualizada continuamente.
Intenção: EDR/NGAV
O foco deste subponto é garantir que o EDR/NGAV tenha a capacidade de bloquear malware conhecido automaticamente e identificar e bloquear novas variantes de malware com base em comportamentos de macro. Ele também garante que a solução tenha recursos de aprovação total, permitindo que a organização permita software confiável enquanto bloqueia todo o resto, adicionando assim uma camada adicional de segurança.
Diretrizes: EDR/NGAV
Dependendo do tipo de solução usada, podem ser fornecidas evidências mostrando as definições de configuração da solução e que a solução tem recursos de Aprendizado de Máquina/heurística, além de estar configurada para bloquear malware após a detecção. Se a configuração for implementada por padrão na solução, isso deverá ser validado pela documentação do fornecedor.
Exemplo de evidência: EDR/NGAV
As próximas capturas de tela da solução OpenEDR demonstram que um Perfil Seguro v7.4 está configurado para impor varredura em tempo real, bloquear malware e quarentena.
As próximas capturas de tela da configuração do Perfil Seguro v7.4 demonstram que a solução implementa a verificação "Realtime" com base em uma abordagem antimalware mais tradicional, que verifica assinaturas de malware conhecidas, e a verificação "Heurística" definida como um nível médio. A solução detecta e remove malware verificando os arquivos e o código que se comportam de maneira suspeita/inesperada ou maliciosa.
O verificador é configurado para descompactar arquivos e examinar os arquivos internos para detectar possíveis malwares que possam estar se ocultando no arquivo morto. Além disso, o verificador é configurado para bloquear microscripts em arquivos do Microsoft Office.
As próximas capturas de tela demonstram que o Secure Profile v.7.4 foi atribuído ao nosso host 'IaaS-Web-app' do dispositivo do Windows Server.
A próxima captura de tela foi tirada do dispositivo do Windows Server 'IaaS-Web-app', que demonstrou que o agente OpenEDR está habilitado e em execução no host.
Proteção contra malware/controle de aplicativos
O controle de aplicativos é uma prática de segurança que bloqueia ou restringe a execução de aplicativos não autorizados de maneiras que colocam os dados em risco. Os controles de aplicativos são uma parte importante de um programa de segurança corporativa e podem ajudar a impedir que agentes mal-intencionados explorem vulnerabilidades de aplicativos e reduzir o risco de uma violação. Ao implementar o controle de aplicativos, as empresas e organizações podem reduzir significativamente os riscos e ameaças associados ao uso de aplicativos, pois a execução dos aplicativos é impedida de ser executada se colocarem a rede ou dados confidenciais em risco. Os controles de aplicativos fornecem às equipes de operações e segurança uma abordagem confiável, padronizada e sistemática para mitigar o risco cibernético. Eles também oferecem às organizações uma visão mais completa dos aplicativos em seu ambiente, o que pode ajudar as organizações de TI e segurança a gerenciar com eficácia o risco cibernético.
Controle nº 3
FALHA DIFÍCIL
Fornecer evidências de que:
Você tem uma lista aprovada de software/aplicativos com justificativa comercial que:
existe e é mantido atualizado
Cada aplicativo passa por um processo de aprovação e aprovação antes de ser implantado
Essa tecnologia de controle de aplicativo está ativa, habilitada e configurada em linha com a lista de aprovação nos componentes do sistema amostrados.
Intenção: lista de softwares
Este subponto visa garantir que exista uma lista aprovada de software e aplicativos dentro da organização e seja continuamente atualizada. Certifique-se de que cada software ou aplicativo na lista tenha uma justificativa comercial documentada para validar sua necessidade. Essa lista serve como uma referência oficial para regular a implantação de softwares e aplicativos, auxiliando na eliminação de softwares não autorizados ou redundantes que podem representar um risco à segurança.
Diretrizes: lista de softwares
Um documento contendo a lista aprovada de software e aplicativos, se mantido como um documento digital (Word, PDF etc.). Se a lista aprovada de softwares e aplicativos for mantida por meio de uma plataforma, deverão ser fornecidas capturas de tela da lista da plataforma.
Exemplo de evidência: lista de softwares
As próximas capturas de tela demonstram que uma lista de softwares e aplicativos aprovados é mantida na plataforma Confluence Cloud.
As próximas capturas de tela demonstram que a lista de softwares e aplicativos aprovados, incluindo o solicitante, data da solicitação, aprovador, data de aprovação, mecanismo de controle, tíquete JIRA, sistema/ativo, é mantida.
Intenção: aprovação de software
O objetivo deste subponto é confirmar que cada software/aplicativo passa por um processo formal de aprovação antes de sua implantação dentro da organização. O processo de aprovação deve incluir uma avaliação técnica e uma aprovação executiva, garantindo que as perspectivas operacionais e estratégicas tenham sido consideradas. Ao instituir esse processo rigoroso, a organização garante que apenas o software verificado e necessário seja implantado, minimizando assim as vulnerabilidades de segurança e garantindo o alinhamento com os objetivos de negócios.
Diretrizes
Podem ser fornecidas evidências de que o processo de aprovação está sendo seguido. Isso pode ser fornecido por meio de documentos assinados, rastreando dentro dos sistemas de controle de alterações ou usando algo como o Azure DevOps/JIRA para rastrear as solicitações de alteração e autorização.
Exemplo de evidência
As próximas capturas de tela demonstram um processo de aprovação completo no JIRA Software. Uma usuária "Jane Doe" levantou uma solicitação para que "Permitir que o Qualys Cloud Agent" seja instalado nos servidores "IaaS-Web-app" e "IaaS-VM-Backend". "Andrew Smith" analisou a solicitação e a aprovou com o comentário "aprovado com base na necessidade comercial de antimalware". Atualizações e patches fornecidos pela Qualys. Software a ser aprovado.
A próxima captura de tela mostra a aprovação sendo concedida por meio do tíquete gerado na plataforma Confluence antes de permitir que o aplicativo seja executado no servidor de produção.
Intenção: tecnologia de controle de aplicativos
Este subponto se concentra em verificar se a tecnologia de controle de aplicativos está ativa, habilitada e configurada corretamente em todos os componentes do sistema amostrados. Certifique-se de que a tecnologia opere de acordo com políticas e procedimentos documentados, que servem como diretrizes para sua implementação e manutenção. Ao ter uma tecnologia de controle de aplicativos ativa, habilitada e bem configurada, a organização pode ajudar a impedir a execução de software não autorizado ou mal-intencionado e aprimorar a postura geral de segurança do sistema.
Diretrizes: tecnologia de controle de aplicativos
Forneça documentação detalhando como o controle de aplicativos foi configurado e evidências da tecnologia aplicável, mostrando como cada aplicativo/processo foi configurado.
Exemplo de evidência: tecnologia de controle de aplicativos
As próximas capturas de tela demonstram que as Políticas de Grupo (GPO) do Windows estão configuradas para impor apenas softwares e aplicativos aprovados.
A próxima captura de tela mostra o software/aplicativos permitidos para serem executados por meio do controle de caminho.
Observação: nesses exemplos, capturas de tela completas não foram usadas, no entanto, TODAS as capturas de tela de evidências enviadas pelo ISV devem ser capturas de tela inteira mostrando qualquer URL, usuário conectado e a hora e data do sistema.
Gerenciamento de patches/aplicação de patches e classificação de risco
O gerenciamento de patches, geralmente chamado de patching, é um componente crítico de qualquer estratégia robusta de segurança cibernética. Envolve o processo sistemático de identificação, teste e aplicação de patches ou atualizações em software, sistemas operacionais e aplicativos. O objetivo principal do gerenciamento de patches é mitigar vulnerabilidades de segurança, garantindo que os sistemas e softwares permaneçam resilientes contra ameaças potenciais. Além disso, o gerenciamento de patches abrange a classificação de riscos, um elemento vital na priorização de patches. Isso envolve avaliar vulnerabilidades com base em sua gravidade e impacto potencial na postura de segurança de uma organização. Ao atribuir pontuações de risco a vulnerabilidades, as organizações podem alocar recursos de forma eficiente, concentrando seus esforços em abordar vulnerabilidades críticas e de alto risco prontamente, mantendo uma postura proativa contra ameaças emergentes. Uma estratégia eficaz de gerenciamento de patches e classificação de risco não apenas aumenta a segurança, mas também contribui para a estabilidade geral e o desempenho da infraestrutura de TI, ajudando as organizações a permanecerem resilientes no cenário em constante evolução de ameaças à segurança cibernética.
Para manter um ambiente operacional seguro, os aplicativos/complementos e sistemas de suporte devem ser devidamente corrigidos. Um período de tempo adequado entre a identificação (ou lançamento público) e a aplicação de patch precisa ser gerenciado para reduzir a janela de oportunidade para que uma vulnerabilidade seja explorada por um agente de ameaça. A Certificação Microsoft 365 não estipula uma 'Janela de Patch'; No entanto, os analistas de certificação rejeitarão prazos que não sejam razoáveis ou estejam de acordo com as melhores práticas do setor. Esse grupo de controle de segurança também está no escopo de ambientes de hospedagem de PaaS (Plataforma como Serviço), pois o aplicativo/suplemento, as bibliotecas de software de terceiros e a base de código devem ser corrigidas com base na classificação de risco.
Controle nº 4
Fornecer evidências de que:
Uma documentação de política e procedimento de gerenciamento de patches define todos os itens a seguir:
janela de patch mínima adequada para vulnerabilidades de segurança críticas/altas e de médio risco a partir do momento do lançamento do patch do fornecedor ou a partir de quando as vulnerabilidades de codificação sob medida são identificadas pela primeira vez
Descomissionamento de sistemas operacionais e software de aplicativo sem suporte, incluindo dependências de código de terceiros
Detalhes sobre como as vulnerabilidades de segurança notificadas pelo novo fornecedor são identificadas e atribuídas a uma pontuação de risco
O processo para a identificação de notificações de vulnerabilidade de segurança de novos fornecedores e atribuição de uma pontuação de risco está sendo executado.
Intenção: gerenciamento de patches
O gerenciamento de patches é exigido por muitas estruturas de conformidade de segurança, ou seja, PCI-DSS, ISO 27001, NIST (SP) 800-53, FedRAMP e SOC 2. A importância de um bom gerenciamento de patches não pode ser enfatizada demais
pois pode corrigir problemas de segurança e funcionalidade em software, firmware e mitigar vulnerabilidades, o que ajuda na redução de oportunidades de exploração. A intenção desse controle é minimizar a janela de oportunidade que um agente de ameaça tem, para explorar vulnerabilidades que possam existir no ambiente no escopo.
A documentação de política e procedimento de gerenciamento de patches da organização deve definir claramente:
Uma janela mínima de aplicação de patch adequada para vulnerabilidades categorizadas como riscos críticos, altos e médios.
Os prazos de aplicação de patch devem ser baseados na data de lançamento do fornecedor, não quando a organização identifica a vulnerabilidade. Ao definir explicitamente esses prazos, a organização pode padronizar sua abordagem para o gerenciamento de patches, reduzindo o risco associado a vulnerabilidades sem patch.
Descomissionamento de software e sistemas operacionais sem suporte.
A política de gerenciamento de patches inclui disposições para o descomissionamento de software e sistemas operacionais não suportados. Os sistemas operacionais e software que não recebem mais atualizações de segurança representam um risco significativo para a postura de segurança de uma organização. Portanto, esse controle garante que esses sistemas sejam identificados e removidos ou substituídos em tempo hábil, conforme definido na documentação da política.
- Um procedimento documentado que descreve como novas vulnerabilidades de segurança são identificadas e atribuídas a uma pontuação de risco.
A aplicação de patches deve ser baseada no risco, quanto mais arriscada a vulnerabilidade, mais rápido ela precisa ser corrigida. A classificação de risco das vulnerabilidades identificadas é parte integrante desse processo. A intenção desse controle é garantir que haja um processo de classificação de risco documentado que esteja sendo seguido para garantir que todas as vulnerabilidades identificadas sejam adequadamente classificadas com base no risco. As organizações geralmente utilizam a classificação CVSS (Common Vulnerability Scoring System) fornecida por fornecedores ou pesquisadores de segurança. Recomenda-se que, se as organizações confiarem no CVSS, um mecanismo de reclassificação seja incluído no processo para permitir que a organização altere a classificação com base em uma avaliação interna de risco. Às vezes, a vulnerabilidade pode não ser aplicável devido à maneira como o aplicativo foi implantado no ambiente. Por exemplo, uma vulnerabilidade Java pode ser lançada, o que afeta uma biblioteca específica que não é usada pela organização.
Observação: mesmo se você estiver executando em um ambiente puramente de plataforma como serviço 'PaaS/sem servidor', você ainda tem a responsabilidade de identificar vulnerabilidades em sua base de código: ou seja, bibliotecas de terceiros.
Diretrizes: gerenciamento de patches
Forneça o documento de política. Evidências administrativas, como documentação de políticas e procedimentos detalhando os processos definidos pela organização que cobrem todos os elementos para o controle fornecido, devem ser fornecidas.
Observação: essa evidência lógica pode ser fornecida como evidência de suporte que fornecerá mais informações sobre o Programa de Gerenciamento de Vulnerabilidades (VMP) da sua organização, mas não atenderá a esse controle por conta própria.
Exemplo de evidência: gerenciamento de patches
A próxima captura de tela mostra um trecho de uma política de gerenciamento de patches/classificação de risco, bem como os diferentes níveis de categorias de risco. Isso é seguido pelos prazos de classificação e correção. Observação: a expectativa é que os ISVs compartilhem a documentação real da política/procedimento de suporte e não simplesmente forneçam uma captura de tela.
Exemplo de evidência técnica adicional (opcional) que apoia o documento de política
Evidências lógicas, como planilhas de rastreamento de vulnerabilidades, relatórios de avaliação técnica de vulnerabilidades ou capturas de tela de tíquetes gerados por meio de plataformas de gerenciamento online para rastrear o status e o progresso das vulnerabilidades, usadas para apoiar a implementação do processo descrito na documentação de política a ser fornecida. A próxima captura de tela demonstrou que o Snyk, que é uma ferramenta de SCA (Análise de Composição de Software), é usado para verificar vulnerabilidades na base de código. Isso é seguido por uma notificação por email.
Observação: neste exemplo, uma captura de tela completa não foi usada, no entanto, TODAS as capturas de tela de evidências enviadas pelo ISV devem ser capturas de tela completas mostrando qualquer URL, usuário conectado e a hora e data do sistema.
As próximas duas capturas de tela mostram um exemplo da notificação por e-mail recebida quando novas vulnerabilidades são sinalizadas pelo Snyk. Podemos ver que o e-mail contém o projeto afetado e o usuário atribuído para receber os alertas.
A captura de tela a seguir mostra as vulnerabilidades identificadas.
Observação: nos exemplos anteriores, capturas de tela completas não foram usadas, no entanto, TODAS as capturas de tela de evidências enviadas pelo ISV devem ser capturas de tela completas mostrando o URL, qualquer usuário conectado e hora e data do sistema.
Exemplo de evidência
As próximas capturas de tela mostram as ferramentas de segurança do GitHub configuradas e habilitadas para verificar vulnerabilidades na base de código e os alertas são enviados por e-mail.
A notificação por email mostrada a seguir é uma confirmação de que os problemas sinalizados serão resolvidos automaticamente por meio de uma solicitação de pull.
Exemplo de evidência
A próxima captura de tela mostra a avaliação técnica interna e a classificação das vulnerabilidades por meio de uma planilha.
Exemplo de evidência
As próximas capturas de tela mostram tíquetes gerados no DevOps para cada vulnerabilidade descoberta.
A avaliação, classificação e revisão por um funcionário separado ocorre antes da implementação das alterações.
Controle nº 5
FALHA DIFÍCIL
Fornecer evidências de que:
Todos os componentes do sistema de amostra, incluindo o software de aplicativo instalado nas máquinas de amostra e todas as dependências de código de terceiros estão sendo corrigidos.
Sistemas operacionais e software de aplicativo sem suporte, incluindo dependências de código de terceiros, não estão em uso.
Para ambientes PaaS verdadeiros, esse controle só é aplicável a dependências de código de terceiros.
Observação: os ambientes PaaS verdadeiros não devem permitir o acesso administrativo do ISV a nenhum componente baseado em infraestrutura; por exemplo, mas não limitado a, nós do Kubernetes do Windows/Linux.
Intenção: componentes do sistema de amostra
Este subponto visa garantir que evidências verificáveis sejam fornecidas para confirmar que todos os componentes do sistema amostrados dentro da organização estão sendo ativamente corrigidos. As evidências podem incluir, mas não se limitam a, logs de gerenciamento de patches, relatórios de auditoria do sistema ou procedimentos documentados mostrando que os patches foram aplicados. Quando a tecnologia sem servidor ou a PaaS (Plataforma como Serviço) for empregada, isso deve se estender para incluir a base de código para confirmar se as versões mais recentes e seguras de bibliotecas e dependências estão em uso.
Diretrizes: componentes do sistema amostrados
Forneça uma captura de tela para cada dispositivo na amostra e nos componentes de software de suporte mostrando que os patches são instalados de acordo com o processo de aplicação de patch documentado. Além disso, forneça capturas de tela demonstrando a aplicação de patch da base de código.
Exemplo de evidência: componentes do sistema amostrados
A próxima captura de tela demonstra a aplicação de patch de uma máquina virtual do sistema operacional Linux 'IaaS- VM-Backend'. Por favor, veja o exemplo de evidência aceitável mostrando que os pacotes de software instalados são atualizados regularmente usando o gerenciador de pacotes Ubuntu APT. A primeira captura de tela confirma que os repositórios de pacotes do sistema foram atualizados e que todos os pacotes instalados estão atualizados. A segunda captura de tela mostra o log do histórico de pacotes do APT, evidenciando que as atualizações de pacotes foram realizadas regularmente ao longo do tempo. Evidências equivalentes de sua própria distribuição do Linux ou solução de gerenciamento de pacotes também são aceitáveis.
Exemplo de evidência
A próxima captura de tela demonstra a aplicação de patch de uma máquina virtual do sistema operacional Windows 'IaaS-Web-app'.
Observação: Quando as atualizações de software de terceiros em máquinas virtuais do Windows são gerenciadas manualmente (ou seja, não por meio de uma solução centralizada de gerenciamento de patches), você deve fornecer evidências do processo de atualização. Isso deve incluir capturas de tela de todos os softwares de terceiros instalados e seus números de versão para nos permitir verificar se o software está sendo mantido e atualizado de acordo com seu processo de gerenciamento de patches documentado.
Exemplo de evidência
Se você estiver mantendo a aplicação de patch de qualquer outra ferramenta, como Microsoft Intune, Defender para Nuvem etc., as capturas de tela dessas ferramentas poderão ser fornecidas. As próximas capturas de tela da solução OpenEDR demonstram que o gerenciamento de patches é realizado por meio do portal OpenEDR.
A próxima captura de tela demonstra que o gerenciamento de patches do servidor no escopo é feito por meio da plataforma OpenEDR. A classificação e o status são visíveis abaixo, demonstrando que a aplicação de patch ocorre.
A próxima captura de tela mostra que os logs são gerados para os patches instalados com sucesso no servidor.
Exemplo de evidência
A próxima captura de tela demonstra que as dependências da base de código/biblioteca de terceiros são corrigidas por meio do Azure DevOps.
A próxima captura de tela mostra que uma correção para vulnerabilidades descobertas por Snyk está sendo confirmada no branch para resolver bibliotecas desatualizadas.
A próxima captura de tela demonstra que as bibliotecas foram atualizadas para versões compatíveis.
Exemplo de evidência
As próximas capturas de tela demonstram que a aplicação de patch da base de código é mantida por meio do GitHub Dependabot. Os itens fechados demonstram que a aplicação de patch ocorre e as vulnerabilidades foram resolvidas.
Intenção: sistema operacional sem suporte
O software que não está sendo mantido por fornecedores sofrerá, com o tempo, vulnerabilidades conhecidas que não são corrigidas. Portanto, o uso de sistemas operacionais e componentes de software sem suporte não deve ser usado em ambientes de produção. Quando a IaaS (Infraestrutura como Serviço) é implantada, o requisito para esse subponto se expande para incluir a infraestrutura e a base de código para garantir que todas as camadas da pilha de tecnologia estejam em conformidade com a política da organização sobre o uso de software com suporte.
Diretrizes: sistema operacional sem suporte
Forneça uma captura de tela para cada dispositivo no conjunto de amostras escolhido pelo seu analista para você coletar evidências contra a exibição da versão do sistema operacional em execução (inclua o nome do dispositivo/servidor na captura de tela). Além disso, forneça evidências de que os componentes de software em execução no ambiente estão executando versões compatíveis do software. Isso pode ser feito fornecendo a saída de relatórios de verificação de vulnerabilidade interna (desde que a verificação autenticada esteja incluída) e/ou a saída de ferramentas que marcam bibliotecas de terceiros, como Snyk, Trivy ou NPM Audit. Se estiver executando em PaaS, somente a aplicação de patch de bibliotecas de terceiros precisará ser abordada.
Exemplo de evidência: sistema operacional sem suporte
A próxima captura de tela da auditoria do NPM do DevOps do Azure demonstra que nenhuma biblioteca/dependência sem suporte é utilizada no aplicativo Web.
Observação: no próximo exemplo, uma captura de tela completa não foi usada, no entanto, TODAS as capturas de tela de evidências enviadas pelo ISV devem ser capturas de tela completas mostrando o URL, qualquer usuário conectado e hora e data do sistema.
Exemplo de evidência
A próxima captura de tela do GitHub Dependabot demonstra que nenhuma biblioteca/dependência é utilizada no aplicativo Web.
Exemplo de evidência
A próxima captura de tela do inventário de software para sistema operacional Windows via OpenEDR demonstra que nenhuma versão de sistema operacional e software desatualizada ou sem suporte foi encontrada.
Exemplo de evidência
A próxima captura de tela é do OpenEDR no Resumo do sistema operacional mostrando o Windows Server 2019 Datacenter (x64) e o histórico completo da versão do sistema operacional, incluindo service pack, versão de compilação, etc ... validar que nenhum sistema operacional sem suporte foi encontrado.
Exemplo de evidência
A próxima captura de tela de um servidor com sistema operacional Linux demonstra todos os detalhes da versão, incluindo a ID do Distribuidor, a Descrição, a Versão e o Codinome, validando que nenhum sistema operacional Linux sem suporte foi encontrado.
Exemplo de evidência:
A próxima captura de tela do relatório de verificação de vulnerabilidades do Nessus demonstra que nenhum sistema operacional (SO) e software não suportados foram encontrados na máquina de destino.
Observação: nos exemplos anteriores, uma captura de tela completa não foi usada, no entanto, TODAS as capturas de tela de evidências enviadas pelo ISV devem ser capturas de tela completas mostrando o URL, qualquer usuário conectado e hora e data do sistema.
Verificação de vulnerabilidade
A verificação de vulnerabilidades procura possíveis pontos fracos no sistema de computador, redes e aplicativos da web de uma organização para identificar brechas que podem levar a violações de segurança e à exposição de dados confidenciais. A verificação de vulnerabilidades geralmente é exigida pelos padrões do setor e regulamentos governamentais, por exemplo, o PCI DSS (Segurança de Dados do Setor de Cartões de Pagamento Standard).
Um relatório da Security Metric intitulado "Guia de métricas de segurança de 2020 para conformidade com o PCI DSS" afirma que "em média, demorou 166 dias a partir do momento em que uma organização foi vista como tendo vulnerabilidades para um invasor comprometer o sistema. Uma vez comprometidos, os invasores tiveram acesso a dados confidenciais por uma média de 127 dias, portanto, esse controle visa identificar possíveis pontos fracos de segurança dentro do ambiente no escopo.
Ao introduzir avaliações regulares de vulnerabilidade, as organizações podem detectar pontos fracos e inseguranças em seus ambientes, o que pode fornecer um ponto de entrada para um agente mal-intencionado comprometer o ambiente. A verificação de vulnerabilidades pode ajudar a identificar patches ausentes ou configurações incorretas no ambiente. Ao realizar regularmente essas verificações, uma organização pode fornecer a correção apropriada para minimizar o risco de um comprometimento devido a problemas que são comumente detectados por essas ferramentas de verificação de vulnerabilidades.
Controle nº 6
Fornecer evidências de que:
A verificação trimestral de infraestrutura externa e vulnerabilidade de aplicativo Web/API é realizada.
E se Híbrido, Local ou IaaS também fornecer evidências de que:
A verificação precisa ser realizada em relação a todo o volume público (IPs/URLs) e intervalos de IP internos se o ambiente for IaaS, híbrido ou local.
Observação: Isso deve incluir todo o escopo do ambiente.
Intenção: verificação de vulnerabilidades
Esse controle visa garantir que a organização realize uma verificação de vulnerabilidades trimestralmente, visando tanto sua infraestrutura quanto seus aplicativos da web. A verificação deve ser abrangente, abrangendo tanto pegadas públicas, como IPs públicos e URLs, quanto intervalos de IP internos. O escopo da verificação varia de acordo com a natureza da infraestrutura da organização:
Se uma organização implementar modelos híbridos, locais ou de IaaS (Infraestrutura como Serviço), a verificação deverá abranger IPs/URLs públicos externos e intervalos de IP internos.
Se uma organização implementar a PaaS (Plataforma como Serviço), a verificação deverá abranger apenas IPs/URLs públicos externos.
Esse controle também exige que a verificação inclua todo o escopo do ambiente, não deixando nenhum componente desmarcado. O objetivo é identificar e avaliar vulnerabilidades em todas as partes da pilha de tecnologia da organização para garantir uma segurança abrangente.
Diretrizes: verificação de vulnerabilidades
Forneça o(s) relatório(s) de verificação completo para as verificações de vulnerabilidade de cada trimestre que foram realizadas nos últimos 12 meses. Os relatórios devem indicar claramente os destinos para validar se a pegada pública completa está incluída e, quando aplicável, cada sub-rede interna. Forneça TODOS os relatórios de verificação para CADA trimestre.
Exemplo de evidência: verificação de vulnerabilidade
A próxima captura de tela mostra uma descoberta de rede e um escaneamento de porta realizado via Nmap na infraestrutura Externa para identificar quaisquer portas abertas não seguras.
Nota: O Nmap por si só não pode ser utilizado para atender a esse controle, pois a expectativa é que uma verificação completa de vulnerabilidade seja fornecida. A descoberta da porta Nmap faz parte do processo de gerenciamento de vulnerabilidades exemplificado abaixo e é complementada por varreduras OpenVAS e OWASP ZAP na infraestrutura externa.
A captura de tela mostra a verificação de vulnerabilidades via OpenVAS em relação à infraestrutura externa para identificar quaisquer configurações incorretas e vulnerabilidades pendentes.
A próxima captura de tela mostra o relatório de verificação de vulnerabilidade do OWASP ZAP demonstrando testes dinâmicos de segurança de aplicativos.
Exemplo de evidência: verificação de vulnerabilidade
As capturas de tela a seguir do relatório de verificação de vulnerabilidades do Tenable Nessus Essentials demonstram que a verificação interna da infraestrutura é realizada.
As capturas de tela anteriores demonstram a configuração de pastas para verificações trimestrais nas VMs do host.
As capturas de tela acima e abaixo mostram a saída do relatório de verificação de vulnerabilidade.
A próxima captura de tela mostra a continuação do relatório cobrindo todos os problemas encontrados.
Controle nº 7
FALHA DIFÍCIL
Forneça evidências de nova análise de que:
- A correção de todas as vulnerabilidades identificadas no controle anterior é corrigida em linha com a janela mínima de aplicação de patch definida em sua política.
Intenção: aplicação de patch
A falha em identificar, gerenciar e corrigir vulnerabilidades e configurações incorretas rapidamente pode aumentar o risco de uma organização de um comprometimento, levando a possíveis violações de dados. Identificar e corrigir corretamente os problemas é visto como importante para a postura e o ambiente de segurança geral de uma organização, o que está de acordo com as melhores práticas de várias estruturas de segurança, por exemplo, ISO 27001 e PCI DSS.
A intenção desse controle é garantir que a organização forneça evidências confiáveis de novas verificações, demonstrando que todas as vulnerabilidades identificadas em um Controle 6 foram corrigidas. A correção deve estar alinhada com a janela mínima de aplicação de patch definida na política de gerenciamento de patches da organização.
Diretrizes: aplicação de patch
Forneça relatórios de nova verificação validando se todas as vulnerabilidades identificadas no controle 6 foram corrigidas de acordo com as janelas de correção definidas no controle 4.
Exemplo de evidência: aplicação de patch
A próxima captura de tela mostra uma verificação do Nessus do ambiente no escopo (uma única máquina neste exemplo chamada Thor) mostrando vulnerabilidades nodia 2 de agosto de 2023.
A próxima captura de tela mostra que os problemas foram resolvidos 2 dias depois, o que está dentro da janela de aplicação de patch definida na política de aplicação de patch.
Observação: nos exemplos anteriores, uma captura de tela completa não foi usada, no entanto, TODOS os ISV enviaram
As capturas de tela de evidência devem ser capturas de tela completas mostrando qualquer URL, usuário conectado e a hora e data do sistema.
NSC (Controles de Segurança de Rede)
Os controles de segurança de rede são um componente essencial das estruturas de segurança cibernética, como ISO 27001, controles CIS e NIST Cybersecurity Framework. Eles ajudam as organizações a gerenciar riscos associados a ameaças cibernéticas, proteger dados confidenciais contra acesso não autorizado, cumprir requisitos regulatórios, detectar e responder a ameaças cibernéticas em tempo hábil e garantir a continuidade dos negócios. A segurança de rede eficaz protege os ativos organizacionais contra uma ampla gama de ameaças de dentro ou de fora da organização.
Controle nº 8
FALHA DIFÍCIL
Fornecer evidências de que:
Os NSCs (Controles de Segurança de Rede) são instalados no limite do ambiente no escopo, como:
entre a Internet e o ambiente no escopo e/ou
entre redes ou sistemas menos confiáveis e o ambiente no escopo.
E se Híbrido, Local ou IaaS também fornecer evidências de que:
- Quando aplicável, todos os componentes do sistema com endereços IP públicos são segmentados adequadamente de todos os outros componentes internos do sistema usando NSCs.
Observação: NSCs referem-se a Firewalls, NSGs (Grupos de Segurança de Rede), SGs (Grupos de Segurança), WAFs, etc. Para esse controle, os NSCs são tecnologias que controlam o fluxo de tráfego entre redes ou sistemas com diferentes níveis de confiança de segurança, ou seja, uma DMZ e a rede interna, uma rede pública e a rede interna, um servidor web frontal e um servidor de banco de dados.
Intenção: NSC
Esse controle tem como objetivo confirmar se os NSCs (Controles de Segurança de Rede) estão instalados em locais-chave dentro da topologia de rede da organização. Especificamente, os NSCs devem ser colocados no limite do ambiente no escopo e entre a rede de perímetro e as redes internas. A intenção desse controle é confirmar se esses mecanismos de segurança estão corretamente situados para maximizar sua eficácia na proteção dos ativos digitais da organização.
Diretrizes: NSC
Evidências devem ser fornecidas para demonstrar que os NSC (Controles de Segurança de Rede) estão instalados no limite e configurados entre o perímetro e as redes internas. Isso pode ser feito fornecendo as capturas de tela das definições de configuração do NSC (Controles de Segurança de Rede) e o escopo ao qual ele é aplicado, por exemplo, um firewall ou tecnologia equivalente, como NSGs (Grupos de Segurança de Rede) Azure Azure Front Door etc.
Exemplo de evidência: NSC
A próxima captura de tela é do aplicativo Web 'PaaS-web-app'; o blade de rede demonstra que todo o tráfego de entrada está passando pelo Azure Front Door, enquanto todo o tráfego do aplicativo para outros recursos do Azure é roteado e filtrado por meio do NSG do Azure por meio da integração VNET.
As regras de negação dentro das "Restrições de acesso" impedem qualquer entrada, exceto do Front Door (FD), o tráfego é roteado por FD antes de chegar ao aplicativo.
Exemplo de evidência: NSC
A captura de tela a seguir mostra a rota padrão do Azure Front Door e que o tráfego é roteado pelo Front Door antes de chegar ao aplicativo. A política WAF também foi aplicada.
Exemplo de evidência: NSC
A primeira captura de tela mostra um Grupo de Segurança de Rede do Azure aplicado no nível VNET para filtrar o tráfego de entrada e saída. A segunda captura de tela demonstra que o SQL Server não é roteável pela Internet e é integrado por meio da VNET e por meio de um link privado.
Isso garante que o tráfego interno e a comunicação sejam filtrados pelo NSG antes de chegar ao SQL server.
Intenção**:** híbrido, local, IaaS
Esse subponto é essencial para organizações que operam modelos híbridos, locais ou de IaaS (infraestrutura como serviço). Procura garantir que todo o acesso público termine na rede perimetral, o que é crucial para controlar os pontos de entrada na rede interna e reduzir a exposição potencial a ameaças externas. As evidências de conformidade podem incluir configurações de firewall, listas de controle de acesso à rede ou outra documentação semelhante que possa fundamentar a alegação de que o acesso público não se estende além da rede de perímetro.
Exemplo de evidência: híbrido, local, IaaS
A captura de tela demonstra que o SQL Server não é roteável pela Internet e é integrado por meio da VNET e por meio de um link privado. Isso garante que apenas o tráfego interno seja permitido.
Exemplo de evidência: híbrido, local, IaaS
As próximas capturas de tela demonstram que a segmentação de rede está em vigor na rede virtual no escopo. A VNET, conforme mostrado a seguir, é dividida em três sub-redes, cada uma com um NSG aplicado.
A sub-rede pública atua como a rede de perímetro. Todo o tráfego público é roteado por meio dessa sub-rede e filtrado pelo NSG com regras específicas e somente o tráfego definido explicitamente é permitido. O back-end consiste em uma sub-rede privada sem acesso público. Todo o acesso à VM é permitido somente por meio do Bastion Host, que tem seu próprio NSG aplicado no nível da sub-rede.
A próxima captura de tela mostra que o tráfego é permitido da Internet para um endereço IP específico somente na porta 443. Além disso, o RDP é permitido somente do intervalo de IP do Bastion para a rede virtual.
A próxima captura de tela demonstra que o back-end não é roteável pela Internet (isso ocorre porque não há IP público para a NIC) e que o tráfego só tem permissão para se originar da Rede Virtual e do Bastion.
A captura de tela demonstra que o host do Azure Bastion é usado para acessar as máquinas virtuais apenas para fins de manutenção.
Controle nº 9
Fornecer evidências de que:
Todos os NSC (Controles de Segurança de Rede) são configurados para descartar o tráfego não definido explicitamente na base de regras.
As revisões de regras do NSC são realizadas pelo menos a cada seis (6) meses.
Intenção: NSC
Esse subponto garante que todos os NSC (Controles de Segurança de Rede) em uma organização estejam configurados para descartar qualquer tráfego de rede que não esteja explicitamente definido em sua base de regras. O objetivo é impor o princípio de privilégios mínimos na camada de rede, permitindo apenas tráfego autorizado enquanto bloqueia todo o tráfego não especificado ou potencialmente mal-intencionado.
Diretrizes: NSC
As evidências fornecidas para isso podem ser configurações de regras que mostram as regras de entrada e onde essas regras são encerradas; roteando endereços IP públicos para os recursos ou fornecendo a NAT (Network Address Translation) do tráfego de entrada.
Exemplo de evidência: NSC
A captura de tela mostra a configuração do NSG, incluindo o conjunto de regras padrão e uma regra Deny:All personalizada para redefinir todas as regras padrão do NSG e garantir que todo o tráfego seja proibido. Nas regras personalizadas adicionais, a regra Deny:All define explicitamente o tráfego permitido.
Exemplo de evidência: NSC
As capturas de tela a seguir mostram que o Front Door do Azure está implantado e todo o tráfego é roteado pelo Front Door. É aplicada uma Política de WAF no "Modo de Prevenção" que filtra o tráfego de entrada em busca de possíveis cargas mal-intencionadas e o bloqueia.
Intenção: NSC
Sem revisões regulares, o NSC (Controles de Segurança de Rede) pode se tornar desatualizado e ineficaz, deixando uma organização vulnerável a ataques cibernéticos. Isso pode resultar em violações de dados, roubo de informações confidenciais e outros incidentes de segurança cibernética. As revisões regulares do NSC são essenciais para gerenciar riscos, proteger dados confidenciais, cumprir os requisitos regulatórios, detectar e responder a ameaças cibernéticas em tempo hábil e garantir a continuidade dos negócios. Esse subponto exige que os NSCs (Controles de Segurança de Rede) passem por revisões de base de regras pelo menos a cada seis meses. Revisões regulares são cruciais para manter a eficácia e a relevância das configurações do NSC, especialmente em ambientes de rede que mudam dinamicamente.
Diretrizes: NSC
Qualquer evidência fornecida precisa ser capaz de demonstrar que as reuniões de revisão de regras estão ocorrendo. Isso pode ser feito compartilhando as atas da reunião da revisão do NSC e qualquer evidência adicional de controle de alterações que mostre quaisquer ações tomadas na revisão. Certifique-se de que as datas estejam presentes, pois o analista de certificação que revisa seu envio precisaria ver no mínimo dois desses documentos de revisão de reuniões (ou seja, a cada seis meses).
Exemplo de evidência: NSC
Essas capturas de tela demonstram que existem revisões semestrais do firewall e os detalhes são mantidos na plataforma Confluence Cloud.
A próxima captura de tela demonstra que toda revisão de regra tem uma página criada no Confluence. A revisão de regra contém uma lista de conjuntos de regras aprovadas descrevendo o tráfego permitido, o número da porta, o protocolo, etc., juntamente com a justificativa comercial.
Exemplo de evidência: NSC
A próxima captura de tela demonstra um exemplo alternativo de revisão de regras de seis meses sendo mantida no DevOps.
Exemplo de evidência: NSC
Esta captura de tela demonstra um exemplo de uma revisão de regra sendo executada e registrada como um tíquete no DevOps.
A captura de tela anterior mostra a lista de regras documentadas estabelecidas junto com a justificativa comercial, enquanto a próxima imagem demonstra um snapshot das regras dentro do ticket do sistema real.
Controle de alterações
Um processo de controle de mudanças estabelecido e compreendido é essencial para garantir que todas as mudanças passem por um processo estruturado e repetível. Ao garantir que todas as mudanças passem por um processo estruturado, as organizações podem garantir que as mudanças sejam gerenciadas com eficácia, revisadas por pares e testadas adequadamente antes de serem aprovadas. Isso não só ajuda a minimizar o risco de interrupções do sistema, mas também ajuda a minimizar o risco de possíveis incidentes de segurança por meio da introdução de alterações inadequadas.
Controle nº 10
Fornecer evidências de que:
Todas as alterações introduzidas nos ambientes de produção são implementadas por meio de solicitações de alteração documentadas que contêm:
Impacto da alteração na segurança
Detalhes de quaisquer procedimentos de retirada
detalhes dos testes a serem realizados para garantir que a mudança tenha sido implementada com segurança
aprovação por pessoal autorizado
Observação: as alterações incluem todas as alterações no ambiente, por exemplo, infraestrutura, configurações de ambiente (ou seja, nuvem/aplicativos/etc.) e alterações de código.
Intenção: controle de alterações
A intenção desse controle é garantir que todas as alterações solicitadas tenham sido cuidadosamente consideradas e documentadas. Isso inclui avaliar o impacto da alteração na segurança do sistema/ambiente, documentar quaisquer procedimentos de retirada para ajudar na recuperação se algo der errado e detalhar os testes necessários para validar o sucesso da alteração.
Devem ser implementados processos que proíbam a realização de alterações sem a devida autorização e aprovação. A alteração precisa ser autorizada antes de ser implementada e a alteração precisa ser assinada quando concluída. Isso garante que as solicitações de alteração tenham sido revisadas corretamente e que alguém com autoridade tenha assinado a alteração.
Diretrizes: controle de alterações
As evidências podem ser fornecidas compartilhando capturas de tela de uma amostra de solicitações de mudança demonstrando que os detalhes do impacto da mudança, procedimentos de back-out e testes são mantidos na solicitação de mudança.
Exemplo de evidência: controle de alterações
A captura de tela a seguir mostra um exemplo de solicitação de alteração de infraestrutura gerada no Jira para a implementação de um WAF (Azure Firewall de Aplicativo Web) no ambiente de aplicativos de produção da Contoso Ltd. A seção Visão geral documenta a finalidade e o escopo da alteração, juntamente com o impacto de segurança associado.
A captura de tela a seguir mostra a mesma solicitação de alteração de infraestrutura aprovada no Jira, realçando o Plano de Retirada. Esta seção documenta os procedimentos de reversão que serão seguidos caso a implementação falhe ou introduza problemas imprevistos. O plano de back-out inclui as etapas necessárias para restaurar a configuração de produção anterior, valida a disponibilidade do serviço após a reversão e identifica a equipe responsável pela execução do procedimento.
A captura de tela a seguir mostra o Plano de Teste associado à solicitação de alteração de infraestrutura aprovada. O plano de teste detalha as atividades de validação funcional e de segurança que serão realizadas antes e depois da implantação para garantir que a mudança tenha sido implementada com segurança. Isso inclui validação de configuração, teste de segurança, teste funcional, validação de log e monitoramento, teste de desempenho e verificação pós-implantação, juntamente com os critérios de sucesso definidos para cada atividade.
A captura de tela a seguir mostra a seção Aprovações da mesma solicitação de alteração de infraestrutura. Isso demonstra que a mudança foi formalmente revisada e aprovada pelo pessoal autorizado antes da implementação. O registro de aprovação inclui o nome, a função, o status de aprovação, a data de aprovação e os comentários de suporte do aprovador, juntamente com a janela de implementação planejada para a alteração de produção.
Exemplo de evidência
As próximas capturas de tela mostram um exemplo de tíquete do Jira mostrando que a alteração precisa ser autorizada antes de ser implementada e aprovada por alguém que não seja o desenvolvedor/solicitante. As alterações são aprovadas por alguém com autoridade. A direita da captura de tela mostra que a alteração foi assinada pelo DP depois de concluída.
Observação: - No exemplo acima, uma captura de tela completa não foi usada, no entanto, TODAS as capturas de tela de evidências enviadas pelo ISV devem ser capturas de tela completas mostrando qualquer URL, usuário conectado e a hora e data do sistema.
Controle nº 11
FALHA DIFÍCIL
Fornecer evidências de que:
Existe um ambiente separado para que:
os ambientes de desenvolvimento e teste/preparo são isolados do ambiente de produção por meio de NSCs.
Os ambientes de desenvolvimento e teste/preparo impõem a separação de tarefas do ambiente de produção por meio de controles de acesso.
Os dados de produção confidenciais não são usados nos ambientes de desenvolvimento ou teste/preparo.
Intenção: ambientes separados
Os ambientes de desenvolvimento/teste da maioria das organizações não sã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, pois isso pode introduzir problemas de segurança ou prejudicar a prestação de serviços aos clientes. Ao manter ambientes separados que impõem uma separação de tarefas, as organizações podem garantir que as alterações sejam aplicadas aos ambientes corretos, reduzindo assim o risco de erros ao implementar alterações nos ambientes de produção quando se destina ao ambiente de desenvolvimento/teste.
Os controles de acesso devem ser configurados de forma que o pessoal responsável pelo desenvolvimento e teste não tenha acesso desnecessário ao ambiente de produção e vice-versa. Isso minimiza o potencial de alterações não autorizadas ou exposição de dados.
O uso de dados de produção em ambientes de desenvolvimento/teste pode aumentar o risco de comprometimento e expor a organização a violações de dados ou acesso não autorizado. A intenção exige que todos os dados usados para desenvolvimento ou teste sejam limpos, anonimizados ou gerados especificamente para esse fim.
Diretrizes: ambientes separados
Podem ser fornecidas capturas de tela que demonstram diferentes ambientes sendo usados para ambientes de desenvolvimento/teste e ambientes de produção. Normalmente, você teria pessoas/equipes diferentes com acesso a cada ambiente ou, quando isso não for possível, os ambientes utilizariam serviços de autorização diferentes para garantir que os usuários não possam fazer logon por engano no ambiente errado para aplicar alterações.
Exemplo de evidência: ambientes separados
As próximas capturas de tela demonstram que os ambientes de desenvolvimento/teste são separados da produção, isso é obtido por meio de Grupos de Recursos no Azure, que é uma maneira de agrupar recursos de forma lógica em um contêiner. Outras maneiras de obter a separação podem ser diferentes Assinaturas do Azure, Rede e Sub-redes etc.
A captura de tela a seguir mostra o ambiente de desenvolvimento e os recursos dentro desse grupo de recursos.
A próxima captura de tela mostra o ambiente de produção e os recursos dentro desse grupo de recursos.
Exemplo de evidência:
As próximas capturas de tela demonstram que os ambientes para desenvolvimento/teste são separados do ambiente de produção. A separação adequada de ambientes é obtida por meio de diferentes usuários/grupos com diferentes permissões associadas a cada ambiente.
A próxima captura de tela mostra o ambiente de desenvolvimento e os usuários com acesso a esse grupo de recursos.
A próxima captura de tela mostra o ambiente de produção e os usuários (diferente do ambiente de desenvolvimento) que têm acesso a esse grupo de recursos.
Diretrizes:
As evidências podem ser fornecidas compartilhando capturas de tela da saída da mesma consulta SQL em um banco de dados de produção (redigir todas as informações confidenciais) e no banco de dados de desenvolvimento/teste. A saída dos mesmos comandos deve produzir conjuntos de dados diferentes. Onde os arquivos estão sendo armazenados, a visualização do conteúdo das pastas em ambos os ambientes também deve demonstrar conjuntos de dados diferentes.
Exemplo de evidência
A captura de tela mostra os três principais registros (para envio de evidências, forneça os 20 principais) do banco de dados de produção.
A próxima captura de tela mostra a mesma consulta do Banco de Dados de Desenvolvimento, mostrando registros diferentes.
Observação: neste exemplo, uma captura de tela completa não foi usada, no entanto, TODAS as capturas de tela de evidências enviadas pelo ISV devem ser capturas de tela completas mostrando o URL, qualquer usuário conectado e hora e data do sistema.
Desenvolvimento/implantação segura de software
As organizações envolvidas em atividades de desenvolvimento de software geralmente enfrentam prioridades concorrentes entre as pressões de segurança e TTM (Time to Market), no entanto, a implementação de atividades relacionadas à segurança em todo o ciclo de vida de desenvolvimento de software (SDLC) pode não apenas economizar dinheiro, mas também economizar tempo. Quando a segurança é deixada em segundo plano, os problemas geralmente são identificados apenas durante a fase de teste do (DSLC), que geralmente pode ser mais demorado e caro para corrigir. A intenção desta seção de segurança é garantir que práticas seguras de desenvolvimento de software sejam seguidas para reduzir o risco de falhas de codificação serem introduzidas no software desenvolvido. Além disso, esta seção procura incluir alguns controles para ajudar na implantação segura de software.
Controle nº 12
Fornecer evidências de que:
A Política/Padrões existe e é mantida que:
dá suporte ao desenvolvimento de software seguro e inclui padrões do setor e/ou práticas recomendadas para codificação segura, como Open Web Application Security Project (OWASP) Top 10 ou SysAdmin, Auditoria, Rede e Segurança (SANS) 25 Principais Enumeração de Fraqueza Comum (CWE)
Os desenvolvedores passam por treinamento relevante em Codificação Segura e Desenvolvimento de Software Seguro, abrangendo padrões do setor e/ou práticas recomendadas para codificação segura pelo menos anualmente.
Todos os desenvolvedores passaram por treinamento adequado de codificação de segurança e desenvolvimento de software pelo menos uma vez por ano.
Intenção: desenvolvimento seguro
As organizações precisam fazer tudo ao seu alcance para garantir que o software seja desenvolvido com segurança e livre de vulnerabilidades. Em um melhor esforço para conseguir isso, um ciclo de vida de desenvolvimento de software seguro (SDLC) robusto e práticas recomendadas de codificação segura devem ser estabelecidas 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.
Existem práticas e técnicas recomendadas de codificação para todas as linguagens de programação para garantir que o código seja desenvolvido com segurança. Existem cursos de treinamento externos projetados para ensinar aos desenvolvedores os diferentes tipos de vulnerabilidades de software, aulas e as técnicas de codificação que podem ser usadas para impedir a introdução dessas vulnerabilidades no software. A intenção desse controle também é ensinar essas técnicas a todos os desenvolvedores e garantir que essas técnicas não sejam esquecidas, ou que novas técnicas sejam aprendidas realizando-as anualmente.
Diretrizes: desenvolvimento seguro
Fornecer o SDLC documentado e/ou a documentação de suporte que demonstra que um ciclo de vida de desenvolvimento seguro está em uso e que são fornecidas diretrizes para que todos os desenvolvedores promovam as melhores práticas de codificação segura. Dê uma olhada no OWASP no SDLC e no Modelode Maturidade do OWASP Software Assurance (SAMM).
Exemplo de evidência: desenvolvimento seguro
Um exemplo do documento de política de Desenvolvimento de Software Seguro é mostrado abaixo. A seguir, um trecho do Procedimento de Desenvolvimento de Software Seguro da Contoso, que demonstra práticas seguras de desenvolvimento e codificação.
Observação: nos exemplos anteriores, capturas de tela completas não foram usadas, no entanto, TODAS as capturas de tela de evidências enviadas por ISV devem ser capturas de tela completas mostrando qualquer URL, usuário conectado e a hora e data do sistema.
Diretrizes: treinamento de desenvolvimento seguro
Forneça evidências por meio de certificados se o treinamento for realizado por uma empresa de treinamento externa ou fornecendo capturas de tela dos diários de treinamento ou outros artefatos que demonstrem que os desenvolvedores participaram do treinamento. Se esse treinamento for realizado por meio de recursos internos, forneça evidências do material de treinamento também.
Exemplo de evidência: treinamento de desenvolvimento seguro
A próxima captura de tela é um email solicitando que a equipe de DevOps seja inscrita no Treinamento Anual dos Dez Principais Treinamentos da OWASP.
A próxima captura de tela mostra que o treinamento foi solicitado com justificativa e aprovação comerciais. Isso é seguido por capturas de tela tiradas do treinamento e um registro de conclusão mostrando que a pessoa concluiu o treinamento anual.
Observação: neste exemplo, uma captura de tela completa não foi usada, no entanto, TODAS as capturas de tela de evidências enviadas pelo ISV devem ser capturas de tela completas mostrando o URL, qualquer usuário conectado e hora e data do sistema.
Controle nº 13
Fornecer evidências de que:
Os repositórios de código são protegidos para que:
Todas as alterações de código passam por um processo de revisão e aprovação por um segundo revisor antes de serem mescladas com a ramificação principal
controles de acesso apropriados estão em vigor
todo o acesso é imposto por meio da autenticação multifator (MFA).
Todas as versões feitas nos ambientes de produção são aprovadas antes de sua implantação.
Intenção: revisão de código
A intenção com este subponto é realizar uma revisão de código por outro desenvolvedor 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 sejam realizadas, os testes sejam feitos, etc. antes da implantação. A etapa de autorização valida que os processos corretos foram seguidos, o que sustenta o SDLC definido no controle 12.
O objetivo é garantir que todas as alterações de código passem por um rigoroso processo de revisão e aprovação por um segundo revisor antes de serem mescladas na ramificação principal. Esse processo de dupla aprovação serve como uma medida de controle de qualidade, com o objetivo de detectar quaisquer erros de codificação, vulnerabilidades de segurança ou outros problemas que possam comprometer a integridade do aplicativo.
Diretrizes: revisão de código
Forneça evidências de que o código passa por uma revisão por pares e deve ser autorizado antes de poder ser aplicado ao ambiente de produção. Essa evidência pode ser por meio de uma exportação de tíquetes de alteração, demonstrando que as revisões de código foram realizadas e as alterações autorizadas, ou pode ser por meio de um software de revisão de código, como o Crucible
Exemplo de evidência: revisão de código
O seguinte é um ticket que mostra as alterações de código submetidas a um processo de revisão e autorização por alguém que não seja o desenvolvedor original. Ele mostra que uma revisão de código foi solicitada pelo destinatário e será atribuída a outra pessoa para a revisão de código.
A próxima imagem mostra que a revisão de código foi atribuída a alguém que não seja o desenvolvedor original, conforme mostrado pela seção realçada no lado direito da imagem. No lado esquerdo, o código foi revisado e recebeu um status 'PASS CODE REVIEW' pelo revisor de código. O tíquete agora deve obter a aprovação de um gerente antes que as alterações possam ser colocadas em sistemas de produção ao vivo.
A imagem a seguir mostra que o código revisado foi aprovado para ser implementado nos sistemas de produção ao vivo. Depois que as alterações de código forem feitas, o trabalho final será aprovado. Observe que, durante todo o processo, há três pessoas envolvidas, o desenvolvedor original do código, o revisor de código e um gerente para dar a aprovação e assinar. Para atender aos critérios desse controle, seria uma expectativa que seus tickets seguissem esse processo.
Observação: neste exemplo, uma captura de tela completa não foi usada, no entanto, TODAS as capturas de tela de evidências enviadas pelo ISV devem ser capturas de tela completas mostrando o URL, qualquer usuário conectado e hora e data do sistema.
Exemplo de evidência: revisão de código
Além da parte administrativa do processo mostrada acima, com repositórios de código e plataformas modernas, controles adicionais, como revisão de imposição de política de branch, podem ser implementados para garantir que as mesclagens não possam ocorrer até que essa revisão seja concluída. O exemplo a seguir mostra isso sendo obtido no DevOps.
A próxima captura de tela mostra que os revisores padrão são atribuídos e a revisão é necessária automaticamente.
Exemplo de evidência: revisão de código
A revisão de imposição de política de branch também pode ser obtida no Bitbucket.
Na próxima captura de tela em que um revisor padrão é definido. Isso garante que qualquer mesclagem exigirá uma revisão do indivíduo atribuído antes que a alteração seja propagada para o branch principal.
As duas capturas de tela subsequentes demonstram um exemplo das definições de configuração que estão sendo aplicadas. Bem como uma solicitação pull concluída, que foi iniciada pelo usuário Silvester e exigiu a aprovação do revisor padrão Andrew antes de ser mesclada com o branch principal.
Observe que, quando as evidências forem fornecidas, a expectativa será que o processo de ponta a ponta seja demonstrado. Observação: as capturas de tela devem ser fornecidas mostrando as definições de configuração se uma política de branch estiver em vigor (ou algum outro método/controle programático) e tíquetes/registros de aprovação sendo concedidos.
Intenção: acesso restrito
A partir do controle anterior, os controles de acesso devem ser implementados para limitar o acesso apenas a usuários individuais que estão trabalhando em projetos específicos. Ao limitar o acesso, você pode limitar o risco de alterações não autorizadas serem realizadas e, assim, introduzir alterações de código inseguras. Uma abordagem com privilégios mínimos deve ser adotada para proteger o repositório de código.
Diretrizes: acesso restrito
Forneça evidências por meio de capturas de tela do repositório de código de que o acesso é restrito a indivíduos necessários, incluindo diferentes privilégios.
Exemplo de evidência: acesso restrito
As próximas capturas de tela mostram os controles de acesso que foram implementados no Azure DevOps. A "Equipe CloudDemo" é mostrada como tendo dois membros, e cada membro tem permissões diferentes.
Observação: as próximas capturas de tela mostram um exemplo do tipo de evidência e formato que se espera que atendam a esse controle. Isso não é extenso e os casos do mundo real podem diferir sobre como os controles de acesso são implementados.
Se as permissões forem definidas no nível do grupo, as evidências de cada grupo e dos usuários desse grupo deverão ser fornecidas, conforme mostrado no segundo exemplo do Bitbucket.
A captura de tela a seguir mostra os membros da "Equipe CloudDemo".
A imagem anterior mostra que Andrew Smith tem privilégios significativamente maiores como proprietário do projeto do que Silvester abaixo.
Exemplo de evidência
Na próxima captura de tela, os controles de acesso implementados no Bitbucket são obtidos por meio de permissões definidas no nível do grupo. Para o nível de acesso ao repositório, há um grupo "Administrador" com um usuário e um grupo "Desenvolvedor" com outro usuário.
As próximas capturas de tela mostram que cada um dos usuários pertence a um grupo diferente e, inerentemente, tem um nível diferente de permissões. Andrew Smith é o administrador e Silvester faz parte do grupo de desenvolvedores, que só lhe concede privilégios de desenvolvedor.
Intenção: MFA
Se um agente de ameaça puder acessar e modificar a base de código de um software, ele poderá introduzir vulnerabilidades, backdoors ou código mal-intencionado na base de código e, portanto, no aplicativo. Já houve vários casos disso, provavelmente o mais divulgado sendo o ataque à SolarWinds em 2020, em que os invasores injetaram código malicioso em um arquivo que foi posteriormente incluído nas atualizações de software Orion da SolarWinds. Mais de 18.000 clientes da SolarWinds instalaram as atualizações maliciosas, com o malware se espalhando sem ser detectado.
A intenção deste subponto é verificar se todo o acesso aos repositórios de código é imposto por meio da MFA (autenticação multifator).
Diretrizes: MFA
Forneça evidências por meio de capturas de tela do repositório de código de que TODOS os usuários têm a MFA habilitada.
Exemplo de evidência: MFA
Se os repositórios de código forem armazenados e mantidos no DevOps do Azure, dependendo de como a MFA foi configurada no nível do locatário, as evidências poderão ser fornecidas do AAD, por exemplo, "MFA por usuário". A próxima captura de tela mostra que a MFA é imposta para todos os usuários no AAD e isso também se aplicará ao Azure DevOps.
Exemplo de evidência: MFA
Se a organização usa uma plataforma como o GitHub, você pode demonstrar que a 2FA está habilitada compartilhando as evidências da conta "Organização", conforme mostrado nas próximas capturas de tela.
Para ver se a 2FA é imposta a todos os membros da sua organização no GitHub, navegue até a guia de configurações da organização, como na próxima captura de tela.
Navegando até a guia "People" no GitHub, pode-se estabelecer que a "2FA" está habilitada para todos os usuários da organização, conforme mostrado na próxima captura de tela.
Intenção: avaliações
A intenção com esse controle é executar uma revisão da versão em um ambiente de desenvolvimento por outro desenvolvedor para ajudar a identificar erros de codificação, bem como configurações incorretas que possam introduzir uma vulnerabilidade. A autorização deve ser estabelecida para garantir que as revisões de versão sejam realizadas, os testes sejam feitos, etc. antes da implantação na produção. A autorização. etapa pode validar que os processos corretos foram seguidos, o que sustenta os princípios do SDLC.
Diretrizes
Forneça evidências de que todas as versões do ambiente de teste/desenvolvimento no ambiente de produção estão sendo revisadas por uma pessoa/desenvolvedor diferente do iniciador. Se isso for obtido por meio de um pipeline de Integração Contínua/Implantação Contínua, as evidências fornecidas deverão mostrar (da mesma forma que nas revisões de código) que as revisões são impostas.
Exemplo de evidência
Na próxima captura de tela, podemos ver que um pipeline de CI/CD está em uso no Azure DevOps, o pipeline contém dois estágios: Desenvolvimento e Produção. Uma versão foi disparada e implantada com sucesso no ambiente de desenvolvimento, mas ainda não se propagou para o segundo estágio (produção) e está aguardando a aprovação de Andrew Smith.
A expectativa é que, uma vez implantado no desenvolvimento, o teste de segurança ocorra pela equipe relevante e somente quando o indivíduo atribuído com a autoridade certa para revisar a implantação tiver realizado uma revisão secundária e estiver convencido de que todas as condições foram atendidas, concederá a aprovação que permitirá que a versão seja colocada em produção.
O alerta por email que normalmente seria recebido pelo revisor atribuído informando que uma condição de pré-implantação foi disparada e que uma revisão e aprovação estão pendentes.
Usando a notificação por email, o revisor pode navegar até o pipeline de lançamento no DevOps e conceder aprovação. Podemos ver a seguir que os comentários são adicionados justificando a aprovação.
Na segunda captura de tela, é mostrado que a aprovação foi concedida e que a liberação em produção foi bem-sucedida.
As próximas duas capturas de tela mostram um exemplo das evidências que seriam esperadas.
As evidências mostram lançamentos históricos e que as condições de pré-implantação são impostas, e uma revisão e aprovação são necessárias antes que a implantação possa ser feita no ambiente de produção.
A próxima captura de tela mostra o histórico de lançamentos, incluindo o lançamento recente, que podemos ver que foi implantado com êxito no desenvolvimento e na produção.
Observação: nos exemplos anteriores, uma captura de tela completa não foi usada, no entanto, TODAS as capturas de tela de evidências enviadas pelo ISV devem ser capturas de tela completas mostrando o URL, qualquer usuário conectado e hora e data do sistema.
Account management
As práticas de gerenciamento de contas seguras são importantes, pois as contas de usuário formam a base para permitir o acesso a sistemas de informação, ambientes de sistema e dados. As contas de usuário precisam ser devidamente protegidas, pois o comprometimento das credenciais do usuário pode fornecer não apenas uma base no ambiente e acesso a dados confidenciais, mas também pode fornecer controle administrativo sobre todo o ambiente ou sistemas-chave se as credenciais do usuário tiverem privilégios administrativos.
Controle nº 14
Fornecer evidências de que:
As credenciais padrão são desabilitadas, removidas ou alteradas nos componentes do sistema de amostra.
Há um processo em vigor para proteger (fortalecer) contas de serviço e esse processo é seguido.
Intenção: credenciais padrão
Embora isso esteja se tornando menos popular, ainda há casos em que os agentes de ameaças podem aproveitar as credenciais de usuário padrão e bem documentadas para comprometer os componentes do sistema de produção. Um exemplo popular disso é o Dell iDRAC (Integrated Dell Remote Access Controller). Esse sistema pode ser usado para gerenciar remotamente um servidor Dell, que pode ser aproveitado por um agente de ameaça para obter controle sobre o sistema operacional do servidor. A credencial padrão de root::calvin é documentada e muitas vezes pode ser aproveitada por agentes de ameaças para obter acesso aos sistemas usados pelas organizações. A intenção desse controle é garantir que as credenciais padrão sejam desabilitadas ou removidas para aprimorar a segurança.
Diretrizes: credenciais padrão
Existem várias maneiras pelas quais as evidências podem ser coletadas para apoiar esse controle. Capturas de tela de usuários configurados em todos os componentes do sistema podem ajudar, ou seja, capturas de tela das contas padrão do Windows por meio do prompt de comando (CMD) e para arquivos /etc/shadow e /etc/passwd do Linux ajudarão a demonstrar se as contas foram desabilitadas.
Exemplo de evidência: credenciais padrão
A próxima captura de tela mostra o arquivo /etc/shadow para demonstrar que as contas padrão têm uma senha bloqueada e as novas contas criadas/ativas têm uma senha utilizável.
Observe que o arquivo /etc/shadow seria necessário para demonstrar que as contas estão realmente desabilitadas, observando que o hash de senha começa com um caractere inválido, como '!', indicando que a senha é inutilizável. Nas próximas capturas de tela, o "L" significa bloquear a senha da conta nomeada. Esta opção desabilita uma senha alterando-a para um valor que não corresponda a nenhum valor criptografado possível (ela adiciona um! no início da senha). O "P" significa que é uma senha utilizável.
A segunda captura de tela demonstra que, no Windows Server, todas as contas padrão foram desabilitadas. Ao usar o comando 'net user' em um terminal (CMD), você pode listar detalhes de cada uma das contas existentes, observando que todas essas contas não estão ativas.
Usando o comando net user no CMD, você pode exibir todas as contas e observar que todas as contas padrão não estão ativas.
Intenção: credenciais padrão
As contas de serviço geralmente são alvo de agentes de ameaças porque geralmente são configuradas com privilégios elevados. Essas contas podem não seguir as políticas de senha padrão porque a expiração de senhas de conta de serviço geralmente interrompe a funcionalidade. Portanto, eles podem ser configurados com senhas fracas ou senhas que são reutilizadas dentro da organização. Outro problema potencial, especialmente em um ambiente Windows, pode ser que o sistema operacional armazena em cache o hash de senha. Isso pode ser um grande problema se:
a conta de serviço estiver configurada em um serviço de diretório, uma vez que essa conta pode ser usada para acessar em vários sistemas com o nível de privilégios configurado ou
a conta de serviço for local, é provável que a mesma conta/senha seja usada em vários sistemas dentro do ambiente.
Os problemas anteriores podem levar um agente de ameaça a obter acesso a mais sistemas dentro do ambiente e podem levar a uma maior elevação de privilégio e/ou movimento lateral. A intenção, portanto, é garantir que as contas de serviço sejam devidamente protegidas e protegidas para ajudar a protegê-las contra serem assumidas por um agente de ameaça ou limitando o risco caso uma dessas contas de serviço seja comprometida. O controle exige que um processo formal esteja em vigor para a proteção dessas contas, o que pode incluir a restrição de permissões, o uso de senhas complexas e a rotação regular de credenciais.
Diretrizes
Existem muitos guias na Internet para ajudar a proteger as contas de serviço. As evidências podem estar na forma de capturas de tela que demonstram como a organização implementou uma proteção segura da conta. Alguns exemplos (a expectativa é que várias técnicas sejam usadas) incluem:
Restringir as contas a um conjunto de computadores no Active Directory,
Definir a conta para que a entrada interativa não seja permitida,
Definir uma senha extremamente complexa,
Para o Active Directory, habilite o sinalizador "A conta é confidencial e não pode ser delegada".
Exemplo de evidência
Há várias maneiras de proteger uma conta de serviço que dependerão de cada ambiente individual. A seguir estão alguns dos mecanismos que podem ser empregados:
A próxima captura de tela mostra que a opção "A conta é confidencial e se conectar será delegada" está selecionada na conta de serviço "Conta de Serviço do _Prod SQL".
Essa segunda captura de tela mostra que a conta de serviço "Conta de Serviço do _Prod SQL" está bloqueada no SQL Server e só pode entrar nesse servidor.
A próxima captura de tela mostra que a conta de serviço "Conta de Serviço do _Prod SQL" só tem permissão para entrar como um serviço.
Observação: nos exemplos anteriores, uma captura de tela completa não foi usada, no entanto, TODAS as capturas de tela de evidências enviadas pelo ISV devem ser capturas de tela completas mostrando o URL, qualquer usuário conectado e hora e data do sistema.
Controle nº 15
Fornecer evidências de que:
Contas de usuário exclusivas são emitidas para todos os usuários.
Os princípios de privilégio mínimo do usuário estão sendo seguidos no ambiente.
Uma política de senha/senha forte ou outras mitigações adequadas estão em vigor.
Um processo está em vigor e é seguido pelo menos a cada três (3) meses para contas desativadas ou excluídas não usadas por três meses.
Intenção: proteger contas de serviço
A intenção desse controle é a responsabilidade. Ao emitir aos usuários suas próprias contas de usuário exclusivas, os usuários serão responsáveis por suas ações, pois a atividade do usuário pode ser rastreada até um usuário individual.
Diretrizes: proteger contas de serviço
A evidência seria por meio de capturas de tela mostrando contas de usuário configuradas nos componentes do sistema no escopo, que podem incluir servidores, repositórios de código, plataformas de gerenciamento de nuvem, Active Directory, Firewalls etc.
Exemplo de evidência: contas de serviço seguras
A próxima captura de tela mostra as contas de usuário configuradas para o ambiente do Azure no escopo e que todas as contas são exclusivas.
Intenção: privilégios
Os usuários só devem ter os privilégios necessários para cumprir sua função de trabalho. Isso é para limitar o risco de um usuário acessar, intencional ou não, dados que não deveria ou realizar uma
Ato malicioso. Seguindo esse princípio, ele também reduz a superfície de ataque potencial (ou seja, contas privilegiadas) que pode ser alvo de um agente de ameaça mal-intencionado.
Diretrizes: privilégios
A maioria das organizações utilizará grupos para atribuir privilégios com base nas equipes dentro da organização. As evidências podem ser capturas de tela mostrando os vários grupos privilegiados e apenas contas de usuário das equipes que exigem esses privilégios. Normalmente, isso seria apoiado por políticas/processos de suporte que definem cada grupo definido com os privilégios necessários e justificativa de negócios e uma hierarquia de membros da equipe para validar se a associação ao grupo está configurada corretamente.
Por exemplo: no Azure, o grupo Proprietários deve ser muito limitado, portanto, isso 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 esse privilégio com os membros da equipe considerados precisando dessa permissão configurados. Isso deve ser documentado para que o analista de certificação possa fazer referência cruzada do documento com os grupos configurados, etc.
Exemplo de evidência: privilégios
As próximas capturas de tela demonstram o princípio do privilégio mínimo em um ambiente do Azure.
A próxima captura de tela destaca o uso de vários grupos no AAD (Azure Active Directory)/Microsoft Entra. Observe que existem três grupos de segurança, Desenvolvedores, Engenheiros-líderes, Operações de segurança.
Navegando para o grupo "Desenvolvedores", no nível do grupo, as únicas funções atribuídas são "Desenvolvedor de aplicativos" e "Leitores de diretório".
A próxima captura de tela mostra os membros do grupo "Desenvolvedores".
Por fim, a próxima captura de tela mostra o Proprietário do grupo.
Em contraste com o grupo "Desenvolvedores", as "Operações de Segurança" têm diferentes funções atribuídas, ou seja, "Operador de Segurança", que está de acordo com o requisito do trabalho.
A próxima captura de tela mostra que há diferentes membros que fazem parte do grupo "Operações de Segurança".
Por fim, o grupo tem um proprietário diferente.
Os administradores globais são uma função altamente privilegiada e as organizações devem decidir o nível de risco que desejam aceitar ao fornecer esse tipo de acesso. No exemplo fornecido, existem apenas dois usuários que têm essa função. Isso é para garantir que a superfície de ataque e o impacto sejam reduzidos.
Intenção: política de senha
As credenciais do usuário geralmente são alvo de ataques de agentes de ameaças que tentam obter acesso ao ambiente de uma organização. A intenção de uma política de senha forte é tentar forçar os usuários a escolher senhas fortes para mitigar as chances de os agentes de ameaça conseguirem forçá-las. A intenção de adicionar a opção "ou outras mitigações adequadas" é reconhecer que as organizações podem implementar outras medidas de segurança para ajudar a proteger as credenciais do usuário com base nos desenvolvimentos do setor, como a Publicação Especial do NIST800-63B.
Diretrizes: política de senha
As evidências para demonstrar uma política de senha forte podem estar na forma de uma captura de tela das configurações de Objeto ou Política de Segurança Local ou de Objeto de uma Política de Grupo organização "Política de Conta → Política de Senha" e "Políticas de Conta → Política de Bloqueio de Conta". A evidência depende das tecnologias que estão sendo usadas, ou seja, para o Linux pode ser o arquivo de configuração /etc/pam.d/common-password, para o Bitbucket a seção "Políticas de autenticação" dentro do Portal de Administração [Gerenciar sua política de senha | Suporte da Atlassian, etc.
Exemplo de evidência: política de senha
As evidências a seguir mostram a política de senha configurada na "Política de Segurança Local" do componente do sistema no escopo "CONTOSO-SRV1".
A próxima captura de tela mostra as configurações de bloqueio de conta para um WatchGuard Firewall.
A seguir está um exemplo de um comprimento mínimo de senha para o WatchGuard Firewall.
Observação: nos exemplos anteriores, uma captura de tela completa não foi usada, no entanto, TODAS as capturas de tela de evidências enviadas pelo ISV devem ser capturas de tela completas mostrando o URL, qualquer usuário conectado e hora e data do sistema.
Intenção: contas inativas
Às vezes, as contas inativas podem ser comprometidas porque são alvo de ataques de força bruta que podem não ser sinalizados, pois o usuário não tentará fazer login nas contas, ou por meio de uma violação de banco de dados de senha em que a senha de um usuário foi reutilizada e está disponível em um despejo de nome de usuário/senha na Internet. As contas não utilizadas devem ser desabilitadas/removidas para reduzir a superfície de ataque que um agente de ameaça precisa para realizar atividades de comprometimento da conta. Essas contas podem ser devidas a um processo de saída que não está sendo realizado adequadamente, um membro da equipe está doente de longa duração ou um membro da equipe está saindo de licença maternidade / paternidade. Ao implementar um processo trimestral para identificar essas contas, as organizações podem minimizar a superfície de ataque.
Esse controle exige que um processo esteja em vigor e seja seguido pelo menos a cada três meses para desativar ou excluir contas que não foram usadas nos últimos três meses, com o objetivo de reduzir o risco, garantindo revisões regulares da conta e desativação oportuna de contas não utilizadas.
Diretrizes: contas inativas
As evidências devem ser duplas:
Primeiro, uma captura de tela ou exportação de arquivo mostrando o "último logon" de todas as contas de usuário no ambiente no escopo. Podem ser contas locais, bem como contas dentro de um serviço de diretório centralizado, como o AAD (Azure Active Directory). Isso demonstrará que nenhuma conta com mais de 3 meses está habilitada.
Em segundo lugar, evidências do processo de revisão trimestral que podem ser evidências documentais da tarefa que está sendo concluída dentro de tíquetes ADO (Azure DevOps) ou JIRA, ou por meio de registros em papel que devem ser assinados.
Exemplo de evidência: contas inativas
A próxima captura de tela demonstra que uma plataforma de nuvem foi utilizada para realizar revisões de acesso. Isso foi feito usando o recurso de Governança de Identidade no Azure.
A próxima captura de tela demonstra o histórico de revisão, o período de revisão e o status.
O dashboard e as métricas da revisão fornecem detalhes adicionais, como o escopo que são todos os usuários da organização e o resultado da revisão, bem como a frequência trimestral.
Ao avaliar os resultados da revisão, a imagem indica que uma ação recomendada foi fornecida, com base em condições pré-configuradas. Além disso, exige que um indivíduo designado aplique manualmente as decisões da revisão.
Você pode observar a seguir que para cada funcionário há uma recomendação e uma justificativa fornecida. Conforme mencionado, a decisão de aceitar a recomendação ou ignorá-la antes de aplicar a revisão é exigida por um indivíduo designado. Se a decisão final for contra a recomendação, a expectativa será que sejam fornecidas evidências para explicar o porquê.
Controle nº 16
FALHA DIFÍCIL
Fornecer evidências de que:
- A MFA é configurada para todos os acessos remotos e todas as interfaces administrativas que não são de console e interfaces de gerenciamento de nuvem.
Significado destes termos
Acesso remoto – Refere-se às tecnologias usadas para acessar o ambiente de suporte. Por exemplo, VPN IPSec de Acesso Remoto, VPN SSL ou Jumpbox/Bastian Host.
Interfaces administrativas que não são de console – Refere-se às conexões administrativas de rede com componentes do sistema. Isso pode ser feito por Área de Trabalho Remota, SSH ou uma interface da web.
Interfaces de gerenciamento de nuvem – onde parte ou todo o ambiente está hospedado no CSP (provedor de serviços de nuvem). A interface administrativa para gerenciamento de nuvem está incluída aqui.
Intenção: MFA
A intenção desse controle é fornecer atenuações contra ataques de força bruta em contas privilegiadas com acesso seguro ao ambiente implementando a MFA (autenticação multifator ). Mesmo que uma senha seja comprometida, o mecanismo de MFA ainda deve ser protegido, garantindo que todas as ações administrativas e de acesso sejam realizadas apenas por funcionários autorizados e confiáveis.
Para aumentar a segurança, é importante adicionar uma camada extra de segurança para conexões de acesso remoto e interfaces administrativas que não são de console usando MFA. As conexões de acesso remoto são particularmente vulneráveis à entrada não autorizada, e as interfaces administrativas controlam funções de alto privilégio, tornando ambas as áreas críticas que exigem medidas de segurança reforçadas. Além disso, os repositórios de código contêm trabalho de desenvolvimento confidencial e as interfaces de gerenciamento de nuvem fornecem amplo acesso aos recursos de nuvem de uma organização, tornando-os pontos críticos adicionais que devem ser protegidos com a MFA.
Diretrizes: MFA
As evidências precisam mostrar que a MFA está habilitada em todas as tecnologias que se encaixam nas categorias anteriores. Isso pode ser feito por meio de uma captura de tela que mostra que a MFA está habilitada no nível do sistema. Por nível de sistema, precisamos de evidências de que ele está habilitado para todos os usuários e não apenas um exemplo de uma conta com MFA habilitada. Quando a tecnologia é recuada para uma solução de MFA, precisamos de evidências para demonstrar que ela está habilitada e em uso. O que se entende por isso é; onde a tecnologia é configurada para autenticação Radius, que aponta para um provedor de MFA, você também precisa evidenciar que o servidor Radius para o qual está apontando é uma solução de MFA e que as contas estão configuradas para utilizá-la.
Exemplo de evidência: MFA
As capturas de tela a seguir demonstram como uma política condicional de MFA pode ser implementada no AAD/Entra para impor o requisito de autenticação de dois fatores em toda a organização. Podemos ver a seguir que a política está "ativada".
A próxima captura de tela mostra que a política de MFA deve ser aplicada a todos os usuários da organização e que está habilitada.
A próxima captura de tela demonstra que o acesso é concedido após o cumprimento da condição de MFA. No lado direito da captura de tela, podemos ver que o acesso só será concedido a um usuário quando a MFA for implementada.
Exemplo de evidência: MFA
Controles adicionais podem ser implementados, como um requisito de registro de MFA que garante que, após o registro, os usuários serão obrigados a configurar o MFA antes que o acesso seja concedido à sua nova conta. Você pode observar abaixo a configuração de uma política de registro de MFA que é aplicada a todos os usuários.
Na continuação da captura de tela anterior, que mostra a política a ser aplicada sem exclusões, a próxima captura de tela demonstra que todos os usuários estão incluídos na política.
Exemplo de evidência: MFA
A próxima captura de tela mostra que a página "MFA por usuário" está demonstrando que a MFA é imposta a todos os usuários.
Exemplo de evidência: MFA
As próximas capturas de tela mostram os realms de autenticação configurados no Pulse Secure, que é usado para acesso remoto ao ambiente. A autenticação é apoiada pelo Serviço SaaS Duo para Suporte a MFA.
Esta captura de tela demonstra que um servidor de autenticação adicional está habilitado que está apontando para "Duo-LDAP" para o realm de autenticação "Duo - Rota Padrão".
Esta captura de tela final mostra a configuração do servidor de autenticação Duo-LDAP, que demonstra que isso está apontando para o serviço SaaS Duo para MFA.
Observação: nos exemplos anteriores, uma captura de tela completa não foi usada, no entanto, TODAS as capturas de tela de evidências enviadas pelo ISV devem ser capturas de tela completas mostrando o URL, qualquer usuário conectado e hora e data do sistema.
Registro em log, revisão e alerta de eventos de segurança
O registro em log de eventos de segurança é uma parte integrante do programa de segurança de uma organização. O registro adequado de eventos de segurança, juntamente com alertas ajustados e processos de revisão, ajuda as organizações a identificar violações ou tentativas de violações que podem ser usadas pela organização para aprimorar as estratégias de segurança e segurança defensiva. Além disso, o registro adequado será fundamental para a capacidade de resposta a incidentes de uma organização, que pode alimentar outras atividades, como identificar com precisão quais e quais dados foram comprometidos, o período de comprometimento, fornecer relatórios de análise detalhados para agências governamentais, etc.
A revisão dos logs de segurança é uma função importante para ajudar as organizações a identificar eventos de segurança que podem ser indicativos de uma violação de segurança ou atividades de reconhecimento que podem ser uma indicação de algo por vir. Isso pode ser feito por meio de um processo manual diário ou usando uma solução SIEM (Security Information and Event Management) que ajuda a analisar logs de auditoria, procurando correlações e anomalias que podem ser sinalizadas para uma inspeção manual.
Eventos críticos de segurança precisam ser investigados imediatamente para minimizar o impacto nos dados e no ambiente operacional. Os alertas ajudam a destacar imediatamente possíveis violações de segurança para a equipe para garantir uma resposta oportuna para que a organização possa conter o evento de segurança o mais rápido possível. Ao garantir que os alertas estejam funcionando de forma eficaz, as organizações podem minimizar o impacto de uma violação de segurança, reduzindo assim a chance de uma violação grave que pode danificar a marca da organização e impor perdas financeiras por meio de multas e danos à reputação.
Controle nº 17
Fornecer evidências de que:
O log de eventos de segurança é configurado em todo o ambiente no escopo, incluindo componentes do sistema amostrados, para registrar eventos quando aplicável, como:
Acesso lógico do usuário aos componentes do sistema (acesso válido & inválido)
Todas as ações executadas por um usuário com altos privilégios
Criação/modificação de conta privilegiada
Violação do log de eventos
Desativação de ferramentas de segurança (exemplo: log de eventos)
Log antimalware (exemplo: atualizações, detecção de malware, falhas de verificação)
Intenção: log de eventos
Para identificar violações tentadas e reais, é importante que logs de eventos de segurança adequados sejam coletados por todos os sistemas que compõem o ambiente. A intenção desse controle é garantir que os tipos corretos de eventos de segurança estejam sendo capturados, o que pode alimentar os processos de revisão e alerta para ajudar a identificar e responder a esses eventos.
Esse subponto exige que um ISV tenha configurado o log de eventos de segurança para capturar todas as instâncias de acesso do usuário aos componentes e aplicativos do sistema. Isso é fundamental para monitorar quem está acessando os componentes e aplicativos do sistema dentro da organização e é essencial para fins de segurança e auditoria.
Esse subponto exige que todas as ações realizadas por usuários com privilégios de alto nível sejam registradas. Usuários com altos privilégios podem fazer mudanças significativas que podem afetar a postura de segurança da organização. Portanto, é fundamental manter um registro de suas ações.
Esse subponto exige o registro em log de todas as tentativas inválidas de obter acesso lógico a componentes ou aplicativos do sistema. Esse registro em log é a principal maneira de detectar tentativas de acesso não autorizado e possíveis ameaças à segurança.
Esse subponto requer o registro em log de qualquer criação ou modificação de contas com acesso privilegiado. Esse tipo de registro é crucial para acompanhar alterações em contas que têm um alto nível de acesso ao sistema e podem ser alvo de invasores.
Esse subponto exige o registro em log de todas as tentativas de adulteração de logs de eventos. A adulteração de logs pode ser uma maneira de ocultar atividades não autorizadas e, portanto, é vital que tais ações sejam registradas e executadas.
Esse subponto requer o registro em log de todas as ações que desabilitam as ferramentas de segurança, incluindo o próprio log de eventos. Desabilitar ferramentas de segurança pode ser um sinalizador vermelho indicando um ataque ou ameaça interna.
Esse subponto requer o registro em log de atividades relacionadas a ferramentas antimalware, incluindo atualizações, detecção de malware e falhas de verificação. O funcionamento adequado e a atualização das ferramentas antimalware são essenciais para a segurança de uma organização e os logs relacionados a essas atividades ajudam no monitoramento.
Diretrizes: log de eventos
A evidência por meio de capturas de tela ou definições de configuração deve ser fornecida em todos os dispositivos de amostra e quaisquer componentes do sistema relevantes para demonstrar como o registro em log é configurado para fornecer garantia de que esses tipos de eventos de segurança sejam capturados.
Exemplo de evidência
As próximas capturas de tela mostram as configurações de logs e métricas geradas por diferentes recursos no Azure, que são então ingeridas no espaço de trabalho centralizado Análise de Log.
Podemos ver na primeira captura de tela que o local de armazenamento do log é "PaaS-web-app-log-analytics".
No Azure, as configurações de diagnóstico podem ser habilitadas em recursos do Azure para acesso a logs de auditoria, segurança e diagnóstico, conforme demonstrado abaixo. Os logs de atividades, que estão disponíveis automaticamente, incluem origem de eventos, data, usuário, carimbo de data/hora, endereços de origem, endereços de destino e outros elementos úteis.
Observação: os exemplos a seguir mostram um tipo de evidência que pode ser fornecida para atender a esse controle. Isso depende de como sua organização configurou o log de eventos de segurança no ambiente no escopo. Outros exemplos podem incluir Azure Sentinel, Datadog etc.
Usando a opção "Configurações de Diagnóstico" para o aplicativo Web hospedado nos Serviços de Aplicativo do Azure App, você pode configurar quais logs são gerados e para onde eles são enviados para armazenamento e análise.
Na captura de tela a seguir, os "Logs de Auditoria do Access" e os "Logs de Auditoria de Segurança IPSecurity" estão configurados para serem gerados e capturados no espaço de trabalho da Análise de Log.
Outro exemplo é o do Azure Front Door, que é configurado para enviar logs gerados para o mesmo espaço de trabalho centralizado da Análise de Log.
Como antes de usar a opção "Configurações de Diagnóstico", configure quais logs são gerados e para onde eles são enviados para armazenamento e análise. A próxima captura de tela demonstra que os "Logs de acesso" e os "logs do WAF" foram configurados.
Da mesma forma, para o servidor SQL do Azure, as "Configurações de diagnóstico" podem configurar quais logs são gerados e para onde eles são enviados para armazenamento e análise.
A captura de tela a seguir demonstra que os logs de "auditoria" para o SQL Server são gerados e enviados para o workspace do Log Analytics.
Exemplo de evidência
A captura de tela a seguir do AAD/Entra demonstra que logs de auditoria estão sendo gerados para funções privilegiadas e administradores. As informações incluem status, atividade, serviço, destino e iniciador.
A captura de tela a seguir mostra os logs de login. As informações de log incluem endereço IP, status, local e data.
Exemplo de evidência
O exemplo a seguir se concentra em logs gerados para instâncias de computação, como Máquinas Virtuais (VMs). Uma regra de coleta de dados foi implementada e os logs de eventos do Windows, incluindo logs de Auditoria de Segurança, são capturados.
A captura de tela a seguir mostra outro exemplo de definições de configuração de um dispositivo de amostra chamado "Galaxy-Compliance". As configurações demonstram as várias configurações de auditoria habilitadas na "Política de Segurança Local".
A próxima captura de tela mostra um evento em que um usuário limpou o log de eventos do dispositivo de amostra "Galaxy-Compliance".
Observação: como os exemplos anteriores não são capturas de tela em tela cheia, você deverá enviar capturas de tela em tela cheia com qualquer URL, usuário conectado e carimbo de data e hora para revisão de evidências. Se você for um usuário do Linux, isso poderá ser feito por meio do prompt de comando.
Controle nº 18
Fornecer evidências de que:
Um mínimo de 30 dias de dados de log de eventos de segurança estão imediatamente disponíveis, com 90 dias de logs de eventos de segurança sendo retidos.
Intenção: log de eventos
Às vezes, há uma lacuna no tempo entre um comprometimento ou evento de segurança e uma organização que o identifica. A intenção desse controle é garantir que a organização tenha acesso a dados de eventos históricos para ajudar na resposta a incidentes e em qualquer trabalho de investigação forense que possa ser necessário. Garantir que a organização retenha um mínimo de 30 dias de dados de registro de eventos de segurança, que estão imediatamente disponíveis para análise para facilitar a investigação rápida e a resposta a incidentes de segurança. Além disso, um total de 90 dias de logs de eventos de segurança é mantido para permitir uma análise aprofundada.
Diretrizes: log de eventos
A evidência geralmente será por meio da exibição das definições de configuração da solução de log centralizado, mostrando por quanto tempo os dados são mantidos. 30 dias de dados de log de eventos de segurança precisam estar imediatamente disponíveis na solução. No entanto, onde os dados são arquivados é necessário demonstrar que o valor de 90 dias está disponível. Isso pode ser mostrando pastas de arquivo morto com datas de dados exportados.
Exemplo de evidência: log de eventos
Seguindo o exemplo anterior no Controle 17, em que um espaço de trabalho centralizado da Análise de Logs está em uso para armazenar todos os logs gerados pelos recursos de nuvem, você pode observar abaixo que os logs estão sendo armazenados em tabelas individuais para cada categoria de log. Além disso, a retenção interativa para todas as tabelas é de 90 dias.
A próxima captura de tela fornece evidências adicionais que demonstram as definições de configuração para o período de retenção do espaço de trabalho Análise de Log.
Exemplo de evidência
As capturas de tela a seguir demonstram que 30 dias de logs estão disponíveis no AlienVault.
Observação: como este é um documento voltado para o público, o número de série do firewall foi redigido, no entanto, os ISVs serão obrigados a enviar essas informações sem redações, a menos que contenham informações de identificação pessoal (PII) que devem ser divulgadas ao analista.
A próxima captura de tela mostra que os logs estão disponíveis, mostrando uma extração de log que remonta a cinco meses.
Observação: como este é um documento voltado para o público, os endereços IP públicos foram redigidos, no entanto, os ISVs serão obrigados a enviar essas informações sem nenhuma redação, a menos que contenham informações de identificação pessoal (PII) que eles devem discutir com seu analista primeiro.
Nota: Os exemplos anteriores não são capturas de tela em tela cheia, você será obrigado a enviar capturas de tela em tela cheia com qualquer URL, usuário conectado e o carimbo de data e hora para revisão de evidências. Se você for um usuário do Linux, isso poderá ser feito por meio do prompt de comando.
Exemplo de evidência
A próxima captura de tela mostra que os eventos de log são mantidos por 30 dias disponíveis, ativos e 90 dias no armazenamento frio no Azure.
Observação: a expectativa será que, além das definições de configuração que demonstrem a retenção configurada, uma amostra de logs do período de 90 dias seja fornecida para validar que os logs são retidos por 90 dias.
Observação: esses exemplos não são capturas de tela em tela cheia, você deverá enviar capturas de tela em tela cheia com qualquer URL, usuário conectado e carimbo de data e hora para revisão de evidências. Se você for um usuário do Linux, isso poderá ser feito por meio do prompt de comando.
Controle nº 19
Fornecer evidência de que:
Os logs estão sendo revisados periodicamente e quaisquer possíveis eventos/anomalias de segurança identificados durante o processo de revisão são investigados e resolvidos.
Intenção: log de eventos
A intenção desse controle é garantir que as revisões periódicas do log estejam sendo realizadas. Isso é importante para identificar quaisquer anomalias que possam não ser detectadas pelos scripts/consultas de alerta configurados para fornecer alertas de eventos de segurança. Além disso, quaisquer anomalias identificadas durante as revisões de log são investigadas e a correção ou ação apropriada é executada. Isso geralmente envolve um processo de triagem para identificar se as anomalias exigem ação e, em seguida, pode ser necessário invocar o processo de resposta a incidentes.
Diretrizes: log de eventos
As evidências seriam fornecidas por capturas de tela, demonstrando que as revisões de log estão sendo realizadas. Isso pode ser feito por meio de formulários que são preenchidos todos os dias ou por meio de um tíquete JIRA ou DevOps com
comentários relevantes sendo postados para mostrar que isso é realizado. Se alguma anomalia for sinalizada, ela poderá ser documentada neste mesmo tíquete para demonstrar que as anomalias identificadas como parte da revisão de log são acompanhadas e, em seguida, detalhar quais atividades foram realizadas posteriormente. Isso pode fazer com que um tíquete específico do JIRA seja gerado para rastrear todas as atividades que estão sendo realizadas ou pode apenas ser documentado no tíquete de revisão de log. Se uma ação de resposta a incidentes for necessária, isso deverá ser documentado como parte do processo de resposta a incidentes e evidências deverão ser fornecidas para demonstrar isso.
Exemplo de evidência: log de eventos
Essa primeira captura de tela identifica onde um usuário foi adicionado ao grupo 'Administradores de Domínio'.
A próxima captura de tela identifica onde várias tentativas de logon com falha são seguidas por um logon bem-sucedido, o que pode realçar um ataque de força bruta bem-sucedido.
Esta captura de tela final identifica onde ocorreu uma alteração na política de senha, definindo a política, para que as senhas da conta não expirem.
A próxima captura de tela mostra que um tíquete é gerado automaticamente na ferramenta ServiceNow do SOC, acionando a regra anterior acima.
Observação: esses exemplos não são capturas de tela em tela cheia, você deverá enviar capturas de tela em tela cheia com qualquer URL, usuário conectado e carimbo de data e hora para revisão de evidências. Se você for um usuário do Linux, isso poderá ser feito por meio do prompt de comando.
Controle nº 20
FALHA DIFÍCIL
Fornecer evidências de que:
As regras de alerta são configuradas para que os alertas sejam disparados para investigação imediata dos seguintes eventos de segurança, quando aplicável:
Criação/Modificações de Conta Privilegiada
atividades ou operações privilegiadas/de alto risco
Eventos de malware (se aplicável)
Violação do log de eventos
Eventos IDPS/WAF (se configurado)
Intenção: alertas
Estes são alguns tipos de eventos de segurança que podem destacar a ocorrência de um evento de segurança, o que pode apontar para uma violação de ambiente e/ou violação de dados.
Esse subponto é para garantir que as regras de alerta sejam configuradas especificamente para disparar investigações após a criação ou modificação de contas privilegiadas. No caso de criação ou modificações de contas privilegiadas, os logs devem ser gerados e os alertas devem ser disparados sempre que uma nova conta privilegiada for criada ou as permissões de conta privilegiada existentes forem alteradas. Isso ajuda a rastrear qualquer atividade não autorizada ou suspeita.
Este subponto visa estabelecer regras de alerta para notificar o pessoal apropriado quando atividades ou operações privilegiadas ou de alto risco são realizadas. Para atividades ou operações privilegiadas ou de alto risco, alertas devem ser configurados para notificar o pessoal apropriado quando tais atividades forem iniciadas. Isso pode incluir alterações nas regras de firewall, transferências de dados ou acesso a arquivos confidenciais.
A intenção deste subponto é exigir a configuração de regras de alerta que são disparadas por eventos relacionados a malware. Os eventos de malware não devem apenas ser registrados, mas também devem disparar um alerta imediato para investigação. Esses alertas devem ser projetados para incluir detalhes como origem, natureza do malware e componentes do sistema afetados para agilizar o tempo de resposta.
Esse subponto foi projetado para garantir que qualquer violação de logs de eventos dispare um alerta imediato para investigação. Em relação à violação do log de eventos, o sistema deve ser configurado para disparar alertas quando o acesso não autorizado a logs ou modificações de logs forem detectadas. Isso garante a integridade dos logs de eventos, que são cruciais para análise forense e auditorias de conformidade.
Este subponto pretende garantir que, se os Sistemas de Detecção e Prevenção de Intrusão (IDPS) ou os Firewalls de Aplicativos Web (WAF) estiverem configurados, eles sejam configurados para disparar alertas para investigação. Se os Sistemas de Detecção e Prevenção de Intrusão (IDPS) ou os Firewalls de Aplicativos Web (WAF) estiverem configurados, eles também deverão ser configurados para disparar alertas de atividades suspeitas, como falhas repetidas de login, tentativas de injeção de SQL ou padrões que sugerem um ataque de negação de serviço.
Diretrizes: alertas
As evidências devem ser fornecidas por meio de capturas de tela da configuração de alertas E evidências dos alertas que estão sendo recebidos. As capturas de tela de configuração devem mostrar a lógica que está disparando os alertas e como eles são enviados. Os alertas podem ser enviados por SMS, Email, canais do Teams, canais do Slack, etc....
Exemplo de evidência: alertas
A próxima captura de tela mostra um exemplo de alertas sendo configurados no Azure. Podemos observar na primeira captura de tela que um alerta foi disparado quando a VM foi parada e desalocada. Observe que isso descreve um exemplo de alertas sendo configurados no Azure e a expectativa será que sejam fornecidas evidências para demonstrar que os alertas são gerados para todos os eventos especificados na descrição do controle.
A captura de tela a seguir mostra alertas configurados para quaisquer ações administrativas executadas no nível do Serviço de Aplicativo do Azure, bem como no nível do Grupo de Recursos do Azure.
Exemplo de evidência
A Contoso utiliza um SOC (Centro de Operações de Segurança) de terceiros fornecido pela Segurança da Contoso. O exemplo mostra que o alerta no AlienVault, utilizado pelo SOC, está configurado para enviar um alerta a um membro da Equipe SOC, Sally Gold da Contoso Security.
A próxima captura de tela mostra um alerta sendo recebido por Sally.
Observação: esses exemplos não são capturas de tela em tela cheia, você deverá enviar capturas de tela em tela cheia com qualquer URL, usuário conectado e carimbo de data e hora para revisão de evidências. Se você for um usuário do Linux, isso poderá ser feito por meio do prompt de comando.
Gerenciamento de riscos de segurança das informações
O Gerenciamento de Riscos de Segurança da Informação é uma atividade importante que todas as organizações devem realizar pelo menos uma vez por ano. As organizações devem entender seus riscos para mitigar as ameaças de forma eficaz. Sem um gerenciamento de risco eficaz, as organizações podem implementar recursos de segurança em áreas que consideram importantes, quando outras ameaças podem ser mais prováveis. O gerenciamento eficaz de riscos ajudará as organizações a se concentrarem nos riscos que representam a maior ameaça aos negócios. Isso deve ser realizado anualmente, pois o cenário de segurança está em constante mudança e, portanto, as ameaças e os riscos podem mudar com o tempo. Por exemplo, durante o recente bloqueio do COVID-19, houve um grande aumento de ataques de phishing com a mudança para o trabalho remoto.
Controle nº 21
Fornecer evidências de que:
Uma política/processo formal de gerenciamento de riscos de segurança da informação ratificada é documentada e estabelecida.
Intenção: gerenciamento de risco
Um processo robusto de gerenciamento de riscos de segurança da informação é importante para ajudar as organizações a gerenciar riscos de forma eficaz. Isso ajudará as organizações a planejar mitigações eficazes contra ameaças ao meio ambiente. A intenção desse controle é confirmar se a organização tem uma política ou processo de gerenciamento de riscos de segurança da informação formalmente ratificado que esteja documentado de forma abrangente. A política deve descrever como a organização identifica, avalia e gerencia os riscos de segurança da informação. Deve incluir funções e responsabilidades, metodologias para avaliação de riscos, critérios para aceitação de riscos e procedimentos para mitigação de riscos.
Nota: A avaliação de risco deve se concentrar nos riscos de segurança da informação, não apenas nos riscos gerais de negócios.
Diretrizes: gerenciamento de risco
O processo de gerenciamento de avaliação de risco formalmente documentado deve ser fornecido.
Exemplo de evidência: gerenciamento de risco
A evidência a seguir é uma captura de tela de parte do processo de avaliação de risco da Contoso.
Observação: a expectativa é que os ISVs compartilhem a documentação real da política/procedimento de suporte e não simplesmente forneçam uma captura de tela.
Observação: a expectativa é que os ISVs compartilhem a documentação real da política/procedimento de suporte e não simplesmente forneçam uma captura de tela.
Controle nº 22
FALHA DIFÍCIL
Fornecer evidências de que:
Uma avaliação formal de risco de segurança da informação em toda a empresa é realizada pelo menos anualmente ou após uma mudança significativa no ambiente.
A avaliação de risco inclui o ambiente no escopo.
Nota: As mudanças podem incluir mudanças tecnológicas que afetam riscos ambientais, legais, operacionais e fusões/aquisições.
Intenção: avaliação anual
As ameaças à segurança estão em constante mudança com base em mudanças no ambiente, mudanças nos serviços oferecidos, influências externas, evolução do cenário de ameaças à segurança, etc. As organizações precisam passar pelo processo de avaliação de risco pelo menos uma vez por ano. Recomenda-se que esse processo também seja realizado mediante mudanças significativas, pois as ameaças podem mudar.
A intenção desse controle é verificar se a organização realiza uma avaliação formal de risco de segurança da informação em toda a empresa pelo menos uma vez por ano e/ou uma análise de risco direcionada durante mudanças no sistema ou incidentes, descoberta de vulnerabilidades, alterações de infraestrutura, etc. Essa avaliação deve abranger todos os ativos, processos e dados organizacionais, visando identificar e avaliar possíveis vulnerabilidades e ameaças.
Para a análise de risco direcionada, esse controle enfatiza a necessidade de realizar análises de risco em cenários específicos, isso é focado em um escopo mais restrito, como um ativo, uma ameaça, um sistema ou um controle. A intenção disso é garantir que as organizações avaliem e identifiquem continuamente os riscos introduzidos por desvios das melhores práticas de segurança ou limitações de design do sistema. Ao realizar análises de risco direcionadas pelo menos uma vez por ano onde faltam controles, quando as restrições tecnológicas criam vulnerabilidades e em resposta a incidentes de segurança suspeitos ou confirmados, a organização pode identificar pontos fracos e exposições. Isso permite decisões informadas baseadas em risco sobre como priorizar os esforços de correção e implementar controles de compensação para minimizar a probabilidade e o impacto da exploração. O objetivo é fornecer due diligence contínua, orientação e evidências de que as lacunas conhecidas estão sendo abordadas de maneira consciente do risco, em vez de serem ignoradas indefinidamente. A realização dessas avaliações de risco direcionadas demonstra o compromisso organizacional em melhorar proativamente a postura de segurança ao longo do tempo.
Diretrizes: avaliação anual
A evidência pode ser por meio de rastreamento de versão ou evidência datada. Devem ser fornecidas evidências que mostrem o resultado da avaliação de risco de segurança da informação e NÃO as datas do próprio processo de avaliação de risco de segurança da informação.
Exemplo de evidência: avaliação anual
A próxima captura de tela mostra uma reunião de avaliação de risco sendo agendada a cada seis meses.
As próximas duas capturas de tela mostram um exemplo de ata de reunião de duas avaliações de risco. A expectativa é que um relatório/ata de reunião ou relatório da avaliação de risco seja fornecido.
Observação: esta captura de tela mostra um documento de política/processo. A expectativa é que os ISVs compartilhem a documentação real da política/procedimento de suporte e não apenas forneçam uma captura de tela.
Observação: esta captura de tela mostra um documento de política/processo, a expectativa é que os ISVs compartilhem a documentação real de política/procedimento de suporte e não simplesmente forneçam uma captura de tela.
Controle nº 23
Fornecer evidências de que:
A avaliação de risco de segurança da informação inclui:
Componente do sistema ou recurso afetado
ameaças e vulnerabilidades, ou equivalentes
métricas de impacto e verossimilhança ou equivalentes
a criação de um registo de riscos/plano de tratamento de riscos
Intenção: avaliação de risco
A intenção é que a avaliação de risco inclua componentes e recursos do sistema, pois ajuda a identificar os ativos de TI mais críticos e seu valor. Ao identificar e analisar ameaças potenciais aos negócios, a organização pode se concentrar primeiro nos riscos que têm o maior impacto potencial e a maior probabilidade. Compreender o impacto potencial na infraestrutura de TI e os custos associados pode ajudar a gerência a tomar decisões informadas sobre orçamento, políticas, procedimentos e muito mais. Uma lista de componentes ou recursos do sistema que podem ser incluídos na avaliação de risco de segurança são:
Servidores
Bancos de dados
Aplicativos
Redes
Dispositivos de armazenamento de dados
Pessoas
Para gerenciar efetivamente os riscos de segurança da informação, as organizações devem realizar avaliações de risco contra ameaças ao ambiente e aos dados e contra possíveis vulnerabilidades que possam estar presentes. Isso ajudará as organizações a identificar a miríade de ameaças e vulnerabilidades que podem representar um risco significativo. As avaliações de risco devem documentar classificações de impacto e verossimilhança, que podem ser usadas para identificar o valor do risco. Isso pode ser usado para priorizar o tratamento de risco e ajudar a reduzir o valor geral do risco. As avaliações de risco precisam ser rastreadas adequadamente para fornecer um registro de um dos quatro tratamentos de risco que estão sendo aplicados. Esses tratamentos de risco são:
Evitar/Encerrar: A empresa pode determinar que o custo de lidar com o risco é maior do que a receita gerada pelo serviço. A empresa pode, portanto, optar por parar de executar o serviço.
Transferir/Compartilhar: A empresa pode optar por transferir o risco para terceiros, movendo o processamento para um terceiro.
Aceitar/Tolerar/Reter: A empresa pode decidir que o risco é aceitável. Isso depende muito do apetite de risco das empresas e pode variar de acordo com a organização.
Tratar/mitigar/modificar: a empresa decide implementar controles de mitigação para reduzir o risco a um nível aceitável.
Diretrizes: avaliação de risco
Devem ser fornecidas provas não só do processo de avaliação dos riscos para a segurança da informação já fornecido, mas também dos resultados da avaliação dos riscos (através de um registo dos riscos/plano de tratamento dos riscos) para demonstrar que o processo de avaliação dos riscos está a ser realizado correctamente. O registro de riscos deve incluir classificações de riscos, vulnerabilidades, impacto e verossimilhança.
Exemplo de evidência: avaliação de risco
A próxima captura de tela mostra o registro de risco que demonstra que as ameaças e vulnerabilidades estão incluídas. Também demonstra que o impacto e as probabilidades estão incluídos.
Observação: a documentação completa da avaliação de risco deve ser fornecida em vez de uma captura de tela. A próxima captura de tela demonstra um plano de tratamento de risco.
Controle nº 24
Fornecer evidências de que:
Existe um processo de gerenciamento de riscos que avalia e gerencia os riscos associados a fornecedores e parceiros de negócios.
O processo de gerenciamento de riscos para fornecedores e parceiros de negócios foi realizado pelo menos nos últimos doze (12) meses.
Intenção: fornecedores e parceiros
O gerenciamento de risco do fornecedor é a prática de avaliar as posturas de risco de parceiros de negócios, fornecedores ou fornecedores terceirizados antes que um relacionamento comercial seja estabelecido e durante toda a duração do relacionamento. Ao gerenciar os riscos do fornecedor, as organizações podem evitar interrupções na continuidade dos negócios, evitar impactos financeiros, proteger sua reputação, cumprir os regulamentos e identificar e minimizar os riscos associados à colaboração com um fornecedor. Para gerenciar efetivamente os riscos do fornecedor, é importante ter processos em vigor que incluam avaliações de due diligence, obrigações contratuais relacionadas à segurança e monitoramento contínuo da conformidade do fornecedor.
Diretrizes: fornecedores e parceiros
Evidências podem ser fornecidas para demonstrar o processo de avaliação de risco do fornecedor, como a documentação estabelecida de aquisição e verificação, listas de verificação e questionários para integração de novos fornecedores e contratados, avaliações realizadas, verificações de conformidade, etc.
Exemplo de evidência: fornecedores e parceiros
A próxima captura de tela demonstra que o processo de integração e verificação do fornecedor é mantido no Confluence como uma tarefa do JIRA. Para cada novo fornecedor, ocorre uma avaliação de risco inicial para revisar a postura de conformidade. Durante o processo de aquisição, um questionário de avaliação de risco é preenchido e o risco geral é determinado com base no nível de acesso aos sistemas e dados fornecidos ao fornecedor.
A captura de tela a seguir demonstra o resultado da avaliação e o risco geral que foi identificado com base na revisão inicial.
Intenção: controles internos
O foco deste subponto é reconhecer e avaliar mudanças e riscos que podem impactar os sistemas de controle interno de uma organização para garantir que os controles internos permaneçam eficazes ao longo do tempo. À medida que as operações de negócios mudam, seus controles internos podem deixar de ser eficazes. Os riscos evoluem com o tempo e podem surgir novos riscos que não foram considerados anteriormente. Ao identificar e avaliar esses riscos, você pode garantir que seus controles internos sejam projetados para resolvê-los. Isso ajuda a evitar fraudes e erros, manter a continuidade dos negócios e garantir a conformidade regulatória.
Diretrizes: controles internos
Evidências podem ser fornecidas, como atas e relatórios de reuniões de revisão, que podem demonstrar que o processo de avaliação de risco do fornecedor é atualizado em um período definido para garantir que as possíveis alterações do fornecedor sejam contabilizadas e avaliadas.
Exemplo de evidência: controles internos
As capturas de tela a seguir demonstram que uma revisão de três meses da lista aprovada de fornecedores e contratados é realizada para garantir que seus padrões de conformidade e nível de conformidade sejam consistentes com a avaliação inicial durante a integração.
A primeira captura de tela mostra as diretrizes estabelecidas para realizar a avaliação e o questionário de risco.
As capturas de tela a seguir mostram a lista real de fornecedores aprovados e seu nível de conformidade, a avaliação realizada, o avaliador, o aprovador etc. Observe que este é apenas um exemplo de uma avaliação de risco rudimentar do fornecedor projetada para fornecer um cenário básico para entender o requisito de controle e mostrar o formato da evidência esperada. Como ISV, você deve fornecer sua própria avaliação de risco de fornecedor estabelecida, conforme aplicável à sua organização.
Resposta a incidentes de segurança
A resposta a incidentes de segurança é importante para todas as organizações, pois isso pode reduzir o tempo gasto por uma organização que contém um incidente de segurança e limitar o nível de exposição da organização à exfiltração de dados. Ao desenvolver um plano de resposta a incidentes de segurança abrangente e detalhado, essa exposição pode ser reduzida desde o momento da identificação até o momento da contenção.
Um relatório da IBM intitulado "Relatório de custo de violação de dados 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 que a maior economia de custos para as organizações que sofreram uma violação foi a preparação para resposta a incidentes, fornecendo uma média de
Economia de custos de US$ 2.000.000. As organizações devem seguir as práticas recomendadas para conformidade de segurança usando estruturas padrão do setor, como ISO 27001, NIST, SOC 2, PCI DSS etc...
Controle nº 25
FALHA DIFÍCIL
Fornecer evidências de que:
Existe um plano/procedimento de resposta a incidentes de segurança (IRP) ratificado descrevendo como sua organização responde a incidentes, mostrando como ele é mantido e que inclui:
Detalhes da equipe de resposta a incidentes, incluindo informações de contato.
Um plano de comunicação interna a ser seguido durante o incidente e para comunicação externa com partes relevantes, como principais partes interessadas, marcas de pagamento e adquirentes, órgãos reguladores (por exemplo, 72 horas para GDPR), autoridades de supervisão, diretores, clientes.
Etapas para atividades como classificação de incidentes, contenção, mitigação, recuperação e retorno às operações normais de negócios, dependendo do tipo de incidente.
Intenção: Plano de Resposta a Incidentes (IRP)
A intenção desse controle é garantir que haja um plano de resposta a incidentes (IRP) formalmente documentado, que inclua uma equipe de resposta a incidentes designada com funções, responsabilidades e informações de contato claramente documentadas. O IRP deve fornecer uma abordagem estruturada para gerenciar incidentes de segurança desde a detecção até a resolução, incluindo a classificação da natureza do incidente, contendo o impacto imediato, mitigando os riscos, recuperando-se do incidente e restaurando as operações comerciais normais. Cada etapa deve ser bem definida, com protocolos claros, para garantir que as ações tomadas estejam alinhadas com as estratégias de gerenciamento de riscos e obrigações de compliance da organização.
A especificação detalhada da equipe de resposta a incidentes dentro do IRP garante que cada membro da equipe entenda seu papel no gerenciamento do incidente, permitindo uma resposta coordenada e eficiente. Ao ter um IRP em vigor, uma organização pode gerenciar uma resposta a incidentes de segurança com mais eficiência, o que pode limitar a exposição à perda de dados da organização e reduzir os custos do comprometimento.
As organizações podem ter obrigações de notificação de violação com base no país ou países em que operam (por exemplo, o Regulamento Geral sobre a Proteção de Dados GDPR) ou com base na funcionalidade oferecida (por exemplo, PCI DSS se dados de pagamento forem manipulados). A falha na notificação oportuna pode ter sérias ramificações; Portanto, para garantir que as obrigações de notificação sejam cumpridas, os planos de resposta a incidentes devem incluir um processo de comunicação, incluindo comunicação com todas as partes interessadas, processos de comunicação da mídia e quem pode e não pode falar com a mídia.
Diretrizes: controles internos
Forneça a versão completa do plano/procedimento de resposta a incidentes. O plano de resposta a incidentes deve incluir uma seção que abranja o processo de tratamento de incidentes, desde a identificação até a resolução, e um processo de comunicação documentado.
Exemplo de evidência: controles internos
A próxima captura de tela mostra o início do plano de resposta a incidentes da Contoso.
Nota: Como parte do envio de evidências, você deve fornecer todo o plano de resposta a incidentes.
Exemplo de evidência: controles internos
A próxima captura de tela mostra um extrato do plano de resposta a incidentes mostrando o processo de comunicação.
Controle nº 26
Fornecer evidências de que:
Todos os membros da equipe de resposta a incidentes de segurança receberam treinamento anual de resposta a incidentes específicos da organização, o que lhes permite responder a incidentes de segurança.
Intenção: treinamento
Quanto mais tempo leva para uma organização conter um comprometimento, maior o risco de exfiltração dos dados, resultando potencialmente em um volume maior de dados exfiltrados e maior o custo geral do comprometimento. É importante que as equipes de resposta a incidentes da organização estejam equipadas para responder a incidentes de segurança em tempo hábil. Ao realizar treinamentos regulares e realizar exercícios de mesa, a equipe está preparada para lidar com incidentes de segurança de forma rápida e eficiente. Esse treinamento deve abranger vários aspectos, como identificação de ameaças potenciais, ações de resposta inicial, procedimentos de escalonamento e estratégias de mitigação de longo prazo.
A recomendação é realizar treinamento interno de resposta a incidentes para a equipe de resposta a incidentes E realizar exercícios regulares de mesa, que devem estar vinculados ao risco de segurança da informação
para identificar os incidentes de segurança mais prováveis de ocorrer. O exercício de mesa deve simular cenários do mundo real para testar e aprimorar as habilidades da equipe para reagir sob pressão. Ao fazer isso, a organização pode garantir que sua equipe saiba como lidar adequadamente com uma violação de segurança ou ataque cibernético. E a equipe saberá rapidamente quais medidas tomar para conter e investigar os incidentes de segurança mais prováveis.
Diretrizes: treinamento
Devem ser fornecidas evidências que demonstrem que o treinamento foi realizado por meio do compartilhamento do conteúdo do treinamento e registros mostrando quem participou (o que deve incluir toda a equipe de resposta a incidentes). Alternativamente, ou também, registros mostrando que um exercício de mesa foi realizado. Tudo isso deve ter sido concluído dentro de um período de 12 meses a partir do momento em que a evidência é apresentada.
Exemplo de evidência: treinamento
A Contoso executou um exercício de mesa de resposta a incidentes usando uma empresa de segurança externa. A seguir está uma amostra do relatório gerado como parte da consultoria.
Observação: o relatório completo precisaria ser compartilhado. Esse exercício também pode ser realizado internamente, pois não há nenhum requisito do Microsoft 365 para que isso seja realizado por uma empresa terceirizada.
Observação: o relatório completo precisaria ser compartilhado. Esse exercício também pode ser realizado internamente, pois não há nenhum requisito do Microsoft 365 para que isso seja realizado por uma empresa terceirizada.
Controle nº 27
Fornecer evidências de que:
A estratégia de resposta a incidentes de segurança e a documentação de suporte são revisadas e atualizadas com base em OU:
lições aprendidas com um exercício de mesa
lições aprendidas com a resposta a um incidente de segurança ou
Mudanças organizacionais significativas
Intenção: revisões de plano
Com o tempo, o plano de resposta a incidentes deve evoluir com base em mudanças organizacionais ou com base nas lições aprendidas ao promulgar o plano. Alterações no ambiente operacional podem exigir alterações no plano de resposta a incidentes, pois as ameaças podem mudar ou os requisitos regulatórios podem mudar. Além disso, à medida que exercícios de mesa e respostas reais a incidentes de segurança são realizados, isso geralmente pode identificar áreas do plano que podem ser melhoradas. Isso precisa ser integrado ao plano e a intenção desse controle é garantir que esse processo seja incluído. O objetivo desse controle é exigir a revisão e atualização da estratégia de resposta a incidentes da organização e da documentação de suporte com base em três gatilhos distintos:
Após a realização dos exercícios simulados para testar a eficácia de sua estratégia de resposta a incidentes, quaisquer lacunas ou áreas de melhoria identificadas devem ser imediatamente incorporadas ao plano de resposta a incidentes existente.
Um incidente real fornece informações valiosas sobre os pontos fortes e fracos da estratégia de resposta atual. Se ocorrer um incidente, uma revisão pós-incidente deve ser realizada para capturar essas lições, que devem ser usadas para atualizar a estratégia e os procedimentos de resposta.
Quaisquer mudanças significativas dentro da organização, como fusões, aquisições ou mudanças no pessoal-chave, devem desencadear uma revisão da estratégia de resposta a incidentes. Essas mudanças organizacionais podem introduzir novos riscos ou mudar os existentes, e o plano de resposta a incidentes deve ser atualizado de acordo para permanecer eficaz.
Diretrizes: revisões de plano
Isso geralmente será evidenciado pela análise dos resultados de incidentes de segurança ou exercícios de mesa em que as lições aprendidas foram identificadas e resultaram em uma atualização do plano de resposta a incidentes. O plano deve manter um changelog, que também deve fazer referência às mudanças que foram implementadas com base nas lições aprendidas ou nas mudanças organizacionais.
Exemplo de evidência: revisões de plano
As próximas capturas de tela são do plano de resposta a incidentes fornecido, que inclui uma seção sobre atualização com base nas lições aprendidas e/ou mudanças na organização.
Nota: Esses exemplos não são capturas de tela em tela cheia, você deverá enviar capturas de tela em tela cheia com qualquer URL, usuário conectado e carimbo de data e hora para revisão de evidências. Se você for um usuário do Linux, isso poderá ser feito por meio do prompt de comando.
Plano de continuidade de negócios e plano de recuperação de desastres
O planejamento de continuidade de negócios e o planejamento de recuperação de desastres são dois componentes críticos da estratégia de gerenciamento de riscos de uma organização. O planejamento de continuidade de negócios é o processo de criação de um plano para garantir que as funções essenciais de negócios possam continuar a operar durante e após um desastre, enquanto o planejamento de recuperação de desastres é o processo de criação de um plano para se recuperar de um desastre e restaurar as operações normais de negócios o mais rápido possível. Ambos os planos se complementam - você deve ter os dois para resistir a desafios operacionais causados por desastres ou interrupções inesperadas. Esses planos são importantes porque ajudam a garantir que uma organização possa continuar operando durante um desastre, proteger sua reputação, cumprir os requisitos legais, manter a confiança do cliente, gerenciar riscos com eficácia e manter os funcionários seguros.
Controle nº 28
Fornecer evidências de que:
A documentação existe e é mantida descrevendo o Plano de Continuidade de Negócios que inclui:
detalhes do pessoal relevante, incluindo suas funções e responsabilidades
Detalhes de todas as funções críticas de negócios com requisitos e objetivos de contingência associados
A prioridade de recuperação e o prazo visam a restauração do sistema e o retorno ao estado original.
Intenção: plano de continuidade de negócios
A intenção por trás desse controle é garantir que uma lista claramente definida de pessoal com funções e responsabilidades atribuídas seja incluída no plano de continuidade de negócios. Essas funções são cruciais para a ativação e execução eficazes do plano durante um incidente.
Diretrizes: plano de continuidade de negócios
Forneça a versão completa do plano/procedimento de recuperação de desastres, que deve incluir seções que abranjam a estrutura de tópicos processada na descrição do controle. Forneça o documento PDF/WORD real se estiver em uma versão digital, alternativamente, se o processo for mantido por meio de uma plataforma online, forneça uma exportação ou capturas de tela dos processos.
Exemplo de evidência: plano de continuidade de negócios
As próximas capturas de tela mostram um extrato de um plano de continuidade de negócios e que ele existe e é mantido.
Observação: essas capturas de tela mostram instantâneos de um documento de política/processo, a expectativa é que os ISVs compartilhem a documentação real de política/procedimento de suporte e não simplesmente forneçam uma captura de tela.
As próximas capturas de tela mostram um extrato da política em que a seção 'Funcionários principais' está delineada, incluindo equipe relevante, detalhes de contato e etapas a serem seguidas.
Intenção: priorização
O objetivo desse controle é documentar e priorizar as funções de negócios de acordo com sua criticidade. Isso deve ser acompanhado por um esboço dos requisitos de contingência correspondentes necessários para sustentar ou restaurar rapidamente cada função durante uma interrupção não planejada.
Diretrizes: priorização
Forneça a versão completa do plano/procedimento de recuperação de desastres, que deve incluir seções que abranjam a estrutura de tópicos processada na descrição do controle. Forneça o documento PDF/WORD real se estiver em uma versão digital, alternativamente, se o processo for mantido por meio de uma plataforma online, forneça uma exportação ou capturas de tela dos processos.
Exemplo de evidência: priorização
As próximas capturas de tela mostram um extrato de um plano de continuidade de negócios e um esboço das funções de negócios e seu nível de criticidade, bem como se existem planos de contingência.
Observação: essas capturas de tela mostram um documento de política/processo, a expectativa é que os ISVs compartilhem a documentação real de política/procedimento de suporte e não simplesmente forneçam uma captura de tela.
Intenção: backups
O objetivo deste subponto é manter procedimentos documentados para fazer backup de sistemas e dados essenciais. A documentação também deve especificar as definições de configuração, bem como as políticas de agendamento e retenção de backup, para garantir que os dados sejam atuais e recuperáveis.
Diretrizes: backups
Forneça a versão completa do plano/procedimento de recuperação de desastres, que deve incluir seções que abranjam a estrutura de tópicos processada na descrição do controle. Forneça o documento PDF/WORD real se estiver em uma versão digital, alternativamente, se o processo for mantido por meio de uma plataforma online, forneça uma exportação ou capturas de tela dos processos.
Exemplo de evidência: backups
As próximas capturas de tela mostram o extrato do plano de recuperação de desastre da Contoso e que existe uma configuração de backup documentada para cada sistema. Observe que na próxima captura de tela em que o agendamento de backup também está delineado, observe que, para este exemplo, a configuração de backup é descrita como parte do plano de recuperação de desastres, pois a continuidade dos negócios e os planos de recuperação de desastres trabalham juntos.
Observação: esta captura de tela mostra um snapshot de um documento de política/procedimento, a expectativa é que os ISVs compartilhem a documentação real de política/procedimento de suporte e não simplesmente forneçam uma captura de tela.
Intenção: linhas do tempo
Esse controle tem como objetivo estabelecer cronogramas priorizados para as ações de recuperação. Esses objetivos de tempo de recuperação (RTOs) devem estar alinhados com a análise de impacto nos negócios e devem ser claramente definidos para que o pessoal entenda quais sistemas e funções devem ser restaurados primeiro.
Diretrizes: linhas do tempo
Forneça a versão completa do plano/procedimento de recuperação de desastres, que deve incluir seções que abranjam a estrutura de tópicos processada na descrição do controle. Forneça o documento PDF/WORD real se estiver em uma versão digital, alternativamente, se o processo for mantido por meio de uma plataforma online, forneça uma exportação ou capturas de tela dos processos.
Exemplo de evidência: linhas do tempo
A captura de tela a seguir mostrando a continuação das funções de negócios e a classificação de criticidade, bem como o RTO (Objetivo de Tempo de Recuperação) estabelecido.
Observação: essas capturas de tela mostram um documento de política/processo, a expectativa é que os ISVs compartilhem a documentação real de política/procedimento de suporte e não simplesmente forneçam uma captura de tela.
Intenção: recuperação
Esse controle pretende fornecer um procedimento passo a passo a ser seguido para retornar sistemas de informação críticos, funções de negócios e serviços ao status operacional. Isso deve ser detalhado o suficiente para orientar a tomada de decisões durante situações de alta pressão, onde ações rápidas e eficazes são essenciais.
Diretrizes: recuperação
Forneça a versão completa do plano/procedimento de recuperação de desastres, que deve incluir seções que abranjam a estrutura de tópicos processada na descrição do controle. Forneça o documento PDF/WORD real se estiver em uma versão digital, alternativamente, se o processo for mantido por meio de uma plataforma online, forneça uma exportação ou capturas de tela dos processos.
Exemplo de evidência: recuperação
As próximas capturas de tela mostram o extrato do nosso plano de recuperação de desastre e que existe um plano de recuperação documentado para cada sistema e função de negócios. Observe que, para este exemplo, o procedimento de recuperação do sistema faz parte do plano de recuperação de desastres, pois a continuidade dos negócios e os planos de recuperação de desastres trabalham juntos para obter recuperação/restauração completa.
Observação: essas capturas de tela mostram um documento de política/processo, a expectativa é que os ISVs compartilhem a documentação real de política/procedimento de suporte e não simplesmente forneçam uma captura de tela.
Intenção: validação
Esse ponto de controle visa garantir que o plano de continuidade de negócios inclua um processo estruturado para orientar a organização na restauração dos sistemas ao seu estado original, uma vez que a crise tenha sido gerenciada. Isso inclui etapas de validação para garantir que os sistemas estejam totalmente operacionais e mantenham sua integridade.
Diretrizes: validação
Forneça a versão completa do plano/procedimento de recuperação de desastres, que deve incluir seções que abranjam a estrutura de tópicos processada na descrição do controle. Forneça o documento PDF/WORD real se estiver em uma versão digital, alternativamente, se o processo for mantido por meio de uma plataforma online, forneça uma exportação ou capturas de tela dos processos.
Exemplo de evidência: validação
A captura de tela a seguir mostra o processo de recuperação descrito na política do plano de continuidade de negócios e as etapas/ações a serem executadas.
Observação: esta captura de tela mostra um snapshot de um documento de política/procedimento, a expectativa é que os ISVs compartilhem a documentação real de política/procedimento de suporte e não simplesmente forneçam uma captura de tela.
Controle nº 29
Fornecer evidências de que:
A documentação existe e é mantida descrevendo o Plano de Recuperação de Desastres, que inclui, no mínimo:
pessoal suas funções, responsabilidades e processo de escalonamento
Inventário dos sistemas de informação usados para dar suporte a funções e serviços críticos de negócios
Procedimentos e configuração do sistema e do backup de dados
Um plano de recuperação detalhando as ações e procedimentos a serem seguidos para restaurar a operação de sistemas de informação e dados críticos.
Intenção: DRP
O objetivo desse controle é ter funções e responsabilidades bem documentadas para cada membro da equipe de recuperação de desastres. Um processo de escalonamento também deve ser delineado para garantir que os problemas sejam rapidamente elevados e resolvidos pelo pessoal apropriado durante um cenário de desastre.
Diretrizes: DRP
Forneça a versão completa do plano/procedimento de recuperação de desastres, que deve incluir seções que abranjam a estrutura de tópicos processada na descrição do controle. Forneça o documento PDF/WORD real se estiver em uma versão digital, alternativamente, se o processo for mantido por meio de uma plataforma online, forneça uma exportação ou capturas de tela dos processos.
Exemplo de evidência: DRP
As próximas capturas de tela mostram o extrato de um plano de recuperação de desastre e que ele existe e é mantido.
Observação: essas capturas de tela mostram um documento de política/processo, a expectativa é que os ISVs compartilhem a documentação real de política/procedimento de suporte e não simplesmente forneçam uma captura de tela.
A próxima captura de tela mostra um extrato da política em que o "Plano de Contingência" está descrito, incluindo equipe relevante, detalhes de contato e etapas de escalonamento.
Intenção: inventário
A intenção por trás desse controle é manter uma lista de inventário atualizada de todos os sistemas de informação que são cruciais para suportar as operações comerciais. Essa lista é fundamental para entender quais sistemas devem ser priorizados durante um esforço de recuperação de desastres.
Diretrizes: inventário
Forneça a versão completa do plano/procedimento de recuperação de desastres, que deve incluir seções que abranjam a estrutura de tópicos processada na descrição do controle. Forneça o documento PDF/WORD real se estiver em uma versão digital, alternativamente, se o processo for mantido por meio de uma plataforma online, forneça uma exportação ou capturas de tela dos processos.
Exemplo de evidência: inventário
As próximas capturas de tela mostram o extrato de um DRP e que existe um inventário de sistemas críticos e seu nível de criticidade, bem como funções do sistema.
Observação: essas capturas de tela mostram um documento de política/processo, a expectativa é que os ISVs compartilhem a documentação real de política/procedimento de suporte e não simplesmente forneçam uma captura de tela.
A próxima captura de tela mostra a definição de classificação e criticidade do serviço.
Observação: essas capturas de tela mostram um documento de política/processo, a expectativa é que os ISVs compartilhem a documentação real de política/procedimento de suporte e não simplesmente forneçam uma captura de tela.
Intenção: backups
Esse controle exige que procedimentos bem definidos para backups do sistema e dos dados estejam em vigor. Esses procedimentos devem descrever a frequência, a configuração e os locais dos backups para garantir que todos os dados críticos possam ser restaurados em caso de falha ou desastre.
Diretrizes: backups
Forneça a versão completa do plano/procedimento de recuperação de desastres, que deve incluir seções que abranjam a estrutura de tópicos processada na descrição do controle. Forneça o documento PDF/WORD real se estiver em uma versão digital, alternativamente, se o processo for mantido por meio de uma plataforma online, forneça uma exportação ou capturas de tela dos processos.
Exemplo de evidência: backups
As próximas capturas de tela mostram o extrato de um plano de recuperação de desastre e que existe uma configuração de backup documentada para cada sistema. Observe abaixo que o agendamento de backup também está descrito.
Observação: essa captura de tela mostra um snapshot de um documento de política/processo, a expectativa é que os ISVs compartilhem a documentação real de política/procedimento de suporte e não simplesmente forneçam uma captura de tela.
Intenção: recuperação
Esse controle exige um plano de recuperação abrangente que descreve procedimentos passo a passo para restaurar sistemas e dados vitais. Isso serve como um roteiro para a equipe de recuperação de desastres e garante que todas as ações de recuperação sejam premeditadas e eficazes na restauração das operações comerciais.
Diretrizes: recuperação
Forneça a versão completa do plano/procedimento de recuperação de desastres, que deve incluir seções que abranjam a estrutura de tópicos processada na descrição do controle. Forneça o documento PDF/WORD real se estiver em uma versão digital, alternativamente, se o processo for mantido por meio de uma plataforma online, forneça uma exportação ou capturas de tela dos processos.
Exemplo de evidência: recuperação
As próximas capturas de tela mostram o extrato de um plano de recuperação de desastre e que uma substituição de equipamento e etapas e instruções de recuperação do sistema existem e estão documentadas, bem como o procedimento de recuperação que inclui prazos de recuperação, ações a serem tomadas para restaurar a infraestrutura de nuvem, etc.
Observação: essa captura de tela mostra um snapshot de um documento de política/processo, a expectativa é que os ISVs compartilhem a documentação real de política/procedimento de suporte e não simplesmente forneçam uma captura de tela.
Controle nº 30
Fornecer evidências de que:
Os Planos de Continuidade de Negócios e Recuperação de Desastres são revisados pelo menos anualmente para garantir que permaneçam válidos e eficazes durante situações adversas.
Todo o pessoal relevante recebe treinamento sobre suas funções e responsabilidades atribuídas nos planos de contingência.
Ambos os planos estão sendo testados por meio de exercícios anuais de continuidade de negócios e recuperação de desastres.
Ambos os planos são atualizados com base nas lições aprendidas com a promulgação dos planos ou por meio dos exercícios anuais, ou atualizados após mudanças organizacionais significativas.
Intenção: revisão anual
O objetivo desse controle é garantir que os planos de continuidade de negócios e recuperação de desastres sejam revisados anualmente. A revisão deve confirmar que os planos ainda são eficazes, precisos e alinhados com os objetivos de negócios e arquiteturas tecnológicas atuais.
Intenção: treinamento anual
Esse controle exige que todos os indivíduos com funções designadas nos planos de continuidade de negócios e recuperação de desastres recebam treinamento adequado anualmente. O objetivo é garantir que eles estejam cientes de suas responsabilidades e sejam capazes de executá-las de forma eficaz em caso de desastre ou interrupção dos negócios.
Intenção: exercícios
A intenção aqui é validar a eficácia dos planos de continuidade de negócios e recuperação de desastres por meio de exercícios do mundo real. Esses exercícios devem ser projetados para simular várias condições adversas para testar o quão bem a organização pode sustentar ou restaurar as operações comerciais.
Intenção: análise
O ponto de controle final visa a documentação completa de todos os resultados do teste, incluindo uma análise do que funcionou bem e do que não funcionou. As lições aprendidas devem ser integradas de volta aos planos e quaisquer deficiências devem ser abordadas imediatamente para melhorar a resiliência da organização.
Diretrizes: revisões
Evidências como relatórios, notas de reuniões e resultados dos exercícios anuais de continuidade de negócios e planos de recuperação de desastres devem ser fornecidas para revisão.
Exemplo de evidência: revisões
As capturas de tela a seguir mostram uma saída de relatório de um exercício de plano de continuidade dos negócios e recuperação de desastres, no qual um cenário foi estabelecido para permitir que a equipe implemente o plano de continuidade dos negócios e recuperação de desastres, além de percorrer a situação até a restauração bem-sucedida das funções de negócios e da operação do sistema.
Observação: essas capturas de tela mostram snapshot de um documento de política/processo, a expectativa é que os ISVs compartilhem a documentação real de política/procedimento de suporte e não simplesmente forneçam uma captura de tela.
Observação: essas capturas de tela mostram snapshot de um documento de política/processo, a expectativa é que os ISVs compartilhem a documentação real de política/procedimento de suporte e não simplesmente forneçam uma captura de tela.