Monday, June 06, 2005

Training, time, and job responsibilities

As sort of a crossover from my last post, I thought I'd blog about some of the responses I received directly to my email inbox...

The biggest thing I'm seeing, from the responses as well as my own personal/professional experience, is that security takes time...and time is usually something in short supply. IT managers (and by this I mean all the way up to C-level folks) don't count on the fact that staying abreast of security issues takes time. Even if you're in an all-MS shop, with only Cisco routing equipment (as I've been), staying up on the latest viruses, effects of patches (and the systems they apply to), etc., all take time. Usually what ends up happening is that either (a) "security" is an ambiguous assignment to an already-overtasked and under-trained admin, or (b) the security guy/gal is seen sitting around staring at their monitor, so they're asked to help out with everything from helpdesk to router installations.

Now and again, I get perturbed at the content I see in posts to public forums. One of my pet peeves is the admin who posts to one of the SecurityFocus lists, and respondants ask questions for clarification...yet through the life of the thread, the original poster (OP) never responds. In the few instances where I've been able to track the OP down via direct email, 99.99% of the time, the reason for the disappearance is that something else more important came up (ie, Shiny Object Syndrome).

Another pet peeve is the OP who will ask a question that could have been answered, or perhaps simply better phrased, had the OP done some research of their own prior to posting. Sometimes a simple Google search is sufficient, other times simply putting together their own test would have answered their question.

So, what do these peeves of mine have to do with the subject at hand? Well, the first has to do with time...in many cases, it seems that admins are turning to public forums for their answers, but don't want to give out too much information about their networks or the situation they're dealing with. In many cases, troubleshooters/respondants need simple things such as the operating system/application name and version...which the OP may not feel comfortable giving out. However, the real issue is the fact that the OP is posting in the first place...they obviously have an issue they're dealing with but don't have the time to learn basic troubleshooting skills, troubleshoot the problem themselves, or get on the phone with techsupport for the application in question.

The second peeve has to do with education and training, at least indirectly. Well, now that I think about it, they both do. In a lot of cases, when I've asked people why they haven't done their own research, the ones that don't feel like they're being bullied (and they're not) will tell me that they don't have the time. There's no harm in asking questions, but sometimes questions can be answered or better phrased if you reason things through, do a little basic research, and even try something for yourself.

Taking training and education a step further, I've often wondered why there are so many people who lurk on public lists, some who post, and so very few who publish anything. When I say publish, I'm not necessarily talking about writing a book or getting an article published...what I'm talking about is doing some testing, documenting the methodology so that it can be duplicated and verified, and then writing up your results. I think that if there were more of this, the computer forensics community itself would be better served, as a whole. However, when I've asked about this, I've been told that the "requirements" are too rigorous...it takes too much time, and many people actually write so poorly, that they don't want to have to go through the headache of constant editing (and the sense of rejection they may feel when someone corrects their spelling and/or grammar).

You know what? You don't have to be a PhD to get something published. Actually, it's pretty easy...of course, I'm saying that as someone who's already done that (and tried to help others do the same). Not only is the act of getting something published educational in and of itself, but just going through the process of discovery teaches us a lot. I set up a testing methodology before where I've had to go back and redo everything, because after I was done I realized that there was something else I could have done. And then once we put our methodology and findings out there, we're all better for it.

[rant off]

No comments: