Cisco tool opens telemetry for advanced network, security analytics

Cisco is offering a new tool that it says democratizes the use of key telemetry streams to help customers more effectively populate analytics applications and efficiently run enterprise network management systems.

Telemetry metrics are generated from enterprise resources, such as switches, routers, wireless infrastructure and IoT systems, and used by business and technology applications to monitor trends and help IT respond to threats or react to changing network conditions.

As use of monitoring and analytics programs grows, so does the need to grab advanced, dependable telemetry data to help feed those applications.

Typically, telemetry information is dumped into a proprietary data lake or repository where its use is really limited, said TK Keanini, a distinguished engineer with Cisco’s Security Platform & Response group. That may be acceptable if a company has a single analytical platform, but today’s enterprise customers have 20 or more systems all competing for the telemetry, Keanini said.

“Visibility also becomes an issue as security professionals have to work with an array of different and often proprietary protocols for their tools,” Keanini said. “Simply managing an organization’s telemetry is often a full-time job with complex spreadsheets handed down through several admins.”

Cisco Telemetry Broker, available now, is designed to address those problems by simplifying the consumption of telemetry data by brokering hybrid-cloud data, filtering unneeded data, and transforming data to the customer’s preferred format, Keanini said. The idea is to set up a telemetry infrastructure that works across enterprise siloes and has no ties to proprietary protocols or data, he said. 

Cisco Telemetry Broker includes two pieces of software: a management node that runs on any industry-standard hypervisor, and a broker node that runs on the network or in a location near the resources customers want to glean telemetry data from.

“If you are managing hundreds or thousands of applications and devices that are all sending some form of telemetry – syslog, NetFlow, SNMP, VPCflowlogs, etc. – all you do is point it at a Cisco Telemetry Broker node and you are done. This is likely the last time you will need to touch that configuration, because now all those telemetry streams become programmable,” Keanini said. 

“On the other hand, if you are the manager of an analytical platform, whether SaaS or on-prem, instead of having to ask several hundred exporters to send to you, or worse, having to go beg another analytical platform for a copy of the data stream, you can just go to the Cisco Telemetry Broker and specify which feeds and in what format you require,” Keanini said.

Management of telemetry itself increases in complexity with added network complexity, Keanini wrote in a recent blog introducing the broker.   

“The network is growing quickly, and the demands on security administrators to provide telemetry to tools only grows,” Keanini stated. “Current telemetry and data management options can also become expensive as more sources are added to the network, forcing security teams to make some tough budget choices,” Keanini stated.

Keanini says the new broker has its roots in Lancope’s Stealthwatch UDP-Director, which used network telemetry to detect a wide range of security attacks and replicated UDP traffic to multiple destinations. It was introduced in 2006, and Cisco bought Lancope for $425 million in 2015.

The idea of an open, democratic telemetry broker is a positive development for users, analysts said, but there are concerns.

“Conceptually this is a good idea,” said Tom Nolle, president of consulting firm CIMI Corporation. “The question is whether something that’s essentially a telemetry distributor moves the ball enough to really simplify enterprise monitoring and analysis.  You still end up with the potential for disconnected monitoring applications working on unified sources; is that really better?”

“Overall, though, they don’t seem to be talking about unifying analytics, only making sure that telemetry sources can feed multiple destinations, which implies a perpetuation of separated analytics processes,” Nolle said. “To me, that dog doesn’t hunt for long.”