Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
This security domain is designed to ensure that any data consumed from Microsoft 365 is adequately protected both in transit and at rest. This domain also ensures that consumers’ (data subjects) privacy concerns are being met by the ISV, in line with GDPR (General Data Protection Regulation) and HIPAA (Health Insurance Portability and Accountability Act of 1996).
Data in Transit
The connectivity requirements of Microsoft 365 developed apps/add-ins necessitate communication over public networks, specifically the internet. Therefore, data in transit must be suitably protected. This section covers the protection of data communications over the Internet.
Control No. 1
HARD FAIL
Provide evidence that:
All TLS Configurations are TLS1.2 or higher as highlighted within the TLS Profile Configuration Requirements.
An inventory of trusted keys and certificates is kept and maintained.
Profile Configuration Requirements
Intent: TLS
The intention of this subpoint is to ensure that Microsoft 365 data being consumed by your organization is transmitted securely. The TLS Profile Configuration is used to define TLS specific requirements that help ensure traffic is secure against man-in-the-middle attacks.
Guidelines: TLS
The easiest way to evidence this is to run the Qualys SSL Server Test tool against ALL web listeners, including any that run on nonstandard ports.
Please remember to tick the “Do not show the results on the boards” option, which stops the URL from being added to the website.
The TLS Profile Configuration Requirements can be demonstrated by providing evidence of individual checks. To provide evidence of specific settings, such as disabling TLS Compression, configuration settings, scripts, and software tools can be utilized.
Example evidence: TLS
The following screenshot shows the results of SSL scan by Qualys for the webappfrontdoor- byendbagh6a0fcav.z01.azurefd.net.
The Protocols section shows that TLS1.2 is the only protocol supported/enabled.
Note: The certification analysts will review the full output of the scan to confirm all requirements of the TLS profile configuration requirements are met. The expectation will be that scans are provided for all end points that are publicly exposed (IP Addresses and URLs) to the backend environment that is in scope. Depending on what evidence has been provided, the analysts may run their own Qualys scan.
Example evidence: TLS
The following screenshot shows the configuration settings for TLS in Azure app service followed by TLS enumeration via PowerShell.
Intent: keys and certificates
The intention of this subpoint is to ensure that a comprehensive inventory of trusted keys and certificates is maintained, which involves identifying various systems, services, and applications that depend on these cryptographic elements.
Guidelines: keys and certificates
The evidence must demonstrate that an inventory of trusted keys and certificates exists and is maintained. Additionally, applicable evidence of the tools used to store the actual keys and certificates can be provided such as Azure key vault, HashiCorp Vault Secrets, Confluence Cloud, etc.
Example evidence: keys and certificates
The following screenshot shows that a key and a certificate inventory is maintained in Confluence Cloud.
The following screenshot shows the approved list of trusted keys and certificates. It includes details such as the certificate, keys, cyphers, and the systems on which they are installed.
The following screenshot is from HashiCorp Vault. The certificates that are outlined and recorded in the inventory list are being stored in this online vault. HashiCorp Vault is an open-source tool for secrets management, encryption as a service, and privileged access management.
The following screenshot is an extract of the actual certificate and the keys stored inside the online vault.
Note: The expectation will be that the storage location of the keys has appropriate access controls in place. If the private key is compromised, someone could spoof the server with a legitimate certificate.
Example evidence: keys and certificates
The next screenshot demonstrates example evidence of certificates stored in Azure KeyVault.
Example evidence: keys and certificates
An inventory of trusted keys and certificates can also be maintained with Microsoft 365 Defender which provides an Inventory feature as shown in the next screenshot.
The next screenshot shows the details of the certificate.
Please note: These examples are not full screen screenshots, you will be required to submit full screen screenshots with any URL, logged in user and the time and date stamp for evidence review. If you are a Linux user this can be done via the command prompt.
Control No. 2
Provide evidence that:
TLS compression is disabled for all public facing services handling web requests to prevent Compression Ratio Info-leak Made Easy (CRIME).
TLS HTTP Strict Transport Security (HSTS) is enabled and configured to minimum age of 180-days across all sites.
Intent: TLS
The CRIME (Compression Ratio Info-leak Made Easy (CVE-2012-4929)) attack is a vulnerability in the compression of the Secure Sockets Layer (SSL)/Transport Layer Security (TLS) protocols. For this reason, industry recommendations are to disable SSL compression.
HTTP Strict Transport Security (HSTS) is a security mechanism designed to protect websites against man-in-the-middle attacks by forcing TLS connections by way of a HTTPS response header field named "Strict-Transport-Security".
Guidelines: TLS
This can be evidenced through the Qualys SSL Labs tool. Example evidence: TLS
The following screenshot shows that SSL/TLS compression is disabled.
The next screenshot shows that HSTS is enabled.
Note: The certification analyst will review the full output to confirm all requirements of the TLS Profile Configuration Requirements are met (Please provide screenshots of the full scan output). Depending on what evidence has been provided, the analysts may run their own Qualys scan.
Other tools that can be used to check that HSTS is enabled are 'HTTP Header Spy', and
securityheaders.com as shown in the examples following. Additional Evidence
Screenshots such as configuration settings of the security headers, specifically HSTS can be provided to further demonstrate the security posture of the public footprint.
The next screenshots show the Azure Front Door configuration and the rule set implemented for rewriting the headers.
The next screenshot shows the security headers scan performed and that all security headers are implemented, not just HSTS.
Note: If Qualys SSL Scanner or Security Headers are used, the expectation will be that the full report is provided for a review.
Data at rest
When data consumed from the Microsoft 365 platform is stored by ISVs, data needs to be suitably protected. This section covers protection requirements of data stored within databases and file stores.
Control No. 3
HARD FAIL
Provide evidence that:
Data at rest is encrypted in line with the encryption profile requirements, using encryption algorithms such as; Advanced Encryption Standard (AES), Blowfish and XChaCha20.
Encryption key sizes of a minimum of 128-bit.
Encryption Profile Requirements
Intent: Some older encryption algorithms are known to contain some cryptographic weaknesses which increases the chances of a threat actor being able to decrypt the data without knowledge of the key. For this reason, the intent of this control is to ensure only industry accepted encryption algorithms are used to protect stored M365 data.
Guidelines: Evidence can be provided by way of screenshots, showing the encryption being employed to protect M365 data within databases and other storage locations. The evidence should demonstrate the encryption configuration is in line with the Encryption Profile Configuration Requirements of the Microsoft 365 Certification.
Example evidence: The next screenshot shows that TDE (Transparent Data Encryption) is enabled on the Contoso database. The second screenshot shows the Microsoft documentation page Transparent data encryption for SQL Database, SQL Managed Instance, and Azure Synapse Analytics showing that AES 256 encryption is used for Azure TDE.
Please Note: In the previous examples full screenshots were not used, however ALL ISV submitted evidence screenshots must be full screenshots showing URL, any logged in user and system time and date.
Example evidence: The following screenshot shows Azure Storage configured with encryption for blobs and files. The next screenshot shows the Microsoft Documentation page Azure Storage encryption for data at rest showing that Azure Storage uses AES-256 for encryption.
Data retention, back-up, and disposal
Where ISVs consume and store Microsoft 365 data, there is the risk of a data compromise should a threat actor compromise the ISV environment. To minimize this risk, organizations should only keep the data they need to deliver services and not data that "may" be of use in the future. Additionally, data should only be kept for as long as is needed to provide the services the data was captured for. Data retention should be defined and communicated with users. Once data exceeds the defined retention period, this must be securely deleted so the data cannot be reconstructed or recovered.
Control No. 4
Provide evidence that:
An approved data retention period is formally established and documented.
Intent: A documented and followed retention policy is important not only to meet some legal obligations, for example data privacy legislation such as, but not limited to, the General Data Protection Regulation (EU GDPR) and the Data Protection Act (UK DPA 2018) but also to limit an organizations risk. By understanding the organizations data requirements and how long data is needed for the business to perform its functions, organizations can ensure that data is properly disposed of once its usefulness expires. By reducing the volumes of data stored, organizations are reducing the amount of data that would be exposed should a data compromise occur. This will limit the overall impact.
Often organizations will store data because it’s nice to have just in case. However, if the organization does not need the data to perform its service or business function, then data should not be stored as this is increasing the organization’s risk unnecessarily.
The objective of this control is to confirm that the organization has formally established and documented an approved data retention period for all relevant types of data. This involves not only specifying the duration for which different types of data will be stored but also outlining the procedures for data deletion or archival post-expiration.
Guidelines: Supply the full data retention policy which clearly details how long data (must cover all data types) should be kept for so the business can perform its business functions. The retention policy should clearly cover all customer data stored within the backend environment of the application being certified.
Example evidence: The next screenshot shows Contoso's data retention policy.
Note: These screenshots show a snapshot of a policy/process document. The expectation is for ISVs to share the actual supporting policy/procedure documentation and not simply provide a screenshot.
Control No. 5
Provide evidence that:
Data is retained only for the defined retention period as discussed in control 4.
Intent: The intent of this control is to simply validate that the defined data retention periods are being met. As already discussed, organizations may have a legal obligation to meet this, but also by keeping data which is necessary and for as long as is necessary helps to reduce the risk to the organization should a data breach occur. This ensures that data is neither retained for an excessively long duration nor prematurely deleted, both of which could pose risks of varying nature—legal, operational, or security- related.
Guidelines: Provide screenshot evidence (or via screenshare) showing that stored data (in all various data locations, including databases, file shares, archives, and backups) does not exceed the defined data retention policy. Examples of acceptable screenshots include:
Database Records with a date field, searched in oldest record order, and/or
File Storage Locations showing timestamps that are within the retention period. Note: Any personal or sensitive customer data should be redacted in the screenshot.
Backup records showing that backup data is retained within the defined retention period and properly deleted after this period.
Example evidence: The following evidence shows a SQL query showing the contents of the database table ordered in ascending order on the ‘DATE_TRANSACTION’ field to show the oldest records within the database. This shows that data is less than two months old which does not exceed the retention period defined.
Note: This is a test database, therefore there is not a lot of historical data within it.
Note: In the previous examples full screenshots were not used, however ALL ISV submitted evidence screenshots must be full screenshots showing URL, any logged in user and system time and date.
Control No. 6
Provide evidence that:
Processes are in place to securely delete data after its retention period.
Intent: The intent of this control is to ensure that the mechanism used to delete data which exceeds the retention period is doing so securely. Deleted data can sometimes be recovered; therefore, the deletion process needs to be robust enough to ensure data cannot be recovered once deleted.
Guidelines: If the deletion process is done programmatically, then provide a screenshot of the script that is used to perform this. If it is executed on a schedule, provide a screenshot showing the schedule. For example, a script to delete files within a file share may be configured as a CRON job, screenshot the CRON job showing the schedule and the script which is executed; and provide the script showing the command used.
Example evidence: This is a simple script which could be used to delete all data records retained based on date -WHERE DateAdd is -30 days which will purge all retained records older than 30 days past the selected data retention date. Please note we will need the script; evidence of the job being run and the results.
Please Note: In the previous examples full screenshots were not used, however ALL ISV submitted evidence screenshots must be full screenshots showing URL, any logged in user and system time and date.
Example evidence: The following screenshot has been taken from the Contoso Data Retention Policy (from Control 4) – This shows the procedures used for data destruction.
Note: This screenshot shows a snapshot of a policy/process document. The expectation is for ISVs to share the actual supporting policy/procedure documentation and not simply provide a screenshot.
Example evidence: In this example a Runbook has been created and a corresponding schedule in Azure to securely delete records that have an end date created from the 30 days after expiry of the data record retention policy. This job is set to run every month on the last day of the month.
The next screenshot shows that the Runbook has been edited to find records and has delete commands not in view like the script.
Note: The full URL and username must be in view for these screenshots and ISVs will be required to show a screenshot of before deletion record count and a screenshot of after deletion record count.
These screenshots are purely examples of the different ways this can be approached.
Control No. 7
Provide evidence that:
An automated backup system is in place and configured to perform backups at scheduled times as per a documented backup procedure.
Backup information is periodically restored to confirm the reliability and integrity of the data as per the documented backup procedure.
Appropriate access controls and protection mechanisms (i.e. immutable backups) are implemented to ensure backups/system snapshots are secured against unauthorized access and to ensure the confidentiality, integrity, and availability of the backup data.
Intent:
The objective of this control is to confirm that the organization has an automated backup system in place, which is configured to execute backups at predetermined times.
Guidelines:
Please provide screenshots of configuration settings from your backup solution showing that backups are being performed at scheduled periods/ intervals of time. If the backup scheduling is done by the solution automatically, this can be supported by providing vendor documentation.
Example evidence:
The following screenshot applies to the Azure Database for MySQL, which is a managed instance. It indicates that a first automated backup has been completed.
The next screenshot is taken after a period has passed shows that further full backups have been made. Backups on flexible servers are snapshot-based where the first snapshot backup is scheduled immediately after a server is created and further snapshot backups are taken once every day.
The next screenshot shows a snapshot of online documentation which outlines the backup frequency and the automated backup capability.
Intent: The aim of this control is to substantiate that backup information is not only generated as per schedule but is also reliable and maintains its integrity over time. To meet this objective, periodic tests will be performed on the backup data.
Guidelines: The evidence to meet this control will be dependent on the organization’s process and procedure for testing backup data. Evidence could be provided showing backups being successfully tested alongside records of historical testing completion.
Example evidence: The following screenshot shows that a backup schedule and restore procedure exists and is maintained and that a backup configuration is defined for all applicable systems including frequency of backups being performed in the Confluence platform.
The next screenshot shows a page of historical records of backup testing for each of the systems applicable. Observe that on the right side of the table JIRA tickets are referenced for each of the tests.
The next four next screenshots show the end-to-end process of restoring the Azure Database for MySQL from a snapshot. Using the ‘Fast Restore’ option we can initiate the restore process of the SQL database.
The following screenshot shows the configuration page where we can customize the restore.
Once the target location, networking, and snapshot from which the database will be restored are selected we can initiate the deployment. Observe that our database instance is now called ‘test’.
After a total of five minutes the SQL database was successfully and fully restored from the backup snapshot as the following shows.
Once the testing was completed, in line with the process a JIRA ticket was created to record the backup testing and details of the restore performed. This ensures that historical data is available for compliance purposes as well as complete records exist for review in the eventuality of an incident or disaster to allow the organization to perform a root cause analysis.
Intent: Leading on from the previous control, access controls should be implemented to limit access to only individual users who are responsible of the backup data. By limiting access, you are limiting the risk of unauthorized changes being carried out and thereby introducing insecure changes. A least privileged approach should be taken to protect the backups.
To properly protect data, organizations need to be aware of what data their environment / systems are consuming and where the data is being stored. Once this is fully understood and documented.
Organizations are then able to not only implement adequate data protection but are also able to consolidate where the data is located to implement protection more effectively. Additionally, when data is consolidated to as few places as possible, it is much easier to implement adequate RBAC (role- based access control) to limit access to as few employees as necessary.
Guidelines: Evidence should be provided from the system/technology used demonstrating the access permissions to the backups and backup solutions with supporting documentation of approved access list.
Example evidence: We can see in the following screenshots presented that access controls are implemented at the database instance to restrict access to only authorized individuals based on job role.
Example evidence:
Azure SQL Database and Azure SQL Managed Instances automated backups are managed by Azure and their integrity is a responsibility of the Azure platform; no user has access to them, and they are encrypted at rest with no possibility of ransomware attacks. They are also replicated to other regions for protection.
Data access management
Data access needs limiting to as few people as required to reduce the chances of data being either maliciously or accidentally compromised. Access to data and encryption keys should be limited to users with a legitimate business need for access to fulfil their job role. A well-documented and well-established process to request access should be implemented. Access to data and encryption keys should follow the least privilege principle.
Control No. 8
Provide evidence that:
A list of users with access to data and/or encryption keys is maintained including the business justification for each person.
This list of users was formally approved based on access privileges required for their job function.
Users are configured with the privileges outlined in the approvals.
Note: A sample of users will be selected to demonstrate points B and C.
Intent:
Organizations should limit access to data and encryption keys to as few employees as possible. The intent of this control is to ensure employee access to data and/or encryption keys are restricted to employees with a clear business need for said access.
Guidelines:
Documentation or screenshots of internal systems which document all employees with access to data and/or encryption keys along with the business justification of why these individuals have access should be provided. This list will be used by the certification analyst to sample users for the next controls.
Example evidence:
The following document shows the documented list of users with access to data and the business justification.
Note: This screenshot shows a policy/process document, the expectation is for ISVs to share the actual supporting policy/procedure documentation.
Intent: The process for granting access to data and/or encryption keys needs to include approval, ensuring that an individual’s access is required for their job function. This ensures that employees without a genuine reason for access, do not get unnecessary access.
Guidelines: Typically, the evidence provided for the previous control can help to support this control. If there is not a formal approval on the supplied documentation, then evidence may consist of a change request being raised and approved for the access within a tool such as, Azure DevOps or Jira.
Example evidence: This set of images shows Jira tickets created and approved for the control (i) to grant or deny access to sensitive data and/or encryption keys. This image is demonstrating that a request has created in Jira to get Sam Daily approval for Encryption Keys on the systems backend environment. This is done as the next step where written authorization has been gained.
This shows that the request to give Sam Daily access has been approved by Jon Smith a person from management. (Please note approval must come from someone with sufficient authority to allow the change request, it cannot be another developer).
The previous shows a workflow in Jira for this process. Note that nothing can be added as Done unless it has been through the approval process which is automated and therefore cannot be bypassed.
The Project board is now showing that approval has been given for Sam Daily's access to encryption keys. The following backlog shows Sam Daily's request approval and the person assigned to do the work.
To meet the requirements of this control you must show all these screenshots or similar/equivalent evidence applicable with an explanation to demonstrate that you have met the control requirement.
Please Note: In the previous examples full screenshots were not used, however ALL ISV submitted evidence screenshots must be full screenshots showing URL, any logged in user and system time and date.
Example evidence: In the next example, admin access and full control permissions have been requested for a user to the production DB. The request has been sent for approval as can be seen on the right of the image and this has been approved as shown on the left.
The next image indicates access has been approved and signed off as done.
Please Note: In the previous examples full screenshots were not used, however ALL ISV submitted evidence screenshots must be full screenshots showing URL, any logged in user and system time and date.