It’s no secret that network threats have grown significantly over the past several years – in number, as well as complexity. This growth continues to place an overwhelming burden on IT resources, who have to combat these threats on a daily basis. These guys already have a rough job of just keeping up with the sheer volume and variety of threats … but also making them go through multiple hoops and internal approvals to procure and piece together the solution from different vendors is enough to push a lot of folks over the proverbial edge!
There is a lot of buzz out there right now about Telework Solutions for Government as many agencies are making the transition that so many Corporations have already completed. Personally, I haven’t worked full time in an office since pre-1996 and can’t imagine wasting that much time every day on preparations and commuting for no real purpose other than donuts, coffee and the latest office gossip.
Work is an activity, not a location in today’s professional world with pervasive networking capabilities and the Government is getting on board under the leadership of the current administration.
If you want to get a feel for the progress and momentum around this, check out the public/private partnership at the Telework Exchange site focused on eliminating the Telework Gridlock. Cisco is one of the sponsors of this activity because we see the value, have lived it for better than 15 years, and can offer solutions to help make this a reality for our Government customers. Read More »
In my last post on this topic, I highlighted just how true the words “Work is no longer a place you go, but what you do” really are. We now have the ability to work anytime, anywhere, using any device. As easy as this has made the lives of workers all over the world, it’s made the lives of security administrators immensely difficult. Providing secure access to the corporate network in a borderless world, while still somehow keeping out the bad stuff, has caused traditional security policies to become increasingly difficult to configure, manage, and troubleshoot – the source of inordinate amounts of pain for security administrators.
That’s why Cisco has introduced identity-based firewall security as a new capability of the ASA platform. As the first installation of what will soon become full context-aware security, identity-based firewall security enables security administrators to utilize the plain language names of users and groups in policy definitions. Rather than authoring and managing the growing list of IP addresses to cover every possible location, device, or protocol that may be required for secure access to the network, identity-based firewall security enables security administrators to grant access to “Jeff.” Regardless of where I am or what I’m using for access, I’m still Jeff… so in the simplest case, my administrator can literally write one policy to provide “Jeff” access to the corporate network, rather than six different IP addresses for all the instantiations of Jeff.
The Unified Network Services (UNS) portfolio of Layer 4-7 services (such as ACE and WAAS) also includes Cisco’s data center security solutions. A critical part of that security portfolio is our virtualization-aware firewall solution, Virtual Security Gateway (VSG). In a series of upcoming blog posts, I’ll be sharing a few use case scenarios that our customers are implementing with VSG.
For those of you new to VSG, I’ll point out that VSG’s role is to act as a virtual firewall between zones of virtual machines. Isolating traffic between VM zones has been very challenging prior to VSG because: 1) security policies have to be enforced between VMs running on the same server or same virtual switch (where there’s no place to put a firewall), 2) VMs move all around the network and the security policies (as enforced in the firewall) must follow the VM, and 3) the need to maintain segregation of duties for compliance purposes between the security and application server teams, where security is potentially enforced inside the virtual server.
A few years back I set up IPv6 connectivity on my home network for the first time. I had a rush of exhilaration when the first ping and traceroute commands completed successfully. Suddenly, I was free of Network Address Translation and bypassing my firewall, connecting directly to any IPv6 device on the Internet. But then it slowly dawned on me that those people same people could also directly connect to my device! In a panic, I wondered if my SMB shares were visible to the world, or if criminals could relentlessly probe my open ports for zero-day vulnerabilities. How could I even check if I had any open ports? My fear got the best of me and I disabled IPv6.
I contacted my friend Dan and posed my dilemma to him. How could I tell if my ports were locked down on a machine which ran IPv6? A number of sites provided port scanners for IPv4, but nobody had a general purpose scanner for IPv6. Hurricane Electric provided one, but only for devices that were on their network. Dan hacked up a primitive IPv6 open port testing site, which uses NMAP to scan an IPv6 visitor for typically vulnerable ports before issuing a simple report. I was pleased to discover that my computer did not answer on any of those commonly attacked ports.
In this process, I discovered that many modern operating systems with IPv6 enabled also come with a set of reasonable host firewall defaults which do not expose listening ports as much as I had expected based on my experience with IPv4. Many hosts with IPv6 enabled by default also come with some very sensible settings to prevent network-launched crimes of opportunity from malicious users.
IPv6 also provides a natural defense against classic portscanning attacks, where an attacker probes for commonly vulnerable ports of every IP address on a subnet. For densely packed IPv4 service provider networks with one IP address assigned per typical user, a few thousand probes across a known DSL or cable subnet can yield a rich collection of potential targets. Since the address space of IPv6 is so much larger and sparsely populated than IPv4, blind portscanning of subnets becomes impractical since a typical IPv6 subnet contains quintillions of addresses hosting a relatively small number of end devices.
Despite the sensible security posture of IPv6, a network based firewall provides additional protections by thwarting attacks at the network perimeter, analyzing connection context and allowing greater control of policy and analytics. An IPv6 Quick Start Guide for the Cisco ASA can be found in the World IPv6 Day – IPv6 Transition community at the Cisco Support Forums. Please visit this forum and ask questions. Overcome your fear of running IPv6 and start reaping the benefits of running IPv6 on your own network in time for World IPv6 Day.