4 Replies Latest reply on Aug 16, 2013 6:42 AM by mp63

    Ironport email security syslog


      Wanted to pose a question to anyone with experience in Ironport and SIEM.   I have some log subscription syslogs pointed to one of my ERCs.  We currently have the following coming over.  System Logs, IronPort Text Mail Logs, and Spam Quarantine Logs.  What comes over and parsed doesn't look particularly useful.   Some things such as "subject" don't get parsed at all.    Ultimately, I'd like to be able to create correlations and alarms based on thresholds related to spam and phishing caught by the IronPort.


      To those that understand Ironport logs and how SIEM sees them, what are the most useful log subscriptions to send to SIEM?  And, what have you found most useful in IronPort logs once they get to the SIEM?



        • 1. Re: Ironport email security syslog

          I have the same question. Can somebody please share with us how they successfully integrated Ironport into the SIEM?


          Best regards,


          Scott Weston

          • 2. Re: Ironport email security syslog

            Same question here.


            We have the Text Mail logs coming in at present and apart from looking at broad trends in message types there doesn't seem to be much you can do with them unless you can parse them and put them in a relational database so the original message details can be reconstructed from the stream of individual log messages associated with the procesing.


            Pity because you could build some useful alarms such as:


            • Emails with a particular subject line with some being blocked as spam and others getting delivered.
            • Indicators of targeted attacks such as increase in blocked emails to senior staff


            And many more once you let your imagination go on it.


            If the out of the box parser extracted all the various message IDs reliably you could start doing something but it's very hit and miss with some Events having all the IDs nicely parsed and assigned to Custom Types and others, such as the IronPort Message Subject, not having the IDs parsed at all.





            Edit - I've uploaded some details of the IronPort messages I'm seeing with details of the fields in them. There are a number of IDs in the various messages, I've indicated where these are parsed out and what field they are parsed into, an X in the entry for a particular message indicates that the value is in the packet but not parsed. The list is ordered by frequency of occurence (decreasing), a number of interesting messaqes do not have IDs parsed :-(


            Message was edited by: acommons on 30/07/13 1:41:12 AM
            • 3. Re: Ironport email security syslog

              The IronMail logs are not THE most useful events to bring in, but they are helpful and we do have views set up for them.  The following is what they will get you:


              My issue with it, and I have opened another conversation on it, is the way Nitro counts the events. As Ironmail users know, one message could be touched 50 or so times by various rule filters, and so Nitro is seeing and counting each of these events. So when I search for a message for a given time slice, I see that 300 were sent, but when I drill into the event, there were 10, of which 3 had 100 events,, you get the idea. So I am working on filtering that noise out and getting to a point where I can see message sent message received or actual count of messages sent to domain X

              • 4. Re: Ironport email security syslog

                Thanks for the feedback feeeds.  I did see an update to some IronPort rules that came in around July 24.  Those updates got the MID (Message ID) parsed out of the "recipient" and "sender" rules.  The MID seems to be key in tying in all the events that are related to one email.   With the help of a McAfee architect, we were able to take the "subject" rule and customize some regex to get that MID as well as the subject parsed out also.  All that helped quite a bit.


                I totally agree about the "many events for one email" issue.  It's more of an IronPort issue though.  The SIEM has to deal with what it gets for each packet.  If you have a receiver getting Exchange logs you'll see something similar.  Very many events per email.  But, those are parsed out fairly well.