Guia de Submissão de Certificação do Microsoft 365

Neste artigo:

• Introdução
• Pré-requisitos
• Atualizações das Especificações de Certificação do Microsoft 365
• Âmbito de Certificação
• Processo de Certificação
• Submissão inicial do Documento
• Atividades de Recolha e Avaliação de Provas
• Critérios de Certificação
• Segurança de Aplicativo
• Segurança Operacional
• Segurança e Privacidade do Processamento de Dados
• Revisão opcional das Arquiteturas de Conformidade Externa
• Apêndice A
• Apêndice B
• Apêndice C
• Apêndice D
• Apêndice E
• Apêndice F
• Apêndice G
• Saiba Mais
• Glossário

Introdução

Parte do programa de Conformidade de Aplicações do Microsoft 365, a Certificação do Microsoft 365 oferece garantia e confiança às organizações empresariais de que os dados e a privacidade estão devidamente protegidos e protegidos ao integrar aplicações/suplementos para programadores de terceiros na plataforma do Microsoft 365. As aplicações e os suplementos que passam a validação serão designados Como Certificado do Microsoft 365 em todo o ecossistema do Microsoft 365.

Ao participar no programa de Certificação do Microsoft 365, está a concordar com estes termos suplementares e a cumprir qualquer documentação associada que se aplique à sua participação no programa de Certificação do Microsoft 365 com a Microsoft Corporation ("Microsoft", "nós", "nós" ou "nosso"). O Utilizador representa e garante-nos que tem autoridade para aceitar estes termos suplementares de Certificação do Microsoft 365 em nome de si, de uma empresa e/ou de outra entidade, conforme aplicável. Podemos alterar, alterar ou cessar estes termos suplementares em qualquer altura. A sua participação contínua no programa de Certificação do Microsoft 365 após qualquer alteração ou emenda significa que concorda com os novos termos suplementares. Se não concordar com os novos termos suplementares ou se terminarmos estes termos suplementares, tem de deixar de participar no programa de Certificação do Microsoft 365.

Este documento destina-se a ISVs (Fabricantes Independentes de Software) para fornecer informações sobre o processo de Certificação do Microsoft 365, pré-requisitos para iniciar o processo e detalhes de controlos de segurança específicos que os ISVs têm de ter implementados. As informações gerais do programa de Conformidade de Aplicações do Microsoft 365 podem ser encontradas na página Programa de Conformidade de Aplicações do Microsoft 365.

Pré-requisitos

Atestado do Editor

Antes de receber o processo de Certificação do Microsoft 365, tem de ter concluído o Atestado do Publisher. No entanto, pode iniciar o processo de Certificação do Microsoft 365 antes de concluir o Atestado do Publisher.

Ler a Especificação de Certificação do Microsoft 365

A Microsoft recomenda que todos os ISVs (Fabricante Independente de Software) leiam esta Especificação de Certificação do Microsoft 365 na sua totalidade para garantir que todos os controlos aplicáveis estão a ser cumpridos pelo ambiente no âmbito e pela aplicação/suplemento. Isto ajudará a garantir um processo de avaliação suave.

Atualizações das Especificações de Certificação do Microsoft 365

As atualizações à especificação de Certificação do Microsoft 365 são antecipadas aproximadamente a cada seis a 12 meses. Estas atualizações podem introduzir novos domínios de segurança de destino e/ou controlos de segurança. As atualizações basear-se-ão nos comentários dos programadores, nas alterações ao panorama das ameaças e no aumento da linha de base de segurança do programa à medida que amadurece.

Os ISVs que já iniciaram a avaliação da Certificação do Microsoft 365 podem continuar a avaliação com a versão da Especificação de Certificação do Microsoft 365 que era válida quando a avaliação foi iniciada. Todas as novas submissões, incluindo a recertificação anual, terão de ser avaliadas em relação à versão publicada.

Âmbito de Certificação

O ambiente no âmbito é o ambiente que suporta a entrega do código de aplicação/suplemento e suporta quaisquer sistemas de back-end com os quais a aplicação/suplemento possa estar a comunicar. Quaisquer ambientes ligados adicionais também serão incluídos no âmbito, a menos que esteja implementada uma segmentação adequada E os ambientes ligados a não possam afetar a segurança do ambiente no âmbito. Todos os ambientes de recuperação após desastre também terão de ser incluídos no âmbito da avaliação, uma vez que estes ambientes seriam necessários para satisfazer o serviço caso algo acontecesse ao ambiente primário. O termo componentes do sistema no âmbito referencia todos os dispositivos e sistemas que são utilizados no ambiente no âmbito. Os componentes no âmbito incluem, mas não estão limitados a:

• As aplicações Web.
• Servidores.
• Firewalls (ou equivalente).
• Comutadores.
• Balanceadores de carga.
• Infraestrutura virtual.
• Portais de gestão Web do fornecedor de cloud

Infraestrutura como Um Serviço (IaaS), Plataforma como Serviço (PaaS) e Software como um Serviço (SaaS)

Quando IaaS e/ou PaaS são utilizados para suportar a infraestrutura da aplicação ou a entrega de código do suplemento em análise, o fornecedor da plataforma cloud será responsável por alguns dos controlos de segurança avaliados ao longo do processo de certificação. Por conseguinte, os analistas de certificação terão de ser fornecidos com uma verificação externa independente das melhores práticas de segurança pelo fornecedor da plataforma cloud através de relatórios de conformidade externos, como relatórios do Tipo II [PCI DSS ISO27001].

O Apêndice F fornece detalhes sobre quais os controlos de segurança que provavelmente serão aplicáveis com base nos seguintes tipos de implementação e com base no facto de a aplicação/suplemento exfiltrar ou não os dados do Microsoft 365:

• ISV Alojado
• IaaS Alojado
• PaaS/Alojado Sem Servidor
• Alojado Híbrido
• Alojado Partilhado

Quando a IaaS ou a PaaS estiverem implementadas, terá de fornecer provas de que o ambiente está a ser alojado nestes tipos de implementação.

Amostragem

Os pedidos de provas de suporte da avaliação de certificação devem basear-se numa amostra dos componentes do sistema no âmbito, tendo em conta os diferentes sistemas operativos, a função primária do dispositivo e os diferentes tipos de dispositivo. Será selecionado um exemplo adequado no início do processo de certificação. A tabela seguinte deve ser utilizada como um guia sobre o tamanho da amostra:

Tamanho da População	Amostra
<5	1
>5 & <10	2
>9 & <25	3
>24	4

Processo de Certificação

Antes de iniciar o processo de certificação, terá de concluir com êxito o Atestado do Publisher. Depois de concluído, o processo de Certificação do Microsoft 365 prossegue da seguinte forma:

Preparação

1. Navegue para o centro de parceiros e reveja a documentação completa do Atestado do Publisher . Se necessário, pode editar e atualizar as suas respostas; No entanto, se o fizer, terá de submeter novamente a documentação do atestado para aprovação. Se a sua submissão tiver mais de três meses, será necessário submeter novamente o Atestado do Publisher para revisão e validação.
2. Leia atentamente o Guia de Submissão de Certificação do Microsoft 365 para compreender o que será necessário para si. Certifique-se de que conseguirá cumprir os requisitos de controlo especificados no Guia de Submissão de Certificação do Microsoft 365.
3. No centro de parceiros, selecione "Iniciar Certificação". Esta ação irá direcioná-lo para o portal de submissão de documentos inicial. Submeta a Submissão Inicial do Documento. Isto irá ajudar-nos a determinar o que está no âmbito da sua avaliação com base na forma como a sua aplicação é arquitetizada e processa os dados dos clientes. Consulte esta página com frequência para ver se a submissão foi aceite.

Avaliação

1. Assim que a submissão inicial do documento tiver sido aceite, o conjunto de controlos de segurança necessários para a sua aplicação será automaticamente apresentado no portal. Em seguida, terá de submeter provas para cada controlo que demonstre que o controlo está em vigor. Tenha em atenção que lhe serão dados 60 dias para submeter todas as provas. Um analista irá rever as suas provas e aprovar o controlo ou pedir provas novas ou adicionais. Consulte esta página com frequência para ver se as suas provas foram aceites.

Certificação

1. Assim que a sua submissão tiver sido validada por um analista, será notificado da sua decisão de certificação. As aplicações atribuídas a uma certificação receberão um distintivo na respetiva aplicação no AppSource e nas páginas de documentos da Microsoft . Pode ler sobre os benefícios completos da certificação aqui.

Rever e Recertificar

Se a sua aplicação sofrer alterações significativas em qualquer altura, terá de nos notificar.

Também terá de passar pela recertificação anualmente. Isto exigirá a revalidação dos controlos no âmbito em relação ao seu ambiente atual. Este processo pode começar até 90 dias antes da expiração da sua certificação. A certificação existente não expira durante o período de recertificação. A recertificação em todos os programas expira no aniversário de um ano da certificação do Microsoft 365.

Se a certificação não for renovada antes da data de expiração, o estado de certificação das aplicações será revogado. Todas as marcas de certificação, ícones e badging serão removidos da sua aplicação e estará proibido de anunciar a sua aplicação como Microsoft 365 Certified.

Submissão de Documento Inicial

A submissão inicial do documento ajudará os analistas de certificação a efetuar o âmbito e a determinar o que estará no âmbito da sua avaliação. Após isso, terá de submeter documentação de suporte e provas utilizadas para realizar a avaliação. A submissão inicial tem de incluir as informações especificadas abaixo. Para obter orientações adicionais, veja o Guia de Submissão inicial de documentos.

Descrição Geral da Documentação	Detalhes da Documentação
Descrição da Aplicação/Suplemento	Uma descrição da finalidade e funcionalidade da aplicação/suplemento. Isto deve fornecer ao analista de certificação uma boa compreensão de como a aplicação/suplemento funciona e qual é a utilização pretendida
Relatório de Testes de Penetração	Um relatório de testes de penetração foi concluído nos últimos 12 meses. Este relatório tem de incluir o ambiente que suporta a implementação da aplicação/adicionar juntamente com qualquer ambiente adicional que suporte o funcionamento da aplicação/suplemento. Nota: se não fizer testes anuais de penetração, pode optar por fazê-los através do processo de certificação.
Diagramas de arquitetura	Um diagrama de arquitetura lógica que representa uma descrição geral de alto nível da infraestrutura de suporte da aplicação/suplemento. Isto tem de incluir todos os ambientes de alojamento e a infraestrutura de suporte que suporta a aplicação/suplemento. Este diagrama TEM de ilustrar todos os diferentes componentes do sistema de suporte no ambiente para ajudar os analistas de certificação a compreender os sistemas no âmbito e a ajudar a determinar a amostragem. Indique também que tipo de ambiente de alojamento é utilizado; ISV Alojado, IaaS, PaaS ou Híbrido. Nota: Quando o SaaS for utilizado, indique os vários serviços SaaS que são utilizados para fornecer os serviços de suporte no ambiente.
Espaço Público	Detalhar todos os ENDEREÇOS IP públicos e URLs utilizados pela infraestrutura de suporte. Isto deve incluir o intervalo de IP encaminhável completo alocado ao ambiente, a menos que tenha sido implementada uma segmentação adequada para dividir o intervalo em utilização (será necessária uma prova adequada da segmentação)
Diagramas de fluxo de dados	Diagramas de fluxo que detalham o seguinte:
	✓ Os dados do Microsoft 365 fluem de e para a Aplicação/Suplemento (incluindo EUII e OII ).
	✓ Fluxos de dados do Microsoft 365 na infraestrutura de suporte (quando aplicável)
	✓ Diagramas que realçam onde e que dados são armazenados, como os dados são transmitidos a terceiros externos (incluindo detalhes de que terceiros) e como os dados são protegidos em trânsito através de redes abertas/públicas e inativos.
Detalhes do Ponto Final da API	Uma lista completa de todos os Pontos Finais da API utilizados pela sua aplicação. Para ajudar a compreender o âmbito do ambiente, forneça localizações do ponto final da API no seu ambiente.
Permissões da API da Microsoft	Forneça documentação que detalha todas as APIs da Microsoft que são utilizadas juntamente com as permissões que estão a ser pedidas para a aplicação/suplemento funcionar, juntamente com uma justificação para as permissões pedidas
Tipos de armazenamento de dados	Armazenamento de dados e processamento de documentos que descrevem:
	✓ Até que ponto os clientes Microsoft 365 Data EUII e OII estão a ser recebidos e armazenados
	✓ O período de retenção de dados.
	✓ Por que motivo os Dados do Microsoft 365 do cliente estão a ser capturados.
	✓ Onde os Dados do Microsoft 365 do cliente são armazenados (devem ser incluídos nos diagramas de fluxo de dados fornecidos acima).
Confirmação de conformidade	Documentação de suporte para estruturas de segurança externas incluídas na submissão do Atestado do Publisher ou a considerar ao rever os controlos de Certificação do Microsoft 365. Atualmente, são suportados os três seguintes:
	✓ Atestado PCI DSS de Conformidade (AOC).
	✓ Relatórios SOC 2 Tipo I/Tipo II.
	✓ Declaração de Aplicabilidade (SoA) e Certificação do ISMS / IEC - 1S0/IEC 27001.
Dependências Web	Documentação que lista todas as dependências utilizadas pela aplicação/suplemento com as versões em execução atuais.
Inventário de Software	Um inventário de software atualizado que inclui todo o software utilizado no ambiente no âmbito, juntamente com as versões.
Inventário de Hardware	Um inventário de hardware atualizado utilizado pela infraestrutura de suporte. Isto será utilizado para ajudar na amostragem ao realizar a fase de avaliação. Se o seu ambiente incluir PaaS, forneça detalhes sobre os serviços consumidos.

Atividades de Recolha e Avaliação de Provas

Os analistas de certificação terão de rever as provas em todos os componentes do sistema no conjunto de exemplo definido. Os tipos de provas necessários para suportar o processo de avaliação incluem qualquer um ou todos os seguintes:

Recolha de Provas

• Documentação inicial realçada na secção Submissão da Documentação Inicial acima
• Documentos de política
• Processar documentos
• Definições de configuração do sistema
• Alterar bilhetes
• Alterar registos de controlo
• Relatórios do sistema

Serão utilizados vários métodos para recolher as provas necessárias para concluir o processo de avaliação. Esta recolha de provas pode ter a forma de:

• Documentos
• Capturas de tela
• Entrevistas
• Partilha de ecrã

As técnicas de recolha de provas utilizadas serão determinadas durante o processo de avaliação. Para obter exemplos concretos do tipo de provas necessárias na sua submissão, veja o Guia de Provas de Exemplo.

Atividades de Avaliação

Os analistas de certificação irão rever as provas que fornecer para determinar se cumpriu adequadamente os controlos nesta Especificação de Certificação do Microsoft 365.

Sempre que possível e para reduzir a quantidade de tempo necessário para concluir a avaliação, qualquer ou toda a documentação detalhada na Submissão da Documentação Inicial deve ser fornecida com antecedência.

Os analistas de certificação irão primeiro rever os elementos de prova fornecidos a partir da submissão da documentação inicial e as informações do Atestado do Publicador para identificar as linhas adequadas de consulta, o tamanho da amostragem e a necessidade de obter mais provas, conforme detalhado acima. Os analistas de certificação irão analisar todas as informações recolhidas para tirar conclusões sobre como e se está a cumprir os controlos nesta Especificação de Certificação do Microsoft 365.

Critérios de Certificação de Aplicações

A sua aplicação, a infraestrutura de suporte e a documentação de suporte serão avaliadas nos seguintes domínios de segurança:

1. Segurança de Aplicativo
2. Segurança Operacional/Implementação Segura
3. Segurança e Privacidade do Processamento de Dados

Cada um destes domínios de segurança inclui controlos chave específicos que abrangem um ou mais requisitos específicos que serão avaliados como parte do processo de avaliação. Para garantir que a Certificação do Microsoft 365 é inclusiva para programadores de todos os tamanhos, cada um dos domínios de segurança é avaliado através de um sistema de classificação para determinar uma classificação geral de cada um dos domínios. As classificações para cada um dos controlos de Certificação do Microsoft 365 são alocadas entre 1 (baixa) e 3 (alta) com base no risco percebido de que esse controlo não é cumprido. Cada um dos domínios de segurança terá uma marca de percentagem mínima para ser considerado um passe. Alguns elementos desta especificação incluem alguns critérios de falha automática:

• As permissões da API não seguem o princípio do menor privilégio (PoLP).
• Não existem relatórios de testes de penetração quando são necessários.
• Sem defesas antimalware
• A autenticação multifator não está a ser utilizada para proteger o acesso administrativo.
• Sem processos de aplicação de patches.
• Nenhum aviso de privacidade do RGPD adequado.

Segurança de Aplicativo

O domínio de segurança da aplicação concentra-se nas três áreas seguintes:

• Validação de Permissão do GraphAPI
• Verificações de Conectividade Externa
• Testes de Segurança de Aplicações

Validação de Permissão do GraphAPI

A validação da permissão GraphAPI é realizada para validar que a aplicação/suplemento não pede permissões excessivamente permissivas. Isto é realizado ao verificar manualmente que permissões são pedidas. Os analistas de certificação irão fazer referência cruzada a estas verificações relativamente à submissão do Atestado do Publisher e avaliar o nível de acesso que está a ser pedido para garantir que as práticas de "privilégio mínimo" estão a ser cumpridas. Quando os analistas de certificação acreditam que estas práticas de "privilégio mínimo" não estão a ser cumpridas, os analistas de certificação terão uma discussão aberta consigo para validar a justificação comercial para as permissões que estão a ser pedidas. Quaisquer discrepâncias em relação à submissão do Atestado do Publisher encontradas durante esta revisão também receberão feedback para que o atestado do Publisher possa ser atualizado.

Verificações de Conectividade Externa

Como parte da avaliação, um Analista irá realizar um guia claro da funcionalidade das aplicações para identificar ligações fora do Microsoft 365. Quaisquer ligações que não sejam identificadas como sendo da Microsoft ou ligações diretas ao seu serviço serão sinalizadas e abordadas durante a avaliação.

Testes de Segurança de Aplicações

Uma revisão adequada dos riscos associados à sua aplicação/suplemento e ambiente de suporte é essencial para fornecer aos clientes garantias sobre a segurança da aplicação/suplemento. Os testes de segurança de aplicações sob a forma de testes de penetração têm de ser realizados se a sua aplicação tiver alguma conectividade a qualquer serviço não publicado pela Microsoft. Se a sua aplicação funcionar autónomamente sem conectividade a qualquer serviço ou back-end que não seja da Microsoft, os testes de penetração não são necessários.

Âmbito dos Testes de Penetração

As atividades de teste de penetração TÊM de ser realizadas no ambiente de produção em direto que suporta a implementação da aplicação/suplemento (por exemplo, onde está alojado o código da aplicação/suplemento, que normalmente será o recurso no ficheiro de manifesto), juntamente com qualquer ambiente adicional que suporte o funcionamento da aplicação/suplemento (por exemplo, se a aplicação/suplemento falar com outras aplicações Web fora do Microsoft 365). Ao definir o âmbito, é necessário ter cuidado para garantir que todos os sistemas ou ambientes "ligados" que possam ter impacto na segurança do ambiente no âmbito também estão incluídos em TODAS as atividades de teste de penetração.

Quando as técnicas são utilizadas para segmentar os ambientes no âmbito de outros ambientes, as atividades de teste de penetração TÊM de validar a eficácia das técnicas de segmentação. Isto tem de ser detalhado no relatório de testes de penetração.

Os relatórios de testes de penetração serão revistos para garantir que não existem vulnerabilidades que cumpram os seguintes critérios de falha automática descritos nos controlos abaixo.

Requisitos de testes de penetração

Tipo de Critérios	Controlos de Testes de Penetração
Critérios Gerais	Controls
	Os testes de penetração de aplicações e infraestruturas têm de ser realizados anualmente (a cada 12 meses) e realizados por uma empresa independente de renome.
	A remediação de vulnerabilidades críticas e de alto risco identificadas tem de ser concluída no prazo de um mês após a conclusão do teste de penetração ou, mais cedo, consoante o processo de aplicação de patches documentado.
	Requisitos de espaço externos completos (Endereços IP, URLs, Pontos Finais da API, etc.) TEM de ser incluído no âmbito dos testes de penetração e deve ser documentado no relatório de testes de penetração.
	Os testes de penetração de aplicações Web TÊM de incluir todas as classes de vulnerabilidade; por exemplo, o OWASP Top 10 ou SANS Top 25 CWE mais recente.
	A retestação de vulnerabilidades identificadas pela empresa de testes de penetração não é necessária— a remediação e a auto-revisão são suficientes, no entanto, são suficientes provas adequadas para demonstrar que tem de ser fornecida uma remediação suficiente durante a avaliação.
Critérios de Falha Automática:	Controls
	Presença de um sistema operativo não suportado.
	Presença de contas administrativas predefinidas, enumeráveis ou adivinhos.
	Presença de riscos de injeção de SQL.
	Presença de scripts entre sites.
	Presença de vulnerabilidades do percurso do diretório (caminho do ficheiro).
	Presença de vulnerabilidades HTTP, por exemplo, Divisão de respostas de cabeçalho, Contrabando de pedidos e ataques de Dessincronização.
	Presença de divulgação do código fonte (incluindo LFI).
	Qualquer classificação crítica ou alta, conforme definido pelas diretrizes de gestão de patches cvSS.
	Qualquer vulnerabilidade técnica significativa que possa ser facilmente explorada para comprometer uma grande quantidade de EUII ou UOI.

Requisitos e Regras de Testes de Penetração Complementares

• Para ISVs que atualmente não se dedicam a testes de penetração, os testes de penetração podem ser realizados gratuitamente na Certificação do Microsoft 365. A Microsoft irá dispor e cobrir os custos de um teste de penetração até 12 dias de testes manuais. Os custos dos testes de penetração são calculados com base no número de dias necessários para testar o ambiente. Quaisquer despesas que excedam os 12 dias de teste serão da responsabilidade do ISV.
• Os ISVs serão obrigados a apresentar provas e a receber aprovação para 50% dos controlos no âmbito antes da realização do teste de penetração. Para começar, preencha a submissão inicial do documento e opte por ter testes de penetração incluídos como parte da sua avaliação. Será contactado para definir o âmbito e agendar o teste de penetração quando tiver concluído 50% dos controlos.
• O relatório emitido assim que o pentest estiver concluído será fornecido ao ISV assim que tiver concluído a certificação. Este relatório, juntamente com a Certificação do Microsoft 365, pode ser utilizado para mostrar aos potenciais clientes que o seu ambiente está seguro.
• Os ISVs também serão responsáveis por demonstrar que as vulnerabilidades identificadas no teste de penetração foram remediadas antes da atribuição de uma certificação, mas não precisam de produzir um relatório limpo.

Uma vez organizado um teste de penetração, o ISV é responsável pelas taxas associadas ao reagendamento e cancelamentos da seguinte forma:

Reagendamento da Escala Temporal de Taxas	Proporção a Pagar
Reagendar pedido recebido mais de 30 dias antes da data de início agendada.	0% a Pagar
Reagendar pedido recebido 8 a 30 dias antes da data de início agendada.	25% a Pagar
Reagendar o pedido recebido dentro de 2 a 7 dias antes da data de início agendada com uma data de remarcação da empresa.	50% a Pagar
Reagendar pedido recebido menos de 2 dias antes da data de início.	A pagar a 100%

Escala Temporal da Taxa de Cancelamento	Proporção a Pagar
O pedido de cancelamento recebeu mais de 30 dias antes da data de início agendada.	25% a Pagar
O pedido de cancelamento recebeu 8 a 30 dias antes da data de início agendada.	50% a Pagar
Pedido de cancelamento recebido no prazo de 7 dias antes da data de início agendada.	90% a Pagar

Segurança Operacional

Este domínio mede o alinhamento dos processos de infraestrutura e implementação de suporte da sua aplicação com as melhores práticas de segurança.

Controles

Família de Controlo	Controls
Proteção Contra Software Maligno - Antivírus	Forneça documentação de política que regule as práticas e procedimentos antivírus.
	Forneça provas demonstráveis de que o software antivírus está em execução em todos os componentes do sistema de amostra.
	Forneça provas de que as assinaturas antivírus estão atualizadas em todos os ambientes (dentro de 1 dia).
	Forneça provas de que o antivírus está configurado para efetuar a análise no acesso ou análise periódica em todos os componentes do sistema de exemplo. Nota: se a análise no acesso não estiver ativada, tem de ativar um mínimo de análise diária e alertas.
	Forneça provas de que o antivírus está configurado para bloquear automaticamente software maligno ou quarentena e alertas em todos os componentes do sistema de exemplo.
Controlos de Aplicação: apenas necessário se não for utilizado o antimalware tradicional	Forneça provas de que as aplicações são aprovadas antes de serem implementadas.
	Forneça provas de que existe e mantém uma lista completa de aplicações aprovadas com justificação comercial.
	Forneça documentação de suporte que detalha que o software de controlo de aplicações está configurado para cumprir mecanismos de controlo de aplicações específicos. (Exemplo: Listagem permitida: exemplo1, exemplo3, assinatura de código)
	Forneça provas de que o controlo de aplicações está configurado como documentado a partir de todos os componentes do sistema de exemplo.
Gestão de Patches - Classificação de Risco	Forneça documentação de política que regule a forma como as novas vulnerabilidades de segurança são identificadas e atribuídas uma classificação de risco.
	Forneça provas de como as novas vulnerabilidades de segurança são identificadas.
	Forneça provas que demonstrem que todas as vulnerabilidades recebem uma classificação de risco depois de identificadas.
Gestão de Patches - Aplicação de Patches	Forneça a documentação da política para a aplicação de patches de componentes do sistema no âmbito que inclua um período de tempo mínimo adequado para a aplicação de patches para vulnerabilidades críticas, de alto e médio risco; e desativação de quaisquer sistemas operativos e software não suportados.
	Forneça provas de que todos os componentes de sistema de exemplo estão a ser corrigidos.
	Forneça provas demonstrativas de que quaisquer sistemas operativos e componentes de software não suportados não são utilizados no ambiente.
Análise de vulnerabilidades	Indique a infraestrutura trimestral e os relatórios de análise de vulnerabilidades de aplicações Web. A análise tem de ser realizada relativamente a toda a quantidade de espaço público (endereços IP e URLs) e aos intervalos de IP internos.
	Forneça provas de que as remediações de vulnerabilidades identificadas durante a análise de vulnerabilidades são corrigidas de acordo com o período de aplicação de patches documentado.
Firewalls	Forneça documentação de política que regule as práticas e procedimentos de gestão da firewall.
	Forneça provas demonstrativos de que as credenciais administrativas predefinidas são alteradas antes da instalação em ambientes de produção.
	Forneça provas demonstrativas de que as firewalls estão instaladas no limite do ambiente no âmbito e instaladas entre a rede de perímetro (também conhecida como DMZ, zona desmilitarizada e sub-rede filtrada) e redes fidedignas internas.
	Forneça provas demonstrativas de que todos os acessos públicos terminam na zona desmilitarizada (DMZ).
	Forneça provas demonstráveis de que todo o tráfego permitido através da firewall passa por um processo de aprovação.
	Forneça provas demonstrativas de que a base de regras de firewall está configurada para remover o tráfego não explicitamente definido.
	Forneça provas demonstráveis de que a firewall suporta apenas criptografia forte em todas as interfaces administrativas que não são da consola.
	Forneça provas de que está a efetuar revisões de regras de firewall, pelo menos, a cada 6 meses.
Firewall de Aplicações Web (WAF) (OPCIONAL): o crédito adicional será recompensado por satisfazer os seguintes controlos.	Forneça provas de que a Firewall de Aplicações Web (WAF) está configurada para monitorizar, alertar e bloquear ativamente o tráfego malicioso.
	Forneça provas demonstráveis de que a WAF suporta a descarga de SSL.
	Forneça provas de que a WAF está protegida contra algumas ou todas as seguintes classes de vulnerabilidades de acordo com o Conjunto de Regras Do OWASP Core (3.0 ou 3.1)
Alterar Controlo	Forneça a documentação da política que rege os processos de controlo de alterações.
	Forneça provas de que os ambientes de desenvolvimento e teste impõem a separação de deveres do ambiente de produção.
	Forneça provas de que os dados de produção confidenciais não são utilizados nos ambientes de desenvolvimento ou teste.
	Forneça provas de que os pedidos de alteração documentados contêm o impacto da alteração, os detalhes dos procedimentos de back-out e os testes a serem realizados.
	Forneça provas de que os pedidos de alteração são submetidos a um processo de autorização e fim de sessão.
Desenvolvimento/Implementação de Software Seguro	Forneça políticas e procedimentos que suportem desenvolvimento e implementação de software seguro, incluindo orientações de melhores práticas de codificação segura contra classes de vulnerabilidade comuns, tais como OWASP Top 10 ou SANS Top 25 CWE.
	Forneça provas de que as alterações ao código são submetidas a um processo de revisão e autorização por um segundo revisor.
	Forneça provas de que os programadores são submetidos anualmente a uma formação segura de desenvolvimento de software.
	Forneça provas de que os repositórios de código estão protegidos com a autenticação multifator (MFA).
	Forneça provas de que os controlos de acesso estão implementados para proteger os repositórios de código.
Gestão de Contas	Forneça documentação de política que regule as práticas e procedimentos de gestão de contas.
	Forneça provas de que as credenciais predefinidas estão desativadas, removidas ou alteradas nos componentes do sistema de exemplo.
	Forneça provas de que a criação, modificação e eliminação da conta passam por um processo de aprovação estabelecido.
	Forneça provas de que está em vigor um processo para desativar ou eliminar contas não utilizadas no prazo de 3 meses.
	Forneça provas de que existe uma política de palavras-passe forte ou outras mitigações adequadas para proteger as credenciais do utilizador. O seguinte deve ser utilizado como uma orientação mínima: comprimento mínimo da palavra-passe de 8 carateres, limiar de bloqueio de conta não superior a 10 tentativas, histórico de palavras-passe com um mínimo de 5 palavras-passe, imposição da utilização de palavra-passe segura
	Forneça provas de que são emitidas contas de utilizador exclusivas a todos os utilizadores.
	Forneça provas de que os princípios de menor privilégio estão a ser seguidos no ambiente.
	Forneça provas de que está em curso um processo para proteger ou proteger contas de serviço e que o processo está a ser seguido.
	Forneça provas de que a MFA está configurada para todas as ligações de acesso remoto e todas as interfaces administrativas não consola.
	Forneça provas de que a encriptação forte está configurada para todas as ligações de acesso remoto e todas as interfaces administrativas não consola, incluindo o acesso a quaisquer repositórios de código e interfaces de gestão da cloud.
	Forneça provas de que a MFA é utilizada para proteger o portal de administração que utiliza para gerir e manter todos os registos do serviço de nome de domínio público (DNS).
Deteção e Prevenção de Intrusões (OPCIONAL): O crédito adicional será recompensado por satisfazer os seguintes controlos	Forneça provas de que os Sistemas de Deteção e Prevenção de Intrusões (IDPS) estão implementados no perímetro dos ambientes no âmbito.
	Forneça provas de que as assinaturas IDPS são mantidas atualizadas (dentro de 24 horas).
	Forneça provas de que o IDPS está configurado para suportar a inspeção TLS de todo o tráfego da Web recebido.
	Forneça provas de que o IDPS está configurado para monitorizar todos os fluxos de tráfego de entrada.
	Forneça provas de que o IDPS está configurado para monitorizar todos os fluxos de tráfego de saída.
Registo de Eventos de Segurança	Forneça documentação de política para melhores práticas e procedimentos que regem o registo de eventos de segurança.
	Forneça provas demonstrativas de que o registo de eventos de segurança está configurado em todos os componentes de sistema de exemplo para registar os seguintes eventos: Acesso do utilizador aos componentes do sistema e à aplicação, Todas as ações realizadas por um utilizador com privilégios elevados, Acesso lógico inválido tenta a criação ou modificação da conta com privilégios, Adulteração do registo de eventos, Desativação de ferramentas de segurança (como registo de eventos ou antimalware), registo antimalware (como atualizações, deteção de software maligno e falhas de análise)., eventos de IDPS e WAF, se configurados
	Forneça provas de que os eventos de segurança registados contêm as seguintes informações mínimas: Utilizador, Tipo de evento, Data e hora, Indicadores de êxito ou falha, Etiqueta que identifica o sistema afetado
	Forneça provas de que todos os componentes de sistema de exemplo são sincronizados com o tempo para os mesmos servidores primários e secundários.
	Forneça provas de que, quando os sistemas destinados ao público estão a ser utilizados, os registos de eventos de segurança estão a ser enviados para uma solução de registo centralizada que não está dentro da rede de perímetro.
	Forneça provas demonstráveis para mostrar que a solução de registo centralizada está protegida contra adulteração não autorizada de dados de registo.
	Forneça provas demonstráveis de que um mínimo de 30 dias de dados de registo de eventos de segurança estão imediatamente disponíveis, com 90 dias de registos de eventos de segurança retidos.
Revisões do Registo de Eventos de Segurança	Forneça documentação de política que regule as práticas e procedimentos de revisão de registos.
	Forneça provas demonstráveis de que os registos são revistos diariamente por uma ferramenta humana ou automatizada para identificar potenciais eventos de segurança.
	Forneça provas demonstrativas de que potenciais anomalias e eventos de segurança são investigados e remediados.
Alertas	Forneça documentação de política que regule os procedimentos e práticas de alerta de eventos de segurança.
	Forneça provas demonstráveis de que os alertas são acionados para triagem imediata para os seguintes tipos de eventos de segurança: Criação ou modificações de conta com privilégios, Eventos de vírus ou software maligno, Adulteração do registo de eventos, eventos de IDPS ou WAF
	Forneça provas demonstráveis que mostrem que os funcionários estão sempre disponíveis, todos os dias, para responder a alertas de segurança.
Gerenciamento de risco	Forneça provas de que é estabelecido um processo formal de gestão de riscos de segurança de informações.
	Forneça provas demonstráveis de que uma avaliação formal de riscos ocorre anualmente, no mínimo.
	Forneça provas demonstráveis de que a avaliação de riscos de segurança de informações inclui ameaças, vulnerabilidades ou o equivalente.
	Forneça provas demonstráveis de que a avaliação do risco de segurança de informações inclui impacto, matriz de risco de probabilidade ou equivalente.
	Forneça provas demonstráveis de que a avaliação de riscos de segurança de informações inclui um registo de riscos e um plano de tratamento.
Resposta a incidentes	Indique o plano de resposta a incidentes de segurança (IRP).
	Forneça provas demonstráveis de que o IRP de segurança inclui um processo de comunicação documentado para garantir uma notificação oportuna aos principais intervenientes, tais como marcas de pagamento e adquirentes, entidades reguladoras, autoridades de supervisão, diretores e clientes.
	Forneça provas demonstráveis de que todos os membros da equipa de resposta a incidentes concluíram a formação anual ou um exercício de topo de tabela.
	Forneça provas demonstrativas para mostrar que o IRP de segurança é atualizado com base nas lições aprendidas ou nas alterações organizacionais.

Segurança e Privacidade do Processamento de Dados

Os dados em trânsito entre o utilizador da aplicação, os serviços intermediários e os sistemas do ISV terão de ser protegidos pela encriptação através de uma ligação TLS que suporte um mínimo de TLS v1.1. ConsulteApêndice A.

Quando a sua aplicação obtém e armazena os dados do Microsoft 365, terá de implementar um esquema de encriptação de armazenamento de dados que siga a especificação, conforme definido no Apêndice B.

Controles

Família de Controlo	Controls
Dados em Trânsito	Forneça provas de que a configuração do TLS cumpre ou excede os requisitos de encriptação nos requisitos de configuração do perfil TLS
	Forneça provas de que a compressão TLS está desativada em todos os serviços destinados ao público que processam pedidos Web.
	Forneça provas de que a segurança de transporte estrita http do TLS está ativada e configurada para >= 15552000 em todos os sites.
Dados inativos	Forneça provas de que os dados inativos são encriptados inline com os requisitos do perfil de encriptação, utilizando algoritmos de encriptação como AES, Blowfish, TDES e tamanhos de chave de encriptação de 128 bits e 256 bits.
	Forneça provas de que a função hash ou a autenticação de mensagens (HMAC-SHA1) só é utilizada para proteger dados inativos inline com requisitos de perfil de encriptação.
	Forneça um inventário que mostre todos os dados armazenados, incluindo a localização de armazenamento e a encriptação utilizadas para proteger os dados.
Retenção e descarte de dados	Forneça provas de que é formalmente estabelecido um período de retenção de dados aprovado e documentado.
	Forneça provas de que os dados retidos correspondem ao período de retenção definido.
	Forneça provas de que os processos estão em vigor para eliminar dados de forma segura após o respetivo período de retenção.
Gestão de Acesso a Dados	Forneça uma lista de todas as pessoas com acesso a dados ou chaves de encriptação, incluindo a justificação comercial.
	Forneça provas de que os indivíduos de exemplo que têm acesso a dados ou chaves de encriptação foram formalmente aprovados, detalhando os privilégios necessários para a função de trabalho.
	Forneça provas de que os indivíduos de exemplo que têm acesso a dados ou chaves de encriptação têm apenas os privilégios incluídos na aprovação.
	Forneça uma lista de todos os terceiros com os quais os dados do cliente são partilhados.
	Forneça provas de que todos os terceiros que consomem dados de clientes têm contratos de partilha implementados.
RGPD (Se aplicável)	Forneça um processo documentado de pedido de acesso a requerentes (SAR) e forneça provas que demonstrem que os titulares dos dados são capazes de gerar SARs.
	Forneça provas de que é capaz de identificar todas as localizações dos dados dos titulares dos dados ao responder a uma SAR.
	Mantém um aviso de privacidade que deve conter os detalhes das empresas (Nome, Endereço, etc.).
	Mantém um aviso de privacidade que deve explicar os tipos de dados pessoais que estão a ser processados.
	Mantém um aviso de privacidade que deve explicar a legalidade do processamento de dados pessoais
	Mantém um aviso de privacidade que explica detalhadamente os direitos do titular dos dados: Direito a ser informado, Direito de acesso pelo titular dos dados, Direito à eliminação, Direito à restrição de processamento, Direito à portabilidade de dados, Direito a objeto, Direitos em relação à tomada de decisões automatizada, incluindo criação de perfis.
	Mantém um aviso de privacidade que deve explicar durante quanto tempo os dados pessoais serão mantidos.

Revisão opcional das Arquiteturas de Conformidade Externa

Embora não seja necessário, se estiver atualmente em conformidade com a NORMA ISO 27001, PCI DSS ou SOC2, pode optar por utilizar estas certificações para satisfazer alguns dos controlos de Certificação do Microsoft 365. Os analistas de certificação tentarão alinhar as arquiteturas de segurança externa existentes com a especificação de Certificação do Microsoft 365. No entanto, se a documentação de suporte não conseguir garantir que os controlos de Certificação do Microsoft 365 foram avaliados como parte da auditoria/avaliação das arquiteturas de segurança externas, terá de fornecer provas adicionais de que esses controlos estão em vigor.

A documentação tem de demonstrar adequadamente que o ambiente no âmbito da Certificação do Microsoft 365 foi incluído no âmbito destas estruturas de segurança externas. A validação destas estruturas de segurança será cumprida ao aceitar provas de certificações válidas realizadas por empresas externas de renome. Estas empresas de renome devem ser membros de organismos internacionais de acreditação para programas de conformidade relevantes. Veja Normas de Certificação e Conformidade ISO para ISO 27001 e Avaliadores de Segurança Qualificados (QSA) para PCI DSS.

A tabela seguinte destaca as arquiteturas externas e a documentação exigida pelos analistas de certificação como parte deste processo de validação:

Standard	Requisitos
ISO 27001	Será necessária uma versão pública da Declaração de Aplicabilidade (SOA) e uma cópia do certificado ISO 27001 emitido. A SOA resume a sua posição sobre cada um dos 114 controlos de segurança de informações e será utilizada para identificar se existe alguma exclusão de controlos que não sejam satisfatoriamente detalhados no certificado ISO 27001. Se isto não puder ser determinado ao rever a versão pública da SOA, o analista poderá precisar de acesso ao SOA completo se a ISO 27001 for utilizada para validar alguns dos controlos de Especificação de Certificação do Microsoft 365. Além de validar o âmbito das atividades de avaliação iso 27001, os analistas também confirmarão a validade da empresa de auditoria, conforme descrito acima.
PCI DSS	Tem de ser fornecido um documento válido do Atestado de Conformidade (AOC) de Nível 1 que identifique claramente a aplicação no âmbito e os componentes do sistema. Uma AOC de autoavaliação não será aceite como prova do cumprimento das melhores práticas de segurança. O AOC será utilizado para determinar quais dos controlos de Especificação de Certificação do Microsoft 365 foram avaliados e confirmados como parte da avaliação do PCI DSS.
SOC 2	O relatório SOC 2 (Tipo I ou Tipo II) tem de estar atualizado (emitido nos últimos 15 meses e o período de tempo declarado iniciado nos últimos 27 meses) para ser utilizado como prova de conformidade com qualquer um dos controlos de avaliação nesta Especificação de Certificação do Microsoft 365.

Se as arquiteturas de segurança externas tiverem sido incluídas no Atestado do Publicador, os analistas de certificação terão de verificar a validade dessas arquiteturas de conformidade de segurança como parte da avaliação da Certificação do Microsoft 365.

Framework	Considerações adicionais
ISO 27001	Apêndice C: Recolha de Provas – Deltas para ISO 27001.
PCI DSS	Apêndice D: Recolha de Provas – Deltas para PCI DSS.
SOC 2	Apêndice E: Recolha de Provas – Deltas para SOC 2.

Requisitos para utilizar arquiteturas de conformidade externas

✓ O ambiente de suporte da Aplicação/Suplemento E todos os processos empresariais de suporte têm de ser incluídos no âmbito de quaisquer arquiteturas de conformidade de segurança externa suportadas e devem ser claramente indicados na documentação fornecida.

✓ Os quadros de conformidade de segurança externos suportados têm de estar atualizados, ou seja, nos últimos 12 meses (ou no prazo de 15 meses, se a reavaliação estiver a ser realizada e os elementos de prova puderem ser fornecidos).

✓ As estruturas de conformidade de segurança externa suportadas têm de ser executadas por uma empresa acreditada independente.

Apêndice A

Requisitos de configuração do Perfil TLS

Todo o tráfego de rede, seja numa rede virtual, num serviço cloud ou num datacenter, tem de ser protegido com um mínimo de TLS v1.1 (recomenda-se o TLS v1.2+) ou outro protocolo aplicável. As exceções a este requisito são:

• Redirecionamento HTTP para HTTPS. A sua aplicação pode responder através de HTTP para redirecionar clientes para HTTPS, mas a resposta não pode conter dados confidenciais (cookies, cabeçalhos, conteúdo). Não são permitidas outras respostas HTTP além de redirecionamentos para HTTPS e resposta a pesquisas de estado de funcionamento. Confira a seguir.
• Sondas de estado de funcionamento. A sua aplicação só pode responder a pesquisas de estado de funcionamento através de HTTP se as pesquisas de estado de funcionamento HTTPS não forem suportadas pela entidade de verificação.
• Acesso ao certificado. O acesso aos pontos finais CRL, OCSP e AIA para efeitos de validação de certificados e verificação de revogação é permitido através de HTTP.
• Comunicações locais. A sua aplicação pode utilizar HTTP (ou outros protocolos não protegidos) para comunicações que não saem do sistema operativo, por exemplo, ligar a um ponto final do servidor Web exposto no localhost.

A Compressão TLS TEM de ser desativada.

Apêndice B

Requisitos de Configuração do Perfil de Encriptação

Só são permitidos parâmetros e primitivos criptográficos da seguinte forma:

Criptografia simétrica

Encryption

 ✓ Só são permitidos AES, BitLocker, Blowfish ou TDES. Qualquer um dos comprimentos de chave suportados =128 são permitidos >(são permitidos 128 bits, 192 bits e 256 bits) e podem ser utilizados (são recomendadas chaves de 256 bits).

 ✓ Só é permitido o modo CBC. Todas as operações de encriptação têm de utilizar um vetor de inicialização gerado (IV) fresco e gerado aleatoriamente.

 ✓ A utilização de cifras de fluxo, como RC4, NÃO é permitida.

Funções hash

 ✓ Todos os novos códigos têm de utilizar SHA-256, SHA-384 ou SHA-512 (coletivamente denominado SHA-2). A saída pode ser truncada para um número inferior a 128 bits

 ✓ SHA-1 só pode ser utilizado por motivos de compatibilidade.

 ✓ A utilização de MD5, MD4, MD2 e outras funções hash NÃO é permitida, mesmo para aplicações não criptográficas.

Autenticação de mensagens

 ✓ Todos os novos códigos TÊM de utilizar O HMAC com uma das funções hash aprovadas. A saída do HMAC pode ser truncada para um número inferior a 128 bits.

 ✓ O HMAC-SHA1 só pode ser utilizado por motivos de compatibilidade.

 ✓ A chave HMAC TEM de ter, pelo menos, 128 bits. São recomendadas chaves de 256 bits.

Algoritmos assimétricos

Encryption

 ✓ RSA é permitido. A chave TEM de ter, pelo menos, 2048 bits e o preenchimento OAEP tem de ser utilizado. A utilização do preenchimento PKCS só é permitida por motivos de compatibilidade.

Assinaturas

 ✓ RSA é permitido. A chave TEM de ter, pelo menos, 2048 bits e o preenchimento PSS tem de ser utilizado. A utilização do preenchimento PKCS só é permitida por motivos de compatibilidade.

 ✓ECDSA é permitido. A chave TEM de ter, pelo menos, 256 bits. A curva NIST P-256, P-384 ou P-521 tem de ser utilizada.

Troca de Chaves

 ✓ ECDH é permitido. A chave TEM de ter, pelo menos, 256 bits. A curva NIST P-256, P-384 ou P-521 tem de ser utilizada.

 ✓ ECDH é permitido. A chave TEM de ter, pelo menos, 256 bits. A curva NIST P-256, P-384 ou P-521 tem de ser utilizada.

Apêndice C

Recolha de Provas – Delta para ISO 27001

Quando já obteve ISO27001 conformidade, as seguintes diferenças (lacunas) não totalmente abrangidas pela ISO 27001 terão, no mínimo, de ser revistas como parte desta Certificação do Microsoft 365.

Proteção Contra Software Maligno – Antivírus

Se a proteção contra software maligno estiver em vigor com o controlo de aplicações e for atestada no Relatório ISO 27001, não é necessária mais investigação. Se não existir nenhum controlo de aplicação, os analistas de certificação terão de identificar e avaliar provas dos mecanismos de controlo de aplicações para impedir a detonação de software maligno no ambiente. Isto irá exigir que:

• Demonstre que o software antivírus está em execução em todos os componentes do sistema de exemplo.

• Demonstre que o antivírus está configurado em todos os componentes do sistema de exemplo para bloquear automaticamente software maligno, colocar em quarentena & alerta ou alertar.

• O software antivírus tem de ser configurado para registar todas as atividades.

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

Uma vez que as auditorias ISO 27001 não avaliam especificamente esta categoria, será necessário:

• Os componentes de software e os sistemas operativos já não suportados pelo fornecedor DEVEM não ser utilizados no ambiente. As políticas de suporte TÊM de estar implementadas para garantir que os componentes de software/sistemas operativos não suportados serão removidos do ambiente e um processo para identificar quando os componentes de software têm de estar em vigor

Verificação de vulnerabilidade

Uma vez que as auditorias ISO 27001 não avaliam especificamente esta categoria, será necessário:

• Demonstrar que a análise trimestral de vulnerabilidades internas e externas é realizada.

• Confirme que a documentação de suporte está em vigor para a remediação de vulnerabilidades com base na classificação de riscos e em conformidade com a especificação seguinte:

✓ Corrija todos os problemas de risco Críticos e Altos em linha com a classificação de risco para Análise interna.

✓ Corrija todos os problemas críticos, altos e médios de risco em linha com a classificação de risco para análise externa.

✓ Demonstrar que a remediação é realizada em conformidade com a política de remediação de vulnerabilidades documentada.

Firewall – Firewalls (ou tecnologias equivalentes)

Uma vez que as auditorias ISO 27001 não avaliam especificamente esta categoria, será necessário:

• Demonstre que as firewalls estão instaladas no limite do ambiente no âmbito.

• Demonstre que as firewalls estão instaladas entre o DMZ e as redes fidedignas.

• Demonstre que todos os acessos públicos terminam na rede de perímetro.

• Demonstre que as credenciais administrativas predefinidas são alteradas antes da instalação no ambiente ativo.

• Demonstre que todo o tráfego permitido através das firewalls passa por um processo de autorização, o que resulta na documentação de todo o tráfego com uma justificação comercial.

• Demonstrar que todas as firewalls estão configuradas para remover o tráfego não definido explicitamente.

• Demonstre que as firewalls suportam apenas criptografia forte em todas as interfaces administrativas não consola.

• Demonstre que as interfaces administrativas não consola da firewall expostas à MFA de suporte da Internet.

• Demonstrar que as revisões de regras de firewall são realizadas pelo menos a cada 6 meses

Firewall – Firewalls de Aplicações Web (WAF)

Será fornecido crédito adicional se uma WAF for implementada para ajudar a proteger contra a miríade de ameaças e vulnerabilidades de aplicações Web às quais a aplicação pode ser exposta. Quando estiver presente uma WAF ou semelhante, será necessário:

• Demonstrar que a WAF está configurada no modo de defesa ativa ou monitorizar mais com alertas.

• Demonstrar que a WAF está configurada para suportar a Descarga de SSL.

• Está configurado de acordo com o Conjunto de Regras Principais do OWASP (3.0 ou 3.1) para proteger contra a maioria dos seguintes tipos de ataque:

✓ Problemas de protocolo e codificação.

✓ Injeção de cabeçalho, contrabando de pedidos e divisão de respostas.

✓ Ataques de passagem de ficheiros e caminhos.

✓ Ataques de inclusão remota de ficheiros (RFI).

✓ Ataques de execução remota de código.

✓ Ataques de injeção de PHP.

✓ Ataques de scripts entre sites.

✓ Ataques de injeção de SQL.

✓ Ataques de fixação de sessões.

Alterar Controlo

Uma vez que as auditorias iso 27001 não avaliam especificamente alguns elementos dos processos de Pedido de Alteração, isto requer que:

• Demonstre que os pedidos de alteração têm os seguintes detalhes:

✓ Impacto documentado.

✓ Detalhes do teste de funcionalidade a realizar.

✓ Detalhes de quaisquer procedimentos de back-out.

• Demonstre que os testes de funcionalidade são realizados após a conclusão das alterações.

• Demonstre que os pedidos de alteração são assinados após a realização dos testes de funcionalidade.

Gestão de Contas

Uma vez que as auditorias iso 27001 não avaliam especificamente alguns elementos dos processos de gestão de contas, isto requer que:

• Demonstre como ✓s são implementados para mitigar ataques de repetição (por exemplo, MFA, Kerberos).
• Demonstre como as contas que não são utilizadas há 3 meses são desativadas ou eliminadas.
• ✓ou outras mitigações adequadas têm de ser configuradas para proteger as credenciais do utilizador. A seguinte política mínima de palavras-passe deve ser utilizada como orientação:

✓ Comprimento mínimo da palavra-passe de 8 carateres.

✓ Limiar de bloqueio de conta não superior a 10 tentativas.

✓ Histórico de palavras-passe com um mínimo de cinco palavras-passe.

✓ Imposição da utilização de palavras-passe fortes.

• Demonstrar que a MFA está configurada para todas as soluções de acesso remoto.

• Demonstre que a encriptação forte está configurada em todas as soluções de acesso remoto.

• Quando a gestão do DNS Público está fora do ambiente no âmbito, todas as contas de utilizador capazes de efetuar modificações de DNS têm de ser configuradas para utilizar a MFA.

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

Uma vez que as auditorias iso 27001 não avaliam especificamente alguns elementos dos processos dos Serviços de Deteção e Prevenção de Intrusões (IDPS), isto requer que:

• O IDPS deve ser implementado no perímetro do ambiente de suporte.

• As assinaturas IDPS devem ser mantidas atualizadas, no último dia.

• O IDPS DEVE ser configurado para inspeção TLS.

• O IDPS DEVE ser configurado para TODO o tráfego de entrada e saída.

• O IDPS DEVE ser configurado para alertas.

Registo de Eventos

Uma vez que as auditorias ISO 27001 não avaliam especificamente alguns elementos dos processos de registo de eventos de segurança, será necessário:

• Demonstre que os sistemas destinados ao público estão a iniciar sessão numa solução de registo centralizada que não está dentro da rede de perímetro.

• Demonstre como um mínimo de 30 dias de registo de dados está imediatamente disponível, com 90 dias a serem retidos.

Rever (Dados de Registo)

Uma vez que as auditorias ISO 27001 não avaliam especificamente alguns elementos desta categoria, será necessário:

• Demonstre como as revisões diárias de registos são realizadas e como as exceções e anomalias são identificadas, mostrando como estas são processadas.

Alertas

Uma vez que as auditorias ISO 27001 não avaliam especificamente alguns elementos desta categoria, será necessário:

• Demonstrar como os eventos de segurança são configurados para acionar alertas para triagem imediata.

• Demonstre como a equipa está disponível 24 horas por dia para responder a alertas de segurança.

Gestão de Riscos

Uma vez que as auditorias iso 27001 não avaliam especificamente alguns elementos dos processos de avaliação de riscos, isto requer que:

• Demonstrar que é estabelecido um processo formal de gestão de riscos.

Resposta a Incidentes

Uma vez que as auditorias iso 27001 não avaliam especificamente alguns elementos de políticas e processos de resposta a incidentes, isto requer que:

• Demonstre que o plano/procedimento de resposta a incidentes inclui:

✓ Procedimentos de resposta específicos para modelos de ameaças esperados.

✓ Capacidades de processamento de incidentes alinhadas com o NIST Cybersecurity Framework (Identificar, Proteger, Detetar, Responder, Recuperar).

✓ O IRP abrange os sistemas no âmbito.

✓ Formação anual para a equipa de resposta a incidentes.

Apêndice D

Recolha de Provas – Deltas para PCI DSS

Quando já obteve a conformidade com o PCI DSS, as diferenças seguintes não totalmente abrangidas pelo PCI DSS terão, no mínimo, de ser revistas como parte desta Certificação do Microsoft 365.

Proteção Contra Software Maligno - Controlo de Aplicações

Se a proteção contra software maligno estiver em vigor através da utilização de antivírus e for atestada no Relatório PCI DSS, não é necessária mais investigação. Se não existir nenhum antivírus, os analistas de certificação terão de identificar e avaliar provas dos mecanismos de controlo de aplicações para impedir a detonação de software maligno no ambiente. Isto irá exigir que:

• Demonstre como a aprovação da aplicação é realizada e confirme que esta ação foi concluída.

• Demonstre que existe uma lista completa de aplicações aprovadas com justificação comercial.

• Indique ou demonstre que está em vigor documentação de suporte que detalha como o software de controlo de aplicações está configurado para cumprir mecanismos de controlo de aplicações específicos (ou seja, lista de permissões, assinatura de código, etc.).

• Demonstre que, em todos os componentes do sistema de exemplo, o controlo de aplicações está configurado como documentado.

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

Uma vez que as auditorias PCI DSS não avaliam especificamente esta categoria, será necessário:

• Demonstrar como é realizada a classificação de risco de vulnerabilidades.

Verificação de vulnerabilidade

Uma vez que as auditorias PCI DSS não avaliam especificamente esta categoria, será necessário:

• Demonstre que a remediação é realizada de acordo com a política de remediação de vulnerabilidades documentada.

Firewall – Firewalls (ou tecnologias equivalentes)

Uma vez que as auditorias PCI DSS não avaliam especificamente esta categoria, será necessário:

• Demonstre que as firewalls suportam apenas criptografia forte em todas as interfaces administrativas não consola.

• Demonstre que as interfaces administrativas não consola da firewall expostas à MFA de suporte da Internet.

Será fornecido crédito adicional se uma Firewall de Aplicações Web (WAF) for implementada para ajudar a proteger contra a miríade de ameaças e vulnerabilidades de aplicações Web às quais a aplicação pode ser exposta. Quando estiver presente uma WAF ou semelhante, será necessário:

• Demonstrar que a WAF está configurada no modo de defesa ativa ou monitorizar mais com alertas.

• Demonstrar que a WAF está configurada para suportar a descarga de SSL.

• Está configurado de acordo com o Conjunto de Regras Principais do OWASP (3.0 ou 3.1) para proteger contra a maioria dos seguintes tipos de ataque:

✓ Problemas de protocolo e codificação.

✓ Injeção de cabeçalho, contrabando de pedidos e divisão de respostas.

✓ Ataques de passagem de ficheiros e caminhos.

✓ Ataques de inclusão remota de ficheiros (RFI).

✓ Ataques de execução remota de código.

✓ Ataques de injeção de PHP.

✓ Ataques de scripts entre sites.

✓ Ataques de injeção de SQL.

✓ Ataques de fixação de sessões.

Alterar Controlo

Uma vez que as auditorias do PCI DSS não avaliam especificamente alguns elementos dos processos de Pedido de Alteração, será necessário:

• Demonstre que os pedidos de alteração são gerados antes de serem efetuados em ambientes de produção.

• Demonstre que as alterações são autorizadas antes de entrar em produção.

• Demonstre que os testes de funcionalidade são realizados após a conclusão das alterações.

• Demonstre que os pedidos de alteração são assinados após a realização dos testes de funcionalidade.

Desenvolvimento/Implementação de Software Seguro

Uma vez que as auditorias PCI DSS não acedem especificamente a alguns elementos de processos seguros de desenvolvimento e implementação de software; isto irá exigir-lhe:

• Os repositórios de código têm de ser protegidos pela MFA.

• Os controlos de acesso adequados têm de estar implementados para proteger os repositórios de código contra modificações de código malicioso.

Gestão de Contas

Uma vez que as auditorias PCI DSS não avaliam especificamente alguns elementos dos processos de gestão de contas, será necessário:

• Demonstre como os mecanismos de autorização são implementados para mitigar ataques de repetição (por exemplo, MFA, Kerberos).

• As políticas de palavras-passe fortes ou outras mitigações adequadas têm de ser configuradas para proteger as credenciais do utilizador. A seguinte política mínima de palavras-passe deve ser utilizada como orientação:

✓ Comprimento mínimo da palavra-passe de 8 carateres.

✓ Limiar de bloqueio de conta não superior a 10 tentativas.

✓ Histórico de palavras-passe com um mínimo de cinco palavras-passe.

✓ Imposição da utilização de palavras-passe fortes.

• Demonstre que a encriptação forte está configurada em todas as soluções de acesso remoto.

• Quando a gestão do DNS Público está fora do ambiente no âmbito, todas as contas de utilizador capazes de efetuar modificações de DNS têm de ser configuradas para utilizar a MFA.

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

Uma vez que as auditorias PCI DSS não avaliam especificamente alguns elementos dos processos dos Serviços de Deteção e Prevenção de Intrusões (IDPS), será necessário:

• O IDPS DEVE ser configurado para inspeção TLS.

• O IDPS DEVE ser configurado para TODO o tráfego de entrada e saída.

Gestão de Riscos

Uma vez que as auditorias PCI DSS não avaliam especificamente alguns elementos dos processos de avaliação de riscos, será necessário:

• Demonstrar a avaliação de riscos inclui matrizes de impacto e probabilidade.

Resposta a Incidentes

Uma vez que as auditorias PCI DSS não avaliam especificamente alguns elementos de políticas e processos de resposta a incidentes, isto exigirá que o programador:

• Demonstre as capacidades de processamento de incidentes alinhadas com o NIST Cybersecurity Framework (Identificar, Proteger, Detetar, Responder, Recuperar).

Apêndice E

Recolha de Provas - Deltas para SOC 2

Quando já tiver atingido a conformidade com o SOC 2, as diferenças (lacunas) seguintes não totalmente abrangidas pelo SOC 2 terão de ser revistas como parte desta Certificação do Microsoft 365.

Proteção Contra Software Maligno - Controlo de Aplicações

Se a proteção contra software maligno estiver em vigor através da utilização de antivírus e for atestada no seu relatório SOC 2, não é necessária mais investigação. Se não existir nenhum antivírus, os analistas de certificação terão de identificar e avaliar provas dos mecanismos de controlo de aplicações para impedir a detonação de software maligno no ambiente. Isto irá exigir que:

• Indique ou demonstre que está em vigor documentação de suporte que detalha como o software de controlo de aplicações está configurado para cumprir mecanismos de controlo de aplicações específicos (ou seja, lista de permissões, assinatura de código, etc.).

• Demonstre como a aprovação da aplicação é realizada e confirme que esta ação foi concluída.

• Demonstre que existe uma lista completa de aplicações aprovadas com justificação comercial.

• Demonstre que, em todos os componentes do sistema de exemplo, o controlo de aplicações está configurado como documentado.

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

Uma vez que as auditorias do SOC 2 não avaliam especificamente esta categoria, isto exigirá que:

• Qualquer problema Baixo, Médio, Alto ou Crítico tem de ser corrigido nas janelas de atividade de aplicação de patches normais.

• Os componentes de software e os sistemas operativos já não suportados pelo fornecedor DEVEM não ser utilizados no ambiente. As políticas de suporte TÊM de estar implementadas para garantir que os componentes de software/sistemas operativos não suportados serão removidos do ambiente e um processo para identificar quando os componentes de software têm de estar em vigor.

Firewall – Firewalls

Uma vez que as auditorias do SOC 2 não avaliam especificamente os controlos de alteração às listas de controlo de acesso da firewall, isto exigirá que:

• Demonstre que todo o tráfego permitido através das firewalls passa por um processo de autorização que resulta na documentação de todo o tráfego com uma justificação comercial.

• Demonstre que as revisões de regras de firewall são realizadas pelo menos a cada seis meses.

Será fornecido crédito adicional se uma Firewall de Aplicações Web (WAF) ou semelhante for implementada para ajudar a proteger contra a miríade de ameaças e vulnerabilidades de aplicações Web às quais a aplicação pode ser exposta. Quando estiver presente uma WAF ou semelhante, será necessário:

• Demonstrar que a WAF está configurada no modo de defesa ativa ou monitorizar mais com alertas.

• Demonstrar que a WAF está configurada para suportar a descarga de SSL.

• Está configurado de acordo com o Conjunto de Regras Principais do OWASP ((3.0 ou 3.1) para proteger contra a maioria dos seguintes tipos de ataque:

 ✓ Problemas de protocolo e codificação.

 ✓ Injeção de cabeçalho, contrabando de pedidos e divisão de respostas.

 ✓ Ataques de passagem de ficheiros e caminhos.

 ✓ Ataques de inclusão remota de ficheiros (RFI).

 ✓ Ataques de execução remota de código.

 ✓ Ataques de injeção de PHP.

 ✓ Ataques de scripts entre sites.

 ✓ Ataques de injeção de SQL.

 ✓ Ataques de fixação de sessões.

Alterar Controlo

Uma vez que as auditorias do SOC 2 não avaliam especificamente alguns elementos dos processos de Pedido de Alteração, isto exigirá que o programador:

• Demonstrar como os ambientes de desenvolvimento/teste são separados do ambiente de produção que impõe a separação de deveres.

• Demonstrar como os dados dinâmicos não são utilizados nos ambientes de desenvolvimento/teste.

• Demonstre que os testes de funcionalidade são realizados após a conclusão das alterações.

• Demonstre que os pedidos de alteração são assinados após a realização dos testes de funcionalidade.

Desenvolvimento/Implementação de Software Seguro

Uma vez que as auditorias do SOC 2 não acedem especificamente a alguns elementos de processos seguros de desenvolvimento e implementação de software; isto irá exigir-lhe:

• Tem de ter um processo de desenvolvimento de software estabelecido e documentado que abranja todo o ciclo de vida de desenvolvimento de software.

• Os programadores têm de ser submetidos a uma formação segura de codificação de software, pelo menos, anualmente.

• Os repositórios de código têm de ser protegidos pela MFA.

• Os controlos de acesso adequados têm de estar implementados para proteger os repositórios de código contra modificações de código malicioso.

Gestão de Contas

Uma vez que as auditorias do SOC2 não avaliam especificamente alguns elementos dos processos de gestão de contas, será necessário:

• Demonstre como os mecanismos de autorização são implementados para mitigar ataques de repetição (por exemplo, MFA, Kerberos).

• Demonstre como as contas que não são utilizadas há 3 meses são desativadas ou eliminadas.

• As políticas de palavras-passe fortes ou outras mitigações adequadas têm de ser configuradas para proteger as credenciais do utilizador. A seguinte política mínima de palavras-passe deve ser utilizada como orientação:

 ✓ Comprimento mínimo da palavra-passe de 8 carateres.

 ✓ Limiar de bloqueio de conta não superior a 10 tentativas.

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

 ✓ Imposição da utilização de palavras-passe fortes

• Demonstrar que as contas de utilizador exclusivas são emitidas para todos os utilizadores.

• Quando a gestão do DNS Público está fora do ambiente no âmbito, todas as contas de utilizador capazes de efetuar modificações de DNS têm de ser configuradas para utilizar a MFA.

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

Uma vez que as auditorias do SOC 2 não avaliam especificamente alguns elementos dos processos dos Serviços de Deteção e Prevenção de Intrusões (IDPS), será necessário:

• As assinaturas IDPS devem ser mantidas atualizadas, no último dia

• IDPS DEVE ser configurado para inspeção TLS

• O IDPS deve ser configurado para TODO o tráfego de entrada e saída

Registo de Eventos

Uma vez que as auditorias do SOC 2 não avaliam especificamente alguns elementos dos processos de registo de eventos de segurança, será necessário:

• Demonstrar como, em todos os componentes do sistema no conjunto de exemplo, o sistema seguinte está configurado para registar os seguintes eventos

 ✓ Acesso do utilizador aos componentes do sistema e às aplicações.

 ✓ Todas as ações executadas por um utilizador com privilégios elevados.

 ✓ Tentativas de acesso lógico inválidas.

Demonstrar que os eventos registados contêm; no mínimo, as seguintes informações:

 ✓ Utilizador.

 ✓ Tipo de Evento.

 ✓ Data e Hora.

 ✓ Indicador de êxito/falha.

 ✓ Etiqueta para identificar o sistema afetado.

• Demonstre que todos os componentes do sistema no conjunto de exemplo estão configurados para utilizar a sincronização de tempo e que estes são os mesmos que os servidores de hora primária/secundária.

• Demonstre que os sistemas destinados ao público estão a iniciar sessão numa solução de registo centralizada que não está dentro da rede de perímetro.

• Demonstre que os sistemas destinados ao público estão a iniciar sessão numa solução de registo centralizada que não está dentro da rede de perímetro.

• Demonstrar como a solução de registo centralizada está protegida contra adulteração não autorizada de dados de registo.

• Demonstre como um mínimo de 30 dias de registo de dados está imediatamente disponível, com 90 dias ou mais a serem retidos.

Gestão de Riscos

Uma vez que as auditorias do SOC2 não avaliam especificamente alguns elementos dos processos de avaliação de riscos, será necessário:

• Demonstrar que uma avaliação formal de riscos é realizada, pelo menos, anualmente.

Resposta a Incidentes.

Uma vez que as auditorias do SOC2 não avaliam especificamente alguns elementos de políticas e processos de resposta a incidentes, será necessário:

• Demonstre que o plano/procedimento de resposta a incidentes inclui:

 ✓ Procedimentos de resposta específicos para modelos de ameaças esperados.

 ✓ Processo documentado de comunicações para garantir uma notificação oportuna dos principais intervenientes (marcas de pagamento/adquirentes, entidades reguladoras, autoridades de supervisão, diretores, clientes, etc.

Apêndice F

Tipos de Implementação de Alojamento

A Microsoft reconhece que irá implementar aplicações e armazenar código de aplicação/suplemento em diferentes ambientes de alojamento. As responsabilidades gerais de alguns dos controlos de segurança na Certificação do Microsoft 365 dependerão do ambiente de alojamento que está a ser utilizado. O Apêndice F analisa os tipos de implementação comuns e mapeia-os em relação aos controlos de segurança que são avaliados como parte do processo de avaliação. Foram identificados os seguintes tipos de implementação de alojamento:

Tipos de Alojamento	Descrição
ISV Alojado	Os tipos alojados isv podem ser definidos como onde é responsável pela infraestrutura utilizada para suportar o ambiente de aplicação/suplemento. Isto pode estar localizado fisicamente nos seus próprios datacenters ou datacenters de terceiros com um serviço de colocalização. Em última análise, tem total propriedade e controlo administrativo sobre a infraestrutura de suporte e o ambiente operativo.
Infraestrutura como Um Serviço (IaaS) (https://azure.microsoft.com/overview/what-is-iaas/)	A infraestrutura como um Serviço é um serviço fornecido através do qual a infraestrutura de suporte físico é gerida e mantida em seu nome pelo fornecedor de serviços cloud (CSP). Normalmente, a rede, o armazenamento, os servidores físicos e a infraestrutura de virtualização são da responsabilidade do CSP. O Sistema Operativo, o Middleware, o Runtime, os Dados e as Aplicações são das suas responsabilidades. As capacidades de firewall também seriam geridas e mantidas por terceiros. No entanto, a manutenção da base de regras de firewall seria normalmente a responsabilidade dos consumidores.
Plataforma como um Serviço/Sem Servidor (PaaS) (https://azure.microsoft.com/overview/what-is-paas/)	Com a Plataforma como um Serviço, é aprovisionado com uma plataforma gerida que apresenta um serviço que pode ser consumido. Não precisa de executar funções sysadmin, uma vez que o sistema operativo e a infraestrutura de suporte são geridos pelo CSP. Normalmente, isto seria utilizado quando as organizações não querem preocupar-se com a apresentação de um serviço Web e, em vez disso, podem concentrar-se na criação do código fonte da aplicação Web e na publicação da aplicação Web nos serviços Web geridos pela cloud. Outro exemplo pode ser um serviço de base de dados onde a conectividade é atribuída a uma base de dados, no entanto, a infraestrutura de suporte e a aplicação de base de dados são abstraídas do consumidor. Nota: Sem servidor e PaaS são semelhantes, pelo que, para efeitos do Tipo de Implementação Sem Servidor e PasS do Tipo de Implementação de Alojamento de Certificação do Microsoft 365, são considerados iguais
Alojado Híbrido	Com o tipo alojado híbrido, pode utilizar vários tipos alojados para suportar várias partes do ambiente de suporte. Este pode ser mais o caso em que as aplicações/suplementos são utilizados em várias pilhas do Microsoft 365. Embora a Certificação do Microsoft 365 suporte onde as aplicações/suplementos em vários serviços do Microsoft 365 são desenvolvidos, uma avaliação de todo o ambiente de suporte (entre aplicações/suplementos) teria de ser avaliada de acordo com cada um dos "Mapeamentos de Tipos Alojados" aplicáveis. Ocasionalmente, pode utilizar diferentes tipos alojados para um único suplemento, em que está a ser realizado, a aplicabilidade dos critérios terá de seguir os critérios "Mapeamentos de Tipos Alojados" nos vários tipos alojados.
Alojamento Partilhado	O alojamento partilhado é onde está a alojar o ambiente numa plataforma que é partilhada por vários consumidores individuais. A Especificação de Certificação do Microsoft 365 não foi escrita em consideração devido à adoção da cloud, o alojamento partilhado não é comum. Se acredita que está a ser utilizado, contacte a Microsoft, uma vez que terão de ser criados requisitos adicionais para ter em conta os riscos adicionais neste tipo de alojamento.

Apêndice G

Saiba mais

Descrição Geral do Programa de Conformidade de Aplicações do Microsoft 365O que é o Atestado do Microsoft 365 App Publisher?O que é a Certificação do Microsoft 365?

Glossário

AIA

*O Acesso a Informações de Autoridade é um descritor de localização de serviço utilizado para localizar o certificado da autoridade de certificação emissora.

CRL

*A Lista de Revogação de Certificados fornece um meio para um ponto final SSL (Secure Sockets Layer) verificar se um certificado recebido de um anfitrião remoto é válido e fidedigno.

Classificação cvss

*O Common Vulnerability Scoring System é um padrão publicado que mede a vulnerabilidade e calcula uma classificação numérica com base na sua gravidade.

Diretrizes de gestão de patches CVSS

• Crítico (9.0 - 10.0)
• Alto (7.0 - 8.9)
• Médio (4.0 - 6.9)
• Baixa (0,0 - 3,9)

DMZ

*A zona desmilitarizada é uma rede intermédia física ou lógica que interage diretamente com redes externas ou não proprietárias, mantendo a rede interna privada do anfitrião separada e isolada.

EUII

Informações identificáveis do utilizador final.

RGPD

*O Regulamento Geral sobre a Proteção de Dados é um regulamento de privacidade e proteção de dados da União Europeia (UE) para todos os dados dos cidadãos da UE, independentemente da localização do seu site de aplicação.

HSTS

*Http Strict Transport Security utiliza um cabeçalho de resposta HTTP que instrui o browser a aceder apenas ao conteúdo através de HTTPS. Isto foi concebido para proteger contra ataques de mudança para uma versão anterior e sequestro de cookies.

IEC

*Comissão Electrotécnica Internacional.

ISMS

*Sistema de Gestão de Segurança de Informações.

ISV

Os Fornecedores independentes de Segurança são indivíduos e organizações que desenvolvem, comercializam e vendem software que é executado em plataformas de software e hardware de terceiros.

ISO 27001

Uma arquitetura de especificação do sistema de gestão de segurança de informações para todos os controlos técnicos em processos de políticas e procedimentos de gestão de riscos de organizações.

LFI

A Inclusão de Ficheiros Locais permite que um atacante inclua ficheiros num servidor através do browser.

NIST

O National Institute of Standards (NIST), uma agência não reguladora do Departamento de Comércio dos EUA, fornece orientações para organizações do sector privado nos EUA avaliarem e aprovarem a sua capacidade de prevenir, detectar e responder a ciberataques.

Alterações não significativas

• Pequenas correções de Erros.
• Pequenas melhorias de desempenho.
• Patches de aplicações de servidor/sistemas operativos/bibliotecas/cliente.

OCSP

O Protocolo de Estado do Certificado Online é utilizado para verificar o estado de revogação dos certificados digitais X.509.

OII

Informações identificáveis organizacionais.

OWASP

Abra o Projeto de Segurança de Aplicações Web.

PCI DSS

Payment Card Industry Data Security Standard, uma organização que mantém padrões para a segurança dos dados de titulares de cartões em todo o mundo.

Teste da caneta

Os testes de penetração são um método de teste de uma aplicação Web ao simular ataques maliciosos para encontrar vulnerabilidades de segurança que um atacante poderia explorar.

SAML

O Security Assertion Markup Language é um padrão aberto para trocar dados de autenticação e autorização entre o utilizador, o fornecedor de identidade e o fornecedor de serviços.

Dados confidenciais

• Dados de controlo de acesso.
• Conteúdo do cliente.
• Informações de identidade do utilizador final.
• Dados de suporte.
• Dados pessoais públicos.
• Informações pseudonimísticas do utilizador final.

Alterações significativas

• Reposicionamento do ambiente de alojamento.
• Atualizações importantes para a infraestrutura de suporte; por exemplo, a implementação de uma nova firewall, atualizações principais para serviços front-facing, etc.
• Adição de capacidades e /ou extensões à sua aplicação.
• Atualizações à sua aplicação que capturam Dados confidenciais adicionais.
• Alterações aos fluxos de dados ou modelos de autorização da sua aplicação
• Adição de pontos finais de API ou funções de ponto final da API.

SOC 2

Service Organization Control 2, um procedimento de auditoria técnica composto por cinco Princípios de Serviço de Confiança para garantir que os fornecedores de serviços gerem os dados e a privacidade de forma segura para os clientes de uma organização.

SSL

Camada de Sockets Seguros.

TLS

Transport Layer Security.