31 Mar Part 1 | Securing a Google Apps environment
My name is Guy Ellis, Head of Deployment and Support at Appscare, a Google Premier partner in EMEA. This is the first in a series of “takeover” blog posts I am writing around securing a Google Apps environment – why this is so important and how this can be achieved.
Secure your accounts
The very first step we encourage all of our customers to take is securing the individual accounts in a domain. We see a number of methods attackers use to compromise accounts;
- Stolen devices
- Stolen passwords (for example, from another compromised service, where a user has used the same email / password combination)
- Phished passwords (either via email or keylogging)
- Physical break-ins (written down passwords)
Password complexity is bad!
Often customers are surprised that Google do not offer the ability to define password complexity for a Google Apps account. In my opinion, this is a conscious decision Google have made – password complexity encourages bad user behaviour;
- Pattern passwords (January01, February02, March03….. etc)
- Written down passwords (post-it notes, back of a notepad etc)
- Password re-use (one “complex” password used between multiple services)
So – I assume you are now wondering, if complex passwords are discouraged what is the solution?
Two-factor authentication is good!
Two-factor authentication (or two-step verification). The concept is simple, the first factor of authentication should be something that the user knows (a password). The second factor of authentication should be something that the user has (a token, a mobile phone, a cryptographic USB key etc).
Google provide two step authentication services, free of charge to both paid for (Google Apps) and free (Gmail.com) accounts. Google provide a number of mechanisms to provide the “something a user has” side of the authentication;
- Google Authenticator Application | Android / iOS
- SMS message
- Voice call (landline / mobile)
- U2F security key
- Backup codes
The technical details – how does it work?
Google assign a threat score to every single request which traverses their platform, whether this is a logon request, access to open an email or opening a Google Drive attachment. Factors which are used to determine a threat score include;
- Service accessed (i.e. admin panel would achieve a higher score than Gmail)
- Last logon time
- Last 2FA provided time
- Known device
- Historic user behaviour (common logon locations, times, device type(s)
- Other account activity (invalid password attempts)
When thresholds in the threat score are breached, the user is re-prompted for authentication, or subject to severity two factor authentication. Certain actions will *always* trigger two factor authentication;
- Logging on from a new device
- If two factor authentication has not been completed on that device in the last 30 days
The outcome, is that two factor authentication should not be intrusive or inconvenient for any users, but provides strong protection against compromised passwords. Most users (same device, same country of logon) will only be prompted once every 30 days.
How should I go about rolling this out?
Ultimately, how you roll this out is up to you! I would however seriously encourage you used the following as a guideline;
- Set a deadline date for enrollment – do not budge for anyone.
- If you are in the process of rolling out Google Apps, make 2FA mandatory from the time the user goes live
- If you have already rolled out Google Apps, most organisations should be able to achieve 2FA roll-out within 3 weeks.
- Communicate communicate communicate!
- Clear communications as to why two factor is being enforced, when this is being enforced and what a user must do before this date
- Re-enforcement communication “The deadline is approaching, ensure you complete these steps before x date to continue accessing your account”
- Use multiple communication channels – intranet, email, posters, video – whatever means are available in your organisation!
- Skill your helpdesk up – there will be queries, there will be people who ignore all instructions – make sure the helpdesk are equipped to help!
Watchpoints / Notes from the field
Despite the fact that we, here at AppsCare pride ourselves on always getting things right, first time, every time, no exceptions. Miraculously there are a few watchpoints we have discovered over time!
- 2 Step authentication is not suitable for shared accounts. Google best-practice dictates that if shared accounts are required, they should not be logged into directly. Consider using Google Groups collaborative inbox, or Gmail delegation if users currently log directly into shared accounts.
- Consider how you will handle new starters. We recommend issuing the following information with the new starter credentials;
- Backup Code 1
- Backup Code 2
- Instructions to enable 2FA
- Do not be rigid with the 2nd factor options – encourage people to use the application, SMS, voice calls – but let them make the ultimate choice on the best mechanism for them.
- Build a plan-of-attack for service accounts. If you have service accounts (for example, for SMTP relaying), consider how this will authenticate moving forwards – there are many options including;
- oAuth2 tokens
- Application specific passwords
- Enforce 2FA across all accounts – no exceptions
- Seek internal sponsorship (exec / heads of departments) to add validation that this is important, and encourage uptake before the deadline date
- Consider your mobile device types – will they be impacted by this rollout? How can this be mitigated (for example – encouraging the Google applications on iOS)
- If you are using SAML based SSO, you will need to consult with your SSO provider as to what two factor authentication options they provide
I hope you found this guest blog post useful – if you have any questions please drop them in the comments box below!
Keep an eye out for part 2 … email authentication, why you need to do your bit!
Thanks – Guy Ellis.