Partilhar via


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

Apêndice A

Requisitos de configuração de perfil TLS

Todo o tráfego de rede, seja dentro de uma rede virtual, serviço de nuvem ou um data center, deve ser protegido com um mínimo de TLS v1.1 (TLS v1.2+ é recomendado) ou outro protocolo aplicável. As exceções a esse requisito são:

  • Redirecionamento HTTP-to-HTTPS. Seu aplicativo pode responder por HTTP para redirecionar clientes para HTTPS, mas a resposta não deve conter dados confidenciais (cookies, cabeçalhos, conteúdo). Nenhuma outra resposta HTTP além de redirecionamentos para HTTPS e responder a investigações de integridade são permitidas. Confira a seguir.
  • Investigações de integridade. Seu aplicativo só poderá responder a investigações de integridade por http se não houver suporte para investigações de integridade HTTPS pela parte de verificação.
  • Acesso ao certificado. O acesso aos pontos de extremidade CRL, OCSP e AIA para fins de validação de certificado e verificação de revogação é permitido por HTTP.
  • Comunicações locais. Seu aplicativo pode usar HTTP (ou outros protocolos não protegidos) para comunicações que não saem do sistema operacional, por exemplo, conectar-se a um ponto de extremidade do servidor Web exposto em localhost.

A compactação TLS deve ser desabilitada.

Apêndice B

Requisitos de configuração de perfil de criptografia

Somente primitivos e parâmetros criptográficos são permitidos da seguinte maneira:

Criptografia simétrica

Encryption

 ✓ Somente AES, BitLocker, Blowfish ou TDES são permitidos. Qualquer um dos comprimentos >de chave com suporte =128 são permitidos (128 bits, 192 bits e 256 bits) e podem ser usados (chaves de 256 bits são recomendadas).

 ✓ Somente o modo CBC é permitido. Cada operação de criptografia deve usar um vetor de inicialização (IV) gerado aleatoriamente.

 ✓ Uso de cifras de fluxo, como RC4, NÃO é permitido.

Funções de hash

 ✓ Todos os novos códigos devem usar SHA-256, SHA-384 ou SHA-512 (coletivamente conhecido como SHA-2). A saída pode ser truncada para nada menos que 128 bits

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

 ✓ O uso de MD5, MD4, MD2 e outras funções de hash NÃO é permitido, mesmo para aplicativos não criptográficos.

Autenticação de mensagem

 ✓ Todos os novos códigos devem usar o HMAC com uma das funções de hash aprovadas. A saída do HMAC pode ser truncada para nada menos que 128 bits.

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

 ✓ A chave HMAC deve ter pelo menos 128 bits. As chaves de 256 bits são recomendadas.

Algoritmos assimétricos

Encryption

 ✓ RSA é permitido. A chave DEVE ter pelo menos 2.048 bits e o preenchimento OAEP deve ser usado. O uso de preenchimento PKCS só é permitido por motivos de compatibilidade.

Assinaturas

 ✓ RSA é permitido. A chave DEVE ter pelo menos 2.048 bits e o preenchimento PSS deve ser usado. O uso de preenchimento PKCS só é permitido por motivos de compatibilidade.

 ✓ECDSA é permitido. A chave DEVE ter pelo menos 256 bits. A curva NIST P-256, P-384 ou P-521 deve ser usada.

Troca de Chaves

 ✓ ECDH é permitido. A chave DEVE ter pelo menos 256 bits. A curva NIST P-256, P-384 ou P-521 deve ser usada.

 ✓ ECDH é permitido. A chave DEVE ter pelo menos 256 bits. A curva NIST P-256, P-384 ou P-521 deve ser usada.

Apêndice C

Coleta de Evidências – Delta para ISO 27001

Onde você já alcançou ISO27001 conformidade, as seguintes (lacunas) delta não totalmente cobertas pelo ISO 27001 precisarão, no mínimo, ser revisadas como parte desta Certificação microsoft 365.

Observação

Como parte da avaliação de certificação do Microsoft 365, o analista de certificação determinará se algum dos controles iso 27001 mapeados não foi incluído como parte da avaliação iso 27001 e também pode decidir por exemplo controles que foram encontrados para fornecer mais garantia. Todos os requisitos ausentes da ISO 27001 precisarão ser incluídos em suas atividades de avaliação de certificação do Microsoft 365.

Proteção contra Malware – Antivírus

Se a proteção contra malware estiver em vigor usando o controle de aplicativo e for atestada no ISO 27001 Relatório, nenhuma investigação adicional será necessária. Se nenhum controle de aplicativo estiver em vigor, os analistas de certificação precisarão identificar e avaliar evidências de mecanismos de controle de aplicativo para evitar a detonação de malware no ambiente. Isso exigirá que você:

  • Demonstre que o software antivírus está sendo executado em todos os componentes do sistema amostrados.

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

  • O software antivírus DEVE ser configurado para registrar todas as atividades.

Gerenciamento de Patch – Patching

Como as auditorias iso 27001 não avaliam especificamente essa categoria, isso exigirá que você:

  • Componentes de software e sistemas operacionais não suportados mais pelo fornecedor não devem ser usados no ambiente. As políticas de suporte devem estar em vigor para garantir que componentes de software/sistemas operacionais sem suporte sejam removidos do ambiente e um processo para identificar quando os componentes de software vão para o fim da vida útil deve estar em vigor

Verificação de vulnerabilidade

Como as auditorias iso 27001 não avaliam especificamente essa categoria, isso exigirá que você:

  • Demonstre que a verificação trimestral de vulnerabilidades internas e externas é realizada.

  • Confirme se a documentação de suporte está em vigor para correção de vulnerabilidade com base na classificação de risco e de acordo com a especificação da seguinte maneira:

✓ Corrija todos os problemas de risco críticos e altos em linha com a classificação de risco para verificação interna.

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

✓ Demonstrar que a correção é conduzida de acordo com a política de correção de vulnerabilidade documentada.

Firewall – Firewalls (ou tecnologias equivalentes)

Como as auditorias iso 27001 não avaliam especificamente essa categoria, isso exigirá que você:

  • Demonstre que os firewalls estão instalados no limite do ambiente no escopo.

  • Demonstre que os firewalls estão instalados entre as redes DMZ e confiáveis.

  • Demonstre que todo o acesso público termina na DMZ.

  • Demonstre que as credenciais administrativas padrão são alteradas antes da instalação no ambiente ao vivo.

  • Demonstre que todo o tráfego permitido por meio dos firewalls passa por um processo de autorização, o que resulta na documentação de todo o tráfego com uma justificativa comercial.

  • Demonstre que todos os firewalls estão configurados para remover o tráfego não definido explicitamente.

  • Demonstre que os firewalls dão suporte apenas a criptografia forte em todas as interfaces administrativas que não são de console.

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

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

Firewall – WAF (Firewalls de Aplicativo Web)

Crédito adicional será fornecido se um WAF for implantado para ajudar a proteger contra a miríade de ameaças e vulnerabilidades do aplicativo Web às quais o aplicativo pode ser exposto. Quando um WAF ou similar estiver presente, isso exigirá que você:

  • Demonstre que o WAF está configurado no modo de defesa ativa ou monitorando mais com alertas.

  • Demonstre que o WAF está configurado para dar suporte ao descarregamento de SSL.

  • É configurado de acordo com o conjunto de regras do OWASP Core (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 solicitações e divisão de resposta.

✓ Ataques de passagem de arquivo e caminho.

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

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

✓ Ataques de injeção php.

✓ Ataques de script entre sites.

✓ Ataques de injeção de SQL.

✓ Ataques de correção de sessão.

Alterar controle

Como as auditorias iso 27001 não avaliam especificamente alguns elementos dos processos de Solicitação de Alteração, isso exigirá que você:

  • Demonstre que as solicitações de alteração têm os seguintes detalhes:

✓ Impacto documentado.

✓ Detalhes de quais testes de funcionalidade devem ser realizados.

✓ Detalhes de todos os procedimentos de back-out.

  • Demonstre que o teste de funcionalidade é realizado após a conclusão das alterações.

  • Demonstre que as solicitações de alteração são assinadas após a realização do teste de funcionalidade.

Gerenciamento de Conta

Como as auditorias iso 27001 não avaliam especificamente alguns elementos dos processos de gerenciamento de conta, isso exigirá que você:

  • Demonstre como ✓s são implementados para mitigar ataques de reprodução (por exemplo, MFA, Kerberos).
  • Demonstre como as contas que não são usadas há três meses estão desabilitadas ou excluídas.
  • ✓ou outras mitigações adequadas devem ser configuradas para proteger as credenciais do usuário. A seguinte política mínima de senha deve ser usada como diretriz:

✓ Comprimento mínimo de senha de 8 caracteres.

✓ Limite de bloqueio da conta de no máximo 10 tentativas.

✓ Histórico de senhas de no mínimo cinco senhas.

✓ Imposição do uso de senhas fortes.

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

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

  • Quando o gerenciamento de DNS público está fora do ambiente no escopo, todas as contas de usuário capazes de fazer modificações de DNS devem ser configuradas para usar o MFA.

Detecção e prevenção de intrusão (OPCIONAL)

Como as auditorias do ISO 27001 não avaliam especificamente alguns elementos dos processos de IDPS (Serviços de Prevenção e Detecção de Intrusões), isso exigirá que você:

  • O IDPS DEVE ser implantado no perímetro do ambiente de suporte.

  • As assinaturas IDPS DEVEM ser mantidas atuais no último dia.

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

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

  • O IDPS DEVE ser configurado para alerta.

Registro em log de eventos

Como as auditorias iso 27001 não avaliam especificamente alguns elementos dos processos de log de eventos de segurança, isso exigirá que você:

  • Demonstre que os sistemas voltados para o público estão fazendo logon em uma solução de log centralizada que não está dentro da DMZ.

  • Demonstre como um mínimo de 30 dias de dados de registro em log está disponível imediatamente, com 90 dias sendo retidos.

Revisão (Dados de Log)

Como as auditorias iso 27001 não avaliam especificamente alguns elementos dessa categoria, isso exigirá que você:

  • Demonstre como as revisões diárias de log são conduzidas e como exceções e anomalias são identificadas mostrando como elas são tratadas.

Alertando

Como as auditorias iso 27001 não avaliam especificamente alguns elementos dessa categoria, isso exigirá que você:

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

  • Demonstre como a equipe está disponível 24/7 para responder aos alertas de segurança.

Gerenciamento de Riscos

Como as auditorias iso 27001 não avaliam especificamente alguns elementos de processos de avaliação de risco, isso exigirá que você:

  • Demonstre que um processo formal de gerenciamento de risco está estabelecido.

Resposta a incidentes

Como as auditorias iso 27001 não avaliam especificamente alguns elementos de políticas e processos de resposta a incidentes, isso exigirá que você:

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

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

✓ Recursos de tratamento de incidentes alinhados ao NIST Cybersecurity Framework (Identificar, Proteger, Detectar, Responder, Recuperar).

✓ O IRP abrange os sistemas no escopo.

✓ Treinamento anual para a equipe de resposta a incidentes.

Apêndice D

Coleta de Evidências – Deltas para DSS PCI

Onde você já alcançou a conformidade do PCI DSS, as seguintes (lacunas) delta não totalmente cobertas pelo PCI DSS precisarão, no mínimo, ser revisadas como parte desta Certificação microsoft 365.

Observação

Como parte da avaliação de certificação do Microsoft 365, o analista de certificação determinará se algum dos controles PCI DSS mapeados não foi incluído como parte da avaliação do PCI DSS e também pode decidir pelos controles de exemplo que foram encontrados para fornecer mais garantia. Todos os requisitos ausentes do DSS PCI precisarão ser incluídos nas atividades de avaliação de certificação do Microsoft 365.

Proteção contra Malware – Controle de Aplicativos

Se a proteção contra malware estiver em vigor por meio do uso do antivírus e for atestada no Relatório PCI DSS, nenhuma investigação adicional será necessária. Se nenhum antivírus estiver em vigor, os analistas de certificação precisarão identificar e avaliar evidências de mecanismos de controle de aplicativo para evitar a detonação de malware no ambiente. Isso exigirá que você:

  • Demonstre como a aprovação do aplicativo é conduzida e confirme se isso foi concluído.

  • Demonstre que existe uma lista completa de aplicativos aprovados com justificativa comercial.

  • Forneça ou demonstre que a documentação de suporte está em vigor detalhando como o software de controle de aplicativo está configurado para atender a mecanismos de controle de aplicativo específicos (ou seja, permissão, assinatura de código etc.).

  • Demonstre que, em todos os componentes do sistema amostrados, o controle do aplicativo está configurado como documentado.

Gerenciamento de Patch – Classificação de Risco

Como as auditorias PCI DSS não avaliam especificamente essa categoria, isso exigirá que você:

  • Demonstre como a classificação de risco de vulnerabilidades é conduzida.

Verificação de vulnerabilidade

Como as auditorias PCI DSS não avaliam especificamente essa categoria, isso exigirá que você:

  • Demonstre que a correção é conduzida de acordo com a política de correção de vulnerabilidade documentada.

Firewall – Firewalls (ou tecnologias equivalentes)

Como as auditorias PCI DSS não avaliam especificamente essa categoria, isso exigirá que você:

  • Demonstre que os firewalls dão suporte apenas a criptografia forte em todas as interfaces administrativas que não são de console.

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

Crédito adicional será fornecido se um WAF (Firewall de Aplicativo Web) for implantado para ajudar a proteger contra a miríade de ameaças e vulnerabilidades do aplicativo Web às quais o aplicativo pode ser exposto. Quando um WAF ou similar estiver presente, isso exigirá que você:

  • Demonstre que o WAF está configurado no modo de defesa ativa ou monitorando mais com alertas.

  • Demonstre que o WAF está configurado para dar suporte ao descarregamento de SSL.

  • É configurado de acordo com o conjunto de regras do OWASP Core (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 solicitações e divisão de resposta.

✓ Ataques de passagem de arquivo e caminho.

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

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

✓ Ataques de injeção php.

✓ Ataques de script entre sites.

✓ Ataques de injeção de SQL.

✓ Ataques de correção de sessão.

Alterar controle

Como as auditorias PCI DSS não avaliam especificamente alguns elementos dos processos de Solicitação de Alteração, isso exigirá que você:

  • Demonstre que as solicitações de alteração são levantadas antes de serem feitas em ambientes de produção.

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

  • Demonstre que o teste de funcionalidade é realizado após a conclusão das alterações.

  • Demonstre que as solicitações de alteração são assinadas após a realização do teste de funcionalidade.

Desenvolvimento/implantação de software seguro

Como as auditorias PCI DSS não acessam especificamente alguns elementos de processos seguros de desenvolvimento e implantação de software; isso exigirá a você:

  • Os repositórios de código DEVEM ser protegidos pela MFA.

  • Controles de acesso adequados DEVEM estar em vigor para proteger repositórios de código contra modificações de código mal-intencionadas.

Gerenciamento de Conta

Como as auditorias PCI DSS não avaliam especificamente alguns elementos dos processos de gerenciamento de conta, isso exigirá que você:

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

  • Políticas de senha fortes ou outras mitigações adequadas devem ser configuradas para proteger as credenciais do usuário. A seguinte política mínima de senha deve ser usada como diretriz:

✓ Comprimento mínimo de senha de 8 caracteres.

✓ Limite de bloqueio da conta de no máximo 10 tentativas.

✓ Histórico de senhas de no mínimo cinco senhas.

✓ Imposição do uso de senhas fortes.

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

  • Quando o gerenciamento de DNS público está fora do ambiente no escopo, todas as contas de usuário capazes de fazer modificações de DNS devem ser configuradas para usar o MFA.

Detecção e prevenção de intrusão (OPCIONAL)

Como as auditorias PCI DSS não avaliam especificamente alguns elementos dos processos de IDPS (Serviços de Detecção e Prevenção de Intrusões), isso exigirá que você:

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

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

Gerenciamento de Riscos

Como as auditorias PCI DSS não avaliam especificamente alguns elementos de processos de avaliação de risco, isso exigirá que você:

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

Resposta a incidentes

Como as auditorias PCI DSS não avaliam especificamente alguns elementos de políticas e processos de resposta a incidentes, isso exigirá que o desenvolvedor:

  • Demonstre que os recursos de tratamento de incidentes se alinham ao NIST Cybersecurity Framework (Identificar, Proteger, Detectar, Responder, Recuperar).

Apêndice E

Coleta de Evidências – Deltas para SOC 2

Onde você já alcançou a conformidade do SOC 2, as seguintes (lacunas) delta não totalmente cobertas pelo SOC 2 precisarão ser revisadas como parte desta Certificação Microsoft 365.

Observação

Como parte da avaliação de Certificação do Microsoft 365, o analista de certificação determinará se algum dos controles do SOC 2 mapeados não foi incluído como parte de sua avaliação do SOC 2 e também poderá decidir pelos controles de exemplo que foram encontrados para fornecer mais garantia. Todos os requisitos ausentes da avaliação do SOC 2 precisarão ser incluídos como parte das atividades de avaliação de certificação do Microsoft 365.

Proteção contra Malware – Controle de Aplicativos

Se a proteção contra malware estiver em vigor por meio do uso de antivírus e for atestada em seu relatório SOC 2, nenhuma investigação adicional será necessária. Se nenhum antivírus estiver em vigor, os analistas de certificação precisarão identificar e avaliar evidências de mecanismos de controle de aplicativo para evitar a detonação de malware no ambiente. Isso exigirá que você:

  • Forneça ou demonstre que a documentação de suporte está em vigor detalhando como o software de controle de aplicativo está configurado para atender a mecanismos de controle de aplicativo específicos (ou seja, permissão, assinatura de código etc.).

  • Demonstre como a aprovação do aplicativo é conduzida e confirme se isso foi concluído.

  • Demonstre que existe uma lista completa de aplicativos aprovados com justificativa comercial.

  • Demonstre que, em todos os componentes do sistema amostrados, o controle do aplicativo está configurado como documentado.

Gerenciamento de Patch – Patching

Como as auditorias do SOC 2 não avaliam especificamente essa categoria, isso exigirá que você:

  • Qualquer problema baixo, médio, alto ou crítico deve ser corrigido em janelas normais de atividade de patch.

  • Componentes de software e sistemas operacionais não suportados mais pelo fornecedor não devem ser usados no ambiente. As políticas de suporte devem estar em vigor para garantir que componentes de software/sistemas operacionais sem suporte sejam removidos do ambiente e um processo para identificar quando os componentes de software forem de fim de vida devem estar em vigor.

Firewall – Firewalls

Como as auditorias do SOC 2 não avaliam especificamente os controles de alteração para listas de controle de acesso de firewall, isso exigirá que você:

  • Demonstre que todo o tráfego permitido por meio dos firewalls passa por um processo de autorização que resulta na documentação de todo o tráfego com uma justificativa comercial.

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

Crédito adicional será fornecido se um WAF (Firewall de Aplicativo Web) ou semelhante for implantado para ajudar a proteger contra a miríade de ameaças e vulnerabilidades do aplicativo Web às quais o aplicativo pode ser exposto. Quando um WAF ou similar estiver presente, isso exigirá que você:

  • Demonstre que o WAF está configurado no modo de defesa ativa ou monitorando mais com alertas.

  • Demonstre que o WAF está configurado para dar suporte ao descarregamento de SSL.

  • É configurado de acordo com o conjunto de regras do OWASP Core ((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 solicitações e divisão de resposta.

 ✓ Ataques de passagem de arquivo e caminho.

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

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

 ✓ Ataques de injeção php.

 ✓ Ataques de script entre sites.

 ✓ Ataques de injeção de SQL.

 ✓ Ataques de correção de sessão.

Alterar controle

Como as auditorias do SOC 2 não avaliam especificamente alguns elementos dos processos de Solicitação de Alteração, isso exigirá que o desenvolvedor:

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

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

  • Demonstre que o teste de funcionalidade é realizado após a conclusão das alterações.

  • Demonstre que as solicitações de alteração são assinadas após a realização do teste de funcionalidade.

Desenvolvimento/implantação de software seguro

Como as auditorias do SOC 2 não acessam especificamente alguns elementos de processos seguros de desenvolvimento e implantação de software; isso exigirá a você:

  • Você deve ter um processo de desenvolvimento de software estabelecido e documentado que abrange todo o ciclo de vida de desenvolvimento de software.

  • Os desenvolvedores devem passar por treinamento seguro de codificação de software pelo menos anualmente.

  • Os repositórios de código DEVEM ser protegidos pela MFA.

  • Controles de acesso adequados DEVEM estar em vigor para proteger repositórios de código contra modificações de código mal-intencionadas.

Gerenciamento de Conta

Como as auditorias SOC2 não avaliam especificamente alguns elementos dos processos de gerenciamento de conta, isso exigirá que você:

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

  • Demonstre como as contas que não são usadas há três meses estão desabilitadas ou excluídas.

  • Políticas de senha fortes ou outras mitigações adequadas devem ser configuradas para proteger as credenciais do usuário. A seguinte política mínima de senha deve ser usada como diretriz:

 ✓ Comprimento mínimo de senha de 8 caracteres.

 ✓ Limite de bloqueio da conta de no máximo 10 tentativas.

 ✓ Histórico de senhas de no mínimo 5 senhas.

 ✓ Imposição do uso de senhas fortes

  • Demonstre que contas de usuário exclusivas são emitidas para todos os usuários.

  • Quando o gerenciamento de DNS público está fora do ambiente no escopo, todas as contas de usuário capazes de fazer modificações de DNS devem ser configuradas para usar o MFA.

Detecção e prevenção de intrusões (OPCIONAL).

Como as auditorias do SOC 2 não avaliam especificamente alguns elementos dos processos de IDPS (Serviços de Detecção e Prevenção de Intrusões), isso exigirá que você:

  • Assinaturas IDPS DEVEM ser mantidas atuais, no último dia

  • IDPS DEVE ser configurado para inspeção do TLS

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

Registro em log de eventos

Como as auditorias do SOC 2 não avaliam especificamente alguns elementos dos processos de log de eventos de segurança, isso exigirá que você:

  • Demonstre como, em todos os componentes do sistema dentro do conjunto de exemplo, o sistema a seguir está configurado para registrar os eventos a seguir

 ✓ Acesso do usuário aos componentes do sistema e aos aplicativos.

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

 ✓ Tentativas de acesso lógico inválidas.

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

 ✓ Usuário.

 ✓ Tipo de evento.

 ✓ Data e hora.

 ✓ Indicador de êxito/falha.

 ✓ Rótulo para identificar o sistema afetado.

  • Demonstre que todos os componentes do sistema dentro do conjunto de exemplos estão configurados para utilizar a sincronização de tempo e que eles são iguais aos servidores de tempo primário/secundário.

  • Demonstre que os sistemas voltados para o público estão fazendo logon em uma solução de log centralizada que não está dentro da DMZ.

  • Demonstre que os sistemas voltados para o público estão fazendo logon em uma solução de log centralizada que não está dentro da DMZ.

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

  • Demonstre como um mínimo de 30 dias de dados de registro em log está disponível imediatamente, com 90 dias ou mais sendo retidos.

Gerenciamento de Riscos

Como as auditorias SOC2 não avaliam especificamente alguns elementos de processos de avaliação de risco, isso exigirá que você:

  • Demonstre que uma avaliação formal de risco é realizada pelo menos anualmente.

Resposta a incidentes.

Como as auditorias SOC2 não avaliam especificamente alguns elementos de políticas e processos de resposta a incidentes, isso exigirá que você:

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

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

 ✓ Processo de comunicação documentado para garantir a notificação oportuna dos principais stakeholders (marcas/adquirentes de pagamento, órgãos reguladores, autoridades de supervisão, diretores, clientes etc.

Apêndice F

Tipos de implantação de hospedagem

A Microsoft reconhece que você implantará aplicativos e armazenará o código de aplicativo/suplemento em diferentes ambientes de hospedagem. As responsabilidades gerais de alguns dos controles de segurança dentro da Certificação Microsoft 365 dependerão do ambiente de hospedagem que está sendo usado. O apêndice F analisa tipos comuns de implantação e mapeia-os em relação aos controles de segurança avaliados como parte do processo de avaliação. Os seguintes tipos de implantação de hospedagem foram identificados:

Tipos de hospedagem Descrição
ISV hospedado Os tipos hospedados no ISV podem ser definidos como onde você é responsável pela infraestrutura usada para dar suporte ao ambiente de aplicativo/suplemento. Isso pode estar fisicamente localizado em seus próprios data centers ou data centers de terceiros com um serviço de co-localização. Em última análise, você tem total propriedade e controle administrativo sobre a infraestrutura de suporte e o ambiente operacional.
IaaS (infraestrutura como serviço) (https://azure.microsoft.com/overview/what-is-iaas/) A infraestrutura como serviço é um serviço fornecido pelo qual a infraestrutura de suporte físico é gerenciada e mantida em seu nome pelo CSP (provedor de serviços de nuvem). Normalmente, rede, armazenamento, servidores físicos e a infraestrutura de virtualização são responsabilidade do CSP. O Sistema Operacional, Middleware, Runtime, Dados e Aplicativos são responsabilidades de você. Os recursos de firewall também seriam gerenciados e mantidos por terceiros, no entanto, a manutenção da base de regras de firewall normalmente ainda seria responsabilidade dos consumidores.
PaaS (plataforma como serviço/sem servidor) (https://azure.microsoft.com/overview/what-is-paas/) Com o Platform as a Service, você é provisionado com uma plataforma gerenciada apresentando um serviço que pode ser consumido. Você não precisa executar funções de sysadmin, pois o sistema operacional e a infraestrutura de suporte são gerenciados pelo CSP. Isso normalmente seria usado quando as organizações não querem se preocupar em apresentar um serviço Web e, em vez disso, podem se concentrar na criação do código-fonte do aplicativo Web e na publicação do aplicativo Web nos serviços Web gerenciados pela nuvem. Outro exemplo pode ser um serviço de banco de dados em que a conectividade é dada a um banco de dados, no entanto, a infraestrutura de suporte e o aplicativo de banco de dados são abstraídos do consumidor. Observação: Sem servidor e PaaS são semelhantes, portanto, para fins do Microsoft 365 Certification Hosting Deployment Type's Serverless e PasS são considerados os mesmos
Híbrida hospedada Com o tipo hospedado híbrido, você pode utilizar vários tipos hospedados para dar suporte a várias partes do ambiente de suporte. Isso pode ser mais o caso em que aplicativos/suplementos são utilizados em várias pilhas do Microsoft 365. Embora a Certificação Microsoft 365 dê suporte a onde aplicativos/complementos em vários serviços do Microsoft 365 são desenvolvidos, uma avaliação de todo o ambiente de suporte (entre aplicativos/suplementos) precisaria ser avaliada de acordo com cada um dos "Mapeamentos de Tipo Hospedado" aplicáveis. Ocasionalmente, você pode utilizar diferentes tipos hospedados para um único suplemento, onde isso está sendo realizado, a aplicabilidade dos critérios ainda precisará seguir os critérios "Mapeamentos de Tipo Hospedado" entre os vários tipos hospedados.
Hospedagem Compartilhada A hospedagem compartilhada é onde você está hospedando o ambiente em uma plataforma compartilhada por vários consumidores individuais. A Especificação de Certificação do Microsoft 365 não foi gravada para dar conta disso devido à adoção da nuvem, a hospedagem compartilhada não é comum. Se você acredita que isso está sendo usado, entre em contato com a Microsoft, pois requisitos adicionais precisarão ser criados para responder pelos riscos adicionais nesse tipo de hospedagem.

Apêndice G

Saiba mais

Visão geral do Programa de Conformidade de Aplicativo do Microsoft 365 O que é o Atestado do Microsoft 365 App Publisher?O que é a Certificação do Microsoft 365?

Glossário

AIA

*O Acesso de Informações de Autoridade é um descritor de local de serviço usado para localizar o certificado da autoridade de certificado emissora.

CRL

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

Pontuação CVSS

*Common Vulnerability Score System é um padrão publicado que mede a vulnerabilidade e calcula uma pontuação numérica com base em sua gravidade.

Diretrizes de gerenciamento de patch do CVSS

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

DMZ

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

FedRAMP

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

EUII

Informações identificáveis do usuário final.

RGPD

*O Regulamento Geral de Proteção de Dados é uma regulamentação de privacidade e proteção de dados da União Europeia (UE) para todos os dados dos cidadãos da UE, independentemente de onde seu site de aplicativo esteja localizado.

HSTS

*HTTP Strict Transport Security utiliza um cabeçalho de resposta HTTP instruindo o navegador da Web a acessar apenas o conteúdo por HTTPS. Isso foi projetado para proteger contra ataques de downgrade e sequestro de cookie.

IEC

*Comissão Eletrotécnica Internacional.

ISMOS

*Sistema de Gerenciamento de Segurança de Informações.

ISV

Fornecedores de segurança independentes são indivíduos e organizações que desenvolvem, comercializam e vendem softwares executados em plataformas de software e hardware de terceiros.

ISO 27001

Uma estrutura de especificação do sistema de gerenciamento de segurança de informações para todos os controles técnicos em um processo de gerenciamento de riscos de organizações.

LFI

A Inclusão de Arquivos Local permite que um invasor inclua arquivos em um servidor por meio do navegador da Web.

NIST

O National Institute of Standards (NIST), uma agência não regulatória do Departamento de Comércio dos EUA, oferece diretrizes para organizações do setor privado nos EUA para avaliar e aprovar sua capacidade de prevenir, detectar e responder a ataques cibernéticos.

Alterações não significativas

  • Correções de bugs menores.
  • Pequenas melhorias de desempenho.
  • Sistemas operacionais/bibliotecas/patches de aplicativo de cliente e servidor.

OCSP

O Protocolo de Status do Certificado Online é usado para marcar o status de revogação de certificados digitais X.509.

OII

Informações identificáveis organizacionais.

OWASP

Abra o Projeto de Segurança de Aplicativo Web.

PCI DSS

Padrão de Segurança de Dados do Setor de Cartões de Pagamento, uma organização que mantém padrões para a segurança dos dados do titular do cartão em todo o mundo.

Teste de caneta

O teste de penetração é um método de teste de um aplicativo Web simulando ataques mal-intencionados para encontrar vulnerabilidades de segurança que um invasor poderia explorar.

SAML

A Linguagem de Marcação de Declaração de Segurança é um padrão aberto para a troca de dados de autenticação e autorização entre o usuário, o provedor de identidade e o provedor de serviços.

Dados confidenciais

  • Acessar dados de controle.
  • Conteúdo do cliente.
  • Informações de identidade do usuário final.
  • Suporte a dados.
  • Dados pessoais públicos.
  • Informações de pseudônimo do usuário final.

Alterações significativas

  • Realocação do ambiente de hospedagem.
  • Atualizações importantes para a infraestrutura de suporte; por exemplo, implementação de um novo firewall, atualizações importantes para serviços frontais, etc.
  • Adição de recursos e /ou extensões ao seu aplicativo.
  • Atualizações ao aplicativo que captura dados confidenciais adicionais.
  • Alterações nos fluxos de dados ou modelos de autorização do aplicativo
  • Adição de pontos de extremidade de API ou funções de ponto de extremidade de API.

SOC 2

Controle de Organização de Serviço 2, um procedimento de auditoria técnica composto por cinco Princípios do Serviço de Confiança para garantir que os provedores de serviços gerenciem com segurança os dados e a privacidade dos clientes de uma organização.

SSL

Camada de soquetes seguros.

TLS

Segurança da Camada de Transporte.