As a fresh graduate I'm wondering what my chances are of joining a great pen-testing group. Is there a risk that a career in pen-testing may one day not be needed? If so, how applicable will skills from a pen-testing job be towards getting another job in the IT field?
I think it would be hard for security to be much less of a concern than it is today. The state of computer security is pretty abysmal. The research community is pretty good and there are lots of people out there that do know what they are doing, but there are far more who do not or simply don't care.
Meanwhile, as attackers become more and more technically advanced, it is going to become more and more of a risk to businesses, so the need will only increase. The only real issue I could see happening is that there may be a bubble for a while as everyone starts trying to get their legacy systems more secure after which it will only be maintenance, but there is always going to be a need for info-sec as long as there is IT.
As far as within IT, the skills for penetration testing are going to be useful to IT and other Info-Sec stuff in general, so I don't see too big of a risk going in to it. (I also don't expect it will become a minor part of security at any point in the near future, but it's good to know that a lot of the skills are still useful.)
A Little Background
Penetration testing probably feels like the sexiest part of security, but it is also a very small part. It's also exceptionally broad. The term "penetration test" is often used as an umbrella to mean any one of the following:
- Vulnerability Assessment
- Security Assessment
- Security Audit
- Penetration Test
- Social Engineering
It could be argued that exploit development is actually outside the scope of the term, even though in some engagements custom exploit development may be performed.
Just so we're on the same page, let's do a very brief description of what I mean by each of those.
This would be the real world version of peaking in windows and rattling doorknobs. In this type of engagement the tester will be given, or attempt to determine, the architecture and analyse it for weaknesses. We'll look to see what services are running, what versions of the software those are, attempt to figure out how things are configured and connected together, how the services are used, and what security protections may be in place.
Taking all that information we'll identify potential weaknesses and report on them. This may include findings relating to out of date software versions, weak configurations (such as using HTTP when they should use HTTPS), no of insufficiently restrictive firewalls, etc.
The idea here is to look for problems and report on them, not to actually break into systems.
In most cases a security assessment is a complete vulnerability assessment followed up with a policy and procedure review. This will allow the assessor to judge, not only if the procedures are in line with policy, but also whether the business unit's workflow needs tightening up. This is important because a technical vulnerability assessment won't reveal whether or not sensitive files are routinely stored in unlocked file cabinets in the main lobby, or discarded in the normal trash.
Audits can be very similar to an assessment, with one major difference. An audit is a strict formal test against a pre-determined standard or set of standards. An assessment may use standards as guidelines, an assessment report will include anything the assessor feels may be a weakness. An audit, however, is restricted to testing ONLY THAT WHICH IS DEFINED IN THE STANDARD. The intent here is that an audit is very formal, repeatable, and predictable.
Some audit reports may include additional, or informational, findings very reminiscent of an assessment. There should not, however, be many of those. They should not be binding, and they should be used to inform compliance against the tested standard.
This is effectively a more thorough form of a Vulnerability Assessment. Once the tester has identified weaknesses they will then attempt to exploit those weaknesses. This has two major advantages:
- It helps determine whether the findings in the assessment are false positives, such as the case of a software version that should be vulnerable but contains backported security patches.
- It tests the vulnerabilities against mitigating controls.
It is one thing to have a finding that the company's ERP solution is a year behind on patches, it is another to demonstrate that being behind on patches allowed an attacker to retrieve payroll information.
Unlike a security assessment a penetration test will not usually involve a policy/procedure review.
During a social engineering engagement your team will attempt to con or infiltrate the organization to ex-filtrate information. This is where you get into the types of things you'll often see in spy shows or movies like Sneakers. You'll probably do some dumpster diving, attempt to create (or steal) badges, talk your way past security, pose as the CEO and attempt to convince the help desk to change your password, etc. This may or may not be included as part of a penetration test.
What All This Means To You
In the end, all of these things require specific skills. Some of them are technical, some of them are personal, some of them are organizational. Your best bet to break into the assessment/penetration field is to start somewhere else. It is generally the case that the best way to know how to break something is to first know how to make it work.
The people I've talked to, or read about, who do the best got their start as developers, systems administrators, network administrators, or something similar. Let's not forget that at the end of the day you're not breaking into a server for fun. You're figuring out how something breaks in order to tell the client what they need to do to fix it. If your report can't include recommendations on locking down the TNS listener then it doesn't really matter whether you accessed the database.
Reporting a hack (or potential hack) with no recommendations just simply not useful to the client. As such you would be doing a disservice to the client, and as such it would make your employer look bad.
So as counter-intuitive as it may seem, you really should start somewhere else. Keep your eye on the ball, though. You may be able to get a job in Security Operations, that is acting as a firewall administrator, or a systems administrator for security appliances. That would certainly help jumpstart a move into assessments or incident response.
When a company hires someone, it is the company which takes a risk. The employee might turn out to be a lamer. If the company is so ELITE then they already know it. If they want to hire you then it is their problem.
If you choose to specialize in an area which, one day, goes out of fashion, then you'll have to learn a new craft. Or simply shrivel up and die. Your choice. People who were very good at driving horse carts got out of job when oil-powered cars were invented.