en/security/best-practices/ops.html - platform/docs/source.android.com - Git at Google

 <html devsite>
   <head>
     <title>Organizational and Operational Security</title>
     <meta name="project_path" value="/_project.yaml" />
     <meta name="book_path" value="/_book.yaml" />
   </head>
   <body>
   <!--
       Copyright 2017 The Android Open Source Project

       Licensed under the Apache License, Version 2.0 (the "License");
       you may not use this file except in compliance with the License.
       You may obtain a copy of the License at

           http://www.apache.org/licenses/LICENSE-2.0

       Unless required by applicable law or agreed to in writing, software
       distributed under the License is distributed on an "AS IS" BASIS,
       WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
       See the License for the specific language governing permissions and
       limitations under the License.
   -->
   <p>The foundation of good security practices start in your organization.</p>


 <h3 id="create-a-team">Create a security and privacy team</h3>

 <p>Create a dedicated security and privacy team and establish a leader for this
 organization.</p>

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

 <h3 id="build-verification">Build verification process</h3>

 <p>Evaluate gaps in your existing internal build verification and approval
 processes.</p>

 <ul>
   <li>Identify any gaps in your current build verification process that could
     lead to the introduction of a
     <a href="/security/reports/Google_Android_Security_PHA_classifications.pdf">Potentially
       Harmful Application</a> (PHA) into your build.</li>
   <li>Ensure you have a code review and approval process, even for in-house
     patches to <a href="https://android.googlesource.com/"
     class="external">AOSP</a>.</li>
   <li>Improve build integrity by implementing controls in these areas:
     <ul>
       <li><strong>Track changes</strong>. Track software engineers; keep
         change logs.</li>
       <li><strong>Assess risk</strong>. Assess permissions used by an app;
         require manual review of code changes.</li>
       <li><strong>Monitor</strong>. Evaluate changes made to privileged code.</li>
     </ul>
   </li>
 </ul>

 <h3 id="source-code-change-tracking">Source code change tracking</h3>

 <p>Monitor for unintentional modifications of source code or third-party
 apps&hairsp;/&hairsp;binaries&hairsp;/&hairsp;SDKs.</p>

 <ul>
   <li><strong>Assess partnerships</strong>. Assess the risk of working with a
     technical partner using the following steps:

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

 <h3 id="validate-source-code">Validate source code integrity and pedigree</h3>

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

 <ul>
   <li><strong>Manage signing certificates</strong>.
     <ul>
       <li>Store keys in a hardware security module (HSM) or secure cloud service
         (don't share them).</li>
       <li>Ensure access to signing certificates is controlled and audited.</li>
       <li>Require all code signing be done in your build system.</li>
       <li>Revoke lost keys.</li>
       <li>Generate keys using best practices.</li>
     </ul>
   </li>
   <li><strong>Analyze new code</strong>. 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.</li>
   <li><strong>Review before publishing</strong>. Look for security
     vulnerabilities in source code and third-party apps before you push them
     into production. For example:
     <ul>
       <li>Require apps to use secure communication.</li>
       <li>Follow the principle of least privilege and grant the minimum set of
         permissions needed for the app to operate.</li>
       <li>Ensure data is stored and transferred over secure channels.</li>
       <li>Keep service dependencies up-to-date.</li>
       <li>Apply security patches to SDKs and open source libraries.</li>
     </ul>
   </li>
 </ul>

 <h2 id="incident-response">Incident response</h2>

 <p>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.</p>

 <ul>
   <li><strong>Establish contact</strong>. Create an email address, such as
     security@<var>your-company</var>.com or a website with clear instructions
     for reporting potential security issues associated with your product
     (<a href="https://security.samsungmobile.com/securityReporting.smsb"
       class="external">example</a>).</li>
   <li><strong>Contribute changes upstream</strong>. 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 <a
     href="g.co/AndroidSecurityReport" class="external">security bug report</a>.
   </li>
   <li><strong>Promote good security practices</strong>. 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.</li>
 </ul>
   </body>
 </html>
	<html devsite>
	<head>
	<title>Organizational and Operational Security</title>
	<meta name="project_path" value="/_project.yaml" />
	<meta name="book_path" value="/_book.yaml" />
	</head>
	<body>
	<!--
	Copyright 2017 The Android Open Source Project

	Licensed under the Apache License, Version 2.0 (the "License");
	you may not use this file except in compliance with the License.
	You may obtain a copy of the License at

	http://www.apache.org/licenses/LICENSE-2.0

	Unless required by applicable law or agreed to in writing, software
	distributed under the License is distributed on an "AS IS" BASIS,
	WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
	See the License for the specific language governing permissions and
	limitations under the License.
	-->
	<p>The foundation of good security practices start in your organization.</p>


	<h3 id="create-a-team">Create a security and privacy team</h3>

	<p>Create a dedicated security and privacy team and establish a leader for this
	organization.</p>

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

	<h3 id="build-verification">Build verification process</h3>

	<p>Evaluate gaps in your existing internal build verification and approval
	processes.</p>

	<ul>
	<li>Identify any gaps in your current build verification process that could
	lead to the introduction of a
	<a href="/security/reports/Google_Android_Security_PHA_classifications.pdf">Potentially
	Harmful Application</a> (PHA) into your build.</li>
	<li>Ensure you have a code review and approval process, even for in-house
	patches to <a href="https://android.googlesource.com/"
	class="external">AOSP</a>.</li>
	<li>Improve build integrity by implementing controls in these areas:
	<ul>
	<li><strong>Track changes</strong>. Track software engineers; keep
	change logs.</li>
	<li><strong>Assess risk</strong>. Assess permissions used by an app;
	require manual review of code changes.</li>
	<li><strong>Monitor</strong>. Evaluate changes made to privileged code.</li>
	</ul>
	</li>
	</ul>

	<h3 id="source-code-change-tracking">Source code change tracking</h3>

	<p>Monitor for unintentional modifications of source code or third-party
	apps&hairsp;/&hairsp;binaries&hairsp;/&hairsp;SDKs.</p>

	<ul>
	<li><strong>Assess partnerships</strong>. Assess the risk of working with a
	technical partner using the following steps:

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

	<h3 id="validate-source-code">Validate source code integrity and pedigree</h3>

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

	<ul>
	<li><strong>Manage signing certificates</strong>.
	<ul>
	<li>Store keys in a hardware security module (HSM) or secure cloud service
	(don't share them).</li>
	<li>Ensure access to signing certificates is controlled and audited.</li>
	<li>Require all code signing be done in your build system.</li>
	<li>Revoke lost keys.</li>
	<li>Generate keys using best practices.</li>
	</ul>
	</li>
	<li><strong>Analyze new code</strong>. 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.</li>
	<li><strong>Review before publishing</strong>. Look for security
	vulnerabilities in source code and third-party apps before you push them
	into production. For example:
	<ul>
	<li>Require apps to use secure communication.</li>
	<li>Follow the principle of least privilege and grant the minimum set of
	permissions needed for the app to operate.</li>
	<li>Ensure data is stored and transferred over secure channels.</li>
	<li>Keep service dependencies up-to-date.</li>
	<li>Apply security patches to SDKs and open source libraries.</li>
	</ul>
	</li>
	</ul>

	<h2 id="incident-response">Incident response</h2>

	<p>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.</p>

	<ul>
	<li><strong>Establish contact</strong>. Create an email address, such as
	security@<var>your-company</var>.com or a website with clear instructions
	for reporting potential security issues associated with your product
	(<a href="https://security.samsungmobile.com/securityReporting.smsb"
	class="external">example</a>).</li>
	<li><strong>Contribute changes upstream</strong>. 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 <a
	href="g.co/AndroidSecurityReport" class="external">security bug report</a>.
	</li>
	<li><strong>Promote good security practices</strong>. 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.</li>
	</ul>
	</body>
	</html>