Slashdot Mirror
Ask Slashdot - Breaking Into Penetration Testing At 30
An anonymous reader writes I currently work for a small IT MPS in the Southern USA. Recently, my boss approached me about offering security evaluation and penetration testing to customers in our area due to the increasing number of regulations companies area are having to meet. My role in the company is that of a proactive systems administrator. I have strong troubleshooting skills, a moderate knowledge of Linux, and a strong grasp on Windows systems. My working knowledge of networks is a bit rusty, but I've started working on my CCNA again, and skill/knowledge of any kind of programming language is extremely lacking as I have slacked off in that department. However, I've been working with Powershell scripting, and have picked up some resources on Python. Where would a guy like me start? What can I do, as far as personal development, to give me a shot at building this "new department" within my company? Am I beyond hope?
Have you run Nmap.exe ever? If yes, you are a fully qualified security expert.
Seriously, nmap should let you find an unpatched internet facing system. Then you have a vulnerability to point at. Instant cred.
Enough for you to learn while being paid.
John McAfee 'It was like that time I hired that Bangkok prostitute; to do my taxes, while I fucked my accountant'
At 30?
You're young.
Do whatever you want.
Your employer is going to be held liable/accountable if you miss a glaring hole in their information security infrastructure. I'm not saying you can't train to do this but I don't necessarily know that it's the kind of thing you can pick-up on the side or over a few weekends. I've dabbled in security over the years, am very familiar with *nix, worked in infrastructure as a sysadmin, am a fulltime well paid programmer and I am familiar with the variety of tools out there and I wouldn't consider myself for a role like this one. Too much risk.
I think penetration testing requires pretty good programming skills, particularly low level type stuff.
The fact that you have not maintained any programming skills suggests that it is not something which interests you sufficiently to pursue it in your free time. I am skeptical that a person without an intense curiosity to understand how systems work at a low (i.e., code and assembly level) would find the motivation to develop the necessary programming skills and reverse engineering know-how to discover holes in systems.
But perhaps I am wrong and these skills are not required to be a successful penetration tester.
Why would it? Pen testers jobs are not to write vulnerabilities. True, someone who knows how to write vulns will make a pretty good pen tester, but you don't need to know how to refine petroleum to be good at pumping gas. A basic pen tester needs these skills (in this order): 1) knowledge of current vulns across a wide variety of platforms, and a channel to keep up to date on the latest new vulns that come out, 2) knowledge of how to find if a vuln is present across a variety of platforms, using methods that don't involve "just give me root so i can check your versions" and 3) knowledge of how to actually run some/all of the exploits when the customer looks at your report of 13 high risk issues in disbelief.
To be a great pen tester you need one of two skills: programming knowledge to put together unique exploits on the fly, or diverse systems knowledge to know how to multiply existing vulns (exploit, pivot, repeat) in order to move from system to system.
Probably the most important thing is to have the mindset for penetration testing.
You are no longer trying to keep things up and running, and making systems usable; you are looking for all of the ways to make things break in new and interesting ways. You have to think creatively - you have to think about what the system/network admin missed and/or how "best practices" fail in a given situation/on a specific system.
That's why a deep technical understanding in a lot of areas is very helpful - you learn how things interact, and how failures can occur in different areas. For example, does a software package add a user? Does it open a network port? How does it handle permissions? How is authentication done? How do systems rely on the network? How does the network rely on various systems (like a DNS server)? The more you know about all of the interactions between the system(s) and the network, the more attack vectors you can come up with.
Reading code is like reading the dictionary - you have to read half of it before you can go back and understand it.
It's useless to learn pen testing... unless you also learn "pen fixing".
It's totally useless to know that there are problems there, but now how to fix them.
It's like going to a doctor, they tell you they have bad news and good news. The bad news is that you have cancer. The good news is that they scored 5 under par during their last round of golf. The second piece of information doesn't help resolve the first one. Unless you treat any disease you find, you haven't helped them, you've only made them feel like crap about something they can't do anything about on their own.
Typically, you want a "defense in depth" strategy, which means firewalls, DMZs, the whole nine yards. But learning how to use script kiddy tools to get in is not going to teach you the skills you are going to need if you want to keep someone else using those same script kiddy tools out.
It takes an almost entirely different mindset, and it does, in fact, take real skills -- almost the same skills you'd need to write those tools yourself, in order to write the code necessary to fix the problem so it can no longer happen. In other words, you not only have to know how the tool is getting in, to keep the tool from getting in. This can require substantial knowledge in systems and network architecture, and, if the way the tool happens to get in is via SQL injection, cross-site scripting, etc., etc., you will likely have to *minimally* know enough about the technology that's being exploited that you can fix it.
This is not the job for a single individual; it's a job for a team of at least several people (if they are incredibly good), or potentially a *lot* of people, if they are individually specialized to the point of being narrowly focussed in being able to go deep in only one or two areas.
The best advice I could give you is advice you are no longer able to take: learn this stuff while you are a minor, and unlikely to be put away for a felony, or learn this stuff prior to the electronic trespass laws going into effect in the mid to late 1980's. Both of these mean you've missed your window on getting a broad base of experience on a lot of disparate systems, of the type you'd be asked to pen test (or subsequently "pen fix").
Unless you are really wealthy - or your company is - and you are able to set up a lot of systems which, when you hack them, there's no risk that you'll end up in jail.
Other than that - there's some training available, but if you want to fix the problems you find, you have to think about systems as a gestalt, and you'll have to learn about networking and at least some types of programming, probably in considerable depth, to make up for your inability to legally acquire breadth, and then hire people to get breadth on your team.
Alternately, realize what I did the first day of kindergarten: I didn't want to go back after the first day "because they would not give me reading, writing, and arithmetic". In other words, this is not knowledge that someone can gift you with, it's knowledge that you'll have to fight to acquire, and it's not going to be easy for you.