Wednesday, August 17, 2011

Some musings on security

Security is a chain; the chain is only as strong as its weakest link. The chain extends a long, long way. The kinds of things involved in the chain include (in no particular order), the server software, server hardware, client software, client hardware, backup tapes, LAN, WAN/Internet, wireless networks, backup tapes, passwords, people peering over your shoulder, and the actual users of the system. The latter is generally the weakest part of the chain.

But before we get to that, a diversion to the server side. We recently purchased a subscription to an online service for our school. I didn't have any part in the evaluation of the product, but looking at it once connected, soon saw that the administrator user could see all users' passwords. Fail. Passwords on the server should never, but never be recoverable. The reasons for this are plastered all over the Internet, and relevant literature; I won't go into them here. Additionally, the server did not use an encrypted connection to accept passwords; the password went in cleartext from client to server. Two major security flaws in the one product does not provide much confidence in the designers of the product. What other holes are there in the product, waiting to be exploited? I'll bet little Bobby Tables is just waiting to get in there. The designers of the software might think security holes will only affect their system; they'd be wrong. Password re-use is rampant; an exploit of one site will likely lead to other accounts being compromised.

So, if web-software designers (of quite a popular product in the education sector, I might add) have virtually no idea of basic security principles (I certainly don't recall learning any of that in my Computer Science and Computer Engineering courses), what do we expect of the end-user? We might tell people not to re-use passwords, but who's going to remember a unique password for every site they register on? It's just not going to happen. There has been much discussion on this topic of late, brought on by this comic.

The end-user is (usually) the weakest link in the chain, being human, and in all likelihood, having no idea about security principles. And there are two things (or lack thereof) that make them the weakest link: Usability and education.

Usability in Security: The people who implement security are generally nerds who know a hell of a lot about security. Unfortunately, they don't tend to know much about usability, or user experience (UX) as it's now known. That's a broad, sweeping statement, and I'm sure there are plenty of counter-examples, so apologies to those unfairly tarred by that brush. But any technical security must be balanced with usability. There is no point having a complex password requirement, and resetting passwords regularly if the user won't remember them: they will just write the password on a sticky-note, stuck to the screen. The computer-side security might be strong, but the user has just shifted the security hole beyond the reach of the computer. Users will always find a way to do this. Nothing can be idiot-proof, because idiots are so ingenious.

Security in Education: We do not teach security anywhere. There might be mention of it in the Victorian curriculum, but in passing. Most schools do not have a separate IT subject anymore; the trend has been to integrate it into other subjects. Most teachers I know know less about security than the students they teach. There needs to be some expertise in teaching this, which is currently not being met. The Hacker High School project attempts to cover this, but is excessively technical, and perhaps with an ill-thought-out name. Where are people expected to learn this sort of thing? From the occasional email that the bank sends? Does anyone actually read those? You might think that banks would be interested in getting this into the curriculum, given that they tend to be the primary target of this sort of thing. Perhaps we need to form some partnerships with them.

Perhaps biometrics (fingerprint scanners, iris scanners) will fill in some of these holes, but even they require the hardware to be fully trusted, which is difficult when dealing with user-owned devices. A fully networked world will be full of exploits until that weakest link is somehow strengthened. (Bruce Schneier's upcoming book on security from a societal perspective should be interesting).

Wednesday, March 23, 2011

The advantages of the teaching IT manager

I like to play with new technologies. There are plenty of interesting things out there, but a recurring problem of mine has been to actually put them in effective use in the classroom or school setting. Some people and places respond well to “Here’s something cool – go play with it.” They will play, explore what’s possible, what could go wrong, and if things add up, put it into use. Many people don’t – they’d (rightly) need to see some examples of use, and the benefits. So some technologies get left behind, sometimes because they’re dud technologies, sometimes because no-one’s given it a good shot. Which is where having a teaching load on top of the IT manager job is really quite nice. You can experiment on your class. You have a context in which to use such technologies. That’s not to say other analysis doesn’t need to happen – an assessment of the tech needs to take place before and after. But it provides a starting point for further discussion.
 For example, a few weeks ago on the weekend I set up a Q-and-A site ask.jmss.monash.edu based on the open source OSQA software. It is based on stackoverflow (now the stack-exchange collection of sites) – some kind of merging of social networking, forums, and news sites. I’m not aware of any school using this type of software. I deployed this to my IT class to get an idea of how students would use it. Certianly, it was a small and unrepresentative sample, but within a couple of days I had some idea of how what students were doing that was productive, unproductive, good, and evil, and some clues on how it might go pushed out further. Now I can enter into discussion with other staff on how they might use it, and have some starting points (good and bad) that otherwise would not be there.
Similarly, my increased use of google sites (or at least more ownership in my use of it) has given me better ideas how to make the most of it in class.
I’ve started using google presentations for most of my classes (at least in classes where it fits); this lets me embed the lesson in the subject webpage, and the students can look along as they go, or refer back at a later point. A small change to attaching a powerpoint, but I didn’t know that was possible until the classroom opportunity presented it. Last class I tried giving one student write permissions to one such presentation, and making him the ‘scribe’ for any blank ‘discussion’ slides. It went quite well, both for the student (I picked one who was often distracted or disengaged), and the rest of the class (down the track).
Without the teaching load, I wouldn’t know about these things. I think I’ll aim to try one new technology (however small) each week.  

Sunday, February 20, 2011

A question of control

The issue is seemingly minor, yet opens up a major question. We use Google Apps for our communication and collaboration needs. One of the features is Google Groups - this allows for mailing lists, web forums, and access control. Now, anybody in the school can create a group. I could turn this feature off, but don't really see any reason why. At the same time, I create (via some scripts and magic sauce), the entire range of class, house, and staff groups. In the long term, these will be automagically synchronised to the Single Authoritative Data Source, though for now it's a hodge-podge of scripting and manual intervention. In preparing for the deletion of last year's groups, I asked staff if there are any groups that need to be saved or archived. This showed me that a number of staff had created their own groups for various purposes - staff, class, etc. Here lies the question: how much control over this do I want? It is certainly less work for me if the staff create their own groups as needed - this is simple enough for them to do, disperses control, and empowers the staff in the ICT realm. On the other hand, if everything is automated, that should be less work for the teachers and would make life easier for less techy teachers. Such a system would need to be quickly responsive to changes in group memberships, which it hasn't always been.

And having both systems side-by-side could get messy - I'm happy for ad-hoc groups to be created as needed, but having two groups for the same purpose is messy, and will get confusing in the long term.

Giving this to the teachers cedes control. Which I shouldn't have any issues with, but strangely find creeping into my thoughts increasingly.

The other point this issue raises is the lack of a forum to discuss this sort of thing. I'm happy to make certain decisions, but some things (like this) should be open to discussion by the user base, but there is no real place for this discussion to occur. Not enough of the staff seem to be on twitter or facebook to be representative, the staff@ group I prefer to keep as announcement only, and staff meetings are already overloaded as it is. Perhaps I'll set up an opt-in staff-discuss@ group for this purpose.

Thursday, February 10, 2011

Tablet rollout and distribution

Manic. As usual. Well, perhaps not quite as usual. Things are quietening down a little now, though as soon as I look at the work I've been pushing aside things will no doubt pick up again. This rant will try to cover the tablet rollout process, and the good and the bad.

Timing. Hmmm, not to sure about this. I suppose things went on time to some degree - at least much more on time than last year. Though the delay in shipment last year meant that we could chase up students who hadn't paid, and get them all out just about at the same time. The timeline was much tighter this year.

Communication and Coordination. We really could have better communicated with staff what to expect with the tablet rollout. After the initial handout, there were perhaps 30-40 students still without tablets. Classes, however, went on (as far as I can gather) as though every student had a tablet, hence some students were missing out/falling behind. Staff should have been forewarned about this, to plan lessons accordingly. Additionally, I should have better co-ordinated the handout day with the other staff to prevent collisions and students being in the wrong place etc.


Monash network and tech stuff. This needs to be majorly fixed for next time. The imaging process needs to happen on the Monash net. Ideally, using WDS, the machine is plugged into the network, PXE booted, then everything else is automatic. The major bit that didn't work (I really should have done an end-to-end test) was the AD accounts. User accounts created in MDS don't shift across to AD until the user has changed their initial password. This creates a chicken-egg situation, since they need to have a computer in order to change their password. Hopefully we can change the process for next year so the AD account is created straight up. Additionally, we really need domain logons to work via the wireless. Hopefully this is forthcoming. We will be moving on these things in the coming weeks on the way to re-imaging the 2010 tablets - this will be a good test for future years. (Of course, in future years we'll probably have moved away from PC tablet devices)


Distribution. The distribution model this year was one house at a time. This disrupts classes pretty badly. Though it was a very disrupted day anyway. It is also a lot of students, at the same time, not that many students. Some aspects (e.g. email, compass, basic overview) would be better done with the whole year at once, other aspects (initial login) needed to happen in smaller groups. Problem solving on the fly was tricky - mostly the students had to wait till the session was over. If the initial network login problems can be fixed for next time, the distribution would be a lot less painful, but that's completely dependent on Monash. Additionally, the account slips could have had some info clearer, and more instructions/URLs. A model some other school uses involves making an evening out of it, with parents involved. The logistics would be tricky, but would also put some more pride and excitement into the affair.