This was a question I had in a recent meeting with a large Fortune 100 company. They were traditionally a strong Check Point customer, but a shift in upper management forced them to take on 50+ Cisco ASAs. This was really unfortunate because their team’s Check Point knowledge was very strong and their experience with the ASAs for the next few years was anything but positive.

If you have worked with the ASAs you aware of some of the serious limitations. One of the big ones being the abysmal logging (or lack of) that the ASA tries to provide. For starters, when you load up the highly limited ASDM Java interface to administrate the ASA, you quickly realize that by default you can only view log events that have occurred since you launched ASDM. Need to troubleshoot an event that happened 10 minutes ago? Too bad. You need to keep the resource sucking ASDM open on your desktop and hope that you will see it before it scrolls by.

Once you realize this limitation, the lousy reseller that sold you this garbage will swoop in for another sale: Cisco MARS. This product is supposed to allow you to collect Syslog information. CS-MARS used to be a small company called Protego. Cisco acquired them back in 2004, which also happens to be when the product had its most active development.

Fast forward four years and you have pretty much the same product, which is notoriously difficult to setup and maintain. It has a lousy Java interface that is sloooow. CS-MARS has also had a questionable history when being used in a security function. But what was Cisco to do? They needed something that could function as a repository for all of the syslog traffic the ASAs kick out…unencrypted, with no authentication. How well will that fly in an audit? How can you possible demonstrate that your logs have not been tampered with, or are even accurate without strong encryption and authentication? Ahem…

Now going back to the customer that I am working with, we are now looking at several options. The first and easiest is to activate the Syslog function on the CMA, CLM, or SmartCenter object. This is done by simply checking a box. No special appliances needed, no special licenses, just check a box. This will allow you to then forward syslog events (unfortunately in the “clear”…hello Cisco?) to a CMA, CLM, or SmartCenter Server. These logs can then be viewed in SmartView Tracker which everyone knows is by far the best logging tool out there.

The next step will be a proof of concept with Eventia Analyzer to collect the logs, and correlate them against logs from other devices, and other security domains. On March 18th, there was an update released by Check Point to support ASA message IDs. Eventia Analyzer will allow the customer to watch for events being generated by the ASAs, and then tie them into a true Unified Security Architecure.

That is the solution for the next 18 months…which happens to be how much time is left until the ASAs are end of support, and can be replaced by UTM-1s.

Can I view my ASA logs in Tracker?

8 thoughts on “Can I view my ASA logs in Tracker?

  • May 7, 2008 at 12:54 pm
    Permalink

    Hey missed your posts over the past few weeks. Glad to see you are back it.

  • May 8, 2008 at 2:57 pm
    Permalink

    Can I send all syslog info to my Smart Center or just from the ASA? From routers and switches? How about unix or windoes boxes?

  • May 10, 2008 at 1:37 pm
    Permalink

    You don’t need MARS, any syslog server will do. Additionally running log traffic OOB or through a vpn tunnel would be satisfactory in most cases. At least as satisfactory as any undocumented proprietary encryption.

  • May 10, 2008 at 1:56 pm
    Permalink

    Snowpeak – Yes you can point anything that speaks “syslog” to a SmartCenter Server or P1 environment. For Windows there is a good client called “Snare”

    http://www.intersectalliance.com/projects/SnareWindows/

    UNIX and Linux syslog is well documented, and Cisco has plenty of info on how to configure their equipment to forward syslog info. So you have plenty of options for gathering 3rd party syslog info into your Check Point environment.

  • May 10, 2008 at 2:17 pm
    Permalink

    E.C – “At least as satisfactory as any undocumented proprietary encryption.”

    I don’t believe you are talking about Check Point’s architecture for messaging and alerts when you said the above (hopefully). CP uses SIC (Secure Internal Communications) which is very well documented and uses SSL. SIC along with the rest of the Check Point management architecture has been Common Criteria EAL4 certified since 2006. The documentation is included below. You will notice in the documentation that the TOE (Target of Evaluation) includes the whole Check Point architecture: Management GUI SmartCenter Server Firewall

    http://www.commoncriteriaportal.org/files/epfiles/ST_VID10091-VR.pdf
    http://www.commoncriteriaportal.org/files/epfiles/ST_VID10091-ST.pdf

    This is in stark contrast to Cisco’s TOE which includes an ASA/PIX and Syslog service running on a Windows server.

    http://www.commoncriteriaportal.org/files/epfiles/st_vid6016-vr.pdf

    Which one sounds more secure? An architecure that uses encryption, authentication, and integrity validation for all messaging, logs, alerts, rule changes, etc.

    or

    A firewall that forwards its logs in the clear, using a protocol that does not use encryption, authentication, or integrity as part of the messages. You can put this into into a VPN tunnel, but that still only addresses one out of the three critical components of a secure architecture.

    I would say the vast majority of security professionals will lean heavily towards the Check Point architecture because of its security and simplicity.

  • December 7, 2010 at 5:38 pm
    Permalink

    Dead on, brother! I have been banging my head against ASAs in our enterprise for several years now. My organization took the same route… deploy several ASAs in critical environment… find logging to be terrible… purchase CS-MARS to handle logging… find CS-MARS was never meant to be syslog server. Eventually… finally… company management is realizing ASAs are not as cheap as they appear.

    Don’t forget about Cisco ASA crappy centralized management. Cisco Security Manager is a complete waste. CSM isn’t even compatible with ASDM. If you already started building rules with ASDM, you can’t not reliably import objects and rules into CSM. Often you will be missing netmasks on network objects. ACL rules end-up as jibberish in CSM since ASDM uses auto-grouping to organize rules.

    Anyway… nice post. Wish I had read this and presented this to management two years ago. Not that it would have mattered… but I would have felt better.

  • Pingback: fireverse.org » Blog Archive » ASA Logs in SmartView Tracker Redux

  • December 4, 2012 at 5:23 pm
    Permalink

    I nearly wet my pants reading this. too funny and accurate.

Leave a Reply

Your email address will not be published. Required fields are marked *