From The Inbox 2

lmran writes:

Hi Paul,
Do you know any reason why ArcSight ESM does not support the Cisco MARS? Right now, all my firwalls send the syslog feeds into Cisco MARS and I'm trying to set the Cisco MARS to send thoes raw feeds data to ArcSight local connector but I just found out that ArcSight does not support the Cisco MARS. Thanks in ADV for any info reading this subject.

Starting in 4.x, MARS can forward events to another remote syslog listener. ArcSight has a syslog connector. So you ought to be able to forward events from MARS to ArcSight via syslog assuming MARS doesn't change the format of the log events too much. Even if MARS does mangle the event format, ArcSight will still receive them, but then most or all of the event will be parsed into the CEF Name field and categorization and prioritization won't be accurate.

If you are unable to upgrade your MARS appliance to 4.31 or later (I think that's the rev you need), another option would be to use a syslog-ng server out front. It supports forwarding events by source to other syslog servers. You could use this to send the stuff you want in ESM to ArcSight's syslog Connector and the stuff you want in MARS to MARS.

Or, you could do the environmentally conscious thing and unplug then recycle your MARS appliance. ;-)

From The Inbox

Anonymous writes,

Hi Paul, I am one of those who, as you say, found your blog by googling ArcSight, trying to do some recon on the product for my employer. (I think I see that the most recent posts here are from 2007 so who knows if you or anybody will be seeing my question.) I'm trying to find out, can Arcsight's data be queried programmatically; i.e. is it stored in a relational database, hopefully SQL Server or Oracle, or if not, is there an API or ADO.NET provider that can allow it to be queried, preferably with SQL? Thanks for any info anyone reading can provide.

ArcSight ESM uses Oracle 10g for its back-end database. At one point, and this may still be true, DB2 was also supported. You can query the database directly, and the schema is pretty straightforward. The table ARC_EVENT_DATA is where most of the event data lives, for example. But depending on your use case, that might not be the best way to get data out of ESM.

Also, since you didn't specify, it may be worth mentioning that the same is not true of the ArcSight Logger platform, which is flat storage. Instead of querying the log store directly, Logger can be configured to forward events based on source, type, etc. to another destination, if you need them in real-time. There is a PostegreSQL database on Logger, but it's my understanding that it supports the reports engine, and doesn't store the raw or CEF events in any comprehensive way.

The interesting thing is that the storage technology behind Logger 3.0, because of its performance and relative "cheapness" may become the data store for ESM down the road. It would only make sense, since you could handle MUCH higher event rates with less disk and no Oracle license fee. If it can be done while maintaining the stability and feature set that the Oracle-based data store has, it's a walk-off home run for ArcSight.

New Rules

After many months off, I'm jumping back in to the blog with both feet. Mostly in a Howard Beale sort of way. Didja miss me? Anyway, stealing a meme from Bill Maher, I've got something to say to security vendors. Without further ado, New Rules.

If you are a vendor, especially a vendor of security products or services, these are the rules I expect your product to follow. These are common sense, and I feel a little condescending telling them to you. But if recent experience is any indicator, you need to hear them. And you deserve the condescension.

1. Do not store credentials in clear text! Seriously, you can get free libraries to hash credentials or store them in a secure container file that requires a secret key. There's no reason for a password to be in a text file or HKLM Registry key. None.
2. Do not hardcode passwords! If I can't change every single password associated with your product simply and easily, then there should be a law that strips all of your developers of any degree they hold and forces them to go back to college and learn file IO methods.
3. Do not use HTTP/Telnet/FTP/LDAP for authentication! Seriously, more than enough free libraries for SSH, TLS, IPSec exist. Use one. Or buy the one you really like. It beats having to issue a "patch" to sell to government and regulated industry.
4. Don't run as root/SYSTEM/sa/DBA! Your product is not so special that it actually needs administrative privileges to run on the server or database that hosts it. Unless by "special" you mean "coded by lazy fools that don't want to define even the most basic security model." OK, then it is special.
5. Don't use broken crypto algorithms! Sorry, but if you are shipping new product that uses 56-bit DES, RC4, or ROT13, please see rule #3.
6. Don't send passwords in e-mail! Remote password reset is easy enough to do properly, there's no reason to be lazy and just send me my password if I forget it. Also, it means you're breaking rule #1. Busted.
   

There are no excuses for any product to not follow these rules, but especially security/compliance products. Gee, thanks. I just spent six figures on a product to help me manage or achieve compliance, and the product itself can't comply with the regulation I'm trying to address.

The Next Phase

For those of you who haven't given up on my blog (or forgot it was still in your feed list), I want to let you know that I will be back to it later this year. More punditry, more metrics, more SIM, more cool random technical stuff. I'll try anyway. I've been missing it, but I had too much going on, had to prioritize, and this blog has rusted as a result.

A lot has changed since my last blog post in November - a new position at work, a new baby daughter - and the one thing that I've come to realize is that changing is hard work, but if you want it, it's worth it. There's been an excessive amount of talk about change this past year, and on the eve of President Obama's inauguration, I've decided to share with you this story of a moment I had recently.

On November 5th, the day after Election Day 2008, I spoke at the SecureWorld Expo conference in Detroit. I've been in West Michigan for the past several years, but I used to live and work on the East side of the state. It was a gorgeous Wednesday, clear and unseasonably warm for November. And as I was driving westbound on I-96, into the dusk between me and the sunset, I looked up and found myself in familiar territory - Webberville.

You've probably never heard of Webberville, Michigan. That's OK. It's a rural town on the automotive corridor where in the 1990's, companies got huge tax breaks to buy up farmland and build factories. And in 2001, I had an office in one of those factories. That company (a "Tier One" in industry lingo because we sold directly to car makers), like many automotive suppliers, has since gone out of business. And despite working there only a year, I have some very fond and vivid memories of that job. Perhaps the most vivid, however, is driving that stretch of I-96 between Webberville and Wixom and hearing the radio newscaster describe the second plane hitting the World Trade Center on 9/11.

That day changed everything for Americans. I was living in the Midwest, working in a one-story office that had highway on one side and cows on the other, but for the weeks that followed the attacks, I was afraid. We all were. I recall making that drive to Webberville again a week later while all of the planes were still grounded and thinking to myself, "How long until we recover? Can we recover? What will it take for us to move forward?"

Not get over it. Not forget. But move forward - take the next step as a society, as a culture, as a country.

So back to 11/5/2008, and my drive home from SecureWorld, less than 24 hours after learning that Barack Obama - a young, African-American man - would be our next president. And it was there, on that piece of highway in rural Michigan that I answered my own question. Seven years and two months later, I knew America was moving forward. We were moving forward.

SecureWorld Expo Slides

Earlier this month I gave a talk at SecureWorld Expo Detroit on malware analysis. The goal of the talk was to discuss the state of malware and tools for people who aren't ready to go to town with a debugger. Unfortunately, to put it on SlideShare, I had to replace the cool Camtasia videos with lame screen shots.

Malware Analysis Made Simple

View SlideShare presentation or Upload your own.

SecureWorld Expo Detroit

SecureWorld Expo Detroit is coming up at the beginning of next month. I will be presenting on operationalized malware analysis and response. In this case "operationalized" means, "without a debugger.

Cathy Luders, a friend and colleague that I met through the local ISSA chapter, is also presenting at SecureWorld. On the same day. At the exact same time. Which has me bummed out more than a little because I've not gotten to see her present before. But now that I know she's got a talk in her back pocket, I'll probably ask her to present at an upcoming ISSA meeting. :-)

ArcSight Tools Slide Deck

Wow, I've just been buried, both at work and at home. I promised a sanitized copy of our slides from the ArcSight User Conference and here they are. A month late. Enjoy.