pointer

Monthly Archives: February 2011

3 Ways to Deliver Wireless that Rivals Wired for Performance

Posted on by .

    End users will drive even the most patient network engineer to pull their hair out. No matter how many times you explain to them that wireless and wired are not the same, they just won’t listen. They demand the same performance no matter what, no matter where they are. Unfortunately, unlike your wired infrastructure that was probably carefully planned and built, your wireless network is still evolving and growing organically. While I can’t offer you a magic pill, you can save what hair you have left, by addressing these three often-overlooked issues:

    1. Deploy 11n gear; update mixed 802.11 environments.
    802.11n is not only here – it’s thriving. However, a lot of organizations are still operating in a mixed environment. All new deployments, as well as any replacement projects, which are in place for 802.11, should be with 11n gear. Sounds simple, but can cause a lot of issues if not addressed.

    2. View your network as a whole.
    We used to think of wireless as a completely separate entity or “overlay.” However, if you have a wireless network, you must have a wired network. They do not exist in a vacuum. Granted, network management may be a bit different between the two, but the network must be viewed as a whole, meaning a unified wired/wireless network.

    Wireless networks, especially in enterprises, have often been used as a “fill in” technology to cover specific areas where wired coverage may be difficult or where large numbers of transient connections may be required. Fortunately enterprises have, for the most part, outgrown this deployment mentality in favor of organized wireless deployments with centralized management.

    3. Update your security policy.
    This topic has truly been covered to death! The debate is over; the myths are debunked. Security is a policy, not just a technology, and this policy transcends both the wired and wireless network. For example, authentication can and should take place on the wired network (802.1x), even when users are wireless. The policy must be integrated and consistent, and cover all use cases, whether wired or wireless.

    These challenges are still relevant, even though wireless deployment is nothing new. Keeping your organization on top of its unified networks, including wireless and wired, will only help with evaluating and correcting risk factors later down the road.

      3 Ways to Deliver Wireless that Rivals Wired for Performance

      Posted on by .

        End users will drive even the most patient network engineer to pull their hair out. No matter how many times you explain to them that wireless and wired are not the same, they just won’t listen. They demand the same performance no matter what, no matter where they are. Unfortunately, unlike your wired infrastructure that was probably carefully planned and built, your wireless network is still evolving and growing organically. While I can’t offer you a magic pill, you can save what hair you have left, by addressing these three often-overlooked issues:

        1. Deploy 11n gear; update mixed 802.11 environments.
        802.11n is not only here – it’s thriving. However, a lot of organizations are still operating in a mixed environment. All new deployments, as well as any replacement projects, which are in place for 802.11, should be with 11n gear. Sounds simple, but can cause a lot of issues if not addressed.

        2. View your network as a whole.
        We used to think of wireless as a completely separate entity or “overlay.” However, if you have a wireless network, you must have a wired network. They do not exist in a vacuum. Granted, network management may be a bit different between the two, but the network must be viewed as a whole, meaning a unified wired/wireless network.

        Wireless networks, especially in enterprises, have often been used as a “fill in” technology to cover specific areas where wired coverage may be difficult or where large numbers of transient connections may be required. Fortunately enterprises have, for the most part, outgrown this deployment mentality in favor of organized wireless deployments with centralized management.

        3. Update your security policy.
        This topic has truly been covered to death! The debate is over; the myths are debunked. Security is a policy, not just a technology, and this policy transcends both the wired and wireless network. For example, authentication can and should take place on the wired network (802.1x), even when users are wireless. The policy must be integrated and consistent, and cover all use cases, whether wired or wireless.

        These challenges are still relevant, even though wireless deployment is nothing new. Keeping your organization on top of its unified networks, including wireless and wired, will only help with evaluating and correcting risk factors later down the road.

          How Network Forensics Goes Beyond Security

          Posted on by .

            With the RSA Conference next week, network forensics will be on the minds of many. Network forensics, or post-incident analysis, is the capture, recording, and analysis of network events. Imaging having a time machine that you can use to go back in time and replay network activity – answering what, how, and who questions. What happened? How did it happen? Who was responsible? That’s what Network Forensics makes possible, and the applications in the security area are fairly obvious.

            Typically, network forensics solutions employ simple and complex filters to mine stored data to reveal anomalies along with what caused them and what their impacts were,  including things like the magnitude of a security breach, the entry points, the impact on network performance, etc.

            It’s easy to see why the industry typically associates network forensics with network security. Who doesn’t love a good whodunit? Who can resist a car chase? But to view network forensics as a weapon for combating cyber attacks is to give it short shrift.

            Everyone should view network forensics as a friendly companion or aid. Network forensics is your faithful bloodhound, your handy reading glasses, and more. Here’s why; unless you’re capturing, recording, and analyzing your network on an ongoing basis, you’ll be scrambling when an incident arises. And by incident I don’t just mean an attack.

            Below are three other incidents where network forensics can be extremely helpful:

            1. Pinpointing the source of intermittent performance issues
            On a practical level, here’s where network forensics  tools really come in handy — capturing and isolating intermittent network problems, especially problems that occurred hours or days ago. Traditional “reactive” ad hoc troubleshooting is completely inadequate for dealing with intermittent issues. If the issue is intermittent, by definition you don’t know when it’s going to occur, and odds are you have little else to go on in attempting to reproduce the issue. In a reactive mode you just wait around for it to happen again, and just hope you’re paying attention the next time around. With network forensics, you already have a record of the intermittent event because you’re always capturing all of the traffic on the network segment. Simply use the built-in user interface to scan back in time, and when there’s an indication of problems simply drill into that time period and begin analyzing. The time saved in not having to reproduce the problem is huge! That’s often where most time is spent in troubleshooting problems like intermittent network performance.

            2. Business transaction analysis
            For transactions that take place in clear text like SQL, HTTP requests, FTP, or telnet, network forensics allows the network administrator to create the ultimate audit trail for business transactions. Not just server activity, but entire business transactions enacted by clients and servers, including network timing, which can be critical in analyzing financial transactions. Additionally, with network forensics you can troubleshoot transaction problems that server logs miss.

            3. Monitoring User Activity
            Social networking sites like Facebook and Twitter have been shown to zap productivity in the workplace. As a result, many organizations have user policies that prohibit, or at least curtail such activities. Additionally, policies prohibiting non-work related “bandwidth sucking” download activities (music, videos, games, etc) are common. Lastly, to skirt corporate usage policies, users may attempt to use a proxy server, opening up the network to various malware. Network forensics allows all these “rogue” activities to be monitored, revealing details as to who broke policy, what policy infraction was committed, and at what time it occurred.

            Isn’t it time we expand of our view of network forensics? To learn more about network forensics, check out our Network Forensics 101: Finding the Needle in the Haystack white paper.