A tradução para Português (Brasil) não foi concluída ainda.
Atualização em Português (Brasil):
Data Security Requirements
The following data security requirements correspond to the 2023 Data Protection Assessment.
For assessment versions received after February 2024, please see this page.
Apps with access to certain types of Platform Data from Meta are required to complete the annual Data Protection Assessment (DPA). DPA is designed to determine whether developers meet the requirements of Meta Platform Terms as it relates to the use, sharing, and protection of Platform Data. A subset of the DPA questionnaire is focused on Platform Term 6, which outlines data security requirements. We recommend you utilize this document to understand the expectations, requirements, and related evidence with respect to data security use and processing as defined in Meta Platform Terms.
Please note there is a glossary included at the end of this document with key terms and definitions.
Find more video resources from Data Protocol.
Throughout this document, the phrase server side is used as a shorthand for any backend environment that an organization uses to process Platform Data, whether running on a cloud host like Amazon Web Services (AWS), hosted by the developer in a shared or exclusive data center, or a hybrid (combination of these).
Client side requirements refer to processing Platform Data within browsers, mobile devices, within apps on desktop and laptop computers, and other types of devices used by people.
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.
- Lado do cliente - Inclua todos os softwares do cliente, como navegadores, dispositivos móveis e quaisquer outros tipos de dispositivos compatíveis.
- Lado do servidor - Inclua quaisquer ambientes relacionados ao servidor ou à nuvem e identifique o seguinte:
- Os componentes onde os Dados da Plataforma:
- Entram ou saem do(s) ambiente(s) do servidor (por exemplo, web listeners e REST APIs).
- São gravados em armazenamento persistente ou durável, como banco de dados, discos ou arquivos de registro.
- O modelo de hospedagem, por exemplo:
- Auto-hospedado - os próprios servidores de uma organização que funcionam em um data center próprio ou compartilhado.
- Infraestrutura como serviço (IaaS) - Como a AWS EC2, o Microsoft Azure IaaS e o Google Compute Engine.
- Plataforma como serviço (PaaS) - como o AWS Elastic Beanstalk, o Google App Engine e o Force.com.
- Backend como Serviço (BaaS) - como o AWS Amplify, o Azure Mobile Apps, o Firebase e o MongoDB Switch.
- Híbrido - uma combinação dos modelos acima.
No final, o diagrama ou a descrição do fluxo de dados deve incluir:
- 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).
- 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.
- Como você usa, armazena e transmite esses dados.
- 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.
Edite (remova) dados sensíveis das provas antes de enviá-las.
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:
- 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].
- 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:
- A prova de política ou de procedimento deve atender ou exceder, claramente, os requisitos da Meta
- 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.
- Você deve anotar o documento para destacar as seções relevantes.
- 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:
- Os dados da plataforma da Meta nunca devem ser transmitidos por redes não confiáveis em formato não criptografado.
- 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.
- 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
- A prova de implementação deve mostrar um ou mais exemplos de implementação de cada política ou procedimento
- Você deve carregar um ou mais documentos, capturas de tela ou configurações de ferramentas que demonstrem como você implementou cada proteção.
- A Meta analisará as provas de implementação para verificar se estão alinhadas com as provas de política ou de procedimento.
- 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
Protecting Platform Data Stored Server Side with Encryption at Rest
Question: Do you enforce encryption at rest for all Platform Data stored in a cloud, server, or data center environment?
Intent
Encryption at rest protects Platform Data by making the data indecipherable without a separate decryption key. This provides an additional layer of protection against unauthorized read access.
- On servers or in a cloud environment - where Platform Data related to all of an app’s users tends to be concentrated - encryption at rest reduces the risk of a data breach
- For example, encryption at rest protects against threats like an unauthorized access to a database backup, which may not be protected as tightly as the production database itself
Summary of Requirements
If you do store Platform Data server side:
- You MUST protect that data:
- With encryption at rest, or
- With acceptable alternative protections (see Acceptable Alterative Protections)
- Specific to the type of encryption used:
- Either application-level (e.g., software encrypts/decrypts specific columns in a database) or full-disk encryption are acceptable
- Although we recommend that industry-standard encryption (e.g., AES, BitLocker, Blowfish, TDES, RSA) be used, we do not require any particular algorithm or key length
If developer does NOT store Platform Data server side, this requirement is not applicable.
Special Cases
Server Side Storage using IaaS, Self Hosting, or Hybrid Hosting
If you store Platform Data using IaaS hosting (e.g., AWS EC2, Microsoft Azure IaaS, and Google Compute Engine), self hosting, or a hybrid approach then this question does apply.
Server Side Storage using SaaS, PaaS, or BaaS Products
However, there are other backend hosting models that are special cases:
If you store Platform Data only via any of these (and not using IaaS, Self Hosting, or Hybrid Hosting), this question does not apply. You should instead describe this relationship in the Service Provider section of the DPA.
- BaaS - e.g., AWS Amplify, Azure Mobile Apps, Azure Playfab, Google Firebase, and MongoDB Switch
- PaaS - e.g., AWS Elastic Beanstalk, Google App Engine, Force.com
- SaaS - e.g., MailChimp or Salesforce
Server Side Storage using Meta APIs
If you store Platform Data only via a Meta API, for example using player.setDataAsync(), in the Instant Games SDK, this question does not apply.
Evidence Guide
If you are asked to submit evidence for this protection, follow the instructions in Preparing Evidence to prepare both policy/procedure and implementation evidence.
Example Implementation Evidence
AWS RDS
AWS RDS - encryption at rest is configurable in AWS RDS, so developers must make sure that the configuration option is set to apply this protection.
For a representative RDS instance that contains Platform Data, use the AWS CLI tool to fetch its StorageEncrypted configuration.
# 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
]AWS DynamoDB
AWS DynamoDB is encrypted at rest by default. You can fetch the encryption at rest configuration for a table using these commands.
$ aws dynamodb list-tables --output table -------------- | ListTables | +------------+ ||TableNames|| |+----------+| || Users || |+----------+| $ aws dynamodb describe-table \ --table-name Users \ --query "Table.SSEDescription.Status" "ENABLED"
AWS DocumentDB
AWS DocumentDB must be configured to apply encryption at rest. For a representative cluster that contains Platform Data, use these commands to fetch the StorageEncrypted configuration.
$ aws docdb describe-db-clusters --query 'DBClusters[*].DBClusterIdentifier'
[
"docdb-users"
]
$ aws docdb describe-db-clusters \
--db-cluster-identifier 'docdb-users' \
--query 'DBClusters[*].StorageEncrypted'
[
true
]AWS S3
AWS S3 buckets may be configured to apply encryption at rest to all objects created within the bucket. Use these commands to list buckets and fetch the configuration for default bucket encryption.
$ 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
Consult Microsoft’s documentation on encryption at rest in Azure that’s relevant to the organization’s use of their services.
Google Cloud Platform
Consult Google’s documentation on encryption at rest on Google Cloud Platform.
Acceptable Alternative Protections
If you do not implement encryption at rest in the server side environment, you may be protecting Platform Data in an alternative way that is still acceptable. In this case, you should describe the following:
- Sensitivity of the Platform Data - Storage of specific Platform Data is considered lower or higher risk. You will need to research which specific platform data user attributes are being stored server side.
- Controls Applied to Reduce Likelihood of Specific Harms
- Controls to prevent compromise of networks containing Platform Data
- Controls to prevent compromise of apps/systems having access to Platform Data
- Controls to prevent loss of physical storage media (e.g., decommissioned network storage devices) containing Platform Data
- Controls to prevent unauthorized access to backup copies of storage containing Platform Data backups
- Strength of Evidence - be sure to note if these protections have been evaluated by an independent auditor, for example as part of a SOC2 audit.
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.
Esse requisito é aplicável independentemente de você tratar ou não Dados da Plataforma no servidor.
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.
| Tipo de transmissão | Política de criptografia em trânsito |
|---|---|
De e para dispositivos do usuário final (celulares, PCs, tablets etc.) e a infraestrutura de servidor ou de nuvem. |
|
De e para a infraestrutura de servidor ou de nuvem e qualquer servidor remoto, infraestrutura de nuvem ou serviço quarteirizado. | O TLS 1.2 ou versões posteriores devem ser aplicados |
De e para componentes inteiramente dentro da infraestrutura de servidor, de nuvem ou centro de dados privado | A criptografia TLS é recomendada, mas não obrigatória para transferências de Dados da Plataforma que estejam inteiramente dentro de uma rede privada em nuvem |
De e para a Meta e qualquer dispositivo, servidor ou infraestrutura de nuvem | Fora do escopo de Avaliação da Proteção dos Dados: a Meta controla a política de TLS para essas transferências |
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).
Se a organização está cogitando adicionar o teste de segurança de apps estáticos (SAST, pelas siglas em inglês) ao processo de desenvolvimento, o National Institute of Standards and Technology (Instituto Nacional de Padrões e Tecnologia) mantém uma lista de ferramentas de código aberto e comerciais que pode ser útil como ponto de partida para escolher uma ferramenta.
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.
O software de nuvem ou de servidor acessível pela internet (como uma REST API usada por clientes web e móveis) que você usa para tratar Dados da Plataforma deve estar dentro do escopo desse teste para que ele seja aceitável.
- 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.
O arquivo JSON bruto da NCC Scout Suit contém detalhes sobre seu ambiente de nuvem que você não deve carregar. Em vez disso, filtre as respostas para exibir a contagem de achados por gravidade.
$ 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?
- 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.
- 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
- 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.
- No servidor: se você trata ou armazena tokens de acesso da Meta no servidor, eles:
- 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
- não devem ser gravados em arquivos de registro.
Chave secreta do app: uma destas duas alternativas deve ser verdadeira:
- 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.
- 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).
Não inclua os valores de texto sem formatação de chaves ou de tokens de acesso nas provas enviadas.
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
- Caso não proteja os tokens de acesso armazenados no servidor com um cofre de dados ou criptografia do app, você pode:
- Proteger a chave secreta do aplicativo usando criptografia de cofre ou aplicativo, em que a chave somente é acessível ao aplicativo.
- E configurar o aplicativo para exigir provas da chave secreta em todas as chamadas a APIs da Meta.
- 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.
Esse requisito é aplicável independentemente de você tratar ou não Dados da Plataforma no servidor.
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.
Apenas as duas primeiras páginas estão incluídas aqui, mas você deve enviar o documento inteiro.
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.
Esse requisito é aplicável independentemente de você tratar ou não Dados da Plataforma no servidor.
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:
- Bibliotecas, SDKs, pacotes, contêineres de apps e sistemas operacionais usados em um ambiente de nuvem ou de servidor
- Bibliotecas, SDKs, pacotes usados em dispositivos clientes, como em apps para celular
- 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.
Esse requisito é aplicável independentemente do tipo de hospedagem (como BaaS, PaaS, IaaS, auto-hospedagem ou híbrida), embora o conjunto de componentes que você é responsável por manter atualizado varie.
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).
Glossary
A
3rd party - in risk management terminology, 3rd party refers to developers on Meta’s platform (1st party is Meta itself; 2nd party is people that use Meta’s products)
4th party - in risk management terminology, 4th party refers to the firms that developers rely on to provide them services that enable their business (1st party is Meta, 2nd party is Meta’s users, and 3rd party is developers on Meta’s platform)
Access token - a credential, like a password, that allows software to call an API to take some action (e.g., read data from a user’s profile).
Amazon Web Services (AWS) - Amazon’s suite of cloud computing services
App scoped ID (ASID) - a unique identifier that Meta generates when a person chooses to use an app. ASIDs help improve privacy for users by making it more difficult for data sets to correlate users across apps, since a single user using two apps will have different ASIDs in each app.
App secret - a shared secret that Meta makes available to developers via the app dashboard. Possession of the app secret authorizes software to take some actions via the Graph API, so developers need to take care that unauthorized parties are not able to get access to the app secret.
App compromise - if a malicious actor is able to gain unauthorized access to an organization’s internal network via a misconfiguration or vulnerability in their app (e.g., a software vulnerability in a webapp) it’s called app compromise. A defense against app compromise is to pen test the app. See also network compromise.
Application container - a container packages up software code and related dependencies so that the app will run on different types of servers (e.g., servers running different operating systems like Linux or Windows Server). A developer will create a container image that packages their app. An application container engine or runtime hosts (runs) the container image.
Application encryption - a method of protecting data where the application software itself does the encryption and decryption operations. In contrast, Transport Layer Security (TLS) seamlessly encrypts data in transit when an application establishes a secure connection to a remote server (e.g., using HTTPS) and cloud providers offer services to transparently encrypt data at rest.
Application Programming Interface (API) - allows two computers to talk to each other over a network, for example a mobile app fetching today’s weather for a certain location from a centralized weather forecasting system
Appsecret proof - an additional layer of security for API calls to Meta whereby a developer generates a parameter (the appsecret proof) that demonstrates that they possess the app secret. The appsecret proof is the product of a hashing function (also called a one-way function) based on the app secret and access token. Configuring an app to require appsecret proofs during Graph API invocations reduces the potential harm from a breach of user access tokens, since those access tokens cannot be used without the additional appsecret proof parameter.
B
Backend as a Service (BaaS) - a style of cloud computing that provides a suite of server-side capabilities for an app developer so that the developer can focus on building the frontend (i.e., the part of an app that users interact with). BaaS solutions are similar to PaaS and, in addition, add services like user authentication and mobile push notifications. For example, these are some popular BaaS products: AWS Amplify, Azure Mobile Apps, Firebase, and MongoDB Switch.
C
Cipher text - a synonym for encrypted data, cipher text is the name given to data that has been made unreadable via some encryption algorithm. The opposite of cipher text is plain text.
Client side - people typically interact with internet-accessible services by opening a website in a browser or by running a mobile app on a phone or tablet. The browser or mobile apps are referred to as local clients or client side. Clients make requests from remote computers (servers) via the internet.
Cloud computing - refers to a style of managing server computers, networks, and storage so that an organization doesn’t need to worry about the physical environment (i.e., a data center full of server racks and network cables). Instead, the organization can provision these assets on demand and pay for the services that they consume.
Cloud configuration - the set of cloud computing options that an organization has set in relation to their use of a cloud provider running some software. Examples of cloud configuration include what sorts of network connections are allowed or blocked, where log files are written and how long they are kept, and the set of users who are authorized to make changes to the cloud configuration.
Compensating controls - a security control that differs from some baseline set of requirements but is intended to deliver comparable protection against a risk.
D
Database - software that allows arbitrary data to be stored, read, updated, and deleted. Databases can run on clients and on servers. Organizations that integrate with the Meta platform will commonly store data they fetch from the Graph API in a database that runs server side.
Decryption - process by which encrypted data is transformed back into its original format. In other words, decryption changes cipher text into plain text.
E
Encryption - process by which data is transformed into a format that is unusable to anyone that cannot decrypt it. In other words, encryption changes plain text into cipher text.
Encryption at rest - data that has been protected with encryption when written to persistent storage (e.g., a disk drive). Encryption at rest provides an additional layer of protection against unauthorized access since an actor that’s able to read the raw files on the storage device will see cipher text and will not be able to decrypt it unless they are also able to gain access to the decryption key.
Encryption in transit - data that has been protected with encryption when transmitted across a network. Encryption in transmit provides protection against eavesdropping along the network path since an actor that’s able to read the network packets will see cipher text and will not be able to decrypt it unless they are also able to gain access to the decryption key.
End of Life (EOL) software - when an organization chooses to stop support (e.g., create patches to resolve security vulnerabilities) for a software product that software is considered EOL. Since this software is no longer maintained, it’s very risky to run any EOL software.
G
Google Cloud Platform (GCP) - Google’s suite of cloud computing services
Graph API - the primary way for apps to read and write to the Meta social graph. All Meta SDKs and products interact with the Graph API in some way.
H
Hashing function - a cryptographic function that takes any data as input and outputs a short code that cannot be reversed into the original input. In cryptography, hashing functions are used to protect data like passwords – instead of storing a user’s password in plaintext that could be stolen, passwords are first transformed with a hash function and then stored. Later, to confirm that a user has input the correct password, the system will use the same hash function to transform the input and compare the resulting hash against the stored value. Also called a one-way function since the output hash cannot be reversed into the original input.
Hosted environment - refers to a set of remote servers, networks, and storage devices that an organization is running in their own data center or within a data center co-located (or colo) with other customers. This arrangement is relatively uncommon in the modern era since cloud computing has become more popular.
I
Identity Provider (IdP) - a cloud service used to centralize management of digital identities and authenticate users. Organizations that use an IdP typically configure cloud apps to rely on the IdP for user authentication. The organization can then manage users by creating, granting access to selected apps, and disabling user accounts centrally within the IdP instead of having to do this repeatedly in each cloud app.
Identity and Access Management (IAM) - refers to the category of tools and processes that are used to manage accounts and grant access to systems.
Infrastructure as a Service (IaaS) - a cloud computing approach that lets customers configure computing, storage, and networking services without having responsibility for the physical assets themselves (e.g., managing a data center full of servers, network devices, and storage arrays). Compared to Paas, IaaS gives an organization more control over the configuration of their cloud assets but at the cost of more complexity to manage those assets. For example, these are some popular IaaS products: AWS EC2, Microsoft Azure IaaS, and Google Compute Engine.
L
Library - pre-existing software building blocks, typically from an external company or developer, that’s used to handle certain tasks within another developer’s app or system. Libraries simplify development of an app since a developer doesn’t have to reinvent the wheel when a library already exists for a given function. However, libraries can contain security vulnerabilities – or can themselves include additional libraries that do – so developers who use libraries as part of their app need to know what libraries are in use and keep them up to date over time.
M
Mobile client or mobile app - an app that a person installs onto a phone or table from a mobile app store (e.g., iOS App Store or Google Play Store). It’s common for mobile clients to communicate over the internet with an organization’s REST API and may also communicate with other parties (e.g., to the Graph API via the Facebook SDK for Android).
Multi-Factor Authentication (MFA) - an authentication approach that requires more than one factor to gain access to an app or system. MFA, in contrast to single factor authentication that relies on just a password to authenticate a user, will typically require a password plus one or more of these: a code sent via email or SMS, a code from an authenticator app, a biometric scan, or a security key. MFA protects against account takeovers by making it more difficult for unauthorized actors to force their way into an account, e.g., by repeatedly attempting to login to an account by using a known email address and common passwords until successful.
N
Native software - apps that are downloaded and installed onto laptops or mobile devices are referred to as native software (e.g., the Facebook app for iOS). In contrast, an app that runs within a browser is referred to as a webapp (e.g., opening Facebook using the Chrome browser).
Network compromise - if a malicious actor is able to gain unauthorized access to an organization’s internal network via a misconfiguration or vulnerability in the network itself it’s called a network compromise. A defense against network compromise is to run a network scan to identify misconfigurations and vulnerabilities in the internet-facing network. See also application compromise.
Network scan - a risk management process that uses software to: (1) identify active servers on a network that will respond to remote communications, and then (2) see if any of those servers are running old versions of software that is known to be vulnerable to one or more security exploits. An organization may use network scanning periodically to make sure that there are no unexpected open ports on their network perimeter, for example.
Node Package Manager (NPM) - a tool used by JavaScript developers to speed up development by allowing pre-built packages to be included in a developer’s app or system. NPM includes features to audit the set of packages that are in use by an app and to identify packages that have known security vulnerabilities.
O
Object storage buckets - a type of persistent storage in the cloud that makes it simple for organizations to store files into persistent storage, including files that are very large, without having to worry about scaling physical assets like storage arrays or how to back these files up to ensure they aren’t lost in the case of a disaster like a fire or flood.
Operating System - the software running on a computer or mobile device that allows applications to run and use that computer’s processor, memory, storage, and network resources. For example, Microsoft’s Windows, Apple’s macOS or iOS, and Linux.
Organization member - someone with a role and responsibilities within an organization, for example an employee, a contractor, a contingent worker, an intern, or a volunteer.
Organizational device - a computer or mobile device used by an organization member in the context of doing work for the organization.
P
Platform Term 6.a.i - Refers to Meta’s Platform Terms section (6) heading (a) paragraph (i), which describes platform developers’ obligations related to data security.
Package - synonym for library
Patch - software updates that resolve security vulnerabilities, fix bugs, or add new functionality. All sorts of software gets patched, including Operating Systems, containers, libraries, and SDKs.
Penetration test - a simulated attack against an app or system where the tester attempts to find vulnerabilities in the code or configuration that could be exploited by an unauthorized actor. Pen testers will use similar tools to cyber criminals to conduct reconnaissance, scan for potential weaknesses, and test vulnerabilities that could be used to gain unauthorized access. At the conclusion of a pen test, the tester will create a report that describes the findings along with the severity of each and the organization that maintains the software is responsible for crafting fixes to resolve the vulnerabilities.
Plain text - a synonym for unencrypted data, plain text is the name given to data that has not been protected by encryption.
Platform as a Service (PaaS) - a cloud computing approach whereby a customer deploys an application into a platform managed by the cloud provider. Compared to IaaS, PaaS is simpler for customers to manage since not only the physical assets (i.e., the servers, storage devices, and network devices) are managed by the cloud host but also the operating system and application container where the customer’s app runs. For example, these are some popular PaaS products: AWS Elastic Beanstalk, Google App Engine, Force.com.
Port - when a client makes a connection to a server over the internet the destination address has two parts: (1) an Internet Protocol (IP) address for the server and (2) a port number on that server that a particular application will respond to. Common protocols use reserved ports (e.g., HTTPS uses 443) but a developer can use custom ports for network communications if desired.
R
REST API - a widely adopted style of building web-accessible services where the client and server communicate using the HTTP protocol. A developer on the Meta platform might host a REST API on a subdomain like api.example.com that their mobile app sends and receives Platform Data to/from.
S
Secure Shell (SSH) - a communication scheme that allows administrators to remotely login to servers and run programs on those servers. Referred to as secure since the communications between the client and server are protected against eavesdropping unlike earlier protocols like Telnet. Also called Secure Socket Shell.
Secure Sockets Layer (SSL) - An obsolete and insecure version of encryption in transit. The modern secure version is called Transport Layer Security (TLS).
Server - a computer that provides services remotely over a network. Browsers and mobile apps connect to servers over the internet.
Serverless computing - a style of cloud computing where the cloud host manages the physical infrastructure, the server operating system, and the container. A developer is only responsible for custom code and associated libraries along with the cloud configuration.
Server side - data or computation on the other side of a network connection (i.e., on a server) is referred to as server side. In contrast, data or computation on a local device like a laptop or mobile device is referred to as client side.
Single Sign On (SSO) - an arrangement where apps rely on a centralized user directory (i.e., an IdP) to authenticate users. In addition to centralizing user account and app access administration for the organization, users benefit by having a single set of credentials instead of requiring users to maintain different credentials (e.g., username and password) for each different app.
Software Development Kit (SDK) - a building block of code that a developer can use to simplify the development process for a given need. For example, Meta creates and maintains SDKs that simplify working with the Graph API for iOS and Android developers. Similar to a library, developers that use SDKs in their apps need to keep them up to date over time.
Software as a Service (SaaS) - allows customers to use cloud-based apps via the internet. Unlike PaaS or IaaS, a customer of a SaaS app does not deploy custom code nor have responsibility for configuring, upgrading, or patching the SaaS app as all of these are the responsibility of the SaaS software vendor. For example, these are some popular SaaS products: Dopbox, MailChip, Salesforce, Slack.
Static analysis - see Static Application Security Testing
Static Application Security Testing (SAST) - an approach for finding vulnerabilities in software by running a specialized tool against the source code. A SAST tool will identify potential vulnerabilities, such as those listed in the OWASP Top 10 project, and then the developer is responsible for reviewing the findings, distinguishing true positives from false positives, and fixing vulnerabilities in the software. SAST can be useful because it can allow developers to find vulnerabilities before they are deployed into production, but unlike a penetration test a SAST tool will not be able to find vulnerabilities related to the production configuration of the app.
T
Transparent data encryption - a type of encryption at rest that typically applies to database storage (i.e., the database contents themselves and its log files). In this arrangement, the database software manages the encryption keys and transparently handles the encryption operations (upon writes) and decryption operations (upon reads).
Transport Layer Security (TLS) - an encryption in transit scheme that uses encryption to protect data transmitted over networks from eavesdroppers along the network path. TLS is the modern secure version of the obsolete earlier technology called SSL.
Two-Factor Authentication (2Fac) - a synonym for Multi-Factor Authentication.
V
Vault - a secret management system for sensitive data like encryption keys, access tokens, and other credentials. A vault allows tight control over who is able to access the secrets it contains and offers additional services like keeping audit logs.
Virtual Machine (VM) - very similar to an Application Container – a VM runs in a host called a hypervisor whereas an Application Container runs in a container engine. The main difference is that a VM image contains an Operating System whereas an Application Container will not. Both VMs and Application Containers contain application(s) and dependencies like libraries.
Virtual Private Cloud (VPC) - term used by AWS to refer to a set of cloud resources that resembles a traditional network in a data center in the pre-cloud era.
Vulnerability - a flaw in a system or app that could be exploited, e.g., to read data that the actor otherwise would not be entitled to read
Vulnerability Disclosure Program (VDP) - an approach whereby organizations solicit security vulnerability reports from researchers (sometimes called ethical hackers) so that the vulnerabilities can be discovered and fixed before malicious actors exploit them. An effective VDP requires a set of researchers who are actively looking for vulnerabilities, analysts within the organization to review and triage incoming disclosures, and engineers who are knowledgeable about cybersecurity that are able to create and deploy fixes for vulnerabilities.
Vulnerability scan - an approach that uses software to look for vulnerabilities in servers, networks, and apps. Compared to a penetration test, a vulnerability scan is cheaper to run and hence can be run repeatedly (e.g., monthly or quarterly) but it’s typical that a pen test will find vulnerabilities that a vulnerability scan misses because skilled penetration testers bring analytical skills and instincts that are hard to replicate with strictly automated approaches. See also network scan.
W
Webapp - Webapps are programs that run inside browsers and are comprised of resources like HTML documents, JavaScript code, videos and other media, and CSS for styling. In contrast to a mobile app that a person installs onto a mobile phone from an app store, people simply fetch a webapp from a remote server using their browser (e.g., www.facebook.com) without the need for an installation step.