Data Security Requirements

These data security requirements are intended to provide helpful information and assist you in completing Meta’s Data Protection Assessment. For any given question, please note there may be more than one way to demonstrate that you meet our requirements. Only a member of Meta’s review team can make a final determination on whether the evidence provided meets the requirements of our Data Protection Assessment. In addition to using this guide, we recommend consulting with your Chief Information Officer, the person with an equivalent role within your organization, or a qualified cybersecurity firm when preparing your responses to Meta’s Data Protection Assessment to ensure your responses are complete and accurate.

Si è verificato un errore

Stiamo riscontrando problemi con la riproduzione di questo video.

Scopri di più

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.

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.

Note there is a glossary included at the end of this document with key terms and definitions.

Q3.1-7 questions - Information security certification

All questions

3.1-7.a, 3.1-7.a.i.A, 3.1-7.a.i.B

Summary

You may have undergone an audit by an accredited third party and received certification(s) regarding your information security practices. Sharing such a certification provides helpful context for our reviews.

We do not require any information security certifications, but if you provide a valid ISO 27001, ISO 27018, or SOC 2 Type 2, they will be taken into account during our reviews.

Changes from prior version

None

Additional guidance

None

External resources

Not familiar with information security certifications? Review these resources.

• AICPA: SOC 2 for Service Organizations: Trust Services Criteria
• ISO: ISO/IEC 27001:2022
• ISO: ISO/IEC 27018:2019

Evidence examples

None

Q3.1-8 Questions - Storage of Platform Data in a Server or Backend Environment

All questions

3.1-8.a, 3.1-8.b, 3.1-8.a.i

Summary

In order to perform our reviews accurately, we need to first understand how Platform Data is processed and stored by your system or application.

This section asks if you store Platform Data in a backend environment, and if so:

• Which specific Platform Data attributes
• What backend hosting approach(es) are used

Changes from prior version

• You will now be asked to indicate what Platform Data attributes you store in your backend environment.
• You will also be asked to indicate what hosting solutions/infrastructure you use to process Platform Data in your backend environment.

Additional guidance

None

External resources

Not familiar with security in server or backend environments? Review these resources.

• CSA: Cloud Security Alliance
• AWS: Security best practices for Amazon S3
• Azure: Azure security baseline for Storage
• GCP: Google Cloud security best practices
• Heroku: Heroku Security
• Alibaba Cloud: Cloud Security on Alibaba Cloud
• Tencent Cloud: TencentDB for MySQL Security White Papers
• Oracle Infrastructure:
  • Oracle Infrastructure and Platform Cloud Services Security
  • Oracle Cloud Infrastructure Security Guide
• Digital Ocean: Digital Ocean Data Security
• Cisco: What Is Data Center Security

Evidence examples

Developers are not required to provide evidence in response to this question.

Q3.1-9 Questions - Protecting Platform Data at Rest in a Server or Backend Environment

All questions

3.1-9.a, 3.1-9.b, 3.1-9.b.i, 3.1-9.b.ii, 3.1-9.c.i, 3.1-9.c.ii

Summary

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 in cloud or server environments where Platform Data tends to be concentrated.

You must encrypt all Platform Data stored within your backend environments. You may be asked to provide policy/procedure documentation and screenshot proof to demonstrate you have implemented this control.

This section asks if Platform Data stored in your backend environment is protected with encryption at rest or another acceptable approach to reduce the risk of data loss.

Changes from prior version

• If you only store Meta User IDs or hashed User IDs in your backend environment, you are not required to answer these questions.
• If you do not protect Platform Data in your backend environment with encryption at rest, you will be asked if your hosting provider has an ISO 27001 or SOC 2 certificate that meets certain criteria.

Additional guidance

Q3.1-9.a, Q3.1-9.b Requirements

You must encrypt all Platform Data stored within your backend environments. You may be asked to provide policy/procedure documentation and screenshot proof to demonstrate you have implemented this control.

Q3.1-9.c Requirements

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.

• Confirm that your responsible hosting provider has demonstrated to an independent auditor that sufficient physical security and secure media handling controls are in place (i.e., ISO 27001:2013: Control A.11 for Physical and Environmental Security and Control A.8.3 for secure media handling, SOC 2 Type 2: Control CC6.4 for physical security and CC6.5 for secure media handling).
• Provide the date that your hosting provider’s ISO 27001 or SOC 2 certificate issued. The certificate is invalid if the SOC 2 Type 2 issuance date is older than 1 year or if the ISO 27001 is older than 3 years compared to the date of your DPA dispatch.

External resources

Not familiar with encryption at rest in a server or backend environment? Review these resources.

• NIST - Protection of Data at Rest
• CIS - Encrypt Data at Rest - Essential Guide to Election Security
• OWASP - Cryptographic Storage - OWASP Cheat Sheet Series
• AWS - Encrypting File Data with Amazon Elastic File System
• GCP - Default encryption at rest | Documentation | Google Cloud
• Azure - Azure Data Encryption-at-Rest - Azure Security | Microsoft Learn

Evidence examples

Q3.1-9 evidence examples

Q3.1-10 Questions - Protecting Platform Data at Rest on Organizational and Personal Devices

All questions

3.1-10, 3.1-10.a, 3.1-10.a.i, 3.1-10.a.ii, 3.1-10.a.iii, 3.1-10.a.iv, 3.1-10.b, 3.1-10.c, 3.1-10.c.i, 3.1-10.c.ii, 3.1-10.d

Summary

If your organization allows Platform Data on devices like employee laptops or removable storage (e.g., USB drives), that data is at high risk of unauthorized access if the device is lost or stolen. We require developers to take steps to limit this risk to Platform Data.

If you don’t allow storage of Platform Data on devices, but it is still accessible to members of your organization, we require developers to take steps to limit unauthorized use/storage.

This question asks if you have technical or administrative controls to limit the risk of loss of confidentiality of Platform Data stored on organizational and personal devices.

Changes from prior version

Changed questionnaire to ask specifically whether technical or administrative controls are in place specific to protection of storage of Platform Data on organizational devices and removable media.

Additional guidance

Q3.1-10.a Requirements

This requirement applies to all developers that have at least one member that could process Platform Data on an organizational or personal device such as a work or personal laptop computer.

If you store Platform Data on organizational devices or removable media:

You must have EITHER technical controls OR administrative controls relevant to Platform Data stored on organizational devices (e.g., laptops) and removable media.

Acceptable Technical Controls:

Acceptable Administrative Controls:

Q3.1-10.b, Q3.1-10.c Requirements

If you do not store platform data on organizational devices but it is still accessible to members of your organization, we require that you forbid storage of platform data on all organizational devices and removable media:

Q3.1-10.d Requirements

If you store Platform Data neither in a backend environment nor on organizational devices and removable media, please provide a data flow diagram to demonstrate how you are processing Platform Data. Your diagram should:

1. Show how your app makes calls to Meta APIs, such as graph.Meta.com and identify all components that use Platform Data, including those that store, cache, process, or transfer Platform Data across networks
2. Describe the primary use cases (i.e., flows that provide valuable outcomes to users of your app) that you support

External resources

Not familiar with encryption at rest on organizational and personal devices? Review these resources.

• CIS: EI-ISAC Encrypt Data at Rest
• OWASP: OWASP Cheat Sheet Series
• Apple IOS: FileVault on MAC OS
• Linux: Linux Disk Encryption
• MS O365: Set up encryption in Microsoft 365 Enterprise

Evidence examples

Q3.1-10 evidence examples

Q3.1-11 Questions - Protecting Platform Data in Transit

All questions

3.1-11.a, 3.1-11.b, 3.1-11.c, 3.1-11.a.i, 3.1-11.a.ii

Summary

Platform Data transmitted across the internet is accessible to anyone that can observe the network traffic. Therefore it must be protected with encryption to prevent those unauthorized parties from being able to read the data.

• Encryption in transit protects Platform Data when it is transmitted across untrusted networks (e.g., the internet) by making it indecipherable except for the origin and the destination devices
• In other words, parties in the middle of the transmission would not be able to read Platform Data even if they can see the network traffic (this is also called a man-in-the-middle attack)
• TLS is the most prevalent form of encryption in transit because it’s the technology that browsers use to secure communications to websites like banks

This section asks if you always protect Platform Data with encryption in transit when sending it over the Internet.

Changes from prior version

None

Additional guidance

This requirement applies to all developers who transmit Platform Data over the internet for any reason other than requests directly to Meta:

• Platform Data must never be transmitted across untrusted or third party networks in unencrypted format including transmission of platform data to your cloud environment outside of a Virtual Private Cloud (VPC)
• For all web listeners (e.g., internet-facing load balancers) that receive or return Platform Data, you must:

  • Enable TLS 1.2 or above
  • Disable SSL v2 and SSL v3
  • TLS 1.0 and TLS 1.1 may only be used for compatibility with client devices that are not capable of TLS 1.2 or greater
• Meta recommends, but does not require, that encryption in transit be applied to transmissions of Platform Data that are entirely within private networks, e.g., within a Virtual Private Cloud (VPC)

Q3.1-11.a Requirements

The table below summarizes encryption in transit policy for different transmission types:

External resources

Not familiar with encryption in transit? Review these resources.

• NCSC (UK): UK National Cyber Security Centre - data in transit
• AWS Well Architected: SEC09-BP02 Enforce encryption in transit
• LinkedIn Collaborative Articles: What are the best practices for testing and auditing your data encryption in transit and at rest?

Evidence examples

Q3.1-11 evidence examples

Q3.1-12 Questions - Application and Cloud Security Testing

All questions

3.1-12.a , 3.1-12.a.i, 3.1-12.a.ii, 3.1-12.b, 3.1-12.b.i, 3.1-12.b.ii, 3.1-12.c, 3.1-12.c.i, 3.1-12.c.ii

Summary

You must test for vulnerabilities and security issues so that they can be discovered proactively, ideally preventing security incidents before they happen

• Developers write software and operate apps and systems to process Platform Data
• These apps and systems may contain security vulnerabilities that malicious actors can exploit, putting Platform Data at risk
• You must take steps to find and resolve these kinds of vulnerabilities

This section asks about steps you take to test your software and cloud configuration for vulnerabilities and security issues.

Changes from prior version

• Added a question about the specific tool or process you use to test your software or backend environment for vulnerabilities.
• Added a question about your approach for testing your cloud environment for security misconfigurations, if applicable.

Additional guidance

Q3.1-12.a, Q3.1-12.b Requirements

This requirement is applicable to all developers.

Vulnerability Disclosure Program (VDP)

If you are operating a functioning Vulnerability Disclosure Program (VDP), e.g., using the BugCrowd, HackerOne platforms, or another platform meeting industry standards, you may present this as an alternative protection instead of a pen test or vulnerability scan. To demonstrate this, you must submit the following evidence:

Q3.1-12.c Requirements

If you store Platform Data in a backend environment hosted by a cloud provider, you must test your cloud configuration for security issues. This requirement applies irrespective of the hosting approach (e.g., BaaS, PaaS, IaaS, self hosted, or hybrid), except if you are using a no-code backend.

External resources

Not familiar with application and cloud security testing? Review these resources.

• NIST: Open source and commercial SAST tools
• NIST: NISTIR 8397 Guidelines on Minimum Standards for Developer Verification of Software
• OWASP: OWASP Code Review Guide v2
• GitHub: AKS DevSecOps Workshop
• BugCrowd:10 Essentials to Look for in a Crowdsourced Security Platform
• AWS Security Hub: SEC 11. Incorporate and validate the security properties of applications throughout the SSDLC
• NCC Group: Best Practices of the use of SAST within a Real-World SDLC
• CIS Benchmarks: Foundational Cloud Security with CIS Benchmarks
• Scout Suite: GitHub - nccgroup/ScoutSuite: Multi-Cloud Security Auditing Tool

Evidence examples

Q3.1-12 evidence examples

Q3.1-13: Protect the App Secret and Meta Access Tokens

All questions

3.1-13.a, 3.1-13.b, 3.1-13.c, 3.1-13.c.i, 3.1-13.c.ii, 3.1-13.d, 3.1-13.d.i, 3.1-13.d.ii

Summary

App secrets and access tokens are fundamental to the security of how Meta APIs make decisions about what actions to allow. If an unauthorized party gains access to these credentials they could call Meta APIs - impersonating the real developer - and take any of the actions that we have granted the app (e.g., reading data from Meta APIs about an app’s users).

• You have access to sensitive credentials as a part of the use of Meta’s Platform. Specifically:

  • Access Token - When people authorize the app, the software gets a credential called an access token that’s used in subsequent API calls
  • App Secret - Meta shares an app secret with developers with the expectation that only trusted parties (e.g., app admins) within the organization have access to this secret
• An unauthorized party who is able to read these sensitive credentials can use them to call Meta APIs as if they are you (this is sometimes called token impersonation) leading to unauthorized access to Platform Data
• Therefore these credentials must be protected from unauthorized access to prevent impersonation

This section asks questions about how you protect these attributes on the client and server side, as applicable.

Changes from prior version

Refactored to ask about protecting app secret and access tokens on client and backend environments separately.

Additional guidance

Q3.1-13.c Requirements

This question pertains to protecting Meta User Access Tokens stored in your backend environment.

Q3.1-13.d Requirements

This question pertains to storage of Meta App Secrets.

Acceptable Alternative Protections

1. If you do not protect access tokens stored server side with a data vault or via app-level encryption, you may:
1. Protect the app secret by using a vault or application encryption where the key is only accessible to the app
2. AND configure the app to require app secret proof for all API calls to Meta
2. If approach #1 above is not viable (i.e., cannot require appsecret proof because it would block certain necessary API calls), then Meta will consider any other controls that you have in place to limit the risk of unauthorized use of the access tokens compared to the the risk of misuse of stored access tokens

External resources

• OWASP Secrets Management Cheat Sheet
• NIST Digital Identity Guidelines
• AWS Secrets Manager Service Provider Documentation
• GCP Secret Manager Service Provider Documentation

Evidence examples

Q3.1-13 evidence examples

Q3.1-15 Questions - Protecting Accounts from Unauthorized Access

All questions

3.1-15.a, 3.1-15.b, 3.1-15.c, 3.1-15.d, 3.1-15.e, 3.1-15.e.i, 3.1-15.e.ii

Summary

A common technique used by adversaries to gain access to confidential data is to start by gaining access to tools that a developer uses to build or operate their app/system. Sophisticated tools exist to hack into accounts that are protected only by password and present the risk of account takeover attacks. The intent of these questions is to ensure developers have implemented multi-factor authentication to mitigate these risks.

This section asks about how you protect accounts against unauthorized access using multi factor authentication or another approach.

Changes from prior version

Refactored to ask about protecting against unauthorized access using multi-factor authentication or another approach for each of these separately:

• Collaboration and communication tools
• Code repository
• Backend software deployment tools
• Backend administrative console
• Remote access to backend servers

Additional guidance

Q3.1-15.e Requirements

Related to an organization’s processing of Platform Data, remote access to all tools listed above (if applicable) must be protected with multi factor authentication (i.e., not simply a password):

Acceptable Alternative Protections

Meta recommends that developers protect against account takeover by requiring MFA. However, when MFA is not used, developers must take other steps to protect against unauthorized access in line with industry best practices for password complexity rules (see The Center for Internet Security (CIS) Password Policy Guide here: https://www.cisecurity.org/insights/white-papers/cis-password-policy-guide).

External resources

Not familiar with protecting accounts from unauthorized access? Review these resources.

• NIST: NIST SP 800-218
• OWASP: Enforce Access Controls

Evidence examples

Q3.1-15 evidence examples

Q3.1-16 Questions - Access Controls

All questions

3.1-16, 3.1-16.a, 3.1-16.a.i, 3.1-16.a.ii

Summary

Accounts are the basic unit of management for granting people access to systems, data, and administrative functions. Having good account management hygiene is an important part of preventing unauthorized use of accounts to gain access to Platform Data. The intent of this question is to ensure developers are following the principle of least privilege and have a systematic way for managing accounts, granting permissions or privileges, and revoking access when it’s no longer needed.

This section asks about the systems and processes you use to manage access to your systems / tools.

Changes from prior version

Refactored to ask a question about the specific processes you have in place for reviewing and revoking access under different circumstances.

Additional guidance

You must have a tool or process for managing accounts for each of the these tools/systems/apps:

• Those used to communicate with one another, e.g., Slack or business email
• Those used to ship software, e.g. code repository and
• Administer and operate the system (as applicable to processing Platform Data)

You must regularly review (i.e., not less than once every 12 months) access grants and have a process for revoking access when: (1) it’s no longer required, (2) no longer being used, and (3) when a person departs the organization

Meta does not require:

• That any particular tool be used – a developer may use a directory product like Google Cloud identity or Microsoft Azure Active Directory, a cloud product like AWS Identity and Access Management (IAM), or use a spreadsheet that is kept up to date regularly.
• That there be a single consolidated tool for managing accounts across these various access types.

Q3.1-16.a Requirements

External resources

Not familiar with access controls? Review these resources.

• NIST: NIST SP 800-218
• OWASP: Enforce Access Controls

Evidence examples

Q3.1-16 evidence examples

Q3.1-17 Questions - Keep Software Up to Date

All questions

3.1-17.a, 3.1-17.a.i, 3.1-17.a.ii, 3.1-17.b, 3.1-17.b.i, 3.1-17.b.ii, 3.1-17.c, 3.1-17.c.i, 3.1-17.c.ii

Summary

Software components are routinely updated or patched to resolve security vulnerabilities, and eventually these components will reach their end of life when they are no longer supported. Developers who package or rely on these components must keep up to date to avoid running software with known vulnerabilities. Therefore, developers using Meta’s platform must have a systematic way to identify, prioritize, and apply patches for all relevant parts of their tech stack.

This section asks about the systems and processes you use to keep software up to date.

Changes from prior version

Refactored to ask about your approach for keeping different types of software up to date, in separate questions:

• Third-party software in your backend environment
• Third-party code in your mobile app
• Other third-party software used by people in your organization to build and operate your app

Additional guidance

For the following software components, as applicable, you must have a defined and repeatable way of identifying available patches that resolve security vulnerabilities, prioritizing based on risk, and applying patches as an ongoing activity:

1. Libraries, SDKs, packages, app containers, and operating systems used in a cloud or server environment
2. Libraries, SDKs, packages used on client devices, e.g., within mobile apps
3. Operating systems and applications used by members to build and operate the app/system, e.g., operating systems and browsers running on employee laptops

Meta does not require the use of any particular tool for these activities. It’s common that an organization would use different approaches for keeping different types of software up to date (e.g., libraries that are packaged with the app vs operating system updates for employee laptops).

This requirement applies irrespective of the hosting approach (e.g., BaaS, PaaS, IaaS, self hosted, or hybrid), although the set of components that you are responsible for keeping up to date will vary Start by identifying the in-scope types of software in the environment, e.g., Libraries, SDKs, Packages, Virtual Machine images, app containers, and operating systems, Browsers, operating systems, and other applications used by the employees / contributors.

You may have one or more tools that you use for the following activities:

• Inventory - document via a screenshot or document that a tool or process that, ultimately, represents a list of in-scope libraries, packages, SDKs, containers, app servers and operating systems that need to be patched. There needs to be inventories for a representative of the software types (e.g., cloud app(s), client app(s), employee devices).
• Identifying available software patches - a tool or process must exist for identifying security patches that exist that are relevant to the inventory.
• Prioritizing - there needs to be a tool or process (e.g., Jira tickets, GitHub issues, tracking spreadsheet) by which relevant patches are assigned a priority
  • Patching
  • Document via a screenshot or document that demonstrates that, after relevant patches have been identified and prioritized, that they are then rolled out into the various destinations.
• Include policies around time to resolve and use of End of Life (EOL) software.

Q3.1-17.a Requirements related to third-party software in your backend environment, if applicable:

Q3.1-17.b Requirements related to third-party code in your mobile app, if applicable:

Q3.1-17.c Requirements related to other third-party software used by people in your organization to build and operate your app, if applicable:

External resources

Not familiar with keeping software up to date? Review these resources.

• OWASP - OWASP Vulnerable Dependency Management Cheat Sheet
• OWASP OWASP Checking for Weaknesses in Third Party Libraries
• CSF Tools - 7: Continuous Vulnerability Management - CSF Tools
• AWS - AWS SEC 11 incorporate and validate the security properties of applications throughout the design, development, and deployment lifecycle

Evidence examples

Q3.1-17 evidence examples

Q3.1-22 Questions - Administrator and Application Logging in Backend Environment

All questions

3.1-22, 3.1-22.a, 3.1-22.a.i, 3.1-22.b, 3.1-22.b.i, 3.1-22.b.ii, 3.1-22.b.iii, 3.1-22.c, 3.1-22.d, 3.1-22.e, 3.1-22.e.i, 3.1-22.e.ii, 3.1-22.e.iii, 3.1-22.f, 3.1-22.f.i, 3.1-22.f.ii, 3.1-22.g, 3.1-22.g.i

Summary

Without reliable log files it can be difficult to impossible for a developer to detect unauthorized access to Platform Data. Audit logs allow an organization to record the fact that an event occurred, e.g. that a particular user executed a query against database tables containing Platform Data. These logs can then support processes like triggering automated alerts based on suspicious activity or forensic analysis after a security incident has been identified. The intent of this question is to determine if developers have implemented controls around admin and application event logging to flag and escalate potential security incidents.

Changes from prior version

• This section is new as of questionnaire v3.

Additional guidance

Q3.1-22.a Requirements

Q3.1-22.b Requirements

Q3.1-22.e.i Requirements

Q3.1-22.f.i Requirements

Q3.1-22.g Requirements

External resources

Not familiar with audit logs? Review these resources:

• Data Dog - Audit Logging Overview *CIS - Center for Internet Security (CIS): Audit Log Management Policy Template
• Worldbank: Practitioner's Guide: Tamper-proof logs
• CSF Tools - NIST Controls: Audit and Accountability
• AICPA - SOC 2 AICPA Trust Criteria, specifically CC7.2 and CC7.3
• OWASP - OWASP Logging Cheat Sheet

The following resources are not available free-of-charge, but offer valuable information and guidance:

• ISO 27001:2013
• Annex A.12.4 - Logging and Monitoring

Evidence examples

Q3.1-22 evidence examples

Q3.1-23 Questions - Security Processes for People that have access to Platform Data

All questions

3.1-23

Summary

Ensuring personnel are properly trained in the safe handling and protection of confidential data, including Platform Data, along with recognizing signs of potential compromise will reduce the likelihood a security incident.

Changes from prior version

• This section is new as of questionnaire v3.

Additional guidance

None

External resources

Not familiar with personnel security? Review these resources:

• CSF Tools - CSF Tools: Personnel Security
• Information Security Program - Personnel Security Policy Best Practices
• IFSec Global - How a personnel security policy can combat the insider threat

Evidence examples

Developers are not required to provide evidence in response to this question.

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

Admin Audit Logs - records of actions taken by users with elevated privileges in data systems. Properly configured, admin audit logs record the actions that a system administrator takes within the system, for example executing programs or scripts, creating or disabling accounts, resetting passwords or changing multifactor authentication configurations and the editing, moving or deleting of log files within a system.

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 event logs - are structured records of events and activities generated by software applications. They capture a wide range of information, including error messages, user interactions, system events, and application-specific data.

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 environment - In system architecture, frontend refers to the part of the system that runs on user devices (e.g., a mobile app on an Android or iPhone or a web app on the user’s laptop), whereas backend refers to the part of the system that runs remote from end users on computers that are controlled by the developer or a hosting provider. Backend environments have network, compute, and storage resources and are hosted in a cloud or other type of server environment like a data center.

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.

Dynamic Application Security Testing (DAST) - is a program used by developers to analyze a web application (web app), while in runtime, and identify any security vulnerabilities or weaknesses. Using DAST, a tester examines an application while it's working and attempts to attack it as a hacker would.

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

Package - synonym for content 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.

Platform Data - see the definition in Meta’s Platform Terms.

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.

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

Security information and event management (SIEM) - technology supports threat detection, compliance and security incident management through the collection and analysis (both near real time and historical) of security events, as well as a wide variety of other event and contextual data sources.

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: Dropbox, 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.

System Administrator Audit Logs - See Admin Audit Logs.

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.