Data Security

Step 2: Secure the Data

A critical component of data security is minimizing harm to your users if their data is compromised. By encrypting data, both in transit AND at rest, you make that data unreadable in the event that an unauthorized user accesses it. This step is not only essential to a security-first mindset that builds trust among your users, but is an industry standard as required under the DDUP.

Use this resource to determine whether or not your organization encrypts data at rest and in transit according to the DDUP's requirements.

Note: Data that is not written to storage does not need encryption at rest.

• Use standard encryption like AES-256
  • Don't roll your own or rely on data encoding or obfuscation
  • Don't encrypt data at rest using obsolete encryption algorithms
• Enable any platform-level controls where available
• Verify the data is encrypted

If you think you're encrypting data at rest, validate these things:

• Use trusted certificate authorities (CAs)
• Ensure certificates are configured properly
• Use the most updated versions of Transport Layer Security (TLS) possible
• Enforce encryption for all network connections
• Test to verify network connections are not accidentally sending data in the clear
• Verify that metadata in HTTP headers doesn't include personal information

While encryption goes a long way to protect user data, you should still be diligent about what data you store, and how. Because credentials and access tokens are used to authenticate user access to services like APIs, it can be extremely harmful if they are compromised. For example, gaining access to a user's credentials and/or access token could enable a bad actor to impersonate that user and use any enabled access settings to cause harm within your systems. Meta strongly recommends that you have processes in place to adequately secure and manage credentials and access tokens.

Consider these best practices to protect sensitive credentials and tokens:

• Use tools such as GitHub's secret scanning features to make sure that no credentials or access tokens have been checked into your code repository
• Store credentials and access tokens so only administrators can access them If possible…
• Use a token vault in a cloud or server environment
• Use system credential storage on mobile devices

If possible...

• Use a token vault in a cloud or server environment
• Use system credential storage on mobile devices

This section doesn't represent everything you can - or should - do to secure data itself, but it's a good starting point. Adopting a security-first mindset means you will continue to consider how you can protect the data you store and transmit. Once you have a plan for securing user data… it's time to think about who within your organization should be able to access it.

Step 3: Define and Manage Access to Data

When you are granted access to user data, it's your responsibility to be a good steward of that data. That not only means keeping that data out of the hands of bad actors external to your organization, but limiting access to internal users as well.

Start by evaluating how your organization currently manages accounts and access management. When it comes to the system accounts, which of the following security measures does your organization enforce?

1. Separate roles and functions with different accounts and credentials
3. Allow only administrators to create necessary accounts
5. Configure existing accounts according to the “least privilege” principle
7. Log access to user data
9. Monitor transfers of user data and key points where user data can leave the system (e.g., third parties, public endpoints)
11. Immediately disable accounts that are or will no longer be in use (i.e., user accounts for users who are no longer with the company)
13. Audit regularly to identify and address gaps within the system

Manage Keys and Passwords

With accounts created, and access limited, the next step is to make sure that only the authorized users can access those accounts. Some suggestions to protect access to user accounts include:

1. Never storing passwords in plain text or embedding them in code
3. Never using vendor-supplied defaults for system passwords
5. Using key management systems when possible
7. Having a system for maintaining keys (assigning, revoking, rotating, deleting)

One potential technique to support authorized access management is multi-factor authentication or MFA. MFA requires account holders to provide two or more forms of authentication before they can access data, systems, or whatever else they are permissioned for.

Consider implementing MFA and requiring all new and existing users to keep their login information updated.

Step 4: Secure and Maintain Your Systems

System Maintenance

Once you have a plan to keep any non-essential personnel out of the systems storing user data, consider how you are protecting the systems themselves. Start with system updates. Running critical updates helps you find - and mitigate - security vulnerabilities, so it is an essential step to keeping bad actors from exploiting those vulnerabilities.

These attacks on your systems could be destructive. When scanning for vulnerabilities, check the following:

1. Software on the servers and within your applications are updated regularly

   Tip: Enable automatic updates whenever possible

3. All devices within the organization are updated regularly

   Tip: Share regular communications about updates. For any updates that cannot be automated, include implementation instructions

5. Relevant assets, such as servers, software, applications, dependencies, and devices

• Have they been scanned and audited to ensure current relevancy?
• Are they properly functioning for your application?
• Have policies related to system updates been created, revised, and implemented to remain up-to-date?
• Are there other technological devices or software systems being used to automate and enforce these policies?

Your production systems handle all of your requests… but they are also accessible by bad actors. In addition to finding and mitigating vulnerabilities in your systems, it's important to keep up with regular system maintenance. When doing your routine systems maintenance check, be sure to consider the following:

1. Identify what services are required on your systems
3. Disable or remove all unnecessary services from your systems
5. Have procedures for keeping these systems updated with security patches and upgrades
7. Audit your systems regularly for deviations from your original plan

Configuration Management

As you do regular system maintenance, you want to ensure that configuration management is also being implemented throughout your system. Some of the best ways to ensure this is happening is to check for the following within your system:

1. For applications that rely on a database, use standard hardening configuration templates
3. Define processes and approved channels for asset acquisition, including intake request and purchase approval
5. Implement a system development lifecycle to manage systems
7. Maintain an asset inventory that implements lifecycle tracking
9. Utilize end-of-life asset management procedures for the sanitization and destruction of all decommissioned production and non-volatile memory media including certification of sanitization/destruction
11. Implement a mobile device management solution that allows controlled access to networks
12. 1. Does it have the ability to remotely wipe lost or stolen mobile devices?
13. Periodically assess for unauthorized, unlicensed, and unsupported hardware/software
15. Establish standard configurations for network devices
17. Utilize secure configuration baselines for assets, and maintain baselines for servers, mobile devices, and network devices
19. Store baseline configurations in a central repository, and define the services available and how those services should be configured
21. Regularly check systems for compliance with secure configuration baseline
23. Manage security configurations through configuration management and change control processes
25. Use centrally managed anti-malware software

When managing systems it is important to be able to refer back to access logs as they help answer the questions, “who did what and when did it happen?” By logging and monitoring activities happening in the system, you are able to mitigate risks, catch them in their preliminary phase, and take action.

Check out our best practices below:

• Minimize the number of locations where Meta or Device User Data is held
• Use network segmentation to isolate the Meta or Device User Data and prevent unauthorized access
• Log all access and data egress to the protected segment
  • NOTE: Audit logs should be tamper-proof
• Log changes to access levels for analysis and investigative purposes
• Monitor assets that store or transmit User Data and/or Device User Data for unauthorized personnel, connections, devices, and software
• Design logging and monitoring systems to generate logs of event types that enable security-related activities to be detected

Step 5: Monitor & Respond

Vulnerability Management and Security Testing

If you store User Data and/or Device User Data on non-Meta servers, it's critical that you take the necessary steps to secure those servers by identifying and mitigating any vulnerabilities. While Meta will run a vulnerability scan on your app binary at upload, you should enforce vulnerability and security testing to help mitigate risks for any software and hardware that you do, or will, maintain. Start by assessing your organization's current capacity for security testing and vulnerability management.

Answer the following questions to begin evaluating your organization's tools and processes for vulnerability management and security testing.

Which of the following do your static or dynamic tools and/or manual code reviews currently support?

1. Identifying vulnerabilities
3. Triaging vulnerabilities
5. Monitoring vulnerabilities
7. Mitigating vulnerabilities

Have you…

1. used static analysis to examine your source code for coding errors that could ultimately result in security issues?
3. performed an assessment of the systems that store or access User Data and/or Device User Data to determine if they are compliant with security policies, frameworks, and regulatory requirements?
5. implemented vulnerability management and patching programs for systems that store or access User Data and/or Device User Data?
7. performed vulnerability scans or detection on systems that store or access User Data and/or Device User Data to identify vulnerabilities and evaluate the risks?
9. conducted internal or external penetration tests to evaluate systems that store or access User Data and/or Device User Data?
11. coordinated with owners of systems that store or access User Data and/or Device User Data to resolve vulnerabilities according to severity level and defined service levels?

These questions aren't exhaustive, and checking off each of them won't guarantee that your processes are sufficient for protecting data. But, they provide a good starting point for you to evaluate and consider how you can improve your vulnerability management and security testing processes.

Incident Response

Lastly, you need a plan in the event of unauthorized access to User Data and/or Device User Data. Have an incident response plan in place to detect and respond quickly to anything that may compromise the confidentiality, integrity, or availability of User Data and/or Device User Data.

This incident response plan will help strengthen the security and vitality of your application. To evaluate your current incident response plan, check whether you have the following:

1. A formally defined security incident response plan to detect, record, prioritize and respond to security incidents with defined roles and responsibilities in case there is an incident
3. Procedures for escalation and isolation/containment
5. A process to document and incorporate lessons learned into future responses
7. Training to enable employees and contractors to identify and report security incidents
9. A process to regularly test, review, and update your incident response systems or processes

Before You Submit

Remember: You can have security without privacy, but you can't have privacy without security. Protecting user data requires you to adequately secure it. Before you submit your app for review:

1. Partner with an Information Security subject matter expert at your organization to understand Meta's requirements and locate all supporting documentation
2. Determine whether your organization:
   • Follows a specific Information Security Standard, like ISO 27001
   • Has obtained a specific data security certification
   • Or, minimally, has used known information security standards to inform your Information Security Practices
3. Review the following in detail and determine whether your organization is currently compliant:
   • Security requirements outlined in this section of the DDUP
   • Data Security Details section of the DPA developer document
4. Review Meta's Developer Data Security Best Practices for more tips on sound data security.