How Compliant Products Stay Compliant
By Steve Cunningham
Many AV Technology readers are IT professionals, many of whom work in the education sector. With that in mind, the following story will not comprise just another recitation on the importance of network security in education; that movie has been around so long that even Netflix dropped it. Rather, this story is about how a relatively small school within a big university is adapting to the necessary hardening process.
To be clear, there are no high-drama incidents involved, and no confidential data has been expropriated. However, there have been a couple of near-misses, and the administration decided about a year ago that it was time to launch a long-term, methodical program of hardening our Information Technologies across the entire university. Professionals were called in to perform security audits, or as they prefer to call them, "assessments," in an effort to find as many points of vulnerability as possible so they might be fortified. Those points were found and listed in the reports which wrapped up just a couple of months ago.
That's where I come in, since I'm responsible for several servers within the school. These include an oft-mentioned Apple Xserve connected to an Xserve RAID, both of which were rendered redundant by Apple in 2011, which serve as a nice Mac-based file share serving several dozen iMac client machines located in computer labs. Of course the Xserve showed up in the report writ large, in part because it is two OS generations behind the client machines it serves. For those of you keeping score, the server is on 10.5.8, while the clients are on 10.7.5. This is not unusual in general, nor is it seen as a big deal within the Mac IT community. But it was a big deal during the aforementioned "assessment" where it generated several pages of non-compliant list items.
Fortunately, the decision to put the Xserve out of its misery had already been made given the server's age, the dearth of support from Apple, and the demands placed upon it during normal teaching and lab hours. In fact, experiments were already underway to determine if that Apple server software could be made to provide the same reliability and performance on a VMWware virtual box that it does when on the native Apple hardware. Unfortunately, at that point we experienced some turnover in IT which tabled those experiments until just recently, so we still do not have a complete answer to that question.
The other non-compliant items on the hardening checklist have been easier to remedy; we are in the process of switching all off-campus users of file shares to VPN, and are monitoring what appears to be a very slight hit in performance as a result of that change. Thankfully, the hit is far smaller then it was when I last regularly used VPN—today's software seems far more efficient, a finding for which I was particularly grateful as I uploaded a multitrack audio project for students whose size was just under a gigabyte.
Other necessary steps are and will continue to be taken, but that's not the real issue. The issue is that the technical staff consists of two full-time staff, a remote consultant, and one faculty member (for better or worse, it’s me). The four of us are already carrying full loads; mine in classroom units and the others' in staff hours serving student and faculty needs, from grumpy network printers to malfunctioning Fender guitar amps (this is a school of music, after all). It's clear that another network-oriented staff member will be required to ensure that compliance stays compliant. Did I mention that the school's website is being completely redesigned so faculty can produce and upload their own content?
Almost all technology used in the education space carries with it a cost that remains hidden, right up to the moment when the implementation is deemed complete and the switch is thrown. That cost is maintenance, to which compliance can be added, and it remains a fact of life. Those who overlook, minimize, or ignore it, especially in the rough-and-tumble world that is the Internet, put their data at risk.
Steve Cunningham is an assistant professor at USC’s Thorton School of Music.