In light of the endless predictions for 2016 stating "security" as the hot topic for the year, I want to take this opportunity to highlight some of your best practices for maintaining a secure Google Apps experience. These are 6 must-do's for any end-user or admin who takes their privacy & security seriously. Even better, they are all relatively easy to implement--be sure to spread the word across your organization!
Enable 2-Step Verification
One of the simplest methods of maximizing your Google Apps security is to turn on and enforce 2-Step Verification for your Google Apps users. Since most people these days have a smartphone, or can at least receive text messages on their mobile device, enabling 2SV is a no brainer.
2-Step Verification requires your users to sign in with an additional time-sensitive security token that is sent to a trusted device. Its also only required every 30 days or whenever they log in from a new device. An attacker therefore must know the user’s email address, password, and physically have their secure device in hand before accessing the account. Are company phones too expensive to make sure everybody can get their 2SV token? Don’t worry! Google supports the U2F authentication standard which means you can use a small USB-flash-drive-sized device to authenticate as long as your users are on Google Chrome.
Increase your minimum password length
Your cloud security is only as strong as your users’ passwords. The default minimum password length required by Google Apps is 8 characters long, and for most customers this is sufficient. Increasing the length of your passwords, however, helps cut down on the chances of a password being guessed. While Google has rate limits in place to prevent brute force password cracking, it doesn’t stop somebody from guessing the password in a couple tries based on publically available information such as pet’s names (not that I would ever use such an obvious password).
Changing the password length is really easy from the Google Apps Admin Panel. Simply follow the steps in this Google Support article and you can quickly increase the length of passwords to something a little more secure.
Set up SPF
Helping others increase their security helps everyone’s security. By creating a SPF (Sender Policy Framework) record in your DNS, you are saying which servers are allowed to send as your domain. This is a framework used by email recipients to help them sort through spam and determine whether or not an email is legitimate. At a basic level, it is a list of all servers that you have control over that can send out emails. The recipient’s email service checks this publically available list and makes sure that an email came from an approved source. If an unapproved source sent an email on behalf of your domain, the SPF record will let recipients know that it is most likely spam or phishing.
These types of records can be easily set up in your DNS and made to be compliant with using Google Apps as your email provider. Just follow the steps in this Google Support article for enabling this protection.
Turn on DKIM
Intended to prevent spoofing, DKIM (DomainKeys Identified Mail) is a way to let recipients know they have received a legitimate email from your domain. It uses a private and public key pair that creates a digital signature on the headers of an outgoing email. The public key is published on your DNS and can therefore be read by any recipient. Google Apps can then sign emails with a private key that can only be properly decrypted with the public key. When a recipient gets a signed email, they can decrypt it and determine if it was really sent not only by an authorized server, but an authorized server with the right key on it. Emails that are not legitimate will not be signed at all or with the wrong key. Google Apps makes DKIM very easy to implement by simply following the steps available in this Google Support article.
Require passwords for mobile devices
Many companies are now adding a Bring Your Own Device (BYOD) policy to their list of tech do’s and don’ts. However, not all of them are clear on whether or not a device needs to be password protected. Without a password on the device itself, any phone left in a cab or forgotten in a restaurant becomes an open portal to all of your company’s data. Have your company go a step further by not only telling users they need to have a password-protected phone to get their email and documents on the go, but by denying their device access to data until it conforms to all security policies.
In your Google Apps Admin Panel, choose Device Management and then Mobile from the left menu. The first option in the list, Device management settings, contains all of the security policies you can not only enable but actually demand your users employ. Simply make sure the checkboxes for the 3 types of syncing are checked, and that the box next to “Require users to set passwords on their devices” is also enabled. Here you can tweak settings for characteristics such as password complexity (swipe pattern or pin vs. a real password for example), as well as if passwords ever expire. Don’t forget to save your changes!
Use Google Apps as SSO Provider
Back in October Google introduced the ability for Google Apps to be used as an Identity Provider (IdP) for integration with other popular service providers such as AWS, BlueJeans, Dropbox, Salesforce, WebEx, Zendesk, and more. This means that your users can use their Google Apps credentials (and 2SV) to sign in to other cloud applications that your company uses.
Google provides step by step instructions for some of the most popular applications, and the same steps can be applied to other service providers that utilize SAML 2.0. By using Google Apps as your IdP, you make managing multiple separate cloud services much easier on your admin team. Locking a terminated user out of all of your company’s applications is as easy as locking them out of just Google.Originally published on January 14, 2016