So you want to work in security? (and for some reason ended up here rather than reading other people’s posts on the topic).

A lot of people (including my colleagues from Google, Parisa and Michal) already wrote great posts on this topic, and I fully encourage you to read them. I expect there will be a lot of overlap with things already said, but every once in a while I get a question like this, so rather than typing something every time and linking to the aforementioned posts, I decided to write my own version that includes some of my own personal observations and experiences.

Take note that I’m an application security guy an am writing this from a vulnerability research / security review / bug hunting / hacking / whatever you choose to call it perspective. There are other career paths in security such as in secure development, malware analysis, infrastructure security and others with which I am not as intimately familiar and might not be the right person to give advice on.

So, who am I and why should you trust me with this topic? Well, first of all I'm not saying you should trust me because everyone’s experience and everyone’s path will be different. But just in case you are curious: I’m currently a member of Google Project Zero, I used to be a member of the Google Security team, I’m the author of several security tools and if you scroll sufficiently long down this blog (which hasn’t been updated in a while, see the GPZ blog for the most recent posts) you’ll see that I’ve been tinkering with this security stuff for over 10 years.

But my background is somewhat besides the point because people I know in security come from a variety of different backgrounds. For example, I also have a fairly strong academic background (with a Ph.D. in computing, having worked at an university a long time), but that is fairly atypical among my peers and certainly not a requirement to get into security. That is, of course, not to say that having any degree not useful and I do feel that my education gave me a solid foundation to build upon later. However, regardless of the education you choose or already have, there is one thing most of the people in security I know have in common, and here we come to the first tip:

Do stuff on your own

For the majority of people I know in the industry, security was a hobby first before it became a job. Of course, if you are just considering getting into security, telling you to do stuff on your own does not help you much without telling you how you can get started doing that. Keep on reading because we’ll get to that below. But first, one other thing you should be aware of (don’t let it discourage you, we’ll see how you can deal with it later).

Don’t look now but getting started is more difficult now than it was 10 years ago

I suspect not everyone will admit it, but security did improve rather significantly over time. Sure, if you dig enough you’re going to find pieces of software and hardware against which techniques from over 10 years ago still work. But take a look at, for example, web browsers. When I was working on my first Windows exploit (a heap overflow) I was getting frustrated because Microsoft recently introduced Safe Unlinking so generic well known heap exploitation techniques I read about no longer worked. 10 years forward and someone just getting started wouldn’t just have to deal with Safe Unlinking and stack cookies, but also SafeSEH/SEHOP, DEP, ASLR, CFG, ACG, a sandbox around every major browser and who knows what else. And it’s not limited to web browsers. If you take a look at the commonly used web application frameworks 10 years ago and now, you’ll also see significant differences in the security posture.

Don’t be afraid if the words in the previous paragraph mean nothing to you (yet).

So, how do you combat the increasingly steep difficulty curve?

Take advantage of the learning resources

While in general, the difficulty of getting started is higher, the fact is, there are also a lot more learning resources out there now than there were before.

But another word of warning: You need to be able to go out and learn on your own. Nobody is going to hold your hand or be your mentor (there might always be a master and an apprentice with the Sith, but it rarely works that way with hackers). If you prefer to follow a pre-set curriculum (like admittedly I did for the large part of my education) you’re not going to get very far in security.

Before you can get to the right learning resources, you need to start asking the right questions. Googling for “how to hack” and similar is still going to result in the same bullshit now as it ever did. Instead, try asking more subtle questions like:

1. How does this piece of software/hardware I’m interested in work? What technology it is based on? Is there source code I can read? Tutorials? Books?

2. Did someone already manage to break this piece of software/hardware I want to break? Did they publish writeups? Exploits? Conference presentations? Do I truly understand what they did?

It follows that you yourself must be rather technically savvy to understand how a real-world piece of software or hardware made by someone else works. While writing code and reading code are not exactly the same skills, there is a significant overlap so if you are not comfortable coding, this is something you might want to improve before digging further into security.

Don’t forget the second point. While I was reasonably good when it comes to technical stuff even before, my understanding of security didn’t come until I started reading vulnerability research and exploits published by other people.

Yet another word of warning: Don’t give up when you encounter things you don’t understand. Especially when getting started and reading various resources you’re going to encounter a lot of it. Skipping those parts is the easy path but it is also the wrong path to take. Instead think of encountering every bit of information you don’t understand as a clue about what else you need to learn.

Although I wrote that nobody is going to hold your hand, that doesn’t mean you should not ask questions. In fact, you should feel free to. People won’t do your job for you but they just might give you a nod in the right direction if you get stuck.

Use Twitter

Seems strange to endorse a specific social network, but the fact of the matter is that a lot of security community uses Twitter to share news, but more importantly links to recent research, vulnerabilities, PoCs, conference presentations, source and the like. I don’t really know how this came to pass, perhaps it’s the short message format that is more convenient for people to share links to resources without getting (too) encumbered by unnecessary long discussions. So find people on Twitter who work on or publish stuff you are interested in and check out what they tweet.

Besides Twitter, some other places you can find interesting resources are r/netsec and Hacker News (though it carries other stuff besides just security). Check out also presentations and recordings of talks from security conferences (there is a lot of them, but not all of them are good. Focus on the more technical ones).

Playing CTFs is a good way to learn

Another strange advice for me to give as I myself almost never play them, but remember what I wrote about the difficulty curve? CTFs can make your learning experience more gradual because challenges come in various difficulties (you can usually tell by the number of points each task is worth) so you can start with the easier ones and then build up from there. For example, sometimes there are exploitation challenges with some of the mitigations turned off. There is also some comfort in knowing that there is a bug / way to solve it.

There is a CTF somewhere almost every week, most of them can be played remotely and you can find the schedule here. If you fail at solving a task, don’t forget to check out the writeups from the people who did solve it.

CTFs can be a pretty gratifying experience but once you get better, don’t be afraid to go out and try yourself against a real-world target. You might surprise yourself!

Oh, and when it comes to real-world targets:

Don’t be afraid to fail. A lot.

Especially these days, vulnerability research can be a very frustrating experience. Most of the things you’ll try won’t work and you need to come to accept that, but don’t let it discourage you from trying it anyway. It doesn’t happen just to you, it happens to me and it happens to other experienced researcher as well. But it's easy to think it happens only to you because, after all, what you end up seeing from other people are their successes and not their failures. The important thing is, if your idea fails, learn why it failed before moving on.

You are smarter than you think (conversely: other people are not as smart as you think)

This might be a controversial point because other people gave advice along the lines of “you are not smarter than the developers”. While this is true in general and good advice for a lot of people people already in the industry, it might be the wrong thing to say to a lot of people who are just getting started or are just considering getting started. The thing is, after seeing what other smart people do, without having done anything in the field yourself, it is easy to doubt in one's own abilities. Let me give you a personal example:

It might sound strange to you now, but when I started doing security as a hobby I thought I was never going to be “l33t” enough to find bugs in Windows. And I might have never tried, except I found my first Windows bug by accident: I was fuzzing some crappy image library and after a while I had some samples that caused crashes. And when I accidently clicked one of those crashing samples in Windows, Windows Explorer crashed - and that was CVE-2008-3013.

Another case in point: When doing a review of a piece of software, you might have an idea and then think “nah, that’s stupid, the developers surely thought of that”. The thing is, they often haven’t. To be fair, that’s not because they are stupid, that’s because they thought about other problems at the time. But if the mindset of “I’m smarter than them” helps you break through the artificial limitations you set for yourself, then use it and to hell with being humble.

When you’re talking to other people, especially developers, then it is the time to drop it though. You’re going to have a much more pleasant time interacting with people if they’ll see you as someone who wants to work with them rather than an adversary. This doesn’t mean trusting whatever you’re being told though. Remember, they are the experts in their code, but you’re the expert in security.

What do I do once I’m ready to show my skills to the world?

To start with, you can do that while earning something at the same time: A lot of companies, both small and large offer bug bounties for skilled researchers who find bugs in their product. Google has it, Facebook has it, Microsoft has it as well as lots of others.

Even if you’re looking at something that doesn’t have a bug bounty, but it’s something a lot of people use and care about, finding a bug in it can be a nice way to showcase your skills and writing about your research can help other people get started as well as get you noticed.

While it sometimes gets disproportionally large amount of attention, publishing vulnerabilities is not the only way to contribute to the community - creating useful tools, doing defensive research etc. are cool as well!

What else do I need to know?

A life of a security researcher might not be as glorious as you imagine it. You’re going to sit in front of a computer. A lot. So if you find the idea of that off putting this might not be the right career path for you. It is also quite intellectually challenging and is pretty much the opposite of a routine job. Which means it can be quite rewarding, but also quite mentally exhausting.