In article <1159650373.038559.249970@i3g2000cwc.googlegroups. com>,
bob <r_stringer66@yahoo.com> wrote:

>I didn't say that my cs degree will make me qualified right now, all I
>am asking is what path should I take so that I can get there. I am
>looking for a road map.

>I don't believe your analogy to debugging is relevant.

There are small number of major branches of security work:

- academic and theoretical work, such as cryptography (e.g.,
public key cryptography, or new encryption algorithms), key exchange
theory (e.g., zero knowledge proofs), finding new theoretical attacks
(e.g., the "birthday paradox" collision attacks on MD5), invention
of new security mechanisms (e.g., better face recognition algorithms),
formal studies of how organizations are actually implementing security
and whether it is working for them, formal studies of whether
security devices actually work (e.g., the Dutch study a couple of
years ago that showed trivial attacks on fingerprinter readers),
and studies on security in public interests such as voting machines
(e.g., Avi Rubin, Rebecca Mercuri)

- formal security process modeling, requirements analysis, documentation,
and compliance checking (security analysts and auditors)

- virus/trojan/malware related work (development of, protection against)

- "front line" security related work (the people who have to
protect real networks)


Your CS degree could hypothetically provide a lead-in to the academic
side, but is -unlikely- to in practice. Professors in charge of graduate
studies programs have told me that *in practice*, very few people
successfully come back from working careers into advanced degrees:
one has to be -highly- motivated to put up with all the aggrevation
that a typical PhD student is put through. And darn, the kids need
orthodontics, so "I'll just take this semester off to earn money for
that"... and few make it back from that (or the new house that has
to be saved for, etc., etc..)


Your CS degree -might- have given you a taste of formal design
specifications and requirements analysis. Your years of work might well
have thrown all that out the window because The Product Must Ship.
You might have been one of the lucky ones that worked in a place
that really cared about changing -processes- to reduce errors: if so,
that experience would be *much* more valuable to security work than
your CS degree.

Keep in mind, though, that a security auditor is an *auditor* --
which can be mostly paperwork and process checking. To be the
kind of auditor that notices the "crooked books" (companies hiding
their true security practices, or intruders who have surreptiously taken
control), it is usually best to already have been on the front lines
and to have experienced security life "behind the scenes".


Very few CS degrees that I've heard of offer courses on malware;
I think I've heard of one in Scotland and two in the USA. Maybe
there are more by now.


That brings us to front line security, in which I mostly refer to
the (generally) unloved and underfunded people who actually have to
make the security *work* in an organization; but I also include those who
provide direct support for that kind of effort by working on
intrusion detection and real log file analysis. Programming
skills can certainly help in this kind of work, in providing the
ability to write or adapt or repair probe programs and analysis tools;
and good knowledge of how networking really works helps a lot.
But those are more a function of experience than of anything gained
through a CS degree. A CS degree might give you the confidence that
your programs will work reasonably well (instead of a perpetual
feeling of "I hacked as best I could"), but the actual programming
is typically an adjunct, not the bulk of the work.

To my mind, there is no academic substitute for front line security
experience, for having been there and done that and having lived
with the panic of security crises. And of having dealt with
the person who think it is their "right" to watch multimedia at work
or their right to have a backdoor to their system at home or from
home to their system at work. And to have figured out what to do about
the people who write their passwords on a post-it note on their screen,
or who demand administrator access. If you haven't had to talk a boss
*out* of a planned security measure then you probably don't know
law and rights and court cases and company policy as well as you should.

I know this harkens back to the old "Certification or Experience"
debates; you can probably tell that I generally favour Experience.
Not that I disdain academic works: they can be very valuable in
providing new ways to think about matters. But books get shut, and
professors and instructors go home at night, and security crises don't...


>I like
>debugging and I am pretty darn good at it.

I wasn't being facetious or irrelevant: in my experience, there
are quite close ties between the skills used in serious debugging
and remdiation and QA, and the skills used in practical security.
Both benefit greatly from strong skills in analysis, and pattern
recognition (very quickly seeing something the slightest bit odd
as being "wrong"); benefit from the perversity of mind to not see the
shiny image of what the program or process -should- do, but instead
see myriad ways that the program or process could go wrong; and
benefit from the QA- type fire to get it *right*. At the same time,
though, a person doing practical security work has to recognize
budgets, and time limits, and politics, and personalities, and overwork,
and to do the important things first... even if it sometimes means
doing what *has* to be done instead of what you've been told to do.


But as for a road map for getting from where you are to where you
want to go; sorry, I don't really have one. I think I'd suggest
starting with getting a business firewall and tossing it on your
network at home and learning how to exploit all the information you
can from it. But I'd also suggest that for learning purposes, it
might be very instructive to get one of the open source honeypots
and study it an implement it; see for example the article at
http://www.securityfocus.com/infocus/1659
And if you were to look at Nessus and were to learn what it scanned
for and why, you'd have learned a lot.