pointer

Monthly Archives: August 2012

How Employees can Circumvent Corporate Policies through the Network

Posted on by .

    Every corporation has a different corporate policy when it comes to what applications can be used over the web—what can and cannot be accessed on the company’s network and what websites are deemed work appropriate. For example, many financial firms do not allow mobile phones, personal email and other seemingly innocent activities or devices as they have the potential to be used for fraud, embezzlement or data leakage.

    On the other hand, maybe your work environment is much more laissez-faire with these policies, and browsing the Internet and using your phone at work are not seen as jeopardizing factors.

    Whatever your corporate policy, when it comes to network security to prevent data leakage it is essential that employees adhere by the rules. A recent survey that Cisco commissioned from InsightExpress asked IT personnel about the common mistakes employees make that result in data leakage. The survey found that 70 percent of IT professionals believed the use of unauthorized applications resulted in as many as half of a company’s data loss, while 39 percent of IT professionals said they have dealt with an employee accessing unauthorized parts of the company’s network or facility.

    Even when security policies are in place, whether malicious or not, people still circumvent corporate policies. So, how can you as a network engineer or IT personnel help to create a more secure network to prevent data leakage caused by misuse of policies? Here a few common hot areas that are often circumvented by employees along with some practices and tools you can use to ensure that data stays secure.

    Using Mobile Devices at Work
    Many businesses have deployed Wi-Fi, with the initial intention of supporting IT-issued laptops. The growing trend of BYOD shows that employees are increasingly trying to add their mobile devices, like tablets, to the corporate Wi-Fi. Using mobile devices might be allowed at your office, however it is important to realize that most mobile devices don’t allow for corporate controls. If you allow BYOD on the same network as your corporate-controlled equipment, there is a possible data hygiene violation: untrusted equipment, even if operated by well-intentioned users, is running on your trusted network.

    In addition, if an employee invites a friend over and provides him or her with the Wi-Fi password, you may get rogue mobile devices – untrusted devices with untrusted users -that could affect your overall network. Apart from the obvious danger of an unauthorized user, there are less obvious issues, like malware which could jump to internal devices with the specific goal of giving access to an attacker.

    BYOD requires a balance between easily allowing authorized users to get on the network, plus securely keeping unauthorized users off. A common first step is a dedicated BYOD or guest wireless network, but additional steps include 802.1x or WPA2 Enterprise to perform per-user authentication, or even supplementing passwords with device certificates.

    Given that there are political and technical issues with managing BYOD devices directly, network analyzers are a great choice. The network perspective lets you apply controls to the data that’s carried without requiring device-based agents. Network analyzers also can help you find the rogue users and take you directly to where the source lies at your office to either enforce the mobile policy or to kick the user off the network.

    Accessing Inappropriate Areas of the Web
    The challenge of enforcing corporate standards in accessing the Web is also well-served by a network-based solution. Network-level controls can be device-agnostic and comprehensive, since they focus on what data is delivered rather than what the user is doing.

    The “classic” method is using a network proxy. Proxy support is built-in for every major browser and OS, including automatic proxy detection. It is also possible to set up a transparent proxy, which requires no browser or OS support. The upside with a proxy is that it gives you as an administrator a great deal of control, as well as some bandwidth reduction due to local caching. The downside with a proxy is that it may not be fast enough to keep up with the demand for traffic, causing unhappy users.

    Another method is web filtering on a Deep Packet Inspection (DPI) hardware device, like a firewall. The DPI box can observe and intercept the web requests, much like a transparent proxy. The upside with DPI hardware is that there should not be a speed impact – your mileage may vary – and the downside is a combination of cost and control. It can be difficult to justify the cost of a DPI appliance just for web filtering, but the feature is becoming more common in enterprise-class firewalls, so you may already have such a device in production, which makes it a no-cost solution. The other downside is that web filtering is not generally a primary feature of these devices, so the quality of enforcement set-up and monitoring can vary greatly.

    A method which has gotten more attention lately is cloud-based enforcement. At WildPackets, we use a DNS-based web filtering service. There are also web filtering services which are available as part of “clean pipe” services. These services vary in terms of cost and delivery method, but it should be worth your time to do some initial analysis whether they make sense for your business.

    Users can use a couple of different methods to circumvent web filtering. These methods include proxies, browser-in-browser, and VPNs. Fortunately, all of these are straightforward to detect. Proxies and browser-in-browser may be blocked by your web filtering solution. VPNs should show up either as a VPN or a non-standard protocol, both of which are easy to identify.

    When these user bypass methods aren’t blocked or obvious, they hide as web traffic, either http or https. Here, the key is to find the traffic pattern. Since the bypass works by forwarding all web traffic through a remote server, the user’s computer will only have remote connections to the bypass server, but there will be a lot of traffic from that user to that server! If you find either large flows from a user, or a user connecting only to one external address, those are indications of web filtering bypass.

    Overall Data Leakage Prevention
    When employees circumvent policies, the possibility for data leakage—whether purposeful or not—can arise. To prevent this, new data leakage prevention (DLP) tools are available on the market.

    This technology allows users to inspect network traffic for the purpose of determining whether or not sensitive data is being transmitted in ways that violate corporate policy. It uses deep packet inspection (DPI), and requires both an inline appliance and analysis of both the header and payload information. Often based on keyword rules, DLP systems analyze each packet for rule violations, only saving metadata when violations are detected. DLP systems are far from foolproof, and require detailed knowledge of typical network traffic patterns and constant adjustment to reduce false alarms while keeping data secure.

    If you are considering deploying a DLP solution, consider using a packet analyzer as a test case. Use keyword filters with alerts to test what a DLP system might find, and how much tuning it might take to keep the results relevant. The experience will give you lots of questions to ask a potential DLP vendor, and help you narrow down your choices quickly.

    Adhering to corporate policies as they relate to the network is essential to security. However, employees often violate these policies and fail to understand why such rules are put in place. There are easy steps to find these users and work with them to follow the policies to ensure that data leakage or other security risks do not become a problem for your network.

      Packet Analysis in a Virtual World

      Posted on by .

        As virtual experts head to the mecca of virtualization conferences next week, VMworld, we wanted to talk more in-depth about how monitoring and analysis of the network changes in the virtual world. As more companies virtualize their data center(s), problems can arise because the architecture of virtualization is vastly different than that of the physical environment. While this generates challenges for network monitoring, there are already tools and techniques to conquer the problem, helping to ease the pain of implementation.

        On the surface, virtual networks work in very much the same way as physical networks. Features like promiscuous mode, NIC teaming and load balancing still exist in the virtual work, and switches and network interface cards still exist as virtual switches (vSwitches) and virtual NICs (vNICs).

        Looking deeper, virtual networks have a unique element: vSwitches are typically controlled through the server virtualization tools, meaning that most vSwitches are controlled by server admins rather than network admins . While VMware and others have tried to make vNetworks easy to configure, the reality is that vSwitches have to interface with physical switches. Misconfigurations between the virtual and physical sides are more likely given that the devices are configured by two different teams. These misconfigurations can cause serious problems like network loops, or can remain hidden until exposed by an event like VM migration from one host to another. Hopefully, the network team can work with the server team to implement monitoring before one of these problems occurs.

        Fortunately, the semi-exotic technology of virtual networking does not require equally exotic monitoring tools. All in all the practice of monitoring your network and the tools used to monitor that network have not had to drastically change their architecture. The practice of using a flow-based tool when you are trying to solve a high-level network problem like bottleneck identification is still a great choice, and for the more granular issues, deep-packet analysis is still the best option.

        Similar to a physical network infrastructure, you would use a flow-based or packet-based solution to collect data across multiple points for the infrastructure and then analyze it with a network performance management and monitoring tool. The major difference here is how you gain visibility into the traffic.

        The most common complaint about a vSwitch in network monitoring is that hardware-based monitoring equipment can’t see “inside” the vSwitch. Given the multi-level architecture of modern network applications, the so-called East-West traffic between servers may exist entirely within a single VM host. Fortunately, just like physical switches, vSwitches support port mirroring or spanning. It’s relatively simple to deploy a lightweight VM guest running network monitoring or packet capture software to capture packets by adding a second vNIC connected to a port mirror. The software in the VM guest will capture all traffic across the vSwitch in a manner very familiar to network admins.

        Things appear to get a little more tricky when using a distributed vSwitch, which runs on multiple VM hosts, but acts like a single switch. To capture the traffic between instances of the vSwitch on different VM hosts, remember that the hosts are connected to each other via physical switches, which support port mirroring. This design complication is therefore fairly simple to monitor.

        There is one complication in virtual networks which does not exist in physical networks. Physical switches use custom hardware to forward traffic at line rate, but vSwitches are software in the VM host. Therefore, vSwitches increase the host’s IO load, which may cause complications if the hosted apps are primarily IO bound. With that restriction in mind, the question from a network monitoring perspective is whether to perform real-time analysis or post-capture analysis.

        If you are looking to monitor in real-time, the main item to consider on your monitoring host is capture buffer size, because you are working in a fixed amount of resources on the host for many different guest applications to share. This creates contention among your resources, so it is very important to set a buffer limit for network monitoring that is enough to get the job done without compromising the execution of other applications on the virtual machine.

        It is best to use limited real-time analysis: either monitor with lightweight tools, or use packet capture only when you are facing immediate issues. For ongoing analysis, flow-based solutions are the best choice, as they typically don’t increase the IO requirements. Most of these will rely on the vSwitch to provide a statistical overview of the traffic it’s forwarding. Another alternative is to use a packet capture agent on critical VM guests, especially if that agent doesn’t continually forward the captured packets across the network. When a deeper dive is needed for troubleshooting, either connect to the packet capture agent, or use a packet capture VM guest on the host with a vNIC connected to a mirrored port on the vSwitch. Again, be aware that if the packet capture VM guest forwards the packets off-box, it will increase the IO load on the physical NIC on the host.

        If you are performing post-capture analysis, it is essential that you collect all the packets at the time of the incident that are traversing the network for further analysis. This significantly reduces the need for buffering data in RAM for immediate analysis, but increases the need for disk space based on the overall throughput of the virtual network and the amount of time post-capture analysis that is required.

        Post capture forensics searches are CPU and RAM intensive in a virtual environment, so it is best to perform this type of analysis when virtual machines are at low capacity, or perform the analysis outside the VM realm on a regular PC. Be judicious with the type of searches you perform, as this will save you time and resources.

        Post capture analysis is best for long-term monitoring of vNetworks, just as it is with the physical environment. You never know when a virtual environment might go awry, so continuous capturing is necessary to ensure that you find the right packets. Having the data from the moment of failure will let you diagnose the issue, and not have to tediously reproduce the circumstances or nervously wait for it to happen again.

        Although the virtual environment may be shaking up the rest of the IT world, network administrators have come up with tried-and-true methods for analyzing in the virtual world. Although certain network devices may have switched names, network administrators just have minor adaptation to ensure that they can keep their network up.

          Is Omnipliance Portable Right for You?

          Posted on by .

            We’ve been in the network monitoring and troubleshooting business for over two decades, and we’ve learned some very important things along the way, one being that sometimes you just need to be at the source of the problem. Over the years WildPackets has introduced a wide range of distributed analysis solutions that allow you to monitor and troubleshoot network segments anywhere in the world, but again, sometimes you just need to be there. Whether it’s because the segment in question cannot be remotely monitored – no tools, not Internet accessible, etc – or because the severity of the situation just demands face time, a portable network analysis solution is required.

            When nothing but face time will do, WildPackets offers the Omnipliance Portable. This appliance is an integrated hardware/software solution ideal for performing network analysis of any type, from wireless to 10G. The primary goal of the appliance is portability, as the name implies, but the Omnipliance Portable is capable of much much more.

            In addition to portability, any device you’re going to travel with needs to be rugged, and this is one of the primary design elements of this appliance. It’s built for the road warrior – light enough to carry yet able to stand up to any baggage handler.

            Once the appliance is on site it’s all about the capabilities, and Omnipliance Portable is up to any network analysis and troubleshooting task. Right out of the case the unit is capable of analyzing both wired and wireless networks (simultaneously, if needed), up to 1G segments. If you also need to be prepared for 10G segments, the appliance can support up to two full duplex 10G analysis adapters, making this appliance the only solution you need for any on-site visit.

            Software Options
            Omnipliance Portable has two software options. For strictly portable operation we offer the appliance with OmniPeek Enterprise, our flagship network monitoring and troubleshooting application. OmniPeek Enterprise provides complete control of the device while on site, including advanced features like detailed, per call, VoIP analysis and full 10G performance.

            But what if you require remote access to the appliance, whether from your hotel room in the evening to stay on top of a highly volatile situation, or because you want to leave the appliance on site to monitor a highly sporadic issue? In this case the unit can be configured with OmniEngine Enterprise and OmniPeek Connect, allowing both on-site access as well as remote access to the appliance, 24×7. The analysis capabilities remain the same, including VoIP and 10G, but this configuration offers a bit more flexibility for remote analysis.

            Hardware Options
            From a processing perspective, the appliance comes fully loaded, including dual quad-core Intel Xeon processors, 24G of RAM and 6TB of disk storage. The options come in the form of included network analysis adapters, or OmniAdapters. If your analysis needs never go beyond 1G network segments, our standard OmniAdapter will provide everything you need. But if you have 10G segments in your network, or are planning a transition to 10G in the near future, equipping the Omnipliance Portable with one or even two OmniAdapter 10G cards is the way to go. Fully loaded, you won’t find a more powerful portable solution on the market.

            So, even though it’s the Omnipliance Portable, maybe we should call it the Omnipliance Portable, Rugged, High Performance, Flexible, Scalable? Now doesn’t that just roll off the tongue?

            For more information on Omnipliance Portable, please click here. If you’re interested in seeing if the Omnipliance is a good fit for you, request an evaluation here.