Ask HN: Can you get into security research self taught?
The word “research” tends to evoke ideas of long, expensive academic careers you have to put in until you can be considered qualified for industrial R&D type roles. But security research seems to be orthogonal to many fields that tend to focus less on credentialism and more on proven past ability. It’s not uncommon software devs, other security roles, etc. to be able to break into to their respective fields self taught so is it possible for security research roles?
If so, how difficult is it to self teach this sort of stuff and how long would someone with a cursory understanding of exploits, security, etc. to be “ready” for a industrial role in this field. I get that’s a very open question, with widely varied answers based on individuals, but for comparison, it doesn’t seem to take software developers that show existing aptitude for the field very long to have the potential for productivity in a industrial setting. Hell there are entire industries around pumping out new programmers in 6mo-1y, and while they may not all be top of the line, if good at all, getting your foot into the door seems to be the biggest step into separating those who are and getting them into the right track.
23 comments
[ 2.4 ms ] story [ 46.3 ms ] threadLong story very short: if you like systems that much, get out of the security industry and become an engineer in an area that excites you.
There are exceptions (1337 low-level programming hacker in the security industry) but they're rare enough that you and I aren't likely to be one.
I phreaked more last year than I ever did as a kid since I got back into telephony, set up phones, and started scanning.
Then not long after I realized that I probably would not learn much unless I bag enough positive engineering experience under me. A few years of Windows system programming is pretty much needed.
What I find a bit more useful is to find malware analysis and especially articles that examine the _methods_ malwares use with simple examples (e.g. Process Hollowing is used by some malware, but if you are to read the source code for that, good luck, it's a lot easier to read a blog that explain what it is and how to do it in a naive way). But even those are not easy for a layman so I figured I' still far from the doorway.
I'm getting into a Graduate Diploma of Computer Science in my late 30s so it's more as a hobby than a career. While the department is out of top 200 of global ranking, I did get A+ on Comp Arch and am going into Advanced Programming which is based on C++. From the few malware reports that I read and can understand a bit, malwares in general don't deal with sophiscated algorithms,unlike in the business of Database Engine development. I only have a shallow deeling but they seem to care a lot more about hidden entries, side-channel attacks or even upstream attacks (Solarwind). And there are a LOT of vectors to approach.
This further confused me so I figured it's better for me to concerntrate on the fundementals a.k.a. general programming (problem solving in general but not really focused on leetcode style questions), computer architecture and assembly language, compiler theory and operating system. How the operating system load and execute code and how does virtual memory and processes work, these kind of things.
It feels very much like a detective job in which one needs to reverse engineer the motives and etc. In the meantime, although the detectives are not suppose to commit crimes (positive engineering a malware), he/she must learn all those tricks to fight the criminals.
BTW kudos for whatever you achieved :D
Anything that you picked up in particular from engineering school that was more rigorous than what you could glean from Phrack or txt files?
I would've thought phreaking was a dead art after the move to digital phone systems and VOIP. Any way for someone interested in 21st century phreaking to get started?
I never used a blue box (I was not that advanced as a teenager). I made and used less-cool boxes (red, beige) in the 90s. Blue boxes theoretically still work in some countries, but not the US (even the last 1AESS was removed a few years ago, and that was a digital switch.)
There are (or very recently were) MF trunks with in-band signalling to overseas locations that could be boxed... but the owners of the trunk(s) knew that risk and so used a very non-standard method of signalling that would be hard to figure out. I'm talking about this year, even.
The cool thing about phreaking now (just scanning, really) is that the traditional (POTS) phone system is dying. So it's like exploring ancient architecture. There's a ton of stuff out there to find. Just get an account with a provider like voip.ms (much cheaper than AT&T or other traditional POTS), install Asterisk and hook up a retro phone to it, and dial around randomly.
About school: One can learn to program or hack (even well, if they have the knack) from text files. I went to engineering school about 1.5 decades after the "hacking" career and it's a completely different approach to knowledge.
For example I remember picking up a tech manual for a radio at the age of about 20 and seeing a bunch of 'cos' and 'sin', knowing they were trig functions and related to radio, but not understanding what they were actually getting at with their description. It was just "deep and probably irrelevant" in my mind. Now I can understand (to some extent) those kind of things.
Engineering school provides a lower-level understanding of the world, just as assembly language provides a lower-level understanding of the machine
Work at a security company. Everyone I know with "research" in their title is legitimately great.
That being said there are different types of security researchers. It seems like you were focused on vulnerability research/exploit development/offensive stuff. There's also malware analysis, intelligence, and detection research.
Just like exploit development, malware analysis requires reverse engineering skills. However, Intelligence analysts and people doing detection research often have incredibly deep and broad skillsets that don't involve knowing assembly or C, yet they are still doing amazing work. Some of them are also reverse engineers, but depending on the role its not the standard by which I would judge competence.
I've seen orgs that hire mostly bureaucrats, but if a person has genuine passion for security they can find a fun and challenging place to work.
I hear quite a bit about security companies/large companies with mature security programs trying to build services/products that utilize AI. FireEye/Mandiant, Rapid7, Palo Alto Networks, Microsoft, Apple, Google, Talos, would probably be good places to look.
Two more questions: a) Is it possible to get domain specific experience without getting into an cyber security role? b) Did you mean to say that Companies will be open to hire non-Cyber Security folks due to the high number of vacancies? I am sorry. I did not understand what you meant.
Thanks a ton!
In fact the job you posted says this:
"Passion to the cybersecurity is mandatory, though no previous experience or knowledge is required"
I'm an Application Security Champion (ASC). This is very true. My job is basically filling out paperwork, scheduling meetings, and stuff like that. Of course this is only a partial role that is in addition to my regular dev duties.
I would say today it is both easier and harder. It is harder because the body of knowledge is so much larger, it is easier because so many more materials and exercises are available.
From my perspective, and I lead a team of these security researchers, it is an advanced career path, and still requires a lot of self-motivation. That said, there are more and more definitions of what "security researcher" means, in some cases it means being able to find web vulnerabilities without using Burp, so YMMV.
I would suggest to focus on fundamental skills such as reverse engineering, code review, low-level languages such as C and assembly, interfacing at a low-level with binaries through debuggers and instrumentation etc etc. Those are all broadly applicable. Playing CTF games is a good starting point too, as is auditing open source software.
But make no mistake, it will be a challenge, and it will require tenacity on your part. Good luck !
I'm not trying to be insulting here, but you asking this here gives me the impression that you don't have that motivation. Because if you did, you would have sought this answer on your own. It wouldn't be the first time, I'm wrong, though.
Dip your toe in and see where it goes. If it's not for you, move onto something else that interests you. It's fine to explore.