add best practices to Server security doc

Author: rosieyohannan

jekyll/_cci2/security-server.adoc

@@ -78,3 +78,23 @@ Following are the system events that are logged. See `action` in the Field secti
 - **scope:** If the target is owned by an Account in the CircleCI domain model, the account field should be filled in with the Account name and ID. This data is a JSON blob that will always contain `id` and `type` and will likely contain `name`.
 - **success:** A flag to indicate if the action was successful.
 - **request:** If this event was triggered by an external request this data will be populated and may be used to connect events that originate from the same external request. The format is a JSON blob containing `id` (the request ID assigned to this request by CircleCI), `ip_address` (the original IP address in IPV4 dotted notation from which the request was made, eg. 127.0.0.1), and `client_trace_id` (the client trace ID header, if present, from the 'X-Client-Trace-Id' HTTP header of the original request).
+
+== Checklist To Using CircleCI Securely as a Customer
+
+If you are getting started with CircleCI there are some things you can ask your team to consider for security best practices as _users_ of CircleCI:
+
+- Minimise the number of secrets (private keys / environment variables) your
+  build needs and rotate secrets regularly.
+  - It is important to rotate secrets regularly in your organization, especially as team members come and go.
+  - Rotating secrets regularly means your secrets are only active for a certain amount of time, helping to reduce possible risks if keys are compromised.
+  - Ensure the secrets you _do_ use are of limited scope - with only enough permissions for the purposes of your build. Consider carefully adjudicating the role and permission systems of other platforms you use outside of CircleCI; for example, when using something such as IAM permissions on AWS, or Github's https://developer.github.com/v3/guides/managing-deploy-keys/#machine-users[Machine User] feature.
+- Sometimes user misuse of certain tools might accidentally print secrets to stdout which will land in your logs. Please be aware of:
+  - running `env` or `printenv` which will print all your environment variables to stdout.
+  - literally printing secrets in your codebase or in your shell with `echo`.
+  - programs or debugging tools that print secrets on error.
+- Consult your VCS provider's permissions for your organization (if you are in an organizations) and try to follow the https://en.wikipedia.org/wiki/Principle_of_least_privilege[Principle of Least Privilege].
+- Use Restricted Contexts with teams to share environment variables with a select security group. Read through the <<contexts#restricting-a-context,contexts>> document to learn more.
+- Ensure you audit who has access to SSH keys in your organization.
+- Ensure that your team is using Two-Factor Authentication (2FA) with your VCS (https://help.github.com/en/articles/securing-your-account-with-two-factor-authentication-2fa[Github 2FA], https://confluence.atlassian.com/bitbucket/two-step-verification-777023203.html[Bitbucket]). If a user's GitHub or Bitbucket account is compromised a nefarious actor could push code or potentially steal secrets.
+- If your project is open source and public, please make note of whether or not you want to share your environment variables. On CircleCI, you can change a project's settings to control whether your environment variables can pass on to _forked versions of your repo_. This is **not enabled** by default. You can read more about these settings and open source security in our <<oss#security,Open Source Projects document>>.
+