The Future of Penetration testing

JasonP03

New programming languages like rust are making common memory corruption vulnerabilities like buffer overflows obsolete, and new smarter automated tools are becoming a cheaper, yet less effective, compromise to hiring a pentester.

What is your opinion on the future of pentesting? Do you think security vulnerabilities will decrease making the value of a pentester's services slimmer, or will new techniques and vulnerabilities arise as technology advances?

docrice

I highly doubt that the value a pentester brings will become reduced in the future. There will always be legacy systems with old code, network topologies and applications are going to increasingly become more complex, and with the trend towards cheaper/faster/first-to-market efforts with less/any security review/oversight will expand the vulnerability horizon considerably.

If anything, I expect to see L1 - 7 become a more populated minefield.

YuckTheFankees

@JasonP03,

I have wondered the same exact question. I definitely do not see tools replacing pentesters fully but in some ways, yes. I do think a major focus will be on web and mobile attacks over the next 5 years....but what that will do for a pentester career, I do not know.

@docrice,

What is L1-7?

jasong318

I thought by now everyone would be able to fix their home PC's and configure a router As new technologies arise, new exploit techniques will follow suit. Yes, there are secure programming languages and secure programming techniques, but like docrice said, everyone wants be first to market so secure SDLC often gets put off to the wayside. Plus, how long and costly would it be for a company to port their code from legacy C (or other code base with known holes) to a newer, more secure programming language? And for what measurable benefit? Most companies will just do a cost/risk analysis and come to the conclusion to go the course unless a new product comes along that forces change or a complete compromise of their product occurs. And even then a patch is usually pushed instead of a hard look at their SDLC.

Plus, not all vulnerabilities are related to buffer overflows or memory corruption. A lot has been done in the recent past to mitigate these attack vectors such as stack protection, safe libraries, DEP, NX, ASLR, etc. Each specifically designed to prevent buffer overflows (yet each has its own vulnerabilities) but not much else (SQLi anyone?). A lot of people thought that the move to IPv6 was going to solve so many of the security problems of IPv4, and some were, but new vulnerabilities were also introduced and discovered. And a company can (and many do) opt for an automated tool over a pentester and feel secure that the end report says 'secure', but a trained individual is needed to actually interpret those results and deduce any lingering vulnerabilities.

instant000

You didn't ask me specifically, but L1-7 is referring to layers 1 through 7 of the OSI model, I suspect.

The way I see it is that security has to be built in from the inside out, as well as from the outside in.

The hardware itself needs to have been compiled securely, because if you don't know what's running your hardware firmware, it really does matter less whether or not you have good application software on top of that. Do you know what's in that compiler?

Who cares what the app is telling you, if the underlying hardware is lying to you?

This is why I agree that Layer 1-7 will only become more important, and feel that code does need to be proven from layers 1 through 7 ... especially when you consider how much hardware itself comes from organizations that may not necessarily want to be your friends, or even intentionally leave in backdoors to make the programmer's job easier. ... isn't that what the root cause of the issue with the Iran centrifuges was?

Just saying, there's a lot that can go wrong in security, before it even gets to the stage where a compiled app matters.

Security is needed inside-out, as well as outside-in. Can't ignore either side of it.

Hope this helps.

wes allen

This is a subject I have been interested in as well. One thing to think about is that a vulnerability scan != a pen test. The scan might pick up some known problems, but a pen tester will find ways to exploit, chain, and escalate those into greater access then what a report might say is possible. Internal network pen testing is starting to become more popular as companies accept that it isn't very difficult to compromise a workstation via social engineering, so they want to see where an attacker can get to with a pivot point inside the internal net. Which opens up a whole other range of attacks that are not possible from outside, but which need to be mitigated. Like access to your SQL server ports from outside is blocked at the firewall, but what about from the inside? ARP spoofing/DNS posioning? MITM attacks? Local and domain password hash attacks? And, then there are still all the webapps and mobile apps as well. How well does a mobile app do encryption? Is the back end secure? Etc.

ptilsen

Exploits becoming more difficult doesn't make pentesting less valuable. It makes it more valuable, because people who can do it will become more scarce.

Even if Rust magically fixes most exploits within software made in the next five years (which it won't), there will still be thousands upon thousands of corporations running outdated technology and using inadequate processes. Besides, if pentesting were just a matter of finding flaws in equipment and software, it would be a very different game. The fact of that matter is, a lot of attacks are preventable with better processes, procedures, and configurations of what's already out there. These are inadequate across the industry with no signs of imminent change, which means there is a foreseeable need for pentesting for a long time, regardless of how inherently secure software and hardware get.

JDMurray

Vulnerability assessment only looks for known vulnerabilities, such as those listed in the CVE. Pen testing also looks for unknown vulnerabilities, and therefore will always be needed as part of Software Quality Assurance (SQA) process.

As to a computer language saving us humans from having to do proper programming, there is more to application vulnerabilities than the programming language a program is written in. The operating system, visualized host, and run-time environments the program is running on all contribute vulnerabilities. It is highly unlikely we will one day see all that written in the same programming language that makes it impossible to produce less than 100% bullet-proof code.

wes allen

Also, there is physical pen testing and social engineering as well. Can you craft an email such that someone will click the link or open the attachment? Can you get to the 5th floor conference room, defeat the door lock and plug your laptop into the internal network?

010101

As far as a tool or language fixing things so much that it's impossible for things to be hacked. HA!!! That's a joke.
If the US government with all their money can't keep China out, if google and all of their PHD geniuses can't keep China out, then hacking isn't going away anytime soon.

On the other hand, one potential problem is the cloud.
If the cloud takes off(which I don't think it will), then pen-testing could die to a large degree.
But for all we know, in 5 years everyone will be doing boot from cloud VDi and there will be far less things to pentest and hence far less pentesters.

The cloud wont make things more secure. The opposite really. The cloud will make it so instead of 1 hack = 1 company being hacked to a world where 1 hack = 1,000s of companies hacked.
But the issue is, it isn't legal for a pentester to run tools against all the different vendors that your client is using for their cloud apps.



.

the_hutch

wes allen wrote: »

Can you craft an email such that someone will click the link or open the attachment?

Better question. Can you craft an email with a malicious link that at least one idiot WON'T click on? People are pretty stupid. And like they say...you can't fix stupid.

r0ckm4n

As long as you have human intervention, you will need pentesters. Not all IT people have the knowledge, skills or the required time to do what needs to be done to secure and, or maintain systems. A lot of IT people are spread thin. I worked for a company that the business units went around IT and would hire there own departmental IT people. They didn't know what to look for and eventually IT inherited their mess. In some cases some small companies don't have dedicated IT staff and whoever is the most tech savvy are the ones that end up performing IT tasks. The operating systems are becoming more secure, but when you have to loosen the server on a security to get apps and, or legacy apps to work, then it makes it more vulnerable. Also apps aren't always updated and your users are forced to use older versions of Internet Explorer. Also pentests are required for federal regulations and PCI. I used to work for a financial institution and there is a lot of regulatory stuff to contend with in banks. Also look at healthcare and HIPPA.