Sdílet prostřednictvím

Microsoft 365 App Compliance documentation appendix and glossary

  • Článek

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 aren't 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 don't 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 bits, 192 bits, 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 don't 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 don't 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 don't 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 don't 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 don't specifically assess some elements of account management processes, this will require you to:

  • Demonstrate how ✓s are implemented to mitigate replay attacks (for example, MFA, Kerberos).
  • Demonstrate how accounts that haven't 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 don't 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 don't 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 that 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 don't 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 don't 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 don't 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 don't 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 (that is, allowlisting, code signing, etc.).

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

Patch Management – Risk Ranking

As PCI DSS audits don't specifically assess this category, this will require you to:

  • Demonstrate how risk ranking of vulnerabilities is conducted.

Vulnerability Scanning

As PCI DSS audits don't 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 don't 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 don't 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 don't 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 don't specifically assess some elements of account management processes, this will require you to:

  • Demonstrate how the authorization mechanisms are implemented to mitigate replay attacks (for example, 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 don't 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 don't 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 (that is, allowlisting, 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 don't 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 don't 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 that 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 most 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 don't 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 don't specifically assess some elements of account management processes, this will require you to:

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

  • Demonstrate how accounts that haven't 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 don't 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 don't 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 that isn't within the DMZ.

  • Demonstrate that public facing systems are logging to a centralized logging solution that 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 don't 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 don't 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'll 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:

Hosting Types Description
ISV Hosted ISV hosted types can be defined as where you're 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/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/overview/what-is-paas/) With Platform as a Service, you're provisioned with a managed platform presenting a service that can be consumed. You don't need to perform sysadmin functions as the operating system and supporting infrastructure is managed by the CSP. This would typically be used when organizations don't 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 Microsoft 365 stacks. Although the Microsoft 365 Certification will support where apps/add-ons across multiple Microsoft 365 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're hosting the environment within a platform that shared by multiple individual consumers. The Microsoft 365 Certification Specification wasn't written to account for this due to the adoption of cloud, shared hosting isn't 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

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.

FedRAMP

The Federal Risk and Authorization Management Program (FedRAMP) is a U.S. federal government-wide program established in 2011. It provides a standardized approach to security assessment, authorization, and continuous monitoring for cloud products and services.

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 an 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 Commerceprovides 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.