As a disclaimer, this blog is intended to address just Microsoft based systems and environments, with a focus on Office 365 Government Community Cloud High (GCC High). This is not a complete approach but an overview of capabilities and functionality available to assist in your overall approach.
It's important to start with identity management in Office 365 Government Community Cloud High (O365 GCCH). The core of identity management and authentication in O365 GCCH is Azure Active Directory (AAD), and O365 GCCH is built in Microsoft's Azure Government infrastructure. As confusing as it may be, when you are purchasing Office 365, you are also investing in Azure. The beauty of this, however, is that you can begin to have unified identity and authentication across your IaaS and SaaS solutions. The other benefit to having an underlying Azure Government infrastructure is it is natively suited for DFARS compliance (namely paragraphs c-g) and hosting ITAR data.
You can continue to use another on premises active directory or identity solution in a hybrid scenario by leveraging AD Federated Services (AD FS) or Azure AD Connect. Nevertheless, I will mainly address the functionality provided by your Office 365 GCC High licensing that helps address the 3.5 Control Family.
Within NIST 800-171, the 3.5 Control Family addresses the identification and authentication practices of users, actions conducted as a user (in the instance of automation/workflows for example), and devices. This is plainly stated in the "Basic Security Requirements" of 3.5.1 and 3.5.2:
Basic Security Requirements
3.5.1 Identify system users, processes acting on behalf of users, and devices.
As a part of your initial entry into Office 365, you will be establishing your Azure Active Directory instance or synchronizing with an on premises active directory. Either way - authority is established or reestablished to identify system users. Additionally, we advise that you enroll managed devices as part of your first steps if you haven't already.
Nevertheless, Azure Active Directory and it associated security products will track all login attempts (successful or not), user activities (including process activities on behalf of users), devices used by each user to access cloud systems, and any changes to a user account. Device identifiers,IP addresses, device operating systems, and more are included in the information tracked in AAD. Moreover, AAD Identity Protection will detect vulnerabilities and suspicious actions, as well as provide a method to investigate odd authentication activity.
This requirement is naturally addressed by Azure Active Directory, but the challenge comes in synchronizing with or migrating from previous active directory instances on premises.
3.5.2 Authenticate (or verify) the identities of users, processes, or devices, as a prerequisite to allowing access to organizational systems.
A user cannot access Exchange (Outlook), SharePoint, OneDrive, Word Online, Teams, and the long list of other places CUI can be stored or accessed in Office 365 without first authenticating via Azure Active Directory. No matter what SaaS product or application in Office 365 being accessed, authentication occurs first. Additionally, as you read in the subsequent derived requirements, Multifactor Authentication (MFA) is a critical component to truly "verify" identity.
Derived Security Requirements
3.5.3 Use multifactor authentication for local and network access to privileged accounts and for network access to non-privileged accounts.
NIST and the vast majority of the security community define multi factor as something you know, something you have, and/or something you are. For example, you know your username/password combination, possess a mobile device, and have a fingerprint (biometrics) that identifies who you are. Facial recognition is a relatively easier method to circumvent or manipulate, and a PIN can be more useful.
Users accessing Office 365 and its consortium of applications and data sources will be considered a "privileged account" or "non-privileged account" using "network access" because the user will be using a network to access the system(s). This definition is also assuming that the contractor is accessing, storing, and/or transmitting CUI/CDI via Exchange, SharePoint, and the like.
Office 365 GCC High thankfully provides native Multifactor Authentication (MFA); however, it is not turned on by default. MFA is available for all O365 enterprise license types across all user roles and advanced MFA options are available with Enterprise Mobility + Security (EMS). It is also important to note that what is actually created behind the scenes are Azure AD MFA policies. To simplify, though, we will stick with the O365 MFA moniker.
With O365 MFA we can establish policies with the following authentication methods:
- Mobile app notification (and wearable applications, such as Microsoft's Authenticator app on the Apple Watch)
- Mobile app verification code
- Phone call
- One-way SMS
- Hardware Tokens
- and more to come
These methods can also be customized to some extent and enhanced with additional configurations in the Security and Compliance Center. One nice feature is Conditional Access, which can stop logins from certain locations, devices, and other parameters.
There is one gap of sorts to be aware of. Office 365's MFA product does not extend to the device, meaning a user does not authenticate by more than one factor on their machine (computer) unless there is a 3rd party tool installed on the device. This is something Microsoft intends to address and is on the roadmap. MFA will go the similar route of Advanced Threat Protection (ATP) and eventually include a Windows product. Certain Microsoft licensing includes Azure ATP, O365 ATP, and Windows Defender ATP; and these products compliment one another to address threat vectors across systems and devices. MFA will eventually cover similar ground.
Many of the government contractors we interact with are considering or implementing 3rd party tools to extend MFA to the device: Duo, RSA, YubiKey, Okta, and others, Office 365 GCC High can be integrated with these products to allow a synchronized authentication experience for users, but it does require a certain level of expertise and elbow grease to make it work. If you'd like to discuss this further and wouldn't mind some help integrating Duo, Jamf, RSA, YubiKey, and Okta into your security and compliance approach, give us a shout.
3.5.4 Employ replay-resistant authentication mechanisms for network access to privileged and non- privileged accounts.
Replay resistance is defined by NIST as - "Protection against the capture of transmitted authentication or access control information and its subsequent retransmission with the intent of producing an unauthorized effect or gaining unauthorized access."
Replay attacks are thwarted first and foremost by MFA, and I don't believe this control follows the MFA requirement in 3.5.3 by coincidence. If an individual were to possess a user's ID and password, they still would not authenticate because they would not have access to the user's mobile device (for MFA via the Authenticator app). Additionally, Office 365 authentication uses a traditional challenge-response, and authentication traffic over the network is always encrypted with TLS/SSL (some implementation required).
Here comes the rub. TLS, Kerberos, MFA, and more are native technologies to Office 365; however, they need to be implemented and configured respectively. Also, one of the most powerful tools to meet 3.5.4 in your cloud environment is AAD Conditional Access, and it is not a quick setup. Conditional Access (CA) can serve as the final line of defense in the event of a compromised credential, compromised device, or lost device.
You can create separate CA policies for privileged and non-privileged accounts based upon several conditions: sign-in risk (calculated by Microsoft), device platform (Windows, iOS, Android, etc), device state (managed or unmanaged), and locations (where is someone logging in from).
3.5.5 Prevent reuse of identifiers for a defined period.
With proper Azure Active Directory configuration, licenses can be reassigned to individuals as the company sees fit; however, usernames and other identifiers will remain unique to an individual. AAD uses a database logic by default for most things. For example, if a username or group name is used/taken, then a new user cannot be created (a new row created) with an identical username (primary key). After users are deleted, a default hold can be placed on the username for a "defined period".
3.5.6 Disable identifiers after a defined period of inactivity.
This particular requirement does not have a baked in solution in Azure Active Directory or Office 365. Yet, this requirement can be easily met with an Azure Function running a PowerShell script to find inactive users and block them on a regular basis. "Inactive" and "regular basis" can be defined within the script.
SharePoint Online also has functionality to block access after certain levels of inactivity, but it does not reach beyond SharePoint. You can also run PowerShell to turn on auditing for Exchange Online. There to, this only covers one workload in Office 365.
3.5.7 Enforce a minimum password complexity and change of characters when new passwords are created.
"Minimum" is determined by your organization. The minimum set forth by Microsoft in Office 365 can be adopted as your minimum. Azure AD in a cloud only scenario requires 8-16 character passwords that require three of four character types: lowercase, uppercase, numbers, and symbols. If you have a hybrid AD environment (over 80% of our clients do) using something like AAD Connect, then you have more flexibility to increase the level of complexity beyond the cloud defaults.
Another capability in Office 365 (Azure AD) is the ability to create a custom banned password list (currently in preview) that will prohibit certain words from being used. A good example of this would be prohibiting users from using the company name within a password. There are also globally banned words, such as 'password', that Microsoft blocks for you.
Lastly, let's not forget devices and containers that could store and transmit CUI/CDI/ITAR data. We suggest companies use Microsoft Intune to extend password requirements to devices. Mobile Device Management (MDM) policies can apply the minimum complexity to access data stored on the device, and then Mobile Application Management (MAM) can take things a step further and require a PIN to open particular applications.
3.5.8 Prohibit password reuse for a specified number of generations.
The default password reuse policies for Office 365 (AAD) prohibit the user from using the previous password - 1 generation - when changing it. This technically meets this requirement, but you can extend this "specified number" by using a hybrid AD environment using AAD Connect. The policies you set in your on premises instance will supersede and precede your cloud policy.
Outside the scope of Office 365 somewhat, you can also create enterprise-wide Window 10 policies for enrolled machines via the AAD portal and Intune policies for mobile device password reuse.
3.5.9 Allow temporary password use for system logons with an immediate change to a permanent password.
This can be achieved through standard username and password reset capabilities within the respective Office 365 and the Azure AD admin centers. When resetting a user's password in Office 365 (see below), the admin can set the process to force a password change "when they first sign in". This will immediately change the temporary password to a permanent password. Additionally, password expiration policies can limit temporary passwords from hanging in limbo if for some reason a user fails to respond to the reset prompting.
3.5.10 Store and transmit only cryptographically-protected passwords.
Passwords stored in Azure Active Directory are a result of one-way cryptographic hash and salted. The most common way this is accomplished in a synchronized hybrid state is with Azure Active Directory Connect.
3.5.11 Obscure feedback of authentication information.
Office 365 natively obscures password entry with asterisks or dots. This experience is the same across web applications and local applications installed on a device or machine.
Wrapping It All Up
For additional details and background on the referenced data points and releases, subscribe to our blog and don't hesitate to reach out. This blog is one of many to come addressing each control family in NIST 800-171 with an overview of capabilities in Office 365 GCC High. We also hope to partner each of these with a video for those that dislike reading or want the general overview. Shoot us questions if you need specifics or further explanations.