Advice for getting started in penetration testing
This post is a result of an email exchange between me and a young professional looking to get into IT security in general and penetration testing in particular. After taking the time to write up some advice to answer his questions and give him some insight into my own path to where I have thus far arrived, I figured it might be useful for others, as well. The text is largely unedited, only tweaking a couple things to make them more generic than the private email.
—My journey—
My journey was a bit indirect, but for the most part the various work I did helped me to get where I am today. I worked as I made my way through school, so I was getting the theory and the hands-on experience at the same time, through most of it (I also finished my degree years ‘late’ as a result).
I started in residential technical support for a local ISP near where I grew up. I picked up a few technical skills but went into that one with most of what I needed in that regard from tinkering with computers as a hobby. Looking back, the main thing I developed in that job was customer service skills: the ability to handle customers of varying technical abilities (often little or none), to guide someone over the phone and walk them through, step-by-detailed-step to achieve a certain goal. To help them understand when they seemed to want understanding, or to pick up on their impatience and just try to make things as short and sweet as possible. Also, how to handle irate customers who just wanted to yell and vent. Adjusting to the audience is a skill I still use, even though my job is very different, today. I also got practice at documenting details in a ticketing system and the ability to speak and type at the same time, which was a trick at first.
After that I worked a number of different positions for a small MSP/VAR company that was also local to where I lived. I started in their NOC, where I got my first real hands-on experience with Linux and with Cisco gear. I dove into basic support and configuration on Cisco before I had taken any formal training on it, and that ended up leading me to add some Cisco electives to my studies, which resulted in my earning CCNA and eventually CCNP. I consider CCNA (and subsequently, CCNP) a solid foundation for understanding networking fundamentals, which is absolutely critical to success in the IT security field in general, and the penetration testing field in particular. Short of social engineering, there is no testing task I perform that does not benefit from my thorough understanding of network technology at layers 1-4 (and 7) of the OSI model.
Back to my history, at that company I spent a year or so in the NOC picking up some more technical and support skills (similar to the ISP tech support, but more advanced and usually dealing with technicians rather than end customers). It was more hands-on but still involved taking phone calls and documenting details in a ticketing system. I got exposed to a number of different technologies that helped round out my understanding of different systems.
After that I worked for the same company as a project manager for about a year. That was a really interesting lateral step outside of my career path, but it did offer me some valuable insights. I learned the complexities that the “non-technical” side of a major project has to deal with, the importance of coordination and logistics, and solving problems with limited or conflicting resources among a shared pool (e.g., one PM needs engineer X on Friday, but another PM does, too).
From there I moved into the network engineering team within the same company. That was a more advanced position back in the technical workflow. Complex problems that couldn’t be solved by the NOC were escalated up, and the engineers were responsible for configuring hardware for deployment (either based on existing config templates, or by coming up with new configs to meet a certain design requirement), and in some cases managing and maintaining systems. I got a lot of hands-on time configuring Cisco gear from scratch, building Windows and Linux servers for deployment, and remote management of a Windows domain for a customer of ours. That last one was where I learned the importance of IPMI interfaces on servers.
While I was working as network engineer I picked up my CCNA, and shortly after that I moved to another local company that did not provide services to third parties, but rather had an in-house technical engineering and support group for its own remote store locations. I configured Cisco hardware (routers, switches, ASAs) for remote deployment to units, worked with remote techs over the phone to install the hardware, and helped store managers with troubleshooting when things weren’t working right. I also helped to optimize the configuration process for our equipment based on various different configuration profiles, and I spearheaded a configuration migration project from the Cisco ASA 8.2 to 8.3 code, which included some scripting to translate some major changes in syntax with regard to how NAT was implemented on the devices. I learned a number of things from that job, but my main takeaways were a better understanding of the value of the skills I had developed (protip: talk with others who are peers to you and don’t be afraid to ask how much they make, if they are willing to share the info), how to deal with “deadbeat” team members, and knowing when it was time to give up on a company and start looking for greener pastures. It was while working there that I accidentally discovered my love of IT security: on a lark I took the CCNA security class as an elective, and it was the first time I remember reading a textbook for a class where I had the “That is SO COOL!” feeling while reading through some of the material (it was the section on VLAN hopping, as I recall). I immediately got interested in security and started focusing on those elements of the job I had, working toward a better understanding of what the Cisco ASA platform could do as a stateful network firewall.
From there I went to work for the local county government that the city I lived in was part of. I worked in their IT security team and was primarily responsible for managing Palo Alto Networks firewalls. It was my first exposure to those and to this day I maintain that they are some of the best next-gen firewalls available. They are quite expensive, but at the time they had the most robust Next-gen firewall package hands-down. Check Point has caught up with them to a great extent, as I understand it, these days.
That work environment was, unfortunately, not the most conducive to my professional growth. It was stifling since the majority of my “peers” were 50-60+ and just waiting around for their pensions to retire. It was very much a “don’t rock the boat” environment, where 90% of the work was performed by 10% of the people, and trying to bring about major changes was difficult to impossible. Frustrating for a young and eager IT security guy who wanted to make a difference :) I did make a lot of progress on completing my degree while I was there, and I got some good experience in networking and communicating across functional units within a very broad, diverse organization. I was involved in selecting a SIEM product for the county, working through a methodology to identify requirements, comparing different solutions to determine which best fit the requirements, and presenting my conclusion to the management structure within the county. I also got first-hand exposure to the importance of “who you know” in finding new and better jobs. One of the biggest steps I took in furthering my understanding (and improving my job opportunities) was studying for and earning my CISSP certification during this time. The CISSP is the “inch deep, mile wide” approach to understanding IT security, and while it has a number of concepts that are not immediately valuable to non-DOD professionals, its approach to helping paint the “big picture” is invaluable in developing a solid foundation on which to learn, and in communicating with other security professionals and understanding the specific concepts that are meant by certain technical language. Some professionals in the pentesting space will rag on the CISSP, and to be honest its value has been diminished over time since ISC2 has lowered the bar on obtaining it, but there is still valuable information that you can learn from in obtaining it. Eric Conrad and Seth Misenar’s book is second to none, when it comes to materials to study for the CISSP.
It was while I worked there for the county government that I met some members of the team that I would eventually end up working with in my current company; the county was a client of a third-party security assessment and penetration testing company based in a neighboring city, and I was very impressed by the work they performed. Some other events transpired in the background that ended up with me and my wife moving to that neighboring city (something we had wanted to do, but needed the right opportunity to do so), and my manager at the county mentioned conversationally to that third party that I was moving nearby. He effectively put in a good word for me, and they were looking for a new consultant at the time, so I interviewed and ended up getting the job I have now. It’s who you know.
In this position I started out as a hybrid assessor, performing risk assessments of a non-hands-on nature, with a plan to later begin hands-on penetration testing. While it is something of a side-step from my goal, the non-hands-on work has been very beneficial in helping to flesh out my understanding of the big picture. I am fortunate that my company values formal professional training, and since I perform well they have sent me to SANS training courses to further my training. That willingness can be hard to find, and is worth its weight in gold. After taking a penetration testing course at SANS (SEC-560 by Ed Skoudis, who is an amazing instructor and all around awesome guy), I have gradually (through persistence, and the support of my management) begun doing more and more hands-on penetration testing and social engineering. I’m now about 50/50 in my time between pentests and risk assessments, and slowly working toward more focus on pentests as my primary function.
So that is my journey, so far. Hopefully you found it somewhat interesting and useful to gain some insights.
—Tips for an aspiring pentester—
As for tips, I’ll just rattle off some things I have found useful and valuable, in no particular order:
Read all the things. Don’t limit yourself to only the technical resources out there, as having a well-rounded understanding of security and risk makes you a much more effective tester, and makes you more valuable as a consultant or to a potential employer.
Some of my favorite security websites:
Get on Twitter. I resisted this one for a long time because I didn’t “get” it, and only VERY recently learned the value of Twitter. The level of direct access that it grants to people you might otherwise never encounter is invaluable, and it moves FAST when major breaches and events are going down. Now that I have a good web of IT folks to follow, I typically hear about new breach events hours or even days before they make it into security blogs/websites. A good place to start is to look up SANS instructors, follow them, and then start following people they follow/retweet. Don’t over do it since you can flood yourself with too many tweets to handle, but having a reasonably wide net gives you access to tons of good insights from people living in the biz, and you will meet some great people. I recommend having an account that is just for infosec, so if you use it more casually or with friends you can keep those accounts separate and avoid any embarrassing retweets that are way off topic showing up on your feed.
Tinker. In order to learn you will have to put in the hours in your spare time, at least until you land your dream job. There are plenty of good guides on how to build cheap or free home labs for playing with different tools. If you get really serious you might pick up some hardware that is a little pricier down the road, but to begin with you can run a couple of VMs (one for attack and one as the ‘victim’ to exploit) and get lots of experience in a safe, controlled manner.
Participate in CTFs and both online and offline practice labs that are available. There are some great free sites that teach web app pentesting, some vulnerable VMs that you can pwn offline, and multi-player competitive CTF contests that you can participate in once you have some knowledge under your belt. It’s a huge list, but Aman Hardikar’s mind map on practice labs is the best compilation of different such resources I’ve found. Explore them, find some you like, and learn. Approach each one first as a “closed box” and see if you can do it without hints. If not, make use of whatever hint/clue system is provided (some, such as Mutillidae, have tutorials built in, while others require you to look up other people’s walkthrough blogs for help on solving them). Use them for what they are: learning resources. The point is not to “win,” but rather to further your understanding so that if you encounter a similar scenario in the real world you can use what you have learned in practice. Then later you can play to win ;)
Last but by no means least, read the CFAA Read the wiki article and then the full text. It’s important to understand the legal implications of this field and to comport yourself in a safe, mature, respectful, authorized, and legal manner. The codes of ethics from various certification bodies (ISC2, EC-Council, SANS/GIAC) are also important to read and understand. As you become certified, perform research, and get into working in the field, you are an indirect representative of those bodies, and have to conduct yourself accordingly. It also helps keep you out of trouble.
A bit lengthy, but at the same time nowhere near exhaustive. I hope that you find the above useful and informative. Feel free to reach out to me with any suggestions, questions, or comments.