I drafted this back in January and realized I had never posted it anywhere. Apologies in advance for any typos or lack of copyediting, I thought it more important to get it out there and I don't have time to edit it.
Security for Small Teams
Author: Jeffrey Paul firstname.lastname@example.org
Date: 23 January 2017
Security is hard, and the right answers are frequently non-obvious. There’s a lot of religion and dogma floating around, and only some of it is valid or useful. The landscape is shifting. Some best practices from a year ago are now risky, and there’s advice coming at you from every direction, the quality of which is difficult to evaluate.
This document attempts to be an overview of some best practices for small teams as of January, 2017.
This is an opinionated document, based on my own personal experiences as a security engineer for the last twenty years. Your opinions may vary. These are mine. Mine are probably better, unless you are one of the very few people on Earth who has been doing this longer or harder than I have.
General Purpose Best Practices
Don’t share passwords between users. (Sometimes this is unavoidable, but do your best.)
Use a password manager, like 1Password, iCloud Keychain, or LastPass. There are no good ones, only ones that suck less. Some are sketchy, so stick to the well-trod path here.
Do not reuse passwords. Everyone reuses passwords because we’re all lazy. Stop doing it.
Use only non-jailbroken, up-to-date iOS devices for primary communications. Avoid Android, and especially avoid out-of-date carrier Android.
Use 2FA everywhere it is available. The most important accounts for 2FA are your iCloud/Apple ID, your domain registrar, and your hosting providers.
Use the Authy app, not Google Authenticator, for your two-factor codes.
For high-security projects, consider a dedicated phone, Apple ID, and phone number.
Use Chrome, not Safari or Firefox.
chrome://plugins/ and click Disable on every item except the PDF viewer.
Use the minimum number of Chrome Extensions possible, and review the enabled ones periodically.
Use U2F USB tokens for 2FA with Chrome.
uBlock Origin extension for Chrome. Read the docs and learn how to use it effectively in default-deny expert mode.
G Suite and Single Sign On (SSO)
It is important to avoid having to manage too many credentials. G Suite from Google (formerly Google Apps for Business) offers email hosting, file sharing, and, critically, Single Sign On (SSO) which can be used as a central company authentication database for apps.
It’s about $50/year per user, and you’ll need a few extra users: if you are e.g.
email@example.com, then you also need a
firstname.lastname@example.org that can administrate G Suite users. Plan for your day-to-day user account to get compromised. Make sure that someone with access to your daily-driver account cannot destroy your company.
Give accounts only to humans, and only one to each (unless they also get a second admin account). Don’t use a login account for a group mailbox like
email@example.com. That’s what Groups are for. (Also, you’re not to share passwords, remember?)
G Suite 2FA Caveat
2FA stands for “Two Factor Authenticaton”, which helps (but is not a panacea) with attempts to phish your staff’s credentials. It is essential.
Don’t use your phone number for 2FA. Sadly, when you enable 2FA (Google calls this “two step verification”) on a Google account, it demands a phone number, and defaults to SMS (text message) based 2FA. This is bad. As soon as you enable 2FA (having provided your phone number), you still have two more steps: first, switch to app-based 2FA (using the Authy app on your iOS device), and then you must remove your telephone number entirely from the Google account. The reason for this is that even if you have enabled app-based 2FA, SMS-based 2FA is always available as a fallback option. When people steal your cellphone number via your carrier’s shitty security practices, they will use this method (even if you have app-based 2FA turned on) to log in to your account. The phone number must be completely removed.
Set up an
everyone@ email group so that you can easily communicate important security information to all staff. Tell everyone to set up 2FA using these instructions by emailing
everyone@. Mention a completion deadline in the email for one week later. Send another email on the deadline telling everyone that their G Suite account will be suspended in 48 hours if they don’t have 2FA turned on. Set a calendar reminder for yourself (as admin) and make good on the promise (fail closed) 48h later by suspending anyone without 2FA. When they complain to you, walk them through the setup process on the phone when you unsuspend their account. (Setting up 2FA takes about 5-10 minutes, and is not burdensome.)
Do not continue with operations without app-based 2FA enabled for every single human in your organization.
Workstation security is a full-time job for a dozen people. We’re going to somewhat punt on this: Continue using your OS X (pron: oh ess ten) workstation like you always have, but buy a $200 Chromebook to augment it for when you need to perform security-sensitive tasks (like G Suite admin, or logging in to production).
Turn on Full Disk Encryption (FileVault) on your OSX machine if it’s not already on.
Turn off iCloud Drive on your Mac. If you must have it on, be damn sure that it’s not configured to store your documents from
~/Desktop in iCloud Drive.
It’s a good idea to use my (osximage tools) to build a standard OSX OS image for your organization and reimage your Mac a few times per year. This keeps your configuration as code that is documented in a repo (or, some of it anyway), and hopefully saves your coworkers some time each year.
Remember, every single rubygem you install, every shitty node package you haven’t read the source code from, every random-ass python package you
pip install—all of these can read every file in your home directory and silently upload them to eastern European teenagers ready and willing to use your AWS keys to mine altcoins. Don’t keep sensitive data (like secret keys or production API tokens) sitting unencrypted on your OSX machine’s filesystem. Leverage the OSX Keychain if you know how. Use Vagrant or Docker to isolate your development environments and avoid installing or executing any development code on your actual OSX workstation. (virtualenv and bundler don’t count, as those have full access to your filesystem.)
Workstation Security Checklist
Use a Chromebook for sensitive tasks, like anything that could potentially handle PII or encryption keys.
Reinstall your Mac periodically, automating as many of the “I have just fresh installed” tasks as possible. The list is still sadly sort of long (e.g. Little Snitch must be manually installed).
osximage repository) to automate the process.
Use Little Snitch. Avoid making blanket rules for tcp/443 for “forever” for things like curl/ruby. This is how your secrets get exfiltrated!
Use Little Flocker.
Avoid installing software. Use web apps instead of local apps when possible (e.g. appear.in instead of Skype, Google Docs instead of Word or Pages, et c.)
Consider a dedicated machine for the security tire fire that is the Adobe suite. (I’m serious.) Same goes for that weird old java app you have to run to configure your wireless Access Points or webcam or whatever. Don’t do it on your main machine.
Install homebrew under your home directory, and avoid modifying the root filesystem outside of your home directory. (
osximage handles this for you.)
Decide who’s going to play sysadmin and add and remove user accounts. Now decide who does it when they get hacked or go on vacation, and make sure they have an admin account and Chromebook too. The primary person should have a recurring calendar reminder for not less than every 90 days to go into the G Suite user admin list and ensure that every single account has 2FA enabled.
This same person should check several times a year to ensure that the 2FA requirement setting is enabled on the GitHub organization, as well.
G Suite Email
Use Slack’s Google login integration to ensure everyone accessing your Slack is logging in with their Google account and not via a direct Slack account. If you have a public/semipublic Slack where external people can join, make a second, internal-only private one that only allows logins from your G Suite domain. Coupled along with periodic review of the G Suite user list by an admin, this should mean nobody can access Slack without 2FA (via their Google account).
Set your Slack private message retention time to 7 days. This way, if someone screws up and shares a password or credential, if someone compromises their account after 7 days later, it won’t compromise that credential. Resist the urge to default to DMs between team members and encourage all discussion in channels, anyway, because this is better for keeping the team in sync.
Do not use iMessage, have everyone install the Slack mobile app (configure notifications correctly so it doesn’t blow up your phone constantly). Do not use Skype, have everyone install the Slack desktop app and set it to open on login.
If you must communicate super-secret things, use Signal, ideally only with phone numbers that aren’t widely known.
Call your carrier, and tell them to enable a port lock on your number due to a security threat. Do this for every number you use. Today it is a very common attack that someone will impersonate you to your carrier and get them to either issue them a replacement SIM card (deactivating yours, and allowing them to send and receive texts from your number), or to port the number to a different carrier (at an account that they control). This attack is enabled by the fact that people know your phone number, name, and address, and this (plus some other easily obtainable information) is pretty much all that most carriers require.
For any services that support only SMS-based 2FA and don’t let you use app-based 2FA: don’t use your normal phone number that people call you on. Use either a dedicated Google Voice number that you’ve not given to anyone, or get a dedicated mobile account just for these things.