Data Security Requirements

Preparando-se para responder a perguntas sobre segurança de dados

Fluxo de dados

Crie (ou atualize, se necessário) um diagrama ou uma descrição de fluxo de dados que ilustra como o app ou o sistema tratam Dados da Plataforma.

1. Lado do cliente - Inclua todos os softwares do cliente, como navegadores, dispositivos móveis e quaisquer outros tipos de dispositivos compatíveis.
2. Lado do servidor - Inclua quaisquer ambientes relacionados ao servidor ou à nuvem e identifique o seguinte:
1. Os componentes onde os Dados da Plataforma:
1. Entram ou saem do(s) ambiente(s) do servidor (por exemplo, web listeners e REST APIs).
2. São gravados em armazenamento persistente ou durável, como banco de dados, discos ou arquivos de registro.
2. O modelo de hospedagem, por exemplo:
1. Auto-hospedado - os próprios servidores de uma organização que funcionam em um data center próprio ou compartilhado.
2. Infraestrutura como serviço (IaaS) - Como a AWS EC2, o Microsoft Azure IaaS e o Google Compute Engine.
3. Plataforma como serviço (PaaS) - como o AWS Elastic Beanstalk, o Google App Engine e o Force.com.
4. Backend como Serviço (BaaS) - como o AWS Amplify, o Azure Mobile Apps, o Firebase e o MongoDB Switch.
5. Híbrido - uma combinação dos modelos acima.

No final, o diagrama ou a descrição do fluxo de dados deve incluir:

1. Onde os tokens de acesso da API da Meta são gerados e transmitidos/armazenados/renovados, tanto no software do cliente quanto no do servidor (se aplicável ao design do sistema).
2. Como você busca Dados da Plataforma nas APIs da Meta, com foco específico em Informações de Identificação Pessoal (PII), como nome, endereço de email, gênero e data de nascimento de alguém, entre outros dados do usuário.
3. Como você usa, armazena e transmite esses dados.
4. Quaisquer empresas quarteirizadas para as quais os Dados da Plataforma são enviados.

Elaboração de provas

Pode ser necessário enviar provas que sustentem as respostas relacionadas às proteções de segurança de dados que você implementa. Recomendamos a leitura do Guia de Provas neste documento para obter exemplos de provas aceitáveis e aprender a elaborá-las adequadamente. Aceitamos tipos de arquivos de documentos comuns junto com capturas e gravações de tela. Verifique se os arquivos não estão protegidos por senha. Você pode carregar vários arquivos, com no máximo 2 GB cada. Aceitamos .xls, .xlsx, .csv, .doc, .docx, .pdf, .txt, .jpeg, .jpg, .png, .ppt, .pptx, .mov, .mp4, .zip e .zipx.

Tipos de provas

Para aplicativos que precisam enviar provas relacionadas a proteções de segurança de dados, a Meta requer dois tipos diferentes de documentação:

1. Prova de política ou de procedimento - Um documento de política ou de procedimento que explica a abordagem de segurança de dados para [esta proteção].
2. Prova de implementação - Prova do sistema ou do app, como uma configuração de ferramenta ou uma captura de tela, que mostra como você implementou uma determinada proteção.

Prova de política ou de procedimento

A prova de política ou de procedimento, às vezes chamada de controle administrativo, é uma documentação escrita que descreve a abordagem para uma proteção de segurança de dados específica. O formato dessa prova pode variar – pode ser um trecho de um conjunto de políticas internas, parte de ou uma página inteira de um wiki interno ou um documento recém-criado que você usa para descrever a abordagem, caso você não tenha uma documentação pré-existente. Em qualquer caso, a prova de política ou de procedimento que você enviar deve explicar, claramente, como a abordagem para uma determinada proteção se relaciona com os requisitos da Meta. Forneça apenas a política ou os detalhes relevantes e necessários para a análise de segurança da Meta ou use a caixa de texto livre associada à pergunta para direcionar nossos analistas às seções relevantes.

Prova de implementação

A prova de implementação ilustra como você implementou a política ou o procedimento na prática diretamente por meio de uma captura ou gravação de tela. Considerando que desenvolvedores diferentes têm configurações distintas, não podemos fornecer exemplos para todos as situações. Portanto, a prova de implementação deve demonstrar, na medida do possível, o mesmo nível de detalhe dos exemplos que fornecemos.

Integralidade das provas

Entendemos que pode ser excessivamente oneroso elaborar provas de implementação que demonstrem, de forma abrangente, a implementação de uma determinada proteção de segurança de dados. Considerando isso, você deve enviar provas de acordo com as orientações fornecidas aqui e remover informações confidenciais das provas antes de enviá-las:

1. A prova de política ou de procedimento deve atender ou exceder, claramente, os requisitos da Meta
1. A Meta analisará as provas de política ou de procedimento das declarações que se alinham aos requisitos dela para a proteção fornecida.
2. Você deve anotar o documento para destacar as seções relevantes.
3. Por exemplo, em relação à proteção Ativar a criptografia TLS 1.2 ou superior para todas as conexões de rede em que os dados da plataforma são transmitidos, as provas aceitáveis incluiriam um documento que declarasse claramente:
1. Os dados da plataforma da Meta nunca devem ser transmitidos por redes não confiáveis em formato não criptografado.
2. Todos os web listeners (por exemplo, balanceadores de carga voltados para a internet) que recebem ou retornam dados da plataforma serão configurados de forma que o TLS 1.2 seja habilitado.
3. Todos os web listeners que recebem ou retornam dados da plataforma serão configurados de forma que os seguintes sejam desabilitados: SSL v2, SSL v3, TLS 1.0, e TLS 1.1
2. A prova de implementação deve mostrar um ou mais exemplos de implementação de cada política ou procedimento
1. Você deve carregar um ou mais documentos, capturas de tela ou configurações de ferramentas que demonstrem como você implementou cada proteção.
2. A Meta analisará as provas de implementação para verificar se estão alinhadas com as provas de política ou de procedimento.
3. Por exemplo, em relação à proteção Ativar a criptografia TLS 1.2 ou superior para todas as conexões de rede em que os dados da plataforma são transmitidos, as provas aceitáveis incluiriam o relatório de teste Qualys SSL para um dos domínios da web configurados de acordo com a política ou o procedimento.

Dados sensíveis que você deve remover das provas

Não envie provas que contenham qualquer um desses valores em formato legível (não removido). Se você estiver usando um editor de imagens para fazer uma captura de tela, coloque uma caixa preta em cima do valor. Se você estiver usando um editor de PDF, ajuste o texto usando uma ferramenta que realmente remova os valores, em vez de simplesmente adicionar uma caixa de texto por cima deles (por exemplo, a ferramenta de edição no app Apple Preview).

• Dados de saúde
• Dados financeiros
• Endereços IP
• Senhas, credenciais e tokens de acesso
• Chaves de criptografia
• Endereços físicos
• Informações de Identificação Pessoal (PII) sobre uma pessoa física (sem incluir empresas ou outras organizações empresariais), funcionários ou outras afiliadas que possam identificar essa pessoa, direta ou indiretamente, como:

  • Nome
  • Endereços de email
  • IDs de usuário
  • Datas de nascimento
  • Dados de localização
  • Dados de saúde
  • Identidade cultural, social e política
  • Dados que poderiam identificar, de outra forma, alguém no contexto específico da prova
• Etapas detalhadas de reprodução de vulnerabilidades (por exemplo, em um relatório de teste de penetração)
• Dados que os desenvolvedores sabem ou deveriam saber de ou sobre crianças menores de 13 anos

Como proteger Dados da Plataforma armazenados no servidor com criptografia em repouso

Pergunta: você aplica a criptografia em repouso a todos os Dados da Plataforma armazenados em um ambiente de nuvem, de servidor ou de data center?

Intenção

A criptografia em repouso protege os Dados da Plataforma, tornando os dados indecifráveis sem uma chave de descriptografia separada. Isso proporciona uma camada adicional de proteção contra acesso de leitura não autorizado.

• Em servidores ou em um ambiente de nuvem, em que os Dados da Plataforma relacionados a todos os usuários de um app tendem a estar concentrados, a criptografia em repouso reduz o risco de uma violação de dados.
• Por exemplo, ela protege contra ameaças como um acesso não autorizado a um backup de banco de dados, que pode não ser protegido com tanta rigorosidade quanto o próprio banco de dados de produção.

Resumo de requisitos

Se você armazena Dados da Plataforma no servidor:

• é necessário protegê-los das seguintes formas:

  • com criptografia em repouso ou
  • com proteções alternativas aceitáveis (veja Proteções alternativas aceitáveis).

• No que diz respeito ao tipo de criptografia usada, especificamente:

  • A criptografia de app (por exemplo, um software que criptografa/descriptografa colunas específicas em um banco de dados) ou de disco completo é aceitável.
  • Embora recomendemos o uso da criptografia padrão da indústria (como AES, BitLocker, Blowfish, TDES, RSA), não exigimos nenhum algoritmo ou comprimento de chave em particular.

Se o desenvolvedor não armazena Dados da Plataforma no servidor, esse requisito não é aplicável.

Casos especiais

Armazenamento no servidor com IaaS, auto-hospedagem ou hospedagem híbrida

Caso você armazene Dados da Plataforma com hospedagem IaaS (como Amazon EC2, IaaS do Microsoft Azure e Google Compute Engine), auto-hospedagem ou abordagem híbrida, essa questão se aplica.

Armazenamento no servidor com produtos SaaS, PaaS ou BaaS

Entretanto, existem outros modelos de hospedagem back-end que são casos especiais:

Caso você armazene Dados da Plataforma apenas por meio de qualquer um desses tipos (e não use IaaS, auto-hospedagem ou hospedagem híbrida), essa questão não se aplica. Em vez disso, você deve descrever essa relação na seção Provedor de Serviços da Avaliação da Proteção dos Dados (DPA).

• BaaS: por exemplo, AWS Amplify, Aplicativos Móveis Azure, Azure Playfab, Google Firebase e MongoDB Switch
• PaaS: por exemplo, AWS Elastic Beanstalk, Google App Engine, Force.com
• SaaS: por exemplo, MailChimp ou Salesforce

Armazenamento no servidor com APIs da Meta

Se você armazenar Dados da Plataforma apenas por meio de uma API da Meta, como a player.setDataAsync(), no SDK dos Jogos Instantâneos, essa questão não se aplica.

Guia de provas

Caso peçam para você enviar provas dessa proteção, siga as instruções em Elaboração de provas para preparar a política ou o procedimento e as provas de implementação.

Exemplo de provas de implementação

Amazon RDS

É possível configurar a criptografia em repouso no Amazon RDS. Por isso, os desenvolvedores devem garantir que a opção de configuração está definida para aplicar essa proteção.

Em uma instância RDS que contenha Dados da Plataforma, use a ferramenta AWS CLI para buscar a configuração StorageEncrypted.

# List RDS instances in default region
$ aws rds describe-db-instances \
  --query 'DBInstances[*].DBInstanceIdentifier'

[
    "database-1",
    "database-2"
]

# For each instance returned, retrieve the storage encrypted config
$ aws rds describe-db-instances \
  --db-instance-identifier database-1 \
  --query 'DBInstances[*].StorageEncrypted'
[
    true
]

$ aws rds describe-db-instances \
  --db-instance-identifier database-2 \
  --query 'DBInstances[*].StorageEncrypted'
[
    true
]

Amazon DynamoDB

Por padrão, o Amazon DynamoDB tem criptografia em repouso. Você pode buscar a configuração de criptografia em repouso para uma tabela usando esses comandos.

$ aws dynamodb list-tables --output table

--------------
| ListTables |
+------------+
||TableNames||
|+----------+|
||  Users   ||
|+----------+|


$ aws dynamodb describe-table \
 --table-name Users \
 --query "Table.SSEDescription.Status"

"ENABLED"

Amazon DocumentDB

O Amazon DocumentDB deve ser configurado para aplicar a criptografia em repouso. Em um grupo que contenha Dados da Plataforma, use esses comandos para buscar a configuração StorageEncrypted.

$ aws docdb describe-db-clusters --query 'DBClusters[*].DBClusterIdentifier'

[
    "docdb-users"
]

$ aws docdb describe-db-clusters \
  --db-cluster-identifier 'docdb-users' \
  --query 'DBClusters[*].StorageEncrypted'
[
    true
]

Amazon S3

É possível configurar os buckets Amazon S3 para aplicar a criptografia em repouso a todos os objetos criados dentro deles. Use esses comandos para listar os buckets e buscar a configuração para a criptografia padrão deles.

$ aws s3api list-buckets --output table --query "Buckets[*].Name"

---------------------------------------------
|                ListBuckets                |
+-------------------------------------------+
|  platform.storage                         |
+-------------------------------------------+

$ aws s3api get-bucket-encryption \
  --bucket  platform.storage \
  --query "ServerSideEncryptionConfiguration.Rules[*].ApplyServerSideEncryptionByDefault" \
  --output table
---------------------
|GetBucketEncryption|
+-------------------+
|   SSEAlgorithm    |
+-------------------+
|  AES256           |
+-------------------+

Microsoft Azure

Confira a documentação da Microsoft sobre criptografia em repouso no Azure que seja relevante para o uso dos serviços pela organização.

Google Cloud Platform

Confira a documentação da Google sobre criptografia em repouso no Google Cloud Platform.

Proteções alternativas aceitáveis

Caso não implemente a criptografia em repouso no ambiente de servidor, você pode proteger os Dados da Plataforma de outra forma que seja aceitável. Nesse caso, é necessário descrever o seguinte:

1. A sensibilidade dos Dados da Plataforma: o armazenamento de Dados da Plataforma específicos é considerado de baixo ou alto risco. É necessário pesquisar quais atributos de usuário dos Dados da Plataforma estão sendo armazenados no servidor.
2. Os controles usados para reduzir a possibilidade de danos específicos
1. Controles para prevenir o comprometimento de redes que contenham Dados da Plataforma
2. Controles para prevenir o comprometimento de apps ou sistemas que têm acesso aos Dados da Plataforma
3. Controles para prevenir a perda de mídia de armazenamento físico (como dispositivos de armazenamento de rede desativados) que contém Dados da Plataforma
4. Controles para prevenir a perda de mídia de armazenamento físico (como dispositivos de armazenamento de rede desativados) que contém Dados da Plataforma
5. Controles para prevenir o acesso não autorizado a cópias de backup de armazenamento que contêm backups de Dados da Plataforma
3. Força das provas: confira se essas proteções passaram pela análise de um auditor independente, por exemplo, como parte de uma auditoria SOC2.

Como proteger Dados da Plataforma armazenados em dispositivos organizacionais e mídia removível contra perdas

Pergunta: especificamente com relação aos dados armazenados em dispositivos organizacionais e pessoais, você aplica a criptografia em repouso a todos os Dados da Plataforma armazenados nesses dispositivos ou tem políticas ou regras em vigor para reduzir o risco de perda de dados?

Intenção

Quando os desenvolvedores permitem Dados da Plataforma em dispositivos como notebooks de funcionários ou armazenamento removível (por exemplo, pen drives), esses dados correm um grande risco de acesso não autorizado caso os dispositivos sejam perdidos ou roubados. Para limitar esse risco, é necessário que os desenvolvedores tomem providências.

Resumo de requisitos

• Para reduzir o risco de acesso não autorizado aos Dados da Plataforma, é necessário que os desenvolvedores tenham controles técnicos (preferível) ou administrativos (não preferível, mas aceitável) que sejam relevantes aos Dados da Plataforma em dispositivos organizacionais (como notebooks) e mídia removível.

  • Controles técnicos: exemplos de controles técnicos incluem 1) permitir apenas que dispositivos gerenciados se conectem à rede corporativa, 2) aplicar a criptografia de disco completo em dispositivos gerenciados (como BitLocker), 3) impedir que mídia removível (por exemplo, pen drives) seja conectada a dispositivos gerenciados e 4) usar a tecnologia de prevenção contra perda de dados (DLP, pelas siglas em inglês) em dispositivos gerenciados.
  • Controles administrativos: os exemplos de controles administrativos incluem documentação de política escrita e treinamento anual sobre formas aceitáveis de manusear Dados da Plataforma em dispositivos organizacionais e pessoais.

Guia de provas

Caso peçam para você enviar provas dessa proteção, siga as instruções em Elaboração de provas para preparar a política ou o procedimento e as provas de implementação.

Talvez você esteja usando uma ou duas das seguintes opções: 1) controles técnicos (como criptografia de disco) ou 2) regras ou políticas para reduzir o risco de perda de Dados da Plataforma armazenados em dispositivos organizacionais, como notebooks ou celulares.

Os controles técnicos podem incluir os seguintes:

• Impedir que dispositivos não gerenciados se conectem a serviços sensíveis, como a rede de produção.
• Aplicar a criptografia de disco em dispositivos gerenciados (como por BitLocker no Windows ou FileVault no Mac).
• Impedir que mídia removível seja usada (por exemplo, pen drive) em dispositivos gerenciados.
• Usar software de DLP em dispositivos gerenciados para evitar o manuseio inadequado dos Dados da Plataforma (como enviá-los em um anexo de email).

As regras ou as políticas podem incluir as seguintes:

• Documentação que descreva formas aceitáveis e inaceitáveis de manusear dados no geral e Dados da Plataforma em específico.
• Um mecanismo que faça com que os membros da organização estejam cientes das diretrizes (por exemplo, acordo contratual como condição de emprego, treinamento, lembretes periódicos por email).

Exemplo de prova

Uma organização classifica os Dados da Plataforma da Meta como “dados privados” conforme o próprio padrão de classificação de dados. Essa organização criou Diretrizes de Manuseio de Dados e obriga todos os funcionários a entender e cumprir essas políticas.

Protegendo Dados da Plataforma transmitidos por redes com criptografia em trânsito

Pergunta: Você habilita o protocolo de segurança TLS 1.2 ou superior para todas as conexões de rede que passem por, ou se conectem, ou cruzem redes públicas em que são transmitidos Dados da Plataforma? Além disso, você assegura que os Dados da Plataforma nunca são transmitidos por redes públicas em forma não criptografada (por exemplo, via HTTP ou FTP) e que os protocolos de segurança SSL v2 e SSL v3 nunca são usados?

Intenção

Os Dados da Plataforma transmitidos pela Internet são acessíveis a qualquer pessoa que possa observar o tráfego da rede. Portanto, eles devem ser protegidos com criptografia para evitar que partes não autorizadas possam ler os dados.

• A criptografia em trânsito protege os Dados da Plataforma quando são transmitidos por redes não confiáveis (por exemplo, a Internet), tornando-os indecifráveis, exceto para os dispositivos de origem e de destino.
• Em outras palavras, as partes no meio da transmissão não seriam capazes de ler os Dados da Plataforma mesmo que pudessem ver o tráfego da rede (isso também é chamado de ataque man-in-the-middle).
• O TLS é a forma mais usada de criptografia em trânsito porque é a tecnologia que os navegadores utilizam para proteger as comunicações com sites de bancos, por exemplo.

Resumo de requisitos

Se você trata Dados da Plataforma no servidor ou não:

• Os Dados da Plataforma nunca devem ser transmitidos por redes não confiáveis em formato não criptografado.
• Para todos os web listeners (por exemplo, balanceadores de carga voltados para a internet) que recebem ou retornam dados da plataforma, você deve:

  • Ativar o TLS 1.2 ou superior;
  • Desativar o SSL v2 e o SSL v3.
• O TLS 1.0 e o TLS 1.1 podem ser usados somente para compatibilidade com dispositivos de clientes que não são compatíveis com o TLS 1.2 ou versões superiores.
• A Meta recomenda, mas não exige, que a criptografia em trânsito seja aplicada às transmissões de Dados da Plataforma que estejam completamente dentro de redes privadas, como dentro de uma Virtual Private Cloud (VPC).

A tabela abaixo resume a política de criptografia em trânsito para diferentes tipos de transmissão.

Guia de provas

Caso peçam para você enviar provas dessa proteção, siga as instruções em Elaboração de provas para preparar a política ou o procedimento e as provas de implementação. O uso da ferramenta Qualys SSL Server Test é uma forma direta de produzir provas de implementação que demonstrem a configuração de um dos web listeners.

• Execute a ferramenta Qualys SSL Server Test em um ou mais dos web listeners que estão configurados de forma idêntica (incluindo qualquer um que seja executado em portas que não sejam as padrões).
• Marque a opção “Não mostrar os resultados nos painéis” para evitar que os resultados sejam adicionados ao site da Qualys. Imprima a página do(s) resultado(s) do teste em PDF e repita as etapas acima para qualquer web listeners que você use para transmitir ou receber Dados da Plataforma que tenham uma configuração de TLS diferente.

Exemplo de provas de implementação

Este é um exemplo do resultado da ferramenta Qualys SSL Server Test. Verifique as observações em vermelho na seção Configuração, que resume quais versões de SSL/TLS são compatíveis. Observação: este exemplo inclui apenas as primeiras duas páginas, mas você deve incluir o resultado do teste na íntegra.

Proteções alternativas aceitáveis

Talvez você proteja os Dados da Plataforma em trânsito com um tipo de criptografia diferente do TLS. Ele pode ser aceitável, se fornecer proteção equivalente. Nesse caso, você deve enviar os detalhes sobre a criptografia usada para a análise da Meta:

• Criptografia simétrica ou assimétrica?
• Algoritmo de criptografia (como AES, BitLocker, TDES, RSA)?
• Qual é o tamanho mínimo da chave?

Como testar o app e os sistemas para detectar vulnerabilidades e problemas de segurança

Pergunta: você testa o app e os sistemas para detectar vulnerabilidades e problemas de segurança pelo menos a cada 12 meses? Por exemplo, você realiza um teste de invasão manual?

Intenção

Os desenvolvedores devem realizar testes para detectar vulnerabilidades e problemas de segurança que podem ser descobertos com proatividade, prevenindo, assim, incidentes de segurança antes que eles aconteçam

• Desenvolvedores de apps que usam a plataforma da Meta para tratar Dados da Plataforma com software escrito por meio de apps ou de sistemas que eles configuram ou operam
• Configurações de software ou de sistema que podem conter vulnerabilidades de segurança que agentes maliciosos conseguem explorar, levando a um acesso não autorizado aos Dados da Plataforma

Resumo de requisitos

Aplicável a todos os desenvolvedores:

• É necessário ter testado o software que serviu para tratar os Dados da Plataforma e detectar vulnerabilidades de segurança ao realizar um dos seguintes itens:

  • um teste de invasão do app ou do sistema ou
  • uma verificação de vulnerabilidades ou uma análise estática do software.
• O resultado do teste deve mostrar que não existem vulnerabilidades críticas ou de alta gravidade não resolvidas.
• O teste deve ter sido realizado nos últimos 12 meses.

Outros requisitos para desenvolvedores que tratam Dados da Plataforma no servidor:

• É necessário ter testado o software no servidor especificamente para detectar vulnerabilidades de segurança ao realizar uma das seguintes opções:

  • um teste de invasão do app ou do sistema ou
  • uma verificação de vulnerabilidades ou uma análise estatística. Também é necessário ter testado a configuração da nuvem para detectar vulnerabilidades de segurança se você está usando um provedor de hospedagem de nuvem. Esse requisito se aplica independentemente da abordagem de hospedagem (como BaaS, PaaS, IaaS, auto-hospedagem ou híbrida).

Guia de provas

Caso peçam para você enviar provas dessa proteção, siga as instruções em Elaboração de provas para preparar a política ou o procedimento e as provas de implementação.

Se a organização trata os Dados da Plataforma em um ambiente de nuvem ou de servidor:

• Envie provas de que um teste de invasão foi concluído ou de que uma ferramenta SAST foi utilizada. As provas devem conter o seguinte:

  • uma declaração do escopo do teste;
  • a data de conclusão do teste (que deve ter acontecido nos últimos 12 meses);
  • um resumo ou uma lista das vulnerabilidades descobertas durante o teste junto com uma categorização de gravidade (por exemplo, crítica, alta, média, baixa ou informativa). Normalmente se espera que não existam vulnerabilidades de gravidade alta ou crítica não resolvidas.

• Se aplicável (isto é, se você está usando uma hospedagem em nuvem como AWS, GCP, Azure, entre outras), envie provas de que uma análise de configuração da nuvem foi feita, como o resultado da execução do Scout Suite (da NCC Group), do AWS Config ou de ferramentas similares. Caso isso não se aplique à sua organização, inclua, no envio das provas, um documento que explique o motivo para tal.
• Remova ou edite informações sensíveis, como etapas detalhadas de reprodução de vulnerabilidades, presentes nas provas antes de enviá-las

Se a organização não trata os Dados da Plataforma em um ambiente de nuvem ou de servidor:

• Envie provas de que um teste de invasão foi concluído ou de que uma ferramenta SAST foi utilizada. As provas devem conter o seguinte:

  • uma declaração do escopo do teste;
  • a data de conclusão do teste (que deve ter acontecido nos últimos 12 meses);
  • um resumo ou uma lista das vulnerabilidades descobertas durante o teste junto com uma categorização de gravidade (por exemplo, crítica, alta, média, baixa ou informativa). Normalmente se espera que não existam vulnerabilidades de gravidade alta ou crítica não resolvidas.
• Remova ou edite informações sensíveis, como etapas detalhadas de reprodução de vulnerabilidades, presentes nas provas antes de enviá-las

Exemplo de prova

Teste de invasão: uma organização encomenda esse tipo de teste em um software que está em execução no servidor, que se integra às APIs da Meta e que trata Dados da Plataforma. A empresa responsável pelo teste o realiza e elabora uma carta de resumo, como o exemplo abaixo. Observe que as anotações em vermelho destacam a data em que o teste foi realizado (o que deve ter acontecido nos últimos 12 meses) e que há um resumo dos achados não resolvidos com gravidade crítica ou alta ao final do teste ou, se aplicável, do reteste. Pedimos que você remova informações sensíveis do relatório (em particular, todas as etapas detalhadas de reprodução de vulnerabilidades) antes de enviá-lo.

Análise estática: se você está usando uma abordagem diferente, como uma ferramenta SAST, exporte os resultados para um documento com a data de execução do teste SAST e para uma lista com os tipos e as gravidades de cada achado.

Análise de configuração da nuvem

Um desenvolvedor usa o Scout Suite, da NCC Group, com o conjunto de regras padrão do provedor de nuvem (nesse caso, a AWS) para analisar a configuração da nuvem e detectar vulnerabilidades e problemas de segurança. A ferramenta retorna um arquivo JSON contendo os resultados detalhados da execução. Nesse exemplo, há um grande número de problemas sinalizados com gravidade “Danger” (“Perigosa”) que o desenvolvedor precisa analisar e resolver.

$ python3 scout.py aws –-no-browser
2022-08-22 11:39:38 localhost scout[76981] INFO Saving data to scoutsuite-report/scoutsuite-results/scoutsuite_results_aws-043954759379.js

$ cd scoutsuite-report/scoutsuite-results
$ tail -n +2 scoutsuite_results_aws-043954750000.js| jq '. | {last_run}' | pbcopy

{
  "last_run": {
    "ruleset_about": "This ruleset consists of numerous rules that are considered standard by NCC Group. The rules enabled range from violations of well-known security best practices to gaps resulting from less-known security implications of provider-specific mechanisms. Additional rules exist, some of them requiring extra-parameters to be configured, and some of them being applicable to a limited number of users.",
    "ruleset_name": "default",
    "run_parameters": {
      "excluded_regions": [],
      "regions": [],
      "services": [],
      "skipped_services": []
    },
    "summary": {
      "acm": {
        "checked_items": 4,
        "flagged_items": 2,
        "max_level": "warning",
        "resources_count": 2,
        "rules_count": 2
      },
      "awslambda": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 0
      },
      "cloudformation": {
        "checked_items": 11,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 11,
        "rules_count": 1
      },
      "cloudfront": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 3
      },
      "cloudtrail": {
        "checked_items": 153,
        "flagged_items": 4,
        "max_level": "danger",
        "resources_count": 17,
        "rules_count": 9
      },
      "cloudwatch": {
        "checked_items": 2,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 2,
        "rules_count": 1
      },
      "codebuild": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 0
      },
      "config": {
        "checked_items": 17,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 1227,
        "rules_count": 1
      },
      "directconnect": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 0
      },
      "dynamodb": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 1,
        "rules_count": 0
      },
      "ec2": {
        "checked_items": 760,
        "flagged_items": 108,
        "max_level": "danger",
        "resources_count": 44,
        "rules_count": 28
      },
      "efs": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 0
      },
      "elasticache": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 0
      },
      "elb": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 3
      },
      "elbv2": {
        "checked_items": 42,
        "flagged_items": 4,
        "max_level": "danger",
        "resources_count": 0,
        "rules_count": 5
      },
      "emr": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 0
      },
      "iam": {
        "checked_items": 801,
        "flagged_items": 27,
        "max_level": "danger",
        "resources_count": 87,
        "rules_count": 37
      },
      "kms": {
        "checked_items": 15,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 15,
        "rules_count": 1
      },
      "rds": {
        "checked_items": 1,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 27,
        "rules_count": 9
      },
      "redshift": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 6
      },
      "route53": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 1,
        "rules_count": 3
      },
      "s3": {
        "checked_items": 121,
        "flagged_items": 34,
        "max_level": "warning",
        "resources_count": 7,
        "rules_count": 18
      },
      "secretsmanager": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 1,
        "rules_count": 0
      },
      "ses": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 4
      },
      "sns": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 7
      },
      "sqs": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 8
      },
      "vpc": {
        "checked_items": 271,
        "flagged_items": 211,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 9
      }
    },
    "time": "2022-08-22 11:42:25-0400",
    "version": "5.11.0"
  }
}

Outra abordagem para desenvolvedores que usam o conjunto de regras da AWS realizarem uma análise de configuração da nuvem.

# Show that AWS Foundational Security Best Practices are enabled
$ aws securityhub get-enabled-standards                                                                                                            
{
    "StandardsSubscriptions": [
        {
            "StandardsSubscriptionArn": "arn:aws:securityhub:us-west-1:043954759379:subscription/aws-foundational-security-best-practices/v/1.0.0",
            "StandardsArn": "arn:aws:securityhub:us-west-1::standards/aws-foundational-security-best-practices/v/1.0.0",
            "StandardsStatus": "READY"
        }
    ]
}

# Show that aggregator is configured for a representative region used to process Platform Data
$ aws securityhub list-finding-aggregators

$ aws securityhub get-finding-aggregator --finding-aggregator-arn '{REPLACE-WITH-FINDING-AGGREGATOR-ARN}'


# Demonstrate that the ruleset is running by fetching active findings and counting the number of lines of output
$ aws securityhub get-findings --query 'Findings[?RecordState==`ACTIVE`]' --filters '{"GeneratorId":[{"Value": "aws-foundational-security","Comparison":"PREFIX"}]}' --output text | wc -l                                     

4876
# Demonstrate that there are no active critical severity findings
$ aws securityhub get-findings --query 'Findings[?Severity.Label==`CRITICAL`] | [?RecordState==`ACTIVE`] | [*][Title, GeneratorId]' --filters '{"GeneratorId":[{"Value": "aws-foundational-security","Comparison":"PREFIX"}]}'

[]

Proteções alternativas aceitáveis

Caso você esteja realizando um programa de divulgação de vulnerabilidade (VDP, pelas siglas em inglês) usando, por exemplo, as plataformas BugCrowd ou HackerOne, é possível apresentá-lo como uma proteção alternativa em vez de conduzir um teste de invasão ou uma verificação de vulnerabilidades. Para demonstrar isso, é necessário enviar provas de que:

• não existem exclusões do escopo do VDP relevantes à forma que você trata Dados da Plataforma;
• há pesquisas e relatórios de vulnerabilidade em andamento nos últimos 12 meses, normalmente indicados por, ao menos, um relatório válido por mês;
• as vulnerabilidades enviadas (válidas) recebem uma pontuação de gravidade de acordo com o sistema de pontuação de vulnerabilidade comum (CVSS, pelas siglas em inglês) 3.1, por exemplo; e
• as vulnerabilidades foram resolvidas em um intervalo razoável, geralmente em menos de 90 dias após a data do envio.

Nesse caso, a evidência deve incluir o seguinte:

• uma declaração do escopo e da forma como isso se relaciona com o software usado para tratar Dados da Plataforma e
• um relatório dos envios de vulnerabilidades no programa nos últimos 12 meses. O relatório deve apresentar o título da vulnerabilidade, a data de envio, a data de resolução (se resolvida) e a categoria ou a pontuação de gravidade.

Como proteger os tokens de acesso a APIs e a chave secreta do app da Meta

Pergunta: os tokens de acesso a APIs e as chaves secretas do app da Meta são protegidos das duas formas a seguir?

1. Não armazenando tokens de acesso a APIs da Meta em dispositivos clientes pelos quais é possível acessá-los fora do app e do usuário atuais.
2. Usando um cofre de dados (como o HashiCorp Vault) com serviço de gerenciamento de chaves (KMS, pelas siglas em inglês) caso estejam armazenados em um ambiente de nuvem, de servidor ou de data center.

Intenção

As chaves secretas do app e os tokens de acesso são fundamentais para as APIs da Meta tomarem decisões de segurança sobre quais ações permitir. Caso uma parte não autorizada tenha acesso a essas credenciais, ela pode chamar as APIs da Meta como se fosse o verdadeiro desenvolvedor e realizar qualquer uma das ações permitidas ao app (como ler dados das APIs da empresa sobre os usuários de um app).

• É necessário ter acesso a credenciais sensíveis como parte do uso da Plataforma da Meta, especificamente as seguintes:

  • Token de acesso: quando as pessoas autorizam o app, o software recebe uma credencial chamada token de acesso que é usada nas próximas chamadas a APIs.
  • Chave secreta do app: a Meta compartilha uma chave com desenvolvedores para que somente as partes confiáveis da organização (por exemplo, administradores do app) tenham acesso a ela.
• Uma parte não autorizada que consegue ler essas credenciais pode usá-las para chamar as APIs da Meta como se fosse você (o que é às vezes chamado de imitação de identidade via token), levando a um acesso não autorizado aos Dados da Plataforma.
• Por isso, é necessário proteger essas credenciais contra o acesso não autorizado para evitar a imitação de identidade.

Resumo de requisitos

Tokens de acesso

1. No dispositivo cliente: os tokens de acesso da Meta não devem ser gravados de modo que outro usuário ou processo possa lê-los.
2. No servidor: se você trata ou armazena tokens de acesso da Meta no servidor, eles:
1. devem ser protegidos usando um cofre de dados (como o HashiCorp Vault) com KMS, inclusive em casos nos quais o acesso à chave de descriptografia não se limita ao app; e
2. não devem ser gravados em arquivos de registro.

Chave secreta do app: uma destas duas alternativas deve ser verdadeira:

1. Você nunca expõe a chave secreta fora de um ambiente de servidor seguro. Por exemplo, ela nunca é retornada por uma chamada de rede a um navegador ou a um app para celular, além de não ser incorporada ao código que é distribuído a clientes nativos/desktop ou móveis.
2. Você deve ter configurado o app com o tipo Nativo/Desktop para que as APIs da Meta não confiem mais em chamadas a APIs que incluam a chave secreta do app.

Guia de provas

Caso peçam para você enviar provas dessa proteção, siga as instruções em Elaboração de provas para preparar a política ou o procedimento e as provas de implementação.

Inclua a documentação sobre a política de proteção dos tokens de acesso a APIs da Meta e sobre a chave secreta do app caso este processe tokens de acesso da Meta no servidor. Também inclua provas que demonstrem as proteções tomadas (isto é, uso de um cofre que armazena valores em um formato criptografado ou configuração do app para exigir provas da chave secreta).

Exemplo de prova

Uma organização usa o AWS Secrets Manager para armazenar dados sensíveis com segurança, incluindo a chave secreta do app da Meta.

Uma organização configurou o app da Meta para exigir provas da chave secreta em chamadas a APIs.

Proteções alternativas aceitáveis

1. Caso não proteja os tokens de acesso armazenados no servidor com um cofre de dados ou criptografia do app, você pode:
1. Proteger a chave secreta do aplicativo usando criptografia de cofre ou aplicativo, em que a chave somente é acessível ao aplicativo.
2. E configurar o aplicativo para exigir provas da chave secreta em todas as chamadas a APIs da Meta.
2. Caso a abordagem n.º 1 não seja viável (por exemplo, não é possível exigir provas da chave secreta do app porque isso bloquearia algumas chamadas necessárias a APIs), a Meta vai considerar qualquer outro controle que você tenha em vigor para reduzir o risco de uso não autorizado dos tokens de acesso em comparação ao risco de uso indevido dos tokens de acesso armazenados.

Tenha um plano de resposta a incidentes e teste os sistemas e processos de resposta a incidentes

Pergunta: Você testa os sistemas e processos que usaria para responder a um incidente de segurança (por exemplo, uma violação de dados ou um ataque cibernético) pelo menos a cada 12 meses?

Intenção

Incidentes de segurança ocorrem em todas as empresas em algum momento, portanto, é essencial que as organizações tenham planejado com antecedência quem, e de que forma, conterá o incidente, se comunicará com as partes interessadas, recuperará o sistema e analisará o que aconteceu.

• Caso haja um incidente de segurança, ter um plano ou um guia, com uma equipe de pessoas treinadas, pode reduzir a duração do evento e, em última instância, limitar a exposição dos Dados da Plataforma.
• Embora organizações diferentes tenham níveis distintos de sofisticação de resposta a incidentes, exigimos, pelo menos, um plano básico que inclua as atividades principais - detectar, reagir, recuperar e analisar em conjunto com o pessoal nomeado para as funções e responsabilidades.

Resumo de requisitos

O desenvolvedor deve ter:

• Um plano de resposta a incidentes que atenda aos critérios mínimos da Meta.
• Esse documento deve incluir (pelo menos): (1) funções e responsabilidades, (2) detecção, (3) etapas para reagir de acordo com as obrigações legais aplicáveis (por exemplo, notificação de violação de dados às autoridades supervisoras e titulares de dados relevantes) e recuperação, e (4) um processo de análise pós-incidente.
• Provas documentadas que demonstrem que o plano foi testado recentemente (nos últimos 12 meses) e que todo o pessoal nomeado no plano participou dele.

Guia de provas

Siga as instruções em Elaboração de provas para preparar a política ou o procedimento e as provas de implementação.

• Envie o plano de resposta a incidentes (um ou mais documentos). Ele deve conter os seguintes tópicos: funções e responsabilidades, detecção, reação e recuperação e análise pós-incidente.

  • Se você não tiver um plano de resposta a incidentes, há muitos recursos disponíveis na internet que podem ajudar. Por exemplo, leia o Modelo de plano de resposta a incidentes da Counteractive e Referências e leitura adicional.
• Envie provas que demonstrem que você testou o plano nos últimos 12 meses. Essa prova pode ser enviada em diferentes formatos, mas deve incluir:

  • Uma descrição da situação (por exemplo, um exercício de simulação em resposta a um ataque de ransomware);
  • A data em que o teste foi realizado;
  • A função de cada participante;
  • Uma justificativa para cada um dos funcionários nomeados na seção de funções e responsabilidades do plano que não tiver participado.
• Remova informações sensíveis (por exemplo, PII, como nome e endereço de email da pessoa) dessa prova antes de enviá-la.

Plano de resposta a incidentes

Um desenvolvedor criou um plano abrangente de resposta a incidentes com base neste modelo. Essas imagens mostram apenas o índice, mas há um link abaixo para acessar o modelo completo.

Veja o Modelo completo de plano de resposta a incidentes da Counteractive (formato docx)

Teste de resposta a incidentes

Um desenvolvedor realizou um teste do próprio plano de resposta a incidentes por meio de um exercício de simulação e documentou o resultado com base nesse modelo.

Como exigir a autenticação multifatorial para o acesso remoto

Pergunta: você exige a autenticação multifatorial para o acesso remoto de cada conta capaz de se conectar ao ambiente de nuvem ou de servidor e/ou de acessar os serviços usados para implantar, manter, monitorar e operar os sistemas onde você armazena os Dados da Plataforma da Meta?

Intenção

Uma técnica comum que agentes maliciosos usam para acessar dados confidenciais é ganhar acesso às ferramentas que desenvolvedores usam para criar ou operar apps ou sistemas. Existem ferramentas sofisticadas para invadir contas protegidas apenas com senhas. Por isso, para proteger as pessoas contra esse risco, a autenticação multifatorial oferece uma camada adicional de segurança.

• Os desenvolvedores de software usam uma variedade de ferramentas para criar, implantar e administrar apps ou sistemas.
• É comum utilizar essas ferramentas remotamente pela internet. Por exemplo, um funcionário que trabalha de casa envia o novo recurso de um software ou atualiza a configuração da nuvem.
• As ferramentas protegidas com autenticação de fator único (nome de usuário e senha) são altamente suscetíveis a invasões de conta. Por exemplo, os agentes maliciosos podem usar programas para tentar combinações de nome de usuário e senha que tenham vazado de uma ferramenta para ganhar acesso a outra.
• A autenticação multifatorial protege contra esses ataques, pois exige não só uma senha no login, mas também um fator adicional, como um código de um app autenticador.

Resumo de requisitos

Quanto ao tratamento de Dados da Plataforma realizado por uma organização, é necessário proteger o acesso remoto às seguintes ferramentas com autenticação multifatorial (ou seja, não somente com uma senha):

• Ferramentas utilizadas para implantar e gerenciar mudanças de código/configuração do app/sistema
• Acesso administrativo a um ambiente de nuvem ou de servidor, se aplicável.

Especificamente, é necessário ativar a autenticação multifatorial ou ter uma proteção alternativa aceitável nos seguintes casos:

• Ferramentas de colaboração ou de comunicação: por exemplo, email comercial ou Slack.
• Repositório de código: por exemplo, GitHub ou outra ferramenta usada para rastrear alterações no código ou na configuração do app ou do sistema.
• Se você trata Dados da Plataforma no servidor:

  • Ferramentas de implantação de software: ferramentas usadas para implantar código no ambiente de nuvem ou de servidor, como Jenkins ou outra ferramenta de integração ou de implantação contínua (CI/CD).
  • Ferramentas administrativas: portal ou outro acesso usado para gerenciar ou monitorar o ambiente de nuvem ou de servidor.
  • Acesso remoto a servidores: SSH, área de trabalho remota ou ferramentas similares usadas para login remoto em servidores em execução no servidor.

Quanto à implementação da autenticação multifatorial:

• É recomendado o uso de um app ou de um hardware autenticador (como YubiKey) em vez de códigos enviados por SMS.
• Entretanto, as organizações podem usar qualquer implementação de autenticação multifatorial.

Guia de provas

Caso peçam para você enviar provas dessa proteção, siga as instruções em Elaboração de provas para preparar a política ou o procedimento e as provas de implementação.

• Mostre que aplica a autenticação multifatorial às ferramentas aplicáveis ao ambiente e listadas acima (como ferramentas de colaboração, repositório de código, implantação na nuvem ou no servidor, portal administrativo na nuvem ou no servidor, acesso remoto na nuvem ou no servidor).
• A implementação varia de acordo com a configuração:

  • Por exemplo, se você está usando um provedor SSO, pode ser uma captura de tela de uma configuração global da organização ou de uma configuração por app.
  • Se você não tem um provedor SSO, pode ser uma captura de tela da configuração de uma ferramenta específica.
• Em qualquer caso, precisamos de provas de que a autenticação multifatorial está ativada para todos os usuários, e não somente um exemplo de uma conta com ela ativada.

Exemplo de prova

Azure AD

Uma organização usa o Azure AD como solução de login único (SSO). Essa política exige a autenticação multifatorial.

Depois, ela mapeia os apps na nuvem aos quais se aplica. Com essa abordagem, é necessário que as provas mostrem toda a seção Itens selecionados para deixar claro quais apps na nuvem exigem esse tipo de autenticação.

Okta

Essa regra exige a autenticação multifatorial para todos os logins.

AWS IAM

Esse é um exemplo de uma política do AWS IAM que permite a configuração de autenticação multifatorial, mas proíbe outras ações caso esse tipo de autenticação esteja ausente.

GitHub

Uma organização configurou o GitHub para exigir a autenticação multifatorial de todas os membros.

Proteções alternativas aceitáveis

• Com relação a qualquer tipo de acesso remoto que exista na organização, mas em que a autenticação multifatorial não é aplicada, é necessário descrever se você está usando uma ou mais das seguintes abordagens para evitar invasões de conta:

  • Requisitos de senha forte: por exemplo, exigir uma complexidade mínima para senhas, proibir palavras do dicionário ou senhas que são conhecidas por terem sido violadas anteriormente.
  • Recuo de autenticação: uso de uma ferramenta que introduz períodos de espera cada vez mais longos entre tentativas falhas de login da mesma fonte.
  • Bloqueios automáticos: por exemplo, um mecanismo para bloquear, automaticamente, o login em um conta após dez tentativas falhas.

Como ter um sistema para cuidar de contas de usuário

Pergunta: você tem um sistema para cuidar de contas, o que inclui atribuir, revogar e analisar acesso e privilégios?

Intenção

Ter um bom gerenciamento de contas é importante para evitar o uso não autorizado delas e, por consequência, o acesso aos Dados da Plataforma. Em particular, os desenvolvedores devem garantir que o acesso aos recursos ou sistemas seja revogado quando não é mais necessário.

• As contas são a unidade básica de gerenciamento para conceder acesso aos sistemas, dados e funções administrativas
• Elas recebem permissões que autorizam ações específicas. Por isso, é uma boa prática conceder apenas as permissões mínimas de que uma conta precisa. Isso é chamado de princípio do menor privilégio
• Quando uma pessoa deixa uma organização, é fundamental que as contas de usuário dela sejam imediatamente desativadas pelas seguintes razões:

  • (1) para impedir o acesso dessa pessoa (ou seja, o ex-funcionário) e
  • (2) para reduzir a probabilidade de uma pessoa não autorizada usar a conta sem ser notada. Por exemplo, um agente malicioso pode usar engenharia social para fazer com que o suporte de TI redefina a senha da conta. Se essa conta pertence a um funcionário atual, é provável que ele informe que não consegue fazer login, mas, se a conta ainda está ativa e pertence a um ex-funcionário, é menos provável que o ataque seja notado.
• Com isso em mente, as organizações devem ter uma forma sistemática de gerenciar contas, conceder permissões ou privilégios e revogar o acesso quando ele não é mais necessário.

Resumo de requisitos

• É necessário ter uma ferramenta ou um processo para gerenciar as contas de cada uma dessas ferramentas, sistemas ou apps:

  • programas usados para comunicação, como o Slack ou email corporativo;
  • programas usados para enviar software, como um repositório de código; e
  • programas para administrar e operar o sistema (conforme aplicável ao tratamento de Dados da Plataforma).
• É necessário analisar periodicamente (ou seja, pelo menos uma vez a cada 12 meses) as concessões de acesso e ter um processo de revogação quando: (1) o acesso não é mais necessário e (2) as concessões não são mais usadas
• Também é necessário ter um processo para revogar imediatamente o acesso a essas ferramentas quando uma pessoa deixa a organização.
• A Meta não exige que:

  • uma ferramenta em particular seja usada. Por exemplo, os desenvolvedores podem usar um produto de diretório, como Cloud Identity, da Google, ou Azure Active Directory, da Microsoft, um produto de nuvem, como AWS Identity and Access Management (IAM), ou uma planilha que seja atualizada com frequência.
  • exista apenas uma ferramenta consolidada para gerenciar contas em diferentes tipos de acesso.

Guia de provas

Siga as instruções em Elaboração de provas para preparar a política ou o procedimento e as provas de implementação.

• Política ou procedimento: providencie políticas documentadas e documentos de procedimento que abordem as práticas de gerenciamento de contas. Espera-se que esse documento apresente procedimentos para criar e redefinir contas e conceder permissões, requisitos mínimos de senha, políticas de bloqueio de conta e de autenticação de vários fatores e processos para revogar o acesso após um período de inatividade e quando as pessoas deixam a organização (isto é, quando um funcionário pede demissão ou é demitido).
• Provas de implementação: apresente provas de ao menos uma das seguintes ferramentas ou processos que esteja em vigor para gerenciar contas ou indique como não aplicável ao ambiente: (1) email corporativo e ferramentas de colaboração, (2) repositório de código, (3) ferramentas de implantação de nuvem ou de servidor, (4) portal administrativo de nuvem ou de servidor, (5) login remoto de nuvem ou de servidor (como SSH ou área de trabalho remota). No caso de ferramentas ou processos diferentes, inclua provas que demonstrem que:

  • as pessoas que deixaram a organização tiveram o acesso a essas ferramentas revogado, como um relatório de reconciliação que compara as contas de usuário com os dados oficiais dos atuais membros da organização e
  • o acesso não usado durante certo tempo é revogado, como um relatório que mostra que a data do último acesso de um titular de conta de usuário ativa está dentro dos últimos 90 dias se o período máximo de inatividade é de três meses.

Exemplo de prova

Política ou procedimento: um desenvolvedor criou um padrão de gerenciamento de ciclo de vida de acesso que inclui procedimentos para conceder, analisar e revogar acesso.

Exemplo de implementação: o acesso é revogado para ex-funcionários

Um desenvolvedor usa o Workday como fonte oficial para os dados de recursos humanos (RH), incluindo status de emprego atual. Ele usa o Cloud Identity, da Google, como provedor de identidade (IdP) para gerenciar contas de usuário e conceder acesso aos sistemas e ferramentas de informação.

Um desenvolvedor envia provas de que o acesso é revogado para ex-funcionários. Para isso, ele providencia um relatório de conciliação recente (ou seja, dentro dos últimos 12 meses) do Workday que mostra que nenhuma conta de usuário ativa existe no Cloud Identity para quem não é funcionário ativo.

Exemplo de implementação: o acesso é revogado ao deixar de ser usado

Um desenvolvedor usa o Cloud Identity, da Google, como provedor de identidade (IdP) para gerenciar contas de usuário e conceder acesso aos sistemas e ferramentas de informação.

Um desenvolvedor envia provas de que o acesso é revogado quando deixa de ser usado (ou seja, nenhum login nos últimos seis meses). Para isso, ele mostra o diretório de usuários classificado pelo último login para demonstrar que não há contas de usuário ativas nos casos em que o último login foi há mais tempo do que o definido.

Exemplo de implementação: GitHub (repositório de código)

Um desenvolvedor usa uma ferramenta de login único (SSO) para gerenciar identidades e conceder acesso aos sistemas e ferramentas de informação e configurou o GitHub para exigir autenticação SSO.

Como manter softwares atualizados

Pergunta: você tem um sistema para manter o código e os ambientes atualizados, incluindo servidores, máquinas virtuais, distribuições, bibliotecas, pacotes e software antivírus?

Intenção

Os componentes de software são constantemente atualizados ou corrigidos para resolver vulnerabilidades de segurança. No entanto, em algum momento, a vida útil deles chega ao fim quando deixam de ser compatíveis. Os desenvolvedores que empacotam ou usam esses componentes devem se manter atualizados para evitar a execução de software com vulnerabilidades conhecidas.

• Os desenvolvedores de apps usam uma variedade de softwares de terceiros para executar apps ou sistemas que tratam Dados da Plataforma.
• Confira alguns desses softwares:

  • Bibliotecas, SDKs, pacotes: os desenvolvedores empacotam esses softwares com seu próprio código personalizado para construir um app.
  • Imagens de máquinas virtuais, contêineres de apps e sistemas operacionais: um app é executado dentro de um ou mais desses contêineres, que oferecem serviços como virtualização e acesso a redes e armazenamento.
  • Navegadores, sistemas operacionais e outros apps que funcionários ou colaboradores usam: software que é executado nos dispositivos móveis e nos notebooks que um desenvolvedor usa para criar e executar o sistema.
• Vulnerabilidades de segurança são constantemente encontradas nesses componentes, levando ao lançamento de patches.
• Essas vulnerabilidades são então divulgadas em bancos de dados públicos com uma classificação de gravidade (baixa, média, alta ou crítica).
• Por isso, é necessário que os desenvolvedores que usam a plataforma da Meta tenham uma forma sistemática de gerenciar os patches das seguintes maneiras:

  • identificando aqueles que são relevantes para o app ou o sistema deles;
  • Priorização da urgência com base na exposição e
  • aplicando-os como uma atividade comercial contínua

Resumo de requisitos

Para os seguintes componentes de software, conforme aplicável, é necessário ter uma forma definida e repetível de identificar os patches disponíveis que resolvem as vulnerabilidades de segurança, priorizando com base no risco e os aplicando continuamente:

1. Bibliotecas, SDKs, pacotes, contêineres de apps e sistemas operacionais usados em um ambiente de nuvem ou de servidor
2. Bibliotecas, SDKs, pacotes usados em dispositivos clientes, como em apps para celular
3. Sistemas operacionais e apps que os membros da organização usam para criar e operar o app ou o sistema, como sistemas operacionais e navegadores executados em notebooks dos funcionários

A Meta não exige o uso de nenhuma ferramenta específica para essas atividades. É comum que uma organização use mais de uma abordagem para manter diferentes tipos de software atualizados. Por exemplo, bibliotecas que são empacotadas com o app em comparação a atualizações do sistema operacional para notebooks dos funcionários.

O diagrama abaixo ilustra onde a aplicação de patches pode ser necessária para vários tipos de arquitetura.

Guia de provas

Caso peçam para você enviar provas dessa proteção, siga as instruções em Elaboração de provas para preparar a política ou o procedimento e as provas de implementação.

Comece identificando os tipos de software dentro do escopo no ambiente, como bibliotecas, SDKs, pacotes, imagens de máquina virtual, contêineres de apps, sistemas operacionais, navegadores e outros apps que funcionários ou colaboradores usam.

Talvez você tenha uma ou mais ferramentas destinadas às seguintes atividades:

• Inventário: com uma tela de captura ou um documento, demonstre que uma ferramenta ou um processo representa, em última análise, uma lista das bibliotecas, dos pacotes, dos SDKs, dos contêineres, dos servidores de app e dos sistemas operacionais dentro do escopo que precisam ser corrigidos. É necessário que existam inventários para um representante dos tipos de software, como apps de nuvem, apps clientes ou dispositivos de funcionários.
• Identificação de patches disponíveis para softwares: é necessário que haja uma ferramenta ou um processo que identifique patches de segurança relevantes para o inventário.
• Priorização: é necessário que exista uma ferramenta ou um processo, como tíquetes do Jira, problemas do GitHub, planilhas de rastreamento, para atribuir uma prioridade a patches relevantes.

  • Aplicação de patches
  • Com uma tela de captura ou um documento, demonstre que, após a identificação e a priorização de patches relevantes, eles são implementados em vários destinos.
• Inclua políticas sobre tempo de resolução e uso de software no final da vida útil.

Exemplo de prova

Snyk para um app NodeJS: um desenvolvedor usa a interface de linha de comando (CLI, pelas siglas em inglês) da Snyk para identificar dependências de terceiros empacotadas que têm vulnerabilidades de segurança conhecidas e priorizá-las com base na gravidade delas.

Auditoria npm

Um desenvolvedor está usando a auditoria npm para encontrar vulnerabilidades nas dependências usadas em um app Node. A imagem de exemplo abaixo mostra várias vulnerabilidades de alta gravidade que precisam ser corrigidas.

Trivy

Um desenvolvedor usa o Trivy para encontrar vulnerabilidades em uma imagem de máquina. A imagem de exemplo abaixo mostra vulnerabilidades de alta gravidade que precisam ser corrigidas e estão localizadas em bibliotecas incluídas nessa imagem.

Windows Server Update Services (WSUS)

Um desenvolvedor usa o WSUS para gerenciar os servidores, assim como os PCs e os notebooks. A imagem de exemplo abaixo mostra um modo de exibição do administrador do WSUS, que permite analisar, aprovar e implantar atualizações do Windows.

Como ter um sistema em funcionamento para registrar acesso aos Dados da Plataforma e rastrear para onde eles foram enviados e armazenados

Intenção

Sem arquivos de registro confiáveis, pode ser difícil, ou até mesmo impossível, para um desenvolvedor detectar acessos não autorizados aos Dados da Plataforma.

• Os registros de auditoria permitem que uma organização grave que um evento ocorreu, como quando um determinado usuário fizer uma consulta em tabelas que contêm Dados da Plataforma.
• Esses registros podem fornecer suporte a processos como a ativação de alertas automatizados com base em atividade suspeita ou a análise forense após a identificação de um incidente de segurança.

Resumo de requisitos

Caso você trate Dados da Plataforma no servidor, dentro desse ambiente:

• Você deve manter registros de auditoria que gravem os principais eventos (por exemplo, acesso aos Dados da Plataforma, uso de contas com permissões elevadas, alterações nas configurações do registro de auditoria).
• Os registros de auditoria devem ser consolidados em um repositório central e protegidos contra alterações e exclusões.

Guia de provas

Caso peçam a você que envie provas, elas devem demonstrar que:

• Você tem conhecimento atual sobre como os Dados da Plataforma são armazenados, acessados e transferidos, por exemplo, por meio de um diagrama de fluxo de dados que fornece uma visão geral do sistema, designa serviços que armazenam os Dados da Plataforma e mostra os pontos de ingresso e egresso, incluindo transferências esperadas para quaisquer serviços quarteirizados.
• Você implementou registros de auditoria invioláveis.
• Os eventos relacionados ao acesso aos dados da plataforma são gravados nos registros.

Como monitorar transferências de Dados da Plataforma e pontos principais onde os Dados da Plataforma podem sair do sistema (por exemplo, terceiros, pontos de extremidade públicos)

Intenção

Entender como se espera que os Dados da Plataforma sejam tratados e monitorar a execução de tal tratamento é uma maneira importante de uma organização garantir que os Dados da Plataforma sejam usados apenas para os fins pretendidos.

• Um desenvolvedor precisa manter um conhecimento atualizado de como os Dados da Plataforma são armazenados, transmitidos por redes e gravados em backups (que podem ser replicados em outro lugar).
• Por exemplo, o monitoramento pode identificar situações em que os Dados da Plataforma estão sendo transmitidos de maneira inesperada ou se estão sendo transmitidos por uma rede sem criptografia adequada em trânsito para que você possa tomar medidas.

Resumo de requisitos

Caso você trate Dados da Plataforma no servidor, é necessário fazer o seguinte dentro desse local:

• Manter um diagrama de fluxo de dados preciso que mostre onde os Dados da Plataforma são armazenados, tratados e transmitidos pelas redes.
• Configurar o monitoramento (por exemplo, registros de auditoria com um produto de monitoramento automatizado) para transferências de Dados da Plataforma fora do sistema.
• Configurar, se possível, o sistema de monitoramento para gerar alertas que sejam analisados prontamente no caso de transferências inesperadas de Dados da Plataforma (veja também o requisito abaixo - Como ter um sistema automatizado para monitorar registros e outros eventos de segurança e gerar alertas para eventos anormais ou relacionados à segurança)

Guia de provas

Caso peçam para você enviar provas dessa proteção, siga as instruções em Elaboração de provas para preparar a política ou o procedimento e as provas de implementação.

Você deve fornecer provas que demonstrem o seguinte:

• Você tem conhecimento atual sobre como os Dados da Plataforma são armazenados, acessados e transferidos, por exemplo, por meio de um diagrama de fluxo de dados que fornece uma visão geral do sistema, designa serviços que armazenam os Dados da Plataforma e mostra os pontos de ingresso e egresso, incluindo transferências esperadas para quaisquer serviços quarteirizados.
• Registros de auditoria invioláveis foram implementados.
• Eventos relacionados a transferências de Dados da Plataforma são capturados nos registros; os eventos devem incluir a hora, a identidade do usuário ou o aplicativo que está realizando a ação, além da origem e o destino.

Como ter um sistema automatizado para monitorar registros e outros eventos de segurança e gerar alertas para eventos anormais ou relacionados à segurança

Intenção

Depender de seres humanos para analisar e identificar comportamentos inesperados em um sistema moderno acessível pela internet é algo inviável. Em vez disso, existem ferramentas que podem ingerir arquivos de registro e outros sinais para disparar alarmes que precisam de mais investigação humana.

Resumo de requisitos

Caso você trate Dados da Plataforma no servidor, é necessário fazer o seguinte dentro desse local:

• Ter uma ferramenta capaz de ingerir arquivos de registro e outros eventos e de estabelecer regras que devem disparar alarmes, se acionadas, além de um mecanismo para encaminhar alarmes às pessoas (como um investigador de segurança de plantão);
• Ingerir sinais relevantes na ferramenta (como registros de acesso web, tentativas de autenticação, ações que usuários com privilégios elevados realizaram, entre outros); e
• Ajustar as regras para equilibrar os sinais e a interferência ao longo do tempo (ou seja, evitando muitos alarmes falsos, mas também levando em consideração eventos que requerem investigação).

Guia de provas

Um desenvolvedor normalmente adotaria uma ferramenta de Gerenciamento de Eventos e Informações de Segurança (SIEM, na sigla em inglês) para esse fim, por exemplo:

• McAfee Enterprise Security Manager
• SolarWinds Security Event Manager
• Splunk Enterprise Security
• Sumo Logic

É necessário fornecer provas de que as fontes de sinais relevantes estão sendo encaminhadas para a ferramenta da sua escolha, que os disparos ou os alarmes foram configurados, que os alarmes são encaminhados para o pessoal responsável pelo acompanhamento e que existe um processo pelo qual os alarmes são ajustados periodicamente (ou seja, por meio de ciclos mensais de análise e de atualização).

Glossário

A

Terceirizados - na terminologia de gestão de riscos, “terceirizados” se refere a desenvolvedores na plataforma da Meta (a parte primária é a própria Meta; a secundária são as pessoas que usam os produtos da Meta)

Quarterizados - na terminologia de gestão de riscos, “quarteirizados” se refere às firmas às quais os desenvolvedores recorrem para obter serviços que lhes permitem realizar sua atividade (a parte primária é a Meta, a secundária são os usuários da Meta, e os terceirizados são os desenvolvedores na plataforma da Meta) Token de acesso - uma credencial, como uma senha, que permite que um software acione uma API para realizar alguma ação (por exemplo, ler dados do perfil de um usuário).

Amazon Web Services (AWS) - um conjunto de serviços de computação em nuvem da Amazon

ID no escopo do app (ASID) - um identificador único gerado pela Meta quando uma pessoa decide usar um app. Os ASIDs ajudam a melhorar a privacidade dos usuários tornando mais difícil para os conjuntos de dados correlacionarem usuários em diferentes apps, já que um único usuário que use dois apps terá ASIDs diferentes em cada um deles.

Chave secreta do app - um segredo compartilhado que a Meta disponibiliza aos desenvolvedores por meio do painel do app. A posse da chave secreta do app autoriza o software a realizar algumas ações por meio da Graph API, portanto, os desenvolvedores precisam tomar cuidado para que usuários não autorizados não possam acessar a chave secreta do app.

Comprometimento do app - o comprometimento do app é quando um indivíduo mal-intencionado consegue obter acesso não autorizado à rede interna de uma organização por meio de uma configuração incorreta ou de uma vulnerabilidade do respectivo app (por exemplo, uma vulnerabilidade de software em um app da web). Uma defesa contra o comprometimento do app consiste em submetê-lo a um teste de penetração. Consulte também comprometimento da rede.

Contêiner do app - um contêiner empacota um código de software e as respectivas dependências para que o app possa ser executado em diferentes tipos de servidores (por exemplo, servidores executados em diferentes sistemas operacionais, como Linux ou Windows Server). Um desenvolvedor cria uma imagem de contêiner que empacota o respectivo app. Um mecanismo de contêiner ou tempo de execução de app hospeda (executa) a imagem de contêiner.

Criptografia de app - um método para proteger dados em que o próprio software do app realiza as operações de criptografia e descriptografia. Por outro lado, a Transport Layer Security (TLS) criptografa sem interrupções os dados em trânsito quando um app estabelece uma conexão segura com um servidor remoto (por exemplo, usando HTTPS), e os provedores de nuvem oferecem serviços para criptografar dados em repouso de forma transparente.

Interface de Programação de Apps (API) - permite que dois computadores se comuniquem por meio de uma rede, como quando um app para celular obtém as condições meteorológicas de hoje em um determinado local a partir de um sistema de previsões climáticas centralizado.

Comprovação da chave secreta do app - uma camada de segurança adicional para chamadas de API à Meta em que um desenvolvedor gera um parâmetro (a comprovação da chave secreta do app) que demonstra que ele possui a chave secreta do app. A comprovação dessa chave é o produto de uma função de codificação em hash (também denominada função unidirecional) baseada na chave secreta do app e no token de acesso. Configurar um app de modo que ele exija comprovações da chave secreta do app reduz os danos potenciais decorrentes de uma violação dos tokens de acesso dos usuários, já que esses tokens não podem ser usados sem o parâmetro adicional da comprovação da chave secreta do app.

B

Back-end como serviço (BaaS) - um tipo de computação em nuvem que fornece um conjunto de recursos no servidor para um desenvolvedor de apps, de modo que o desenvolvedor possa se concentrar em construir o front-end (ou seja, a parte de um app com a qual os usuários interagem). As soluções de BaaS são semelhantes às de PaaS, e além disso adicionam incluem serviços como autenticação de usuários e notificações push para dispositivos móveis. Por exemplo, estes são alguns produtos de BaaS populares: AWS Amplify, Azure Mobile Apps, Firebase e MongoDB Switch.

C

Texto criptografado - um sinônimo de dados criptografados; texto criptografado é o nome atribuído a dados que tenham sido tornados ilegíveis por meio de algum algoritmo de criptografia. O antônimo de texto criptografado é texto sem formatação.

Lado do cliente - as pessoas geralmente interagem com serviços acessíveis via Internet abrindo um site em um navegador ou executando um app para celular em um smartphone ou tablet. O navegador ou o app para esses dispositivos são denominados clientes locais ou lado do cliente. Os clientes fazem solicitações a partir de computadores remotos (servidores) pela Internet.

Computação em nuvem - um tipo de gerenciamento de computadores servidores, redes e armazenamento de modo que uma organização não precise se preocupar com o ambiente físico (ou seja, um data center repleto de racks de servidores e cabos de rede). Em vez disso, a organização pode obter esses ativos sob demanda e pagar pelos serviços consumidos.

Configuração de nuvem - um conjunto de opções de computação em nuvem que uma organização estabeleceu com relação a seu uso de um provedor de serviços de nuvem que executa um determinado software. Os exemplos de configuração de nuvem incluem quais tipos de conexões de rede são permitidos ou bloqueados, onde os arquivos de registros são gravados e por quanto tempo são mantidos, assim como o conjunto de usuários autorizados a fazer alterações na configuração de nuvem.

Controles de compensação - um controle de segurança que difere de um conjunto básico de requisitos, mas que é destinado a fornecer uma proteção comparável contra um determinado risco.

D

Banco de dados - um software que permite armazenar, ler, atualizar e excluir dados arbitrários. Os bancos de dados podem ser executados em clientes ou em servidores. As organizações que se integram à plataforma da Meta geralmente armazenam os dados obtidos da Graph API em um banco de dados executado no servidor.

Descriptografia - o processo pelo qual os dados criptografados são transformados de volta ao seu formato original. Em outras palavras, a descriptografia transforma texto criptografado em texto sem formatação.

E

Criptografia - o processo pelo qual os dados são transformados em um formato que é inutilizável por qualquer pessoa que não consiga descriptografá-los. Em outras palavras, a criptografia transforma texto sem formatação em texto criptografado.

Criptografia em repouso - refere-se a dados que foram protegidos com criptografia ao serem gravados em armazenamento persistente (por exemplo, em uma unidade de disco). A criptografia em repouso fornece uma camada de proteção adicional contra acesso não autorizado, já que uma pessoa que consiga ler os arquivos brutos no dispositivo de armazenamento verá texto criptografado, e não conseguirá descriptografá-lo, a não ser que consiga também ter acesso à chave de descriptografia.

Criptografia em trânsito - refere-se a dados que foram protegidos com criptografia ao serem transmitidos por meio de uma rede. A criptografia em trânsito fornece proteção contra escutas não autorizadas ao longo do caminho da rede, já que uma pessoa que consiga ler os pacotes de rede verá texto criptografado, e não conseguirá descriptografá-lo, a não ser que consiga também ter acesso à chave de descriptografia.

Software em fim de vida (EOL) - quando uma organização decide parar o suporte (por exemplo, a criação de patches para resolver vulnerabilidades de segurança) a um produto de software, o software em questão é considerado como EOL. Como o software já não é mantido, é muito arriscado executar qualquer software EOL.

G

Google Cloud Platform (GCP) - o conjunto de serviços de computação em nuvem do Google Graph API - a maneira principal em que os apps leem e gravam no gráfico social da Meta. Todos os SDKs e produtos da Meta interagem de alguma forma com a Graph API.

H

Função de codificação em hash - uma função criptográfica que admite quaisquer dados como entrada e emite como saída um código curto que não pode ser revertido para os dados de entrada originais. Em criptografia, as funções de codificação em hash são usadas para proteger dados como senhas: em vez de armazenar a senha de um usuário como texto sem formatação que poderia ser roubado, elas são primeiro transformadas como uma função de codificação em hash e, em seguida, armazenadas. Posteriormente, para confirmar que um usuário inseriu a senha correta, o sistema usará a mesma função de codificação em hash para transformar os dados de entrada e comparar o resultado com o valor armazenado. Ela também é denominada função unidirecional, já que o hash de saída não pode ser revertido para os dados de entrada originais.

Ambiente hospedado - conjunto de servidores, redes e dispositivos de armazenamento remotos que uma organização está executando em um data center próprio ou alugado e compartilhado com outros clientes locatários. Essa configuração é relativamente pouco comum na era moderna, uma vez que a computação em nuvem se tornou mais popular.

I

Provedor de identidade (IdP) - um serviço em nuvem usado para centralizar o gerenciamento de identidades digitais e autenticar usuários. Geralmente, as organizações que usam um IdP configuram os apps de nuvem para recorrerem a ele para autenticação de usuários. Em seguida, a organização pode gerenciar os usuários criando e concedendo acesso a apps selecionados e desabilitando contas de usuários centralmente a partir do IdP, em vez de ter que fazer isso repetidamente para cada app na nuvem.

Gerenciamento de Identidade e Acesso (IAM) - uma categoria de ferramentas e processos usados para gerenciar contas e conceder acesso a sistemas.

Infraestrutura como Serviço (IaaS) - uma abordagem de computação em nuvem que permite que os clientes configurem os serviços de computação, armazenamento e rede sem ter responsabilidade pelos ativos físicos em si (por exemplo, gerenciar um data center repleto de servidores, dispositivos de rede e matrizes de armazenamento). Em comparação com a PaaS, a IaaS dá à organização mais controle sobre a configuração de seus ativos em nuvem, mas com o custo de uma maior complexidade para gerenciar os ativos em questão. Por exemplo, estes são alguns produtos de IaaS populares: AWS EC2, Microsoft Azure IaaS e Google Compute Engine.

L

Biblioteca - é composta por elementos básicos de software preexistentes, normalmente fornecidos por uma empresa ou desenvolvedor externo, usados para lidar com determinadas tarefas em outro app ou sistema para desenvolvedores. A biblioteca simplifica o desenvolvimento de um app, já que o desenvolvedor não precisa reinventar a roda quando já existe uma biblioteca para uma determinada função. No entanto, as bibliotecas podem conter vulnerabilidades de segurança, ou podem incluir outras bibliotecas que por sua vez tenham essas vulnerabilidades; portanto, os desenvolvedores que usam bibliotecas como parte de seus apps precisam saber quais bibliotecas estão sendo utilizadas e mantê-las atualizadas ao longo do tempo.

M

Cliente móvel ou app para celular - um app que uma pessoa instala em um smartphone ou tablet a partir de uma loja de apps para celular (por exemplo, iOS App Store ou Google Play Store). É comum que os clientes móveis se comuniquem pela Internet com uma API de REST de uma organização, e eles também podem se comunicar com outras partes (por exemplo, com a Graph API por intermédio do SDK do Facebook para Android).

Autenticação multifatorial (MFA) - uma abordagem de autenticação que requer mais de um fator para conceder acesso a um app ou sistema. A MFA, em contraste com a autenticação de um só fator, que recorre a apenas uma senha para autenticar um usuário, normalmente exige uma senha e um ou mais dos seguintes itens: um código enviado por email/SMS ou recebido de um app autenticador, uma varredura biométrica ou uma chave de segurança. Esse tipo de autenticação protege contra controles de conta tornando mais difícil para indivíduos não autorizados a forçar o acesso a uma conta, por exemplo tentando repetidamente fazer login em uma conta usando um endereço de email conhecido e senhas comuns até conseguir acessar.

N

Software nativo - os apps baixados e instalados em notebooks ou dispositivos móveis são denominados software nativo (por exemplo, o app do Facebook para iOS). Por outro lado, um app executado em um navegador é denominado app da web (por exemplo, ao se abrir o Facebook usando o navegador Chrome).

Comprometimento da rede - o comprometimento da rede é quando um indivíduo mal-intencionado consegue obter acesso não autorizado à rede interna de uma organização por meio de uma configuração incorreta ou de uma vulnerabilidade na própria rede. Uma defesa contra o comprometimento da rede consiste em executar uma varredura da rede para identificar configurações incorretas e vulnerabilidades na parte da rede conectada à Internet. Consulte também comprometimento do app.

Varredura de rede - um processo de gestão de riscos que usa software para: (1) identificar servidores ativos em uma rede que responderão a comunicações remotas e, em seguida, (2) verificar se alguns desses servidores estão executando versões antigas de software que tenham ou mais vulnerabilidades de segurança conhecidas. Uma organização pode usar a varredura de rede periodicamente para se certificar de que não haja portas abertas inesperadas no perímetro da rede dela, por exemplo.

Gerenciador de Pacotes de Nós (NPM) - uma ferramenta usada por desenvolvedores de JavaScript para acelerar o desenvolvimento permitindo a inclusão de pacotes pré-criados em um app ou sistema para desenvolvedores. O NPM inclui recursos para auditar o conjunto de pacotes que estão sendo utilizados por um app e para identificar pacotes que tenham vulnerabilidades de segurança conhecidas.

O

Buckets de armazenamento de objetos - um tipo de armazenamento persistente na nuvem que simplifica para as organizações a tarefa de armazenar arquivos de forma persistente, inclusive arquivos muito grandes, sem a necessidade de preocupação com o dimensionamento de ativos físicos, como as matrizes de armazenamento, nem de como fazer backup desses arquivos para assegurar que eles não se percam em caso de desastre como um incêndio ou um alagamento.

Sistema Operacional - o software executado em um computador ou dispositivo móvel que permite que os apps sejam executados e usem o processador, a memória, o armazenamento e os recursos de rede do computador em questão. Por exemplo: Windows da Microsoft, macOS e iOS da Apple e Linux.

Membro de uma organização - alguém que tenha uma função e responsabilidades no contexto de uma organização, como um funcionário, um empreiteiro, um funcionário temporário, um estagiário ou um voluntário.

Dispositivo organizacional - um computador ou dispositivo móvel usado por um membro para realizar trabalho para uma organização.

P

Termo 6.a.i da Plataforma - seção (6) título (a) parágrafo (i) dos Termos da Plataforma da Meta, onde estão descritas as obrigações dos desenvolvedores da plataforma com relação à segurança dos dados.

Pacote - sinônimo de biblioteca

Patch - atualizações de software que resolvem vulnerabilidades de segurança, corrigem bugs ou adicionam novas funcionalidades. São aplicados patches a todo tipo de software, incluindo Sistemas Operacionais, contêineres, bibliotecas e SDKs.

Teste de penetração - um ataque simulado contra um app ou sistema em que o testador tenta achar vulnerabilidades no código ou na configuração que possam ser exploradas por um indivíduo não autorizado. Os testadores de penetração usam ferramentas semelhantes às dos criminosos cibernéticos para realizar reconhecimentos, procurar possíveis pontos fracos e testar vulnerabilidades que podem ser usadas para se obter acesso não autorizado. Ao concluir um teste desse tipo, o testador cria um relatório que descreve os resultados juntamente com a gravidade de cada um deles, e a organização que mantém o software é responsável por elaborar soluções para resolver as vulnerabilidades.

Texto sem formatação - sinônimo de dados não criptografados, texto sem formatação é o nome atribuído a dados que não foram protegidos por criptografia. Plataforma como Serviço (PaaS) - uma abordagem de computação em nuvem em que o cliente implementa um app em uma plataforma gerenciada pelo provedor dos serviços de nuvem. Em comparação com a IaaS, a PaaS é mais simples para ser gerenciada pelos clientes, já que não somente os ativos físicos (ou seja, os servidores, os dispositivos de armazenamento e os dispositivos de rede) são gerenciados pelo hospedeiro da nuvem, mas também o sistema operacional e o contêiner de app em que o app do cliente é executado. Por exemplo, estes são alguns produtos de PaaS populares: AWS Elastic Beanstalk, Google App Engine, Force.com.

Porta - quando um cliente estabelece uma conexão com um servidor pela Internet, o endereço de destino tem duas partes: (1) um endereço de Internet Protocol (IP) para o servidor e (2) um número de porta no servidor em questão, ao qual um app específico responderá. Os protocolos comuns usam portas reservadas (por exemplo, o HTTPS usa a porta 443), mas um desenvolvedor pode usar outras personalizadas para comunicações por rede, se desejar.

R

API de REST - estilo amplamente adotado de criar serviços acessíveis pela web em que o cliente e o servidor se comunicam usando o protocolo HTTP. Um desenvolvedor na plataforma da Meta pode hospedar uma API de REST em um subdomínio como api.exemplo.com ao/do qual o respectivo app para celular envia e recebe Dados da Plataforma.

S

Secure Shell (SSH) - um esquema de comunicação que permite que os administradores façam login remotamente em servidores e executem programas nesses servidores. É designado como “secure” (seguro) porque as comunicações entre o cliente e o servidor são protegidas contra escutas não autorizadas, diferentemente de protocolos anteriores como o Telnet. Ele também é chamado de Secure Socket Shell.

Secure Sockets Layer (SSL) - uma versão obsoleta e não segura de criptografia em trânsito. A versão moderna segura é denominada Transport Layer Security (TLS).

Servidor - um computador que fornece serviços remotamente por meio de uma rede. Os navegadores e os apps para celular se conectam com os servidores pela Internet.

Computação sem servidores - tipo de computação em nuvem em que o hospedeiro da nuvem gerencia a infraestrutura física, o sistema operacional dos servidores e o contêiner. O desenvolvedor é responsável apenas pelo código personalizado e pelas bibliotecas a este associadas, juntamente com a configuração da nuvem.

Lado do servidor - os dados ou a computação do outro lado de uma conexão de rede (ou seja, em um servidor) são denominados “no servidor”. Por outro lado, os dados ou a computação em um dispositivo local como um notebook ou um dispositivo móvel estão no “lado do cliente”.

Login único (SSO) - um arranjo onde os apps recorrem a um diretório de usuários centralizado (ou seja, um IdP) para autenticar os usuários. Além de centralizar a administração do acesso a contas de usuário e apps para a organização, os usuários se beneficiam ao terem um único conjunto de credenciais, em vez de serem obrigados a manter credenciais diferentes (por exemplo, nome de usuário e senha) para cada app.

Kit de desenvolvimento de software (SDK) - elemento básico de código que um desenvolvedor pode usar para simplificar o processo de desenvolvimento para um determinada necessidade. Por exemplo, a Meta cria e mantém SDKs que simplificam o trabalho com a Graph API para desenvolvedores de iOS e Android. Assim como as bibliotecas, os desenvolvedores que usam SDKs em seus apps precisam mantê-los atualizados.

Software como Serviço (SaaS) - permite que os clientes usem apps baseados na nuvem pela Internet. Diferentemente da PaaS e da IaaS, um cliente de um SaaS não implementa código personalizado nem tem a responsabilidade de configurar, atualizar ou aplicar patches no app do SaaS, pois tudo isso é responsabilidade do fornecedor do serviço. Por exemplo, estes são alguns produtos de SaaS populares: Dropbox, MailChip, Salesforce, Slack.

Análise estática - consulte Teste Estático de Segurança do App

Teste Estático de Segurança do app (SAST) - uma abordagem para encontrar vulnerabilidades em um software por meio da execução de uma ferramenta especializada no código-fonte. Uma ferramenta de SAST identificará possíveis vulnerabilidades, como aquelas listadas no projeto OWASP Top 10, e, em seguida, o desenvolvedor é responsável por analisar os resultados, fazer distinções entre os verdadeiros e falsos positivos e corrigir as vulnerabilidades do software. Um SAST pode ser útil porque pode permitir que os desenvolvedores encontrem vulnerabilidades antes de elas serem implementadas na produção; porém, diferentemente de um teste de penetração, uma ferramenta de SAST não pode encontrar vulnerabilidades relacionadas com a configuração de produção do app.

T

Criptografia de dados transparente - tipo de criptografia em repouso que normalmente se aplica ao armazenamento de bancos de dados (ou seja, o próprio conteúdo do banco de dados e seus arquivos de registro). Nesse arranjo, o software do banco de dados gerencia as chaves de criptografia e trata de forma transparente as operações de criptografia (durante gravações) e as operações de descriptografia (durante leituras).

Transport Layer Security (TLS) - esquema de criptografia em trânsito que usa criptografia para proteger dados transmitidos por redes contra escutas não autorizadas ao longo do caminho da rede. A TLS é uma versão moderna segura da tecnologia anterior obsoleta denominada SSL.

Autenticação de dois fatores (2Fac) - sinônimo de Autenticação multifatorial. Cofre - um sistema de gerenciamento secreto para dados sensíveis como chaves de criptografia, tokens de acesso e outras credenciais. Um cofre permite controlar, de forma rigorosa, quem pode acessar os segredos contidos nele e oferece serviços adicionais como a manutenção de registros de auditoria.

V

Máquina Virtual (VM) - muito parecida com um Contêiner de App, a VM é executada em um host denominado hipervisor, enquanto um Contêiner de App é executado em um mecanismo de contêiner. A diferença principal é que uma imagem de VM contém um Sistema Operacional, e um Contêiner de App, não. Tanto as VMs quanto os Contêineres de App contêm app(s) e dependências, como bibliotecas.

Virtual Private Cloud (VPC) - termo usado pela AWS para se referir a um conjunto de recursos de nuvem que se parece com uma rede tradicional em um data center da era pré-nuvem.

Vulnerabilidade - uma falha em um sistema ou app que pode ser explorada, por exemplo, para ler dados que normalmente o indivíduo em questão não teria o direito de ler.

Programa de Divulgação de Vulnerabilidades (VDP) - a abordagem pela qual as organizações solicitam relatórios de vulnerabilidade de segurança a pesquisadores (às vezes chamados de hackers éticos) para que as vulnerabilidades possam ser descobertas e corrigidas antes de serem exploradas por indivíduos mal-intencionados. Um VDP eficaz requer um conjunto de pesquisadores que procurem ativamente vulnerabilidades, analistas dentro da organização para analisar e triar as divulgações de chegada e engenheiros com conhecimentos de segurança cibernética capazes de criar e implementar correções para as vulnerabilidades.

Busca de vulnerabilidades - uma abordagem que usa software para procurar vulnerabilidades em servidores, redes e apps. Em comparação com um teste de penetração, uma busca de vulnerabilidades custa menos, portanto, pode ser executada repetidamente (por exemplo, mensalmente ou trimestralmente). Porém, é comum que um teste de penetração encontre vulnerabilidades que a busca não encontra, porque os testadores de penetração qualificados têm instintos e habilidades analíticas difíceis de replicar com abordagens estritamente automatizadas. Consulte também varredura de rede.

W

App da web - os apps da web são programas executados dentro de navegadores, e incluem recursos como documentos em HTML, código JavaScript, vídeos e outras mídias, e CSS para o estilo. Diferentemente de um app para celular que uma pessoa instala em um celular a partir de uma loja de apps, um app da web pode ser obtido simplesmente a partir de um servidor remoto usando um navegador (como www.facebook.com), sem necessidade de uma etapa de instalação.