Video Screencast Help

Integrating SEP With ArcSight

Created: 15 Jul 2013 • Updated: 25 Jul 2013 | 5 comments
This issue has been solved. See solution.

Hi Guys,

I'm stepping into a setup in which SEP moves some (not all)  threat-related traffic log data from the SQL Server to the ArcSight Connector device.

The problem is that SEP is apparently *moving* (instead of copying) the data over to ArcSight and, to make matters worse, there are no configuration options set on SEP's "external logging" panel - how is this thing even working in the first place????

Does anyone here know a bit more about the relationship between these two products and how changes can be made? I need to hold onto threat data for at least a week in order to perform initial threat analysis and setting up an ArcSight account to view the data from SEP is incredibly expensive and it just doesn't make sense for us to pay to see the data I'm (apparently) giving away!  ;-)

Thanks for any insight you can bring,


Operating Systems:

Comments 5 CommentsJump to latest comment

ᗺrian's picture

All the data is copied to a file and that file is sent over to the IP of the arcsight logger. Did you set that part up or is nothing configured?

Please click the "Mark as solution" link at bottom left on the post that best answers your question. This will benefit admins looking for a solution to the same problem.

SMLatCST's picture

According to an old old thread, Arcsight uses a direct connection to the SQL server running the SEP DB:

And does not employ the "External Logging" options in SEPM (as the post suggest Arcsight no longer supports syslog from the SEPM).

As this is a direct connection to SQL, it's not something under SEP's control.  You'll need to escalate to HP and ask why the SmartConnector appears to be deleting the logs from the SEP DB on SQL after it's ingested them.

Oh yeah, if you can get Arcsight logging to work via the SEPM's "External Logging" feature instead of the direct SQL connector, then this would likely solve your issue too (as it would be managed by SEP at that point).

mbrabson's picture

Thanks for the info - here's a little more insight:

I did not set up or perform the integration and, so far, I know nothing about it except that the ArcSight team is certain (and we've verified) that the SQL account for the ArcSight Connector has read-only permissions in the database so it cannot be responsible for the deletes.  :(

What I've heard from our ArcSight team is that SEP makes the determination of what entries to send to ArcSight. This seems to be borne out by the fact that only some of the records are missing in SEP.  Does this claim conform to your understanding of the relationship between the two?

SMLatCST's picture

I'm afraid I'm not familiar with Arcsight myself.  My reference for it communicating directly with the SEP DB comes from the earlier linked thread.  I reckon if Arcsight is using a direct connection to the SQL DB, then SEP is unlikely to be controlling what gets sent to it.

There's not much documentation I can find on the subject, so as we don't know how the Arcsight Smart Connector works, I'd suggest switching to using the "External Logging" option in SEPM, and disable the Smart Connector, to verify the behaviour if you let SEPM manage the logging instead.

Alternatively, perhaps a SQL trace would shed more light on the subject?

mbrabson's picture

As it turns out, there is a custom API for ArcSight jointly developed by HP and Symantec.

I have a support call in to Symantec on this issue but I don't expect much - they've already blown me off for much more minor requests for information about my information (in fact, they've stopped communicating with me altogether after I escalated my minor requests to Tier 2).

According to the senior tech (and his "floor manager"), the only support available is for previously documented/published features - nothing outside of the box at all.

Pretty sad (more like abysmal), in my book.  :(

Thanks for all your help - I'll try to tough it out with SQL tracing and the like - if I can find the time.  ;-)