Most event processing systems would be incomplete without the ability to process events in the form of messages.   Messages can be delivered in either a connection-oriented protocol or a connectionless protocol.   Most enterprise-class messaging systems have both.   Many messaging systems have features like guarenteed delivery, which are important to many applications.

On the other hand, you do not have to work with a messaging system or enterprise service bus (ESB) to process events, because the transport layer is independent from the event processing layer, theoretically.  Most enterprise-class event processing system architectures will use a combination of both asynchronous and synchronous messaging. 

To understand event processing I recommend you turn to network management and the practical use of Simple Network Management Protocol (SMNP) for a basic undertanding of event processing.   SNMP uses both synchronous event-based messaging, called polling, and asynchronous messaging, called traps.   Network management systems engineers use a combination of both polling and trapping in all enterprise-class operational NMS.  Optimizing polling and trapping is one of the tasks good NMS engineers do well. The same holds true in most distributed event processing architectures.  

For example, look at the CEP/EP reference architecture on this site.  You will notice that the mechanism for event transport is generic, represented as an event bus, but it does not specify the transport protocol.  If you are receiving raw events and comparing correlated results against a signature in a database, you are using both asynchronous and synchronous messaging.    In theory, you could build an event processing system with only connection-oriented protocols, but this would be an exeception, not the rule.

Event processing is generally associated with messaging because we generally represent event-objects as electronic messages.   In theory, we could call these cyber event-objects anything we want; for example, we could call them “packets.” However, packets are generally associated with the underlying Internet Protocol (IP) layer by network engineers.  

Moving up the stack, we think in terms of a complete message-object, which we generally call “a message.”  This message could be an SNMP event-object, an SMTP event-object (an email message), or an HTML request to a web server, to only name a few.    In fact, the basic unit of work at the application level of a distributed network application is what we call “a message.”  

So, in On Messaging and Events Opher asks, “Is event processing just fancy name to message processing ?”

Events are generally represented in some electronic format.  The event-object must be transported electronically in cyberspace, and the way that it is transported is in what network engineers generally call “a message.”   It make no difference what we call it, really; because whatever we call it, it is still binary data representing information we are interested in, hopefully in a format we can efficiently process.    Enterprise-class event processing systems are designed to work with myriad formats, protocols and transports.   One size does not fit all.

Dear network vendor,

As someone that is forced to configure and implement security on your hardware, I would greatly appreciate stable code and properly functioning features. Unfortunately, I cannot always choose the hardware my customers are using in their infrastructure. However, if you would like for me to recommend they continue purchasing and using it, then the product must demonstrate to me that it is: capable, reliable, predictable and well-documented. If your product is not meeting these requirements, I’m forced to recommend other solutions to your (current) customer.

Stable Code. If I have to spend 2-6 hours per implementation working through your product’s bugs, and then must either spend time on a support call or spend time getting packet captures to prove to you it’s not working, I am not a happy camper because you’re slowing down my progress. Your customer is not happy because they’re paying for that time and I’m not cheap.

Features. Don’t publish in technical documentation that your product, or code can do something, only for me to find out later that it cannot. On-site in the middle of an implementation is not the time to architect Plan B. Let me know before, either through technical docs, white papers, best practices or release notes. I do read those. If you want to bend the truth, do it the marketing fluff, not my technical documents.

Documentation. If your product does do what you say it does, then please do document and explain the concepts and procedures. Examples are good, but explanations are mandatory. A correct CLI reference is always lovely as well. If there are got’chas or tricks, please also document those. Again, white papers or release notes are fine. Having to track down the one security engineer from your company that holds the magic key is not practical, nor scalable. Plus, he may be on vacation during my install, which would make me irate.

Support. If your product is not functioning or performing as expected, do NOT expect your customers to have a current maintenance contract to address a known issue or bug (or an un-known issue or bug for that matter). If they found a bug for you, you should probably give them a maintenance contract for a year… or two. If you don’t let us call support, I will find one of your pre-sales engineers and we will use him or her for post-sales support, which is not what you want them to do. But that’s your problem, not mine.

I believe that sums up the major issues. Specifically, I am interested in security, RADIUS, SSH, SNMP, DHCP and 802.1X functions. Before you add another bell or tweak another whistle, please make what you have works… consistently. That should be first, so it’s my Feature Request #1.

Respectfully,

jj

# # #

The lofty goals: Vendors working together in a very abbreviated timetable to make sure that their solutions 1) worked 2) got fully deployed to support the show network goals and 3) talked to each other so that the sum of the parts added up to much more than the individual solutions.

It’s a heterogeneous world. We see it all the time, and it shows in our products. We talk about being vendor neutral – so whether you’re using Cisco (probably), Juniper, Foundry, Enterasys (and the list goes on), EM7 can provide fault and performance monitoring for all of it. Agents, no agents – we don’t care as long as there’s some way to communicate with each other (XML, SOAP, SNMP, SQL queries, logs, traps, emails…).

Louis will share a post later on a neat, real-world and real-time wireless security solution that took EM7, Enterasys and Aruba together to make happen. Using this, the InteropNet NOC team could literally find network/security offenders even if they were hiding under a desk somewhere on the show floor.

InteropNet – we loved it. We’re probably a bit biased because having everything connected and able to talk to each other is at the heart of what we do. But there was truly a sense of people wanting to help each other out – vendors, show organizers, and of course volunteers – that made InteropNet a great team experience and a lovely microcosm example of how networking should be.

And all this is not even going into Interop’s ILabs – which had some very cool, vendor-agnostic projects around NAC and UCM. Gerard from Cisco (who I met in the casino lounge – hey it’s Vegas) gave me a tour and showed off the Cisco wireless management software.

There’s just a couple of months off and then this process starts again for Interop NY. Will New York be different? Well, for one thing, we won’t be stranded in a desert with too much to drink.

ShareThis

As I have written before, I always laugh when I remember speaking to a potential NAC customer who had recently met with a NAC competitor of ours.  We got around to discussing enforcement options and the customer was hell bent on using SNMP to have his switches enforce access policies.  I explained to him that since he had switches from at least 3 different vendors and different models of switches from each of those vendors, the idea of scripting each of those switches and than updating each of them every time there was a change was a lot of work. He understood that but was willing to put up with the extra work for the added security that SNMP afforded him over 802.1x.  Amazed, I informed him that SNMP is not usually thought of as very secure and that 802.1x while not perfect, had many advantages in terms of security over SNMP.  Than the kicker! The prospect told me I must be mistaken, after all SNMP stood for Secure Networking Management Protocol, didn't it?  When I stopped laughing I asked him where he heard that.  He told me that the NAC vendor he spoke to before me told him that and touted how by using SNMP he was getting the most secure method of NAC.  After all SNMP was designed for security!  Well after some quick Google searching, he quickly found out that the other NAC vendor was feeding him a line and it made me and StillSecure golden in his eyes.

I never forget that story and am reminded of it every time I read about a security hole around SNMP. This week came two reports of SNMP vulnerabilities in DarkReading.  One by Kelly Jackson Higgins details a report that researchers doing a simple SNMP scan over the Internet turned up over 5000 devices that reported back with names, models and even patch levels.  The devices were not off brands either, but Cisco, Apple and Microsoft devices.  This underscores how leaky SNMP can be if you don't lock it down right. 

This report came on the heels of an earlier report by Kelly that researchers had discovered a new attack vector of using SNMP in a persistent XSS attack.  Just another reason to lock down your SNMP capable equipment. By the way, for those of you wondering, SNMP stands for simple networking management protocol.

As I have written before, I always laugh when I remember speaking to a potential NAC customer who had recently met with a NAC competitor of ours.  We got around to discussing enforcement options and the customer was hell bent on using SNMP to have his switches enforce access policies.  I explained to him that since he had switches from at least 3 different vendors and different models of switches from each of those vendors, the idea of scripting each of those switches and than updating each of them every time there was a change was a lot of work. He understood that but was willing to put up with the extra work for the added security that SNMP afforded him over 802.1x.  Amazed, I informed him that SNMP is not usually thought of as very secure and that 802.1x while not perfect, had many advantages in terms of security over SNMP.  Than the kicker! The prospect told me I must be mistaken, after all SNMP stood for Secure Networking Management Protocol, didn't it?  When I stopped laughing I asked him where he heard that.  He told me that the NAC vendor he spoke to before me told him that and touted how by using SNMP he was getting the most secure method of NAC.  After all SNMP was designed for security!  Well after some quick Google searching, he quickly found out that the other NAC vendor was feeding him a line and it made me and StillSecure golden in his eyes.

I never forget that story and am reminded of it every time I read about a security hole around SNMP. This week came two reports of SNMP vulnerabilities in DarkReading.  One by Kelly Jackson Higgins details a report that researchers doing a simple SNMP scan over the Internet turned up over 5000 devices that reported back with names, models and even patch levels.  The devices were not off brands either, but Cisco, Apple and Microsoft devices.  This underscores how leaky SNMP can be if you don't lock it down right. 

This report came on the heels of an earlier report by Kelly that researchers had discovered a new attack vector of using SNMP in a persistent XSS attack.  Just another reason to lock down your SNMP capable equipment. By the way, for those of you wondering, SNMP stands for simple networking management protocol.

There is little that I hate more than  siloed approach to logs. A situation when you have your security team "owning" network IDS logs, network team having firewall and router logs (as well as all SNMP traps) and, say, a sysadmins possessing  (or, rather, ignoring!) the logs from servers and desktop is not only sad, counterproductive, inefficient and wasteful, but also dangerous.

Where does such approach to logs (where they are divided by both technical and political chasms) breaks down most painfully? In case of an incident response, of course. This is where instead of one query across all logs and all log sources (or whatever needed subset of logs or log sources), you'd end up with having run around, beg, connect, wait, swear, wait, download logs, dig in many places at once, wait, grep, suffer with many UIs, swear more - and have a time of your life in general! :-) All of the above instead of connecting to your shiny new log management system and running a few reports, drilldowns and searches across the relevant logs.

Ideally, you'd fight the evil and break down the silo walls by deploying a log management platform across the entire organization and then letting every team that needs logs to get them from the system in a controlled fashion, via the interface or a web API (BTW, LogLogic has a web API to get logs!). Apart from being a trend (e.g. see recent ESG report on that), it will make your IT and security operations that much more efficient - and pleasant!

On the other hand, what is bizarre is that some newer vendors,  who claim to do log management, actually work to propagate, not combat, the siloed approach. For example, selling the tool for $5000 to each of the many separate teams within the organization IMHO must be made illegal :-) as it builds walls, not bridges; digs holes and overall "silo-izes" your operation...