The red with blue LED scroller is definitely a better look than the previous model. Still no backlit logo, though. :-)
Monday, June 16, 2008
ArcSight Logger Face-plate-lift
Not only did ArcSight deliver on the improved UI and feature set for Logger 2.5, but like any good appliance vendor, they've popped their collar. And by collar I mean front bezel.

The red with blue LED scroller is definitely a better look than the previous model. Still no backlit logo, though. :-)
The red with blue LED scroller is definitely a better look than the previous model. Still no backlit logo, though. :-)
Friday, June 13, 2008
ArcSight's new Logger Apps
ArcSight is releasing the Logger 2.5 software here soon, and along with it new appliances with some interesting variations. You can check out the vitals on the ArcSight website here.
Prior versions of Logger were available in small, large, and SuperSized, where the SuperSized box was the same spec as the large box with artificial limitations removed via license key. So really only two boxes, all self-contained, all CentOS, all MySQL.
Now, there's a whole new batch. It would appear by the naming designations that they are going after PCI compliance heavily with the L3K-PCI, which must have retention policies and capabilities that make it easier to comply with PCI-DSS 5.2. Another model supports SAN-attached storage and Oracle, so you can grow your Logger with SAN instead of NAS. And finally, there are two new L7100 models with 6x750MB drives. If I'm doing my math right, that works out, after compression, to about40TB 36TB of log storage. That's a significant increase over the 15TB 12TB that the large/SuperSized L5K boxes shipped with.
Update: Talked with Ansh at ArcSight today, and aparently the 2.5 software adds columns to the CEF event view. That's a big deal for folks using CEF events in Logger, and may make CEF-only the preferred format for most Logger users. The new software also includes real-time alert views (like Active Channels in ESM), as well as a number of other enhancements to alerts and search filters and more. Current customers can download 2.5 from the software site.
Prior versions of Logger were available in small, large, and SuperSized, where the SuperSized box was the same spec as the large box with artificial limitations removed via license key. So really only two boxes, all self-contained, all CentOS, all MySQL.
Now, there's a whole new batch. It would appear by the naming designations that they are going after PCI compliance heavily with the L3K-PCI, which must have retention policies and capabilities that make it easier to comply with PCI-DSS 5.2. Another model supports SAN-attached storage and Oracle, so you can grow your Logger with SAN instead of NAS. And finally, there are two new L7100 models with 6x750MB drives. If I'm doing my math right, that works out, after compression, to about
Update: Talked with Ansh at ArcSight today, and aparently the 2.5 software adds columns to the CEF event view. That's a big deal for folks using CEF events in Logger, and may make CEF-only the preferred format for most Logger users. The new software also includes real-time alert views (like Active Channels in ESM), as well as a number of other enhancements to alerts and search filters and more. Current customers can download 2.5 from the software site.
DefCon 2008 Quals
The lineup for this year's DefCon CTF competition has been decided.
And, better still, Doc Brown has once again posted the challenges (with answers) for everyone to try on their own. Brain calisthenics, to be sure. Get your mental leg warmers on and jazzercise kenshoto style.
And, better still, Doc Brown has once again posted the challenges (with answers) for everyone to try on their own. Brain calisthenics, to be sure. Get your mental leg warmers on and jazzercise kenshoto style.
Sunday, June 1, 2008
From My Inbox... (ArcSight Connectors & Logger)
SC left a comment on an earlier post on ArcSight Logger and CEF vs. Raw formats...
There are probably a number of ways to do this, but I've only tested one. In earlier configurations of our syslog infrastructure, there were a couple single points of failure. In order to meet log analysis commitments, we would reload lost syslog data from file.
Start by configuring a 'Syslog Pipe' Connector. Since the connector only has to be online with the Manager when you're manually inserting logs from file, you have greater flexibility about where this Connector will live. It lived on my laptop for a while. When you set it up, point to a path that isn't already used for anything else. Then you can simply start the Connector and pipe the raw log file(s) to the named pipe:
# cat oldsyslogs.txt >> /var/spool/my_arcsight_pipe
Depending on how far the date/time stamps of the events in those files are from $Now, ArcSight will probably throw some errors. It will maintain the "End Time" from the raw log events, and apply "Manager Receipt Time" as the time the manager collects the parsed events from the Connector. This will absolutely screw up any correlation rules you wanted these events to be subject to. Sorry, no easy way around that.
Hi Paul,
Do you know if its possible to "insert" logs into the logger or SmartConnector if the logs are on a physical storage, e.g. DVD or external storage?
Thanks.
Kind Regards,
SC
There are probably a number of ways to do this, but I've only tested one. In earlier configurations of our syslog infrastructure, there were a couple single points of failure. In order to meet log analysis commitments, we would reload lost syslog data from file.
Start by configuring a 'Syslog Pipe' Connector. Since the connector only has to be online with the Manager when you're manually inserting logs from file, you have greater flexibility about where this Connector will live. It lived on my laptop for a while. When you set it up, point to a path that isn't already used for anything else. Then you can simply start the Connector and pipe the raw log file(s) to the named pipe:
# cat oldsyslogs.txt >> /var/spool/my_arcsight_pipe
Depending on how far the date/time stamps of the events in those files are from $Now, ArcSight will probably throw some errors. It will maintain the "End Time" from the raw log events, and apply "Manager Receipt Time" as the time the manager collects the parsed events from the Connector. This will absolutely screw up any correlation rules you wanted these events to be subject to. Sorry, no easy way around that.
Friday, May 23, 2008
Game Theory and Mac Malware
Cloudmark's Adam J. O'Donnell wrote a fascinating article which uses game theory to predict the tipping point for mass malware attacks on Mac OS X.
It's very hard to construct a game that can accurately represent an uncontrolled environment like the one that malware and botnets currently exist in - and to his credit, Adam fully acknowledges this. But Adam's article is great for two reasons.
First, I think that his estimate of Mac's needing to break 17% market share before they become worthwhile to malware authors isn't too far off. And second, the game he's constructed is a great model for risk-based analysis of a partially unknown threat environment (which is a fancy way of saying how likely you are to be pwned in the future).
I so often find myself ranting about infosec articles and papers that fail at basic math, let alone reasonable science, that it's nice to see something of this quality hit the trade press. Thanks, Adam.
It's very hard to construct a game that can accurately represent an uncontrolled environment like the one that malware and botnets currently exist in - and to his credit, Adam fully acknowledges this. But Adam's article is great for two reasons.
First, I think that his estimate of Mac's needing to break 17% market share before they become worthwhile to malware authors isn't too far off. And second, the game he's constructed is a great model for risk-based analysis of a partially unknown threat environment (which is a fancy way of saying how likely you are to be pwned in the future).
I so often find myself ranting about infosec articles and papers that fail at basic math, let alone reasonable science, that it's nice to see something of this quality hit the trade press. Thanks, Adam.
Thursday, May 22, 2008
TJX vs. CrYpTiC_MauleR
rsnake reported today that TJX has fired an employee who goes by the handle CrYpTiC_MauleR. He was apparently fired for disparaging remarks he left on a sla.ckers.org message board.
So who is CrYpTiC_MauleR and why should you care? He's some college kid working a retail job at TJ Maxx, and you probably shouldn't. Unless you're TJX, that is. And not for the reasons you might think.
Sure, this kind of thing is bad PR for TJX coming and going. And sure, it's disloyal and immature of an employee to trash his employer to the public, especially when it exposes their security vulnerabilities to self-proclaimed hackers. So you might think that firing this guy is an appropriate response. And maybe it is. But I don't think so.
Now, don't get me wrong, I don't believe for a second that this guy is an actual whistleblower. PCI's not a law, and rsnake isn't a regulatory or law-enforcement agency (that I know of), so what he did doesn't even approach whistleblower status. But his now-public firing is going to have a stifling effect on employees, both retail and corporate. And that is a failure of TJX's security program (one of many if you believe CrYpTiC_MauleR).
The thing is, a company needs to have a method of intaking security concerns from staff, and whatever that looks like needs to be communicated to staff, especially from company leadership, like the loss prevention exec that CrYpTiC_MauleR claims to have spoken to. Firing this kid for airing his concerns to the only people that would listen to him is certainly TJX's perrogative and not at all unexpected, really. But it also points out that the culture that allowed the initial breach to occur in the first place hasn't changed.
I've suggested before that TJX could stand to purge themselves. This only reinforces that opinion. If TJX can't change its overall security culture, it's only a matter of months before they're all over the news again.
So who is CrYpTiC_MauleR and why should you care? He's some college kid working a retail job at TJ Maxx, and you probably shouldn't. Unless you're TJX, that is. And not for the reasons you might think.
Sure, this kind of thing is bad PR for TJX coming and going. And sure, it's disloyal and immature of an employee to trash his employer to the public, especially when it exposes their security vulnerabilities to self-proclaimed hackers. So you might think that firing this guy is an appropriate response. And maybe it is. But I don't think so.
Now, don't get me wrong, I don't believe for a second that this guy is an actual whistleblower. PCI's not a law, and rsnake isn't a regulatory or law-enforcement agency (that I know of), so what he did doesn't even approach whistleblower status. But his now-public firing is going to have a stifling effect on employees, both retail and corporate. And that is a failure of TJX's security program (one of many if you believe CrYpTiC_MauleR).
The thing is, a company needs to have a method of intaking security concerns from staff, and whatever that looks like needs to be communicated to staff, especially from company leadership, like the loss prevention exec that CrYpTiC_MauleR claims to have spoken to. Firing this kid for airing his concerns to the only people that would listen to him is certainly TJX's perrogative and not at all unexpected, really. But it also points out that the culture that allowed the initial breach to occur in the first place hasn't changed.
I've suggested before that TJX could stand to purge themselves. This only reinforces that opinion. If TJX can't change its overall security culture, it's only a matter of months before they're all over the news again.
Saturday, May 17, 2008
List of Malware Analysis Tools
Update: There is an updated version of this list of tools posted to my blog here.
The first step is to build a virtual machine with VMware, VirtualPC, or whatever you prefer. It should be as similar to your corporate image as you can make it, but it should not be on your domain. Also, if you select VMware Server, do not install VMware Tools into the VM. Sure it makes things easier, but it can also make it easy for malware to determine that it's in a VM and prevent it from running. I would also recommend installing your company's AV scanner, but disable real-time scanning by default.
Once you've created your VM, you need add some tools to make analysis possible. Here's the list of stuff in my VM.
Cygwin
- Didier Stevens' SpiderMonkey
- pefile
- Jim Clausing's packerid.py
- My ieget.sh
- Mozilla rhino debugger
GMER
catchme
Mandiant Red Curtain
OSAM Autorun Manager
Mike Lin's Startup Control Panel
HiJackThis / StartupList / ADSSpy
HashCalc
HHD Free Hex Editor
OllyDBG (also: Immunity Debugger)
Plugins:
- AnalyzeThis
- FindCrypt
- Hide Debugger
- OllyDump
- OllyFlow
- OllyDbg PE Dumper
ImportREC
iDEFENSE
- MAP
- SysAnalyzer
- HookExplorer
- SniffHit
- PEiD
SysInternals
- AccessEnum
- autoruns
- Filemon
- procexp
- psexec
- psfile
- psgetsid
- Psinfo
- pskill
- pslist
- psloggedon
- psloglist
- pspasswd
- psservice
- psshutdown
- pssuspend
- Regmon
- RootkitRevealer
- tcpvcon
- Tcpview
Firefox (JavaScript Console mod)
Also, having links to VirusTotal and CWSandbox in your VM is a good idea.
Subscribe to:
Posts (Atom)