This week I’m happy to continue our customer guest-blog series with Blake Krone, CCNA Wireless, CCNP Wireless, and CCIE Wireless candidate. You can read more from Blake on his blog, Digital Lifestyle or connect with him via Twitter @blakekrone. Read on for a Cisco Live perspective from a true wireless professional.
Recently 14,000+ technology geeks invaded Las Vegas for Cisco Live! 2011 at Mandalay Bay Convention Center. For me this was my 4th year in a row attending Cisco Live! and the 2nd in a row at Vegas. If you have never attended a Cisco Live! event in person I strongly suggest that you try to budget for it next time around. Not only is this the best week to jump head first into all areas of Cisco’s product portfolio but it is also an opportunity to see how the products can come together to provide connectivity for devices and people.
For every Cisco Live! event that is held Cisco builds their own network to support the conference attendees, sponsors, and speakers. This gives Cisco the opportunity to get a large set of data points regarding their products performance in abusive conditions. Lately we have seen or heard about the BYOD (bring your own device) phenomenon that is sweeping across the enterprise network and there is no better place to see that than a large IT conference.
One can safely assume that for all the 14,000+ in attendance each person will have at least 1 Wi-Fi connected device. Now let’s assume that a large chunk of those in attendance are like me and also have their laptop and a tablet with them, that’s a lot of connected devices to support! Whenever I talk with customers about wireless deployments the first thing I will say when we get to the point of turning on a network is that the client will cause the best wireless network to fail. We always push to make sure that the latest drivers are applied to the devices going to be used to ensure proper roaming and performance. But how do you manage that when you have no control over the devices being used? In the future we’ll use tools like Cisco NCS and ISE, for now we just hope it works!
Each year a considerable part (up to 30% in some cases) of IT budgets is funneled towards device troubleshooting. It is no surprise therefore that after security, maintaining lean operational efficiency is the next most frequent concern regarding enabling a BYOD (Bring Your Own Device) model.
Suppose you have allowed personal devices to connect on your corporate network, and you get a helpdesk call from a disgruntled employee that can’t access certain resources. How would you go about addressing the issue? In this video, Saurabh Bhasin, Product Manager of the Cisco Prime Network Control System (NCS) – a newly launched platform for unified wired and wireless network management – answers the troubleshooting question.
What is CVSS -- (the Common Vulnerability Scoring System)? How can it help me manage risk -- and why is it an important step forward in security research? In this short video Gavin Reid CVSS Program Chair share’s his perspective on the vulnerability scoring standard
Allowing personal devices on the corporate network can make any IT professional cringe. Security is naturally a top concern – and the topic of today’s blog.
One dimension of security is about enabling network access. To do that properly, you would need to design and enforce a mobile device access policy, which may include attributes such as: what the device is, who the user is, where and when access is requested, and the health (posture) of the device. Another dimension of security is about maintaining overall device integrity regardless of the network (corporate or otherwise) it connects to.
In this video we only address the first. Cisco’s solution is based on a newly launched product, the Cisco Identity Services Engine (ISE). Watch the video to learn:
What is the Cisco ISE?
Can I treat corporate devices differently from personal ones?
What about guests in the organization, do I need a separate system?
Sometimes it is interesting to take a look at darknet data and see what you come across. If you are not familiar with the term “darknet,” I am using the definition used by some in the service provider community where a darknet is a set of address space which contains no real hosts. That means no client workstations to initiate conversations with servers on the Internet. It also means no advertised services from those ranges, such as a webserver, a DNS server, or a database server. There is really no reason to see any traffic destined for addresses within those ranges. From a network point of view, it should be as desolate and deserted as the town of Pripyat in the Ukraine, within the evacuation zone due to the Chernobyl disaster back in the 1980s. However, in practice, you do see traffic to those address ranges, which is what makes that traffic somewhat interesting. Traffic destined to those ranges could be the result of malware attempting to locate machines to infect, part of a research project or it could be as simple as a misconfiguration or a typographical error. One example of traffic resulting from a typo would come from attempting to ping a host and typing the wrong address in. However, it would be hard to believe that all of the traffic seen in a darknet is the result of a mistake.
Setting up a darknet does not have to be hard to do. If your organization has address space that is not being used, then all that you need to do is advertise a route for those addresses and leave them unused. In our case, we have advertised several ranges and we collect Netflow data for the traffic destined to them from a nearby Cisco router. That Netflow data is exported to a collector, such as nfcapd, where it is aggregated for further analysis.