Document Security and Testing

Learning Objectives

After completing this unit, you’ll be able to:

List the types of tests required before a B2C Commerce storefront implementation goes live.
Explain the difference between performance and load testing.
List the important security measures you need to document.
Explain the security-related actions that a merchant must take.
List planning considerations.

Complete the Technical Specification

Last but not least in the technical specification are the security and test details. How are you going to test the system once it’s implemented? Who is going to test it and when? How are you going to ensure the B2C Commerce storefront implementation is secure when it goes live?

Let’s take a look at how you can answer these questions as you complete the last details of your technical specification.

Testing

Testing comes in many flavors. For an implementation, that means user acceptance testing (UAT), performance testing, and load testing. You must document the approach for each, with the following guidelines.

Three types of testing: UAT, load, and performance

UAT

Once the B2C Commerce project team certifies that the storefront implementation is complete and has passed quality assurance (QA) testing, the site is turned over to the merchant for UAT. B2C Commerce Support provides core test scripts for the merchant to test against on desktop, tablet, and mobile devices. They record all issues and log defects as bugs, which are triaged by a team that includes a B2C Commerce business analyst, technical architect, and technical team lead to eliminate duplicates and tickets deemed not to be a defect (based on the finalized and approved requirements).

UAT defects are reassigned to the developers where the work is corrected, unit tested, and retested by B2C Commerce QA, and finally retested and approved by the merchant.

Document your standard UAT approach.

Load Test

Test to the predicted load, not to capacity. The goal is to see if the system can handle the expected load, not to see at what point it breaks. This means just testing the instance, not the end-to-end timing with the browser loading all assets. No static resources are loaded or processed, meaning there are no images, CSS, or JavaScript. Due to the integration between Cloudflare and B2C Commerce, this is deemed unnecessary, and this test targets the code, customizations, and integrations. Here are some test goals.

Cached pages should load in under 250 milliseconds. Cached pages generally include home, category landing, grid, product details, and static content (for example, the about us page).
Dynamic pages should load in under 3,000 milliseconds. These are the account and checkout pages.
Third-party integrations should be included in load testing. Check real-time integrations to third parties such as payment processors and sales tax providers to ensure they withstand peak loads.

See the Holiday Season Readiness with Salesforce B2C Commerce module, “Plan and Implement Load Testing” unit.

Performance Test

B2C Commerce Support requires that all implementations are load tested to ensure proper performance in the multi-tenant environment. There are some exceptions for smaller clients, but the assumption is that any implementation is tested before launch.

Performance testing will be performed on the completed build at twice the expected capacity to ensure the platform scales as designed.

Document the specific B2C Commerce performance testing requirements.

Security

Trust is the most important Salesforce value. Be sure to document important implementation security measures such as these.

Implement multi-factor authentication (MFA): New code deployment and other WebDav access must use MFA as required by B2C Commerce. The merchant is responsible for implementing this, and it must be in place by launch date following the merchant’s security policies.
Protect sensitive data: The storage, transfer, and encryption of sensitive data (B2C Commerce and customer credit card data) must be tokenized via a third-party payment processor. Card CVV is never processed by B2C Commerce infrastructure. Instead, it is sent directly from the browser to the payment processor. No other method is acceptable per best practices.
Eliminate unnecessary third-party access: Eliminate unnecessary third-party access and privilege escalation. It is standard to complete this by launch date.
Be able to disable non-core integrations: Have the ability to disable non-core integrations, where possible, per recommended guidelines.
Use valid SSL certificates: SSL certificates, the standard storefront certificates required for HTTPS access to a site during checkout, must be signed by a valid signing authority. This process is managed by the technical architect.

Security-Related Actions

Document the following security-related actions; make sure the merchant understands that they are responsible.

External integrations/customizations: For external integrations or customizations built on top of B2C Commerce, the merchant is responsible for ensuring PCI-DSS compliance. For example, for external integration to OMS and other services: Is it over TLS and with appropriate firewall restrictions? Merchants are responsible for the outbound ports they request to be open from B2C Commerce. If these ports aren’t secure, they might affect PCI compliance.
Retaining outbound ports: Customers should review the need for the requested outbound ports to be open every six months and notify B2C Commerce if those ports are no longer required.
Retaining payment data: Merchants are responsible for defining how long they retain payment data. This can be managed in Business Manager by defining the Payment Information Retention.
Secure custom exports: Custom exports are encrypted and treated appropriately.
Vulnerable customizations: Customizations can have security ramifications. The merchant is responsible for ensuring their customizations do not capture credit card or other sensitive information through insecure means. Clear text storage of credit card information (including in log files) is not permitted, and merchants are responsible for complying with this requirement. Vulnerability and penetration testing is done by an external QSA/ASV.
Maintain security logs: It’s important to maintain custom logs specific to merchant security and access control, such as the log framework, error, custom error, security, or other logs. Custom logs and other security logs should be downloaded within 30 days and archived by the customer according to the PCI DSS requirement.

This list is not comprehensive. Merchants should consult with their PCI DSS assessor or consultant to determine all requirements and responsibilities required to maintain PCI DSS Merchant compliance.

See the Salesforce B2C Commerce Storefront Security Strategies module for details.

Disaster Recovery

Create a disaster recovery plan that includes the steps each participant (merchant, Salesforce, or third party) must take to get a site back up and running. Document the code backup process and schedule. A periodic backup of the GIT repositories is important for disaster recovery. In the current configuration, however, the GIT repository doesn’t need a rigorous backup schedule because each clone serves as a backup of the remote.

Two servers, the smaller one failing, the larger one doing great.

Work with the merchant to configure their POD IP addresses. They (or a provider) are responsible for configuring external B2C Commerce IP addresses. They must also configure B2C Commerce outgoing POD IP addresses for PODs in their region to allow for connections to back-end systems in case of a disaster recovery, and not just those belonging to the PODs they are currently associated with.

During a disaster recovery process, the merchant is responsible for updating the dynamic name system (DNS) and notifying third-party services of the new POD IP. They must ensure their integrated systems work on the secondary POD. This secondary POD already exists in a different data center.

B2C Commerce support works with each merchant to verify and resolve networking issues specific to the disaster recovery POD. Support also transfers merchant data and catalogs to the new POD as part of the database and file system replication process. The merchant is responsible for normal data backups.

Time to Recover

There’s no typical time between when a disaster recovery event is first identified and when the secondary POD is running the application. Disasters are complex events with compounding factors, so it’s hard to predict a specific time. Most cases, however, recover in 24 hours, with the target recovery of the core server in 8 hours.

Support might know in less than an hour that a POD won’t be recoverable for a long time because the power or network was inadvertently shut down by construction. In this case, disaster recovery procedures will begin immediately.

When it’s a known issue with a known recovery time, support might wait longer (several hours) before initiating disaster recovery procedures. For example, when it would take longer to move all the realms on the impacted POD to a secondary POD, they typically wait it out.

Who Tests What?

Before releasing the secondary POD realm to the merchant, support runs tests to ensure it’s OK. That means testing the availability of the B2C Commerce service to the production instance on the new POD for all affected merchants. It doesn’t mean rigorously testing each custom solution’s functionality or external integrations and services.

Let’s Wrap It Up

In this unit, you documented the final technical specification test and security details. Earlier in this module, you learned about the technical documentation, the data model, and how to document the architectural landscape. Now you can take the final quiz and earn the badge.