ArcSight Ideas - TEMPORARILY CLOSED
cancel

Feature Request - Daisy-chain SmartConnectors using SmartMessage

Currently, if an administrator wants to connect a series of SmartConnectors together, eg:

Device --> Local Office SmartConnector  --> Data Centre Aggregating SmartConnector --> ESM

They must use one of:

- CEF TCP (for reliable transport)

- CEF UDP (for simplicity/load balancing)

- CEF UDP Encrypted (encrypted, but not reliable)

- SyslogNG TLS  (encrypted, reliable, but not compressed)

It would be very useful for the upstream SmartConnector to support receiving SmartMessage as a protocol, as sent by the downstream connector. This would then provide a connector-to-connector protocol which is:

- Reliable (failure detection supported)

- Encrypted

- Compressed

- Authenticated

There are lots of reasons for daisy-chaining connectors, such as:

- Aggregating very large numbers of connectors (eg. branch office or agent connectors) down to a number that ESM can handle being directly connected to it

- Aggregating connectors to a point before/after a load balancing architecture, where it is much easier to aggregate the feeds first

- Relaying through aggregators that are needed to simplify firewall rules at different zone boundaries

This request is to add "SmartMessage" as a device type that can be received by a Connector, to the SmartConnector framework

- This would simply be a type of connector selected on installation or configuration, in the same way as "Syslog Daemon" or "ArcSight CEF Syslog"

- It would allow the receiver name (configured on the downstream connector) to be defined, or to accept any receiver name

- It would provide support a means for downstream connector authentication/registration, similar to when registering a connector to ESM, to protect against rogue connectors being associated in order to send spoofed events

4 Comments
Absent Member.

Hi Damian, thank you for bringing this up, this is actual very usefull for two projects I'm working. If required I can specify details to product management for the business case.

Absent Member.

I guess feel free to add them here, Rudi, if you can publish/generalise them

Absent Member.

Need exactly this feature! Any word on if/when it will be made available?

Outstanding Contributor..

I wrote a JIRA for this a while back, I called it a 'relay connector'.

I don't actually see anything unique/special about 'smartmessage', I think that it is all covered by CEF with every intermediate Connector except for the originalAgent being Syslog-ng.

To me smartmessage means Logger Destination, during connector configuration ESM is always referenced as some other ESM encrypted, and in the agent.properties is distinguished https .vs. smartmessage. But both are TCP/SSL aren't they?

I think just moving CEF around on the intermediate (relays) is the way to go and then chose your transport UDP/TCP and if necessary encryption, noting that it seems finally some (CEF?) TCP TLS issues have been addressed in the last 3-6 months. When you get to the 'end' and the Destination is a 'consumer' then you drop out with the appropriate destination formatting.

I probably have missed something in the 'need' that isn't handled above.