Does ArcMC really require a Syslog Connector to forward Internal events to ESM?

So here is the platform layout

Arc Sight Express 4.0 ---- with Connector , AD Actor Import - and a getting Audit events forwarded from Logger -- All connector send to this destination

Arc Sight Logger 6.0.1  --  top Level peer to Express ----Audit forwarding to Express --- No connectors --  Receivers for all Connectors as a Second Destination added after Express -- Express is the primary Destination on all connectors.

Arc Sight MC 2.0 Patch 2 --- Has a running agent on 3 other MC appliances working on getting 6.0.1 Logger added also ---- 1 Container -- 4 Connectors (Flex Area) --- Audit Forwarding - does not appear it can be set up unless a Syslog connector is added to the current system <-- Why Logger needs no connector to forward but this does -- come on now seriously?

3 MC Appliances 2 -C6504s and 1 C6408M ---all managed by the MC above all on version 2.0 Patch 2 ----

Tell me if this is correct if so HP you need to fix this I should not need to burn a Connector just to forward audit details to Express or ESM

Labels (5)
7 Replies

From the perspective of ESM everything is a connector.  When you configure an ESM destination on Logger you are in fact creating a connector to ESM. 

The difference between creating a destination in Logger and installing the connector in ArcMc is largely semantic. 

However, I agree that if you have limited resources available and needed to use all the local ArcMc containers as efficient and effectively as possible, it is limiting to have to "burn" one on internal events.

So, yes, you have to install a Syslog connector. 

Cadet 2nd Class Cadet 2nd Class
Cadet 2nd Class

I agree with your points, but here is my understanding:

1. ArcMC itself is designed for mornitoring and administration of Software based connectors, connector appliances, loggers and arcmc.

2. You can monitor w.r.t. operations of all these products on arcmc, if user audit on arcmc is your concern then a connector would be required because arcmc does not have a forwarder like loggers and not even required. So the best and last option we are left with is syslog connector.

This isn't something which HP missed


Absent Member.
Absent Member.

Hmm not sure I agree with the logic here By that logic, the only way an application could possibly log is by having an ArcSight *Connector installed (wouldn't that be amazing for HP business) - how does every other piece of software on earth send syslog then? That's like saying that a Cisco router doesn't need to be capable of logging audit information unless you install some software on it because its designed only to route network traffic.

Since when is audit *not* a concern for a SIEM system? Its whole job is to ingest and analyse security events, especially audit information - why it does not provide this by default is beyond me!

Also, ArcMC really doesn't do a good job at its *core* tasks either

Cadet 2nd Class Cadet 2nd Class
Cadet 2nd Class

ArcSight infra audit is not the concern for all the Arcsight users as per my experience except "esm" audit.

Again, For ArcMC Appliance audit there is no need to install syslog on arcmc but it can send syslog to any syslog connector installed in network and the same thing we ask cisco router to do.


The issue here is with this being used as a management and software distribution point, configuration audit, and compliance engine that has no direct feed of its own internal usage to ESM or Express.

As stated originally it can't forward internal events to ESM - unless a Syslog connector is installed on the device.

It should in my opinion be able to forward events (internally) to ESM or Express with out needing a formal collector/connector configured just like Logger.

Since every vendor keeps saying here is your "Single Pane of Glass for MGMT" that's great for MC centric stuff but does nothing for ESM / Express whose core job role and responsibility on my network is to see - parse, correlate, analyze, and alert on everything. These would be high on the list of things I would want to know who accessed it when, where from, how often, and what got changed - especially if it altered say the Backup Configurations or Authentication settings.

I have said this time and again to multiple vendors, in multiple meetings - standardization is the key to uniform, managed, stories of consistent success.

If you have an authentication principle that works and meets multiple regulatory needs and you build a framework of software around the things you sell - Why would you re-invent the wheel and alter the authentication of any one of the various applications -

Example - EXPRESS - can use LDAP or Active Directory - but that same authentication engine is not set up the same as it is for ConApp, Logger, or MC.

Example - Hardware - HP your the kings of NIC teaming you can team as many NICs as you can throw at the server, but can we Team NICs on ConApp, Logger, MC, or Express - nope. I know I have heard they are all appliances - that is a scapegoat it does not make support any easier if the device has 1 NIC enabled or 20 - the important thing is redundancy and recovery for the customer.    ---- Enterasys IDS/IPS uses the embedded tools of the LINUX kernel to team NICs, its an ethtool script <- everyone guess what is on your ConApp, Logger, Express, and MC appliance - ethtool -- so why not make me a command line or gui based advanced set up that would allow the addition of NICs to the devices ---

ConApps and MCs -- suggestion ----

NIC 1 & 2 -  Connectors Inbound (all but say Net Flow, and Syslog) Those last two should probably have there own nic depending on the size of the organization and the diversity of devices monitored.

NIC 3 & 4 -   Outbound to ESM / Logger, MGMT, Backups, etc ..


NIC 1 & 2 -  All inbound receivers

NIC 3 & 4 -  All outbound reports, ESM/Express searches, MGMT, Backups etc.

Better yet - Express --

NIC 1 and 2 - Teamed for all Inbound / outbound event collections and WEB :8443 MGMT

NIC 3 - WEB Console - :9443

NIC 4 - ConApp :6443  -- because yes I got a Connector Appliance with the 4.0 upgrade (1 container / 4 connectors possible)  because I really want to throw more traffic at the 1 NIC that can be used on the system.

I think we all can see that fully supported NIC Teaming would a huge benefit to multiple organizations.


It should in my opinion be able to forward events (internally) to ESM or Express with out needing a formal collector/connector configured just like Logger.

An ESM destination in Logger is a connector...just under the guise of a different name and used in conjunction with a "Forwarder" to specify which events get sent to ESM.


That is true Mary - it is a connector - but it is free and cost nothing -  it does not even show up on the license - it does not take up an available slot for monitoring use -

It is free - every MC appliance should be able to forward events to ESM or Express exactly the same way as Logger - just for the pure and simple Audit requirement and integrity of the platform.

The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.