Network configuration errors can prevent your log and event management solution from receiving all of its intended events. It's a common issue, and an easy one to overlook. We review how to locate missing events in ArcSight environments.

There is a certain degree of complexity to every average medium-to-large sized corporate network. Over the years various personnel have been involved in the design and implementation of network management and security equipment, network access controls, cabling.  Although an objective for an event management solution's (such as ArcSight Logger) is to collect log messages from across the enterprise, and most network devices may have been configured to send log messages to SIM/LM, how do we know we're really receiving everything we should?  With ArcSight, we should be able to the discern if all of the intended event traffic is being delivered to Logger or ESM/Express.

In the last part of this post we discussed the methods of extracting logs from OpenVMS systems for processing by ArcSight SmartConnectors.

This installment will focus on transferring these logs to a machine (in our example a Unix-type system like Linux or Solaris) that runs the SmartConnector and processes the delivered log files.

ArcSight supports a wide variety of “legacy” products out of the box, such as large parts of IBM, z/OS and others. ArcSight’s support of these older platforms is lacking in certain areas and may require a fair amount of extra work in order to be integrated properly. I recently discovered this when installing a connector for my favorite “legacy” platform, VMS. This article will focus on how to properly integrate ArcSight with HP’s OpenVMS (don’t tell anyone I called VMS a “legacy” product around comp.os.vms or HECnet though).

There is a multitude of automated sources tweeting out there, aside from bots and spammers.  All those updates broadcasted in real-time by scripts and applications are a goldmine of intelligence information with a lot of potential for security practitioners.