Whether or not most ArcSight SIEM customers underutilize their solutions is an excellent question, although the answer may be completely subjective.  As information security consultants, we know that the InfoSec infrastructure has to adhere to Corporate Security Program objectives, which are driven by business priorities and the critical infrastructure, which supports business.  Therefore, an answer to "Is the SIEM implementation leveraged to its full potential?" depends not as much on the incredible SIEM capabilities, but much on what were the original business drivers behind the deployment, or to put it simply, why was the solution procured?  Reviewing the original goals and motivations may provide a direct answer to whether or not your organization's SIEM solution is used to its full intended potential.

Of course, these objectives may not always be clear due to organizational changes or complexity of internal decisions (or, let's face it, politics).  So let us take a look at the most common scenarios which we have seen to drive customers to invest into enterprise-grade SIEM solutions, such as ArcSight in particular.

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).