10 Myths About Life As An IT Security Professional

Posted on April 26, 2008

image credit: Lady Pain

When you picture the future, what do you see yourself doing? If you find the subject of IT security fascinating, you may be considering a career as an IT Security Professional. To help you decide, here are 10 myths about life as an IT Security Professional.

  1. IT Security is basically about Passwords and Anti-virus.  This is completely untrue.  You may hear this from people that don’t get paid to do security, but think they know all about it.  Security is a very diverse field covering a wide range of skills including; threat modeling, risk analysis, policy creation, security awareness, incident response (wide field), forensics (desktop, server, network), platform specific security (e.g. Windows, UNIX, Linux, OS/400), network security (WAN/LAN/Internet/wireless/telco), vulnerability assessment, penetration testing, application security, reverse engineering, malware analysis, vulnerability analysis, exploit development, social engineering, physical security, cryptography, crisis management, disaster recovery, 3rd party security reviews etc etc.
  2. You get to bark security orders.  Some people feel that holding a security policy in their hand means they get to call the shots.  Do this on a regular basis and not only is it counterproductive but its a surefire CLM (Career Limiting Move).  Some years ago, this may have been possible but these days its much more myth than fact.  From my experience, you can get a *lot* further in the long term through a mix of explanation, persuasion, technical demonstration (”look how easy that was to break into!”), humour and relationship building.  And sometimes, the policy is wrong and you have to big enough to admit it and fix it.  One thing to note: in a crisis or other time sensitive incident, it may be time to bark the orders.  Most reasonable people will understand that after the event.
  3. You don’t need any technical skills.  I believe you do need *some* technical security skills to be effective.  However, that doesn’t mean you need them before you start the job, just you should be prepared to develop them.  If your role is writing general security policies - frequently seen as a non-technical role - you will write better policies if you have an appreciation of technical issues.  What’s the right level?  Hard to say as it will depend on the composition of the team. If its just you, a strong grasp of technical security will be vital.
  4. You won’t learn as much as someone doing a “normal” IT job.  Possibly the biggest myth.  From my own experience: I used to manage very high-end UNIX and ORACLE servers.  At the time, I thought I was pretty knowledgeable - I was working on the latest kit, worth millions of dollars.  I was considered something of an authority.  But then I stumbled into IT security and soon realised that despite my deep system administration knowledge I didn’t understand the detail of what was going on “underneath the surface” and specifically, how it could be subverted.  From that day forward, I made it my mission to learn everything I could.  I am still learning now, a decade later.  It was the best switch I could have made.
  5. Your friends will disown you - IT security is geek - but not “cool” geek.  Thats a funny one.  Some people get hung up that their friends will think their job is boring.  If you work in the IT industry, your non-IT friends probably think you are boring already - get over it :-).  Who are you doing this for, you or your friends?  Besides, over time, you will develop new friends who work in the same industry as you and by definition, they will think you’re cool ;-).  Plus, if you get to do really cool security stuff at work, your friends will ultimately be jealous of you.
  6. You get to read security mailing lists and RSS feeds all day.  Ha!  Drinking from the firehose of the Internet is generally not recommended.  A few gulps a day is definitely helpful, but the reality is that organisations typically have a slew of security issues to deal with.  Wrapping your head around those and figuring out creative ways to handle them is more fulfilling and why you got hired.  Staying up to date is important, but unless you are a full time researcher, its 20 minutes to an hour per day on average.
  7. Security is a dead end job.  Firstly, there is so much scope within IT security you will never run out of career options within the Industry.  Secondly, if management is your thing, large companies frequently have a CISO (Chief Information Security Officer).  The CTO (Chief Technology Officer) position is a popular jump at some large companies or leaving the fold and becoming a ‘consultant’.  Either way, your options will not be limited. 
  8. You get to snoop on employees under the pretense of ’security’.  No-one I know gets to ’snoop’ on fellow employees just because they ‘feel’ like it.  From time to time you may have cause to investigate the activity of company employees.  Company security policy likely requires that certain criteria be met first and HR and senior management must be informed - prior to any monitoring taking place.  Failure to follow that kind of policy could easily get you fired.
  9. You get to write exploits all day.  Its true that some people do get paid to write exploits but for most people in the Industry its a definite myth.   Developing reliable exploit code for non-trivial vulnerabilities can be time consuming and hence expensive from the employers perspective, hence there are few opportunities.  Unless you can demonstrate talent and strong potential, its unlikely you’ll get hired to develop exploits all day.
  10. You get to break into company systems when you feel like it.  A dangerous myth these days!  Even if your boss thinks its a good idea, you’ll be needing a legal sign off letter from an authorised party (typically a CIO) before running *any* attacks.  This is your ‘get out of jail free’ card.  The sign off should include specific dates, IP ranges and any specific limitations.  No company is interested in having random attacks that potentially crash key operational systems or hinder development schedules (let alone open themselves to the accountability issues).  A desire to test security is understandable, but its very easy to break things, especially when you don’t have much experience.   Even if you don’t crash anything,  if you were not specifically authorised, you would likely get fired (and maybe arrested) if you got found out.