Forcepoint DLP

Our overall experience with Forcepoint Data Loss Prevention has been mixed, and I would like to start with the challenges related to the agent. Compared to other solutions we have used, Forcepoint agents are updated very frequently - almost every 1-2 months. It is difficult to rely on a stable agent version, as new issues often arise and are later fixed through patches and new agent releases. One of the biggest challenges this creates is in agent deployment. Unlike other solutions that support seamless in-place upgrades on endpoints, Forcepoint requires us to redeploy agents using additional tools, which is not user-friendly. Another limitation is the lack of real-time visibility into agent status. In other systems, it is easy to see whether an endpoint is connected, disconnected, or has lost connection over time. However, in the Forcepoint management console, it is not always possible to clearly determine whether a device is currently active or if an agent has stopped working. We have also experienced issues with version stability. After the release of version 10.4 (following 10.3), several problems were encountered by organizations that upgraded. Versions were withdrawn, fixed, and re-released, but issues persisted, requiring another rollback and update cycle. In our opinion, such releases should undergo more thorough testing before being deployed to production environments, rather than effectively being tested in customer environments. Additionally, macOS agents have not always performed reliably in our experience. The inline proxy mode, while available, has not proven to be stable. Although it can still capture incidents without browser extensions, it may cause unnecessary browser blocking or create issues when accessing certain websites. Based on our testing, this mode negatively impacts user experience and has not been suitable for our environment. One of the most critical weaknesses is in the Application channel. Forcepoint Data Loss Prevention performs quite poorly in this area, particularly with default Microsoft applications. For example, applications like Link to Windows or apps installed via Microsoft Store (such as WhatsApp or Telegram) are not properly detected for incident generation. The main issue is that Forcepoint relies on identifying applications via .exe files, whereas Microsoft Store applications do not operate in the same way. When we raised a support case, we were advised to block RuntimeBroker.exe for Microsoft Store WhatsApp. However, this process is not specific to a single application - many system components rely on the Runtime Broker. As a result, implementing such a block led to a large number of false positives and user dissatisfaction. Ultimately, we were unable to apply an effective and targeted control for these applications, which we consider to be one of the major limitations of the solution. Another limitation we have encountered is related to file fingerprinting. There is no option to define a custom similarity threshold when detecting matches. The percentage is fixed, and we cannot adjust it to better suit our requirements. Furthermore, when a fingerprint rule is created and applied to the printer channel, it does not function as expected-fingerprinting does not work on the printer channel. We have also observed issues with Pattern and Phrase detection. Even when configuring rules with the "only unique" option enabled, the system treats the same word written in uppercase and lowercase as different entries. This behavior can lead to excessive false positives, especially when specific thresholds are configured.