SSP Application Policy Recommendation Engine Incorrectly Appends Unrelated Groups in the "Applied To" Field

Products

• VMware vDefend Firewall with Advanced Threat Prevention
• VMware vDefend Firewall

Issue/Introduction

When using the Security Services Platform (SSP) Application policy recommendation , users may experience an issue where the user interface incorrectly appends random or unrelated groups (e.g., a X group object or other default inventory items) to the intended source applications within the "Applied To" field.

 

Environment

SSP 5.0 , 5.1 , 5.1.1

Cause

Engineering has identified this as a UI-to-backend communication bug regarding how empty arrays are processed.

When the "Applied To" scope dialog is opened for a policy recommendation, the UI dispatches parallel queries to the backend to fetch relevant application and tier IDs.

Due to a bug in handling empty tier arrays, the backend interprets one of these parallel requests as completely unfiltered.

Consequently, the backend returns a default list of inventory items - which can be any random group from your environment depending on API pagination and naming - and the UI mistakenly merges this default list into your specifically selected applications.

 

Resolution

A permanent fix for this array-handling bug has been developed and merged by engineering. The correction will be officially included in the upcoming SSP 5.x release.

Workaround / Interim Guidance

Until you are able to upgrade to the patched 5.x release, you can safely continue using the intelligence recommendation by observing the following guidance:

• Standard Publishing: You may proceed with publishing the recommended policies as usual. The extra random groups shown in the dialog are strictly a UI-level merge issue and will not be written into the actual firewall rules upon standard execution.

• Precaution on Rule Modification: To avoid the potential functional impact described above, do not manually update the source or destination fields of a recommended rule before publishing. If modifications to the source/destination are necessary, publish the recommended rule first as-is, and then make the required edits to the established rule afterward to prevent the section's "Applied To" scope from erroneously overriding the rule's scope.