Internal vs. External Pentest Teams - Two Worlds Apart
When I think of pentesting, I think of people trying to circumvent or abuse controls in people, processes, and technology to their advantage. But these “people” come from very different perspectives – we have internal pentest teams which usually work for security divisions inside organizations; and external pentest teams which are usually advisory roles brought in for specialisation or to augment internal teams.
One thing I want to highlight is that not every organization has an internal pentest team - and this is for many good reasons. A few of those reasons are mentioned below.
I promised a perspective from the inside – myself, I have been in the pentesting space for the past decade. I’ve worked for a big consultancy; I’ve run my own consultancy; and more recently at AttackForge, we work closely with consultancies and enterprises from all over the world in all shapes and sizes – each achieving pentesting in very different ways. This provides a unique insight into the challenges or “feature requests” we get on a daily basis, to solve interesting and sometimes very complex problems (where technology is part of the solution, anyways).
Let’s start by defining these terms.
An internal pentest team is usually:
Centralized function within the organization. Some very large organizations have multiple teams, with focus on different areas such as penetration testing; red teaming; testing corporate systems; testing customer-facing systems; compliance; and others.
Unified with the view to improve the security posture for the organization.
Integrated as a formal workflow within SDLC.
Collaborative with engineering, product and business teams.
Focus on fixing vulnerabilities and reducing risk.
Provides advisory on risk and sign-off on technical security for projects and BAU systems.
On the flipside, an external pentest team is usually:
Advisory roles within a consultancy or MSSP.
Unified with the view to sustain and grow their business.
Ad-hoc projects, based on when customers need advisory or technical services.
Focus on reporting and communication of findings.
Advisory on priority of resolution for findings – does not dictate organizational risk.
Collaborative directly with customer and their relevant stakeholders.
Minimal involvement during remediation process – usually to retest findings.
Internal and external pentest teams each have their own priorities and ways to getting the job done. Working for either can shape the view of what pentesting “is” for many people, creating a tunnel-vision of sorts. This can lead to misrepresentation of pentesting as a profession and as a career choice, planting seeds of bias for which is “better or worse” in the minds of the next generation.
Some of the best pentesters I know have experience working in both internal and external teams. Conversations with them usually go very differently when compared to conversations with people who have only ever worked one side of the coin. The primary difference is the gap on perspective and appreciation for the challenges engineering, operations & security teams are facing when trying to ‘secure all of the things’.
There is no denying it, pentester burnout is a real thing. We see this all the time. Pentesters are technical security experts who ordinarily should be focusing on breaking things – however in the real-world, this means having to deal with all the other uncool tasks that comes with the profession.
Below are some of the daily tasks you would expect to find in an internal pentest team:
Team meetings, focused on alignment and progress updates against organisational security strategy.
Consulting with product and BAU teams to define scope for pentests. Sometimes met with resistance and reluctance to test.
Chasing developers, engineers, system administrators, etc. to get test credentials, system details/documentation, and understanding of what it is they built or own as to make meaningful use of testing time.
Organising firewall burns from pentester source IPs/hosts.
Notifying SOC teams so they don’t freak out when testing starts.
Sending daily testing notifications and updates on testing progress and findings.
Updating progress on test cases against agreed methodology and scope.
Capturing findings and evidence.
Defining risk scores for each of the pentest findings. Sometimes involves discussion with other risk and compliance teams.
Helping to define remediation plan for project and BAU teams. Sometimes involves presentations to get stakeholder buy-in or use of other persuasion tactics.
Chasing teams for updates to understand where they are tracking against remediation plan and SLAs.
Organising retesting, repeating many of the tasks above.
Tracking open & risk-accepted findings and reporting to senior management or board.
Understanding what new projects, technologies, and attack vectors to consider as part of the input to organisational security strategy.
Also below are some of the daily tasks you would expect to find in an external pentest team:
Timesheets. Utilization is king if you want to keep your job.
Team meetings, focused on new attack vectors, new customers, company growth.
Scoping meetings with customers to understand what it is they want tested, why, and how it’s going to be achieved. Most of the time it goes smoothly, however sometimes met with
that’s insanely expensive..
why do you need so much time?
you’re hackers, why should I tell you anything about the system? You can figure it out…
I thought you just run a scan?
Replying to RFTs/RFPs/RFIs/RF… adding as much fluff as possible to win the bid and convince customer your testing is superior to your competitors. Doing everything you can to win work and keep the pipeline of projects going!
Testing access to systems to check if everything is working, ahead of planned start.
Doing a 5-day pentest, in 2-days – because the environment was not accessible during first 3-days (happens more often than you think).
Spending 8-days of effort on a 5-day project because it was scoped wrong or sales are trying to cut costs and win more work. Sometimes working overtime to make ends meet.
Reports. Writing long reports. Very very long reports. Also doing peer & technical quality assurance reviews on other very very long reports.
Persuading customers why your Critical or High rating for certain vulnerabilities cannot be downgraded to Low.
Presentation of findings to customers.
Remediation testing. Repeating many of the tasks above.
Training. Certifications. Keeping your skills sharp and knowledge broad.
Internal presentations on recent successful pentests.
Note that none of these activities actually include the testing component, where you use your tools and brainpower to prod and poke things till they break.
So what are the highlights and advantages of working for an internal pentest team?
Job security. Usually not having to worry about utilization and timesheets.
Focus. You get to focus only on certain systems at any one time and gain deeper understanding for how they work. Unlike external teams which have to bill as much as they can, as pentesting is seasonal work, sometimes having to do 2-3 pentests simultaneously.
Exposure to workflows and processes. Interaction with other parts of the business and gaining understanding of where pentesting fits within the wider organization. Useful if you have managerial or wider security aspirations.
Cross-skilling with blue-teams. Learning how findings get remediated and how these teams operate on the inside.
Hone your collaborative and persuasion skills. It’s not just about finding vulnerabilities – they actually need to be fixed too. Easier said than done in most places I have seen.
Less emphasis on writing reports – more emphasis on structuring remediation plans.
And what are the benefits and advantages of working for an external pentest team?
Higher pay. Consultancies usually pay well compared to full-time positions within internal teams. However, this is definitely not true in all cases. I also know of many internal teams which are remunerated very well.
Breadth of experience. You will become well versed in different technologies, tools, solutions that your customers are using – providing a solid foundation for technical growth.
Exposure to different tools. External teams need to be efficient. This means doing what it takes to cut down on human costs, usually involving access to bleeding-edge testing, reporting & process improvement tools.
Don’t have to deal with remediation. This is one of the biggest challenges security teams face. Being an impartial outsider, this is not your responsibility.
Learn technical writing skills. Because you will be writing and reviewing many reports, you will become proficient in this – one way or another ;)
Learn how to multi-task and re-prioritise. You will be faced with challenges where you need to do multiple pentests simultaneously, or address urgent customer matters, so learning to deal with this is a crucial skill that will stick with you throughout your career.
Cross-skilling with red-teams, physical security teams, etc. Consultancies and MSSPs usually provide multiple types of technical security testing services. You could get exposure to this easier and faster than your counterpart working in an internal pentest team.
There are many advantages of working for an internal team and also for an external team. If this analysis was a venn diagram, getting to break things is the overlap – the rest is worlds apart. Pentesting is not just about running scans and reporting. It’s a complex ecosystem of processes and people, and when done well – it can have a tremendously positive influence. There is no denying that pentesting can be a rewarding career, however wherever you start your career – internal or external – can shape what you think pentesting actually “is”. If you’re looking to join the industry, or if you are simply looking out the window for greener pastures, I hope this analysis will provide some food for thought.