Organizational and operational security

The foundation of good security practices start in your organization.

Create a security and privacy team

Create a dedicated security and privacy team and establish a leader for this organization.

• Build a security team.
  • Ensure at least one employee is responsible for security, privacy, and incident response.
  • Define a mission and scope for this team.
  • Develop an org chart and job descriptions for: Security Manager, Security Engineer, Incident Manager.
  • Hire employees or external contractors to fill these roles.
• Define a security development lifecycle (SDL). Your SDL should cover these areas:
  • Security requirements for products.
  • Risk analysis and threat modeling.
  • Static and dynamic analysis of apps and code.
  • Final security review processes for products.
  • Incident response.
• Assess organizational risk. Create a risk assessment and develop plans to eliminate or mitigate those risks.

Build verification process

Evaluate gaps in your existing internal build verification and approval processes.

• Identify any gaps in your current build verification process that could lead to the introduction of a Potentially Harmful Application (PHA) into your build.
• Ensure you have a code review and approval process, even for in-house patches to AOSP.
• Improve build integrity by implementing controls in these areas:
  • Track changes. Track software engineers; keep change logs.
  • Assess risk. Assess permissions used by an app; require manual review of code changes.
  • Monitor. Evaluate changes made to privileged code.

Source code change tracking

Monitor for unintentional modifications of source code or third-party apps / binaries / SDKs.

• Assess partnerships. Assess the risk of working with a technical partner using the following steps:
  • Establish criteria for how to assess the risk of working with a specific supplier.
  • Create a form that asks the supplier how they resolve incidents and manage security and privacy.
  • Verify their claims with a periodic audit.
• Track changes. Record which companies and employees modify source code and conduct periodic audits to ensure only appropriate changes take place.
• Keep records. Record which companies add third-party binaries to your build and document what function those apps perform and what data they collect.
• Plan updates. Ensure that your suppliers are required to provide software updates for the full life of your product. Unforeseen vulnerabilities might require support from vendors to address.

Validate source code integrity and pedigree

Inspect and validate source code supplied by an original device manufacturer (ODM), Over-the-air update (OTA), or carrier.

• Manage signing certificates.
  • Store keys in a hardware security module (HSM) or secure cloud service (don't share them).
  • Ensure access to signing certificates is controlled and audited.
  • Require all code signing be done in your build system.
  • Revoke lost keys.
  • Generate keys using best practices.
• Analyze new code. Test newly added code with security code analysis tools to check for the introduction of new vulnerabilities. In addition, analyze overall functionality to detect expression of new vulnerabilities.
• Review before publishing. Look for security vulnerabilities in source code and third-party apps before you push them into production. For example:
  • Require apps to use secure communication.
  • Follow the principle of least privilege and grant the minimum set of permissions needed for the app to operate.
  • Ensure data is stored and transferred over secure channels.
  • Keep service dependencies up-to-date.
  • Apply security patches to SDKs and open source libraries.

Incident response

Android believes in the power of a strong security community to help find issues. You should create and publicize a way for external parties to contact you about device-specific security issues.

• Establish contact. Create an email address, such as security@your-company.com or a website with clear instructions for reporting potential security issues associated with your product (example).
• Establish a Vulnerabiity Rewards Program (VRP). Encourage external security researchers to submit security vulnerability reports impacting your products by offering monetary rewards for valid submissions (example). We recommend rewarding researchers with industry competitive rewards, such as $5,000 for Critical severity vulnerabilities and $2,500 for High severity vulnerabilities.
• Contribute changes upstream. If you become aware of a security issue affecting the Android platform or devices from multiple device manufacturers, contact the Android Security Team by filing a security bug report.
• Promote good security practices. Proactively assess the security practices of hardware and software vendors who provide services, components, and/or code for your devices. Hold vendors accountable for maintaining a good security posture.