diff --git a/5_authentication_checklist.md b/5_authentication_checklist.md
index 658be8dbf9338499213053445482e54f5d9fd25e..43554b31098de2aa7bb1a47ad2cf268f43ad33e1 100644
--- a/5_authentication_checklist.md
+++ b/5_authentication_checklist.md
@@ -66,7 +66,9 @@ on the provider to protect your most important secret.*
*A newer and very strong second factor is a code embedded on a special type of USB device also known as a "Universal 2nd Factor" (U2F) such as a the Yubikey (https://www.yubico.com). Not having a dependency on a working phone or cell signal is one of many advantages of U2F devices, but as of the latest update to this document in the fall of 2017, there are still relatively few services that support such U2F capable devices. Major services your organization may use that support U2F keys include Dashlane, Dropbox, Facebook, Google and Salesforce. You can read more about U2F at https://www.yubico.com/solutions/fido-u2f/.*
-***Text message-based codes are not recommended for use as a second factor, as they are vulnerable to hijacking and interception. For example, a malicious party could call your cell provider, impersonate you, say you lost your phone, and arrange for a new SIM card linked to your number to be sent to them. Once they receive the card and put it in a phone, they would be able to receive your text messages.*** <are there other examples or a better way to put this?> *Adopt one of the other mechanisms above instead.*
+***Text message-based codes are not recommended for use as a second factor.*** *It can be surprisingly easy for someone to take over control of a cell number via social engineering and/or fraud (see https://www.ftc.gov/news-events/blogs/techftc/2016/06/your-mobile-phone-account-could-be-hijacked-identity-thief, https://techcrunch.com/2016/06/10/how-activist-deray-mckessons-twitter-account-was-hacked/, and https://threatpost.com/nist-recommends-sms-two-factor-authentication-deprecation/119507/ for more information). Adopt one of the other mechanisms above instead.*
+
+*Access Now, an organization that "defends and extends the digital rights of users at risk around the world," has released a clear and handy guide to choosing a two-factor authentication method: https://www.accessnow.org/cms/assets/uploads/2017/09/Choose-the-Best-MFA-for-you.png.*
:heavy_check_mark: **Separate organizational and everyday passwords**
:rocket::rocket::rocket::wrench::wrench::fire::fire::fire:
diff --git a/8_gsuite_security_checklist.md b/8_gsuite_security_checklist.md
index 0138d83fc2e463ebcc460293805f399f940e75d7..e45c828b1dced12a07e60be41ead641418e03023 100644
--- a/8_gsuite_security_checklist.md
+++ b/8_gsuite_security_checklist.md
@@ -1,24 +1,26 @@
---
document set: DRAFT DIGITAL SECURITY CHECKLISTS FOR U.S. NON-PROFITS
-title: GSuite Security Checklist
+title: G Suite Security Checklist
author: Jonah Silas Sheridan, Lisa Jervis for Information Ecology
-last modified: 9/2/2017
+last modified: 10/11/2017
version: 2.0, DRAFT NOT FOR FOR PUBLIC USE
---
-# GSuite Security Checklist
+# G Suite Security Checklist
## Introduction
-As of this document's creation (in 2017) a significant portion of U.S. non-profits rely on Google's free online "cloud" applications (Gmail, Google Docs/Sheets, GDrive, and Google Calendar among them) to do their work. While many groups still depend on personal or other Gmail accounts made for their work (any login that ends with @gmail.com) for access to these services, Google also offers GSuite: a version of these tools suited for use in organizations. GSuite provides significant advantages over personal accounts, including organizational email addresses using your chosen domain name (the part of an email address after the @ sign), administrative controls, advanced settings, and 24/7 support 24/7 tech support for use of the tools. These features can improve your organization's technology in many areas, including helping you better secure your information by providing tighter management, control, and monitoring of your systems and how they are used.
+*This checklist comes from the Weathering the Storms toolkit, which contains wraparound documentation including an introduction, frequently asked questions, and a glossary where you can look up any terms that are unfamiliar to you. This is a community-driven document set with the latest version always at https://ecl.gy/sec-check. We welcome your feedback via RoadMap, or our contact form at https://iecology.org/contact/.*
-Because of these advantages, and the fact that Google offers the Basic version of GSuite for free to registered U.S. 501c3 organizations, setting it up for your organization is highly recommended for all U.S. organizations that already rely on Google's web-based tools. While there are definitely risks associated with providing any third-party corporation access to all your information and the metadata about how and where you and your team use it--especially a corporation in the business of data mining and advertisement targeting--if you are already accepting this risk by relying on Google's tools, GSuite will at least help you secure that information from others. You can begin the sign up process and read about the offerings at https://www.google.com/nonprofits/products/apps-for-nonprofits.html.
+As of this document's creation (in 2017) a significant portion of U.S. non-profits rely on Google's free online "cloud" applications (Gmail, Google Docs/Sheets, GDrive, and Google Calendar among them) to do their work. While many groups still depend on personal or other Gmail accounts made for their work (any login that ends with @gmail.com) for access to these services, Google also offers G Suite: a version of these tools suited for use in organizations. G Suite provides significant advantages over personal accounts, including organizational email addresses using your chosen domain name (the part of an email address after the @ sign), administrative controls, advanced settings, and 24/7 support 24/7 tech support for use of the tools. These features can improve your organization's technology in many areas, including helping you better secure your information by providing tighter management, control, and monitoring of your systems and how they are used.
-***Please note that this document should in no way be read as an explicit endorsement of GSuite or other Google tools for movement-building, activist, or other non-profit organizations. There are many other tools--with a range of associated security and operational tradeoffs--that can meet the needs that GSuite fills. If any previous security risk assessment has shown that the vulnerabilities and risks associated with Google's tools are unacceptable for your organization, or for any reason having strong trust relationship with a U.S.-based corporation is concerning to you, this checklist is not relevant to you and it is not a recommendation to rethink your existing decisions.***
+Because of these advantages, and the fact that Google offers the Basic version of G Suite for free to registered U.S. 501c3 organizations, setting it up for your organization is highly recommended for all U.S. organizations that already rely on Google's web-based tools. While there are definitely risks associated with providing any third-party corporation access to all your information and the metadata about how and where you and your team use it--especially a corporation in the business of data mining and advertisement targeting--if you are already accepting this risk by relying on Google's tools, G Suite will at least help you secure that information from others. You can begin the sign up process and read about the offerings at https://www.google.com/nonprofits/products/apps-for-nonprofits.html.
-For those that have already adopted GSuite in the non-profit sector, the checklist that follows offers direction on how to set up and use the administrative controls offered by the free GSuite Basic platform to harden your organizational GSuite account and improve your overall digital security level. (In this context, "harden" means to reduce the points of vulnerability of a system by turning off or disabling functionality that is not needed.) Note that, as indicated in the associated description, many of these tasks are specific implementations of checklist items from elsewhere in this set.
+***Please note that this document should in no way be read as an explicit endorsement of G Suite or other Google tools for movement-building, activist, or other non-profit organizations. There are many other tools--with a range of associated security and operational tradeoffs--that can meet the needs that G Suite fills. If any previous security risk assessment has shown that the vulnerabilities and risks associated with Google's tools are unacceptable for your organization, or for any reason having strong trust relationship with a U.S.-based corporation is concerning to you, this checklist is not relevant to you and it is not a recommendation to rethink your existing decisions.***
-It is also noted that there are additional controls and security features available using other editions of GSuite, including GSuite for Business and GSuite Enterprise. While neither of these other editions are provided for free (and for a system that is priced by the user, costs can add up quickly), the additional functionality provided has tremendous value for organizations that have additional security needs stemming from items including but not limited to compliance requirements, the presence of highly sensitive data, or a wish to deploy tightly controlled mobile devices. You can review edition differences at https://gsuite.google.com/compare-editions/; if you're unsure which is best for your needs, ask for help from your technical support provider.
+For those that have already adopted G Suite in the non-profit sector, the checklist that follows offers direction on how to set up and use the administrative controls offered by the free G Suite Basic platform to harden your organizational G Suite account and improve your overall digital security level. (In this context, "harden" means to reduce the points of vulnerability of a system by turning off or disabling functionality that is not needed.) Note that, as indicated in the associated description, many of these tasks are specific implementations of checklist items from elsewhere in this set.
+
+It is also noted that there are additional controls and security features available using other editions of G Suite, including G Suite for Business and G Suite Enterprise. While neither of these other editions are provided for free (and for a system that is priced by the user, costs can add up quickly), the additional functionality provided has tremendous value for organizations that have additional security needs stemming from items including but not limited to compliance requirements, the presence of highly sensitive data, or a wish to deploy tightly controlled mobile devices. You can review edition differences at https://G Suite.google.com/compare-editions/; if you're unsure which is best for your needs, ask for help from your technical support provider.
## Key
:heavy_check_mark: Record actions
@@ -26,67 +28,77 @@ It is also noted that there are additional controls and security features availa
:wrench: Technical skill level required
:fire: Work flow disruption for staff
-## GSuite Configuration Security Tasks
-:heavy_check_mark: **Make a plan, preferably before deploying GSuite, detailing how your information is used by your staff, volunteers, and others, to ensure that you understand your security needs and can configure the tools correctly.**
+## G Suite Configuration Security Tasks
+:heavy_check_mark: **Make a plan, preferably before deploying G Suite, detailing how your information is used by your staff, volunteers, and others, to ensure that you understand your security needs and can configure the tools correctly.**
:rocket::rocket::rocket::wrench::fire:
-*GSuite is a powerful platform with a lot of moving parts and a lot of possible configurations. As with all tools, the more time and energy you put into understanding the different users and user types you have and what features they need to use, the more effective your implementation of security controls will be. First read through this checklist to familiarize yourself with some practices you may want to employ in your GSuite setup. Then make a list of all the different groups of people you have in your organization that will be using GSuite; a typical lit might be: full-time staff, part-time staff, volunteers, and or board members). Then think about and list how each of those groups will need each of the various tools: e.g., to send email, to edit documents, to access your shared contacts list, to maintain a shared calendar, and so on. Think about whether any group should have special access to specific tools that nobody else needs or whether any group should be restricted from tools that everyone else needs. Also think about any shared roles where multiple people need access to the same identity, email box or set of documents -- such as an email account used to send or receive invoices, or a set of documents used for a volunteer run hotline. Google has produced a lot of documentation on how to plan your GSuite deployment (see https://support.google.com/a/answer/4514329) that can help you understand the applications and settings available to you in your configuration process. At a minimum, having a well-crafted plan will guide you as you step through the administrative tools at https://admin.google.com and also help you formulate specific questions for GSuite support as you go through the setup.*
+*G Suite is a powerful platform with a lot of moving parts and a lot of possible configurations. As with all tools, the more time and energy you put into understanding the different users and user types you have and what features they need to use, the more effective your implementation of security controls will be. First read through this checklist to familiarize yourself with some practices you may want to employ in your G Suite setup. Then make a list of all the different groups of people you have in your organization that will be using G Suite; a typical list might be: full-time staff, part-time staff, volunteers, and board members). Then think about and list how each of those groups will need each of the various tools that are part of G Suite: e.g., to send email, to edit documents, to access your shared contacts list, to maintain a shared calendar, and so on. Does any single group need a tool that no one else needs? Conversely, does any group have no need for a tool that everyone else uses? Also think about any shared roles where multiple people need access to the same identity, email box, or set of documents -- such as an email account used to send or receive invoices, or a set of documents used for a volunteer-run hotline. Google has produced a lot of documentation on how to plan your G Suite deployment (see https://support.google.com/a/answer/4514329); it can help you understand the applications and settings available to you in your configuration process. At a minimum, having a well-crafted plan will guide you as you step through the administrative tools at https://admin.google.com and also help you formulate specific questions for G Suite support as you go through the setup.*
-:heavy_check_mark: **Create a single, dedicated account with full administrative control of GSuite ("Super Admin" permissions) and do not associate it with with any individual's email address; provide a recovery email address or phone number that is controlled by your organization or trusted tech support provider and not an individual employee. Assign other administrative permissions appropriately.**
+:heavy_check_mark: **Create a single, dedicated account with full administrative control of G Suite ("Super Admin" permissions) and do not associate it with with any individual's email address; provide a recovery email address or phone number that is controlled by your organization or a trusted tech support provider and not an individual employee. Assign other administrative permissions appropriately.**
:rocket::rocket::wrench::wrench::fire::fire:
-*While convenient, giving everyday user accounts permission to administer your GSuite creates risk. Doing so can mean that the loss or theft of a person's device, or a breach of their password, could put all of your organization's information at risk. Instead, sign up with or create a unique email address (like gsuite@yourdomain.org, replacing yourdomain.org with your organization's domain name) for this purpose that isn't used for anything else. Give this account "Super Admin" permissions (which means full control over your GSuite setup, including access to all calendars and accounts), remove those permissions from any other accounts (note that the account you use to perform your GSuite setup will have Super Admin permissions assigned automatically), and store the password in a safe way such as a well-configured password manager (see authentication checklist for more information) or safety deposit box, using it only when you need to change settings in GSuite. You will be asked to give recovery email or phone number in case of a lost password. This email or phone should be controlled by your organization or trusted delegate such as a tech support provider or affiliate organization rather than by an individual employee. You can find instructions for giving or taking away Super Admin permissions for a user at https://support.google.com/a/answer/172176. Directions for setting up a recovery phone number or email are at https://support.google.com/accounts/answer/183723.*
+*While convenient, giving everyday user accounts permission to administer your G Suite creates risk. Doing so can mean that the loss or theft of a person's device, or a breach of their password, could put all of your organization's information at risk. Instead, sign up with or create a unique email address (like GSuite@yourdomain.org, replacing yourdomain.org with your organization's domain name) for this purpose; do not use it for anything else. Give this account "Super Admin" permissions (which means full control over your G Suite setup, including access to all calendars and accounts), remove those permissions from any other accounts (note that the account you use to perform your G Suite setup will have Super Admin permissions assigned automatically), and store the password in a safe way such as a well-configured password manager (see the authentication checklist for more information) or safety deposit box, using it only when you need to change settings in G Suite. You will be asked to give recovery email or phone number in case of a lost password. This email or phone should be controlled by your organization or trusted delegate such as a tech support provider or affiliate organization rather than by an individual employee. You can find instructions for giving or taking away Super Admin permissions for a user at https://support.google.com/a/answer/172176. Directions for setting up a recovery phone number or email are at https://support.google.com/accounts/answer/183723.*
-*Other levels of administrative control can be assigned according to your organizational needs. For example, you could give a tech support provider Help Desk Admin permissions, which will allow them to reset passwords for people but not create users or groups. Now you can give control of that account to someone who does tech support without giving them total control of your systems. You can review the built-in administrative groups and find a link on how to make custom roles of your own at https://support.google.com/a/answer/2405986. Creating new users is the most common administrative task in many organizations and, although it may be tempting to delegate this permission to a normal operating account, gaining the power to create a user and add it to groups effectively gives a malicious actor access to all of your files until the user they create is identified and disabled, so it is best to give this permission only to specialized administrative accounts.
+*Other levels of administrative control can be assigned according to your organizational needs. For example, you could give a tech support provider Help Desk Admin permissions, which will allow them to reset passwords for people but not create users or groups. You can give control of that account to someone who does tech support without giving them total control of your systems. You can review the built-in administrative groups and find a link on how to make custom roles of your own at https://support.google.com/a/answer/2405986. Creating new users is the most common administrative task in many organizations and, although it may be tempting to delegate this permission to a normal operating account, gaining the power to create a user and add it to groups effectively gives a malicious actor access to all of your files until the user they create is identified and disabled, so it is best to give this permission only to specialized administrative accounts.*
:heavy_check_mark: **Enforce password length rules.**
:rocket::wrench::fire::fire:
-*GSuite allows you to set minimum (and maximum) password lengths. Setting a minimum length of at least 12 characters helps guard against easily guessable passwords. Instructions on getting this up are at https://support.google.com/a/answer/139399?hl=en. Note that helping people to produce long passphrases that are a combination of words that have never appeared together (perhaps with some character substitutions) and that don't include any information about that person will allow you to push this minimum length even higher so that guessing a password becomes virtually impossible.*
+*G Suite allows you to set minimum (and maximum) password lengths. Setting a minimum length of at least 12 characters helps guard against easily guessable passwords. Instructions on getting this up are at https://support.google.com/a/answer/139399?hl=en. Note that helping people to produce long passphrases that are a combination of words that have never appeared together (perhaps with some character substitutions) and that don't include any information about that person will allow you to push this minimum length even higher so that guessing a password becomes virtually impossible. <include this tip in passwords doc, and/or replace this sentence with a reference to the password checklist?>*
-:heavy_check_mark: **Use the organizational units functionality in GSuite to make groupings of user accounts or devices, and give them the minimum level of access required to do their work.**
+:heavy_check_mark: **Use the organizational units functionality in G Suite to make groupings of user accounts or devices, and give them the minimum level of access required to do their work.**
:rocket::rocket::wrench::wrench::fire::fire:
-*Giving all users ability to use all the GSuite tools in any way they want invites security risk for your organization. Instead, you should practice the security concept of "least authority"--meaning you give users only the minimum access that is required for them to do their work. For example, you may want have volunteers enter information into Google Sheets but not send email from accounts with your domain name. To allow you to control access in this way efficiently rather than on a per-user basis, GSuite provides a structure called an organizational unit. Organizational units allow you to categorize users or devices into groups, and then assign policies to each of those groups. These policies, including the ability to access specific tools or to apply certain settings to their accounts. You can read an overview of applying policies at https://support.google.com/a/topic/1227584. An article about organizational structures is at https://support.google.com/a/answer/4352075 and instructions for creating them at https://support.google.com/a/answer/182537.*
+*Giving all users ability to use all the G Suite tools in any way they want invites security risk for your organization. Instead, you should practice the security concept of "least authority"--meaning you give users only the minimum access that is required for them to do their work. For example, you may want have volunteers enter information into Google Sheets but not send email from accounts with your domain name. To allow you to control access in this way efficiently rather than on a per-user basis, G Suite provides a structure called an organizational unit. Organizational units allow you to categorize users or devices into groups, and then assign policies to each of those groups. These policies cover things like the ability to access specific tools or to apply certain settings to their accounts. You can read an overview of applying policies at https://support.google.com/a/topic/1227584. An article about organizational structures is at https://support.google.com/a/answer/4352075 and instructions for creating units is at https://support.google.com/a/answer/182537.*
*Once you have created these units, you can use them to control access to services as described at https://support.google.com/a/answer/182442 or to apply specific settings about those services as described at https://support.google.com/a/answer/2655363.*
:heavy_check_mark: **Use Google Groups and Team Drive features to provide appropriate access to files for different groups of users, and to ensure that your organization always controls its own information.**
:rocket::rocket::wrench::fire::fire::fire:
-*Historically one of the challenges of managing your organization's files using Google Drive has been the risk of loss of access to key documents when employees or volunteers leave the team, as well as the lack of ability to prevent sensitive information from being shared more widely than it should be. By setting up one or more Team Drives (as described at https://support.google.com/a/answer/7212025) you can ensure that the Super Admin for your GSuite domain always has access to the files that are stored there. You can also apply permissions (as described in this article https://support.google.com/a/answer/7337635?hl=en) to a Team Drive to allow only the minimum access needed. For example, you might have organizational policy documents that everyone needs to be able to view and only certain staff members should be able to change. You can give these permissions by individual email address if your organization is small enough, and, for larger groups and easier management, you can create groups in Google Groups (https://support.google.com/a/answer/33329) and give appropriate permissions to the Group's email address. This way when a new person comes on board or leaves a team or the organization, you need only to take them out of the relevant Google Groups or Team Drives to also remove their account's permissions to files. Note that by locking down your files in this way, your system becomes much less widely accessible to staff, and someone will need to be in charge of and regularly available for changes to permissions and group settings as needed. The increased control of your files is well worth this task overhead. (Note also that Team Drive permissioning carries other operational tradeoffs around folder structure: it may limit who can create folders and move files around, which can benefit the clarity with which files are organized and may also run counter to staff expectations and be quite disruptive.)*
+*Historically one of the challenges of managing your organization's files using Google Drive has been the risk of loss of access to key documents when employees or volunteers leave the team, as well as the lack of ability to prevent sensitive information from being shared more widely than it should be. By setting up one or more Team Drives (as described at https://support.google.com/a/answer/7212025) you can ensure that the Super Admin for your G Suite domain always has access to the files that are stored there. You can also apply permissions (as described in this article https://support.google.com/a/answer/7337635?hl=en) to a Team Drive to allow only the minimum access needed. For example, you might have organizational policy documents that everyone needs to be able to view and only certain staff members should be able to change. You can give these permissions by individual email address if your organization is small enough, and, for larger groups and easier management, you can create groups in Google Groups (https://support.google.com/a/answer/33329) and give appropriate permissions to the Group's email address. This way when a new person comes on board or leaves a team or the organization, you need only to take them out of the relevant Google Groups or Team Drives to also remove their account's permissions to files. Note that by locking down your files in this way, your system becomes much less widely accessible to staff, and someone will need to be in charge of and regularly available for changes to permissions and group settings as needed. The increased control of your files is well worth this overhead. (Note also that Team Drive permissioning carries other operational tradeoffs around folder structure: it may limit who can create folders and move files around, which can benefit the clarity with which files are organized and may also run counter to staff expectations and be quite disruptive.)*
:heavy_check_mark: **Turn on two-factor authentication, and, in conjunction with appropriate planning, training, and support, enforce it for all users. Use Google Authenticator codes or universal two-factor (U2F) hardware keys as a second factor rather than text message codes, and make sure staff reports immediately if their second factor is lost or stolen.**
:rocket::rocket::rocket::wrench::wrench::wrench::fire::fire::fire:
-*One of the advantages of GSuite as a platform is its support for two-factor authentication, whereby users to prove their identity at login with two things that they know or control: 1) a password and 2) a hardware key, code produced by a program running on their computer or phone, a text message code, or even a list or codes they have printed out. Unless your organization owns and manages the cell phones that would be receiving a text message, it is strongly advised that all staff use a non-text-message-based second factor when logging into Google services, especially for any accounts with Super Admin or other administrative rights to your GSuite domain. This is because it can be surprisingly easy for someone to take over control of a cell number via social engineering and/or fraud (see https://www.ftc.gov/news-events/blogs/techftc/2016/06/your-mobile-phone-account-could-be-hijacked-identity-thief, https://techcrunch.com/2016/06/10/how-activist-deray-mckessons-twitter-account-was-hacked/, and https://threatpost.com/nist-recommends-sms-two-factor-authentication-deprecation/119507/ for more information).*
-*There are several alternatives to text messaging for this purpose. Google Authenticator is available in the Google Play store for Android phones, in the App Store for iOS devices, and as a Chrome extension for use in the browser. The most common U2F hardware key is called a Yubikey and can be ordered at: https://www.yubico.com/gafw/. Using this link and logging into your GSuite admin account will allow you to order up to 50 keys at the half-price cost of $9 each.*
-*Because of the choices available, the impact of this change on staffs' daily work, and the consequences of disrupted access to GSuite accounts, careful planning for the rollout of two-factor authentication is essential. Furthermore, enforcing two-factor authentication for all users requires each staff member to participate in this rollout in very specific ways. Refer to all the information and resources below to understand the scope of necessary planning.*
-*Information about setup, as well as links to training materials for staff, is detailed in this document: https://support.google.com/a/answer/175197. Have staff print backup codes (see directions here: https://support.google.com/accounts/answer/1187538) so that they can still get into their account if their phone or hardware key is lost or stolen. Although those backup keys will allow them keep working, it is important to train users to report a lost second factor or set of backup codes to whomever is responsible for administration of your GSuite domain. Once reported lost or stolen, a security key MUST be revoked (https://support.google.com/a/answer/2537800#seckey), backup codes MUST be regenerated by the user (https://support.google.com/accounts/answer/1187538) or a Google Authenticator app MUST be removed as a second factor to preserve your security levels.*
-*Be aware that separate passwords for applications such as email or calendaring clients that do not support the two-factor process will become necessary, and you will want to be sure you help staff create those as outlined in this document: https://support.google.com/a/answer/1032419.*
-*You can also use the Advanced Security Settings, which can be applied to all of your users, or any group of users in an Organizational Unit, to require that two-factor authentication is set up within a certain amount of time after a user's first login. Although this may put a strain on technical support resources, it is highly recommended. Directions to enforce two-factor authentication can be found at https://support.google.com/a/answer/2548882.*
-*Note: A more general version of this recommendation can be found in the Authentication Checklist that is part of this document set. Two-factor authentication is a best practice for use with any service or tool that supports it, and each will have its own set of options available--and planning steps--for you and your staff to consider.*
+*One of the advantages of G Suite as a platform is its support for two-factor authentication, whereby users to prove their identity at login with two things that they know or control: 1) a password and 2) a hardware key, code produced by a program running on their computer or phone, a text message code, a phone call to a cell or landline, or even a list or codes they have printed out. Unless your organization owns and manages the cell phones that would be receiving a text message <or phone call? is the problem with the SMS protocol, the SIM card, or both?>, it is strongly advised that all staff use a non-text-message-based <phone number based? see above Q> second factor when logging into Google services, especially for any accounts with Super Admin or other administrative rights to your G Suite domain. This is because it can be surprisingly easy for someone to take over control of a cell number via social engineering and/or fraud (see https://www.ftc.gov/news-events/blogs/techftc/2016/06/your-mobile-phone-account-could-be-hijacked-identity-thief, https://techcrunch.com/2016/06/10/how-activist-deray-mckessons-twitter-account-was-hacked/, and https://threatpost.com/nist-recommends-sms-two-factor-authentication-deprecation/119507/ for more information).*
+
+*There are several alternatives to text messaging for this purpose. Google Authenticator is available in the Google Play store for Android phones, in the App Store for iOS devices, and as a Chrome extension for use in the browser. The most common U2F hardware key is called a Yubikey and can be ordered at: https://www.yubico.com/gafw/. Using this link and logging into your G Suite admin account will allow you to order up to 50 keys at the half-price cost of $9 each.*
+*Because of the choices available, the impact of this change on staffs' daily work, and the consequences of disrupted access to G Suite accounts, careful planning for the rollout of two-factor authentication is essential. Furthermore, enforcing two-factor authentication for all users requires each staff member to participate in this rollout in very specific ways. Refer to all the information and resources below to understand the scope of necessary planning.*
+
+*Information about setup, as well as links to training materials for staff, is detailed in this document: https://support.google.com/a/answer/175197. Have staff print backup codes (see directions here: https://support.google.com/accounts/answer/1187538) so that they can still get into their account if their phone or hardware key is lost or stolen. Although those backup codes will allow them keep working, it is important to train users to report a lost second factor or set of backup codes to whomever is responsible for administration of your G Suite domain. Once reported lost or stolen, a security key MUST be revoked (https://support.google.com/a/answer/2537800#seckey), backup codes MUST be regenerated by the user (https://support.google.com/accounts/answer/1187538), or a Google Authenticator app MUST be removed as a second factor to preserve your security levels. Be aware that separate passwords for applications such as email or calendaring clients that do not support the two-factor process will become necessary, and you will want to be sure you help staff create those as outlined in this document: https://support.google.com/a/answer/1032419.*
+
+*You can also use the Advanced Security Settings, which can be applied to all of your users, or any group of users in an organizational unit, to require that two-factor authentication is set up within a certain amount of time after a user's first login. Although this may put a strain on technical support resources, it is highly recommended. Directions to enforce two-factor authentication can be found at https://support.google.com/a/answer/2548882.*
+
+*Note: A more general version of this recommendation can be found in the Passwords and Authentication Safety Checklist in this document set. Two-factor authentication is a best practice for use with any service or tool that supports it, and each will have its own set of options available--and planning steps--for you and your staff to consider.*
:heavy_check_mark: **Implement controls that make it difficult for anyone to spoof email from your domain.**
:rocket::rocket::rocket::wrench::wrench::wrench::wrench::fire::fire:
-*Google has produced a strong set of tools to allow other email systems to verify that email coming from your GSuite domain is in fact yours, preventing spoofed emails. (Email spoofing is the creation of email with a forged "from" address, generally sent with the intent to deceive the recipient.) Using them will make it very hard for your email addresses to be abused for phishing or other attacks against others as well as faked internally. These tools use the latest Internet standards called Domainkeys Identified Mail (DKIM), Sender Policy Framework (SPF) records, and the associated Domain-based Message Authentication, Reporting & Conformance (DMARC) to do this. Documentation that will guide you through setting them all up is at https://support.google.com/a/topic/4388154.
-*This is a highly technical set of tasks which also involve your Domain Name Servers (DNS) which may not be hosted at Google and so require a different login and may not have an easy interface to work within.*
-*Correct SPF records require identifying **all** *the services that are currently sending email on your behalf (which could include databases, mass mailing tools, email list hosts, fundraising tools, and more) and incorrect configurations can cause your legitimate email to be marked as spam. For this reason, determining this list carefully is critical to implementing this recommendation in a way that does not interrupt ongoing operations. Once your SPF record is set up, you will need to maintain by making changes any time your organization adopts any new tools that send email from the same domain as your GSuite email addresses. (Other than this maintenance, the tools listed should function in the background and be invisible in their operation.) “Hard fail” settings (records ending in "-all") are preferred for SPF records wherever possible, but be aware that this can cause email bounces if your records are not carefully tuned.*
-*A more general version of this recommendation can be found in the Email Safety Checklist that is part of this document set. It is more easily set up in an integrated platform such as GSuite than in many other environments, so here is rated slightly lower in difficulty and skill required.*
+*Google has produced a strong set of tools to allow other email systems to verify that email coming from your G Suite domain is in fact yours, preventing spoofed emails. (Email spoofing is the creation of email with a forged "from" address, generally sent with the intent to deceive the recipient.) Using them will make it very hard for your email addresses to be abused for phishing or other attacks against external parties, as well as faked internally. These tools use the latest Internet standards called Domainkeys Identified Mail (DKIM), Sender Policy Framework (SPF) records, and the associated Domain-based Message Authentication, Reporting & Conformance (DMARC) records to do this. Documentation that will guide you through setting them all up is at https://support.google.com/a/topic/4388154.*
+
+*Setting up DKIM, SPF, and DMARC is a highly technical set of tasks that involves your Domain Name Servers (DNS) in addition to Google. Your DNS may not be hosted at Google and so require a different login; the management tools and may not have an easy interface to work within. It may be more appropriate to assign this set of tasks to your tech support provider than to do it yourself.*
-:heavy_check_mark: **Disable email forwarding for users so that any sensitive internal emails don't end up traveling insecurely to other email accounts or remain in less-secured email systems that are vulnerable to attack.**
+*SPF records identify which mail servers are permitted to send email on behalf of your domain. Be aware that setting this up requires identifying **all** *the services that are currently sending email on your behalf (which could be databases, mass mailing tools, email list hosts, fundraising tools, and more); incorrect configurations can cause your email to be incorrectly marked as spam. Determining this list carefully is critical to implementing this recommendation in a way that does not interrupt ongoing operations. "Hard fail” settings (records ending in "-all") are preferred for SPF records wherever possible, but be careful, as this can cause email bounces if your records are not carefully tuned. Once set up correctly, however, you will need to maintain this list and make changes any time your organization adopts any other tools that send email from the same domain as your email addresses. Other that these maintenance steps, this should be invisible in operation.*
+
+*A more general version of this recommendation can be found in the Email Safety Checklist in this document set. It is more easily set up in an integrated <same Q as in the email list--what does this mean?> platform such as G Suite than in many other environments, so here is rated slightly lower in difficulty and skill required.*
+
+:heavy_check_mark: **Disable users' ability to set up automatic email forwarding on their account, so that any sensitive internal emails don't end up traveling insecurely to other email accounts or remain in less-secured email systems that are vulnerable to attack.**
:rocket::wrench::fire:
-*Although it can be handy for people to be able to forward their organizational email to personal or other email accounts, your organization has no control over how that email travels and how secured it is once it gets there. By allowing email forwarding to other systems, you create a point of potential disclosure for internal conversations that would be otherwise locked into Google's secured infrastructure and (assuming you follow this checklist in full) protected by strong passwords and two-factor authentication. This is a simple setting that can be applied to all users or a set of users in an Organizational Unit as detailed at https://support.google.com/a/answer/2491924.*
+*Although it can be handy for people to be able to forward their organizational email automatically to personal or other email accounts, your organization has no control over how that email travels and how secured it is once it gets there. By allowing automatic email forwarding to other systems, you create a point of potential disclosure for internal conversations that would be otherwise locked into Google's secured infrastructure and (assuming you follow this checklist in full) protected by strong passwords and two-factor authentication. This is a simple setting that can be applied to all users or a set of users in an Organizational Unit as detailed at https://support.google.com/a/answer/2491924.*
:heavy_check_mark: **Educate your staff on file sharing, including the higher security of sharing by email address and risks associated with sharing files by link.**
:rocket::rocket::wrench::fire:
-*All users should be trained on the exact options available to them for sharing files in GSuite both with peers in the organization and others outside. This help document provides a good overview: https://support.google.com/drive/answer/2494822. Though this article is clear, helpful, and very suitable for end users, document sharing and collaboration workflows can be complex; it is recommended to document some guidelines based on your organization's specific ways of working and then offer in-person or webinar trainings, with live practice, to develop shared understanding and strong usage practices among staff.*
-*Although it is very easy to click the "Get shareable link" on a file or folder and send it to someone for collaboration, there are risks associated with this way of sharing. It is always better to avoid link sharing, as you cannot control that link after it has left your hands. The tightest sharing is by clicking the "Share" button and filling out the "People" field with email addresses associated with Google-based accounts, whether inside your domain or not. If sharing in this way, you can copy the link from your address bar and share it safely. Although it doesn't always transfer the way you expect, the only risk is that the link won't work and not an increased risk of accidental disclosure of data.*
-* Of course, not everyone has a Google account and sometimes you need to post a to another system and so sometimes a shareable link is necessary. If using link sharing, be sure to watch out for accidentally making a file public, choosing "anyone with the link" instead. You should also teach users set an expiration date, even if far in the future so that the file or folder in question eventually becomes unshared. Last it is important to choose the most limited permissions appropriate -- allowing people with the link to only view or comment on a file if they do not need to change it's contents.*
+*All users should be trained on the exact options available to them for sharing files in G Suite both with coworkers and external partners. This help document provides a good overview: https://support.google.com/drive/answer/2494822. Though this article is clear, helpful, and very suitable for end users, document sharing and collaboration workflows can be complex; it is recommended to document some guidelines based on your organization's specific ways of working and then offer in-person or webinar trainings, with live practice, to develop shared understanding and strong usage practices among staff.*
+
+*Although it is very easy to click the "Get shareable link" on a file or folder and send it to someone for collaboration, there are risks associated with this way of sharing. By default <can this default behavior be changed in the NPO version? it is in our paid version i am pretty sure, 'cause i think we changed it>, clicking "Get shareable link" will create a link that is open to anyone, without needing to sign into a Google account. It is always better to avoid this sharing setting, as you cannot control that link after it has left your hands. The tightest control over sharing is exercised by clicking the "Share" button and filling out the "People" field with email addresses associated with Google-based accounts, whether inside your domain or not. When sharing in this way, you can copy the link from your address bar and share it safely, as it will remain accessible only to those with whom it has been shared.*
-:heavy_check_mark: **Make sure someone is assigned to regularly monitor what is happening in GSuite, has time to do so, and knows how to identify and escalate any security incidents or other concerns about abnormal usage.**
+*Situations will inevitably arise where a broadly accessible link is necessary (for example, if your external collaborator does not have a Google account, or you want to cast a wide net for feedback). Be sure to consider the sensitivity of the document in these situations, and, when you choose to share this way, watch out for accidentally making a file public--be sure to choose "anyone with the link" instead. You should also train users set an expiration date on shared links, even if it is far in the future. This will ensure that the file or folder in question eventually becomes unshared. Last but not least, it is important to choose the most limited permissions appropriate -- allowing people with the link to only view or comment on a file if they do not need to change its contents.*
+
+:heavy_check_mark: **Make sure someone is assigned to regularly monitor what is happening in G Suite, has time to do so, and knows how to identify and escalate any security incidents or other concerns about abnormal usage.**
:rocket::rocket::wrench::wrench::fire:
-*Reporting on what is happening with your organizational tools and information over time this is an important security practice. This is true for all tools, and an advantage of GSuite is that it makes this kind of reporting more accessible than in other tools. You want one individual or a team tasked with this ongoing monitoring, even if it's an external tech support provider, so that problems are caught quickly. Monitoring should be done on a schedule, no less than a monthly and preferably more often. To sustain this practice, it is essential that the person, team, or external provider is assigned this task via their workplan or scope of work. The goal of monitoring is to find unusual behavior such as sudden growth in file sets or email activity, so the responsible party should first establish a baseline of normal activity and then look for trends outside of that baseline. Any questionable activity should be investigated with the users whose accounts are involved, or escalated to a tech support professional.*
-*Activity Reports are available inside the administrative console including use of two-factor authentication, external apps installed, emails sent/received and file activity in Google Drive. An article describing these basic reports is at https://support.google.com/a/answer/4580176. A broader explanation of all the reporting available to you in GSuite can be found at https://support.google.com/a/answer/6000239.*
-*In addition to this activity monitoring, it is important to regularly review the security settings of your users, especially password strength for any users not enrolled in two-factor authentication, as described here: https://support.google.com/a/answer/2537800#password. Google is continually updating their password-strength rating system in response to leaked passwords and other emerging threats, so a password that is judged strong one week may be judged weak the next. (This is less important for users with two-factor authentication, because in those cases as their password is only half of what is needed to access their account.) When you see a weak password in your systems, it should be changed. If you have regular contact with the user in question, walking them through changing to a better password is the best option. If you don't have regular access or they don't use the systems regularly, you can reset the password (using these directions) so the account is protected, get them the new password and then proceed as above, helping them to change that password to something stronger. In the case of an account where you cannot get the user a new password (so reset isn't an option) but that is rarely used you can follow these directions to suspend the account and reenable it as needed: https://support.google.com/a/answer/33312?hl=en.*
+*Reporting on what is happening with your organizational tools and information over time is an important security practice. This is true for all tools, and an advantage of G Suite is that it makes this kind of reporting more accessible than in other tools. You want one individual or a team tasked with this ongoing monitoring, even if it's an external tech support provider, so that problems are caught quickly. Monitoring should be done on a schedule, no less than a monthly and preferably more often. To sustain this practice, it is essential that the person, team, or external provider is assigned this task via their workplan or scope of work. The goal of monitoring is to find unusual behavior, such as sudden growth in file sets or email activity, so the responsible party should first establish a baseline of normal activity and then look for trends outside of that baseline. Any questionable activity should be investigated with the users whose accounts are involved, or escalated to a tech support professional.*
+
+*Activity Reports are available inside the administrative console, including use of two-factor authentication, external apps installed, emails sent/received, and file activity in Google Drive. An article describing these basic reports is at https://support.google.com/a/answer/4580176. A broader explanation of all the reporting available to you in G Suite can be found at https://support.google.com/a/answer/6000239.*
+
+*In addition to this activity monitoring, it is important to regularly review the security settings of your users, especially password strength for any users not enrolled in two-factor authentication, as described here: https://support.google.com/a/answer/2537800#password. Google is continually updating their password-strength rating system in response to leaked passwords and other emerging threats, so a password that is judged strong one week may be judged weak the next. (This is less important for users with two-factor authentication, because in those cases as their password is only half of what is needed to access their account.) When you see a weak password in your systems, it should be changed. If you have regular contact with the user in question, walking them through changing to a better password is the best option. If you don't have regular access or they don't use the systems regularly, you can reset the password (using these directions: https://support.google.com/a/answer/33319?hl=en) so the account is protected and communicate the new password to them via a secure channel; if you don't have a secure channel through which to give them their new password, you can reset the password and let them know that they should go through the "forgot password" process the next time they need to log in (be sure to follow up to make sure the new password they choose is strong enough). If appropriate to your operations and the frequency of their use of the account, you can also suspend the account and reenable it as needed (https://support.google.com/a/answer/33312?hl=en).*
-:heavy_check_mark: **Train users not to check the "Don't ask again on this computer" checkbox when using public or other untrusted computers, to logout after using such computers, and to untrust computers that are lost, stolen or otherwise compromised.**
+:heavy_check_mark: **Train users not to check the "Don't ask again on this computer" checkbox when using public or other untrusted computers, to logout after using such computers, and to untrust computers that are lost, stolen, or otherwise compromised.**
:rocket::wrench::fire:
-*This practice will help ensure that all your other efforts to create high barriers to accessing your information are successful. When a user checks the "Don't ask again on this computer" box when logging into GSuite with two-factor authentication, they are telling Google not to ask for a password or second factor for 30 days. In the case of a poorly managed (i.e. not regularly cleaned or reset) computer in a library, Internet cafe, or other public place, this leaves an account wide open to abuse during that period. Though Google will prompt again for password changes and other sensitive actions, that computer retains the ability to access account information, send emails, and read and edit documents. Trusted computers can always be reviewed, or the trust revoked, within a user's account settings as detailed here: https://support.google.com/accounts/answer/2544838.
+*This practice will help ensure that all your other efforts to create high barriers to accessing your information are successful. When a user checks the "Don't ask again on this computer" box when logging into G Suite with two-factor authentication, they are telling Google not to ask for a password or second factor for 30 days. In the case of a poorly managed (i.e. not regularly cleaned or reset) computer in a library, Internet café, or other public place, this leaves an account wide open to abuse during that period. Though Google will prompt again for password changes and other sensitive actions, that computer retains the ability to access account information, send emails, and read and edit documents. Trusted computers can always be reviewed, or the trust revoked, within a user's account settings as detailed here: https://support.google.com/accounts/answer/2544838.*
-:heavy_check_mark: **Install Chrome on all staff computers and set it as the default web browser. Make sure staff know how to keep it updated and that they use Chrome instead of other browsers whenever they are using GSuite tools.**
+:heavy_check_mark: **Install Chrome on all staff computers and set it as the default web browser. Make sure staff know how to keep it updated and that they use Chrome instead of other browsers whenever they are using G Suite tools.**
:rocket::rocket::wrench::wrench::fire:
-*This practice will help you have strong security between your web browser and GSuite. Because Google controls both things, they have a lot of ways to verify that your connection is well-secured and that newer features like two-factor authentication work wely; they can also push out corrected software if they have a security incident in their infrastructure. Generally Chrome will self-update, but you should teach your staff how to recognize when an update is available (as described here: https://support.google.com/chrome/answer/95414). Quitting and reopening the browser will allow it to update to the latest, most secure version.*
+*This practice will help you have strong security between your web browser and G Suite. Because Google controls both things, they have a lot of ways to verify that your connection is well-secured and that newer features like two-factor authentication work well; they can also push out corrected software if they have a security incident in their infrastructure. Generally Chrome will self-update, but you should teach your staff how to recognize when an update is available (as described here: https://support.google.com/chrome/answer/95414). Quitting and reopening the browser will allow it to update to the latest, most secure version.*