I think the article overlooks the value of strong fundamentals. If you deeply understand a specific technology it's so much easier than if you have scraped the surface by learning the most common exploits. I find that books, courses and resources about security _specifically_ are often superficial and foregoes deep understanding and instead focus on shallow techniques, tips and tricks. Sure, the tricks are useful, but so much more if they rest on strong foundations.
For someone that just want to get a foot in the industry and be useful in some real world scenarios (where knowledge of the most common problems will probably be enough to find real problems) I think this article is a useful resource. But in the long term you will be better and more valuable to skip security resources most of the time and instead go deep in a wide set of areas.
Rather than working as a pen tester, I'd rather work on developing pen testing, auditing, intrusion detection software. A lot of security has been and is going to be automated.
And pen testing isn't a "sexy" job. Not amongst security and software developers anyway. I see on the same level as QA.
Having worked alongside pentesters, I can assure you that there is plenty of pentesting that is far more complex than QA.
There are already many automated pentesting tools, and those are a good first pass, and yes, they could improve much further and take more of the bottom end of the pentesting market.
However, logic vulnerabilities, hardware vulns, research against browsers and operating systems, malware analysis, and even advanced network and web security testing, are all far from being automated.
Good writeup! Finding bugs is just a portion of a pen tester's responsibilities.
- You need to have strong technical writing skills. Reporting for each vulnerability should include:
* Title
* Two sentence summary explaining the impact of the finding.
* Explanation of the vulnerability.
* Where the bug is (code if available).
* Proof of concept for exploitation. Clients may want a retest, ensure that the person reading the report can find the vulnerability quickly if need be! A quick explanation of how to navigate the app to the vulnerable page is useful.
* Remediation.
The reporting should also contain an executive summary, summary of overall security posture, and any strategic recommendations.
- Report patterns that can lead to exploitation, but are currently not exploitable, as informational findings. Are they copying and pasting security sensitive code throughout application? Recommend a useful abstraction in the remediation! You don't want to play wack-a-mole and try to find all locations to update these scenarios.
- Does the client have sufficient logging and monitoring capabilities to detect an attack? The client may be interested in knowing if the security team can detect an intrusion is or has occurred.
- Recommend automation when possible! A Continuous Integration System should automatically be scanning for out of date dependencies.
- Time management skills are vital. Is a finding really convoluted to exploit, and would take a while to develop a Proof of Concept? Save the proof of concept for the end of the project. Ensure you try and get as much coverage as possible during your available given time.
- Project management skills are important. Test credentials early, and request whatever else you may need as soon as possible (buffer up questions to avoid email spam). Double check to ensure information hasn't been given to you already. You don't want to wait until the last couple days to request additional access if possible.
This is a really good writeup for anybody interested in getting in the field. But, also a really good reminder for people who don't do security on a daily basis all of the components that go into keeping things secure.
>Now, being a Pentester doesn’t mean you only focus on one thing - such as Network Pentesting or Web Apps
I disagree. There are people who's entire jobs are just to break web apps (most banks probably have a couple on the payroll) or just to get into and around a network (though the latter is slowly becoming less common as network architecture is changing).
> It goes without saying that being a Professional Penetration Tester is one of the “sexier” jobs in InfoSec
I thought this was mostly the perception from people outside infosec. The vibe I tend to get from people within infosec is that pentesting is a low status specialization.
Depends so much. But yes, the good old "compliance checkers" who run a couple of scripts and call them self pen tester are very low on the lader. These are the majority nowadays.
People who can actually penetrate stuff "by hand" are considered sexy alright.
People who can actually penetrate stuff "by hand" do exist, and I'm one of them, but how many of us work for pentesting companies? I don't think the money is there, mostly, because clients are wary of buying snake oil and because clients don't actually need real live vulnerability exploits. The pentesting clients just need to close holes, or at least satisfy an insurance company that they did so. Pentesting clients want to certify compliance.
I put a "by hand" job posting in the "Who Is Hiring?" thread. Here: https://news.ycombinator.com/item?id=19543995 It isn't anything I'd call pentesting. We study software, not specific installations of software.
From personal experience, Root-Me is easily one of the best way to get into infosec for someone with no prior knowledge of infosec or even information technologies in general.
For someone that just want to get a foot in the industry and be useful in some real world scenarios (where knowledge of the most common problems will probably be enough to find real problems) I think this article is a useful resource. But in the long term you will be better and more valuable to skip security resources most of the time and instead go deep in a wide set of areas.