Partilhar via

Apêndice e glossário da documentação de Conformidade de Aplicações do Microsoft 365

  • Artigo

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 razões 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

  • Todo o novo código TEM 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.

*A ECDSA é permitida. 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

  • O 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.

  • O 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.

Observação

Como parte da avaliação da Certificação do Microsoft 365, o analista de certificação determinará se algum dos controlos ISO 27001 mapeados não foi incluído como parte da avaliação iso 27001 e também pode decidir se foram incluídos controlos de exemplo que foram incluídos para fornecer mais garantias. Todos os requisitos em falta no ISO 27001 terão de ser incluídos nas suas atividades de avaliação de 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.

  • 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 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çalhos, contrabando de pedidos e divisão de respostas.

  • Ataques de passagem de ficheiros e caminhos.

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

  • Ataques de execução de código remoto.

  • Ataques de injeção php.

  • Ataques de scripting entre sites.

  • Ataques de injeção de SQL.

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

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 sobre o teste de funcionalidades 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.

Observação

Como parte da avaliação da Certificação do Microsoft 365, o analista de certificação determinará se algum dos controlos PCI DSS mapeados não foi incluído como parte da avaliação do PCI DSS e também pode decidir se foram incluídos controlos de exemplo que foram incluídos para fornecer mais garantias. Todos os requisitos em falta no PCI DSS terão de ser incluídos nas atividades de avaliação da 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 um Firewall de Aplicativo Web (WAF) for implementado 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çalhos, contrabando de pedidos e divisão de respostas.

  • Ataques de passagem de ficheiros e caminhos.

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

  • Ataques de execução de código remoto.

  • Ataques de injeção php.

  • Ataques de scripting entre sites.

  • Ataques de injeção de SQL.

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

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.

Observação

Como parte da avaliação da Certificação do Microsoft 365, o analista de certificação determinará se algum dos controlos SOC 2 mapeados não foi incluído como parte da avaliação do SOC 2 e também pode decidir se foram incluídos controlos de exemplo que foram incluídos para fornecer mais garantias. Todos os requisitos em falta na avaliação do SOC 2 terão de ser incluídos como parte das atividades de avaliação da 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 um Firewall de Aplicativo Web (WAF) ou semelhante for implementado 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çalhos, contrabando de pedidos e divisão de respostas.

  • Ataques de passagem de ficheiros e caminhos.

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

  • Ataques de execução de código remoto.

  • Ataques de injeção php.

  • Ataques de scripting entre sites.

  • Ataques de injeção de SQL.

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

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 realizadas 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.

  • Documentou o processo 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.

FedRAMP

O Federal Risk and Authorization Management Program (FedRAMP) é um programa do governo federal dos EUA criado em 2011. Fornece uma abordagem padronizada para avaliação de segurança, autorização e monitorização contínua para produtos e serviços cloud.

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 marcar a status de revogação de certificados digitais X.509.

OII

Informações identificáveis organizacionais.

OWASP

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

PCI DSS

O Payment Card Industry Data Security Standard, uma organização que mantém padrões para a segurança dos dados dos 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 captura 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.