
So You Want to Be a Security Expert - 127001brewer
http://www.schneier.com/blog/archives/2012/07/how_to_become_a_1.html
======
daeken
I have no idea what his list would actually make you, but it wouldn't be
anything I'd consider to be approaching "security expert". So, here's my list,
So You Want To Break Shit:

\- Learn C. Learn it well. That will give you the level of understanding you
need of the way the computer works.

\- Learn Python or Ruby. If you can automate something, do it. Computers are
better than you at repeatable tasks.

\- Learn x86 assembly (to start). Write some C code, compile it down to
assembly, and read it; understand how the two map to each other. Get your
friends to write stuff for you and decompile it back to C, and have them check
your work.

\- Learn the basics (at least) of web development. Understand how web
applications work, understand the constraints it puts in place, understand the
interactions between the client and server.

\- Internalize the OWASP Top 10. Understand and be able to recognize and
mitigate XSS, SQL injection, command injection, arbitrary file reads/writes,
etc.

\- Grab old versions of open source software and rediscover known
vulnerabilities. Grab the latest versions of open source software and discover
new ones. Start off looking for simple things, and know it well.

\- Reverse-engineer network protocols. Pick a game, write a server emulator
for it. This is a great way to use all your skills up to this point. It's also
a lot of fun (it's how I cut my teeth).

\- Write a debugger. Understand the interaction between hardware, the kernel,
and userland.

\- Understand, understand, understand. Ask questions. Ask a _lot_ of
questions. In my opinion, the key to security is always asking "Why?"

These are in no particular order, and none of these is more important than the
other. It also jumps all over the place, perhaps because that's what I do
myself; I may be breaking a web app one day and reversing some hardware the
next. But these are things I feel are important, and will give you some
direction.

If anyone has any questions, wants direction, or anything else, my contact
info is in my profile. The world needs more breakers.

~~~
yan
I think this is a good list on how to get good at learning to jump between
layers of abstraction with gusto, but I think ultimately this all needs to be
motivated by a desire to actually exploit or reverse engineer something (as
your latter bullets point out).

Learning C super well is important, so is assembly, so is other topics but I
think fundamentally, step one needs to be: "I have product X. What is it
trusting? What is it trying to protect? How do I get around it?" Then, find
similar vulnerabilities and continue on stumbling to the ultimate goal.

~~~
tptacek
Being able to jump between layers of abstraction --- in both directions, so
I'd add "learn the browser JS DOM model inside and out --- has to be in the
top 5, probably top 3 all time most useful software security survival skills.

~~~
sadpluto
What is the standard reference for DOM mastery?

~~~
wglb
Another document worthy of some study is <http://lcamtuf.coredump.cx/postxss/>

~~~
tptacek
Yes! This is a great paper which made surprisingly little noise given how
important it is.

The idea is: stipulate that no attacker can ever inject Javascript into a
browser. Assume we solve that problem completely. Now, how secure are DOM-
based applications? Turns out: not that much more secure. Lots of very clever
examples.

------
drostie
If you want to start _doing_ security, I think it is more important to learn a
fundamentally different perspective. It's sort of like learning magic, where
the new perspective is 'What will my audience assume automatically? How can I
get them to think that a given hat is empty?' (If it's a baseball cap and you
drop it or invert it or so, for example.)

In security you're asking a similar question addressed instead at yourself.
You're asking, "what am _I_ assuming automatically?" Schneier for example has
talked about why pilots don't get reduced screening at airports. The problem
is that the pilots who cry out, "this is absurd, I could crash the plane I'm
flying, how could I possibly be _more_ of a risk to these people?" don't
realize a certain automatic assumption: the assumption that the only people
wearing the pilot's uniform are fellow pilots.

I tell this story occasionally, sorry if you've already heard me tell it. I
once corrected a major security leak in an application I was paid to help
develop -- the leak existed in the dev but not in production (thankfully!).
The problem was that the team who had asked me to help out had made an
assumption: "logs are good and are one of the only ways to create an
audit/revert trail, we should log every request which comes our way just in
case." This was built deep into the system. When I heard that, I was almost
floored. As a proof of concept of the seriousness of what I'd realized, I
looked through the audit logs for my boss's dev password and sent it to him.

It's a fundamental perspective shift: "if I wanted to break this, what
assumptions could I use against it?" Whenever you see an implicit assumption
you ask "how could that come back to bite us later?"

------
tuxidomasx
I'm glad he mentioned the importance of doing and showing rather than just
studying the material. But be careful-- like many careers, computer security
favors specialization, and its easy to get more or less pigeonholed into a few
areas. This is further complicated by the rate at which technology changes.

I spent 6 years in computer security right out of college, and most of it was
PKI and assessments. To stay on top of other areas of security required
constantly learning and doing stuff on my own, outside of work.

Even if you make it a profession, you have to keep learning and doing if you
want to be considered an expert or specialist.

~~~
skrebbel
> _But be careful-- like many careers, computer security favors
> specialization_

I agree that this is worthwhile to be careful of, but it very much depends on
your employer as well. As with any career, find a good employer. So if you
care about being a generalist, find an employer that needs you to be a
generalist. I know for a fact that there's plenty of these in the security
space.

------
z1g1
I would be interested to see what the HN crowd's opinion on certifications
are. Mr. Schneier mentions them in his post but they seem to be a sticking
point in the community as a whole. I have been on the hunt for ~2-3 months now
without luck so far. I am currently working on my CISSP though I don't have
the experience to qualify (CISSP requires 5+ I only have 2+) for it so even if
I pass I can only qualify for the associate level.

I'm not sure if the CISSP is the way to go but I want to feel as if I am
moving forward on a career search so I don't get stuck in a rut.

~~~
rdl
IMO, he's seriously wrong about certifications. (and not really on the right
track with this article in general; a good background in making stuff is key
to knowing the tradeoffs in securing stuff...)

Maybe the perfect cert would be a useful tool for some purposes (corporate
hiring, huge projects with consultants doing low-level IT, etc.), but those
are crappy jobs (and not really "expert" in any way).

More importantly, the extant certifications are all crap. CISSP in particular.
Get it if an employer requires it, but it's independent of your actual
knowledge and learning process.

~~~
tptacek
You will never, ever get the time you waste at a bad employer back. Employers
that require CISSPs are far more likely to be wasting your time than not. The
most important life lesson I've learned over the previous 10 years: be
jealously protective of your time.

~~~
rdl
If you're in the military, you're basically required to get it, and it's not
much more of a waste of your time than other things you could be doing
there...

I personally got it just so that no one else in my company would ever need to
do so; there are stupid companies which won't buy a product without
integration, and where they have artificial requirements for integrators being
certified. Given that it is only 1% of useless pain to enable 99% useful
rewarding stuff, I found the sacrifice worthwhile.

~~~
tptacek
This comment is a great example of why I'm training myself to be less
factional and defensive about people who hold the certificate. The military
thing hadn't ever occurred to me.

But to be clear: I believe pretty firmly that for technical / software
security, the CISSP is useless.

~~~
rdl
CCIE Security is probably useful, although that's more CCIE + Security than
some abstract security cert, too, and specifically for network security, and
specifically the kind of network you get in a corporate environment, not a
startup/saas.

I'm not sure how I feel about SANS/GIAC. Absurdly expensive IMO, but
potentially actually has some value for sysadmins doing system security. I
can't think of what CISSP is actually good for, except maybe trivial pursuit -
crappy consultant edition.

~~~
suresk
Somewhat related - about 2 years ago, my employer had a bunch of us go through
the SANS/GIAC GSSP training & certification. Some of the material was pretty
boring and of questionable utility, but we had a good instructor and some of
the hands-on parts where we were finding vulnerabilities was actually really
fun.

I'm under no illusions about the certification's marketplace value and I doubt
I would have ever paid for the course/cert on my own, but it felt like one of
the better formal trainings I've been through in my professional career
(which, granted, isn't saying a whole lot by itself).

Also, the certificate comes mounted on a comically oversized plaque, which
provides some entertainment value.

------
phaus
An important thing to note is that there are many different aspects of
security, and therefore, there are many different types of security "experts."

Here at HN, many of us tend to view things in terms of how it relates to
software development, but there is more to security than computer security,
and the author mentions this in some of his other articles.

There are physical security experts, often having an extensive background in
military or law enforcement operations. There are COMSEC custodians who are
experts at implementing, operating and repairing a wide variety of
cryptographic equipment, while also managing a program that generates, issues,
maintains and disposes of an organization's crypto keying material. There are
also security managers who at one time may have been experts in a specific
domain, but are now called upon to maintain a bird's eye view of an
organization's entire security strategy in order to develop a cohesive plan
for minimizing the treats presented to their employer. There are intelligence
analysts who make an organization more secure by using their expertise of
social engineering to actively track down those who would wish them harm. Each
of these types of employees is a security expert in their own right, yet none
of these examples really need any knowledge of programming.

When you look at the content from the Security+, CISSP, and CISM, the classes
lean heavily towards information security, but they address the other areas
briefly. More specifically, they focus on information security from the
perspective of a security manager. In other words, you don't take these
certifications to gain technical expertise.

Unfortunately, many businesses fail to understand this, and so they end up
making CISSP a requirement for their technical recruits out of ignorance. Does
this make the CISSP a worthless piece of paper? Not really. It's just
misunderstood by those whom are doing the hiring.

~~~
rdl
There are lots of subfields of security. (for instance I really wish I knew
more about appsec; by far my weakest area, working on it.)

However, CISSP is a worthless piece of paper for IT security managers, crypto
custodians, developers, pentesters, and auditors.

------
danielrm26
This is a good list for getting a job in information security. Becoming an
expert? Not so much.

~~~
SoftwareMaven
To be fair, though, he is writing it for people who want to get into the
field, and you can't become an expert without getting into the field first.

(Well, you can, but it requires dedicating a lot of time and energy to it,
more than most people are willing to give up after the normal day job.)

------
stickfigure
I have a better idea: Forget becoming a "security expert" and become a
security-conscious developer instead. The world needs a lot more of the later.

~~~
tptacek
Disagree. With possibly a few exceptions, secure software development is led
by the breakers, not the builders. Some of the best of the breakers start out
as competent builders, but either way: you can't defend something if you don't
understand how it's going to be attacked, and the history of software security
over the last 20 years suggests that we _suck_ at predicting what attackers
will come up with. Great example: "buffer overflows are easy to fix; just make
the stack non-executable".

One of the best secure developers in the world is Daniel J. Bernstein, and,
two things you'd want to know about DJB: (i) he missed LP64 integer overflows,
which got flagged by (pure breaker) Georgey Guninski, and (ii) he's a world-
class cryptanalyst and breaker in his own right.

There's a reasonable "builders vs. breakers" argument to be had, I'm sure, but
my experience suggests that overwhelmingly the people making this "world needs
more builders and less breakers" point are people who are annoyed at the
prospect of sinking the time into becoming a competitive breaker.

~~~
cperciva
Disagree. You don't need to be a breaker to learn how things get attacked;
being a fixer also works. I've broken a few things over the years, but I've
learned far more by fixing things in FreeBSD which everybody else has broken.

(Maybe you don't think I'm a good secure developer, though.)

~~~
tptacek
By definition, fixers aren't leading; they're reacting to what the breakers
do. Also: you're a breaker. Face it.

~~~
cperciva
Fixers are reacting, sure, but they're probably reacting to far more
vulnerabilities than any one breaker could find. And reacting doesn't mean
that you can't be leading -- it's entirely possible for someone to say "gee,
OpenSSL seems to have lots of security vulnerabilities, maybe we should avoid
using OpenSSL" and thereby pre-emptively immunize themselves against a wide
range of yet-to-be-discovered breaks.

As for me being a breaker... I'd say that my security-related time is split
roughly 90% building, 9% fixing, and 1% breaking.

~~~
tptacek
That's how you spend your time _now_.

~~~
cperciva
No, that's how I spent my time when I was FreeBSD Security Officer. Now
there's more building.

------
musashibaka
This is a good article, with links to good resources for those interested in
security. One good place to learn is IRC. I must say though that a better
title would have been, "So, you want to get into Computer Security..."

------
lgieron
On a related issue, I'd like to know if there's market for security (mostly
appsec I guess) freelancers working remotely? The area interests me, but I
have limited time I could contribute to it if it were only a hobby; OTOH, if
it could one day transform from a mere hobby into a marketable skill, I'd be
much more inclined to make time for it (The "remote" part of my questions
comes from the fact that I don't think many interesting jobs will be available
in my area, so remote's the pretty much the only option).

------
sodelate
i wanna be

