FedRAMP SSP Appendix A: Security Controls

FedRAMP^® System

Security Plan (SSP)

Appendix A: High

FedRAMP Security

Controls

for Microsoft

Office

365 Multi-Tenant & Supporting Services

Version 12.2

08/21/2024

Controlled

Unclassified Informationinfo@fedramp.gov

fedramp.gov

Responsible Role:

Customer Administrator, M365 Trust Program Manager, Program Manager

Parameter AC-01(a):

all personnel

Parameter AC-01(a)(1):

organization-level

Parameter

AC-01(b): Appropriate service team

personnel, security engineering teams, service provider personnel with

authority on access control policies

Parameter

AC-01(c)(1)-1: at least annually

Parameter

AC-01(c)(1)-2: significant changes

Parameter

AC-01(c)(2)-1: at least annually

Parameter

AC-01(c)(2)-2: significant changes

Implementation Status

(check all that apply):

☒ Implemented

☐ Partially implemented

☐ Planned

☐ Alternative implementation

☐ Not applicable

Control Origination

(check all that apply):

☐ Service Provider Corporate

☐ Service Provider System Specific

☐ Service Provider Hybrid (Corporate and System Specific)

☐ Configured by Customer (Customer System Specific)

☐ Provided by Customer (Customer System Specific)

☒ Shared (Service Provider and Customer Responsibility)

☐ Inherited from pre-existing authorization

Part a

_{Customer Responsibility

}_

Government customers are responsible for developing and maintaining

appropriate Access Control policies and procedures that govern access

management activities for their organization and users.

Customers are responsible for setting access control policies that support

the confidentiality of stored content. For example, sensitive documents

stored in SharePoint should not be shared outside of the M365 boundary, and

sensitive email should be sent using encryption.

For more information, see

<https://learn.microsoft.com/en-us/sharepoint/external-sharing-overview>

and

<https://learn.microsoft.com/en-us/microsoft-365/compliance/email-encryption?view=o365-worldwide>.

_{M365

}_

Part 1

The "M365 Information Security Policy" provides the overarching

security guidance for M365. This document addresses the purpose, scope,

roles, responsibilities, compliance requirements, and required coordination

among the various Microsoft organizations providing some level of support for

the security of M365. Policies are distributed via SharePoint to personnel

responsible for implementing access control policies and procedures.

Part 2

Standards and procedures to facilitate execution of the M365 Information

Security Policy are documented in the M365 SOPs and service team-specific

SOPs. These standards and procedures act as adjuncts to the security policy

and provide implementation level requirements and details to carry out

specific operational tasks. A detailed mapping of M365 SOPs are distributed

via SharePoint to roles providing support for M365 security.

Part b

_{Customer Responsibility

}_

Government customers are responsible for designating an organization-defined

official to manage the development, documentation, and dissemination of their

organization's access control policy and procedures.

_{M365

}_

The "M365 Information Security Policy" provides the overarching

security guidance for M365. This document addresses the purpose, scope,

roles, responsibilities, compliance requirements, and required coordination

among the various Microsoft organizations providing some level of support for

the security of M365. Policies are distributed to personnel responsible for

implementing access control policies and procedures via SharePoint.

The "M365 Information Security Policy" is reviewed and updated

annually.

Part c

_{Customer Responsibility

}_

Government customers are responsible for annually updating their Access

Control policies and procedures.

_{M365

}_

Part 1

The M365 Information Security Policy is reviewed and updated at least

annually or whenever a significant change occurs.

Part 2

The "M365 Information Security Policy" and AC SOP are reviewed and

updated at least annually or whenever a significant change occurs.

Responsible Role:

Customer Administrator, M365 Trust Program Manager, Program Manager

Parameter AC-02(c):

IDM eligibilities

Parameter AC-02(d)(3):

RBAC

Parameter AC-02(e):

Service Team Manager or Eligibility Owner

Parameter AC-02(f):

Microsoft M365 Information Security Policy

Parameter AC-02(h):

relevant security group members

Parameter AC-02(h)(1):

twenty-four (24) hours

Parameter AC-02(h)(2):

eight (8) hours

Parameter AC-02(h)(3):

eight (8) hours

Parameter AC-02(i)(3):

security group membership

Parameter AC-02(j):

monthly for privileged accessed, every six (6) months for non-privileged

access

Implementation Status

(check all that apply):

☒ Implemented

☐ Partially implemented

☐ Planned

☐ Alternative implementation

☐ Not applicable

Control Origination

(check all that apply):

☐ Service Provider Corporate

☐ Service Provider System Specific

☐ Service Provider Hybrid (Corporate and System Specific)

☐ Configured by Customer (Customer System Specific)

☐ Provided by Customer (Customer System Specific)

☒ Shared (Service Provider and Customer Responsibility)

☒ Inherited from pre-existing authorization for Azure Government

(F1603087869), 4/17/2020

Part a

_{Customer Responsibility

}_

All customers, including government and non-government customers, are

responsible for identifying the account types for their organization in

compliance with their organizational policies. Customers will configure their

account types in their existing Active Directory infrastructure or they will

configure account types in AAD.

Non-government customers will configure account types in AAD via SUE. For

more information on managing customer account types via the M365 Admin Center,

see the following link:

<https://learn.microsoft.com/en-us/microsoft-365/admin/m365-feature-descriptions>.

Guest access to MSTeams meetings, if enabled, allows anyone with a meeting

invite to access the meeting lobby; this method of guest access is considered

session access as no account is assigned to the guest user. The meeting

organizer is responsible for establishing the identity of lobby participants

before granting them access to the meeting. Government customers are

responsible for disabling guest access to MSTeams meetings to remain

compliant with FedRAMP standards as advised in "M365 Complementary

Federal User Entity Control".

Non-government customers are responsible for determining if the use of guest

access to MSTeams meetings should be allowed for their organization. This

setting can be configured by government and non-government customers.

SharePoint Online guest invitations allow external users to access an

organization's SharePoint Online site(s). Government and non-government

customers are responsible for determining if the use of guest access to

SharePoint Online, as an account type, should be allowed for their

organization. Government customers are responsible for disabling guest access

to SharePoint Online to remain compliant with FedRAMP standards. The setting

to allow or disallow guest access to SharePoint Online can be configured by

government and non-government customers.

For more information, see the Microsoft 365 Solution and Architecture Center:

<https://learn.microsoft.com/en-us/microsoft-365/solutions>

_{M365

}_

M365 accounts are only provided to Microsoft personnel supporting M365

services. Accounts with permissions to internal assets and resources are not

provisioned to customers. Microsoft personnel are assigned unique corporate

network (CorpNet) AD accounts as part of a standard onboarding to Microsoft.

These CorpNet accounts, known as user alias', do not have access to any

production environment by default.

For personnel supporting M365 services, service team accounts are used to

manage and administer M365. Service team accounts tie to the user's CorpNet

account. This alias is consistent across all of the user's accounts in all

Microsoft domains, including M365. CorpNet and M365 access are provisioned

and managed using separate account management tools.

Below are the different account types that M365 utilizes:

Standard Access

All personnel with standard access to M365 are granted system metadata read

access used for regular troubleshooting, release management, and other maintenance

and monitoring activities. Standard access provides permissions to key M365

tools, services, SharePoint sites, documentation, and a variety of

dashboards.

Standard access does not provide access into the production environment. A

user with standard access may have the need to review service-specific logs

within M365 to identify and diagnose issues. Any additional permissions above

standard access requires elevation of access via Torus JIT, described below.

Elevated Access

All personnel must use JIT when interactive elevated access is required in

the M365 production environment. Except in the case of an approved exception

as described below, there is no standing or persistent elevated access to the

production environment. The primary exception is Break-Glass elevated access,

described below.

In scenarios where JIT does not yet support management of elevated access,

standing access may exist; these gaps in JIT support are identified and

tracked as an exception, which requires approval. Software deployment via

automated means (i.e., not using an interactive login) does not require

interactive login to a resource that is accessed via JIT. In this case, a

service team member submits a job (e.g., Pull Request in Azure DevOps), and

another team member reviews, approves, and then the safe deployment system

deploys.

Elevated Access – Break-Glass Access

M365 maintains Break-Glass accounts with elevated access for use in the

scenario that the JIT service is not available. These accounts have

persistent elevated access to perform maintenance activities if JIT is unable

to provide temporary elevated access. These accounts are carefully managed,

only to be used in emergencies, and have notifications associated with their

use. Whenever such an account is utilized, a Severity 2 incident ticket is

generated that requires the service that owns the resource to investigate and

determine whether the access is valid.

Service Accounts

Non-user, non-interactive service accounts are used to run relevant services.

Service accounts are not used for interactive logins. For example, software

deployment via automated means does not require interactive login to a

resource that would normally be accessed via JIT. In this example, a service

team member submits a job, such as a Pull Request in Azure DevOps, and

another team member reviews and approves.

Part b

_{Customer Responsibility

}_

All customers, including government and non-government customers, are

responsible for assigning account managers for the account types identified

in part a of this control.

_{M365

}_

M365 assigns account managers to each role type using IDM, which include

workflows that enforce business rules. Throughout this SSP, these tools are

collectively referenced as "account management tools".

Part c

_{Customer Responsibility

}_

All customers, including government and non-government customers, are

responsible for establishing conditions for group/role membership for their

organization in compliance with their organizational policies.

Non-government customers will configure groups in AAD via SUE. For more

information on managing customer groups/roles in AAD via the SUE portal, see

the following link:

<https://learn.microsoft.com/en-us/microsoft-365/admin/m365-feature-descriptions>.

_{M365

}_

Service teams establish conditions for group/role membership by defining and

enforcing conditions for each group/role in account management tools. In

addition, service teams use Torus and IDM to enforce additional, more

granular conditions for privilege escalation and approval for interactive

sessions.

M365 establishes conditions for group and role membership based on least

privilege necessary for a user to perform their assigned duties.

Predetermined conditions are established when groups are created.

Part d

_{Customer Responsibility

}_

Part 1, 2, 3

Government and non-government customers are responsible for identifying

organizationally authorized users and specifying access privileges for those

users using their existing Active Directory (AD) infrastructure. These users

utilize the customer AD infrastructure to identify, authenticate, and apply

permissions to that user's session. Customers communicate

identification/authentication and the associated permissions to AAD via

certificate-based authentication.

For more information on managing user accounts in AD, see the following link:

<https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/understand-default-user-accounts>

Non-government customers will manage user accounts in AAD via SUE. For these

customers, AAD is responsible for identifying organizationally authorized

users and will enforce the access privileges defined by the customer. For

more information on managing customer user identifiers and specifying access

privileges in AAD via the SUE portal, see the following link:

<https://learn.microsoft.com/en-us/microsoft-365/admin/m365-feature-descriptions>.

_{M365

}_

Part 1, 2, 3

Role Based Access Control (RBAC) is used to identify and control the access

privileges of each service team personnel Service teams define their roles in

IDM which contain a list of eligibilities. Eligibilities vary depending on

the role that a specified service team personnel will assume within the

service team. Privileges are defined in the eligibilities and enforced by

Active Directory.

By default, these service team accounts initially belong to a security group

that has remote system metadata read access, and no direct access to the

production environment. If service team personnel need additional access to

the production environment, they request that access and provide business

justification using Just-In-Time (JIT) tools.

Part e

_{Customer Responsibility

}_

All customers, including government and non-government customers, are

responsible for requiring appropriate approvals for requests to establish

organizational accounts in compliance with their organizational policies.

Government and non-government customers will manage their accounts in their

existing Active Directory infrastructure.

Non-government customers will configure account types in AAD via SUE. For

more information on managing customer account types via the M365 Admin

Center, see the following link:

<https://learn.microsoft.com/en-us/microsoft-365/admin/m365-feature-descriptions>.

_{M365

}_

In order to gain access to the production environment, service team personnel

must first request access via the account management tools; access to the

production environment is provided via security group membership. Approval to

establish the account from the service team's management is required for a

service team administrator to be added to the appropriate security group.

These approvals are tracked and enforced by account management tools.

Part f

_{Customer Responsibility

}_

Government customers are responsible for establishing, activating, modifying,

disabling, and removing organizational accounts in accordance with their

procedures using their AD infrastructure. Government users utilize the

government AD infrastructure to identify, authenticate, and apply permissions

to that user's session. Government users communicate

identification/authentication, and the associated permissions to AAD via

certificate-based authentication.

For more information on managing user accounts in Active Directory (AD), see

the following link:

<https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/understand-default-user-accounts>

Non-government customers establish, activate, modify, disable, and remove

organizational accounts following the same procedures outlined for government

customers. Non-government customers manage user accounts in AAD via SUE.

For more information on managing customer accounts via the SUE portal, see

the following link: <https://learn.microsoft.com/en-us/microsoft-365/admin/m365-feature-descriptions>

_{M365

}_

Account changes are managed through IDM in accordance with M365 Standard

Operating Procedures (SOP) The M365 Information Security Policy and rules

have been defined in account management tools which provide an automated

workflow that allows service teams to track account requests, approvals,

creations, modifications, and deletions. Service team managers are

responsible for approving account lifecycle events in account management

tools, ensuring that M365 establishes, activates, modifies, disables, and

removes accounts appropriately.

Part g

_{Customer Responsibility

}_

Government customers are responsible for monitoring the use of information

system accounts managed by their AD. See AU-2, AU-3, AU-6, and SI-4 for more

details about these responsibilities.

_{M365

}_

M365 monitors the use of information system accounts in accordance with the

AU family of security controls. M365 records the auditable events defined in

AU-2 with the content defined in AU-3 and monitors those records in

accordance with the control descriptions for AU-6 and SI-4.

Part h

_{Customer Responsibility

}_

Part 1, 2, 3

Government and non-government customers are responsible for implementing

processes to notify customer account managers when accounts are no longer

required, when users are terminated or transferred, or when individual

information system usage or need-to-know changes.

_{M365

}_

Part 1, 2, 3

M365 uses automated workflow account management tools that allow service

teams to track the account management process through account request,

approval, creation, modification, and deletion. As changes occur, the

corresponding account manager is notified of the changes that require their

approval. Information system usage and need-to-know are mapped to the roles

defined by each service team. When an employee is transferred or their

employment is terminated, the account management tools will automatically

revoke the associated account's access to the privileges mapped to their

previous role.

Part i

_{Customer Responsibility

}_

Part 1, 2, 3

Government customers are responsible for managing organizational user

accounts by granting access to M365 based on: a valid access authorization;

intended system usage; and other attributes as required by the organization

or associated missions/business functions using their AD infrastructure.

Government users utilize the government AD infrastructure to identify,

authenticate, and apply permissions to that user's session. Government users

communicate identification/authentication, and the associated permissions to

AAD via certificate-based authentication.

For more information on managing user accounts in AD, see the following link:

<https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/understand-default-user-accounts>

Non-government customers can manage organizational user accounts by granting

access to M365 based on: a valid access authorization; intended system usage;

and other attributes as required by the organization or associated

missions/business functions following the same procedures outlined for

government customers, or they can elect to manage user accounts in AAD via

SUE.

For more information on managing customer accounts via the SUE portal, see

the following link:

<https://learn.microsoft.com/en-us/microsoft-365/admin/m365-feature-descriptions>

_{M365

}_

Part 1, 2, 3

M365 Membership in security groups that give access to the system is given

only to those in specific roles that require system access. Service team

managers are responsible for approving group membership. Service team

personnel with the access approver role then review and approve or deny the

type of access requested. Access is only provided for a finite period of time

(no more than 24 hours) based on the expected duration of the work to be

performed. If access is approved, Torus assigns the service team personnel to

eligibilities with the minimum permissions required to perform the work and

automatically revokes permissions at the end of the specified time period.

The managers validate the eligibilities requested and justification provided

and grant access once validated.

Part j

_{Customer Responsibility

}_

M365 Customers are responsible for reviewing the accounts of their

organization's users in compliance with their organizational policies. M365

allows for customers to manage/review their user accounts via SUE.

For more information on managing user accounts in AD, see the following link:

<https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/understand-default-user-accounts>

Non-government customers may manage accounts in Azure Active Directory via

the Suite User Experience (SUE) portal. Customers are responsible for logging

into the portal and reviewing the M365 MT accounts of their users compliant

with their organizational policies. Disabling or removing users in the SUE

portal revokes access to M365 MT for the affected users.

For more information on managing user accounts via the SUE portal, see the

following link:

<https://learn.microsoft.com/en-us/microsoft-365/admin/m365-feature-descriptions>

_{M365

}_

The M365 service teams review service team administrator accounts at least

monthly.

Access is based on specific roles and duties to support the operational

environments. The foundation is granting elevated access for a limited

duration through JIT not to exceed twenty-four (24) hours; and a formal

program that monitors account activities enabled by auditing account

management actions. This provides ongoing review of accounts and alerts of

changes. The objective is a continuous rather than static review of access

authorizations and activities.

Part k

_{Customer Responsibility

}_

If government customers allow the use of group shared customer accounts, they

are responsible for terminating group/shared account credentials when

individuals leave the group.

Non-government customers will terminate credentials using SUE.

_{M365

}_

M365 does not allow the use of shared/group service team accounts.

Part l

_{Customer Responsibility

}_

Government customers are responsible for aligning account management

processes with personnel termination and transfer processes within their

organization.

_{M365

}_

Torus performs a full sync with the Human Resources Information System (HRIS)

every 4 hours as well as differential syncs in near-real time. Syncs between

these account management tools will revoke account access if the account no

longer meets requirements for access; this could be for: inactivity,

background check, clearance, EUPI attestation, or when an employee is

transferred or their employment is terminated.

Responsible Role:

Customer Administrator, M365 Security Manager, M365 Trust Program Manager,

Program Manager

Parameter AC-02(01):

IDM, MyAccess

Implementation Status

(check all that apply):

☒ Implemented

☐ Partially implemented

☐ Planned

☐ Alternative implementation

☐ Not applicable

Control Origination

(check all that apply):

☐ Service Provider Corporate

☐ Service Provider System Specific

☐ Service Provider Hybrid (Corporate and System Specific)

☐ Configured by Customer (Customer System Specific)

☐ Provided by Customer (Customer System Specific)

☒ Shared (Service Provider and Customer Responsibility)

☐ Inherited from pre-existing authorization

_{Customer Responsibility

}_

Government customers are responsible for automatically terminating temporary

and emergency government customer accounts, in compliance with their

organizational policies, using their Active Directory (AD) infrastructure (no

more than 30 days for FedRAMP compliance).

Government customers are responsible for employing their Active Directory

(AD) infrastructure as automated mechanisms to support their organizational

user accounts. Certificate-based authentication (CBA) is available to

Government users to communicate identification/authentication and the

associated permissions to AAD.

For information regarding how to manage user accounts in AD, see the

following link:

<https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/understand-default-user-accounts>.

Non-government customers can employ AD as an automated mechanism following

the same procedures outlined for government customers, or they can elect to

manage user accounts in AAD via SUE. For customers, AAD is employed as an

automated mechanism to support their organizational user accounts.

For more information on managing customer accounts via the SUE portal, see

the following link:

<https://learn.microsoft.com/en-us/microsoft-365/admin/m365-feature-descriptions>.

_{M365

}_

IDM is an automated workflow management tool that allows service teams to

manage service team administrator and service accounts through account

request, approval, creation, modification, and deletion. IDM integrates with

Microsoft Online Directory Service (MSODS) to provide identity

synchronization, certificate management, service team administrator password

resets and service team administrator provisioning from a single interface.

Service team managers are responsible for approving requests in IDM.

By default, service team AD accounts belong to a security group that only has

read access to the production environment. Additionally, if a service team

administrator needs elevated privileges to the production environment, they

request that access, providing a business justification using Torus and IDM.

A service team administrator with the access approver role then reviews and

approves or denies the type of access requested. Access is only provided for

a finite period of time based on the expected duration of the work to be performed.

If access is approved, Torus and IDM assign the service team administrator to

security groups with the minimum permissions required to perform the work and

automatically revokes permissions at the end of the specified time period.

Falcon, ObjectStore, and SCS also use MyAccess to manage security groups,

which are used to gain access to Azure PaaS services, Source Depot, and

configuration files.

Responsible Role:

Customer Administrator, M365 Security Manager, M365 Trust Program Manager,

Service Engineer Operations

Parameter AC-02(02)-1:

Disables

Parameter AC-02(02)-2:

no more than twenty-four (24) hours from last use

Implementation Status

(check all that apply):

☒ Implemented

☐ Partially implemented

☐ Planned

☐ Alternative implementation

☐ Not applicable

Control Origination

(check all that apply):

☐ Service Provider Corporate

☐ Service Provider System Specific

☐ Service Provider Hybrid (Corporate and System Specific)

☐ Configured by Customer (Customer System Specific)

☐ Provided by Customer (Customer System Specific)

☒ Shared (Service Provider and Customer Responsibility)

☐ Inherited from pre-existing authorization

_{Customer Responsibility

}_

Government customers are responsible for automatically terminating temporary

and emergency government customer accounts, in compliance with their

organizational policies, using their Active Directory (AD) infrastructure

(within 24 hours for FedRAMP compliance). Government users communicate

identification/authentication and the associated permissions to AAD via

certificate-based authentication.

For information regarding how to manage user accounts in AD, see the

following link: <https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/understand-default-user-accounts>.

Non-government customers can manage terminating temporary and emergency

accounts following the same procedures outlined for government customers, or

they can elect to manage user accounts in AAD via SUE. For customers using

AAD the process for terminating temporary and emergency accounts will be

manual.

For more information on managing accounts via the SUE portal, see:

<https://learn.microsoft.com/en-us/microsoft-365/admin/m365-feature-descriptions?view=o365-worldwide&tabs=User-account-management>.

_{M365

}_

The Microsoft Security Program Policy (MSPP) prohibits the use of temporary

and emergency accounts. All local guest accounts are disabled on the system

or platform wherever they are located. All account requests follow the

standard account management process.

For servers that are not domain-joined, the JIT process for granting access

to a server includes creating and enabling a local account for the duration

of access. JIT sessions are task-based and have a default TTL of 4 hours and

cannot exceed 24 hours, as documented in AC-2(11). When the life of an

authenticator has ended, the service team member must re-request access, gain

approval, and generate a new authenticator. Because this access is tied to a

specific user’s domain account and requires that the user first authenticate

using multifactor authentication, M365 does not consider this local account

to be a temporary account for purposes of this control.

Responsible Role:

Customer Administrator, M365 Security Manager, M365 Trust Program Manager,

Service Engineer Operations

Parameter AC-02(03)-1:

twenty-four (24) hours for user accounts

Parameter

AC-02(03)(d): Thirty-five (35) days for user accounts (See additional

requirements and guidance.)

Implementation Status

(check all that apply):

☒ Implemented

☐ Partially implemented

☐ Planned

☐ Alternative implementation

☐ Not applicable

Control Origination

(check all that apply):

☐ Service Provider Corporate

☐ Service Provider System Specific

☐ Service Provider Hybrid (Corporate and System Specific)

☐ Configured by Customer (Customer System Specific)

☐ Provided by Customer (Customer System Specific)

☒ Shared (Service Provider and Customer Responsibility)

☐ Inherited from pre-existing authorization

Part a

_{Customer Responsibility

}_

Government customers are responsible for automatically disabling inactive

government customer accounts, in compliance with their organizational

policies, using their Active Directory (AD) infrastructure. Government users

communicate identification/authentication and the associated permissions to

AAD via certificate-based authentication.

For information regarding how to manage user accounts in AD, see the

following link: <https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/understand-default-user-accounts>.

_{M365

}_

Service team accounts are automatically disabled after their Torus session is

completed or expired. Torus sessions last no longer than 24 hours.

Part b

_{Customer Responsibility

}_

Government customers are responsible for automatically disabling inactive

government customer accounts, in compliance with their organizational

policies, using their Active Directory (AD) infrastructure. Government users

communicate identification/authentication and the associated permissions to

AAD via certificate-based authentication.

For information regarding how to manage user accounts in AD, see the

following link: <https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/understand-default-user-accounts>.

_{M365

}_

Service team accounts are automatically disabled after their Torus session is

completed or are no longer associated with an individual. Torus sessions last

no longer than 24 hours.

Part c

_{Customer Responsibility

}_

Government customers are responsible for automatically disabling inactive

government customer accounts, in compliance with their organizational

policies, using their Active Directory (AD) infrastructure. Government users

communicate identification/authentication and the associated permissions to

AAD via certificate-based authentication.

For information regarding how to manage user accounts in AD, see the

following link: <https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/understand-default-user-accounts>.

_{M365

}_

Service team accounts are automatically disabled when in violation of

organizational policy. Torus sessions last no longer than 24 hours.

Part d

_{Customer Responsibility

}_

Government customers are responsible for automatically disabling inactive

government customer accounts, in compliance with their organizational

policies, using their Active Directory (AD) infrastructure. Government users

communicate identification/authentication and the associated permissions to

AAD via certificate-based authentication.

For information regarding how to manage user accounts in AD, see the

following link: <https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/understand-default-user-accounts>.

_{M365

}_

Service team accounts are automatically disabled after their Torus session is

completed. Torus sessions last no longer than 24 hours.

Responsible Role:

Customer Administrator, M365 Security Manager, M365 Trust Program Manager,

Service Engineer Operations

Implementation Status

(check all that apply):

☒ Implemented

☐ Partially implemented

☐ Planned

☐ Alternative implementation

☐ Not applicable

Control Origination

(check all that apply):

☐ Service Provider Corporate

☐ Service Provider System Specific

☐ Service Provider Hybrid (Corporate and System Specific)

☐ Configured by Customer (Customer System Specific)

☐ Provided by Customer (Customer System Specific)

☒ Shared (Service Provider and Customer Responsibility)

☒ Inherited from pre-existing authorization for Azure Government

(F1603087869), 4/17/2020

_{Customer Responsibility

}_

Government customers are responsible for automatically disabling inactive

government customer accounts, in compliance with their organizational

policies, using their Active Directory (AD) infrastructure (no more than 35

days for DISA SRG compliance). Government users communicate

identification/authentication and the associated permissions to AAD via

certificate-based authentication.

For information regarding how to manage user accounts in Active Directory,

see the following link: <https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/understand-default-user-accounts>.

Government customers are responsible for monitoring the use of information

system accounts managed by their AD. See AU-2, AU-3, AU-6, and SI-4 for more

details about these responsibilities.

Non-government customers can audit account creation, modification, disabling,

and termination actions as well as notify appropriate individuals for change

to their organizational user accounts following the same procedures outlined

for government customers, or they can elect to manage user accounts in AAD

via SUE. For customers using AAD, audit records of account creation,

modification, disabling, and termination will be retained for 90 days; the

process for notifying appropriate individuals for change to their

organizational user accounts will be manual.

For more information on managing customer accounts via the SUE portal, see:

<https://learn.microsoft.com/en-us/microsoft-365/admin/m365-feature-descriptions?view=o365-worldwide&tabs=User-account-management>.

_{M365

}_

M365 performs automated auditing of privileged service team accounts through

account management tools, which provide a record of account creation,

modification, disabling, and termination of accounts. A notification is sent

to the account manager when accounts are changed or managed in any way.

Auditing of Azure Portal accounts is inherited from Azure. Azure performs

auditing of privileged user accounts through an event forwarding tool, which

provides a record of all changes made to accounts and notifies the Security

Incident Management (SIM) team for any suspicious activities. The account

management tools logs account creation, modification, and disablement

actions. Monitoring is in place to record all changes to accounts in the

Azure managed domains. Alerts are generated to the workflow ticketing tool if

anyone other than the members of the Online Services Security Accounts and

Access team or the account management tool service account modifies a user

account or security group in the Azure managed domains. Network device access

is audited via logs from the Azure managed CISCO ACS system.

Responsible Role:

Customer Administrator, M365 Trust Program Manager, Service Engineer

Operations

Parameter AC-02(05):

inactivity is anticipated to exceed Fifteen (15) minutes

Implementation Status

(check all that apply):

☒ Implemented

☐ Partially implemented

☐ Planned

☐ Alternative implementation

☐ Not applicable

Control Origination

(check all that apply):

☐ Service Provider Corporate

☐ Service Provider System Specific

☐ Service Provider Hybrid (Corporate and System Specific)

☐ Configured by Customer (Customer System Specific)

☐ Provided by Customer (Customer System Specific)

☒ Shared (Service Provider and Customer Responsibility)

☐ Inherited from pre-existing authorization

_{Customer Responsibility

}_

Government customers are responsible for identifying and implementing their

own requirements for expected inactivity or scenarios where government

personnel are expected to log out.

_{M365

}_

M365 requires that service team administrators log out of M365 in advance of

any expected unattended workstation inactivity, or when they have completed

the task that was the purpose of the log in. Additionally, when a user has

elevated to administrative access using the JIT process, that user's connections

are automatically terminated upon expiration of the elevation.

Responsible Role:

Customer Administrator, M365 Security Manager, M365 Trust Program Manager

Parameter

AC-02(07)(a): a role-based access scheme

Implementation Status

(check all that apply):

☒ Implemented

☐ Partially implemented

☐ Planned

☐ Alternative implementation

☐ Not applicable

Control Origination

(check all that apply):

☐ Service Provider Corporate

☐ Service Provider System Specific

☐ Service Provider Hybrid (Corporate and System Specific)

☐ Configured by Customer (Customer System Specific)

☐ Provided by Customer (Customer System Specific)

☒ Shared (Service Provider and Customer Responsibility)

☐ Inherited from pre-existing authorization

Part a

_{Customer Responsibility

}_

Government customers are responsible for establishing and administering

privileged user accounts with a role-based access scheme that organizes M365

customer privileges into roles in compliance with their organizational

policies.

Government customers will manage their account roles in their existing Active

Directory infrastructure. For information regarding how to manage user

accounts in Active Directory, see the following link:

<https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/understand-default-user-accounts>.

Non-government customers will manage their account roles in AAD via SUE. For

more information on managing customer accounts via the SUE portal, see:

<https://learn.microsoft.com/en-us/microsoft-365/admin/m365-feature-descriptions?view=o365-worldwide&tabs=User-account-management>.

_{M365

}_

All service team personnel accounts are considered privileged. Service team

users are assigned to security roles, which have a defined list of available

permissions. By default, service team accounts belong to a security group

that only has remote access to read system metadata, and no direct access to

the production environment. If a service team user needs elevated privileges

to the production environment, they must request that access and provide a

business justification using Torus and IDM. A service team user with the

access approver role then reviews and approves or denies the type of access

requested. Access is only provided for a finite period of time based on the

expected duration of the work to be performed. If access is approved, Torus

and IDM assign the service team user to security groups with the minimum

permissions required to perform the work and automatically revoke permissions

at the end of the specified time period.

Additionally, for OSI and some IS teams, service team personnel are assigned

a role within their service team that corresponds to a security group. Each

security group is assigned permissions to correlating environments with just

enough access to properly fulfill their tasks. Service team managers are

responsible for approving role assignments.

Part b

_{Customer Responsibility

}_

Government customers are responsible for tracking and monitoring privileged

role assignments, in compliance with their organizational policies, using

their Active Directory (AD) infrastructure. Government users communicate

identification/authentication and the associated permissions to AAD via

certificate-based authentication.

For more information on managing user accounts in Active Directory, see the

following link: <https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/understand-default-user-accounts>.

Non-government customers can track and monitor privileged role assignments

following the same procedures outlined for government customers, or they can

elect to manage user accounts in AAD via SUE. For customers using AAD, audit

records of assignment to privileged roles will be retained for 90 days; the

process for tracking privileged role assignments will be manual.

For more information on managing customer account role assignments via the

SUE portal, see:

<https://learn.microsoft.com/en-us/microsoft-365/admin/m365-feature-descriptions?view=o365-worldwide&tabs=User-account-management>.

_{M365

}_

All service team accounts are considered privileged and are tracked and

monitored using automated account management tools. For service teams that

require Just-In-Time elevated access to the production environment, role

assignments are tracked and monitored through Torus and IDM.

Part c

See part b.

Part d

_{Customer Responsibility

}_

Government and non-government customers are responsible for defining and

taking required actions when privileged role assignments for customer users

are no longer appropriate.

_{M365

}_

Privileged role assignments are no longer appropriate when M365 personnel no

longer have need of the role to support their current work, or if their

employment with Microsoft is terminated. In those cases, Office follows the

account management workflows to disable the account or revoke access.

The system has the capability of terminating a user session on the Terminal

Services Gateway (TSG) immediately. The TSGs are managed by Terminal Service

Gateway service or inherited from Azure. First, the account associated with

the user is disabled, then the session is terminated on the TSG. This

prevents the user from further remote access of the system.

Responsible Role:

Customer Administrator, M365 Security Manager, M365 Trust Program Manager

Parameter AC-02(09):

exception-based criteria

Implementation Status

(check all that apply):

☒ Implemented

☐ Partially implemented

☐ Planned

☐ Alternative implementation

☐ Not applicable

Control Origination

(check all that apply):

☐ Service Provider Corporate

☐ Service Provider System Specific

☐ Service Provider Hybrid (Corporate and System Specific)

☐ Configured by Customer (Customer System Specific)

☐ Provided by Customer (Customer System Specific)

☒ Shared (Service Provider and Customer Responsibility)

☐ Inherited from pre-existing authorization

_{Customer Responsibility

}_

Government customers are responsible for defining conditions for establishing

shared/group accounts and enforcing those conditions if they choose to

establish shared/group accounts.

_{M365

}_

M365 does not allow the use of shared/group service team accounts unless the

requirement to uniquely attribute user activity to the account is

implemented; exceptions may be approved on a case-by-case basis.

Responsible Role:

Customer Administrator, M365 Security Manager, M365 Trust Program Manager

Parameter AC-02(11)-1:

Time-based access control

Parameter AC-02(11)-2:

Information system accounts with access to the production environment

Implementation Status

(check all that apply):

☒ Implemented

☐ Partially implemented

☐ Planned

☐ Alternative implementation

☐ Not applicable

Control Origination

(check all that apply):

☐ Service Provider Corporate

☐ Service Provider System Specific

☐ Service Provider Hybrid (Corporate and System Specific)

☐ Configured by Customer (Customer System Specific)

☐ Provided by Customer (Customer System Specific)

☒ Shared (Service Provider and Customer Responsibility)

☐ Inherited from pre-existing authorization

_{Customer Responsibility

}_

Government customers are responsible for enforcing the appropriate usage and

time-based usage restrictions for all customer-controlled accounts.

_{M365

}_

M365 requires the use of Torus, an internal Just-In-Time (JIT) access control

tool, to access the production environment. Requests for access through Torus

must be approved by an eligibility owner and there are limitations to the

access granted:

• JIT sessions have a default TTL of 4 hours and cannot exceed 24 hours

• Sessions are also task-based – all requests must include a justification

and grant a restricted set of permissions that are scoped to the requested

task

• The management forest for Torus is isolated from, and does not trust, the

management forests of other service teams, further protecting access control

mechanisms from compromise

This process can be circumvented only in the event of an emergency through

the use of a "breakglass" account. There are very few of these

accounts. Use of one creates a Sev 1 alert to the incident response team and

causes the breakglass account password to be rotated.

Responsible Role:

Customer Administrator, M365 Security Manager, M365 Trust Program Manager

Parameter

AC-02(12)(a): Atypical use configured in Near Real Time (NRT) Security

Monitoring and automated security alert logic

Parameter

AC-02(12)(b): At a minimum, the ISSO and/or service owners or OCEs within the

organization

Implementation Status

(check all that apply):

☒ Implemented

☐ Partially implemented

☐ Planned

☐ Alternative implementation

☐ Not applicable

Control Origination

(check all that apply):

☐ Service Provider Corporate

☐ Service Provider System Specific

☐ Service Provider Hybrid (Corporate and System Specific)

☐ Configured by Customer (Customer System Specific)

☐ Provided by Customer (Customer System Specific)

☒ Shared (Service Provider and Customer Responsibility)

☐ Inherited from pre-existing authorization

Part a

_{Customer Responsibility

}_

Government customers are responsible for defining atypical use and monitoring

for that use on their infrastructure. Government customers can additionally

review M365 application logs and analyze them for atypical use.

_{M365

}_

M365 uses Vanquish for Near Real Time (NRT) Monitoring for security alerting

and monitoring, which has two high-level methods of alerting. An alert can be

configured to fire on a specific event or when multiple events correlate to

show an indication of compromise. Atypical use is considered any action that

falls outside of the normal baseline activity for each service team as

defined by Vanquish.

Part b

_{Customer Responsibility

}_

Government and non-government customers are responsible for reporting

atypical usage to defined organizational personnel.

_{M365

}_

M365 follows normal incident reporting procedures if an indication of

compromise is detected. These procedures require reporting incidents to the

M365 Security Incident & Response.

Responsible Role:

Customer Administrator, M365 Security Manager, M365 Trust Program Manager

Parameter AC-02(13)-1:

one (1) hour

Parameter AC-02(13)-2:

any significant risk

Implementation Status

(check all that apply):

☒ Implemented

☐ Partially implemented

☐ Planned

☐ Alternative implementation

☐ Not applicable

Control Origination

(check all that apply):

☐ Service Provider Corporate

☐ Service Provider System Specific

☐ Service Provider Hybrid (Corporate and System Specific)

☐ Configured by Customer (Customer System Specific)

☐ Provided by Customer (Customer System Specific)

☒ Shared (Service Provider and Customer Responsibility)

☐ Inherited from pre-existing authorization

_{Customer Responsibility

}_

Government customers are responsible for disabling user accounts posing a

significant risk.

_{M365

}_

The M365 Security Incident & Response (SIR) team is notified by MSIT

Corporate Security to monitor users that pose significant risk. Account

management tools synchronize with the Human Resources Information System

(HRIS). When a service team user is marked as disabled in HRIS, this

information propagates to account management tools, which then automatically

deactivates the service team domain account. Any accounts associated with the

Microsoft user are disabled in real time.

Responsible Role:

Customer Administrator, M365 Security Manager, M365 Trust Program Manager,

Service Engineer Operations

Implementation Status

(check all that apply):

☒ Implemented

☐ Partially implemented

☐ Planned

☐ Alternative implementation

☐ Not applicable

Control Origination

(check all that apply):

☐ Service Provider Corporate

☐ Service Provider System Specific

☐ Service Provider Hybrid (Corporate and System Specific)

☐ Configured by Customer (Customer System Specific)

☐ Provided by Customer (Customer System Specific)

☒ Shared (Service Provider and Customer Responsibility)

☐ Inherited from pre-existing authorization

_{Customer Responsibility

}_

Government customers are responsible for enforcing approved authorizations

for logical access to the system, in compliance with their organizational

policies, using their Active Directory (AD) infrastructure. Government users

communicate identification/authentication and the associated permissions to

AAD via certificate-based authentication. Once permissions are communicated

to AAD, AAD is responsible for enforcing those permissions for the users M365

session.

For information regarding how to manage user accounts in Active Directory,

see the following link:

<https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/understand-default-user-accounts>.

Non-government customers can enforce approved authorizations for logical

access to the system following the same procedures outlined for government

customers, or they can elect to manage user accounts in AAD via SUE. For

customers using AAD, AAD is responsible for enforcing the approved

authorizations set by the customer in the SUE portal.

For more information on managing customer account privileges via the SUE

portal, see the following link:

<https://learn.microsoft.com/en-us/microsoft-365/admin/m365-feature-descriptions?view=o365-worldwide&tabs=User-account-management>.

_{M365

}_

M365 service teams enforce approved authorizations for logical access using

role-based access control enforced by AD and Azure Active Directory (AAD).

M365 uses AD to implement role-based access control (RBAC) via the use of AD

groups. For the purposes of this control, the term "security group"

references an AD group which is used to enforce RBAC permissions.

M365 service teams are responsible for managing security groups in the

production domain. M365 has three major account types: service team,

customer, and service. Service team accounts are used by service team

personnel to manage and administer M365 Customer accounts are used by

customer users to access M365. Service accounts are used by various services

to authenticate to servers and other services.

Responsible Role:

Customer Administrator, Service Engineer Operations

Parameter AC-04: ACLs

and firewall rules

Implementation Status

(check all that apply):

☒ Implemented

☐ Partially implemented

☐ Planned

☐ Alternative implementation

☐ Not applicable

Control Origination

(check all that apply):

☐ Service Provider Corporate

☐ Service Provider System Specific

☐ Service Provider Hybrid (Corporate and System Specific)

☐ Configured by Customer (Customer System Specific)

☐ Provided by Customer (Customer System Specific)

☒ Shared (Service Provider and Customer Responsibility)

☐ Inherited from pre-existing authorization

_{Customer Responsibility

}_

Government customers are responsible for ensuring that no information with a

security impact level greater than moderate is stored, processed, or

transmitted via the services provided to them by M365. M365 will be

accredited to store, process, and transmit up to moderate Impact information

as defined by NIST SP 800-60.

Non-government customers are responsible for ensuring that information

stored, processed, or transmitted via the services provided to them by M365

MT is appropriate and in compliance with the risk policies of their

organization.

Customer Lockbox is an optional feature that customers can use for

controlling the flow of information in EXO. This feature allows customers to

control Microsoft administrators' ability to access their content. If in

response to a customer support request, a Microsoft administrator needs

access to customer content, that Microsoft administrator initiates a Just In

Time request which is routed to a customer administrator; this is in addition

to the normal internal required access approvals. The customer administrator

can then approve or deny this request via the customer administrator portal.

Note that even if customers choose not to use this tool, M365 Information

Security Policy is to never access customer content unless initiated by a

customer request, and access to this data is always restricted to screened

personnel with required JIT approvals. Customer Lockbox places the technical

enforcement of this policy within the customer's direct control.

For additional information, see:

<https://support.office.com/en-us/article/Office-365-customer-lockbox-requests-36f9cdd1-e64c-421b-a7e4-4a54d16440a2>.

_{M365

}_

M365 implements information flow control by allowing only connections and

communication which are necessary to allow systems to operate, blocking all

other ports, protocols and connections by default. This includes

intra-service communications as well as connections to external information

systems. Access Control Lists (ACLs) restrict network communications by

source and destination networks, protocols, and port numbers.

M365 manages ACL and other firewall rule changes through the same

configuration management processes as code changes, which includes review and

approval steps. ACLs are stored in M365's source code repository, Source

Depot. ACL changes are implemented to the networking devices through various

tools and APIs, including NetConf and Azure management APIs.

The use of firewall rules and ACLs allows M365 to control the flow of

information within the system and between interconnected systems. The use of

the RFC process ensures that data flows are authorized and approved.

A detailed diagram of the M365 dataflows, which includes all internal and

external information flows, is included in this SSP.

M365 is being tested at a High Impact level to demonstrate compliance with

the additional controls, but has not been sponsored for a High ATO at this

time.

Responsible Role:

Customer Administrator, Service Engineer Operations

Parameter AC-04(04)-1:

intrusion detection mechanisms

Parameter AC-04(04)-2:

blocking the flow of encrypted information

Implementation Status

(check all that apply):

☒ Implemented

☐ Partially implemented

☐ Planned

☐ Alternative implementation

☐ Not applicable

Control Origination

(check all that apply):

☐ Service Provider Corporate

☐ Service Provider System Specific

☐ Service Provider Hybrid (Corporate and System Specific)

☐ Configured by Customer (Customer System Specific)

☐ Provided by Customer (Customer System Specific)

☒ Shared (Service Provider and Customer Responsibility)

☐ Inherited from pre-existing authorization

_{Customer Responsibility

}_

Government customers are responsible for preventing encrypted information

from bypassing content-checking mechanisms by (one or more): decrypting the

information; blocking the flow of the encrypted information; terminating

communications sessions attempting to pass encrypted information;

organization-defined procedures or methods. M365 supports customer compliance

with M-21-31 and M-22-09.

_{M365

}_

M365 prevents encrypted information from bypassing IDS through implementing

information flow control by allowing only connections and communication which

are necessary to allow systems to operate, blocking all other ports,

protocols and connections by default. This includes intra-service

communications as well as connections to external information systems. Access

Control Lists (ACLs) are the preferred mechanism to restrict network

communications by source and destination networks, protocols, and port

numbers. ACLs exist at both the host and network level. M365 manages ACL

approvals through the Request For Change (RFC) process (including review and

risk acceptance) and the change process, and Azure implements the approved

change. Approved mechanisms to implement networked-based ACLs include: ACLs

on routers managed by Azure and firewall rules.

The use of firewall rules and ACLs allows M365 to control the flow of

information within the system and between interconnected systems. The use of

the RFC process ensures that data flows are authorized and approved.

Service teams also employ HostIDS to further monitor for data exfiltration at

the host level. NRT is used to alert based on specific security events as

well as other indicators of compromise, through Vanquish, such as anomalous

behavior and suspicious activity.

Responsible Role:

Service Engineer Operations

Parameter AC-04(21)-1:

TLS 1.2 and Active Directory Organizational Units

Parameter AC-04(21)-2:

Separation of all sessions

Implementation Status

(check all that apply):

☒ Implemented

☐ Partially implemented

☐ Planned

☐ Alternative implementation

☐ Not applicable

Control Origination

(check all that apply):

☐ Service Provider Corporate

☒ Service Provider System Specific

☐ Service Provider Hybrid (Corporate and System Specific)

☐ Configured by Customer (Customer System Specific)

☐ Provided by Customer (Customer System Specific)

☐ Shared (Service Provider and Customer Responsibility)

☐ Inherited from pre-existing authorization

_{M365

}_

M365 separates all information flows logically using user session encryption.

TLS 1.2 ensures the confidentiality and integrity of each flow; only the

intended recipient can decrypt information. Additionally, each M365 customer

is placed in a separate Organizational Unit (OU) within Active Directory.

Customer content within M365 is always tied to the customer's specific OU and

M365 will only grant access to the data if there is a valid ticket from AAD

authorizing access to the OU and the specific data.

For a detailed discussion of how M365 separates flows and tenant data, please

see:

<https://learn.microsoft.com/en-us/compliance/assurance/assurance-microsoft-365-isolation-controls?view=o365-worldwide>

<https://learn.microsoft.com/en-us/microsoft-365/enterprise/microsoft-365-isolation-in-azure-active-directory?view=o365-worldwide>

Responsible Role:

Customer Administrator, Program Manager

Parameter AC-05(a):

Code check-in and deployment duties; production access and audit

configuration duties; access requesting and access granting capabilities

Implementation Status

(check all that apply):

☒ Implemented

☐ Partially implemented

☐ Planned

☐ Alternative implementation

☐ Not applicable

Control Origination

(check all that apply):

☐ Service Provider Corporate

☐ Service Provider System Specific

☐ Service Provider Hybrid (Corporate and System Specific)

☐ Configured by Customer (Customer System Specific)

☐ Provided by Customer (Customer System Specific)

☒ Shared (Service Provider and Customer Responsibility)

☐ Inherited from pre-existing authorization

Part a

_{Customer Responsibility

}_

Government customers are responsible for separating duties of their

organizational users as necessary, to prevent malevolent activity without

collusion in compliance with their organizational policies.

Government customers will manage their user accounts in their existing Active

Directory infrastructure. For information regarding how to manage user

accounts in Active Directory, see the following link:

<https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/understand-default-user-accounts>.

Non-government customers manage their user accounts in AAD via SUE. For more

information on managing customer accounts via the SUE portal, see the

following link:

<https://learn.microsoft.com/en-us/microsoft-365/admin/m365-feature-descriptions?view=o365-worldwide&tabs=User-account-management>.

_{M365

}_

Service teams define their roles in IDM. Each role contains a list of

eligibilities. Eligibilities vary depending on the role that a specified

service team personnel will assume within the service team. The separation of

duties is documented through eligibilities (roles) assigned to service team

administrators in IDM. Each service team identifies roles that, if shared by

a single person, would allow for malicious activity without collusion. When

such role pairs exist, no individual is allowed to belong to both roles.

Account permissions and role access are reviewed as part of the monthly

account review process.

Additionally, service team administrators are required to request privileged

access to the production environment and provide a business justification

using Torus and IDM. A different service team administrator with the access

approver role then reviews and either approves or denies the type of access

requested. Access is only provided for a finite period of time based on the

expected duration of the work to be performed. If access is approved, Torus

and IDM assign the service team administrator the minimum permissions

required to perform the work and automatically revoke permissions at the end

of the specified time period.

Implementing access control using Torus and IDM effectively prevents

malevolent activity without collusion, as an individual has to review and

approve the requestor's access request and would deny requests that would

violate separation of duties requirements.

The separation of duties is documented through eligibilities (roles) assigned

to service team administrators in account management tools.

Part b

_{M365

}_

The separation of duties is documented through eligibilities (roles) assigned

to service team administrators in IdM. Each security group in IdM has access

to a specific list of eligibilities that grants specific permissions to

accomplish various tasks. In order for an admin to accomplish a task in

production, they must request elevation to the eligibility with the proper

permissions to accomplish that task.

A list of these roles can be made available to the customer upon request.

Responsible Role:

Customer Administrator, Program Manager, Service Engineer Operations

Implementation Status

(check all that apply):

☒ Implemented

☐ Partially implemented

☐ Planned

☐ Alternative implementation

☐ Not applicable

Control Origination

(check all that apply):

☐ Service Provider Corporate

☐ Service Provider System Specific

☐ Service Provider Hybrid (Corporate and System Specific)

☐ Configured by Customer (Customer System Specific)

☐ Provided by Customer (Customer System Specific)

☒ Shared (Service Provider and Customer Responsibility)

☐ Inherited from pre-existing authorization

_{Customer Responsibility

}_

Government customers are responsible for employing the concept of least

privilege, allowing only authorized accesses for government customer users

(and processes acting on behalf of users) which are necessary to accomplish

assigned tasks in accordance with organizational missions and business

functions in compliance with their organizational policies.

Government customers will manage their user accounts in their existing Active

Directory infrastructure. For information regarding how to manage user

account permissions in Active Directory, see the following link:

<https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/understand-default-user-accounts>.

Non-government customers will manage their user accounts in AAD via SUE. For

more information on managing account permissions via the SUE portal, see the

following link:

<https://learn.microsoft.com/en-us/microsoft-365/admin/m365-feature-descriptions?view=o365-worldwide&tabs=User-account-management>.

_{M365

}_

M365 service teams employ the concept of least privilege, documented in IDM

Roles and Eligibilities, allowing only authorized accesses for service team

users (and processes acting on behalf of service team users) that are

necessary to accomplish assigned tasks in accordance with business functions

and organizational need.

Service owners must employ the concept of least privilege for specific duties

and information systems in accordance with risk assessments as necessary to

adequately mitigate risk to operational assets, individuals, and/or other

organizations. Service team administrator permissions and segregation of

duties are defined in AC-5. Each service team is responsible for defining

least privileged roles within their team. Roles are documented within IDM.

Teams use Torus JIT and IDM, by default; service team accounts belong to a

security group that only has remote metadata access to the environment for

that service team. This does not permit direct environment access, or access

to customer content. If a service team administrator needs other privileges

to the production environment, they must request that access and provide a

business justification using Torus and IDM. A service team administrator with

the access approver role then reviews and approves or denies the type of

access requested. Access is only provided for a finite period of time based

on the expected duration of the work to be performed. If access is approved,

Torus and IDM assigns the service team administrator to security groups with

the minimum permissions required to perform the work and automatically

revokes permissions at the end of the specified time period.

The use of this Just-In-Time permissions model ensures that service team

administrators only ever have the least privileges required to accomplish

assigned tasks in support of M365 mission and business functions, restricted

by elevation level, resource access, and time.

Responsible Role:

Customer Administrator, Program Manager, Service Engineer Operations

Parameter AC-06(01)-1:

service team administrators (and processes acting on behalf of service team

administrators)

Parameter

AC-06(01)(a): All functions not publicly accessible

Parameter

AC-06(01)(b): all security-relevant information not publicly available

Implementation Status

(check all that apply):

☒ Implemented

☐ Partially implemented

☐ Planned

☐ Alternative implementation

☐ Not applicable

Control Origination

(check all that apply):

☐ Service Provider Corporate

☐ Service Provider System Specific

☐ Service Provider Hybrid (Corporate and System Specific)

☐ Configured by Customer (Customer System Specific)

☐ Provided by Customer (Customer System Specific)

☒ Shared (Service Provider and Customer Responsibility)

☐ Inherited from pre-existing authorization

Part a

_{Customer Responsibility

}_

Government customers are responsible for explicitly authorizing access to

security functions, as defined by their organization, in compliance with

their organizational policies, using their Active Directory (AD)

infrastructure. Government users communicate identification/authentication

and the associated permissions to AAD via certificate-based authentication.

For information regarding how to manage user accounts in AD, see the

following link: <https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/understand-default-user-accounts>.

Non-government customers can explicitly authorize access to security

functions following the same procedures outlined for government customers, or

they can elect to manage user accounts in AAD via SUE. For customers using

AAD, the customer is responsible for authorizing access to "tenant

administration" privileges which are used to manage user accounts and

system configuration via the SUE portal.

For more information on managing account privileges via the SUE portal, see

the following link:

<https://learn.microsoft.com/en-us/microsoft-365/admin/m365-feature-descriptions?view=o365-worldwide&tabs=User-account-management>.

_{M365

}_

Service teams employ the concept of least privilege, allowing only

pre-authorized access for service team administrators (and processes acting

on behalf of service team administrators) which are necessary to accomplish

assigned tasks in accordance with business functions and organizational need.

Service owners employ the concept of least privilege for specific duties and

information systems (including specific ports, protocols, and services) in

accordance with risk assessments as necessary to adequately mitigate risk to

operational assets, individuals, and/or other organizations.

All access to the M365 system must be explicitly authorized, including the

following security related functions: establishing system accounts,

configuring access authorizations (i.e., permissions, privileges), setting

events to be audited, and system and security administration. Role owners are

responsible for reviewing and approving role assignments, and roles are

tailored for different job functions such that personnel only have the

minimum access required to perform their duties. For some teams, service team

accounts by default belong to a security group that only has user-level

operating system access to the production environment for that service team -

this does not permit access to customer content. Access to any higher level

of permissions must be requested through Torus and IDM and authorized by the

on-call approver.

Through the use of this just in time model, M365 explicitly authorizes access

to security functions.

Part b

See part a.

Responsible Role:

Customer Administrator, Program Manager

Parameter AC-06(02):

All security functions

Implementation Status

(check all that apply):

☒ Implemented

☐ Partially implemented

☐ Planned

☐ Alternative implementation

☐ Not applicable

Control Origination

(check all that apply):

☐ Service Provider Corporate

☐ Service Provider System Specific

☐ Service Provider Hybrid (Corporate and System Specific)

☐ Configured by Customer (Customer System Specific)

☐ Provided by Customer (Customer System Specific)

☒ Shared (Service Provider and Customer Responsibility)

☐ Inherited from pre-existing authorization

_{Customer Responsibility

}_

Government customers are responsible for requiring that users of information

system accounts/roles with access to government security functions or

security-relevant information use non-privileged accounts/roles when

accessing other system functions. Government customers are also responsible

for auditing any use of privileged accounts/roles for such functions, in

compliance with their organizational policies, using their Active Directory

(AD) infrastructure. Government users communicate

identification/authentication and the associated permissions to AAD via

certificate-based authentication.

For information regarding how to manage user accounts in Active Directory see

the following link:

<https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/understand-default-user-accounts>.

Non-government customers can require that non-government customer users of

information system accounts/roles with access to security functions or

security-relevant information use non-privileged accounts/roles when

accessing other system functions. Non-government customers can also audit any

use of privileged non-government customer accounts/roles for such functions

following the same procedures outlined for government customers, or they can

elect to manage non-government customer user accounts in AAD via SUE. For

customers using AAD, the customer is responsible for authorizing access to

"tenant administration" privileges which are used to manage user

accounts and system configuration via the SUE portal. Customers can elect to

create a separate, non-privileged account for their administrative personnel

to access other functions of M365 MT. AAD audits all actions taken by tenant

administration accounts; audit logs are retained for 90 days.

For more information on managing customer account privileges via the SUE

portal, see the following link:

<https://learn.microsoft.com/en-us/microsoft-365/admin/m365-feature-descriptions?view=o365-worldwide&tabs=User-account-management>.

_{M365

}_

Service teams require all individuals with administrative privileges to use

their assigned accounts for performing business and security administrative

functions in the production environment. M365 requires that service team

administrators of information system accounts, or roles, with access to

security functions or security-relevant information, use non-privileged

accounts, or roles, when accessing other system functions.

Responsible Role:

Customer Administrator, Program Manager

Parameter AC-06(03)-1:

All privileged commands

Parameter AC-06(03)-2:

Maintenance and operational needs

Implementation Status

(check all that apply):

☒ Implemented

☐ Partially implemented

☐ Planned

☐ Alternative implementation

☐ Not applicable

Control Origination

(check all that apply):

☐ Service Provider Corporate

☐ Service Provider System Specific

☐ Service Provider Hybrid (Corporate and System Specific)

☐ Configured by Customer (Customer System Specific)

☐ Provided by Customer (Customer System Specific)

☒ Shared (Service Provider and Customer Responsibility)

☐ Inherited from pre-existing authorization

_{Customer Responsibility

}_

Government customers are responsible for enforcing least privilege when

authorizing network access to privileged commands.

_{M365

}_

M365 requires all individuals with administrative privileges to use their

assigned accounts for performing business and security administrative

functions in the production environment. These administrative functions are

identified within IDM for each service team.

Responsible Role:

Customer Administrator, M365 Security Manager, M365 Trust Program Manager,

Service Engineer Operations

Parameter AC-06(05):

Service Engineer Operations

Implementation Status

(check all that apply):

☒ Implemented

☐ Partially implemented

☐ Planned

☐ Alternative implementation

☐ Not applicable

Control Origination

(check all that apply):

☐ Service Provider Corporate

☐ Service Provider System Specific

☐ Service Provider Hybrid (Corporate and System Specific)

☐ Configured by Customer (Customer System Specific)

☐ Provided by Customer (Customer System Specific)

☒ Shared (Service Provider and Customer Responsibility)

☐ Inherited from pre-existing authorization

_{Customer Responsibility

}_

Customers are responsible for restricting privileged customer-controlled

accounts.

_{M365

}_

M365 restricts privileged access to the system to the internal roles

identified and approved in the account management tools.

Responsible Role:

Customer Administrator, M365 Security Manager, M365 Trust Program Manager,

Service Engineer Operations

Parameter

AC-06(07)(a)-1: At a minimum, annually

Parameter

AC-06(07)(a)-2: All users with privileges

Implementation Status

(check all that apply):

☒ Implemented

☐ Partially implemented

☐ Planned

☐ Alternative implementation

☐ Not applicable

Control Origination

(check all that apply):

☐ Service Provider Corporate

☐ Service Provider System Specific

☐ Service Provider Hybrid (Corporate and System Specific)

☐ Configured by Customer (Customer System Specific)

☐ Provided by Customer (Customer System Specific)

☒ Shared (Service Provider and Customer Responsibility)

☐ Inherited from pre-existing authorization

Part a

_{Customer Responsibility

}_

Government customers are responsible for reviewing user privileges.

_{M365

}_

M365 reviews privileged accounts at least annually. Privileges are enforced

by IDM and are reviewed by managers on a quarterly basis through assigned

tasks in Azure DevOps or the User Account Review (UAR) tool.

Part b

_{Customer Responsibility

}_

Government customers are responsible for reassigning or removing privileges

for customer-controlled accounts when appropriate.

_{M365

}_

M365 follows the IDM workflows to disable the privileged account or revoke

access when M365 personnel no longer have need of the role to support their

current work or if their employment with Microsoft is terminated.

Responsible Role:

Customer Administrator, M365 Security Manager, M365 Trust Program Manager,

Service Engineer Operations

Parameter AC-06(08):

Any software except software explicitly documented

Implementation Status

(check all that apply):

☒ Implemented

☐ Partially implemented

☐ Planned

☐ Alternative implementation

☐ Not applicable

Control Origination

(check all that apply):

☐ Service Provider Corporate

☐ Service Provider System Specific

☐ Service Provider Hybrid (Corporate and System Specific)

☐ Configured by Customer (Customer System Specific)

☐ Provided by Customer (Customer System Specific)

☒ Shared (Service Provider and Customer Responsibility)

☐ Inherited from pre-existing authorization

_{Customer Responsibility

}_

Government customers are responsible for enforcing software execution

privileges on customer-deployed resources.

_{M365

}_

Software execution at a higher privilege level than users executing the

software is not applicable for servers and network devices. M365 only permits

administrator access to server who by default have code execution privileges.

Tools are only accessible by M365 administrators; therefore, no read only

access is provided.

Responsible Role:

Customer Administrator, M365 Security Manager, M365 Trust Program Manager,

Service Engineer Operations

Implementation Status

(check all that apply):

☒ Implemented

☐ Partially implemented

☐ Planned

☐ Alternative implementation

☐ Not applicable

Control Origination

(check all that apply):

☐ Service Provider Corporate

☐ Service Provider System Specific

☐ Service Provider Hybrid (Corporate and System Specific)

☐ Configured by Customer (Customer System Specific)

☐ Provided by Customer (Customer System Specific)

☒ Shared (Service Provider and Customer Responsibility)

☐ Inherited from pre-existing authorization

_{Customer Responsibility

}_

Government customers are responsible for auditing account creation,

modification, disabling, and deletion events for their Active Directory

infrastructure as these events also pertain to M365 access. For these events,

these customers are responsible for capturing what type of event occurred,

when (date and time) the event occurred, where the event occurred, the source

of the event, the outcome (success or failure) of the event, and the identity

of any user/subject associated with the event. Customers using Windows

servers to support their infrastructure automatically meet this requirement

as Windows captures these event details by default. For more information

regarding Windows event logging, see: <https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/plan/appendix-l--events-to-monitor>.

_{M365

}_

M365 includes the execution of privileged functions in the list of events to

be audited by the system.

All commands run by all accounts are logged. Non-privileged actions (for

example, browsing the public internet, use of email clients, etc.) are not

allowed within the production environment. Additionally, some teams use just

in time (JIT) tools to allow privileged access to be granted within the

production environment. Execution of privileged functions using Torus and IDM

is audited.

Responsible Role: M365

Security Manager, M365 Trust Program Manager, Service Engineer Operations

Implementation Status

(check all that apply):

☒ Implemented

☐ Partially implemented

☐ Planned

☐ Alternative implementation

☐ Not applicable

Control Origination

(check all that apply):

☐ Service Provider Corporate

☒ Service Provider System Specific

☐ Service Provider Hybrid (Corporate and System Specific)

☐ Configured by Customer (Customer System Specific)

☐ Provided by Customer (Customer System Specific)

☐ Shared (Service Provider and Customer Responsibility)

☐ Inherited from pre-existing authorization

_{M365

}_

M365 does not have non-privileged users on the system. M365 prevents

non-privileged users from accessing privileged functions. Customers do not

have access to any functionality related to M365 safeguards/countermeasures.

Responsible Role:

Customer Administrator, M365 Security Manager, M365 Trust Program Manager

Parameter AC-07(a)-1:

Not more than five (5) consecutive invalid logon attempts

Parameter AC-07(a)-2:

logon, regardless of time

Parameter AC-07(b):

lock the account or node until released by an administrator; delay next logon

prompt per minimum of 5 seconds

Implementation Status

(check all that apply):

☒ Implemented

☐ Partially implemented

☐ Planned

☐ Alternative implementation

☐ Not applicable

Control Origination

(check all that apply):

☐ Service Provider Corporate

☐ Service Provider System Specific

☐ Service Provider Hybrid (Corporate and System Specific)

☐ Configured by Customer (Customer System Specific)

☐ Provided by Customer (Customer System Specific)

☒ Shared (Service Provider and Customer Responsibility)

☐ Inherited from pre-existing authorization

Part a

_{Customer Responsibility

}_

Customers have the ability to implement an organizationally specified policy

for these account settings. The customer is responsible for ensuring these

are compliant settings.

_{M365

}_

M365 has implemented an integrated defense against brute force attacks on

privileged accounts. GPO settings cover password authentication to endpoints.

Access to endpoints first requires two-factor authentication. M365 leverages

the PIN lockout feature on the YubiKeys to enforce a lockout after 5

consecutive failed attempts regardless of time. All M365 remote

administration requires multi-factor authentication. M365 has adopted this

alternative implementation as an operational requirement in order to ensure

that customers have the ability to implement an organizationally specified

policy for these same account settings. In addition, engineer accounts in the

M365 domains (including the just in time (JIT) account created when an

engineer needs elevated privileges) have machine generated random 30

character passwords which significantly increases the potential cost of a

brute force attempt.

Part b

_{Customer Responsibility

}_

Customers have the ability to implement an organizationally specified policy

for these account settings. The customer is responsible for ensuring these

are compliant settings.

_{M365

}_

M365 leverages the PIN lockout feature on the YubiKey to enforce a lockout

after 5 consecutive failed attempts regardless of time. Once PIN lockout is

triggered, the YubiKey is deactivated and the engineer must perform a full

re-enrollment, which requires multi-factor authentication and an approval

from the engineer's manager.

Responsible Role:

Customer Administrator, M365 Security Manager, M365 Trust Program Manager,

Service Engineer Operations

Parameter AC-08(a):

see additional Requirements and Guidance

Parameter AC-08(c)(1):

see additional Requirements and Guidance

Implementation Status

(check all that apply):

☒ Implemented

☐ Partially implemented

☐ Planned

☐ Alternative implementation

☐ Not applicable

Control Origination

(check all that apply):

☐ Service Provider Corporate

☐ Service Provider System Specific

☐ Service Provider Hybrid (Corporate and System Specific)

☐ Configured by Customer (Customer System Specific)

☐ Provided by Customer (Customer System Specific)

☒ Shared (Service Provider and Customer Responsibility)

☐ Inherited from pre-existing authorization

Part a

_{Customer Responsibility

}_

Government customers are responsible for displaying an approved system use

notification message or banner on the authentication page used to

authenticate to M365 that provides privacy and security notices consistent

with applicable federal laws, Executive Orders, directives, policies,

regulations, standards, and guidance and states that: (i) users are accessing

a U.S. Government information system; (ii) system usage may be monitored,

recorded, and subject to audit; (iii) unauthorized use of the system is

prohibited and subject to criminal and civil penalties; and (iv) use of the

system indicates consent to monitoring and recording.

Non-government customers may implement system use notification messages or

banners on their local workstations.

_{M365

}_

Part 1-4

All service teams include a FISMA warning banner prior to administrative

login to all servers. There are two approved messages reviewed by Microsoft

Corporate, External, and Legal Affairs (CELA). The first reads:

"You are accessing an information system that may contain U.S.

Government data. System usage may be monitored, recorded, and subject to

audit. Unauthorized use of the system is prohibited and may be subject to

criminal and civil penalties. Use of the system indicates consent to

monitoring and recording. Administrative personnel remotely accessing the

M365 environment:

• Maintain their remote computer in a secure manner, in accordance with

organizational security policies and procedures as defined in Microsoft Remote

Connectivity Security Policies.

• Only access the M365 environment in execution of operational, deployment,

and support responsibilities using only administrative applications or tools

directly related to performing these responsibilities.

• Are advised to not knowingly store, transfer into, or process in the M365

environment data exceeding a FIPS 199 Moderate security categorization (FISMA

Controlled Unclassified Information)."

An alternate approved wording states:

"You are accessing an information system that may contain U.S.

Government data. System usage may be monitored, recorded, and subject to

audit. Unauthorized use of the system is prohibited and may be subject to

criminal and civil penalties. Use of the system indicates consent to

monitoring and recording. Administrative personnel remotely accessing the

M365 environment:

1. shall maintain their remote computer in a secure manner, in accordance

with organizational security policies and procedures as defined in Microsoft

Remote Connectivity Security Policies;

2. shall only access the M365 environment in execution of operational,

deployment, and support responsibilities using only administrative

applications or tools directly related to performing these responsibilities;

and

3. shall not knowingly store, transfer into, or process in the M365

environment data exceeding a FIPS 199 Moderate security categorization (FISMA

Controlled Unclassified Information)."

The system use notification message is a required part of system

configuration and is managed as part of the Configuration Management control

family, including configuration baseline review. Configuration baselines are

reviewed monthly, as part of major system releases or upgrades, and when a

significant change occurs. Proposed changes to baselines are reviewed and

approved by the appropriate Change Advisory Board (CAB).

Part b

_{Customer Responsibility

}_

Government customers are responsible for retaining the notification message

or banner on the screen until users take explicit actions to log on to M365.

Non-government customers can retain the notification message or banner on the

screen until users take explicit actions to log on to workstations used to

access M365, consistent with organizational policies and risk tolerances.

_{M365

}_

The warning banner is displayed during the production environment logon

sequence. Service team administrators must acknowledge the usage conditions

and take explicit action to complete the login sequence.

Part c

_{Customer Responsibility

}_

Government customers are responsible for verifying the notification message

or banner on the login page used to authenticate government customer users to

M365 at an interval consistent with organizational policies.

Non-government customers can verify the notification message or banner on the

workstations used to access M365 MT, consistent with organizational policies

and risk tolerances.

_{M365

}_

Part 1, 2, 3

M365 MT does not display a warning banner on customer interfaces. Based on

review of FedRAMP requirements, and discussions and confirmation with M365 MT

environment process owners, this control is not applicable to the M365 MT

environment.

M365 MT considers not implementing a banner to be an operational requirement

for a commercial service. M365 MT does provide links to both privacy and

legal information related to M365 MT on the public-facing M365 MT login page.

Responsible Role: M365

Security Manager, Service Engineer Operations

Parameter AC-10-1: All

account types and/or accounts

Parameter AC-10-2:

three (3) sessions for privileged access and two (2) sessions for

non-privileged access

Implementation Status

(check all that apply):

☒ Implemented

☐ Partially implemented

☐ Planned

☐ Alternative implementation

☐ Not applicable

Control Origination

(check all that apply):

☐ Service Provider Corporate

☒ Service Provider System Specific

☐ Service Provider Hybrid (Corporate and System Specific)

☐ Configured by Customer (Customer System Specific)

☐ Provided by Customer (Customer System Specific)

☐ Shared (Service Provider and Customer Responsibility)

☒ Inherited from pre-existing authorization for Azure Government

(F1603087869), 4/17/2020

_{M365

}_

M365 servers restrict concurrent sessions to one (1) session per service team

administrator per server. Terminal Services Gateways (TSGs) managed by TSG,

or inherited from Azure, are configured to allow single concurrent sessions

for users to those devices. TSGs do not allow multiple sessions, but instead

allow service team administrators to connect to multiple servers

concurrently, using a single session per server, so that administrators can

effectively perform their duties. Service team administrators do not have any

permissions on the TSGs themselves. The TSG is only used to enforce

multifactor authentication and encryption requirements. Once the service team

administrator connects to a specific server through a TSG, the specific

server will enforce a session limit of one per administrator.

Responsible Role:

Customer Administrator, M365 Security Manager, M365 Trust Program Manager,

Program Manager

Parameter AC-11(a):

Fifteen (15) minutes

Implementation Status

(check all that apply):

☒ Implemented

☐ Partially implemented

☐ Planned

☐ Alternative implementation

☐ Not applicable

Control Origination

(check all that apply):

☐ Service Provider Corporate

☐ Service Provider System Specific

☐ Service Provider Hybrid (Corporate and System Specific)

☐ Configured by Customer (Customer System Specific)

☐ Provided by Customer (Customer System Specific)

☒ Shared (Service Provider and Customer Responsibility)

☒ Inherited from pre-existing authorization for Azure Government

(F1603087869), 4/17/2020

Part a

_{Customer Responsibility

}_

Customers are responsible for preventing further access to the system by

initiating a session lock, after a given period of user inactivity at the

workstation level and retaining the session lock until the user reestablishes

access using established identification and authentication procedures, in

compliance with organizational policies.

Non-government customers can prevent further access to the system by

initiating a session lock, after a given period of user inactivity at the

workstation level, in compliance with organizational policies.

_{M365

}_

Server sessions are locked after no more than 10 minutes of inactivity, which

is enforced by Terminal Service Gateways (TSGs), or upon user request. For

teams using Azure managed Terminal Services Gateways, this is inherited from

Azure.

Part b

_{Customer Responsibility

}_

Government customers are responsible for retaining the session lock until the

user reestablishes access using established identification and authentication

procedures, in compliance with organizational policies.

Non-government customers can retain the session lock until the user

reestablishes access using established identification and authentication

procedures, in compliance with organizational policies.

_{M365

}_

M365 users must re-authenticate into the system once the user session has

been locked for inactivity.

Responsible Role:

Customer Administrator, M365 Security Manager

Implementation Status

(check all that apply):

☒ Implemented

☐ Partially implemented

☐ Planned

☐ Alternative implementation

☐ Not applicable

Control Origination

(check all that apply):

☐ Service Provider Corporate

☐ Service Provider System Specific

☐ Service Provider Hybrid (Corporate and System Specific)

☐ Configured by Customer (Customer System Specific)

☐ Provided by Customer (Customer System Specific)

☒ Shared (Service Provider and Customer Responsibility)

☐ Inherited from pre-existing authorization

_{Customer Responsibility

}_

Government customers are responsible for enforcing that the session lock

mechanism, when activated on a device with a display screen, places a

publicly viewable pattern onto the associated display, hiding what was

previously visible on the screen.

Non-government customers can enforce that the session lock mechanism, when

activated on a device with a display screen, places a publicly viewable

pattern onto the associated display, hiding what was previously visible on

the screen.

_{M365

}_

All M365 servers and Terminal Services Gateways managed by TSG or Azure run

Windows. Compliance with this control is a built-in feature of Microsoft

Windows. Microsoft Windows places a publicly-viewable pattern onto the

associated display when the session lock mechanism is activated on a device

with a display screen, hiding what was previously visible on the screen.

Responsible Role:

Customer Administrator,M365 Security Manager, M365 Trust Program Manager,

Program Manager

Parameter AC-12:

Logout request initiated by user, or 24 hours after initiation of session, or

after 10 minutes of inactivity.

Implementation Status

(check all that apply):

☒ Implemented

☐ Partially implemented

☐ Planned

☐ Alternative implementation

☐ Not applicable

Control Origination

(check all that apply):

☐ Service Provider Corporate

☒ Service Provider System Specific

☐ Service Provider Hybrid (Corporate and System Specific)

☐ Configured by Customer (Customer System Specific)

☐ Provided by Customer (Customer System Specific)

☐ Shared (Service Provider and Customer Responsibility)

☒ Inherited from pre-existing authorization for Azure Government

(F1603087869), 4/17/2020

_{Customer Responsibility

}_

Government customers are responsible for configuring a session termination

interval that follows their organizational requirements when using W365

services.

_{M365

}_

M365 automatically disables customer and service team administrator sessions

upon receiving a logout request initiated by users, or after 24 hours from

initiation of session, by enforcing time restrictions configured via

TSG/SAWs. Additionally, service team administrator sessions are disconnected

after no more than 10 minutes of inactivity. For teams using Azure managed

Terminal Services Gateways, this is inherited from Azure.

Responsible Role:

Customer Administrator, M365 Security Manager, M365 Trust Program Manager,

Service Engineer Operations

Parameter AC-14(a):

All user actions

Implementation Status

(check all that apply):

☒ Implemented

☐ Partially implemented

☐ Planned

☐ Alternative implementation

☐ Not applicable

Control Origination

(check all that apply):

☐ Service Provider Corporate

☐ Service Provider System Specific

☐ Service Provider Hybrid (Corporate and System Specific)

☐ Configured by Customer (Customer System Specific)

☐ Provided by Customer (Customer System Specific)

☒ Shared (Service Provider and Customer Responsibility)

☐ Inherited from pre-existing authorization

Part a

_{Customer Responsibility

}_

Government customers are responsible for identifying specific user actions

that can be performed on the information system without identification or

authentication in compliance with organizational policies.

Guest access to MSTeams meetings, if enabled, allows anyone with a meeting

invite to access the meeting lobby. The meeting organizer is responsible for

establishing the identity of lobby participants before granting them access

to the meeting.

Government customers are responsible for disabling guest access to MSTeams

meetings to remain compliant with FedRAMP standards as advised in "M365

MT Government Compliance Considerations". This setting can be configured

by government customers.

Non-government customers are responsible for determining if the use of guest

access to MSTeams meetings should be allowed for their organization. This

setting can be configured by government and non-government customers.

_{M365

}_

The only actions permitted by M365 to be performed on the system without

authentication are accessing the Legal, Privacy, and Feedback option on the

customer facing welcome page.

Part b

_{Customer Responsibility

}_

Government customers are responsible for documenting and providing supporting

rationale for user actions not requiring identification and authentication in

compliance with organizational policies.

Guest access to MSTeams meetings, if enabled, allows anybody with a meeting

invite to access the meeting lobby. The meeting organizer is responsible for

establishing the identity of lobby participants before granting them access

to the meeting.

Government customers are responsible for disabling guest access to MSTeams

meetings to remain compliant with FedRAMP standards.

Non-government customers are responsible for determining if the use of guest

access to MSTeams meetings should be allowed for their organization. This

setting can be configured by government and non-government customers.

_{M365

}_

The information in the Legal, Privacy, and Feedback options on the customer

facing welcome page is either legally required or foundational to an internet

facing cloud service and none of it impacts the security of the system if

publicly disclosed.

Responsible Role:

Customer Administrator, M365 Security Manager, M365 Trust Program Manager,

Program Manager, Service Engineer Operations

Implementation Status

(check all that apply):

☒ Implemented

☐ Partially implemented

☐ Planned

☐ Alternative implementation

☐ Not applicable

Control Origination

(check all that apply):

☐ Service Provider Corporate

☐ Service Provider System Specific

☐ Service Provider Hybrid (Corporate and System Specific)

☐ Configured by Customer (Customer System Specific)

☐ Provided by Customer (Customer System Specific)

☒ Shared (Service Provider and Customer Responsibility)

☒ Inherited from pre-existing authorization for Azure Government

(F1603087869), 4/17/2020

Part a

_{Customer Responsibility

}_

Government customers connect to M365 via the following allowed methods of

remote access: web interface via web browser, email software client, RDP

connection to W365,or PowerShell client. These methods are documented in

"M365 MT Government Compliance Considerations".

Government customers are responsible for ensuring that client software is

configured to only establish sessions using FIPS 140-2 compliant protocols.

This can be accomplished by restricting access to the government customer's

internal network traffic. This will force government customers attempting to

connect to M365 to VPN into the customer's network or directly be on the

network at the time of authentication. When the customer connects (directly

or via VPN) to the network it should perform a health inspection that

validates USGCB baselines including browser settings to require FIPS 140-2

connections.

Non-government customers should adhere to their respective regulatory and

internal policies but may not be required to use FIPS 140-2 compliant

encryption, and M365 MT will accept non-FIPS 140-2 compliant requests.

Because of the need to support customers with out-of-date software, M365 MT

does not enforce FIPS 140-2 compliant encryption for all customers.

_{M365

}_

M365 personnel do not have physical access to datacenters. Each service team

implements remote access through the use of a Terminal Services Gateway (TSG)

managed by either TSG or Azure to gain remote access to M365. Secure Access

Workstations (SAWs) are required to establish remote sessions into the M365

production environment via the TSGs. Government customers do not have access

to authenticate to M365 via the TSGs.

Usage restrictions and connection/configuration requirements for M365

personnel are established in the Terminal Services Gateways by Active

Directory-managed Group Policy. These policies include the bulleted

implementation guidance of configuration/connection requirements listed below

and are available for review:

• TSG servers are configured to only use FIPS 140-2 compliant encryption

• TSG sessions are configured to disconnect after 10 minutes of inactivity

• TSG sessions are configured to automatically log off after 24 hours,

terminating the network session

Part b

_{Customer Responsibility

}_

Remote access is how government customers are expected to interact with M365.

M365 expects all government customers to have remote access. Government

customers are responsible for authorizing their users to access M365 and in

doing so authorize them to use the system remotely. By default, customers do

not have remote access to M365 until an account is created for them by their

customer administrator.

_{M365

}_

All approved maintenance activities are authorized for execution via remote

access to the M365 environment. The system devices reside in data centers

geographically segregated from the operations teams. Personnel local to the

data centers do not have logical access to information system components. As

a result, the only way to perform maintenance is remotely.

Microsoft personnel are required to connect to the Terminal Services Gateways

(TSG) using equipment which complies with Microsoft Corporate Network

security configurations. This limits the ability for malicious software on

remote clients to compromise the M365 environment. TSG or Azure is

responsible for the implementation and configuration of the TSGs.

Responsible Role:

Customer Administrator, M365 Security Manager, M365 Trust Program Manager

Implementation Status

(check all that apply):

☒ Implemented

☐ Partially implemented

☐ Planned

☐ Alternative implementation

☐ Not applicable

Control Origination

(check all that apply):

☐ Service Provider Corporate

☐ Service Provider System Specific

☐ Service Provider Hybrid (Corporate and System Specific)

☐ Configured by Customer (Customer System Specific)

☐ Provided by Customer (Customer System Specific)

☒ Shared (Service Provider and Customer Responsibility)

☒ Inherited from pre-existing authorization for Azure Government

(F1603087869), 4/17/2020

_{Customer Responsibility

}_

Government customers are responsible for employing automated mechanisms to

facilitate the monitoring and control of remote access methods, in compliance

with their organizational policies, using their Active Directory (AD)

infrastructure. Government users communicate identification/authentication

and the associated permissions to AAD via certificate-based authentication.

Non-government customers can employ automated mechanisms to facilitate the

monitoring and control of remote access methods following the same procedures

outlined for government customers, or they can elect to manage user accounts

in Azure Active Directory (AAD) via SUE. For customers using AAD, AAD is the

automated mechanism used to monitor and control remote access, using the

settings defined by the client in the SUE portal. AAD retains audit logs of

remote connections for 90 days.

For more information on managing customer accounts via the SUE portal, see

the following link:

<https://learn.microsoft.com/en-us/microsoft-365/admin/m365-feature-descriptions?view=o365-worldwide&tabs=User-account-management>.

_{M365

}_

All remote access connections from service team personnel are audited

utilizing the access points auditing functionality. The service team monitors

the connections for attempted unauthorized use of M365 using Near Real Time

Alerting tools. Two-factor authentication using YubiKeys through TSGs is the

only approved method to gain remote administrative access to systems in any

M365 domains. Logs from remote access points and customer-facing interfaces

are uploaded to a repository service and reports are generated from those

logs, in conjunction with the NRT Security Monitoring of remote access

methods.

Responsible Role:

Customer Administrator, M365 Security Manager, M365 Trust Program Manager

Implementation Status

(check all that apply):

☒ Implemented

☐ Partially implemented

☐ Planned

☐ Alternative implementation

☐ Not applicable

Control Origination

(check all that apply):

☐ Service Provider Corporate

☐ Service Provider System Specific

☐ Service Provider Hybrid (Corporate and System Specific)

☐ Configured by Customer (Customer System Specific)

☐ Provided by Customer (Customer System Specific)

☒ Shared (Service Provider and Customer Responsibility)

☒ Inherited from pre-existing authorization for Azure Government

(F1603087869), 4/17/2020

_{Customer Responsibility

}_

Government customers are responsible for configuring their workstations to

support the use of cryptography to protect the confidentiality and integrity

of remote access sessions in compliance with organizational policies.

Government customers are required to configure workstations to establish FIPS

140-2 compliant TLS sessions for remote access in order to retain compliance

with FedRAMP requirements. This can be accomplished by restricting access to

the government customer's internal network traffic. This will force

government customers attempting to connect to M365 to VPN into the customer's

network or directly be on the network at the time of authentication.

When the customer connects (directly or via VPN) to the network it should

perform a health inspection that validates USGCB baselines including browser

settings to require FIPS 140-2 connections.

Non-government customers may configure their workstations to support the use

of cryptography to protect the confidentiality and integrity of remote access

sessions in compliance with organizational policies.

_{M365

}_

M365 uses FIPS 140-2 compliant cryptography to encrypt Terminal Services

Gateway (TSG) connections to protect the confidentiality and integrity of

remote access sessions. For teams using Azure managed TSGs, this is inherited

from Azure. FIPS encryption as handled by Microsoft products is further

explained in the following article:

<https://learn.microsoft.com/en-us/windows/security/security-foundations/certification/fips-140-validation>.

M365's FIPS 140-2 encryption modules used for transmitted information are

certified by NIST via certificates listed in Appendix Q of this SSP. For more

information see,

<http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-historical.htm>.

Responsible Role:

Customer Administrator, M365 Security Manager, M365 Trust Program Manager

Implementation Status

(check all that apply):

☒ Implemented

☐ Partially implemented

☐ Planned

☐ Alternative implementation

☐ Not applicable

Control Origination

(check all that apply):

☐ Service Provider Corporate

☐ Service Provider System Specific

☐ Service Provider Hybrid (Corporate and System Specific)

☐ Configured by Customer (Customer System Specific)

☐ Provided by Customer (Customer System Specific)

☒ Shared (Service Provider and Customer Responsibility)

☒ Inherited from pre-existing authorization for Azure Government

(F1603087869), 4/17/2020

_{Customer Responsibility

}_

Government customers are responsible for routing remote access traffic to

M365 through a limited number of managed access points. Further information

is available in CA-3(3).

_{M365

}_

M365 Service teams implement remote access through the use of specially

configured Terminal Services Gateways (TSGs) as the only approved way to gain

remote administrative access to service team systems. Additionally, service

teams require the use of Secure Access Workstations (SAWs) to establish

remote sessions into the M365 production environment via the TSGs. Each

service team has a load-balanced pool of TSGs in two

geographically-distributed data centers. TSGs are managed by the Terminal

Service Gateway service or Azure for M365.

Responsible Role: M365

Security Manager, M365 Trust Program Manager

Parameter

AC-17(04)(a): support of the operational system

Implementation Status

(check all that apply):

☒ Implemented

☐ Partially implemented

☐ Planned

☐ Alternative implementation

☐ Not applicable

Control Origination

(check all that apply):

☐ Service Provider Corporate

☒ Service Provider System Specific

☐ Service Provider Hybrid (Corporate and System Specific)

☐ Configured by Customer (Customer System Specific)

☐ Provided by Customer (Customer System Specific)

☐ Shared (Service Provider and Customer Responsibility)

☐ Inherited from pre-existing authorization

Part a

_{M365

}_

M365 authorizes remote access for M365 service team administrators. Because

M365 service teams do not have physical access to the data centers, there is

a business requirement for those personnel to have remote access.

Before service team personnel can connect to M365 remotely, they must first

be approved for remote access by an authorized manager. This process is

automatically enforced by IDM.

Part b

_{M365

}_

The only way to manage the system is via the remote access process described

above in AC-17. Remote access to privileged functions has been approved by

the system owner. Remote access is only allowed to support authorized

maintenance and support activities.

The rationale for remote access is documented in AC-17.

Responsible Role:

Customer Administrator, Azure, M365 Security Manager, M365 Trust Program

Manager

Implementation Status

(check all that apply):

☒ Implemented

☐ Partially implemented

☐ Planned

☐ Alternative implementation

☐ Not applicable

Control Origination

(check all that apply):

☐ Service Provider Corporate

☒ Service Provider System Specific

☐ Service Provider Hybrid (Corporate and System Specific)

☒ Configured by Customer (Customer System Specific)

☒ Provided by Customer (Customer System Specific)

☐ Shared (Service Provider and Customer Responsibility)

☒ Inherited from pre-existing authorization for Azure Government

(F1603087869), 4/17/2020

Part a

_{Customer Responsibility

}_

M365 does not distinguish between wireless and non-wireless customer access.

If government customers wish to prevent wireless customer access, they can do

so by only allowing connections from domain-joined machines on a non-wireless

network.

_{M365

}_

Azure establishes usage restrictions, configuration/connection requirements,

and implementation guidance for wireless access via the Network Security

Standard, which explicitly prohibits the use of wireless in the Azure

environment. Azure does not permit wireless access within Azure datacenters.

This is inherited from Azure.

Part b

_{Customer Responsibility

}_

M365 does not distinguish between wireless and non-wireless customer access.

If government customers wish to prevent wireless customer access, they can do

so by only allowing connections from domain-joined machines on a non-wireless

network.

_{M365

}_

Azure does not allow wireless access within Azure datacenters. Azure

regularly scans for rogue wireless signals within Azure datacenters. This is

inherited from Azure.

Responsible Role:

Customer Administrator, Azure, M365 Security Manager, M365 Trust Program

Manager

Parameter AC-18(01):

users; devices

Implementation Status

(check all that apply):

☒ Implemented

☐ Partially implemented

☐ Planned

☐ Alternative implementation

☐ Not applicable

Control Origination

(check all that apply):

☐ Service Provider Corporate

☐ Service Provider System Specific

☐ Service Provider Hybrid (Corporate and System Specific)

☐ Configured by Customer (Customer System Specific)

☐ Provided by Customer (Customer System Specific)

☒ Shared (Service Provider and Customer Responsibility)

☒ Inherited from pre-existing authorization for Azure Government

(F1603087869), 4/17/2020

_{Customer Responsibility

}_

M365 does not distinguish between wireless and non-wireless customer access.

If government customers wish to allow wireless customer access and

authenticate devices and users, they are responsible for configuring their

infrastructure to perform this authentication.

_{M365

}_

Azure does not allow wireless access within Azure datacenters. Additionally,

systems within Azure datacenters do not contain wireless network

capabilities. This is inherited from Azure.

Responsible Role:

Azure, M365 Security Manager, M365 Trust Program Manager

Implementation Status

(check all that apply):

☒ Implemented

☐ Partially implemented

☐ Planned

☐ Alternative implementation

☐ Not applicable

Control Origination

(check all that apply):

☐ Service Provider Corporate

☐ Service Provider System Specific

☐ Service Provider Hybrid (Corporate and System Specific)

☐ Configured by Customer (Customer System Specific)

☐ Provided by Customer (Customer System Specific)

☐ Shared (Service Provider and Customer Responsibility)

☒ Inherited from pre-existing authorization for Azure Government

(F1603087869), 4/17/2020

_{M365

}_

M365 does not allow wireless access within Azure datacenters. Additionally,

systems within Azure datacenters do not contain wireless network

capabilities. This is inherited from Azure.

Responsible Role:

Azure, M365 Security Manager, M365 Trust Program Manager

Implementation Status

(check all that apply):

☒ Implemented

☐ Partially implemented

☐ Planned

☐ Alternative implementation

☐ Not applicable

Control Origination

(check all that apply):

☐ Service Provider Corporate

☐ Service Provider System Specific

☐ Service Provider Hybrid (Corporate and System Specific)

☐ Configured by Customer (Customer System Specific)

☐ Provided by Customer (Customer System Specific)

☐ Shared (Service Provider and Customer Responsibility)

☒ Inherited from pre-existing authorization for Azure Government

(F1603087869), 4/17/2020

_{M365

}_

M365 does not allow wireless access within Azure data centers. Additionally,

systems within Azure datacenters do not contain wireless network

capabilities. This is inherited from Azure.

Responsible Role:

Azure, M365 Security Manager, M365 Trust Program Manager

Implementation Status

(check all that apply):

☒ Implemented

☐ Partially implemented

☐ Planned

☐ Alternative implementation

☐ Not applicable

Control Origination

(check all that apply):

☐ Service Provider Corporate

☐ Service Provider System Specific

☐ Service Provider Hybrid (Corporate and System Specific)

☐ Configured by Customer (Customer System Specific)

☐ Provided by Customer (Customer System Specific)

☐ Shared (Service Provider and Customer Responsibility)

☒ Inherited from pre-existing authorization for Azure Government

(F1603087869), 4/17/2020

_{M365

}_

M365 does not allow wireless access within Azure data centers. Additionally,

systems within Azure datacenters do not contain wireless network

capabilities. This is inherited from Azure.

Responsible Role:

Customer Administrator, Azure, M365 Security Manager, M365 Trust Program

Manager

Implementation Status

(check all that apply):

☒ Implemented

☐ Partially implemented

☐ Planned

☐ Alternative implementation

☐ Not applicable

Control Origination

(check all that apply):

☐ Service Provider Corporate

☐ Service Provider System Specific

☐ Service Provider Hybrid (Corporate and System Specific)

☐ Configured by Customer (Customer System Specific)

☐ Provided by Customer (Customer System Specific)

☒ Shared (Service Provider and Customer Responsibility)

☒ Inherited from pre-existing authorization for Azure Government

(F1603087869), 4/17/2020

Part a

_{Customer Responsibility

}_

Government customers are responsible for establishing usage restrictions,

configuration and connection requirements, and implementation guidance for

organization-controlled mobile devices used to connect to M365.

_{M365

}_

There are no mobile devices within the M365 boundary. Azure is responsible

for preventing the physical connection of mobile devices to M365 servers.

The prevention of mobile devices connecting to M365 is inherited from Azure.

Unauthorized mobile computing devices are not permitted in, or directly

attached to, any Azure production environment.

Part b

_{M365

}_

There are no mobile devices within the M365 boundary.

The prevention of mobile devices connecting to M365 is inherited from Azure.

Unauthorized mobile computing devices are not permitted in, or directly

attached to, any M365 Azure production environment. The organization's staff

and contingent staff must adopt and follow appropriate security practices

when using mobile computing devices to protect against the risks of using

mobile equipment.

Responsible Role:

Customer Administrator, Azure, M365 Security Manager, M365 Trust Program

Manager

Parameter AC-19(05)-1:

full-device encryption

Parameter AC-19(05)-2:

All mobile devices

Implementation Status

(check all that apply):

☒ Implemented

☐ Partially implemented

☐ Planned

☐ Alternative implementation

☐ Not applicable

Control Origination

(check all that apply):

☐ Service Provider Corporate

☐ Service Provider System Specific

☐ Service Provider Hybrid (Corporate and System Specific)

☐ Configured by Customer (Customer System Specific)

☐ Provided by Customer (Customer System Specific)

☒ Shared (Service Provider and Customer Responsibility)

☒ Inherited from pre-existing authorization for Azure Government

(F1603087869), 4/17/2020

_{Customer Responsibility

}_

Government customers are responsible for employing full device encryption for

organization-controlled mobile devices used to connect to M365.

_{M365

}_

There are no mobile devices within the M365 boundary.

The prevention of mobile devices connecting to M365 is inherited from Azure.

Azure does not issue or allow connectivity via mobile devices to Azure, and

systems within the Azure information system do not contain wireless

networking capabilities.

Responsible Role:

Customer Administrator, Azure, M365 Trust Program Manager

Parameter AC-20(a):

Establish ISAs, MOUs, MSSA, and/or vendor agreements; Identify NAC/NAP

controls

Parameter AC-20(b):

All external systems that do not meet requirements defined in AC-20(a)

Implementation Status

(check all that apply):

☒ Implemented

☐ Partially implemented

☐ Planned

☐ Alternative implementation

☐ Not applicable

Control Origination

(check all that apply):

☐ Service Provider Corporate

☐ Service Provider System Specific

☐ Service Provider Hybrid (Corporate and System Specific)

☐ Configured by Customer (Customer System Specific)

☐ Provided by Customer (Customer System Specific)

☒ Shared (Service Provider and Customer Responsibility)

☐ Inherited from pre-existing authorization

Part a

_{Customer Responsibility

}_

Government customers are responsible for establishing terms and conditions

allowing authorized individuals to access M365 from customer-controlled

networks and workstations.

_{M365

}_

Part 1, 2

All groups supporting M365 utilize Microsoft issued external information

systems (Laptops, Desktops, etc.). All personnel are required to maintain

secure computer configurations.

M365 has in place an Interconnection Security Agreement (ISA) with Akamai.

The security policy and ISAs/MOUs address the terms and conditions for

accessing M365 data on these external platforms. M365 Trust is responsible

for developing the ISAs/MOUs. ISAs/MOUs are reviewed annually.

With regard to trust relationships established with other organizations

owning, operating, and/or maintaining external information systems, vendors

are required to use the Microsoft provided OS images which meet the

requirements of Network Access Control/Network Access Protection (NAC/NAP)

controls.

Microsoft has also developed the Master Supplier Services Agreement (MSSA)

that vendors and contractors are required to sign to ensure compliance with

Microsoft policies on required engagements.

Through the use of these policies, vendor agreements, ISAs and MOUs establish

conditions for allowing access to M365 from external information systems.

Part b

_{M365

}_

M365 prohibits the use of external systems that do not meet the requirements

of policies and documentation as defined in AC-20(a).

Responsible Role:

Customer Administrator, M365 Trust Program Manager

Implementation Status

(check all that apply):

☐ Implemented

☐ Partially implemented

☐ Planned

☒ Alternative implementation

☐ Not applicable

Control Origination

(check all that apply):

☐ Service Provider Corporate

☐ Service Provider System Specific

☐ Service Provider Hybrid (Corporate and System Specific)

☐ Configured by Customer (Customer System Specific)

☐ Provided by Customer (Customer System Specific)

☒ Shared (Service Provider and Customer Responsibility)

☐ Inherited from pre-existing authorization

Part a

_{Customer Responsibility

}_

Government customers are responsible for verifying the implementation of

organizationally required security and privacy controls on customer

workstations , including W365 virtual machines, in compliance with

organizational policies.

_{M365

}_

M365 only allows remote connections via secure remote desktops known as

Secure Access Workstations (SAWs). These remote desktop sessions are locked

down to only allow very limited and specific access. This access does not

allow broad network access into production by the remote machines. The

network access is limited to one specific protocol, and traffic is only

allowed to specific bastion machines.

Additionally, M365 has implemented compensating controls outlined below:

• Minimal amount of data can be copied. There is a buffer limit on the

clipboard.

• M365 requires Two-Factor Authentication (2FA).

• The M365 Security Incident Response capability is improved through unifying

the available remote access methods.

• M365 requires Just-In-Time (JIT) access, limiting access into production.

• External devices are logically prevented from connecting to the production

environment.

• Aggressive idle time-outs are in place.

• All M365 administrators are required to take security training.

• No customer content is processed, stored, or transmitted.

• All connections are encrypted via TLS 1.2 or higher.

Part b

_{M365

}_

All personnel accessing the environment via Microsoft-issued external

information systems (laptops, desktops, etc.) agree to maintain their remote

computer in a secure manner, in accordance with organizational security

policies and procedures. Microsoft IT (MSIT) is responsible for enforcing

compliance with organizational security policies and procedures.

Responsible Role:

Customer Administrator, M365 Security Manager, M365 Trust Program Manager

Parameter AC-20(02):

policies and documentation

Implementation Status

(check all that apply):

☒ Implemented

☐ Partially implemented

☐ Planned

☐ Alternative implementation

☐ Not applicable

Control Origination

(check all that apply):

☐ Service Provider Corporate

☐ Service Provider System Specific

☐ Service Provider Hybrid (Corporate and System Specific)

☐ Configured by Customer (Customer System Specific)

☐ Provided by Customer (Customer System Specific)

☒ Shared (Service Provider and Customer Responsibility)

☒ Inherited from pre-existing authorization for Azure Government

(F1603087869), 4/17/2020

_{Customer Responsibility

}_

Government customers are responsible for limiting the use of

organization-controlled portable storage media by authorized individuals on

customer workstations connected to M365 in compliance with organizational

policies.

_{M365

}_

M365 prohibits any organization-controlled portable storage media through

policies and documentation covered in AC-20.

Responsible Role:

Customer Administrator

Parameter AC-21(a):

Information sharing circumstances where user discretion is required

Parameter AC-21(b):

Automated mechanisms and manual processes

Implementation Status

(check all that apply):

☒ Implemented

☐ Partially implemented

☐ Planned

☐ Alternative implementation

☐ Not applicable

Control Origination

(check all that apply):

☐ Service Provider Corporate

☐ Service Provider System Specific

☐ Service Provider Hybrid (Corporate and System Specific)

☒ Configured by Customer (Customer System Specific)

☐ Provided by Customer (Customer System Specific)

☐ Shared (Service Provider and Customer Responsibility)

☐ Inherited from pre-existing authorization

Part a

_{Customer Responsibility

}_

Government customers may choose to share their information/content in

accordance with their security policies and are responsible for enabling

authorized customer users to determine whether access authorizations assigned

to the sharing partner match the access restrictions on the information being

shared.

_{M365

}_

M365 employees are not allowed to share M365 data or customer content outside

the security boundary.

Part b

_{Customer Responsibility

}_

Government customers who choose to share their information/content are

responsible for employing automated mechanisms or manual processes to assist

users in making information sharing/collaboration decisions.

_{M365

}_

M365 employees are not allowed to share M365 data or customer content outside

the security boundary and thus do not make discretionary sharing decisions.

Parameter AC-22(d): At

least quarterly

Implementation Status

(check all that apply):

☒ Implemented

☐ Partially implemented

☐ Planned

☐ Alternative implementation

☐ Not applicable

Control Origination

(check all that apply):

☐ Service Provider Corporate

☒ Service Provider System Specific

☐ Service Provider Hybrid (Corporate and System Specific)

☐ Configured by Customer (Customer System Specific)

☐ Provided by Customer (Customer System Specific)

☐ Shared (Service Provider and Customer Responsibility)

☐ Inherited from pre-existing authorization

Part a

_{M365

}_

The only actions permitted by M365 to be performed on the system without

authentication are accessing the Legal, Privacy Statement, Help, and Language

Preference options on the welcome page. M365 has designated Corporate,

External and Legal Affairs (CELA) as the group authorized to make changes to

this limited public information. CELA attorneys are trained in screening

public content for non-public information and are required to earn Continuing

Professional Education credits (CPEs) to maintain their licenses.

Part b

_{M365

}_

The content of the information is vetted through CELA which includes

attorneys who are trained in screening public content for non-public content

and are required to earn Continuing Professional Education credits (CPEs) to

maintain their licenses.

Part c

_{M365

}_

All information must go through CELA for review prior to being posted to

ensure nonpublic information is not made available. This review occurs as

part of normal change management processes.

Part d

_{M365

}_

CELA reviews publicly disclosed information on Microsoft sites. Additionally,

all publicly available white papers are updated and reviewed by the Marketing

and Communications team on a quarterly basis.

If any nonpublic information is identified as part of reviews, the M365

incident response process is followed to investigated and remediate the

issue.

Responsible Role:

Customer Administrator, M365 Trust Program Manager

Parameter AT-01(a):

all personnel

Parameter AT-01(a)(1):

organization-level

Parameter

AT-01(b): Appropriate service team

personnel, security engineering teams, service provider personnel with

authority on awareness and training policies

Parameter

AT-01(c)(1)-1: at least annually

Parameter

AT-01(c)(1)-2: significant changes

Parameter

AT-01(c)(2)-1: at least annually

Parameter

AT-01(c)(2)-2: significant changes

Implementation Status

(check all that apply):

☒ Implemented

☐ Partially implemented

☐ Planned

☐ Alternative implementation

☐ Not applicable

Control Origination

(check all that apply):

☐ Service Provider Corporate

☐ Service Provider System Specific

☐ Service Provider Hybrid (Corporate and System Specific)

☐ Configured by Customer (Customer System Specific)

☐ Provided by Customer (Customer System Specific)

☒ Shared (Service Provider and Customer Responsibility)

☐ Inherited from pre-existing authorization

Part a

_{Customer Responsibility

}_

Government customers are responsible for developing and maintaining

appropriate Access and Training policies that govern security awareness

training activities for their organization and users.

_{M365

}_

Part 1

The M365 Information Security Policy provides the overarching security

guidance for M365policies. This document addresses the purpose, scope, roles,

responsibilities, compliance requirements, and required coordination among

the various Microsoft organizations providing some level of support for the

security of M365. Policies are made available to personnel responsible for

implementing awareness and training policies and procedures via SharePoint.

Part 2

The M365 Information Security Policy contains policies that must be met in

the delivery and operation of M365. Standards and procedures to facilitate

execution of these policies are documented in the M365 SOPs and service

team-specific SOPs. These standards and procedures act as adjuncts to the

security policy and provide implementation level requirements and details to

carry out specific operational tasks. A detailed mapping of M365 standards

and procedures to each control is available for review. M365 SOPs are

distributed via SharePoint.

Part b

_{Customer Responsibility

}_

Government customers are responsible for designating an organization-defined

official to manage the development, documentation, and dissemination of their

organization's awareness and training policy and procedures.

_{M365

}_

The "M365 Information Security Policy" provides the overarching

security guidance for M365. This document addresses the purpose, scope,

roles, responsibilities, compliance requirements, and required coordination

among the various Microsoft organizations providing some level of support for

the security of M365. Policies are distributed to personnel responsible for

implementing awareness and training policies and procedures via SharePoint.

The "M365 Information Security Policy" is reviewed and updated

annually.

Part c

_{Customer Responsibility

}_

Government customers are responsible for annually updating Awareness and

Training policies and procedures.

_{M365

}_

Part 1

The M365 Information Security Policy is reviewed and updated at least

annually by the M365 Trust team.

Part 2

The M365 SOPs are reviewed and updated at least annually or whenever a

significant change occurs.

Responsible Role:

Customer Administrator, M365 Trust Program Manager, Program Manager

Parameter AT-02(a)(1):

At least annually

Parameter AT-02(a)(2):

significant changes, new employee onboarding, or prior to accessing the

system

Parameter AT-02(b):

consistency, repetition

Parameter AT-02(c)-1:

At least annually

Parameter AT-02(c)-2:

security or privacy incidents

Implementation Status

(check all that apply):

☒ Implemented

☐ Partially implemented

☐ Planned

☐ Alternative implementation

☐ Not applicable

Control Origination

(check all that apply):

☐ Service Provider Corporate

☐ Service Provider System Specific

☐ Service Provider Hybrid (Corporate and System Specific)

☐ Configured by Customer (Customer System Specific)

☐ Provided by Customer (Customer System Specific)

☒ Shared (Service Provider and Customer Responsibility)

☐ Inherited from pre-existing authorization

Part a

_{Customer Responsibility

}_

Government customers are responsible for providing security awareness

training to their employees and vendors as necessary, including training on

security awareness training and role-based training, as appropriate per job

description. This training shall include requirements that customer users not

bypass M365 security through actions such as:

1. Improperly forwarding documentation through Exchange Online

2. Circumventing, disabling, or downgrading session-level encryption

3. Improperly securing documentation hosted in SharePoint Online

_{M365

}_

Part 1

M365 provides security and privacy awareness training to all information

system users (including managers, senior executives, and contractors) as part

of initial training for new users. This is accomplished by requiring all

staff to take a New Employee Orientation (NEO) security awareness training

course, Standards of Business Conduct, within the first 30 days of their

employment or transfer into the organization. This training course is

facilitated by Core Services Engineering (CSE) and Corporate Security, and

encompasses standard business security measures, basic information security,

and user actions to maintain security and to respond to suspected security

incidents.

In addition, all staff are required to take security and privacy awareness

training annually after their initial training. M365 has implemented the

security training control by requiring all new users (employees and

contractors) to take the initial security and privacy awareness training

annually. Non-operational personnel, anyone that is involved in development

and quality assurance, are also required to take the mandatory training. In

addition, training related to the system being accessed, along with associated

procedures, may be required. Security training is also required when there is

a significant change to the system environment.

Part 2

M365 provides security and privacy awareness training to all information

system users (including managers, senior executives, and contractors) when

required by system changes. This is accomplished by requiring all staff to

take a New Employee Orientation (NEO) security awareness training course,

Standards of Business Conduct, within the first 30 days of their employment or

transfer into the organization. This training course is facilitated by CSE

and Corporate Security, and encompasses standard business security measures,

information security, and user actions to maintain security and to respond to

suspected security incidents.

In addition, all staff are required to take security and privacy awareness

training annually after their initial training. M365 has implemented the

security training control by requiring all new users (employees and

contractors) to take the initial security and privacy awareness training at

least annually. Non-operational personnel, anyone that is involved in

development and quality assurance, are also required to take the mandatory

training. In addition, training related to the system being accessed, along

with associated procedures, may be required. Security training is also

required when there is a significant change to the system environment.

Part b

M365 requires all information system users (including managers, senior

executives, and contractors) to take Security and Privacy Foundations

training as part of their initial training and annually thereafter.

Consistent and repetitive training for all users helps to ensure that

personnel understand privacy responsibilities and procedures.

Part c

_{M365

}_

Security Foundations Training trainings are updated on a regular basis to

account for updates or changes that render previous training inaccurate. The

trainings are sent to personnel through automated learning system

communications. Training completions are documented and retained for

investigation purposes. Additionally, service teams update training materials

after security or privacy incidents.

Part d

Annual Security Foundations Training includes basic level training on how to

detect, report and implement best practices to safeguard Microsoft and its

customers. Service teams incorporate lessons learned into training materials

as part of their incident post-mortem process.

Responsible Role:

Customer Administrator, M365 Trust Program Manager, Program Manager

Implementation Status

(check all that apply):

☒ Implemented

☐ Partially implemented

☐ Planned

☐ Alternative implementation

☐ Not applicable

Control Origination

(check all that apply):

☐ Service Provider Corporate

☐ Service Provider System Specific

☐ Service Provider Hybrid (Corporate and System Specific)

☐ Configured by Customer (Customer System Specific)

☐ Provided by Customer (Customer System Specific)

☒ Shared (Service Provider and Customer Responsibility)

☐ Inherited from pre-existing authorization

_{Customer Responsibility

}_

Government customers should provide security awareness training to their

users that includes content related to recognizing and reporting potential

indicators of insider threat.

_{M365

}_

M365 security and privacy awareness training includes content related to

recognizing and reporting potential indicators of insider threat.

Responsible Role:

Customer Administrator, M365 Trust Program Manager, Program Manager

Implementation Status

(check all that apply):

☒ Implemented

☐ Partially implemented

☐ Planned

☐ Alternative implementation

☐ Not applicable

Control Origination

(check all that apply):

☐ Service Provider Corporate

☐ Service Provider System Specific

☐ Service Provider Hybrid (Corporate and System Specific)

☐ Configured by Customer (Customer System Specific)

☐ Provided by Customer (Customer System Specific)

☒ Shared (Service Provider and Customer Responsibility)

☐ Inherited from pre-existing authorization

_{Customer Responsibility

}_

Government customers should provide security awareness training to their

users that includes content related to recognizing and reporting potential

and actual instances of social engineering and social mining.

_{M365

}_

M365 security and privacy awareness training includes content related to

recognizing and reporting potential and actual instances of social

engineering and social mining.

Responsible Role:

Customer Administrator, M365 Trust Program Manager, Program Manager

Parameter AT-03(a):

all personnel accessing the system

Parameter AT-03(a)(1):

at least annually

Parameter AT-03(b)-1:

at least annually

Parameter AT-03(b)-2:

new employee onboarding, security or privacy incidents

Implementation Status

(check all that apply):

☒ Implemented

☐ Partially implemented

☐ Planned

☐ Alternative implementation

☐ Not applicable

Control Origination

(check all that apply):

☐ Service Provider Corporate

☐ Service Provider System Specific

☐ Service Provider Hybrid (Corporate and System Specific)

☐ Configured by Customer (Customer System Specific)

☐ Provided by Customer (Customer System Specific)

☒ Shared (Service Provider and Customer Responsibility)

☐ Inherited from pre-existing authorization

Part a

_{Customer Responsibility

}_

Government customers are responsible for providing role-based training to

their employees and vendors as necessary, including training on basic

security awareness training and role-based training, as appropriate per job

description. This training shall include requirements that customer users not

bypass M365 security through actions such as:

1. Improperly forwarding documentation through Exchange Online

2. Circumventing, disabling, or downgrading session-level encryption.

3. Improperly securing documentation hosted in SharePoint Online

_{M365

}_

Part 1

M365 provides role-based security-related training before authorizing access

to the system or performing assigned duties, and at least annually

thereafter.

Part 2

M365 provides role-based security-related training before authorizing access

to the system or when required by information system changes.

Part b

_{Customer Responsibility

}_

Government customers are responsible for providing role-based security

training to their employees and vendors as necessary (at least annually for

government customers relying on FedRAMP certification).

_{M365

}_

M365 service teams review and update role-based training content at least

annually and throughout new employee onboarding. Additionally, service teams

update training materials after security or privacy incidents.

Part c

Service teams incorporate lessons learned into training materials as part of

their incident post-mortem process.

Responsible Role: M365

Trust Program Manager

Parameter AT-04(b):

five (5) years or 5 years after completion of a specific training program

Implementation Status

(check all that apply):

☒ Implemented

☐ Partially implemented

☐ Planned

☐ Alternative implementation

☐ Not applicable

Control Origination

(check all that apply):

☐ Service Provider Corporate

☒ Service Provider System Specific

☐ Service Provider Hybrid (Corporate and System Specific)

☐ Configured by Customer (Customer System Specific)

☐ Provided by Customer (Customer System Specific)

☐ Shared (Service Provider and Customer Responsibility)

☐ Inherited from pre-existing authorization

Part a

_{M365

}_

M365 utilizes corporate training tools to document and monitor security

training. Corporate training tools provides a report, which tracks who has

taken the basic security awareness and specific information system training.

Each employee has access to their own account, which includes courses taken

and elective courses that are suggested. A report can be generated from this

tool to show what courses were taken by a specific employee.

Part b

_{M365

}_

M365 utilizes corporate training tools to retain employee training records

for basic security awareness and specific information system security

training for at least 5 years.

Responsible Role:

Customer Administrator, M365 Trust Program Manager

Parameter AU-01(a):

The ISSO and ISSM and others as the local organization deems appropriate

Parameter AU-01(a)(1):

organization-level

Parameter

AU-01(b): Appropriate service team

personnel, security engineering teams, service provider personnel with

authority on audit and accountability policies

Parameter

AU-01(c)(1)-1: at least annually

Parameter

AU-01(c)(1)-2: significant changes

Parameter

AU-01(c)(2)-1: At least annually

Parameter

AU-01(c)(2)-2: significant changes

Implementation Status

(check all that apply):

☒ Implemented

☐ Partially implemented

☐ Planned

☐ Alternative implementation

☐ Not applicable

Control Origination

(check all that apply):

☐ Service Provider Corporate

☐ Service Provider System Specific

☐ Service Provider Hybrid (Corporate and System Specific)

☐ Configured by Customer (Customer System Specific)

☐ Provided by Customer (Customer System Specific)

☒ Shared (Service Provider and Customer Responsibility)

☐ Inherited from pre-existing authorization

Part a

_{Customer Responsibility

}_

Government customers are responsible for developing and maintaining

appropriate Audit and Accountability policies that govern auditing activities

for their organization and users.

_{M365

}_

Part 1

The M365 Information Security Policy provides the overarching security

guidance for M365. This document addresses the purpose, scope, roles,

responsibilities, compliance requirements, and required coordination among

the various Microsoft organizations providing some level of support for the

security of M365. The M365 Information Security Policy is distributed to

personnel responsible for implementing audit and accountability policies via

SharePoint.

Part 2

The M365 Information Security Policy contains policies that must be met in

the delivery and operation of M365 MT. Standards and procedures to facilitate

execution of the M365 Information Security Policy are documented in the M365

Standard Operating Procedures (SOPs) and service team-specific SOPs. These

standards and procedures act as adjuncts to the security policy and provide

implementation level requirements and details to carry out specific

operational tasks. A detailed mapping of M365 Standards and Procedures to

each control is available for review. M365 SOPs are distributed via

SharePoint.

Part b

_{Customer Responsibility

}_

Government customers are responsible for designating an organization-defined

official to manage the development, documentation, and dissemination of their

organization's audit and accountability policy and procedures.

_{M365

}_

The "M365 Information Security Policy" provides the overarching

security guidance for M365. This document addresses the purpose, scope,

roles, responsibilities, compliance requirements, and required coordination

among the various Microsoft organizations providing some level of support for

the security of M365. Policies are distributed to personnel responsible for

implementing audit and accountability policies and procedures via SharePoint.

The "M365 Information Security Policy" is reviewed and updated

annually.

Part c

_{Customer Responsibility

}_

Government customers are responsible for developing and maintaining

appropriate Audit and Accountability policies that govern auditing activities

for their organization and users.

_{M365

}_

Part 1

The M365 Information Security Policy is reviewed and updated at least

annually.

Part 2

The M365 (SOPs) are reviewed and updated at least annually or whenever a

significant change occurs.

Responsible Role:

Customer Administrator, M365 Security Manager, M365 Trust Program Manager,

Service Engineer Operations

Parameter AU-02(a):

successful and unsuccessful account logon events, account management events,

object access, policy change, privilege functions, process tracking, and

system events. For Web applications: all administrator activity,

authentication checks, authorization checks, data deletions, data access,

data changes, and permission change

Parameter AU-02(c):

All auditable events defined in AU-2 (a) per occurrence.

Parameter AU-02(e):

annually and whenever there is a change in the threat environment

Implementation Status

(check all that apply):

☒ Implemented

☐ Partially implemented

☐ Planned

☐ Alternative implementation

☐ Not applicable

Control Origination

(check all that apply):

☐ Service Provider Corporate

☐ Service Provider System Specific

☐ Service Provider Hybrid (Corporate and System Specific)

☐ Configured by Customer (Customer System Specific)

☐ Provided by Customer (Customer System Specific)

☒ Shared (Service Provider and Customer Responsibility)

☒ Inherited from pre-existing authorization for Azure Government

(F1603087869), 4/17/2020

Part a

_{Customer Responsibility

}_

Government customers are responsible for auditing account creation,

modification, disabling, and deletion events for their Active Directory

infrastructure as these events also pertain to M365 access.

For more information on how to configure auditing of account management, see

the following link:

<https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/audit-policy-recommendations>.

W365:

Government customers using Windows 365 are responsible for configuring audit

policies on their VMs that meet organizational and compliance requirements.

_{M365

}_

The M365 Security team has developed a set of auditable events specific to

the M365 based on ongoing risk assessments of the system which incorporate

identified vulnerabilities, business requirements, and M365 Security

standards. The M365 Security team specifies each event that must be audited

for all servers.

M365 is capable of auditing these events on devices within the boundary.

For teams on PilotFish or Azure PaaS, the Azure Cyber Defense Operations

Center (CDOC) team has developed a set of auditable events which incorporates

identified vulnerabilities, business requirements, and security standards.

Implementation of this control is inherited from Azure for M365 services

using inherited compute.

Part b

_{M365

}_

M365 Security incorporates business requirements from M365 as a whole and

coordinates security audit functions from individual service teams to enhance

mutual support and to help guide the selection of auditable events.

Part c

_{M365

}_

The M365 Security team specifies each event that must be audited for all

servers. Events are audited continually.

For teams on PilotFish or Azure PaaS, the Azure CDOC team has developed a set

of auditable events which incorporates identified vulnerabilities, business

requirements, and security standards. Events are audited continually.

Part d

_{M365

}_

The M365 Security and Engineering teams select auditable events based on

documented investigation procedures. M365 Security has determined that the

general and server-role event sets are adequate to support after-the-fact

investigations.

For teams on PilotFish or Azure PaaS, the Azure CDOC team has developed a set

of auditable events which incorporates identified vulnerabilities, business

requirements, and security standards.

Part e

_{Customer Responsibility

}_

Government and non-government customers are responsible for reviewing and

updating the event types selected for logging on customer-deployed resources

at least annually.

_{M365

}_

Default logging configurations provided by Kevlar are reviewed at least

annually or whenever changes in the threat environment are communicated to

the service provider by the FedRAMP board or AO. Additional logging and

configuration of audit logs by service teams are reviewed and updated at

least annually or whenever there are significant changes in the threat

environment.

Logging and monitoring provided by AzSecPack is inherited from Azure.

Responsible Role:

Customer Administrator, M365 Security Manager, M365 Trust Program Manager,

Service Engineer Operations

Implementation Status

(check all that apply):

☒ Implemented

☐ Partially implemented

☐ Planned

☐ Alternative implementation

☐ Not applicable

Control Origination

(check all that apply):

☐ Service Provider Corporate

☐ Service Provider System Specific

☐ Service Provider Hybrid (Corporate and System Specific)

☐ Configured by Customer (Customer System Specific)

☐ Provided by Customer (Customer System Specific)

☒ Shared (Service Provider and Customer Responsibility)

☒ Inherited from pre-existing authorization for Azure Government

(F1603087869), 4/17/2020

Part a

_{Customer Responsibility

}_

Government customers are responsible for auditing account creation,

modification, disabling, and deletion events for their Active Directory

infrastructure as these events also pertain to M365 access. For these events,

these government customers are responsible for capturing what type of event

occurred, when (date and time) the event occurred, where the event occurred,

the source of the event, the outcome (success or failure) of the event, and

the identity of any user/subject associated with the event. Government

customers using Windows servers to support their infrastructure automatically

meet this requirement as Windows captures these event details by default.

For more information regarding Windows event logging, see the following link:

<https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/plan/appendix-l--events-to-monitor>.

W365:

Government customers using Windows 365 are responsible for configuring audit

policies on their VMs that meet organizational and compliance requirements.

_{M365

}_

Per the M365 Security team, auditable events are required to contain the

following information at a minimum to establish what events occurred, the

sources of the events, and the outcomes of the events:

• Source User ID

• Target User ID – as relevant/appropriate for event type

• Event timestamp (Date & Time)

• Event details

• Type

• Outcome (success/failure)

• Detail information – defined per event type

• Source & Target Hostname – as relevant/appropriate for event type

• Source & Target network addresses and protocols – as

relevant/appropriate for event type

This information is sufficient to identify the event type, source, location,

outcome, time and the entity associated with the event (device or user). All

auditable events captured in Windows event logs contain the minimum

information required and, in many cases, additional information is captured.

M365 does not filter any of the content generated.

Implementation of this control is inherited from Azure for M365 services

using inherited compute.

Part b

See part a.

Part c

See part a.

Part d

See part a.

Part e

See part a.

Part f

See part a.

Responsible Role: M365

Security Manager, M365 Trust Program Manager, Service Engineer Operations

Parameter AU-03(01):

session, connection, transaction, or activity duration; for client-server

transactions, the number of bytes received and bytes sent; additional

informational messages to diagnose or identify the event; characteristics

that describe or identify the object or resource being acted upon; individual

identities of group account users; full-text of privileged commands

Implementation Status

(check all that apply):

☒ Implemented

☐ Partially implemented

☐ Planned

☐ Alternative implementation

☐ Not applicable

Control Origination

(check all that apply):

☐ Service Provider Corporate

☒ Service Provider System Specific

☐ Service Provider Hybrid (Corporate and System Specific)

☐ Configured by Customer (Customer System Specific)

☐ Provided by Customer (Customer System Specific)

☐ Shared (Service Provider and Customer Responsibility)

☐ Inherited from pre-existing authorization

_{M365

}_

M365 generates audit records containing sufficient information to establish

the type of event that occurred, when the event occurred, where the event

occurred, the source of the event, the outcome of the event, and the identity

of any user/subject associated with the event. M365 Windows servers are

configured to utilize the following fields:

• Source User ID

• Target User ID – as relevant/appropriate for event type

• Event timestamp (Date & Time)

• Event details

• Type

• Outcome (success/failure)

• Detail information – defined per event type

• Source & Target Hostname – as relevant/appropriate for event type

• Source & Target network addresses and protocols – as

relevant/appropriate for event type

Responsible Role:

Customer Administrator, Service Engineer Operations

Parameter AU-04:

Ability to retain at least one (1) year worth of logs

Implementation Status

(check all that apply):

☒ Implemented

☐ Partially implemented

☐ Planned

☐ Alternative implementation

☐ Not applicable

Control Origination

(check all that apply):

☐ Service Provider Corporate

☐ Service Provider System Specific

☐ Service Provider Hybrid (Corporate and System Specific)

☐ Configured by Customer (Customer System Specific)

☐ Provided by Customer (Customer System Specific)

☒ Shared (Service Provider and Customer Responsibility)

☒ Inherited from pre-existing authorization for Azure Government

(F1603087869), 4/17/2020

_{Customer Responsibility

}_

Government customers are responsible for auditing account creation,

modification, disabling, and deletion events for their Active Directory

infrastructure as these events also pertain to M365 access. For these events,

these customers are responsible for allocating audit record storage capacity

and configuring auditing to reduce the likelihood of such capacity being

exceeded.

For more information regarding configuring event logging in Windows,

including setting the maximum log size, see the following link:

<https://learn.microsoft.com/en-us/windows-server/administration/server-manager/view-and-configure-performance-event-and-service-data>.

_{M365

}_

M365 utilizes a repository service to store audit information. The repository

service dynamically allocates audit storage space to M365. If it nears the

limits of the storage capacity currently allocated, additional space is

automatically assigned; the likelihood of audit storage capacity being

exceeded is reduced by this dynamic model where allocated audit storage

capacity grows with need. The repository service keeps at minimum ten

petabytes free at any given time for dynamic allocation.

Azure is responsible for managing all network device logs. Azure implements

audit storage capacity through a capacity planning procedure of both

processing and storage requirements to ensure adequate resources are

available for Azure. Due to the high volume of events received on servers and

network devices, Azure audit collection settings are to overwrite when

capacity is exceeded. Azure currently defines baseline requirements for local

security audit log storage capacity to a window of at least 10 minutes of

events on Azure's most-active hosts. Events are continuously sent to the

Syslog and Windows Event Collector, which are monitored by the C+AI Security

Engineering Team, that have adequate storage capacity to handle the volume of

events captured. In addition, collector data is archived via the event

archive process for Syslog and Windows Event Collector, which are maintained

for 180 days. In the event of an audit failure or audit storage capacity

being reached, monitoring tools generate near-real time alerts to the C+AI

Security Engineering Team, who are assigned to address the processing

failure. M365 service teams follow the Data Handling Standard (DHS) for

security logs. DHS defines the minimum retention period for these logs to be

at least one year.

Implementation of this control is inherited from Azure for M365 services

using inherited compute.

Responsible Role:

Customer Administrator, M365 Security Manager, M365 Trust Program Manager,

Service Engineer Operations

Parameter AU-05(a)-1:

Service Engineer Operations personnel, M365 Security Manager if confirmed

Parameter AU-05(a)-2:

near real time

Parameter AU-05(b):

overwrite oldest record

Implementation Status

(check all that apply):

☒ Implemented

☐ Partially implemented

☐ Planned

☐ Alternative implementation

☐ Not applicable

Control Origination

(check all that apply):

☐ Service Provider Corporate

☐ Service Provider System Specific

☐ Service Provider Hybrid (Corporate and System Specific)

☐ Configured by Customer (Customer System Specific)

☐ Provided by Customer (Customer System Specific)

☒ Shared (Service Provider and Customer Responsibility)

☒ Inherited from pre-existing authorization for Azure Government

(F1603087869), 4/17/2020

Part a

_{Customer Responsibility

}_

Government customers are responsible for auditing account creation,

modification, disabling, and deletion events for their Active Directory

infrastructure as these events also pertain to M365 access. For these events,

these customers are responsible for alerting designated organizational

officials in the event of an audit processing failure.

_{M365

}_

Service teams use monitoring agents to verify that audit logs are being

generated by systems and uploaded to a repository service. Audit processing

failures generate alerts that are reported to Service Engineer Operations

personnel and escalated to M365 Security as appropriate. Service engineers

act as the designee of the Security Control Assessor (SCA)/ISSO. Automated

alerts are generated at near real time.

If M365 support nears the limits of the storage capacity currently allocated,

additional space is assigned and the appropriate service team is alerted of

the issue.

Implementation of this control is inherited from Azure for M365 services

using inherited compute.

Part b

_{Customer Responsibility

}_

Government customers are responsible for auditing account creation,

modification, disabling, and deletion events for their Active Directory

infrastructure as these events also pertain to M365 access. For these events,

these customers are responsible for defining actions to be taken, in

compliance with organizational policy, in the event of an audit processing

failure.

For more information regarding configuring a log retention policy in Windows,

see the following link: <https://learn.microsoft.com/en-us/purview/audit-log-retention-policies>.

_{M365

}_

All audit logs are retained in a repository. In the event of an audit

processing failure, an IcM engineer is alerted and will handle the failure

according to the SOP.

Responsible Role:

Customer Administrator, M365 Security Manager, M365 Trust Program Manager,

Service Engineer Operations

Parameter AU-05(01)-1:

Service Engineer Operations personnel, M365 Security Manager if confirmed

Parameter AU-05(01)-2:

Twenty-four (24) hours

Parameter AU-05(01)-3:

75%, or one month before expected negative impact

Implementation Status

(check all that apply):

☒ Implemented

☐ Partially implemented

☐ Planned

☐ Alternative implementation

☐ Not applicable

Control Origination

(check all that apply):

☐ Service Provider Corporate

☐ Service Provider System Specific

☐ Service Provider Hybrid (Corporate and System Specific)

☐ Configured by Customer (Customer System Specific)

☐ Provided by Customer (Customer System Specific)

☒ Shared (Service Provider and Customer Responsibility)

☐ Inherited from pre-existing authorization

_{Customer Responsibility

}_

Government customers are responsible for configuring an audit record storage

capacity warning for customer-deployed resources including the percentage of

storage capacity at which a warning is required; the time period within which

the warning must occur; and the personnel, roles, and/or locations to be

notified.

_{M365

}_

M365 utilizes a repository service to store audit information. The repository

service alerts the appropriate service team within 24 hours and dynamically

allocates additional audit storage space if it nears the limits of the

storage capacity currently allocated.

Responsible Role:

Customer Administrator, M365 Security Manager, M365 Trust Program Manager,

Service Engineer Operations

Parameter AU-05(02)-1:

real-time

Parameter AU-05(02)-2:

service provider personnel with authority to address failed audit events

Parameter AU-05(02)-3:

Audit failure events defined by each service team such as hardware, software

failures, nearing storage capacity

Implementation Status

(check all that apply):

☒ Implemented

☐ Partially implemented

☐ Planned

☐ Alternative implementation

☐ Not applicable

Control Origination

(check all that apply):

☐ Service Provider Corporate

☐ Service Provider System Specific

☐ Service Provider Hybrid (Corporate and System Specific)

☐ Configured by Customer (Customer System Specific)

☐ Provided by Customer (Customer System Specific)

☒ Shared (Service Provider and Customer Responsibility)

☐ Inherited from pre-existing authorization

_{Customer Responsibility

}_

Government customers are responsible for auditing account creation,

modification, disabling, and deletion events for their Active Directory

infrastructure as these events also pertain to M365 access. For these events,

these customers are responsible for providing real-time alerts for audit

event failures.

_{M365

}_

Audit logs are uploaded to a repository service from all servers in the M365

environment.

M365 Security requires service teams to analyze information system audit

records through the implementation of near real-time monitoring. Each team

has implemented alerting within 15 minutes for specific events they have

identified as indicators of inappropriate or unusual activity. Tools used for

monitoring generate actionable reports that the service teams can use to

correct vulnerabilities and improve any weaknesses found. Findings are

reported and escalated using standard security incident management channels:

ticketing tools are used for tracking, and the M365 Security team is engaged

when appropriate.

Responsible Role:

Customer Administrator, M365 Security Manager, M365 Trust Program Manager,

Service Engineer Operations

Parameter AU-06(a)-1:

at least weekly

Parameter AU-06(a)-2:

Indicators of compromise identified by M365 Security

Parameter AU-06(b):

M365 Security Manager and at a minimum, the ISSO and ISSM

Implementation Status

(check all that apply):

☒ Implemented

☐ Partially implemented

☐ Planned

☐ Alternative implementation

☐ Not applicable

Control Origination

(check all that apply):

☐ Service Provider Corporate

☐ Service Provider System Specific

☐ Service Provider Hybrid (Corporate and System Specific)

☐ Configured by Customer (Customer System Specific)

☐ Provided by Customer (Customer System Specific)

☒ Shared (Service Provider and Customer Responsibility)

☒ Inherited from pre-existing authorization for Azure Government

(F1603087869), 4/17/2020

Part a

_{Customer Responsibility

}_

Government customers are responsible for auditing account creation,

modification, disabling, and deletion events for their Active Directory

infrastructure as these events also pertain to M365 access. For these events,

these customers are responsible for reviewing and analyzing information

system audit records for indications of inappropriate or unusual activity (at

least weekly for FedRAMP compliance), and for reporting findings to

designated organizational officials. Customers can view these alerts through

the Admin Portal.

_{M365

}_

Audit logs are uploaded to a repository service from all servers in the M365

environment. Each service team receives near real-time alerting on security

events through various alerting tools and reports can be generated from the

alerts and from the uploader service. Each team is responsible for reviewing

and analyzing the alerts for indications of inappropriate or unusual

activity, including indications of compromise. Findings are reported and

escalated using standard security incident management channels: Tickets are

opened to track these security incidents using ticket tracking software and

the M365 Security team is engaged when appropriate.

Implementation of this control is inherited from Azure for M365 services

using inherited compute.

Part b

_{M365

}_

Service teams report and escalate findings to the M365 Security team when

appropriate, who in turn follow the process defined in the M365 Security

Incident Response Plan. The M365 Security Incident Response team acts as the

designee of the ISSM or ISSO.

Part c

_{Customer Responsibility

}_

Government customers are responsible for adjusting the level of audit review,

analysis, and reporting for customer-deployed resources when there is a

change in risk based on information provided by law enforcement,

intelligence, or other credible sources.

_{M365

}_

M365 Security reviews and updates audit analysis, review, and reporting

procedures at least annually or whenever changes in the threat environment

are communicated to M365 by the FedRAMP board. M365 Security notifies service

teams if a change in the level of monitoring is necessary due to indications

of increased risk, and service teams adjust monitoring accordingly.

Responsible Role:

Customer Administrator, M365 Security Manager, M365 Trust Program Manager,

Service Engineer Operations

Parameter AU-06(01):

security alerting tools

Implementation Status

(check all that apply):

☒ Implemented

☐ Partially implemented

☐ Planned

☐ Alternative implementation

☐ Not applicable

Control Origination

(check all that apply):

☐ Service Provider Corporate

☐ Service Provider System Specific

☐ Service Provider Hybrid (Corporate and System Specific)

☐ Configured by Customer (Customer System Specific)

☐ Provided by Customer (Customer System Specific)

☒ Shared (Service Provider and Customer Responsibility)

☐ Inherited from pre-existing authorization

_{Customer Responsibility

}_

Government customers are responsible for auditing account creation,

modification, disabling, and deletion events for their Active Directory

infrastructure as these events also pertain to M365 access. For these events,

these customers are responsible for utilizing automated tools for integrating

audit review, analysis, and reporting processes to support organizational

processes for investigation and response to suspicious activities.

_{M365

}_

M365 Security uses automated security alerting tools to review and analyze

the audit logs. Each service team also receives Near Real Time (NRT) alerting

on security events through various first party NRT alerting. Reports can be

generated from the alerting tools or from an uploader service. M365 Security

manages both audit monitoring and incident response. The primary objective of

the audit monitoring process is to support incident response.

Responsible Role:

Customer Administrator, M365 Security Manager, M365 Trust Program Manager,

Service Engineer Operations

Implementation Status

(check all that apply):

☒ Implemented

☐ Partially implemented

☐ Planned

☐ Alternative implementation

☐ Not applicable

Control Origination

(check all that apply):

☐ Service Provider Corporate

☐ Service Provider System Specific

☐ Service Provider Hybrid (Corporate and System Specific)

☐ Configured by Customer (Customer System Specific)

☐ Provided by Customer (Customer System Specific)

☒ Shared (Service Provider and Customer Responsibility)

☐ Inherited from pre-existing authorization

_{Customer Responsibility

}_

Government customers are responsible for auditing account creation,

modification, disabling, and deletion events for their Active Directory

infrastructure as these events also pertain to M365 access. For these events,

these customers are responsible for analyzing and correlating audit records

across different repositories to gain organization-wide situational

awareness.

_{M365

}_

The M365 Security team continuously correlates log files across multiple M365

service teams using automated analytics tools. Audit logs are uploaded to a

repository from all servers in the M365 environment . M365 Security then uses

the data from these tools to generate actionable reports that the service

teams can use to correct vulnerabilities and improve any weaknesses found.

The automated security alerting tools also look for issues that may be

affecting multiple service teams, which allows M365 Security to gain

organization-wide situational awareness and respond accordingly.

Responsible Role:

Customer Administrator, M365 Security Manager, M365 Trust Program Manager,

Service Engineer Operations

Implementation Status

(check all that apply):

☒ Implemented

☐ Partially implemented

☐ Planned

☐ Alternative implementation

☐ Not applicable

Control Origination

(check all that apply):

☐ Service Provider Corporate

☐ Service Provider System Specific

☐ Service Provider Hybrid (Corporate and System Specific)

☐ Configured by Customer (Customer System Specific)

☐ Provided by Customer (Customer System Specific)

☒ Shared (Service Provider and Customer Responsibility)

☐ Inherited from pre-existing authorization

_{Customer Responsibility

}_

Government customers are responsible for auditing account creation,

modification, disabling, and deletion events for their Active Directory

infrastructure as these events also pertain to M365 access. For these events,

these government customers are responsible for providing the capability to

centrally review and analyze audit records from multiple system components

within their Active Directory infrastructure.

_{M365

}_

The M365 Security team continuously correlates log files across multiple M365

service teams using automated analytics tools. Audit logs are uploaded to a

repository service from all servers in the M365 environment, where they are

correlated across service teams, in order to gain organization-wide

situational awareness. Reports can be generated from the alerts in the

uploader service. M365 Security uses NRT tools as an automated mechanism to

review and analyze the audit logs.

Responsible Role:

Customer Administrator, M365 Security Manager, M365 Trust Program Manager,

Service Engineer Operations

Parameter AU-06(05):

Vulnerability scanning information, performance data, information system

monitoring information, penetration test data

Implementation Status

(check all that apply):

☒ Implemented

☐ Partially implemented

☐ Planned

☐ Alternative implementation

☐ Not applicable

Control Origination

(check all that apply):

☐ Service Provider Corporate

☐ Service Provider System Specific

☐ Service Provider Hybrid (Corporate and System Specific)

☐ Configured by Customer (Customer System Specific)

☐ Provided by Customer (Customer System Specific)

☒ Shared (Service Provider and Customer Responsibility)

☐ Inherited from pre-existing authorization

_{Customer Responsibility

}_

Government customers are responsible for auditing account creation,

modification, disabling, and deletion events for their Active Directory

infrastructure as these events also pertain to M365 access. For these events,

these government customers are responsible for integrating audit record

analysis with analysis of data/information collected from other sources to

detect suspicious activity.

_{M365

}_

The M365 Security team correlates audit records with vulnerability scanning

information and penetration test data to gain a more complete picture of

potential exploits and to enhance the ability to detect inappropriate

activity. Additionally, M365 Security uses vulnerability scanning reports in

conjunction with performance and system monitoring data to identify unusual

activity. Audit logs are uploaded to a repository service from all servers in

the M365 environment, where they are correlated across service teams to

support after-the-fact investigations of security incidents, including the use

of audit logging data, incident monitoring reports, vulnerability scan data,

and penetration testing results.

Responsible Role:

Azure, M365 Security Manager

Implementation Status

(check all that apply):

☒ Implemented

☐ Partially implemented

☐ Planned

☐ Alternative implementation

☐ Not applicable

Control Origination

(check all that apply):

☐ Service Provider Corporate

☒ Service Provider System Specific

☐ Service Provider Hybrid (Corporate and System Specific)

☐ Configured by Customer (Customer System Specific)

☐ Provided by Customer (Customer System Specific)

☐ Shared (Service Provider and Customer Responsibility)

☒ Inherited from pre-existing authorization for Azure Government

(F1603087869), 4/17/2020

_{M365

}_

Physical access monitoring is inherited from Azure. Any breaches or physical

security incidents are reported through the incident reporting process

described in IR-06 by the physical security team. Information from such

physical security incidents can then be compared to audit logging records by

the C+AI Security Operations Center (SOC) team to further identify and

investigate suspicious behavior. Furthermore, when a physical incident is

detected, the C+AI Security Operations Center (SOC) team will use the related

physical monitoring data and correlate it with audit records to determine if

there was any associated logical breach or suspicious behavior.

Responsible Role:

Customer Administrator, M365 Security Manager, M365 Trust Program Manager,

Service Engineer Operations

Parameter AU-06(07):

Information system process; role; user

Implementation Status

(check all that apply):

☒ Implemented

☐ Partially implemented

☐ Planned

☐ Alternative implementation

☐ Not applicable

Control Origination

(check all that apply):

☐ Service Provider Corporate

☐ Service Provider System Specific

☐ Service Provider Hybrid (Corporate and System Specific)

☐ Configured by Customer (Customer System Specific)

☐ Provided by Customer (Customer System Specific)

☒ Shared (Service Provider and Customer Responsibility)

☐ Inherited from pre-existing authorization

_{Customer Responsibility

}_

Government customers are responsible for specifying the permitted actions

associated with the review, analysis, and reporting of customer-controlled

audit information.

_{M365

}_

M365 specifies the permitted actions for each process, role, or user via

role-based Access Control. Security groups are defined in the account

management tools; each security group has specified access rights and

permitted actions. Users are added to security groups via account management

tools.

The security incident management team, responsible for both incident response

and monitoring defines the roles and responsibilities for reviewing audit log

information in the IR SOP. Only authorized members of the incident response

team have access to audit log information. This information is only used to

aid in incident response and investigation and is not available to personnel

outside the incident response function.

Responsible Role:

Customer Administrator, M365 Security Manager, M365 Trust Program Manager,

Service Engineer Operations

Implementation Status

(check all that apply):

☒ Implemented

☐ Partially implemented

☐ Planned

☐ Alternative implementation

☐ Not applicable

Control Origination

(check all that apply):

☐ Service Provider Corporate

☐ Service Provider System Specific

☐ Service Provider Hybrid (Corporate and System Specific)

☐ Configured by Customer (Customer System Specific)

☐ Provided by Customer (Customer System Specific)

☒ Shared (Service Provider and Customer Responsibility)

☒ Inherited from pre-existing authorization for Azure Government

(F1603087869), 4/17/2020

Part a

_{Customer Responsibility

}_

Government customers are responsible for auditing account creation,

modification, disabling, and deletion events for their Active Directory

infrastructure as these events also pertain to M365 access. For these events,

these customers are responsible for providing an audit reduction and report

generation capability that supports on-demand audit review, analysis, and

reporting requirements and after-the-fact investigations of security

incidents.

_{M365

}_

Audit logs are uploaded to a repository service from all servers in the M365

environment. Each service team receives NRT Security Monitoring alerting on

security events through various alerting tools and reports can be generated

from the alerts and from the uploader service to support after-the-fact

investigations of security incidents, to correct vulnerabilities, and to

address any weaknesses found.

Implementation of this control is inherited from Azure for M365 services

using inherited compute.

Part b

_{Customer Responsibility

}_

Government and non-government customers are responsible for auditing account

creation, modification, disabling, and deletion events for their Active

Directory infrastructure as these events also pertain to M365 access. For

these events, these customers are responsible for utilizing audit processing

tools that do not change the original audit records or time ordering.

_{M365

}_

The tools used in M365 to collect and process audit records do not

permanently or irreversibly alter the original audit record content or time

ordering. M365 scrubs logs of customer information before sending logs to the

repository service. Specifically, scrubbing takes fields containing customer

content, hashes that data, and replaces the field with the hash value. The

rewritten log is sent to the repository service, and each service team stores

a mapping of hash keys to hashes within the M365 accreditation boundary. The

uploader service can then correlate, alert, and report on these anonymized

hashes. If an alert or report requires investigation, the logs are imported

back inside the boundary. The service team can then repopulate the logs to

their original state using the hash to key mapping.

Responsible Role:

Customer Administrator, M365 Security Manager, M365 Trust Program Manager,

Service Engineer Operations

Parameter AU-07(01):

All fields within audit records

Implementation Status

(check all that apply):

☒ Implemented

☐ Partially implemented

☐ Planned

☐ Alternative implementation

☐ Not applicable

Control Origination

(check all that apply):

☐ Service Provider Corporate

☐ Service Provider System Specific

☐ Service Provider Hybrid (Corporate and System Specific)

☐ Configured by Customer (Customer System Specific)

☐ Provided by Customer (Customer System Specific)

☒ Shared (Service Provider and Customer Responsibility)

☐ Inherited from pre-existing authorization

_{Customer Responsibility

}_

Government customers are responsible for auditing account creation,

modification, disabling, and deletion events for their Active Directory

infrastructure as these events also pertain to M365 access. For these events,

these customers are responsible for providing the capability to automatically

process audit records for events of interest based on selectable event

criteria.

_{M365

}_

Logs are uploaded to a repository service, where they are aggregated,

correlated, duplicated, and reduced into security or service-relevant alerts

and alarms that are used by the service teams to analyze and respond

appropriately to suspicious activity. Authorized personnel are able to

perform Database queries to process audit records for events of interest

based on any fields contained within the records; authorized personnel are

also able to generate reports that are used to review events of interest or

investigate specific activities.

Responsible Role:

Azure, Customer Administrator, Service Engineer Operations

Parameter

AU-08(b): One (1) second granularity

of time measurement

Implementation Status

(check all that apply):

☒ Implemented

☐ Partially implemented

☐ Planned

☐ Alternative implementation

☐ Not applicable

Control Origination

(check all that apply):

☐ Service Provider Corporate

☐ Service Provider System Specific

☐ Service Provider Hybrid (Corporate and System Specific)

☐ Configured by Customer (Customer System Specific)

☐ Provided by Customer (Customer System Specific)

☒ Shared (Service Provider and Customer Responsibility)

☒ Inherited from pre-existing authorization for Azure Government

(F1603087869), 4/17/2020

Part a

_{Customer Responsibility

}_

Government customers are responsible for auditing account creation,

modification, disabling, and deletion events for their Active Directory

infrastructure as these events also pertain to M365 access. For these events,

these customers are responsible for using internal system clocks to generate

time stamps for audit records; by default, Windows uses the internal system

clock to generate time stamps for audit records, and this setting is not

configurable.

_{M365

}_

Audit records and events generated by M365 are logged with timestamps.

Windows uses the internal system clock to generate time stamps for audit

records, and this setting is not configurable.

Implementation of this control is inherited from Azure for M365 services

using inherited compute.

Part b

_{Customer Responsibility

}_

Government and non-government customers are responsible for auditing account

creation, modification, disabling, and deletion events for their Active

Directory infrastructure as these events also pertain to M365 access. For

these events, these customers are responsible for recording time stamps with

audit records that can be mapped to UTC or GMT.

_{M365

}_

M365 records time stamps for audit records that can be mapped to Coordinated

Universal Time (UTC). Time stamps are generated either in UTC directly or in

local time with an offset from UTC. M365 time stamps are precise at least to

the second.

Responsible Role:

Customer Administrator, M365 Security Manager, Service Engineer Operations

Parameter AU-09(b):

Service Engineer Operations personnel

Implementation Status

(check all that apply):

☒ Implemented

☐ Partially implemented

☐ Planned

☐ Alternative implementation

☐ Not applicable

Control Origination

(check all that apply):

☐ Service Provider Corporate

☐ Service Provider System Specific

☐ Service Provider Hybrid (Corporate and System Specific)

☐ Configured by Customer (Customer System Specific)

☐ Provided by Customer (Customer System Specific)

☒ Shared (Service Provider and Customer Responsibility)

☒ Inherited from pre-existing authorization for Azure Government

(F1603087869), 4/17/2020

Part a

_{Customer Responsibility

}_

Government customers are responsible for auditing account creation,

modification, disabling, and deletion events for their Active Directory

infrastructure as these events also pertain to M365 access. For these events,

these customers are responsible for protecting audit information and audit

tools from unauthorized access, modification, and deletion.

For more information on controlling access in Windows, see the following

link: <https://learn.microsoft.com/en-us/windows-server/identity/solution-guides/dynamic-access-control--scenario-overview>.

_{M365

}_

Only M365 service team administrators have access to security logs. If a

service team administrator deletes log data locally, this activity is logged,

and an alert is generated. Audit information containing EUII and customer

content is hashed and/or encrypted and can only be read when accessed through

M365 by an authorized user. Authorized M365 personnel are only able to read

information stored in the repository service and are not granted permissions

to modify or delete logs.

Implementation of this control is inherited from Azure for M365 services

using inherited compute.

Part b

_{M365

}_

Only M365 service team administrators have access to security logs. If a

service team administrator deletes log data locally, this activity is logged,

and an alert is generated and sent to responsible service engineer operations

personnel. Audit information containing EUII and customer content is hashed

and/or encrypted and can only be read when accessed through M365 by an

authorized user. Authorized M365 personnel are only able to read information

stored in the repository service and are not granted permissions to modify or

delete logs.

Responsible Role:

Customer Administrator, M365 Security Manager, M365 Trust Program Manager,

Service Engineer Operations

Parameter AU-09(02):

At least weekly

Implementation Status

(check all that apply):

☒ Implemented

☐ Partially implemented

☐ Planned

☐ Alternative implementation

☐ Not applicable

Control Origination

(check all that apply):

☐ Service Provider Corporate

☐ Service Provider System Specific

☐ Service Provider Hybrid (Corporate and System Specific)

☐ Configured by Customer (Customer System Specific)

☐ Provided by Customer (Customer System Specific)

☒ Shared (Service Provider and Customer Responsibility)

☐ Inherited from pre-existing authorization

_{Customer Responsibility

}_

Government customers are responsible for auditing account creation,

modification, disabling, and deletion events for their Active Directory

infrastructure as these events also pertain to M365 access. For these events,

these customers are responsible for backing up audit records at least weekly

onto a different system or media than the system being audited.

_{M365

}_

Each M365 server uploads audit logs to a centralized repository service. In

the event that real-time log shipping fails, logs are retained on the server

until the connection is reinstated and they can be exported to the repository

service.

Responsible Role:

Customer Administrator, M365 Security Manager, M365 Trust Program Manager,

Service Engineer Operations

Implementation Status

(check all that apply):

☒ Implemented

☐ Partially implemented

☐ Planned

☐ Alternative implementation

☐ Not applicable

Control Origination

(check all that apply):

☐ Service Provider Corporate

☐ Service Provider System Specific

☐ Service Provider Hybrid (Corporate and System Specific)

☐ Configured by Customer (Customer System Specific)

☐ Provided by Customer (Customer System Specific)

☒ Shared (Service Provider and Customer Responsibility)

☐ Inherited from pre-existing authorization

_{Customer Responsibility

}_

Government customers are responsible for implementing cryptographic

mechanisms to protect the integrity of customer-controlled audit systems.

_{M365

}_

Only M365 service team administrators have access to security logs. If an

M365 service team administrator deletes log data locally, this activity is

logged and an alert is generated.

In addition, all logs are uploaded to a repository service. Audit information

containing PII is scrubbed before it is sent to an audit log repository.

Audit information is encrypted in transit and is hashed and/or stored in an

encrypted repository. Authorized M365 personnel are only able to read

information and are not granted permissions to modify or delete logs.

M365 servers upload audit logs to the repository service using FIPS-140-2

compliant TLS.

Responsible Role:

Customer Administrator, M365 Security Manager, M365 Trust Program Manager

Parameter AU-09(04):

Service Engineer Operations

Implementation Status

(check all that apply):

☒ Implemented

☐ Partially implemented

☐ Planned

☐ Alternative implementation

☐ Not applicable

Control Origination

(check all that apply):

☐ Service Provider Corporate

☐ Service Provider System Specific

☐ Service Provider Hybrid (Corporate and System Specific)

☐ Configured by Customer (Customer System Specific)

☐ Provided by Customer (Customer System Specific)

☒ Shared (Service Provider and Customer Responsibility)

☐ Inherited from pre-existing authorization

_{Customer Responsibility

}_

Government customers are responsible for auditing account creation,

modification, disabling, and deletion events for their Active Directory

infrastructure as these events also pertain to M365 access. For these events,

these customers are responsible for restricting access to only appropriate

personnel.

_{M365

}_

M365 restricts management of audit functionality within M365 to a limited

subset of Service Engineer Operations personnel responsible for audit

functionality. These personnel do not have the ability to modify or delete

audit records that are stored in a repository service, and if they disable

logging to the repository service, that action itself is logged. Repository

service personnel do not have access to M365 MT.

Responsible Role:

Customer Administrator, M365 Security Manager, M365 Trust Program Manager

Parameter AU-10:

Minimum actions including the addition, modification, deletion, approval,

sending, or receiving of data

Implementation Status

(check all that apply):

☒ Implemented

☐ Partially implemented

☐ Planned

☐ Alternative implementation

☐ Not applicable

Control Origination

(check all that apply):

☐ Service Provider Corporate

☐ Service Provider System Specific

☐ Service Provider Hybrid (Corporate and System Specific)

☐ Configured by Customer (Customer System Specific)

☐ Provided by Customer (Customer System Specific)

☒ Shared (Service Provider and Customer Responsibility)

☒ Inherited from pre-existing authorization for Azure Government

(F1603087869), 4/17/2020

_{Customer Responsibility

}_

Government customers are responsible for enforcing non-repudiation for

customer-deployed resources.

_{M365

}_

As part of the content of audit records captured for M365, unique usernames

are captured by the servers and net devices across the Infrastructure. Unique

identifiers for JIT sessions, required to access production systems, are

assigned based on a combination of random characters appended to the

individual's unique corpnet account name. The combination of event logs

capturing usernames, and usernames uniquely identified based on an

individual's JIT account, constitute non-repudiation for M365.

Segregation of duties protects the information system and prevents

individuals from falsely denying having performed a particular action.

Service team admins are not granted access to audit collection databases

where records of actions performed are stored. User access reviews are done

quarterly to ensure that users have the correct level of access.

Implementation of this control is inherited from Azure for M365 services

using inherited compute.

Responsible Role:

Customer Administrator, M365 Security Manager, M365 Trust Program Manager

Parameter AU-11: a

time period in compliance with M-21-31

Implementation Status

(check all that apply):

☒ Implemented

☐ Partially implemented

☐ Planned

☐ Alternative implementation

☐ Not applicable

Control Origination

(check all that apply):

☐ Service Provider Corporate

☐ Service Provider System Specific

☐ Service Provider Hybrid (Corporate and System Specific)

☐ Configured by Customer (Customer System Specific)

☐ Provided by Customer (Customer System Specific)

☒ Shared (Service Provider and Customer Responsibility)

☒ Inherited from pre-existing authorization for Azure Government

(F1603087869), 4/17/2020

_{Customer Responsibility

}_

Government customers are responsible for auditing account creation,

modification, disabling, and deletion events for their Active Directory

infrastructure as these events also pertain to M365 access. For these events,

these customers are responsible for retaining audit records for at least one

year to provide support for after-the-fact investigations of security

incidents and to meet regulatory and organizational information retention

requirements.

For more information on setting audit retention policy in Windows, see the

following link:

<https://learn.microsoft.com/en-us/purview/audit-log-retention-policies>.

_{M365

}_

M365 retains audit records in a repository service for a time period in

compliance with M-21-31, where possible, to support investigations of

security incidents and to meet regulatory retention requirements. Customers

are allowed to copy and store their own audit records to meet customer

storage requirements.

Implementation of this control is inherited from Azure for M365 services

using inherited compute.

Responsible Role:

Customer Administrator, M365 Security Manager, Service Engineer Operations

Parameter AU-12(a):

all information system and network components where audit capability is

deployed/available

Parameter AU-12(b):

Service Engineer Operations, M365 Security Manager

Implementation Status

(check all that apply):

☒ Implemented

☐ Partially implemented

☐ Planned

☐ Alternative implementation

☐ Not applicable

Control Origination

(check all that apply):

☐ Service Provider Corporate

☐ Service Provider System Specific

☐ Service Provider Hybrid (Corporate and System Specific)

☐ Configured by Customer (Customer System Specific)

☐ Provided by Customer (Customer System Specific)

☒ Shared (Service Provider and Customer Responsibility)

☒ Inherited from pre-existing authorization for Azure Government

(F1603087869), 4/17/2020

Part a

_{Customer Responsibility

}_

Government customers are responsible for generating audit events for account

creation, modification, disabling, and deletion activities for their Active

Directory infrastructure as these events also pertain to M365 access.

For more information on how to configure auditing of account management, see

the following link:

<https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/audit-policy-recommendations>.

_{M365

}_

M365 implements audit generation by configuring all system network devices

and servers to have the capability to generate audit records defined in AU-2

and AU-3.

Implementation of this control is inherited from Azure for M365 services

using inherited compute.

Part b

_{M365

}_

M365 implements audit generation by configuring all system network devices

and servers to have the capability to generate audit records defined in AU-2

and AU-3.

Service teams configure audit generation for the operating system and the

application layer to generate audit records as defined in AU-2 and AU-3.

Audit records are captured in a repository service, which allows for the

record generation and reporting capabilities for the auditable events

identified in AU-2 and AU-3. These capabilities also allow for the review of

audit logs, should information contained within warrant a review.

Part c

_{Customer Responsibility

}_

Government and non-government customers are responsible for generating audit

events for account creation, modification, disabling, and deletion activities

for their Active Directory infrastructure as these events also pertain to

M365 access. Customers using Windows servers to support their infrastructure

automatically meet this requirement as Windows captures these event details

by default.

For more information regarding Windows event logging, see the following link:

<https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/plan/appendix-l--events-to-monitor>.

_{M365

}_

Audit records are captured in active monitoring tools and stored in a

repository service, which allows for the record generation and reporting

capabilities for the auditable events identified in AU-2 with the content

defined in AU-3. These capabilities also allow for the review of audit logs,

should information contained within warrant a review.

Responsible Role:

Azure, Customer Administrator, M365 Security Manager, Service Engineer

Operations

Parameter AU-12(01)-1:

All network, data storage, and computing devices

Parameter AU-12(01)-2:

The time tracking tolerance defined in AU-8

Implementation Status

(check all that apply):

☒ Implemented

☐ Partially implemented

☐ Planned

☐ Alternative implementation

☐ Not applicable

Control Origination

(check all that apply):

☐ Service Provider Corporate

☐ Service Provider System Specific

☐ Service Provider Hybrid (Corporate and System Specific)

☐ Configured by Customer (Customer System Specific)

☐ Provided by Customer (Customer System Specific)

☒ Shared (Service Provider and Customer Responsibility)

☒ Inherited from pre-existing authorization for Azure Government

(F1603087869), 4/17/2020

_{Customer Responsibility

}_

Government customers are responsible for compiling audit records into a

system-wide audit trail for customer-deployed resources.

_{M365

}_

M365 Security team continuously correlates log files across multiple M365

service teams using automated analytics tools. Time stamps are precise at

least to the millisecond.

M365 implements audit generation through configuring all system network

devices and servers to have the capability to generate audit records as

defined in AU-2 and AU-3. All events defined in AU-2 are being logged by M365

systems. Audit logs are uploaded to a repository service from all servers in

the M365 environment, where they are correlated across service teams. This

allows for the record generation capability and convergence of monitoring

data for the auditable events in AU-2 and AU-3.

To provide a time correlated audit trail, all M365 system devices are time

correlated and store time in UTC format. M365 uses stratum 1 clock sources in

the US. From there, every DCR (pair of redundant core Azure datacenter

routers) provides clock to the M365 datacenter devices. The overall approach

is to use the DCRs as NTP servers. The DCRs synchronize off the authoritative

stratum 1 time sources, with Microsoft equipment synchronizing off of the

DCRs. The same IP addresses for NTP are configured on the DCRs in each

datacenter, with routing tables being used to determine the closest source to

any given client (similar to an Anycast style solution). These IP addresses

are in management IP space and synchronization is done over the management

network. The tolerance for the correlation process is under one second.

M365 servers are configured to synchronize time every 5 minutes through M365

managed Domain Controllers. The M365 time servers sync off of Global

Positioning System (GPS) satellites.

Teams that use Azure inherit Internal system clock synchronization from

Azure.

Responsible Role:

Customer Administrator, M365 Security Manager, Service Engineer Operations

Parameter AU-12(03)-1:

M365 Security or service team members with audit configuration

responsibilities, Security Incident Monitoring Team

Parameter AU-12(03)-2:

All network, data storage, and computing devices

Parameter AU-12(03)-3:

Changes to the threat environment; risk-based assessment defined in AU-02

Parameter AU-12(03)-4:

Risk-based assessment; Annually or whenever a change occurs in the threat

Implementation Status

(check all that apply):

☒ Implemented

☐ Partially implemented

☐ Planned

☐ Alternative implementation

☐ Not applicable

Control Origination

(check all that apply):

☐ Service Provider Corporate

☐ Service Provider System Specific

☐ Service Provider Hybrid (Corporate and System Specific)

☐ Configured by Customer (Customer System Specific)

☐ Provided by Customer (Customer System Specific)

☒ Shared (Service Provider and Customer Responsibility)

☐ Inherited from pre-existing authorization

_{Customer Responsibility

}_

Government customers are responsible for providing the capability to extend

or limit auditing as necessary to meet organizational requirements.

_{M365

}_

The M365 Security team has the capabilities and permissions to modify

auditing requirements to be performed on all M365 system network devices and

servers. The auditing events to be selected are based on a risk-based

assessment defined in AU-2. Changes to auditing are made annually or whenever

a significant change occurs in the threat environment as defined by

authoritative sources. For more information on updates to auditable events,

see AU-2 (3).

Responsible Role: M365

Trust Program Manager, Customer Administrator

Parameter CA-01(a):

all personnel

Parameter CA-01(a)(1):

organization-level

Parameter

CA-01(b): Appropriate service team

personnel, security engineering teams, service provider personnel with

authority on assessment, authorization, and monitoring policies

Parameter

CA-01(c)(1)-1: at least annually

Parameter

CA-01(c)(1)-2: significant changes

Parameter

CA-01(c)(2)-1: at least annually

Parameter

CA-01(c)(2)-2: significant changes

Implementation Status

(check all that apply):

☒ Implemented

☐ Partially implemented

☐ Planned

☐ Alternative implementation

☐ Not applicable

Control Origination

(check all that apply):

☐ Service Provider Corporate

☐ Service Provider System Specific

☐ Service Provider Hybrid (Corporate and System Specific)

☐ Configured by Customer (Customer System Specific)

☐ Provided by Customer (Customer System Specific)

☒ Shared (Service Provider and Customer Responsibility)

☐ Inherited from pre-existing authorization

Part a

_{Customer Responsibility

}_

Government customers are responsible for developing and maintaining

appropriate assessment, authorization, and monitoring policies and procedures

that govern activities for their organization and users.

_{M365

}_

Part 1

The "M365 Information Security Policy" provides the overarching

security guidance for M365 policies. This document addresses the purpose,

scope, roles, responsibilities, compliance requirements, and required

coordination among the various Microsoft organizations providing some level

of support for the security of M365. The policy is distributed to all

personnel providing support for M365 via SharePoint.

Part 2

The M365 Information Security Policy contains policies that must be met in

the delivery and operation of M365. Standards and procedures to facilitate

execution of these policies are documented in the M365 SOPs and service

team-specific SOPs. These standards and procedures act as adjuncts to the

security policy and provide implementation level requirements and details to

carry out specific operational tasks. A detailed mapping of M365 Standards

and Procedures to each control is available for review. The SOPs are

distributed to roles providing support for M365 via SharePoint.

Part b

_{Customer Responsibility

}_

Government customers are responsible for designating an organization-defined

official to manage the development, documentation, and dissemination of their

organization's asessment, authorization, and monitoring policy and

procedures.

_{M365

}_

The "M365 Information Security Policy" provides the overarching

security guidance for M365. This document addresses the purpose, scope,

roles, responsibilities, compliance requirements, and required coordination

among the various Microsoft organizations providing some level of support for

the security of M365. Policies are distributed to personnel responsible for

implementing assessment, authorization, and monitoring policies and

procedures via SharePoint.

The "M365 Information Security Policy" is reviewed and updated

annually.

Part c

_{Customer Responsibility

}_

Government customers are responsible for annually updating their Access

Control policies and procedures.

_{M365

}_

Part 1

The "M365 Information Security Policy" is reviewed and updated at

least annually by the M365 Trust team

Part 2

The M365 SOPs are reviewed and updated at least annually or whenever a

significant change occurs.

Responsible Role: M365

Trust Program Manager

Parameter CA-02(d): At

least annually

Parameter CA-02(f):

Individuals or roles to include FedRAMP PMO

Implementation Status

(check all that apply):

☒ Implemented

☐ Partially implemented

☐ Planned

☐ Alternative implementation

☐ Not applicable

Control Origination

(check all that apply):

☐ Service Provider Corporate

☒ Service Provider System Specific

☐ Service Provider Hybrid (Corporate and System Specific)

☐ Configured by Customer (Customer System Specific)

☐ Provided by Customer (Customer System Specific)

☐ Shared (Service Provider and Customer Responsibility)

☐ Inherited from pre-existing authorization

Part a

_{M365

}_

M365 selects an accredited FedRAMP-approved 3PAO as an independent assessor

to perform control assessments and assessment activities.

Part b

_{M365

}_

Part 1, 2, 3

The Control Assessment Plan (CAP) or Security Assessment Plan (SAP) is

developed by a 3PAO-certified independent assessor for M365. M365 requires

that the CAP/SAP include the security controls and enhancements under

assessment, the assessment procedures, and an explanation of the assessment

environment, team, and roles and responsibilities. The CAP/SAP is then

reviewed and approved by M365, followed by a security assessment performed by

the independent assessor. The CAP/SAP will be based on NIST SP 800-53A.

Part c

_{M365

}_

Control assessment plans are reviewed and distributed to the authorizing

official or designated representative, as well as personnel responsible for

helping to manage the assessment prior to conducting the assessment.

Part d

_{M365

}_

M365 will assess security controls in the information system and its

environment of operation at least annually. The controls will be assessed as

part of the continuous monitoring process using a 3PAO-certified independent

assessor as required. Other criteria, such as major system changes and

changes in risk posture and vulnerabilities, will trigger assessments.

If an external system with which M365 maintains an interconnection has a

FedRAMP P-ATO, M365 will leverage that P-ATO. Any system without a FedRAMP

P-ATO from which security controls are inherited will be reviewed by the

independent assessor with respect to security controls inherited from that

system.

M365 employs an onboarding process for new features that do not change the

security posture of the information system as described in the FedRAMP

attestation guidance document. This process includes gathering evidence of

compliance with security controls at the time of onboarding the team to the

environment. The 3PAO reviews the onboarding evidence and attests to the

readiness of the new services.

Part e

_{M365

}_

M365 requires 3PAO-certified independent assessors to produce a Security

Assessment Report (SAR) that documents the results of the assessment,

including security controls that are considered other than satisfied,

security control weaknesses, recommended remediation steps, and the risks

associated with the system.

Part f

_{M365

}_

M365 provides the SAR to Authorizing Officials (including the FedRAMP PMO),

together with the rest of the authorization and accreditation package for an

authorization decision.

Responsible Role: M365

Trust Program Manager

Implementation Status

(check all that apply):

☒ Implemented

☐ Partially implemented

☐ Planned

☐ Alternative implementation

☐ Not applicable

Control Origination

(check all that apply):

☐ Service Provider Corporate

☒ Service Provider System Specific

☐ Service Provider Hybrid (Corporate and System Specific)

☐ Configured by Customer (Customer System Specific)

☐ Provided by Customer (Customer System Specific)

☐ Shared (Service Provider and Customer Responsibility)

☐ Inherited from pre-existing authorization

_{M365

}_

Microsoft employs a FedRAMP-approved 3PAO as an independent assessor to

conduct a control assessment of M365 and its components.

Responsible Role: M365

Trust Program Manager

Parameter CA-02(02)-1:

At least annually

Parameter CA-02(02)-2:

Announced, unannounced

Parameter CA-02(02)-3:

In-depth monitoring, vulnerability scanning, malicious user testing, insider

threat assessment, performance and load testing; phishing campaigns

Implementation Status

(check all that apply):

☒ Implemented

☐ Partially implemented

☐ Planned

☐ Alternative implementation

☐ Not applicable

Control Origination

(check all that apply):

☐ Service Provider Corporate

☒ Service Provider System Specific

☐ Service Provider Hybrid (Corporate and System Specific)

☐ Configured by Customer (Customer System Specific)

☐ Provided by Customer (Customer System Specific)

☐ Shared (Service Provider and Customer Responsibility)

☐ Inherited from pre-existing authorization

_{M365

}_

The M365 Security team performs announced security control assessments at

least annually. These assessments include in-depth monitoring, vulnerability

scanning, insider threat assessment, malicious user testing through Red Team

exercises, and performance/load testing. Additionally, M365 performs an

unannounced phishing campaign as part of its FedRAMP assessment.

Responsible Role: M365

Trust Program Manager

Parameter CA-02(03)-1:

Any FedRAMP Accredited 3PAO

Parameter CA-02(03)-2:

Microsoft 365

Parameter CA-02(03)-3:

The conditions of the JAB/AO in the FedRAMP Repository

Implementation Status

(check all that apply):

☒ Implemented

☐ Partially implemented

☐ Planned

☐ Alternative implementation

☐ Not applicable