Video Screencast Help

Seperate Web Gui for DLP

Created: 05 Jul 2012 • Updated: 23 Jul 2012 | 7 comments
This issue has been solved. See solution.

Hi all,

Is it possible to have a seperate web server/web interface that users of DLP can access to view reports, access incidents etc without going directly to the enforce server?

Any advice appreciated.


Comments 7 CommentsJump to latest comment

AMyers6671's picture

By separate GUI I presume you mean separate from the main Enforce GUI. There is not a separate interface for accessing those items. However, you can accomplish this by applying the appropriate roles to the individuals you want to have limited access.

If this post has helped you, please vote up or mark as solution to help others looking for the same data.

pete_4u2002's picture

yes, enforcer uses web console . Hence you can access it remotely provided that machine ia able to browse.

Enforce Server Console (https) -- port: TCP/443 (Windows) -- ports: TCP/443, TCP/8443 (Linux)

for ex:

linux https://enforce:8443

windows https://enforce:443

jjesse's picture

There is no "reporting" interface but as mentioned above if you want to restrict access you can through secuirty.

When you create a new role, you can completly lockdown the console and the incident to show only what you owuld like an individual to see.

Also in some of the solution packs there are predefined roles including a reporting role that just has access to run reports.

If you have futher questions let me know

Jonathan Jesse Practice Principal ITS Partners

ShawnM's picture


Might I ask what in particular is the reason you want to have a separate web interface? Many folks here are suggesting, as I would to control user access, but I'm curious if that is the true concern.

Another option is to look into the recent news form Symantec about using IT Analytics. This provides (while not necessarily what you are looking for) a separate system that can actually use the DLP database and incidents to create all different types of reports and advanced queries. This does run on a separate system as well and a different web gui. Again, I would recommend as above that you implement role base access to restrict users from accesing information they should be.

Symantec Corporation | Sr Systems Engineer | CISSP, CCSK, VCP

If a post solves your problem, please flag it as solved.

If you like an item, please give it a thumbs up vote.

ralphg33's picture

Hi everyone,

Thanks for all the advice.

ShawnM - the reason is a security perspective, at the moment DLP is relatively new in our environment and we are looking to create further roles for departments to access and manage their incidents.  A senior security staff member would prefer they did not have access to the enforce server, (probably as the DLP hardware is managed by the IT Security department and they don't want anyone on their kit) even with a restricted account, he would like all ip addresses, server names etc unknown to those that don't need to know, one step further away from the hardware so to speak.


ShawnM's picture


In that case I think the best suggestion is to let the other folks you are working with know that the roles are really good at restricting the users from knowing what's going on. The only added way I can suggest to hide the information from the users, would be to use a DNS entry for a different location for those users to visit. While this may not mask the IP, it will mask the "apparent name" to the users.

If you want to jump into further hiding the information from the users, I might suggest using a load balancer type system or a proxy/jump box to let the users access the system. This will help to simulate another system, while not making it much more difficult to do and withing the given capabilities of our product.

Hope that helps give you some alternative ideas on how to "obfuscate" the system from the users. smiley

Symantec Corporation | Sr Systems Engineer | CISSP, CCSK, VCP

If a post solves your problem, please flag it as solved.

If you like an item, please give it a thumbs up vote.

Thomas Fürling's picture

We have built an alternative GUI using a web service interface with write back capabilities. Use case is to have user in a hierarchy to see only the incidents of their direct reports. Implementing this is not possible with the built-in rRBAC of the product. Main reason is, that you would require a role, comparing the login user with the content of an enriched custom attributes.This is not possible, because there is not variable/function to compare the logged in user with the custom attribute.

The remediation GUI we did, works for thousands of users, checking upon login, wether there are incidents to be processed by them using a group/delegate/owner mechanism (customer specific autorisation is possible). The user then sees only the incidents autorised and can perform certain remediation actions. These actions are then performed using the incidents/flexresponses(almost standard flex responses) and are keeping the incidents up to date.

If you do not need to work with the incidents, you can export the incidents using the report API and work offline with the content. If you want to close/remediate the incidents, there is no way around a write back API.

Be aware that this approach has a high potential to reduce the TCO but also requires a significant intial investment. Depending on the real use case, there are fifty shades of grey between the "solve everything with the built in rRBAC" and the full monty Remediation GUI.