4/20/2014

WBEM, what's it to you?

 W eb  B ased  E nterprise  M anagment ( WBEM )

It all about a more secure way of "remotely" pulling the strings and acquiring data from your servers and network devices.

I just got through mentioning [ sfcb ] which is an IBM opensource project to produce a "small footprint cimon broker" or in other words a "light weight CIM repository" for small devices without the massive memory and disk resources of a full fledged server.

Its also the testing ground for a few other initiatives like the [ CMPI ] or "common management programming interface" project. [ CMPI ] is basically a simpler kinder introduction to writing "providers" (otherwise called "agents" in SNMP land) which go fetch and feed information into the CIM "repository" or "database".. lots of terminology "lingo and jargon" here.

So CMPI is in other words a scaffolding or framework for building "providers". A jump start of code to get programmers past the mundane writing of code required to produce an "official" version of a CIM "provider". So they can focus on just their small aspect of a provider for their device or service.

Before the Sblim-sfcb was Tog-Pegasus which was a full fledged operating system WBEM/CIM system and it still exists. But it ran into some issues getting new "providers" written.. these days its benefiting a lot by adopting the providers written to the CMPI from the Sfcb project.

Also, Sfcb is written in plain old "C" code, where as Tog-Pegasus is primarily written in modern "C++" not to be left out there are "Java" CIM projects and Python frameworks for writing "providers".

WBEM is technically a protocol, which handles getting the request from a remote management application or consumer to the provider, via the CIM. It works over http or https ports so its generally firewall "proof" meaning it can slide in under the scrutinity of many compliancy decisions.

Https allows the use of SSL certificates for both authentication and ongoing encryption of the communications after authentication.. or authentication can be a separate affair using many methods common to the protocol or devices.

From this late date in history (April 2014) the adoption of existing SNMP agents and the OID frameworks they use to map data to a MIB structure into the CIM architecture is mostly complete. So if you have existing SNMP agents, they can be mapped into CIM references which can store and forward or directly access the agents in code or via local network queries.

Why would you want to use WBEM? or CIM or WSMAN?

Mostly because SNMP while generally poorly understood and minimally deployed is inherently insecure and is usually only enabled read-only because of the risk of compromise. The terminology gap in common understanding is that community strings are essentially unencrypted passwords flung across the Ethernet or Internet in plain text, and easily sniffed and compromised. Versions 2 and 3 while sometimes deployed are often difficult to comprehend and setup properly, the option to downgrade to 2c and 1 too appealing. For these reasons and others, at least transitioning to SSL "tubing" insulated traffic from prying eyes.. and the authentication was made potentially more secure and no more difficult than setting up peer to peer certificate based authentication... and optionally username/password based.. marginally better than telnet over an open party-line.

NOTE: "minimally deployed" is a relative term based on your perspective. Over a "private" or LAN based network, it can be relatively "widely" deployed as the defacto standard for "private" networks. But the days of "private networks" even being "trusted" let alone "actually secure" are long gone.. and the generic term "network" is more often a WAN.. in which plain text community string "passwords" are easily sniffed and are often left to the default value "public" -- in which case if they are used.. are only trusted with read-only information to smaller and smaller "views" restricting their usefulness.

"Synthetic" VLANs, MPLS, Lambda networks have brought back some feelings of the private LAN security domain, but tend to be "leaky" in that as they mature, security reviews and control often are the last thing thought about when they are extended or merged.. leading to their "leakiness".. hence "Security by Decree" hasn't materialized as a workable concept in most cases. Earnest "waving of hands" and "wishful thinking".. or strategically planning a career move are somewhat more reliable.