Ravi Blogs about IT Topics

I was interviewed by Barbara Fenig from the Argus for an article on Cisco Clean Access. She was very good, came with excellent questions and understood what I told her about a fairly complex technical issue. However, as we all know, when the article gets written, due to space and other constraints, not all details about a topic like this will find its way in. So, I thought I can talk about this in little more detail here.

One of our primary goals is to make sure that our network is healthy and performing well. All our users depend on it to conduct their work. Computers on our network that are vulnerable to attacks can create havoc once attacked – by overwhelming the network either because of a worm or some other form of denial of service. Similarly, vulnerable computers on our network can be the host for hackers from elsewhere in the world, who can compromise the privacy of many of our users. So, we try extremely hard to make sure that our network is well protected, performs well and protects the privacy of our users. Every day, we see hackers out there attempting to break into our network and every so often they have succeeded. But with our constant vigilance, we detect and repair these problems as expeditiously as possible.

It is widely known that these problems affected only Windows PCs and not the Macs. However, we have had compromises on Unix servers and there is considerable debate about the “potential” vulnerabilities of the Macs since their underlying operating system is Unix.

I don’t know how many of you remember the chaos that we faced three or four years ago when the Fall semester started. Students came with a variety of computers and many of them were vulnerable because of the software that they chose to install on their computers. This was not a problem unique to Wesleyan and a worm attacks 3-4 years ago crippled many other University networks. The security patch management and virus protection software were not as advanced as they now are, so this posed a huge problem.

There was a community effort to build a security vulnerability scanner for commonly known problems which resulted in NESSUS plugins. Though there were software that used these plugins to scan the network, we did not find them particularly useful for our environment. We therefore wrote a program that took advantage of NESSUS information. Basically, every summer, we configured our student network so that anytime a computer was plugged in, it had to go through a registration process. What this meant was, our systems initiated a security check on the connected machine remotely using the NESSUS plugins. If the machine was considered clean, we registered the computer and allowed it to connect to the network. If it was not, we provided information on how to resolve the problem and get back on the network.

This worked extremely well considering it was homegrown. There were a couple of problems. One was that we were able to run it only once every year. Running it every so often would have resulted in a lot of disruptions to all the student computers on the network. This simply meant that a student computer that was deemed clean in September, could have been infected in January because the machine was taken home during the winter break and was infected by a worm or a virus. Secondly, it was cumbersome and required significant manual intervention.

In addition, our solution did not work on wireless, so everyone had to physically connect their computer to the orange jack on the wall and register first before getting on wireless. Connecting game consoles such as the Xbox to the network was cumbersome and needed a visit to the Helpdesk. So, we really needed a different approach to this.

I want to take a minute now to talk about Bluesocket, which we have used for the past three years. Bluesocket manages wireless access control. If a student logs in, bluesocket configured that wireless connection so that the user had access to the resources that students should have access to; if you are a faculty member, you had access to a different set of resources. We also used to allow guest access and it was very limited. Due to changes in laws, guest access was disabled last April.

We were searching for a robust solution that did all of the things that we were doing separately through different solutions:

• The system should authenticate a user whether the person connects to the wired or wireless connection.
• It should scan the computer for compliance (version of operating system, critical security updates, and other vulnerabalities) before admitting to the network. Suggest solutions when the computer fails compliance.
• This compliance checking should be a continuous process and not a once a year process.
• It should grant appropriate access to the network resources based on who the user is.
• Connecting game consoles or devices such as iPhones should be pretty easy

We found Cisco Clean Access to be the solution that did all of these and has been installed and tested in many other installations. So, we went with itand implemented it in August. I want to compliment our Helpdesk on managing this transition extremely well. They did a tremendous job in making sure that the problems were attended to in a timely manner.

We did not anticipate certain problems such as the computers with foreign language versions of operating systems that were being considered non-compliant by the clean access software. In addition, we found that clean access for Mac could be improved upon. We cleared these issues in a timely manner and our stats show that with the exception of a very few computers, everyone was connected to the network in a timely manner. The few that are in Helpdesk need some real serious work and they are working on them.

Since we have a much better handle on the faculty and staff computers, we decided not to roll out Cisco Clean Access to them in the Fall. It is our plan to roll this out to faculty and staff later this year. With increasing number of faculty and staff opting for laptops, the possibility for these computers to be infected is increasing.

In addition, the Wesleyan network is designed based on the location from where a computer connects to the network and not based on who is accessing the network. For example, if the computer is in a public lab, its access closely resembles a student access regardless of who logs in. This is very restricting to faculty and staff because they may not have access to certain services when they connect from such a location.

When we roll out Clean Access fully, the access will be determined by who logs into a computer and not by where the computer is. This will be a great advantage.

This is a very complex subject and I have tried very hard to keep it simple while covering a broad range of areas. Ask me specific questions and I will be happy to explain it.