> understanding data structures and algorithms doesn't necessarily correlate to one's ability to identify security vulnerabilities.

No, but it does suggest that you're likely capable of learning security work. Just like your data structure and algorithm knowledge didn't come for free, nobody is born knowing how to find security problems. You need to work for it.

What's a way to learn security work? Genuinely curious.

One of the best introductions to the field is going through overthewire’s bandit vulnerability games. https://overthewire.org/wargames/bandit/

They have 30+ levels where you ssh into a server and attempt to find some type of vulnerability. They start out very easy and get tough quick. It’s very eye opening to see the types of exploits that exist.

They also have a set of challenges aimed at serverside web security. http://overthewire.org/wargames/natas/ I went through the web challenges last year and they helped a ton in my web dev roles.

> One of the best introductions to the field is going through overthewire’s bandit vulnerability games.

Never knew about these. I'm visually impaired, so a text-based system like this appeals. Thanks!

> One of the best introductions to the field is going through overthewire’s bandit vulnerability games.

Out of curiosity I visited your first link and played the first dozen+ levels. It's just been bash-fu and occasional man reading/googling. Judging by the subsequent level instructions I went through, there didn't seem to be much more in there. I'm like, if you really want to learn more about shell commands, there are man pages. Admittedly, a game is arguably a good way to tutor a lazy reader. Still, did I miss anything else in there by not finishing the game?

bandit is just the beginner intro to shell series that is meant for pure beginners to unix, you didnt miss anything. All of the other games on there are actual wargames to learn about security

In addition to other methods, never underestimate the importance of breaking stuff for yourself. Teenagers are often very good at this (partly because they have the free time and they don't care about the consequences).

Beside that lower level knowledge of how computer systems work is always worth studying up on.

I followed a couple of courses at the VU University Amsterdam. I'll tell you what I've learned about security, it gives you a couple of terms to type into a search engine at least.

There are 3 courses they give for it:

1) Computer & Network Security

2) Binary and Malware Analysis

3) Hardware Security

The lower level it gets, the better they are at it. Each course costs 1200 euro's for non-EU students. I recommend it.

I learned about (in random order):

- Rowhammer (I hope memory vendors will fix this)

- Cache attacks (I hope Intel will fix this)

- Stack smashing

- String buffer trickery in C

- Spoofing IPs

- DNS cache poisoning

- Using machine learning to fingerprint things

- Dictionary attacks for password cracking

- Portscanning

- Cold boot attacks

- Spotting vulnerabilities in C code

- Reverse engineering binaries with IDA Pro and knowing x86 and x64 assembly

- Taint analysis

- Instrumenting binaries with PIN

- Using SMT solvers to crack passwords in binaries

Is it remote and in English?

No, you have to be there.

Apart from the standard methods mentioned by other commenters, you can also play CTFs (and read past CTF writeups). The problems in CTFs are not necessarily reflective of the vulnerabilities in modern software, but it's a fun way to learn a lot of the tools and mindset involved in real security research.

I'm not a security expert by any means, but based on learning other niche-ish areas of technology, the following probably exist for security:

* Books

* MOOCs

* Lecture notes, slides, and assignments from university courses

* Subreddits, Quora topics, etc

* Prominent community members you can follow on Twitter

In my experience, security has much fewer of those resources. Most of the information seems to shared through word-of-mouth, conference presentations, and blog posts.

Much of the information is also just RTFM. I don't think it's a stretch to say that security is a lifestyle: if I read the documentation of an API, more often than not I'll wonder if something can be abused for something. Or when trying to register for health insurance, the password field required special characters, so I set my password generator to include them, after which the form broke, and so I investigated and found that I could inject scripts there. It's just stuff I come across when I'm not even trying.

Word of mouth, chat groups where things are shared, conferences, blog posts... yes, those are resources. But it's also just a whole lot of curiosity and poking at systems.

And experience. Knowing what to look for, even if it's just the HTML source of a web page, is rather important in the first steps of breaking the system. How do you learn what to look for? Well, certainly there are blog posts and even playgrounds with virtual systems and components one can have a go at.

Actual security expert^W dude here. On the topic of breaking/hacking things, I never read a book, followed a MOOC, or studied university course material, and I doubt most of my peers do that either. Which is not to say I don't use those resources, but they're for other topics like software development, system administration, or non-fiction books like Predictably Irrational[1].

The only security-relevant subreddit I'm subscribed to is /r/netsec, and sometimes interesting things come by, but I don't use it a lot. HN is more useful for (context about / following) big security events than netsec. Perhaps /r/sysadmin is also fair to mention, but that's more to see what's hot in sysadmin world (and get their perspective on breaking security news) than to learn about security.

Instead of Quora, I use the IT Security StackExchange site[2]: answering questions makes me dive into topics just a little deeper than what I already knew and I always come out knowing a few more useful details. The site has some really hardcore security people who are typically find any mistakes in your answers as well. I'd recommend that site a lot for learning, whether that is through asking or answering questions (though with answering, perhaps it's more to deepen knowledge than to get into the field), or even if it's just for getting correct answers to security questions like "What are the optimal WPA3 settings for a home router" or something.

So then, how does one get into security? Most people I know just started breaking things and noticed that others usually found it useful if we told them about it. After a while you'll have seen most of the common issues. Add to that some more structured materials like the OWASP top 10 and similar resources, and now I feel fairly confident that my reports are not just a haphazard collection of what I came across in previous years, but that I can actually give a reasonably complete assessment of the security of a system.

I don't know why the security field doesn't have as many structured resources as other fields. Maybe the field is just too small compared to how fast it moves? Or maybe security people are, y'know, as breakers of other people's systems, as hackers, as those who outsmart the people who made the system... maybe we want to be different and not follow norms by studying the normal way? And most of us just started doing it for fun before it became a profession, so few people would use the resources even if they were there? I'm just speculating.

[1] https://en.wikipedia.org/wiki/Predictably_Irrational

[2] https://security.stackexchange.com

Ironically, it's being curious on how to break something or how something that is for "A" can be used for "XYZ."

Though what you hear about more often are misconfigurations -- which, are valid, but that's more on execution vs truly finding something wrong.

I learned a tremendous amount from Root-Me [1], it has a strong community and is _often_ updated with new challenges.

1: https://www.root-me.org/?lang=en

no one mentioned it but the secret sauce is to have a "thing" for breaking and exploiting things. whether it's good or not is yours to decide. but here's my experience...

talented hackers, white, gray, black, whatever, excel at breaking and exploiting things. and people. and i have always struggled with that...

in college i took a computer security class. my class had the team ranked #1 in Maryland (US) among young coming up group of hackers. what i saw them do is always, and i mean always, thinking of ways to break things. i mean, well, it's broken a tad bit, adding this or that will fix it. no! i saw them exploit every little tiny thing!

i wanted to "fix" things. i wanted to be a "good" programmer. i was like: "oh they didn't do this, what should they have done to make more secure?". a good hacker was like "oh they didn't do this, what can i do to exploit it?"

i hope my little experience convey to you how they think. or at least what i saw first hand while taking that class. for me it's hard, i wanted to fix things. they wanted to break things. i didn't fail my class. i wasn't good at it either...

but i admire them and i am still amazed by what these people can pull off.

Beware survivorship bias, I wonder what the average hourly rate of bug hunters is?

Trail of Bits has a nice summary[0] on that (they're discussing this[1] book).

> As productive as the top 1% are, their earnings are equally depressing. The top seven participants in the Facebook data set averaged 0.87 bugs per month, earning an average yearly salary of $34,255; slightly less than what a pest control worker makes in Mississippi.

---

[0] https://blog.trailofbits.com/2019/01/14/on-bounties-and-boff...

[1] https://mitpress.mit.edu/books/new-solutions-cybersecurity

The Trail of Bits piece kinda ignores the amount of time invested however: https://www.techrepublic.com/article/bug-bounty-programs-eve...

I feel like there are probably a lot of easy targets available. Look at the network requests between the client and server and see if there is anything that looks like its not validated. If you see ids try changing them and see what happens. Quite often it seems that the back end just trusts whatever the client sends. Especially if its a mobile app or a SPA because new devs seem to think the api is only visible to them.

From reading some of these hacks on peoples blogs it seems like quite often they just man in the middle a mobile app and find out the api provides way more info than should be shown to the user and the ui hides it.

That is indeed a lot of money.

Not sure why there are not more people doing it. I thought about it as well for years but still don't do it.