Security pros: Be wary of tech analysts

This comes on the heels of something Troy was getting at recently on his blog.

It is far to easy for someone to call themselves a "security expert". It gets worse when you are high profile (like an analyist) as followers will be attracted to you like lemmings. Even if you really have no clue what you are talking about. Experience trumps reading a book or FAQ any day, and most of these people who call themselves experts have never even been in the trenches. ZDNet reported this in an article recently, where they point and counterpoint the analyst "expert" issue. I also see this in supposedly "Whitehat" hackers who never have hacked a system.

Yes I am going to cause some sh*t with that statement. Good. Until you know the threats you are susceptable to, you cannot effectively defend against it. And if you are in the field of applying technology to information security issues, you MUST learn how the hacker and his tools work. You must have experience hacking to get that. Now WAIT. I am not saying you should attack OTHER peoples systems.. But you should gain some experience on your own machines, those in which you have permission to do so. I have dedicated VMWare sessions specifically to allow me to try new things, and see how that particular OS would respond. When you have written/modified exploit code and tried a buffer overflow attack, you will vastly grasp how it works, and then can start to learn how to defend against it. Same goes with worm propagation, patch management tests, penetration tests etc.

I see it time and time again. Great security technologies rendered useless by people who don't know how to properly use them. Strong security will always be trumped by weak implementation. Just because you can apt-get snort doesn't mean you know how to use it. Just because you can rpmfind nessus doesn't make you a vulnerability scanning god. Just because you read Secret & Lies doesn't make you a security guru. I could go on and on and on and on and... well you get the picture.

We need to learn from doing, while applying this new knowledge from that which we learn from others. I typically don't need to write a buffer overflow from scratch, I can use the experience of others on mailing lists like bugtraq, ntbugtraq, vuln-dev etc to gain from the experience of others.

I think Douglas Adam said it best when he said:

Human beings, who are almost unique in having the ability to learn from the experience of others, are also remarkable for their apparent disinclination to do so.

Get my point? Roll up your sleeves and get dirty. Install some flavour of an OS (Linux is a simple and good choice) in a vmware session and attack it with the numerous exploits out there. Learn what its actually doing. Then learn how to recognize the attack. Learn how to audit the system and find the penetration. Make the term forensic audit actually mean something to you. Then learn how to defend against it. Learn how to create policies and procedures that can be your guide within your real environment to prevent these sort of attacks from even taking place. When you start to do this, you start to see the entire security management life cycle and realize most analysts don't know what they are talking about. Nor do many MCSE types who sell themselves off as security experts.

My apologies to those in the information security field who lean towards the policy and management side. You will probably not CARE to do this. But I would like to challenge you to consider it. Understanding both sides of the field will make you a more rounded individual. You can better apply policy when you truely understand how the application of technology will be implemented. And hey... its fun! Of course, the reciprocal is also true. Implementors of security technology need to fully understand policy and procedures of the field, so you can truely apply technology properly. Security is not a technology problem alone, its a business one. Understanding this will allow you to go much further in this field, as you can apply policy in the light of politics in any stage of the security management life cycle.

Of course, you can think I am some beaver lovin, nut case Canadian and ignore the electrons that make up this entry. Hopefully you won't be protecting any information that pertains to me, or some nuclear silo at the US border. :)