Microsoft 365 Certification Submission Guide

In this article:

Introduction

Part of the Microsoft 365 App Compliance program, the Microsoft 365 Certification offers assurance and confidence to enterprise organizations that data and privacy are adequately secured and protected when integrating third-party developer apps/add-ins into the Microsoft 365 platform. Applications and add-ins that pass validation will be designated Microsoft 365 Certified throughout the Microsoft 365 ecosystem.

By participating in the Microsoft 365 Certification program, you are agreeing to these supplemental terms and to comply with any accompanying documentation that applies to your participation in the Microsoft 365 Certification program with Microsoft Corporation ("Microsoft", "we", "us", or "our"). You represent and warrant to us that you have the authority to accept these Microsoft 365 Certification supplemental terms on behalf of yourself, a company, and/or other entity, as applicable. We may change, amend or terminate these supplemental terms at any time. Your continued participation in the Microsoft 365 Certification program after any change or amendment means you agree to the new supplemental terms. If you do not agree to the new supplemental terms or if we terminate these supplemental terms, you must stop participating in the Microsoft 365 Certification program.

This document is aimed at ISVs (Independent Software Vendors) to provide information on the Microsoft 365 Certification process, prerequisites to starting the process and details of specific security controls that ISVs must have in place. General information of the Microsoft 365 App Compliance program can be found under the Microsoft 365 App Compliance program page.

Important

Currently, Microsoft 365 Certification is limited:

  • Microsoft Teams applications (Tabs, Bots, etc.) .
  • Sharepoint Apps/Add-ins
  • Office Add-ins (Word, Excel, PowerPoint, Outlook, Project, OneNote)

Prerequisites

Publisher Attestation

Before being awarded the Microsoft 365 Certification process you must have completed Publisher Attestation. However, you may start the Microsoft 365 Certification process prior to completing Publisher Attestation.

Read the Microsoft 365 Certification Specification

Microsoft recommends all ISVs (Independent Software Vendor) to read this Microsoft 365 Certification Specification in its entirety to ensure all applicable controls are being met by the in-scope environment and the app/add-in. This will help ensure a smooth assessment process.

Microsoft 365 Certification Specification Updates

Updates to the Microsoft 365 Certification specification are anticipated approximately every six to twelve months. These updates might introduce new target security domains and / or security controls. Updates will be based on developer feedback, changes to the threat landscape, and to increase the security baseline of the program as it matures.

ISVs that have already started the Microsoft 365 Certification assessment can continue the assessment with the version of the Microsoft 365 Certification Specification that was valid when the assessment was started. All new submissions, including annual recertification, will be required to be assessed against the version published.

Note

You are not required to comply with all the controls within this Microsoft 365 Certification Specification to be awarded a certification. However, passing thresholds (which will not be disclosed) are in place for each of the security domains discussed within this Microsoft 365 Certification Specification. Some controls will be classed as a ‘Hard Fail’ which means the lack of these security controls will result in a failed assessment.

Certification Scope

The in-scope environment is the environment that supports delivery of the app/add-in code and supports any backend systems that the app/add-in may be communicating with. Any additional connected-to environments will also be included in scope unless adequate segmentation is in place AND the connected-to environments cannot impact the security of the in-scope environment. Any disaster recovery environments will also need to be included within the scope of the assessment as these environments would be required to fulfil the service should anything happen to the primary environment. The term in-scope system components reference ALL devices and systems that are used within the in-scope environment. In-scope components include, but are not limited to:

  • The web application(s).
  • Servers.
  • Firewalls (or equivalent).
  • Switches.
  • Load balancers.
  • Virtual infrastructure.
  • Cloud provider web management portals

Important

The in-scope environment, must have a DMZ and the supporting environment of the app/add-in must be segmented from the internal business systems and corporate environments thus limiting the scope of the assessment activities to the in-scope systems only. Certification analysts will validate segmentation techniques during the assessment along with reviewing penetration testing reports which should have included testing to validate the effectiveness of any segmentation techniques in use.

Infrastructure as a Service (IaaS), Platform as a Service (PaaS) and Software as a Service (SaaS)

Where IaaS and/or PaaS is used to support the infrastructure of the application or add-in code delivery under review, the Cloud platform provider will be responsible for some of the security controls assessed throughout the certification process. Therefore, certification analysts will need to be provided with independent external verification of security best practices by the Cloud platform provider through external compliance reports such as PCI DSS Attestation of Compliance (AOC), ISO27001 or SOC 2 Type II reports.

Appendix F provides details of what security controls will likely be applicable based on the following deployment types and based upon whether the app/add-in exfiltrates M365 data or not:

  • ISV Hosted
  • IaaS Hosted
  • PaaS/Serverless Hosted
  • Hybrid Hosted
  • Shared Hosted

Where IaaS or PaaS is deployed, you will need to provide evidence of the environment being hosted within these deployment types.

Sampling

Requests for evidence in support of the certification assessment should be based on a sample of the in-scope system components in consideration of different operating systems, primary function of the device, and different device types. A suitable sample will be selected at the start of the certification process. The following table should be used as a guide on what the sample size may be:

Population Size Sample
<5 1
>5 & <10 2
>9 & <25 3
>24 4

Note

If discrepancies are identified between devices included within the initial sample, the sample size may be increased during the assessment.

Certification Process

Before starting the certification process, you would need to have successfully started or completed your Publisher Attestation. Your attestation responses will be used in support of the Microsoft 365 Certification process and proceeds as follows:

  1. Review your Publisher Attestation documentation to ensure alignment with your current environment
  2. Request to progress to the Microsoft 365 Certification by emailing AppCert@microsoft.com
  3. Certification analysts will open a dialogue before starting the Microsoft 365 Certification process
  4. Submit your Initial Document Submission
  5. Certification analyst will provide a listing of controls for which evidence is required, which formally starts the Microsoft 365 Certification process
  6. Submit evidence that demonstrates that all in-scope Microsoft 365 Certification controls have been met within a 60-day window to complete Microsoft 365 Certification

Important

Submission time frame: It is anticipated that on average the assessment process should take 15 days, provided you are able to respond to evidence requests within a timely manner. Microsoft recommends that you ensure this certification submission guide has been read and be confident that you can meet the controls set out within it, and you can provide enough evidence before starting the certification process. Upon starting the certification process, a maximum of 60 days is permitted to complete the assessment, otherwise evidence already collected becomes stale. If, after the 60-day time-period, a successful assessment is not reached, the submission will be issued a fail and the process must start again. If a fail is issued due to failing to meet the Microsoft 365 Certification Specification or because the 60-day time-period is reached and enough evidence is not provided, failing results will not be made public by Microsoft.

Compliance Evidence

Although it is not required, if you are currently in compliance with other external security frameworks, you can elect to use these certifications to satisfy some of the Microsoft 365 Certification controls. Certification analysts will review the scope and security control coverage of any supported external security frameworks to determine which controls can be excluded from the Microsoft 365 Certification assessment, providing the scope of the external security frameworks include the in-scope environments for the Microsoft 365 Certification assessment.

Certification analysts will try to align existing external security frameworks to the Microsoft 365 Certification specification. However, if supporting documentation is unable to provide assurance that Microsoft 365 Certification controls were assessed as part of the external security frameworks audit/assessment you will need to provide additional evidence of the said controls being in place.

Currently, the external security frameworks that can be used in support of the Microsoft 365 Certification assessment include:

Documentation must adequately demonstrate that the in-scope environment for the Microsoft 365 Certification was included within the scope of these external security frameworks. Validation of these security frameworks will be fulfilled by accepting evidence of valid certifications conducted by reputable external third-party companies. These reputable companies must be members of international accreditation bodies for relevant compliance programs. See ISO Certification and Conformity Standards for ISO 27001 and Qualified Security Assessors (QSA) for PCI DSS.

The following table highlights documentation required by certification analysts as part of this validation process:

Standard Requirements
ISO 27001 A public facing version of the Statement of Applicability (SOA) and a copy of the ISO 27001 certificate issued will be required. The SOA summarizes your position on each of the 114 information security controls and will be used to identify if any exclusion of controls that are not satisfactorily detailed in the ISO 27001 certificate. If this can't be determined by reviewing the public facing version of the SOA, the analyst might need access to the full SOA if ISO 27001 will be used to validate some of the Microsoft 365 Certification Specification controls. In addition to validating the scope of the ISO 27001 assessment activities, the analysts will also confirm the validity of the audit company as described above.
PCI DSS A valid Level 1 Attestation of Compliance (AOC) document must be provided clearly identifying the in-scope application and system components. A self-assessment AOC will not be accepted as evidence of meeting security best practices. The AOC will be used to determine which of the Microsoft 365 Certification Specification controls have been evaluated and confirmed as part of the PCI DSS assessment.
SOC 2 The SOC 2 (Type I or Type II) report must be current (issued within the last 15 months and the declared time period started within the last 27 months) to be used as evidence of conformity with any of the assessment controls within this Microsoft 365 Certification Specification.

Microsoft 365 Certification

Supported external security frameworks can be used as evidence of meeting some of the Microsoft 365 Certification controls. Before external security frameworks can be considered, certification analysts will review the scope and security control coverage of the external security framework using the documentation submitted above.

The following appendixes can be used to identify where potential gaps between the external security framework and the Microsoft 365 Certification specification exist as follows:

Framework Additional considerations
ISO 27001 Appendix C: Evidence Collection – Deltas for ISO 27001.
PCI DSS Appendix D: Evidence Collection – Deltas for PCI DSS.
SOC 2 Appendix E: Evidence Collection – Deltas for SOC 2.

Note

Although the above-mentioned external security standards/frameworks can be submitted as evidence to meet some of the Microsoft 365 Certification controls, passing the Microsoft 365 Certification doesn't mean that you will successfully pass an audit against those standards/frameworks. The Microsoft 365 Certification Specification is only a small subset of those security standards/frameworks that allows Microsoft to gain a level of assurance in reference to your security posture.

Initial document submission

The initial document submission will help certification analysts perform scoping and determine what will be in scope for your assessment. After which you will be required to submit supporting documentation and evidence used to carry out the assessment. Your initial submission must include the information specified below:

Documentation Overview Documentation Details
App/Add-in Description A description of the app/add-in’s purpose and functionality. This should provide the certification analyst with a good understanding of how the app/add-in functions and what it is intended use is
Penetration Testing Report A penetration testing report completed within the last 12 months. This report must include the environment that supports the deployment of the app/add along with any additional environment that supports the operation of the app/add-in. Note: if you do not do annual penetration testing, you can elect to have them done through the certification process.
Architecture diagrams A logical architecture diagram representing a high-level overview of your app's / add-in’s supporting infrastructure. This must include all hosting environments and supporting infrastructure supporting the app/add-in. This diagram MUST depict all the different supporting system components within the environment to help certification analysts understand systems in scope and help to determine sampling. Please also indicate what hosting environment type is used; ISV Hosted, IaaS, PaaS, or Hybrid. Note: Where SaaS is used, please indicate the various SaaS services that are used to provide the supporting services within the environment.
Public Footprint Detailing all public IP Addresses and URLs used by the supporting infrastructure. This must include the full routable IP range allocated to the environment unless adequate segmentation has been implemented to split the range in use (adequate evidence of segmentation will be required)
Data flow diagrams Flow diagrams detailing the following:
✓ M365 Data flows to and from the App / Add-in (including EUII and OII ).
✓ M365 Data flows within the supporting infrastructure(where applicable)
✓ Diagrams highlighting where and what data is stored, how data is passed to external third parties(including details of what third parties) , and how data is protected in transit over open/public networks and at rest.
API Endpoint Details A complete listing of all API Endpoints used by your app. To help understand the environment scope, provide API endpoint locations within your environment.
Microsoft API Permissions Provide documentation detailing ALL the Microsoft APIs that are used along with what permissions are being requested for the app/add-in to function along with a justification for the requested permissions
Data storage types Data storage and handling documents describing:
✓ To what extent is your customers M365 Data EUII and OII is being received and stored
✓ The data retention period.
✓ Why the customer M365 Data is being captured.
✓ Where customer M365 Data is stored (should be included within data flow diagrams supplied above).
Compliance confirmation Supporting documentation for external security frameworks included within the Publisher Attestation submission or to be considered when reviewing Microsoft 365 Certification controls. Currently, the following three are supported:
PCI DSS Attestation of Compliance (AOC).
SOC 2 Type I/Type II reports.
ISMS / IEC - 1S0/IEC 27001 Statement of Applicability (SoA) and Certification.
Web Dependencies Documentation listing all dependencies used by the app / add-in with the current running versions.
Software Inventory An up-to-date software inventory which includes all software used within the in-scope environment along with the versions.
Hardware Inventory An up-to-date hardware inventory used by the supporting infrastructure. This will be used to help with sampling when performing the assessment phase. If your environment includes PaaS provide details of services consumed.

Evidence Collection and Assessment Activities

Through robust evidence collection and assessment activities, certification analysts will be able to assess your security posture to obtain an adequate level of data security assurance and adherence to the Microsoft 365 Certification Specification controls. Certification analysts will achieve this as follows:

Evidence Collection

  • Initial documentation, highlighted within the Initial Documentation Submission section above
  • Policy documents
  • Process documents
  • System configuration settings
  • Change tickets
  • Change control records
  • System reports

Various methods will be used to collect the evidence necessary to complete the assessment process. This evidence collection may be in the form of:

  • Documents
  • Screenshots
  • Interviews
  • Screensharing

The evidence collection techniques used will be determined during the assessment process.

Assessment Activities

Certification analysts will review evidence you provide to determine if you have adequately met controls within this Microsoft 365 Certification Specification.

Where possible and to reduce the amount of time required to complete the assessment, any or all of the documentation detailed in the Initial Documentation Submission should be provided in advance.

Certification analysts will first review the evidence provided from the initial documentation submission and the Publisher Attestation information to identify appropriate lines of inquiry, sampling size, and the need for further evidence to be obtained as detailed above. Certification analysts will analyze all information gathered to draw conclusions as to how and if you are meeting the controls within this Microsoft 365 Certification Specification.

App Certification Criteria

Your app, supporting infrastructure, and supporting documentation will be assessed across the following security domains:

  1. Application Security
  2. Operational Security / Secure Deployment
  3. Data Handling Security and Privacy
  4. Optional External Compliance Framework Review

Each of these security domains include specific key controls encompassing one or more specific requirements that will be evaluated as part of the assessment process. To ensure that Microsoft 365 Certification is inclusive to developers of all sizes, each of the four security domains is assessed using a scoring system to determine an overall score from each of the domains. Scores for each of the Microsoft 365 Certification controls are allocated between 1 (low) and 3 (high) based upon the perceived risk of that control not being met. Each of the four security domains will have a minimum percentage mark to be deemed a pass. Certain elements of this specification include some automatic fail criteria:

  • API permissions not following the principle of least privilege (PoLP).
  • No penetration testing report when it is required.
  • No anti-malware defenses
  • Multi-Factor authentication not being used to protect administrative access.
  • No patching processes.
  • No suitable GDPR privacy notice.

Application Security

The application security domain focuses upon the follow three areas:

  • GraphAPI Permission Validation
  • External Connectivity Checks
  • Application Security Testing

GraphAPI Permission Validation

GraphAPI permission validation is carried out to validate the app/add-in does not request overly permissive permissions. This is carried out by manually checking what permissions are requested. Certification analysts will cross reference these checks against the Publisher Attestation submission and evaluate the level of access being requested to ensure ‘least privilege’ practices are being met. Where certification analysts believe these ‘least privilege’ practices are not being met, certification analysts will have an open discussion with you to validate the business justification for the permissions being requested. Any discrepancies against your Publisher Attestation submission found during this review will also get feedback so your Publisher Attestation can be updated.

External Connectivity Checks

As part of the assessment, an Analyst will perform a light walk through of the applications functionality to identify connections outside of M365. Any connections which are not identified as being Microsoft or direct connections to your service will be flagged and discussed during the assessment.

Application Security Testing

An adequate review of the risks associated with your app/add-in and supporting environment is essential in providing customers with assurance in the security of the app/add-in. Application security testing in the form of penetration testing MUST be carried out if your application has any connectivity to any service not published by Microsoft. If your app operates standalone without connectivity to any non-Microsoft service or backend, then penetration testing is not required.

Penetration Testing Scope

Penetration testing activities MUST include the environment that supports the deployment of the app/add-in (for example; where the app/add-in code is hosted which will typically be the resource within the manifest file) along with any additional environment that supports the operation of the app/add-in (for example; if the app/add-in talks to other web applications outside of Microsoft 365). When defining the scope, care needs to be taken to ensure that any “connected-to” systems or environments that can impact upon the security of the in-scope environment is also included within ALL penetration testing activities.

Where techniques are used to segment the in-scope environments from other environments, penetration testing activities MUST validate the effectiveness of said segmentation techniques. This must be detailed within the penetration testing report.

Test Specification

Test Controls
Penetration testing Application and infrastructure penetration testing MUST take place annually (every 12 months) and conducted by a reputable independent company. Remediation of identified critical and high-risk vulnerabilities MUST be completed within one month of the conclusion of the penetration testing, or sooner depending on the documented patching process. The full external footprint (IP Addresses, URLs, API Endpoints, etc.) MUST be included within the scope of penetration testing and must be documented within the penetration testing report.The full external footprint (IP Addresses, URLs, API Endpoints, etc.) MUST be included within the scope of penetration testing and must be documented within the penetration testing report. Web application penetration testing MUST include all vulnerability classes; for example, the most current OWASP Top 10 or SANS Top 25 CWE. Retesting of identified vulnerabilities by the penetration testing company is not required — remediation and self-review is sufficient however, adequate evidence to demonstrate sufficient remediation MUST be provided during the assessment.

Application Security Testing Report Review

Penetration testing reports will be reviewed to ensure there are no vulnerabilities that meet the following automatic failure criteria:

  • Presence of an unsupported operating system.

  • Presence of default, enumerable, or guessable administrative accounts.

  • Presence of SQL injection risks.*

  • Presence of cross-site scripting.*

  • Presence of directory traversal (file path) vulnerabilities.*

  • Presence of HTTP vulnerabilities, e.g., Header response splitting, Request smuggling, and Desync attacks.*

  • Presence of source code disclosure (including LFI).*

  • Any critical or high score as defined by the CVSS patch management guidelines.

  • Any significant technical vulnerability which can be readily exploited to compromise a large amount of EUII or OUI.

*Regardless of the vulnerabilities CVSS Score

Important

Reports must be able to provide enough assurance that everything detailed within the Application Security Test Specification section can be demonstrated.

Penetration Testing Requirements and Cost

For ISVs that currently do not engage in penetration testing, penetration testing is included under the Microsoft 365 Certification. Microsoft will arrange and cover the cost of a penetration test for up to 12 days of manual testing. Penetration tests costs are calculated based on the number of days required to test the environment. Any expenses exceeding 12 days of testing will be the responsibility of the ISV. The ISV will also be responsible for demonstrating that vulnerabilities identified in the penetration test have been remediated prior to a certification being awarded, but do not need to produce a clean report.

Once a penetration test is arranged, the ISV is responsible for fees associated with rescheduling and cancellations as follows:

Rescheduling Fee Timescale Proportion Payable
Re-schedule request received more than 30 days prior to scheduled start date. 0% Payable
Re-schedule request received 8 to 30 days prior to scheduled start date. 25% Payable
Re-schedule request received within 2 to 7 days prior to scheduled start date with a firm re-booking date. 50% Payable
Re-schedule request received less than 2 days before the start date. 100% Payable
Cancellation Fee Timescale Proportion Payable
Cancellation request received more than 30 days prior to scheduled start date. 25% Payable
Cancellation request received 8 to 30 days days prior to scheduled start date. 50% Payable
Cancellation request received within 7 days prior to scheduled start date. 90% Payable

Operational Security

This domain measures the alignment of your app's supporting infrastructure and deployment processes with security best practices.

Test Specification

Test Controls
Malware Protection You must deploy malware protection mechanisms on all in-scope systems that are commonly affected by malware. These protection mechanisms can include the use of anti-virus software or application control techniques that protect against malware. Where anti-virus software or application control is used, it MUST meet the following criteria. Anti-virus (also including anti-malware products) MUST meet the following:
✓ Anti-virus software is running on all system components within scope.
✓ Anti-virus software is kept up to date (within 30 days).
✓ Anti-virus signatures are kept up to date (within 1 day).
✓ Either on-access scanning and/or periodic scans with notifications must be configured. Where on-access scanning is used, weekly scans MUST also be configured, however if on-access scanning is not configured, daily scanning must be configured.
✓ Anti-virus software MUST be configured as follows.
 ◼ Block suspected malware.
 ◼ Quarantine suspected malware.
 ◼ Provide an alert on suspected malware.
✓ Anti-virus software MUST be configured to log all activities.
✓ Policies and procedures MUST be in place to promote strong anti-malware practices.
or
Application controls MUST be configured on all in-scope system to meet the following:
✓ All allowed applications permitted to execute on in-scope system components MUST be formally approved by the organization..
✓ The organization MUST maintain a complete list of approved applications with business justification for the application.
✓ Specific application control mechanisms MUST be fully documented: i.e. whitelisted locations; code signing, etc.
✓ Application control MUST be configured as document.
✓ Documented process for application approvals must be in place and auditable.
Patch Management You MUST have documented patching policies and procedures in place that ensure patching is conducted in a timely manner. A robust process MUST be in place that identifies, ranks, and patches new security vulnerabilities based on the CVSS V3.1 Recommended Risk Ranking Scores, or equivalent scoring taxonomy:
Recommended Risk Ranking Scores (CVSS v3.1 Base Score Range)
Critical: 9.0 - 10.0.
High: 7.0 - 8.9.
Medium: 4.0 - 6.9.
Low: 0.1 - 3.9.
None: 0.0
IMPORTANT: The process to identify new vulnerabilities must be robust enough to allow for the identification and patching of vulnerabilities in line with the documented patching window you have defined.
Patching ✓ Any Critical, High, or Medium risk issues MUST be patched within a pre-determined and documented period decided by the ISV which represents the minimal window of time before the issue must be resolved. Although the patching window is defined by the ISV, the window needs to be within a reasonable timeframe. For example, three months to patch a Critical vulnerability would not be reasonable and therefore rejected within your Microsoft 365 Certification assessment.
✓ Policies and procedures detailing how patching is conducted MUST be in place and MUST include all applicable operating systems, applications and software components used within the environment. This includes any web dependencies used within the app/add-in.
✓ Software components and operating systems no longer supported by the vendor MUST not be used within the environment. Supporting policies MUST be in place to ensure unsupported software components / operating systems will be removed from the environment and a process to identify when software components go end-of-life must be in place.
Vulnerability scanning Vulnerability scanning must include:
✓ Quarterly external vulnerability scanning carried out against the FULL public footprint of the in-scope environment (URLs AND IP Addresses for Infrastructure and Web Application scanning).
✓ Quarterly authenticated internal vulnerability scanning carried out against in-scope system components (not for PaaS).
✓ A documented vulnerability remediation policy MUST be in place to ensure system components are free from known vulnerabilities by detailing the timeline to fix vulnerabilities based upon your defined CVSS Recommended Risk Ranking Scores(see above).
✓ Ongoing re-scans MUST be carried out until identified risk ranked vulnerabilities are remediated within the required timeline, as defined by the ISV’s remediation policy. Although the remediation timeline is defined by the ISV, the window needs to be within a reasonable timeframe. For example, three months to remediate a Critical vulnerability would not be reasonable and therefore rejected within your Microsoft 365 Certification assessment.
Firewalls Your supporting infrastructure will be expected to have a firewall (or equivalent where Cloud services are being consumed) configured as follows:
MUST be installed on all internet connections exposing the in-scope environments.
MUST be installed between all DMZs (Demilitarized Zones) and any trusted networks.
✓ All public access MUST terminate in a DMZ (Demilitarized Zone).
✓ Default administrative credentials MUST be changed, prior to installation into production environments.
✓ ­All traffic permitted through in-scope firewalls (in either direction) MUST go through an approval process and all protocols, services and ports must be documented with business justifications.
✓ Firewall rules must be configured in-line with the documented permitted rules.
✓ ­Strong cryptography, in line with Appendix B, MUST be enabled on all firewall non-console administrative interfaces.
✓ Multi-factor authentication (MFA) MUST be enabled for firewall administrative access..
✓­ Firewall reviews MUST be conducted at least every six months.
Certification analysis will review the firewall rules base for the presence of egress traffic flows to potential third parties to validate external third-party data sharing.
Web Application Firewall (WAF). Additional credit will be given if a WAF or equivalent measure is deployed to help protect against web application threats and vulnerabilities. If present, supporting policies and procedures SHOULD be in place along with the following WAF configurations:
✓ WAF SHOULD operate in active defense mode (automatically blocking identified attacks) or in monitoring mode (actively monitoring/investigating alerts).
✓ WAF configured to support SSL offloading.
✓ WAF SHOULD be configured as per the OWASPCore Rule Set (3.0 or 3.1) to protect against the majority of the following:
 ◼ Protocol and encoding issues.
 ◼ Header injection, request smuggling, and response splitting.
 ◼ File and path traversal attacks.
 ◼ Remote file inclusion (RFI) attacks.
 ◼ Remote code execution attacks.
 ◼ PHP-injection attacks.
 ◼ Cross-site scripting attacks.
 ◼ SQL-injection attacks.
 ◼ Session-fixation attacks.
Change Control Change control policies and procedures MUST be in place to ensure that changes are implemented in a manner aimed at maintaining the security, stability, and integrity of the environment. The following change control criteria ARE required:
✓ Separation of duties—development and test environments MUST be separate from the production environments.
✓ Sensitive data from production environments MUST not be used within development/test environments.
✓ All changes MUST be tested within a test/development environment prior to being introduced into the production environment.
✓ Change requests ARE raised and authorized PRIOR to going into production.
✓ At a minimum, change requests MUST include:
 ◼ Documentation of impact.
 ◼ Documented back-out procedures.
✓ Change requests MUST be marked as complete, only AFTER successful functionality testing has been carried out.
Secure Software Development/Deployment Security needs to be at the forefront of software development practices to minimize the risk of introducing coding vulnerabilities into the app / add-in, thereby maintaining a secure environment, and securing data. The following software development secure practices MUST be in place:
✓ You MUST have an established and documented software development process covering the entire software-development lifecycle.
✓ All code changes MUST go through a review and authorization process by someone other than the original developer.
✓ Secure coding practices and review techniques MUST address the OWASP Top 10 or SANS Top 25 CWE Vulnerability Classes.
✓ Developers MUST undergo secure software coding training at least annually.
✓ Code repositories MUST be secured by MFA.
✓ Adequate access controls MUST be in place to protect code repositories against malicious code modifications.
Note: Microsoft has published the Security Development Lifecycle (SDL) that Microsoft follows to support security assurance and compliance requirements within its products. The SDL helps developers build more secure software by reducing the number and severity of vulnerabilities in software, while reducing development cost.
Account Management In-scope system component account management as well as supporting policies and procedures MUST meet the following:
✓ Default credentials (Vendor or ISV) ARE either disabled or removed across all in-scope system components.
✓ Account creation, modification and deletion MUST go through an established approval process.
✓ Accounts that have not been used for over 3 months MUST be disabled or deleted, therefore, ISV needs to have a mechanism of achieving this.
✓Strong password policies or other suitable mitigation MUST be configured to protect user credentials. The following password policy should be used as a guideline:
 ◼ Minimum password length of eight characters
 ◼ Account lockout threshold of no more than 10 attempts
 ◼ Password history of a minimum of five passwords
 ◼ Enforcement of the use of strong passwords
✓ Unique user accounts MUST be issued to each user; no shared accounts are to be used.
✓ Least privilege principles MUST apply to all users, the mechanism used to achieve this should be documented (i.e. the use of groups).
✓ Suitable service account hardening MUST be documented and carried out, for example, interactive logon disabled, logons limited to specific hosts, etc.
✓ Remote Access solutions MUST:
 ◼ utilize MFA (Multi Factor Authentication)
 ◼ utilize a data in transit protection profile that meets or exceeds the data-in-transit configuration profile as described in Appendix A
✓ Where the management of Public DNS is outside of the in-scope environment, all user accounts able to make DNS modifications MUST be configured to use MFA.
Note : Cloud Management Portals will also need to meet applicable account management requirements, see Appendix F for further details.
Intrusion Detection and Prevention (OPTIONAL) Extra credit will be given where IDPS (Intrusion Detection and Prevention System) is used at the perimeter of the in-scope supporting environments. The following recommended controls include:
✓ IDPS SHOULD be deployed at the perimeter of the supporting environment
✓ IDPS signatures SHOULD be kept current, within the past day
✓ IDPS SHOULD be configured for TLS inspection
✓ IDPS SHOULD be configured for ALL inbound and outbound traffic
✓ IDPS SHOULD be configured for alerting
Event Logging Logging coverage MUST include ALL in-scope system components and applications, including malware protection mechanisms. The following events MUST be logged:
 ◼ Users access to system components and the application
 ◼ All actions taken by a high-privileged user
 ◼ Invalid logical access attempts
 ◼ Privileged account creation / modification
 ◼ Event log tampering
 ◼ Disabling of security tools; for example, Anti-Malware or event logging
 ◼ Anti-Malware logging; for example, updates, malware detection, scan failures
 ◼ IDPS/WAF events (if configured)
­Event logs MUST include the following information:
 ◼ User Identification
 ◼ Type of event
 ◼ Date and time
 ◼ Success/Failure indicator
 ◼ Label to identify the affected system
­Time-synchronization MUST be used across all in-scope system components to aid in forensic investigations.
Time-synchronization MUST be configured to utilize the same primary (and secondary if required) time source
­Public facing systems (systems within the DMZ) MUST write logs to an internal centralized logging repository. The centralized logging repository must not be within the DMZ.
­ Audit trails MUST be secured to ensure log data cannot be altered by a threat actor. Access to the centralized logging repository must be limited to authorized personnel only.
­ Logs MUST be immediately available for 30 days. Logging data MUST be retained for a minimum of 90 days.
Reviewing Review processes as well as supporting policies and procedures MUST meet the following:
✓ Perform daily log reviews or utilize automated log analysis and alerting technology to review events from all in-scope system components to identify any potential security events.
✓ Potential security events MUST be immediately followed up.
Alerting Alerting processes as well as supporting policies and procedures MUST meet the following:
✓ Logged security events that pose a risk to the security of your systems, operations or data MUST trigger an immediate alert, for example (not an exhaustive list):
 ◼ Privilege account creation / modifications
 ◼ Malware events
 ◼ Disabling security tools
 ◼ Event log tampering
 ◼ IDPS / WAF events (if configured)
✓ Staff MUST always be available (24/7) to react to triggered alerts.
Risk management A risk-assessment methodology must be developed and conducted that includes the following:
✓ A formally defined process.
✓ Performed at least annually.
✓ Includes all assets within the in-scope environment.
✓ Identifies threats and vulnerabilities against all included assets.
✓ Includes the use of defined impact and likelihood matrices.
✓ Results in the creation of a risk register and corresponding risk treatment plan.
Incident response A thorough incident response plan IS required and MUST include as a minimum:
✓ At a minimum, coverage of the in-scope systems components and applications.
✓ Specific incident response procedures for expected threat models.
✓ Documented communications process, ensuring the timely notification of all key stakeholders and any relevant external bodies such as; payment brands/acquirers, regulatory bodies and supervisory authorities (GDPR) in line with mandated reporting requirements.
✓ The incident response is updated based upon lessons learned, organizational changes and to incorporate industry developments.
✓ Annual training for members of the incident response team.

Data Handling Security and Privacy

Data in transit between the application user, intermediary services, and ISV’s systems will be required to be protected by encryption through a TLS connection supporting a minimum of TLS v1.1.See Appendix A.

Where your application retrieves and stores M365 data you will be required to implement a data storage encryption scheme that follows the specification as defined in Appendix B.

Test Specification

Test Controls
Data in Transit Transmission of sensitive data MUST use a minimum of TLS 1.1 with a few exceptions described in Appendix A.
Transmission of sensitive data MUST be suitably encrypted in line with encryption profiles described in Appendix B.
TLS compression must be disabled.
HSTS (HTTP Strict Transport Security) MUST be configured to >= 15552000
Data at Rest Sensitive data storage MUST be protected in line with the encryption profiles described in Appendix B covering minimum requirements of encryption, algorithms, key sizes, hashing and message authentication.
All stored data types MUST be documented.
Data Retention and Disposal Sensitive data storage MUST be kept to a minimum by implementing data retention and disposal policies, procedures and processes that minimally include:
✓ Document and limit data storage amount and retention time to that which is required for legal, regulatory, and/or business requirements.
✓ Document and deploy processes for secure deletion of sensitive data when no longer needed, in-line with documented policies.
✓ Document and deploy a quarterly process for identifying and securely deleting stored sensitive data that exceeds the defined retention period.
Data Access Management Limiting data access to those with a legitimate business reason helps organizations prevent mishandling of sensitive data through inexperience or malice. Sensitive data, received by the app/add-in and access to encryption keys requires documented approval (electronic or in writing) for authorized parties at all access levels to access and must include a listing of approved and verified privileges demonstrating the policy incorporates the specified requirements as follows:
✓ Defining access needs and privilege assignments only to roles that specifically require such privileged access.
✓ Restricting access to the least privileges necessary to perform job responsibilities.
✓ Ensure data sharing agreements are in place with all third-parties consuming M365 data.
GDPR As part of the Microsoft 365 Certification process, you must demonstrate adherence to the GDPR, either by:
✓ Providing an independent review of the GDPR conformance by an experienced external audit company. You will be required to submit the report for review or allow the analyst to view the report. The report should provide enough details to not only validate the external auditor’s assessment but also provide enough confidence that the external review has confirmed conformance to the GDPR.
or
✓ Submitting further evidence to provide additional assurance of your commitment to data privacy laws, as follows:
◼ A documented subject access request (SAR) process designed to meet the requests of customers and meet the thirty-day requirement of the GDPR. It is recommended that adequate data discovery tooling is in place to ensure a SAR is fulfilled within these time frames. Note : Where these tools are not used, you will need to demonstrate how this works and demonstrate how the processes are able to guarantee discovery of all data subject’s information.
◼Privacy Notices must be present on the website and contain the following information:
Where an independent GDPR report isn’t available, the following must be in place to be reviewed as part of the M365 Certification assessment:
✓ A documented subject access request (SAR) process designed to meet the requests of customers and meet the thirty-day requirement of the GDPR. It is recommended that adequate data discovery tooling is in place to ensure a SAR is fulfilled within these time frames, where these tools aren't used, you will need to demonstrate how this works and demonstrate how the processes are able to guarantee discovery of all data subject’s information.
✓ Privacy Notices must be present on the website and contain the following information:
  □ Organizations contact details.
  □ Type of personal data being processed.
  □ Lawfulness of processing personal data (Article 6).
  □ Details of data subject's rights:
  □ Right to be informed (Articles13 and 14).
  □ Right of access by the data subject (Article 15).
  □ Right of rectification (Article 16).
  □ Right to erasure (Article 17).
  □ Right to restriction of processing (Article 18).
  □ Right to data portability (Article 20).
  □ Right to object (Article 21).
  □ Rights in relation to automated decision-marking, including profiling (Article 22).
✓ Information sharing with third-parties must have agreements in place to ensure processing of data subject’s data are in line with data privacy laws.

Optional External Compliance Frameworks Review

If external security frameworks have been included within the Publisher Attestation, certification analysts will need to check the validity of those security compliance frameworks as part of the Microsoft 365 Certification assessment. Evidence for the following supported external security compliance frameworks include:

Documentation identified within the Compliance Evidence section will be used to perform this review.

Test Specifications

✓ The App/Add-in supporting environment AND any supporting business processes MUST be included within the scope of any supported external security compliance frameworks and must be clearly indicated in supplied documentation.

✓ Supported external security compliance frameworks MUST be current, i.e. within the past 12 months (or within 15months if the re-assessment is currently being carried out and evidence can be provided).

✓ Supported external security compliance frameworks MUST be carried out by an independent accredited company.

Appendix A

TLS Profile configuration requirements

All network traffic, whether within a virtual network, cloud service, or a data center, must be protected with a minimum of TLS v1.1 (TLS v1.2+ is recommended) or other applicable protocol. Exceptions to this requirement are:

  • HTTP-to-HTTPS redirect. Your app can respond over HTTP to redirect clients to HTTPS, but the response must not contain any sensitive data (cookies, headers, content). No other HTTP responses other than redirects to HTTPS and responding to health probes are allowed. See below.
  • Health probes. Your app can respond to health probes over HTTP only if HTTPS health probes are not supported by the checking party.
  • Certificate access. Access to CRL, OCSP, and AIA endpoints for the purposes of certificate validation and revocation checking is allowed over HTTP.
  • Local communications. Your app can use HTTP (or other non-protected protocols) for communications that do not leave the operating system, e. g. connecting to a web server endpoint exposed on localhost.

TLS Compression MUST be disabled.

Appendix B

Encryption Profile Configuration Requirements

Only cryptographic primitives and parameters are permitted as follows:

Symmetric cryptography

Encryption

 ✓ Only AES, BitLocker, Blowfish or TDES are allowed. Any of the supported key lengths >=128 are allowed (128, 192, and 256 bits) and may be used (256-bit keys are recommended).

 ✓ Only CBC mode is allowed. Every encryption operation must use a fresh, randomly generated initialization vector (IV).

 ✓ Use of stream ciphers, such as RC4, IS NOT allowed.

Hash functions

 ✓ All new code must use SHA-256, SHA-384, or SHA-512 (collectively referred to as SHA-2). Output may be truncated to no less than 128 bits

 ✓ SHA-1 may only be used for compatibility reasons.

 ✓ Use of MD5, MD4, MD2 and other hash functions IS NOT allowed, even for non-cryptographic applications.

Message authentication

 ✓ All new code MUST use HMAC with one of the approved hash functions. Output of HMAC may be truncated to no less than 128 bits.

 ✓ HMAC-SHA1 may only be used for compatibility reasons.

 ✓ HMAC key MUST be at least 128 bits. 256-bit keys are recommended.

Asymmetric algorithms

Encryption

 ✓ RSA is allowed. Key MUST be at least 2048 bits and OAEP padding must be used. Use of PKCS padding only allowed for compatibility reasons.

Signatures

 ✓ RSA is allowed. Key MUST be at least 2048 bits and PSS padding must be used. Use of PKCS padding only allowed for compatibility reasons.

 ✓ECDSA is allowed. Key MUST be at least 256 bits. NIST P-256, P-384 or P-521 curve must be used.

Key Exchange

 ✓ ECDH is allowed. Key MUST be at least 256 bits. NIST P-256, P-384 or P-521 curve must be used.

 ✓ ECDH is allowed. Key MUST be at least 256 bits. NIST P-256, P-384 or P-521 curve must be used.

Appendix C

Evidence Collection – Delta for ISO 27001

Where you have already attained ISO27001 compliance, the following delta’s (gaps) not wholly covered by ISO 27001 will, at a minimum, need to be reviewed as part of this Microsoft 365 Certification.

Note

As part of your Microsoft 365 Certification assessment, the certification analyst will determine if any of the mapped ISO 27001 controls were not included as part of the ISO 27001 assessment and may also decide to sample controls that were found to be included to provide further assurance. Any requirements missing from the ISO 27001 will need to be included within your Microsoft 365 Certification assessment activities.

Malware Protection – Anti Virus

If malware protection is in place using application control and is attested to within ISO 27001 Report no further investigation is necessary. If no application control is in place, certification analysts will need to identify and assess evidence of application control mechanisms to prevent detonation of malware within the environment. This will require you to:

  • Demonstrate that anti-virus software is running across all sampled system components.

  • Demonstrate that anti-virus is configured across all sampled system components to either automatically block malware, to quarantine & alert or to alert.

  • Anti-virus software MUST be configured to log all activities.

Patch Management – Patching

As ISO 27001 audits do not specifically assess this category, this will require you to:

  • Software components and operating systems no longer supported by the vendor MUST not be used within the environment. Supporting policies MUST be in place to ensure unsupported software components / operating systems will be removed from the environment and a process to identify when software components go end-of-life must be in place

Vulnerability Scanning

As ISO 27001 audits do not specifically assess this category, this will require you to:

  • Demonstrate that quarterly internal and external vulnerability scanning is conducted.

  • Confirm supporting documentation is in place for vulnerability remediation based on risk ranking and in line with the specification as follows:

✓ Fix all Critical and Highs risk issues in-line with the risk ranking for Internal scanning.

✓ Fix all Critical, Highs and Medium risk issues in-line with the risk ranking for external scanning.

✓ Demonstrate that remediation is conducted in-line with the documented vulnerability remediation policy.

Firewall – Firewalls (or equivalent technologies)

As ISO 27001 audits do not specifically assess this category, this will require you to:

  • Demonstrate that firewalls are installed on the boundary of the in-scope environment.

  • Demonstrate that firewalls are installed between the DMZ and trusted networks.

  • Demonstrate that all public access terminates in the DMZ.

  • Demonstrate that default administrative credentials are changed prior to installation into the live environment.

  • Demonstrate that all permitted traffic through the firewall(s) goes through an authorization process which results in the documentation of all traffic with a business justification.

  • Demonstrate that all firewalls are configured to drop traffic not explicitly defined.

  • Demonstrate that firewalls support only strong cryptography on all non-console administrative interfaces.

  • Demonstrate that firewall's non-console administrative interfaces exposed to the Internet support MFA.

  • Demonstrate that firewall rule reviews are conducted at least every 6 months

Firewall – Web Application Firewalls (WAF)

Additional credit will be provided if a WAF is deployed to help protect against the myriad of web application threats and vulnerabilities that the application can be exposed to. When a WAF or similar is present, this will require you to:

  • Demonstrate the WAF is configured in active defense mode or monitoring more with alerting.

  • Demonstrate the WAF is configured to support SSL Offloading.

  • Is configured as per the OWASP Core Rule Set (3.0 or 3.1) to protect against most of the following attack types:

✓ Protocol and encoding issues.

✓ Header injection, request smuggling, and response splitting.

✓ File and path traversal attacks.

✓ Remote file inclusion (RFI) attacks.

✓ Remote code execution attacks.

✓ PHP-injection attacks.

✓ Cross-site scripting attacks.

✓ SQL-injection attacks.

✓ Session-fixation attacks.

Change Control

As ISO 27001 audits do not specifically assess some elements of Change Request processes, this will require you to:

  • Demonstrate that change requests have the following details:

✓ Documented impact.

✓ Details of what functionality testing is to be conducted.

✓ Details of any back-out procedures.

  • Demonstrate that functionality testing is conducted after changes are completed.

  • Demonstrate that change requests are signed off after functionality testing is conducted.

Account Management

As ISO 27001 audits do not specifically assess some elements of account management processes, this will require you to:

  • Demonstrate how ✓s are implemented to mitigate replay attacks (e.g. MFA, Kerberos).
  • Demonstrate how accounts that have not been used in 3 months are either disabled or deleted.
  • ✓ or other suitable mitigations must be configured to protect user credentials. The following minimum password policy should be used as a guideline:

✓ Minimum password length of 8 characters.

✓ Account lockout threshold of no more than 10 attempts.

✓ Password history of a minimum of five passwords.

✓ Enforcement of the use of strong passwords.

  • Demonstrate that MFA is configured for all remote access solutions.

  • Demonstrate that strong encryption is configured on all remote access solutions.

  • Where the management of Public DNS is outside of the in-scope environment, all user accounts able to make DNS modifications MUST be configured to use MFA.

Intrusion Detection and Prevention (OPTIONAL)

As ISO 27001 audits do not specifically assess some elements of Intrusion Detection and Prevention Services (IDPS) processes, this will require you to:

  • IDPS SHOULD be deployed at the perimeter of the supporting environment.

  • IDPS signatures SHOULD be kept current, within the past day.

  • IDPS SHOULD be configured for TLS inspection.

  • IDPS SHOULD be configured for ALL inbound and outbound traffic.

  • IDPS SHOULD be configured for alerting.

Event Logging

As ISO 27001 audits do not specifically assess some elements of security event logging processes, this will require you to:

  • Demonstrate that public facing systems are logging to a centralized logging solution which isn't within the DMZ.

  • Demonstrate how a minimum of 30 days’ worth of logging data is immediately available, with 90 days being retained.

Reviewing (Logging Data)

As ISO 27001 audits do not specifically assess some elements of this category, this will require you to:

  • Demonstrate how daily log reviews are conducted and how exceptions and anomalies are identified showing how these are handled.

Alerting

As ISO 27001 audits do not specifically assess some elements of this category, this will require you to:

  • Demonstrate how security events are configured to trigger alerts for immediate triage.

  • Demonstrate how staff are available 24/7 to respond to security alerts.

Risk Management

As ISO 27001 audits do not specifically assess some elements of risk assessment processes, this will require you to:

  • Demonstrate that a formal risk management process is established.

Incident Response

As ISO 27001 audits do not specifically assess some elements of incident response policies and processes, this will require you to:

  • Demonstrate that the incident response plan/procedure includes:

✓ Specific response procedures for expected threat models.

✓ Incident handling capabilities aligning to NIST Cybersecurity Framework (Identify, Protect, Detect, Respond, Recover).

✓ The IRP covers the in-scope systems.

✓ Annual training for the incident response team.

Appendix D

Evidence Collection – Deltas for PCI DSS

Where you have already attained PCI DSS compliance, the following delta’s (gaps) not wholly covered by PCI DSS will, at a minimum, need to be reviewed as part of this Microsoft 365 Certification.

Note

As part of the Microsoft 365 Certification assessment, the certification analyst will determine if any of the mapped PCI DSS controls were not included as part of the PCI DSS assessment and may also decide to sample controls that were found to be included to provide further assurance. Any requirements missing from the PCI DSS will need to be included into the Microsoft 365 Certification assessment activities.

Malware Protection - Application Control

If malware protection is in place through use of anti-virus and is attested to within PCI DSS Report no further investigation is necessary. If no anti-virus is in place, certification analysts will need to identify and assess evidence of application control mechanisms to prevent detonation of malware within the environment. This will require you to:

  • Demonstrate how the application approval is conducted and confirm that this is completed.

  • Demonstrate that a complete list of approved applications with business justification exists.

  • Provide or demonstrate supporting documentation is in place detailing how application control software is configured to meet specific application control mechanisms (i.e. whitelisting, code signing, etc.).

  • Demonstrate that across all sampled system components, application control is configured as documented.

Patch Management – Risk Ranking

As PCI DSS audits do not specifically assess this category, this will require you to:

  • Demonstrate how risk ranking of vulnerabilities is conducted.

Vulnerability Scanning

As PCI DSS audits do not specifically assess this category, this will require you to:

  • Demonstrate that remediation is conducted in-line with the documented vulnerability remediation policy.

Firewall – Firewalls (or equivalent technologies)

As PCI DSS audits do not specifically assess this category, this will require you to:

  • Demonstrate that firewalls support only strong cryptography on all non-console administrative interfaces.

  • Demonstrate that firewall's non-console administrative interfaces exposed to the Internet support MFA.

Additional credit will be provided if a Web Application Firewall (WAF) s deployed to help protect against the myriad of web application threats and vulnerabilities that the application can be exposed to. When a WAF or similar is present, this will require you to:

  • Demonstrate the WAF is configured in active defense mode or monitoring more with alerting.

  • Demonstrate the WAF is configured to support SSL offloading.

  • Is configured as per the OWASP Core Rule Set (3.0 or 3.1) to protect against most of the following attack types:

✓ Protocol and encoding issues.

✓ Header injection, request smuggling, and response splitting.

✓ File and path traversal attacks.

✓ Remote file inclusion (RFI) attacks.

✓ Remote code execution attacks.

✓ PHP-injection attacks.

✓ Cross-site scripting attacks.

✓ SQL-injection attacks.

✓ Session-fixation attacks.

Change Control

As PCI DSS audits do not specifically assess some elements of Change Request processes, this will require you to:

  • Demonstrate that change requests are raised before being made in production environments.

  • Demonstrate that changes are authorized before going into production.

  • Demonstrate that functionality testing is conducted after changes are completed.

  • Demonstrate that change requests are signed off after functionality testing is conducted.

Secure Software Development/Deployment

As PCI DSS audits do not specifically access some elements of secure software development and deployment processes; this will require to you:

  • Code repositories MUST be secured by MFA.

  • Adequate access controls MUST be in place to protect code repositories against malicious code modifications.

Account Management

As PCI DSS audits do not specifically assess some elements of account management processes, this will require you to:

  • Demonstrate how the authorization mechanisms are implemented to mitigate replay attacks (e.g. MFA, Kerberos).

  • Strong password policies or other suitable mitigations must be configured to protect user credentials. The following minimum password policy should be used as a guideline:

✓ Minimum password length of 8 characters.

✓ Account lockout threshold of no more than 10 attempts.

✓ Password history of a minimum of five passwords.

✓ Enforcement of the use of strong passwords.

  • Demonstrate that strong encryption is configured on all remote access solutions.

  • Where the management of Public DNS is outside of the in-scope environment, all user accounts able to make DNS modifications MUST be configured to use MFA.

Intrusion Detection and Prevention (OPTIONAL)

As PCI DSS audits do not specifically assess some elements of Intrusion Detection and Prevention Services (IDPS) processes, this will require you to:

  • IDPS SHOULD be configured for TLS inspection.

  • IDPS SHOULD be configured for ALL inbound and outbound traffic.

Risk Management

As PCI DSS audits do not specifically assess some elements of risk assessment processes, this will require you to:

  • Demonstrate the risk assessment includes impact and likelihood matrices.

Incident Response

As PCI DSS audits don't specifically assess some elements of incident response policies and processes, this will require the developer to:

  • Demonstrate Incident handling capabilities align to NIST Cybersecurity Framework (Identify, Protect, Detect, Respond, Recover).

Appendix E

Evidence Collection - Deltas for SOC 2

Where you have already attained SOC 2 compliance, the following delta’s (gaps) not wholly covered by SOC 2 will need to be reviewed as part of this Microsoft 365 Certification.

Note

As part of the Microsoft 365 Certification assessment, the certification analyst will determine if any of the mapped SOC 2 controls were not included as part of your SOC 2 assessment and may also decide to sample controls that were found to be included to provide further assurance. Any requirements missing from your SOC 2 assessment will need to be included as part of the Microsoft 365 Certification assessment activities.

Malware Protection - Application Control

If malware protection is in place through use of anti-virus and is attested to within your SOC 2 report no further investigation is necessary. If no anti-virus is in place, certification analysts will need to identify and assess evidence of application control mechanisms to prevent detonation of malware within the environment. This will require you to:

  • Provide or demonstrate supporting documentation is in place detailing how application control software is configured to meet specific application control mechanisms (i.e. whitelisting, code signing, etc.).

  • Demonstrate how the application approval is conducted and confirm that this is completed.

  • Demonstrate that a complete list of approved applications with business justification exists.

  • Demonstrate that across all sampled system components, application control is configured as documented.

Patch Management – Patching

As SOC 2 audits do not specifically assess this category, this will require you to:

  • Any Low, Medium, High, or Critical issue must be patched within normal patching activity windows.

  • Software components and operating systems no longer supported by the vendor MUST not be used within the environment. Supporting policies MUST be in place to ensure unsupported software components / operating systems will be removed from the environment and a process to identify when software components go end-of-life must be in place.

Firewall – Firewalls

As SOC 2 audits do not specifically assess change controls to firewall access control lists, this will require you to:

  • Demonstrate that all permitted traffic through the firewall(s) goes through an authorization process which results in the documentation of all traffic with a business justification.

  • Demonstrate that firewall rule reviews are conducted at least every six months.

Additional credit will be provided if a Web Application Firewall (WAF) or similar is deployed to help protect against the myriad of web application threats and vulnerabilities that the application can be exposed to. When a WAF or similar is present, this will require you to:

  • Demonstrate the WAF is configured in active defense mode or monitoring more with alerting.

  • Demonstrate the WAF is configured to support SSL offloading.

  • Is configured as per the OWASP Core Rule Set ((3.0 or 3.1) to protect against the majority of the following attack types:

 ✓ Protocol and encoding issues.

 ✓ Header injection, request smuggling, and response splitting.

 ✓ File and path traversal attacks.

 ✓ Remote file inclusion (RFI) attacks.

 ✓ Remote code execution attacks.

 ✓ PHP-injection attacks.

 ✓ Cross-site scripting attacks.

 ✓ SQL-injection attacks.

 ✓ Session-fixation attacks.

Change Control

As SOC 2 audits don't specifically assess some elements of Change Request processes, this will require the developer to:

  • Demonstrate how development / test environments are separate from the production environment enforcing separation of duties.

  • Demonstrate how live data isn't used within the development / test environments.

  • Demonstrate that functionality testing is conducted after changes are completed.

  • Demonstrate that change requests are signed off after functionality testing is conducted.

Secure Software Development/Deployment

As SOC 2 audits do not specifically access some elements of secure software development and deployment processes; this will require to you:

  • You MUST have an established and documented software development process covering the entire software-development lifecycle.

  • Developers MUST undergo secure software coding training at least annually.

  • Code repositories MUST be secured by MFA.

  • Adequate access controls MUST be in place to protect code repositories against malicious code modifications.

Account Management

As SOC2 audits do not specifically assess some elements of account management processes, this will require you to:

  • Demonstrate how the authorization mechanisms are implemented to mitigate replay attacks (e.g. MFA, Kerberos).

  • Demonstrate how accounts that have not been used in 3 months are either disabled or deleted.

  • Strong password policies or other suitable mitigations must be configured to protect user credentials. The following minimum password policy should be used as a guideline:

 ✓ Minimum password length of 8 characters.

 ✓ Account lockout threshold of no more than 10 attempts.

 ✓ Password history of a minimum of 5 passwords.

 ✓ Enforcement of the use of strong passwords

  • Demonstrate that unique user accounts are issued to all users.

  • Where the management of Public DNS is outside of the in-scope environment, all user accounts able to make DNS modifications MUST be configured to use MFA.

Intrusion Detection and Prevention (OPTIONAL).

As SOC 2 audits do not specifically assess some elements of Intrusion Detection and Prevention Services (IDPS) processes, this will require you to:

  • IDPS signatures SHOULD be kept current, within the past day

  • IDPS SHOULD be configured for TLS inspection

  • IDPS SHOULD be configured for ALL inbound and outbound traffic

Event Logging

As SOC 2 audits do not specifically assess some elements of security event logging processes, this will require you to:

  • Demonstrate how, on all system components within the sample set the following system are configured to log the following events

 ✓ User access to system components and the application(s).

 ✓ All actions taken by a high privileged user.

 ✓ Invalid logical access attempts.

Demonstrate that logged events contain; at a minimum, the following information:

 ✓ User.

 ✓ Type of Event.

 ✓ Date and Time.

 ✓ Success/Failure indicator.

 ✓ Label to identify the affected system.

  • Demonstrate that all system components within the sample set are configured to utilize time-synchronization and that these are the same as the primary/secondary time servers.

  • Demonstrate that public facing systems are logging to a centralized logging solution which isn't within the DMZ.

  • Demonstrate that public facing systems are logging to a centralized logging solution which isn't within the DMZ.

  • Demonstrate how the centralized logging solution is protected from unauthorized tampering of logging data.

  • Demonstrate how a minimum of 30 days’ worth of logging data is immediately available, with 90 days’ or more being retained.

Risk Management

As SOC2 audits do not specifically assess some elements of risk assessment processes, this will require you to:

  • Demonstrate that a formal risk assessment is conducted at least annually.

Incident Response.

As SOC2 audits do not specifically assess some elements of incident response policies and processes, this will require you to:

  • Demonstrate that the incident response plan/procedure includes:

 ✓ Specific response procedures for expected threat models.

 ✓ Documented communications process to ensure timely notification of key stakeholders (payment brands/acquirers, regulatory bodies, supervisory authorities, directors, customers, etc.

Appendix F

Hosting Deployment Types

Microsoft acknowledges you will deploy applications and store app/add-in code within different hosting environments. The overall responsibilities of some of the security controls within the Microsoft 365 Certification will depend on the hosting environment being used. Appendix F looks at common deployment types and maps these against the security controls that are evaluated as part of the assessment process. The following hosting deployment types have been identified:

ISV Hosted ISV hosted types can be defined as where you are responsible for the infrastructure used to support the app/add-in environment. This can be physically located within your own data centers or third-party data centers with a co-location service. Ultimately, you have full ownership and administrative control over the supporting infrastructure and operating environment.
Infrastructure as a Service (IaaS) (https://azure.microsoft.com/en-gb/overview/what-is-iaas/) Infrastructure as a Service is a service that is provided whereby the physical supporting infrastructure is managed and maintained on their behalf by the cloud service provider (CSP). Typically, networking, storage, physical servers, and the virtualization infrastructure is all the responsibility of the CSP. The Operating System, Middleware, Runtime, Data and Applications are the responsibilities of you. Firewalling capabilities would also be managed and maintained by the third-party, however maintenance of the firewall rule base would usually be still the consumers responsibility.
Platform as a Service/Serverless (PaaS) (https://azure.microsoft.com/en-gb/overview/what-is-paas/) With Platform as a Service, you are provisioned with a managed platform presenting a service that can be consumed. You do not need to perform sysadmin functions as the operating system and supporting infrastructure is managed by the CSP. This would typically be used when organizations do not want to be concerned with presenting a web service and instead can concentrate on creating the web application source code and publishing the web application on the cloud managed web services. Another example may be a database service where connectivity is given to a database, however the supporting infrastructure and database application is abstracted from the consumer. Note: Serverless and PaaS are similar so for the purpose of the Microsoft 365 Certification Hosting Deployment Type's Serverless and PasS are deemed the same
Hybrid Hosted With the hybrid hosted type, you may utilize multiple hosted types to support various parts of the supporting environment. This may be more the case where apps/add-ins are utilized across multiple M365 stacks. Although the Microsoft 365 Certification will support where apps/add-ons across multiple M365 services are developed, an assessment of the entire (across app/add-ins) supporting environment would need to be assessed in line with each of the applicable "Hosted Type Mappings". Occasionally, you may utilize different hosted types for a single add-in, where this is being carried out, applicability of criteria will need to still follow the "Hosted Type Mappings" criteria across the various hosted types.
Shared Hosting Shared hosting is where you are hosting the environment within a platform that shared by multiple individual consumers. The Microsoft 365 Certification Specification was not written to account for this due to the adoption of cloud, shared hosting is not common. If you believe this is being used please contact Microsoft as additional requirements will need to be created to account for the additional risks under this type of hosting type.

Appendix G

Microsoft 365 Certification Process Workflow

Workflow

Learn more

Microsoft 365 App Compliance Program Overview
What is Microsoft 365 App Publisher Attestation?
What is Microsoft 365 Certification?

Glossary

AIA

*Authority Information Access is a service location descriptor used to find the certificate of the issuing certificate authority.

CRL

*Certificate Revocation List provide a means for a Secure Sockets Layer (SSL) endpoint to verify that a certificate received from a remote host is valid and trustworthy.

CVSS score

*Common Vulnerability Scoring System is a published standard that measures vulnerability and calculates a numerical score based on its severity.

CVSS patch management guidelines

  • Critical (9.0 - 10.0)
  • High (7.0 - 8.9)
  • Medium (4.0 - 6.9)
  • Low (0.0 - 3.9)

DMZ

*Demilitarized zone is a physical or logical intermediate network that interacts directly external or non-propriety networks while keeping the host's internal, private network separate and isolated.

EUII

End-user identifiable information.

GDPR

*General Data Protection Regulation is a European Union (EU) privacy and data protection regulation for all EU citizens’ data regardless of where your application site is located.

HSTS

*HTTP Strict Transport Security utilizes a HTTP response header instructing the web browser to only access content over HTTPS. This is designed to protect against downgrade attacks and cookie hijacking.

IEC

*International Electrotechnical Commission.

ISMS

*Information Security Management System.

ISV

Independent Security Vendors are individuals and organizations who develop, market and sell software that runs on third-party software and hardware platforms.

ISO 27001

An information security management system specification framework for all technical controls in an organizations risk management policies and procedures processes.

LFI

Local File Inclusion allows an attacker to include files on a server through the web browser.

NIST

The National Institute of Standards (NIST), a non-regulatory agency of the U.S. Department of Commerce provides guidance for private sector organizations in the US to assess and approve their ability to prevent, detect, and respond to cyber attacks.

Non-Significant changes

  • Minor Bug fixes.
  • Minor performance improvements.
  • Operating systems/libraries/client and server application patches.

OCSP

Online Certificate Status Protocol is used to check the revocation status of X.509 digital certificates.

OII

Organizational identifiable information.

OWASP

Open Web Application Security Project.

PCI DSS

Payment Card Industry Data Security Standard, an organization that maintains standards for the safety of cardholder data worldwide.

Pen testing

Penetration testing is a method of testing a web app by simulating malicious attacks to find security vulnerabilities that an attacker could exploit.

SAML

Security Assertion Markup Language is s an open standard for exchanging authentication and authorization data between the user, the identity provider and the service provider.

Sensitive Data

  • Access control data.
  • Customer content.
  • End-user identity information.
  • Support data.
  • Public personal data.
  • End-user pseudonymous information.

Significant changes

  • Relocation of the hosting environment.
  • Major upgrades to the supporting infrastructure; for example, implementation of a new firewall, major upgrades to front facing services, etc.
  • Addition of capabilities and /or extensions to your app.
  • Updates to your app that capture additional sensitive Data.
  • Changes to your app's data flows or authorization models
  • Addition of API endpoints or API endpoint functions.

SOC 2

Service Organization Control 2, a technical auditing procedure comprised of five Trust Service Principles to ensure that service providers securely manage the data and privacy for an organization's clients.

SSL

Secure Sockets Layer.

TLS

Transport Layer Security.