Add Oracle Net / SQL*Net and other database-native protocols as monitored exit points in Content Aware Protection

Products Endpoint Protector Ideas
,
1

What is a one sentence summary of your feature request?

Add Oracle Net / SQL*Net and other database-native protocols as monitored exit points in Content Aware Protection

Please describe your idea in detail. What is your problem, why do you feel this idea is the best solution, etc.

We are working with a customer whose infrastructure consists of 7–8 Oracle Exadata nodes running Oracle Linux 8 in a pure CLI environment (no GUI/X11/Wayland). Their primary data movement occurs via Oracle’s native database protocol Oracle Net / SQL*Net for replication and application-level data transfers between nodes.

Gap 1 — Oracle Net / SQLNet not a CAP exit point
EPP’s CAP module currently does not list Oracle Net / SQLNet as a monitored exit point. Sensitive data transferred between database nodes via this protocol cannot be inspected, blocked, or logged leaving a critical DLP gap in Oracle Database environments.

Gap 2 — No DLP coverage for CLI-only Linux environments
EPP is primarily designed for GUI-based operating systems. This significantly limits EPP’s value proposition in enterprise Linux server environments such as Oracle Exadata, where the primary workload is database operations.

Gap 3 — SCP and rsync are not inspectable
As confirmed by Netwrix support, EPP currently cannot inspect SSH-based transfer tools like SCP and rsync on Linux. These are common data exfiltration vectors in CLI environments and their absence from CAP monitoring further reduces coverage.

Together, these gaps mean that for Oracle Exadata and similar CLI-only Linux server environments, EPP effectively has very limited DLP enforcement capability.

Proposed improvements

  1. Add Oracle Net / SQL*Net as a recognized and monitorable CAP exit point on Linux

  2. Add SCP and rsync as inspectable exit channels in CAP policies for Linux endpoints

  3. Provide a CLI-mode DLP agent for Linux server environments that can enforce policies without requiring a GUI or EPP Notifier

  4. Expand the monitored applications list to include common database-native protocols (MySQL, PostgreSQL, Oracle Net) for Linux server deployments

How do you currently solve the challenges you have by not having this feature?

Currently there is no workaround available within EPP for this use case.
Database-to-database traffic via Oracle Net / SQL*Net is completely unmonitored, and we have had to inform the customer that this channel falls outside EPP’s current scope.

2

Hello Nick,

Thank you for sharing your valuable feedback on Endpoint Protector!

Please note that your request along with all the details will be forwarded for a technical assessment. We will provide you with an update as soon as we have a response. Thank you for your patience.

Kind Regards,
Simona

3

Hi Nick,

I hope your day is going well!

I’m returning with updates on this matter:
Gap 1 — Oracle Net / SQLNet not a CAP exit point
We fully understand the outcome you’re aiming for and appreciate you sharing this improvement idea with us. After reviewing it internally and considering our current roadmap—focused on several high-priority initiatives—we’re unfortunately not in a position to plan or deliver this within this year.

That said, your request is valuable to us. I will make sure it is formally captured and included in our long-term planning backlog. When we revisit this area in the future, we’ll take your input into account and keep you informed of any updates or progress.

Gap 2 — No DLP coverage for CLI-only Linux environments
Here we have a positive feedback as we have possibility to support Linux systems running without a graphical interface, as such we’ve successfully validated this through tests on distributions like Ubuntu and RHEL.

Gap 3 — SCP and rsync are not inspectable
At this time, we’re not able to support SCP and rsync as inspectable exit channels. The main limitation is that SCP connections are encrypted in a way that we currently cannot decrypt, which prevents us from capturing and analyzing these events.
We understand the value of this capability, and your suggestion has been noted. If our capabilities evolve in the future to address this limitation, we will certainly revisit this request and keep you updated.

However, kindly be informed that your improvement suggestions are truly appreciated! We will make sure they are taken into consideration in the future should the opportunity arise.

Please let me know if you have any other question, I would be happy to help and clarify.

Looking forward to hearing from you,
Simona