Data Loss Prevention

Hi,

Can anyone tell me if it is possible to integrate Aymantec DLP v11.5 with Quest ChangeAuditor?

Ideally I would be using Data Insight but management would rather use existing products within our estate before shelling out for another server to run Data Insight.

Thanks

Ralph

Not familiar with Quest Change Auditor and what types of data it provides, but if there's an element in there that can be correlated back to a DLP incident, it could likely be done with a custom lookup script or some other batch process. 

Ralph

I do not think this is possible, are you useing it for PCI or HIPPA compliane? I have used it a long time ago for compliance and auditing with real time alerts on changes. I do not believe what you are looking for is possible. Can you eleborate more on what you arelooking to do with this and DLP

Ralph,

I'll echo what was asked here as what you want to really do with it? There are different ways to work with connecting data between DLP and other systems through plugins, lookups, and API's.

• If there is information you need to populate in incidents like Data Insight would, you can likely do this with a custom lookup script.
• If it's something you want to take action, or initiate an outside application when an incident is detected/created, then you can use the plugins.
• For simply pulling data to report on, we have a reporting API available to pull out information into other systems.
• If there is somethign that needs to be modified within DLP incidents, with information that has been recorded in another system, we have a new API avaialbel with the reporting API that can update or make simple changes within the DLP incidents.

Many ways to approach this, but it really depends on what you are tryign to do in particular. More details can definitely help to guide you in the right direction.

Hi ShawnM,

I want to use the data gathered by Quest ChangeAuditor to gauge who is the primary user of a document and therefore populate the "file owner" attribute of an incident.

Currently I have a large amount of documnets that create a match to a rule, these documents have been created from a template or earlier version and therefore the file owner is the originator/creator of the document and not the current owner.

Also, we have a large number of "Builtin\Administrator" as the file owner, again I want to user the data gathered by ChangeAuditor to provide a more accurate file owner for the documents.

Quest ChangeAuditor is due to be implemented here and management would rather see if it is possible to extract this data and populate the file owner rather than shell out for a data insight server.. on that note... does data insight need to be installed on a dedicated server... we currently have an enforce server and two discover servers, could data insight be installed on one of these?

Regards

Ralph

Ralphg,

I see where you are going but this is just thinking out load, the product you actually want is data insight.

It may be doable you would need a report from ITA that can be dumped into a csv that then can be merger on filenames to match... this will only happen if there is a violation will you get this information. To get ths violation I am imagaing some complex plicy statements and this is going to increase the overheard on the server requiring additional resources.

Ralph,

If I understand you correctly, then what you really want to do is improve the efficiency of the "owner" that is listed inside the incident details? Or are you trying to use the file "owner" in the actual policies that you are detecting on?

It sounds to me like ChangeAuditor is a comprable product to what Symantec's Data Insight is. Your description of the problem with File Owner not really being correct, and many times being BuiltIn\Administrator is quite common. This is why we push customers lookign for data at rest to use Data Insight to help provide better context.

To your question, is it possible, yes. Using the lookup plugin, you can approach it in 1 of 2 ways really:

1. Use the CSV lookup as described above, with some sort of (for sake of easy explanation) "daily" digest or report of current file owner information. Essentially this would include information corresponding to the filename, owner, and other ancillary data you may have/want to match up. The lookup would match a variable from the incident (%filename% for example) to match the data, and then load into the custom attribute fields with the (%fileowner% for example) variable from the matching field in the CSV. Very manual process.
2. Another way, would be to use the capability fo the FlexResponse plugin to run a script which can do a number fo different things, including launching some sort of script that can populate the information requested inside the incident in a similar fashion.

The last idea I would suggest, is looking at the new reporting API that has been made available in 11.6 which includes the ability to modify/update information within an incident, with data from another system. While we don't have something built for Quest ChangeAuditor, you may be able to have some sharp internal folks develop it, or even look to the trusted Symantec partners recommended by your Symantec Sales team to see if they might be able to scope out building such a connection.

Lastly, to answer the question about the Data Insight server, it's a yes and a no. While you will need another server for the management/indexing, you don't need it for the collector. The collector can usually be colocated on the Discover detection server. If it is a small architecture, you may be able to get away with a VM running the Indexer and Management server. It would be best to consult with your Symantec team though as every deployment varies.

Hello everyone,

Thanks for all the replies and information, all proved informative and helpfull.

Infact the information provided was going to be used wisely to help promote my case to use Data Insight, but by strange coinidence I have just been informed that we are going with Data Insight as it can feed data to Quest....  real turn of events, which thankfully worked in my favour 100%

Thanks again.

Ralph