1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
|
<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 / binaries / 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>
|
