A new anonymous wrote: "Two of the most intractable problems with security in any large organization are lack of resources and counterproductive user behavior. A "computer user good behavior" class would address the latter while leveraging standard academic resources to reduce the impact of the former. It's a brilliant win-win idea. "

A well planned, educating "computer user good behavior" class would be brilliant and address the issue. These classes likely would not be good. I've tried participating in said committees as you mentioned (not for that specific topic...)--the point is students have no real place in those committees. It's all about liability, academic interest, scheduling, budget and other non-issues (as far as I'm concerned, they are non-issues...I don't deny they are valid to some parties). Everybody knows that what a course has on the schedule of record, what it has on the syllabus, and what it does in class is...unfortunately diverse, and someone qualified enough to do a *good* job of this in all likelihood either doesn't work for a university, doesn't have time to come to one, or would not be permitted the resources to do a thorough job. But, assuming that someone *could* teach the basics, there's another issue...

The problem is not being taught by someone who knows less than me, but being taught by someone who has only scratched the surface of the topic and has a shallow inaccurate understanding--if not the outright incompetence I so loathe. I love cryptography, but I wouldn't dare teach a course on it--I know that my interest does not make me good enough. Most people in academia...don't seem to get this--they read a few papers and think they're ready to talk IS.

The head of my uni's cybersecurity program once gave a lecture in which they advised nobody to ever use a credit card over the internet because they were too easy to steal. Evidently they'd never heard of onetime card numbers or the 0 liability law...but the audience looked very scared. They knew about it...had great statistics...but the issue was grossly overrepresented... people left frightened.

It is my assertion that the risk of shallow, ill-advised lectures regarding computer security is greater than the risk posed by an ill-educated audience. In my experience, most ill-educated people are at least wary--but the wrongly informed are likely to either place trust inappropriately, having been told that "if the author replies then you know his institution is real", or perhaps even worse--succumb to FUD and stop using their computing resources altogether. The third (much worse) option is they get frustrated with the amount of work necessary to maintain a reasonable system and give up on it, resigned to simply permitting IT to pull their plug about once a month, and having their entire system reimaged...

I'd like to ask what *would* such a class consist of without treading on the toes of other curricula, and how do you teach a user to differentiate between best practices when even admins can hardly agree upon them? If you tell all your users they should update their Vx Scanner once a week, I'd wager that if they actually listened their systems would all start connecting at a default time every friday night and slowly grind the network to a stall. Do you just do a one hour seminar on not opening unexpected emails, or do you spend a few weeks and get into details like creating non-administrator accounts in windows XP, password policy. I always liked to show students how to download NAI's stinger and adaware, because those addressed their worst symptoms--but that never solved the problem of them clicking "yes" whenever a "do you want to install" dialog popped up. Nothing would change that behavior save multiple painful experiences... Could the people here agree upon a set of guiding principles that such a class should and could cover?

I think Erik had a great point about Denmark, where the university's are tax-funded. In that case, the students are accepting an offering from their government, and have responsibilities that may be established accordingly.

Here in the US though, everything is privatized--we (students) pay the university, and rightfully expect unfettered access as their customers. The liability issue is also an unfortunate point. Liability is an ever-present issue for support staff--but again it is not something that should be evaded--confront it head on and mitigate it like every other risk it is your responsibility to manage--establish policies, document user systems, and make it very clear that you *will not* service pirated software. If appropriate, establish contact mechanisms to report these violations, and make sure that students know in advance about this prior to service.

The point though--perhaps denmark's example can be applied to the US: There was *one* special dorm on campus that had computers provided to the students. These systems had software provided, ACL's set, automatic scanner updating, and almost never had any problems save the cheap hardware failing unfortunately often. Need I say these systems were security problem free except for one person who was good enough to reset the bios pass to reload the o/s, but not good enough to protect it? I didn't like it--but it *did* address the problem of diverse configuration (assuming that is a problem...I'd claim a diverse enough configuration helps avoid a vulnerable monoculture).

I know of at least two or three schools that now require freshmen to use specific laptops...sounds like an argument for a standard install if I've ever heard one, although again *I* would fight it.

I have also heard that at Cambridge Uni, the IT refuses to active a students port in their dorm room until they bring it into some office and have it manually scanned by the staff. Again, a bit unusual for my tastes and it sounds horribly human-resource intensive--but there is no major reason why everyone needs to be online at day 0.

To Erik's question regarding tools:

I have never ran a university network, and wouldn't want to. Networking is just a means to an end for me...and doing it for a living would likely leave me quite unhappy. However, *this* would make a great topic for a thread/article--a compilation of free tools suitable to protect a university network. I'd be interested in seeing what people use on large scale networks... I refuse to believe for an instant the admins are helpless against the onslaught of webbugs, filesharing, spam and viruses/trojans, even from unsecured student computers--the problems just need to be scaled down.

I know that there exists and have used instances of (and I'm sure the people here have deployed on far larger scales than I)

-Traffic shaping applications capable of prioritizing nonfilesharing bandwidth

-Webproxies that may be configured to remove common categories of malicious content.

-Scripts capable of dynamically reprogramming firewalls to temporarily permit necessary traffic through on a case by case basis.

-NAT (the big, obvious one). Why are students computers typically external, global IPv4? Yes, I *want* to run services on occassion, I expect to be able to do so and even expect to be able to request an externally visible static IP at no cost from IT. But *why* is this the default? Why are crackers able to trivially portscan your whole subnet and look for open services?

-honeynets. Having watched one or two computers get broken into over the wire--it's the sad case that these attacks appear to be mostly automatic. So put up a decoy, and detect the automated threat instead of waiting for some kid from germany to start eating your pipe up as part of a DOS. Then do your part as an admin and have their upstream provider pull their plug, and drop the traffic from them. It does create a DOS risk if someone forges packets--but which would you rather deal with, taking an hour to bring the network back up cautiously or a week's worth of quarantining off worm-ridden IIS ? Either way the network will probably go down--but by the former it went down under your control.

-Or how about the simple rule that when a system left support, it had a copy of KaZaA lite's hostfile loaded onto it. We'd tell the user what it was, and provide instructions on how to disable it if there were problems--but doing that alone cut the number of spyware/performance issues we had nearly in half. You don't have access to user system resources, but you could add a few special routing rules...

I make no claim of knowing all solutions for all systems (although I am very confident in my little network)--but I firmly believe they exist, or if not, may be found and implemented in relatively little time.

Regarding defense in depth from another anonymous--I can't agree more wholeheartedly in theory. In practice though, I spend my resources where they will be be the most effective--no point in killing myself when my probable adversary is just another idiot running a generic script, and my worst case adversary is horribly offending somebody in a thread like this... But I have adopted my set of "best practices" to handle what I consider an appropriate level of risk. If I was an admin at a three letter gov't agency obviously I would escalate my set of best practices to a much higher standard of paranoia. Not all tools are appropriate, or scaled to the task at hand.

I think the professional term may be ROI (return on investment)...although I'm not sure there *is* a return on a security investment. Before I bought a cryptocard for my system I set up NAT and portsentry, before I took the time to learn to configure a mailserver I made do with fetchmail. I'm paranoid and would *like* a tempest safe system, but the perceived risk doesn't really justify the cost. Education is a lot more expensive than hardware...

I suppose this whole rant comes down to the fact that I cannot even c

[ reply ]

Link to this comment: http://www.securityfocus.com/comments/columns/267/28580#28580