Video Screencast Help
Protect Your POS Environment Against Retail Data Breaches. Learn More.

Read-Only DLP Scanning Accounts?

Created: 13 Nov 2012 • Updated: 21 Nov 2012 | 1 comment

I am curious if anybody has found a creative way to get a DLP Scanning account out to their servers without having to scrip adding permissions file by file. Quick ways to get the DLP Scanning account out would be to make it a domain admin (not preferred for obvious reason), adding to the backup-operators group (not preferred as this has access to power down systems), or to create an account and script to set read-only persmissions on every file (which would cause for this script to have to run on a regular basis for new files generated). 

Has anybody found a clever way to make a "read-only" DLP Scanning accoun and deploy to the servers for agentless scanning?

Comments 1 CommentJump to latest comment

kishorilal1986's picture

Hi,

 

 
A user can only be logged in as one role at a time.You need to log in by specifying the role
 
Username: System Adminstrator\MyUser 
 
If you do not specify a role, then one will be randomly assigned. So, one time this user will be the System Administrator, then next he may be a Security role. 
 
If possible, only create one role per user. A new role can be created that combines the two permissions. However, If you need more than one role, then specify the role when logging in.

If you find that you have exceeded the capacity of the input data field there are two solutions:

1. Create and use multiple roles for the user, or
2. Use different information to make the access conditions.

In the first solution, create multiple roles, each one with a subset of the full data needed to define the Incident Access.  This requires that the user login with the format of <role>\<user>, instead of just his <user> name.  Not providing a <role> in the login results in a random selection of the <role> to be used.  While this is the easiest to implement, it is an added burden to the user to login to the different roles to get the work done.

In the second solution, a different attribute is used to define access to the incidents.  An example is when there are too many department names to fit, use a higher level identifier like geographic region.  When an alternate attribute is not available, it is usually possible to implement a new attribute to use.  While the impact to the user is small, the cost to implement may be large and/or impractical to implement.

There is an enhancement request to allow an "OR" condition between Incident Access conditions.  This would allow several conditions with the same attribute and test conditions to be chained together, just like one condition with a larger input data field.