a7d10a4 · cryptotaxi247/documentation

@@ -9,16 +9,8 @@ react appropriately to security threats when they arise.

9 ## Table of Contents

10

11 1. [Reporting Security Problems to npm](#reporting-security-problems-to-npm)

12 -2. [Security Point of Contact](#security-point-of-contact)

13 -3. [Onboarding Developers](#onboarding-developers)

14 -4. [Separation of Duties and Authorization](#separation-of-duties-and-authorization)

15 -5. [Critical Updates And Security Notices](#critical-updates-and-security-notices)

16 -6. [Responding to Security Threats](#responding-to-security-threats-and-critical-updates)

17 -7. [Vulnerability Scanning](#vulnerability-scanning)

18 -8. [Password Policies](#password-policies)

19 -9. [Application Design Best Practices](#application-design-best-practices)

20 -10. [Development Process](#development-process)

21 -11. [AntiVirus Software](#antivirus-software)

12 +1. [Security Point of Contact](#security-point-of-contact)

13 +1. [Critical Updates And Security Notices](#critical-updates-and-security-notices)

14

15 ## Reporting Security Problems to npm

16

@@ -36,16 +28,6 @@ Any security tickets opened using [https://npmjs.com/support](https://npmjs.com/

28 will be escalated to the security point of contact, who will delegate incident response

29 activities as appropriate. This is the best and fastest way to contact npm about any security-related matter.

30

39 -## Onboarding Developers

40 -

41 -All new technical hires are introduced to our security policy as part

42 -of the onboarding process.

43 -

44 -## Separation of Duties and Authorization

45 -

46 -* Developers are only given access to key npm services when it's required for their job.

47 -* IAM is used to limit the permissions on accounts, minimizing the damage that would be incurred if an account is compromised.

48 -

31 ## Critical Updates And Security Notices

32

33 We learn about critical software updates and security threats from a

@@ -56,222 +38,6 @@ variety of sources:

38 * [Security tickets](https://npmjs.com/support) sent to us.

39 * and other media sources.

40

59 -### Ubuntu Automatic Security Updates

60 -

61 -Along with keeping an eye out for critical security updates, automatic

62 -security updates are enabled on all of our production servers allowing

63 -patches to be applied immediately without human intervention.

64 -

65 -<https://help.ubuntu.com/community/AutomaticSecurityUpdates>

66 -

67 -## Responding to Security Threats and Critical Updates

68 -

69 -When a security threat is identified, we have the following process in

70 -place:

71 -

72 -1. We have the slack channel `security-all`, which is used to

73 - prioritize and coordinate responses to security threats.

74 -2. Our [Security Point of Contact](#security-point-of-contact)

75 - oversees this discussion: managing the triage, responding to

76 - emails, and updating npm's status page.

77 -3. Based on the triage, work is allocated to developers to address the

78 - threat:

79 -

80 - * `P0`: Drop everything and fix!

81 - * `P1`: High severity, schedule work within 7 days.

82 - * `P2`: Medium severity, schedule work within 30 days.

83 - * `P3`: Low severity, fix within 180 days.

84 -

85 -## Vulnerability Scanning

86 -

87 -Along with reacting to security notifications as they happen, we

88 -proactively pen-test and audit software.

89 -

90 -### Internal Audits

91 -

92 -We have a dedicated security team who perform ongoing penetration testing, code auditing, and other forms of security oversight.

93 -

94 -While working on features at npm, all engineers coordinate security

95 -audits with the [Security Point of Contact](#security-point-of-contact).

96 -

97 -Documentation of our internal audits is available, and can be provided to customers when requested.

98 -

99 -### Automated Scanning

100 -

101 -The cloud hosting platforms that we use provide options for automated

102 -vulnerability scanning.

103 -

104 -* AWS: <https://aws.amazon.com/security/penetration-testing/>

105 -* Google Cloud: <https://cloud.google.com/security-scanner/>

106 -

107 -## Password Policies

108 -

109 -* Enable 2FA on all npm related accounts.

110 -* Passwords should be rolled every 90 days.

111 -* Passwords should contain alpha-numeric characters and symbols.

112 -* Passwords should be a minimum of 8 characters.

113 -* Any systems we build that accept a username and password should

114 - reject a user after repeated failed login attempts.

115 -

116 -### Don't Use Passwords

117 -

118 -We should opt for alternative authentication methods when possible:

119 -

120 -* Asymmetric keys for connecting to servers.

121 -* Delegated authentication (SAML, OAuth2, etc).

122 -* Opaque access tokens.

123 -

124 -### SSH Keys

125 -

126 -SSH keys should be rolled out selectively, providing developers access

127 -to only the servers that they require access to.

128 -

129 -## Application Design Best Practices

130 -

131 -In the next section of the document, we discuss the design

132 -methodologies that we use to build stable and secure software.

133 -

134 -### Logging Practices

135 -

136 -Logs are important for both debugging applications and detecting

137 -security breaches in our software.

138 -

139 -#### What We Log

140 -

141 -* We should track failed login attempts to servers:

142 - * Ubuntu provides this information in _/var/log/auth.log_

143 -* We should log the operations performed by users:

144 - * Ubuntu provides this information in _history_.

145 -* Applications should provide detailed operational logs in a

146 - [standardized format](https://github.com/ceejbot/common-log-string).

147 -

148 -#### Log format

149 -

150 -All applications should contain logging for `date`, `time`,

151 -`operation`, and a `unique request identifier`.

152 -

153 -We use

154 -[common-log-string](https://github.com/ceejbot/common-log-string)

155 -internally to standardize this:

156 -

157 -#### Backing Up Logs

158 -

159 -At least 90 days of logs should be kept for each service. On high

160 -traffic hosts this may require backing-up logs in cloud storage on a

161 -regular basis.

162 -

163 -#### Reviewing Logs

164 -

165 -On the servers that we manage for other companies, we should audit

166 -logs on a regular basis.

167 -

168 -

169 -#### Secrets in Logs

170 -

171 -Logs should not contain any sensitive user information, e.g.,

172 -passwords.

173 -

174 -The module [hide-secrets](https://www.npmjs.com/package/hide-secrets)

175 -is used to help with this.

176 -

177 -### Limiting Access to Operating System Files

178 -

179 -Micro-services should only have access to databases and files that

180 -they need access to.

181 -

182 -With our docker-based infrastructure (npm Enterprise) this is achieved by

183 -having containers only mount folders on the root host that they

184 -require access to.

185 -

186 -In our production environment, this is achieved by partitioning

187 -services across multiple hosts.

188 -

189 -### Security Groups

190 -

191 -Security groups are used to limit the network connectivity between hosts.

192 -

193 -When deploying a service, ask: "what other services does this

194 -actually need to connect to?"

195 -

196 -### Storage of Data

197 -

198 -Any sensitive user information should be encrypted at rest. Using

199 -[encrypted EBS

200 -drives](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html),

201 -or an equivalent, is a great way to achieve this.

202 -

203 -### Inter-Service Communication

204 -

205 -Communication between services on the same host can be performed via

206 -HTTP.

207 -

208 -All inter-service communication between two hosts is performed using

209 -TLS.

210 -

211 -## Development Process

212 -

213 -npm has a well-defined, security-focused, development process:

214 -

215 -### Code Reviews

216 -

217 -No code goes into production unless it is reviewed by at least one

218 -other developer.

219 -

220 -The onus is on the reviewer to ask hard questions: "what are the

221 -ramifications of opening up port-X?", "why is this connection being

222 -made over HTTP instead of HTTPS?"

223 -

224 -### Deploying Updates

225 -

226 -* Any new code pushed to production is first thoroughly tested in a

227 - staging environment.

228 -* Mechanisms are in place for rolling back any changes that are pushed

229 - to production.

230 - * If a schema-change is involved, an inverse migration is first

231 - tested in staging (we want to be confident that we should role

232 - things back).

233 -

234 -### Unit Testing

235 -

236 -We love testing at npm:

237 -

238 -* During the code-review process, if you see logic that's complicated

239 - and lacks a test, politely ask the developer for a test.

240 -* It's particularly important that tests are added to logic that

241 - interacts with sensitive parts of the system: ACL logic, password

242 - validation, database access.

243 -* Tests should not contain user-data, make sure to anonymize email

244 - addresses, usernames, etc.

245 -* Test coverage is a great way to make sure all of the nooks and

246 - crannies of your codebase are tested. npm maintains two tools for

247 - test coverage internally [tap](https://github.com/isaacs/node-tap),

248 - and [nyc](https://github.com/bcoe/nyc).

249 -* Any new functionality should always come with a test to verify that

250 - it does what we think it does.

251 -* Any bug fix should always come with a test so that we don't have to

252 - encounter the same bug multiple times.

253 -

254 -### Design Cycle

255 -

256 -The design process, and management techniques vary from team to team

257 -at npm. Across the board, however, we strive to have continuous

258 -deployments. Releasing many small features as they become production

259 -ready.

260 -

261 -Security is taken into account during all phases of the software

262 -development life-cycle: unit tests think about potential threats; when

263 -testing on staging, we attempt to test potential exploits, etc.

264 -

265 -## AntiVirus Software

266 -

267 -On our managed Ubuntu hosts, we run the

268 -[ClamAV](https://help.ubuntu.com/community/ClamAV) AntiVirus software.

269 -

270 -### When A Virus Is Identified

271 -

272 -The infected server should be retired, and a new server should be

273 -provisioned from scratch.

274 -

41 ## Changes

42

43 This is a living document and may be updated from time to time.

chore: update security policy