How to set up an email alert in Splunk for Cisco Ironport ESA logs

[wrickxian]

We have a requirement that when using Ironport DLP feature, when a DLP violation is detected, we want to encrypt the email using PXE If TLS is not available. But we want to send our sender a notification that the email was sent out using PXE (only), out of the box, Ironport cannot send a notification when only using PXE, so we are trying Splunk.

If anyone can help me out here, I would most appreciated it. From the Ironport log, we see the first MID was generated along with the sender, recipient, and subject, however, once Ironport detected DLP violation and couldn't send using TLS, it uses PXE encryption, that creates a new MID based off the first MID. I have a search that will pick up the sender, recipient and date/time, but unable to pickup the Subject.

May 12 16:42:31 10.88.2.126 May 12 16:42:31 syslog_mail: Info: MID 27186129 Subject 'DLP123'
May 12 16:42:32 10.88.2.126 May 12 16:42:32 syslog_mail: Info: MID 27186129 DLP violation
May 12 16:42:32 10.88.2.126 May 12 16:42:32 syslog_mail: Info: MID 27186129 queued for delivery
May 12 16:42:33 10.88.2.126 May 12 16:42:33 syslog_mail: Info: Message finished MID 27186129 done
May 12 16:42:33 10.88.2.126 May 12 16:42:33 syslog_mail: Info: MID 27186131 was generated based on MID 27186129 by PXE encryption filter 'Encryption_and_Notify'
May 12 16:42:33 10.88.2.126 May 12 16:42:33 syslog_mail: Info: MID 27186131 ICID 0 From: 
May 12 16:42:33 10.88.2.126 May 12 16:42:33 syslog_mail: Info: MID 27186131 ICID 0 RID 0 To: 
May 12 16:42:33 10.88.2.126 May 12 16:42:33 syslog_mail: Info: MID 27186131 queued for delivery

However, this would need to be a 2 part search:

1. Find any log with a PXE encryption.
2. Find all logs pertaining to the first MID value specified in the Log.

Any help would be really appreciated it.

thanks
Wrick

[Richfez · Accepted solution]

Two transactions.

your base search here ...
| rex "MID\s+(?<original_MID>\d+)" | rex "MID\s+(?<new_MID>\d+)"
| rex "MID\s+(?<original_MID>\d+)\s+was\s+generated\s+based\s+on\s+MID\s+(?<new_MID>\d+)"
| transaction maxspan=15s original_MID | transaction maxspan=15s new_MID

This extracts all MIDs as "original_MID". Then also extracts them as "new_MID", so all MIDs will have two names. THEN extract the special set of correct new_MID and original_MID. Then transaction on the old ones, then on the new one. YOU WILL NEED to modify the 'maxspan=XX" parameter to be small but big enough to encompass the length of one transaction. I guessed at 15 seconds (thinking it's probably <1 second). Keeping this short lets Splunk stop comparing "older" events and will be key to keeping this efficient.

I ran this on a couple of sets of your examples (Thank you for providing a good sample!) that I just copied and pasted a few times changing some numbers and it seemed to work fine. Obviously, test. 🙂

You could leave off the second transaction to get a better idea how it does what it does.

[wrickxian]

I tried your query, the query didn't return the original_MID events, it only return the new_MID events. my search base are based on transaction internal_message_id, would that make any difference?
here's my whole search query.

index=cisco sourcetype="cisco:esa:textmail"| transaction internal_message_id | search "by PXE encryption filter" | eval Time = strftime(_time, "%I:%M%p on %B %d, %Y")
 | rex "MID\s+(?\d+)" | rex "MID\s+(?\d+)"
 | rex "MID\s+(?\d+)\s+was\s+generated\s+based\s+on\s+MID\s+(?\d+)"
 | transaction maxspan=30s original_MID | transaction maxspan=30s new_MID
 | table sender, recipient,message_subject,Time

thanks.

[wrickxian]

Hi rich7177,

I played around with the query and modified a few things, it is working for me. thank you very much!
my search base..

| rex "MID\s+(?\d+)" | rex "MID\s+(?\d+)"  | rex "MID\s+(?\d+)\s+was\s+generated\s+based\s+on\s+MID\s+(?\d+)" | transaction  maxspan=15s org2_MID | search "by PXE encryption" | transaction maxspan=15s new2_MID 

[Richfez]

You are right, you can't just

your base search | transaction MID | search "by PXE encryption filter"

You have a transitive relationship between an old MID and a new MID, as you mention.

I'm currently looking at perhaps a way to do a few multiple extractions and group in interesting ways to get around what may be a subsearch or join. Subsearch wouldn't be the end of the world. Join is close to it, but if it's what we turn out needing, then that's what we need. Still, I think creative use of stats can take care of this.