Werner Schmidt
Enterprise Networking and Security Expert

Wireless realities and issues

Wireless is easy to deploy (well there are some exceptions to this), hard to do well. The air is a shared medium. Some of you old schoolers, hikers, mountain bikers understand walkie talkies and we know that RF is a shared medium. “Push to talk” is essential on any medium, but is especially problematic in a more limited spectrum such as wireless. We all know about switches and how superior they are to hubs, but in the air, it’s a hub and not a switch. We begin therefore with less spectrum to squeeze into. While in the US there are 11 channels (channel 12 and 13 existing in other geographies) available in the 802.11b/g 2.4 GHz space, that’s not true. Out of those 11 channels, only three (1, 6 and 11) do not overlap, and of course, not overlapping means then not using channels, 2, 3, 4, 5, 7, 8, 9 and 10. True, things are better in the 802.11a 5 GHz spectrum. 802.11n adds multiple-input multiple-output (MIMO) and 40 MHz bandwidth per channel, but this takes up even more of the 2.4 GHz range. Fortunately 802.11a can also use the 5 GHz frequency, but that assumes the client can use it.

Those iPhone 4s are really cool, they don’t use the 5 GHz range, that makes life really tough. Quoting someone else, that means that iPhone 4 has 802.11n but not the “awesome” 802.11n.

There are lots of tricks different manufacturers use. One professes the advantage of using a single channel across all APs (Access Points); another talks about use adaptive channel management; another talks about beam forming; another about beam steering; still others about techniques for prioritizing traffic. Some use small APs in a larger mesh, others use large UFO looking APs called arrays.

Guests are handled a variety of ways including captive portals and various mechanisms to enable those. Think of a hotel signing-in experience and you get the idea.

Management approaches vary wildly as well. Some use centralized controllers, some use cloud based, some use hive based smart APs, some offer both cloud and controller based. In terms of controlling access to the networks, approaches vary there as well whether it’s a simple physical connection, VLAN based, tunneled back to a controller or the ability to split tunnel. Mesh approaches are used too in order to address connectivity when a LAN wired connection is lost or cannot be made to an AP and a wireless
backhaul needs to be used.

When it comes to prioritizing traffic whether it’s for voice, video or data, different approaches are used there too. At the end of the day, it’s about managing the wireless spectrum and getting a strong predictable signal (with minimal noise and interference) to the client. The best controller is no match for a problematic air space.

So it’s about really understanding what your current air spare and spectrum usage looks like and finding a solution that can work best in your current air space, physical layout, and for the client device connection capabilities and needs that you have. Wireless cannot be magically solved by just deploying technology and neither is it a set and forget approach. It changes due to changing physical environments (think boxes moving in a warehouse, doors opening/closing, etc.), changes in the spectrum (as people and firms in your shared air space add and change their channel usage), evolving standards and client endpoint drivers and capabilities.

I use and offer four different vendor offerings for wireless, each offers a unique solution for certain environments.

SIM, SEM, SIEM, what does it mean?

Before I begin, can I mention my rant for acronyms? Not that long ago, DDI was created. It’s an acronym of acronyms, that stands for DNS, DHCP and IPAM.

Moving on, lets get to the confused field of SIM, SEM, SIEM and others. I’ll start with the purist definitions and then get into what people want and ask for versus what they ought to need. I won’t expand too much on what a log message is. Suffice it to say that it might be a syslog entry, but in fact can come from numerous sources including flat files, various agents, etc.

SIM - Security Information Management
SEM - Security Event Management
SIEM - Security Information and Event Management

Might as well add in here LM which stands for log management. These terms are bantered about by various manufacturers and even research groups like Gartner who haven’t quite come up to speed on how to really differentiate the terms, let alone the solutions, or better yet the requirements and needs. This has led to the problem of trying to find the best ideal solution for an indeterminate problem. Unfortunately, this has led to a lot of misunderstanding and hype around SIEM, a hybrid by definition of SIM and SEM. Like a multifunction copier, scanner and printer, make sure you really need all the functions and that the “blend” is right for you.

Ultimately these solutions are used to deal with various functions or capabilities such as:
Alerting - An automated response or alert to a single message, several messages or correlated event.
Retention - The ability to retain in full or summarized form messages from a period of time ideally related to compliance retention concerns.
Compliance - Ability of the system to create standardized reports for compliance or audit concerns.
Reporting - The ability to create useful reports that go beyond just compliance driven reports.
Normalizing - Taking similar messages from disparate systems and noting how different terms for things like properties are the same. For instance, knowing that bytes sent, sent bytes, traffic sent, etc., are all similar terms.
Correlation - Combining several different events, messages, threats, etc. into a single incident or event

In the classic purest view, LM/SIM solutions collect, store, alert and report on the data. Ideally these systems are tailored for long retention periods. Better solutions tend to be indexed, they usually offer stock reports for compliance, and often times have additional and extensive reports. Due to their nature, they are excellent aggregators and repositories of messaging.

SEM solutions by and large use a rolling shorter window of log messages, normalize it, correlate it and then attempt to do some kind of automated alerting and perhaps trouble ticketing. A SEM solution goes through the reams of log messages trying to find and summarize the most important information. They usually offer stock reports for compliance. Tend to have elaborate messaging and alerting. However, their goal is to process logs with the intent of creating alerts from correlated events.

Therefore, when we look at weaknesses:
SIM - Not ideal for complex alerting and not good for security (aka incident) reporting, trending or dashboards.
SEM - Not ideal for long term collection and storage or detailed searching and reporting.

Since SIM tends to be better at log collections, it can be used to drive or feed SEM solutions. SIEM solutions attempt to do both, but frankly it is a massive task and if the goal is long term retention and detail message logs, almost all of them will fall apart in a one size fits all approach. If you think databases and know how a single SQL search on poor indexing can take down a database, you get the idea. A hybrid system must make sure there is enough horsepower to constantly normalize, correlate and create incidents real time. It’s akin to trying to mix up operational database base needs with longer term data mining, the two are in direct conflict.

This is also a case of needing to walk before running. A good SIEM cannot be built upon a poor foundation of SIM. A strong SIM can feed one or multiple SEM/SIEM solutions. SEM/SIEM solutions require training. They need to be taught about correlation that matters in your environment and just as importantly trained to minimize false positives. SIM is easy to implement and deploy, SEM/SIEM takes time. That’s not to say SEM/SIEM is bad, it can be impossible to deal with reams of information coming from a SIM and most folks do ignore it until they need to deconstruct an incident.

The point is, it’s important to understand where your needs are and what solution or solutions will meet your need. There is some good news here. Mid-market customer can often times buy a single solution that can meet SIM/SEM/SIEM needs. Large enterprises should focus on buying both solutions and using an enterprise SIM to feed one or multiple SEM/SIEM solutions. Mid market customer will probably find our
LogLogic SEM solutions meet their needs. Larger customers will be thrilled with our LogLogic SIM solutions to feed other SEM and compliance solutions including LogLogic SEM. Smaller customers may find that the LogLogic virtual appliance can meet logging needs when less than 40 devices are involved.

It's about web presence

As a technical person, it’s easy to get caught in a trap of just looking at features and benefits and thoroughly missing the point. It seems like that has happened with a lot of firms when it comes to network plumbing and infrastructure. Sure, we talk about active/passive, active/active, dual stack, DR sites, virtualizing, load balancing and the list goes on. However, when you get down to it, it’s all about presence. I often like to say you must be present to win. Whether it’s responding to a phone call, Email or web site, presence is essential.

Load balancing is one of those areas. Yes, I realize the new marketing lingo is layer 7 load balancing, application acceleration and application delivery. However, it’s about the basics, is the web site present?

Lack of presence is harmful and catastrophic. What happens when a bank site is down with a 404 error? Do these customers or prospects come back? Do existing customers start to get concerned? Is an opportunity lost or a reputation? Sure, we can build all sorts of technology to raise availability, but what about adding one more layer to display a message when for whatever reason when things are down hard and the availability layers have failed? We call this a “sorry server” message. Basically it’s the ability to detect a total outage and then create a responder that will display a web page indicating the service is down, management is aware, folks are diligently working on the problem and a please call the following number message appears.

Presence is great. Loss of presence or even responsiveness for a web site is now a Google factor that can affect rankings. That means beyond the outage itself, we can now lose precious rankings that affect future traffic!

Forget about all the stats whether it’s transactions per second, sessions per second or bytes transferred. From a high level view, do you have the ability to maintain presence? It’s easier than it sounds. We offer load balancers that include the ability to offer up a sorry page and provide that last informational message when all else fails, thereby preventing the dreaded 404 error.

Maybe it isn’t even a major infrastructure failure, but rather a human error that lead to a content loss. Perhaps even a hack or defacement issue where presence is available, but not the one you want.

That’s my challenge then, make sure to architect for presence. Use an affordable load balancer like we offer in
Coyote Point from us and use it to maintain presence. I bet you’ll discover some high level management support to maintain presence versus a request to just upgrade infrastructure. Consider us too for how to load balance Microsoft Exchange servers or other applications.