Before we start to get to the main point, I want to use an example so it’s easier to understand for the non-tech head audience.
Computers like an axe is a man-made tool to make our life easier. I’m using an axe as an example since it is a simple tool with 2 parts a blade and a handle. Now as a security researcher you will have to jobs, protect the axe and protect those who use it. If you don’t have an experience with the tool you won’t know what to do, but an experienced security researcher would recommend to put it a dry relatively cold place because water can oxidize the metal blade and extreme heat could cause the wood to burn or water could damage the wood. Now for protecting the user you would put a plastic cap on top of the blade. We know this because we experienced being hurt with a sharp blade and also understand the physical and chemical characteristic of the metal and the wood.
Now image if an axe was invented last week and your job is to protect both the user and the product.
In the computer security field, you have to understand the language that was used to make the program or an app used by the user. If the programming language is a high-level language you have to understand the language that made the language before getting hired and after getting hired you have to use the axe (in this case an app or website or …) in any and all way possible to see what are the possible ways that you can hurt yourself or the product being damaged. Also, the product may not be a simple thing as an axe, it usually is a complex multi-part code which usually involves you using all the features of the product and after you are done reading the code multiple times.
There are many reasons why a security researcher may get hired:
1) after a known attack, you have to patch the product the narrowest timeline and get the product online as fast as possible.
2) be part of a big company where it’s more like proofreading a 5 years old English essay.
3) being part of a start-up. Which is the most difficult
People usually prefer being a security researcher for a startup, it has big rewards in the lowest amount of time but also not only you have to read the code and make sure everything works fine, but also check all the new features daily as they are being added. People on the start-up many now have enough experience coding so you have to try to understand awful codes at a time and fixing a bug in a function that was never used or gets removed the day after. And finally we get to my nightmare: use of multiple APIs that sometimes does similar things the worst of all using APIs in beta.
Why those being a security researcher pays well? Because it has a lot of stress, risk (if you are working with banks or something important like money) and people who are good at their jobs come only with experience and not an ethical hacking certification.
How to become a good security researcher: never stop learning new languages or updating your knowledge or the ones you know. Put yourself the shoes of the hacker. Try to think evil and see what will motivate people to hack something. It usually comes down to money, fame, or curiosity (hacking something just to know if it’s possible or not.)
Now a few tips for my fellow now or future security researchers working with a new group.
have everyone use the same coding syntax
never use a beta API and always consult other team members when implementing a new one.
ask everyone to have a weekly or monthly code clean up, a day you focus only on making the already existing code better smaller, more understandable, removing unused functions and … (like house cleaning) it will remove a lot of headaches and hassles later on.
don’t be afraid of refusing a job because if you can’t work with the people, not familiar with the type of language or tools being used, it may have a blowback that may ruin your career.
Dictionary by example:
function: a + sign is a function adding numbers together.
bug: a problem. I debugged that code. I fixed a known issue in the product.
beta: an unfinished product
API: application programming interface, a set of tools. let's say you are making a car but you are buying an engine from someone else, you could say you are using the-the API example.
APIS: more than one API