NetSPI Managing Director Nabil Hannan was featured on the Open Web Application Security Project (OWASP) Portland, Oregon Chapter podcast. During the interview, Nabil and the hosts, David Quisenberry and John L. Whiteman, discuss mentorship, advice for entry-level pentesters, security hiring amid the cyber security skills shortage, advice for companies building a security program, cyber security policy, and more. Listen to the full episode or continue reading for highlights from the conversation.

John: A lot of people in our chapter want to be pentesters. What advice do you have for them, especially coming from your direction as a consultant?
Nabil: When I built a pentesting practice, I was tasked with hiring and training a team of pentesters. The saying I picked up from that experience is, “I can teach someone to be smart, but I can’t teach someone to be clever.” So, if you want to be a pentester, truly a pentester that’s finding interesting and unique things, it requires you to think creatively and think outside the box. The technical part of pentesting can be learned or acquired, or you can get help, but it ultimately is someone that is clever who succeeds at pentesting.

John: Are there certain security domains that we simply don’t have enough skilled people for?
Nabil: Today, there is demand for security professionals in general across every domain. It is evident that we have a shortage in security expertise across the board. Security is still in its infancy. If you want to get in, regardless of which area, whether you want to test autonomous cars, or mobile applications, or medical devices, there’s a need for security in all of those things. What I would recommend to people is, figure out what you are truly interested in and figure out if there is an area or a domain that really excites you. Find something that you understand and are passionate about and decide if the security aspect is a fit for you.

John: Has there ever been a time where you have been challenged with communicating results or recommendations to clients that may have differing levels of security understanding?
Nabil: It’s a common situation that we find ourselves in. You have to speak the right language for your audience. And if you are not doing that, it can be a challenge. It’s even more challenging when you have multiple levels of people in your audience that have varying degrees of technical or security understanding.

An example that comes to mind is a secure code review assessment I completed where we found cross site request forgery (CSRF). Nobody seemed to pay attention to it because we rated it medium severity given you had to be authenticated to really do any harm. The leadership team came to us, and said, let us know if you find anything critical, then we will decide if we need to push the production date. We replied, the vulnerability may not be critical, but it can still cause a lot of damage. To communicate the severity of the damage effectively we decided to create a proof of concept to show the impact and we were able to effectively show how easy it would be to exploit that vulnerability. As a result, they pushed their deployment to focus on remediation and better secure the application, based on our recommendation.

John: Its exploits that speak louder than words, if you just give two-dimensional bug numbers or risk rating, it doesn’t mean anything until you bring it to life as what you did here.
Nabil: As a consultant, your job is to help people understand what the true impact is based on the business that is being supported. Make sure you’re speaking the right language, the right message, and the impact defined from the business perspective and the technical perspective.

David (aka: Quiz): We often get asked by the young people in our chapter, do you need to have some time as a developer before going into something like pentesting?
Nabil: There are two ways to think about it. I come from a software development background and when I look at vulnerabilities, I can dissect them by really understanding the inner workings of the software and where it failed. If you don’t have software development experience, you can still be a tester. You can still run scripts, you can probably still run tools, and you can learn basic scripting to build automation and identify vulnerabilities. If you want to be an application pentester, chances are if you have a better understanding of how software systems are built, it will give you an advantage in coming up with creative ways to make those systems break. Is it a requirement? I don’t think so. But some of the best pentesters I know do come from a software development background.

John: What advice do you have for companies building a security program?
Nabil: Being in the security space, people naturally think security is the most important thing. That being said, when trying to figure out what’s the right security strategy for your organization, you first have to learn how the business makes money. That’s the first thing you need to learn as a security professional.

Then, align your security practices and efforts to enable the business to be better versus thinking of security as something separate. Organizations that are more immature or just getting started with security often view it as a roadblock or cost center, something that is going to only slow them down. But more mature practices adopt security culture over time and incorporate it into their processes. They learn do it in a way where it enables the business. This allows you to have a program that is mature, with security integrated. Understand the appetite for the organization and what threshold of risk you are willing to take when designing and defining the program. Try as hard as possible to make security a part of the process without it becoming a friction point for the business to function. For example, trigger out-of-band activities for security reviews in an automated fashion that won’t block your business flow and understand your risk appetite and have the ability to stop a business process from going forward if it is too risky. Being able to build that level of culture, communication, buy-in, and metric alignment is key.

John: …Should this process start with policy?
Nabil: Policy comes from somewhere even more important. It comes from your customers. Ask what security expectations your customers have. Then, depending on the business, there’s also regulation and compliance. Based on these two components, you need the right structures of leadership and culture to get buy-in across the organization to make security a part of your regular workflow versus it being a separate function.

Quiz: A challenge I have had this past year, is ensuring our security conversations are communicated correctly to others… product, customers, engineering, leadership, etc.
Nabil: Human behavior is something that I am fascinated by – how people can react to the same message but deliver it differently.

At NetSPI, our Resolve™ threat and vulnerability management platform is used by many of our customers internally to track and communicate their program metrics and dashboarding. If you start showing metrics like number of open vulnerabilities by business unit, it creates a very different effect than if you were to name the open vulnerabilities with the leader of that business unit. It builds a sense of competition to be better. When we work with customers to build threat and vulnerability management programs, security champions, or training curriculum, we try to focus on the human element of it to get people excited to improve their security posture rather than see it as a hinderance.

Quiz: What were your favorite Agent of Influence podcast episodes to date?
Nabil: My favorite was the first podcast episode I did with Ming Chow, a professor at Tufts University. We talked about computer science and education around security and we even touched around interesting topics such as, how he feels about teaching someone who could potentially do bad things.

During the episode with the former CISO of the CIA Bob Bigman, he provided really great insights around the life of the CISO, what they do, and what they have to live through. He helped define and change the focus of the CISO career.

Jeff Williams, the CTO of Contrast Security was a good one, too. Him and I recently did a joint webinar, How to Streamline AppSec with Interactive Pentesting.

And Quiz, I’m not saying this because you’re on this interview, but your interview was great too. Especially the book recommendations near the end. I had friends reach out the day it posted telling me how much they enjoyed the interview.

Nabil Hannan

In 2008, Brian Chess declared the impending death of application penetration testing. He believed that pentesting, as everyone knew it back then, was in its final days – about to die and come back as something else. He likened it to the ubiquitous personal digital assistants (PDAs) of the early 2000s – disappearing in form, while the key functions were reborn in modern smartphones.

Pentesting Remains Alive and Well

But more than 12 years since Chess predicted the imminent demise of pentesting, it continues to thrive in almost exactly the same form as before. This is because penetration testing examines a target environment as a whole – looking into complex or fundamental vulnerabilities that scan-based tools cannot find, such as business logic flaws, poor separation of duties, or ineffective network segmentation. Pentesting can offer tangible ROI in terms of breach prevention, compliance reporting, and ongoing security metrics.

The objective of pentesting is to simulate attacks on network infrastructure and applications in order to test defenses and find vulnerabilities.

• Network penetration testing targets network and host configurations to verify patches and other vulnerability checks.
• Application penetration testing focuses on testing custom applications, such as web applications, application programming interfaces (APIs), and rich-client applications.

With application pentesting in particular, a typical engagement involves a small team that spends a week or two focused on a specific application. Because of the long delays and natural bottlenecks associated with the process, organizations generally save these tests for the end of the software development life cycle (SDLC).

Feeding the Need for DevOps Speed

In the early 2000s, pentesting traditional monolithic web applications was relatively easy. Anyone with a proxy and the OWASP Testing Guide could find a wide range of issues. However, since that “golden age” of pentesting, software development has accelerated dramatically.

An astounding 92.7 billion lines of code were written in 2020 alone. Today’s software applications have become much larger, more complex, more interconnected, and far more critical to the individuals and organizations that use them. The majority (79%) of DevOps teams report that they are under increasing pressure to shorten release cycles – and 80% of teams deploy code to production at least multiple times per week. Indeed, modern development pipelines are designed to deliver software not in days or even hours – but in minutes.

How Can Pentesting Keep Up With Today’s Development Cycles?

1. Start with threat modeling

Traditional pentesting efforts are often poorly prioritized and directed. Rather than focusing on finding the most critical risks, they simply use a checklist or a specific set of tools. For modern applications in particular, threat modeling can help drive testing priorities by identifying key security and privacy concerns. The Threat Modeling Manifesto is a great place to get started.

2. Partner with development

Effective testing requires detailed information about how the application works and the ability to leverage the quality-test infrastructure to generate and modify application traffic. The fastest way for application security to do this is to partner with the development team. Here, pentesters should strive to work with developers to understand an application’s unique complexities without compromising their independence.

3. Stop competing with tools

Pentesting should be part of a “balanced breakfast” of testing techniques. Do not waste precious pentesting hours on things that have been already thoroughly tested with other techniques, such as interactive application security testing (IAST). Focus manual testing efforts on the specific areas where other application security tools are weak, like authentication, access control, and use of encryption. Track your route coverage to make sure you have thoroughly tested all the applications or API attack surface.

4. Embrace continuous testing

DevOps and Agile workflows have been widely embraced to accelerate release cycles and the amount of new code being written. Modern SDLC pipelines often deploy code to production many times each day. There is simply no way to perform traditional penetration tests before release without disrupting workflows and severely slowing down the SDLC. To reduce the time between deployment and testing, organizations must consider more scalable approaches that can run continuously.

5. Adapt to modern application complexity (APIs, microservices, serverless)

Today’s cloud-native applications can be difficult to test. Authentication schemes are complex and rapid request rates make interception difficult. For example, APIs do not just use HTTP with simple payloads. They also use things like JSON, XML, and serialized objects. And API security has become particularly important – specifically, APIs serve as gateways into an enterprise (making them popular targets for bad actors). Further, as modern pentesting requires tools that generate attack traffic across all the distributed parts of the application, it may take time to understand these communications and gain comprehensive visibility.

6. Understand open-source libraries and frameworks

Similarly, there is complexity on the server side. The vast majority of applications (94%) rely on open-source components, each with an average of nearly 700 dependencies that present potential vulnerabilities. For example, the newly discovered dependency confusion attack can leverage an open-source ecosystem flaw to upload malware to repositories, which then get automatically distributed downstream into internal applications. To address these sorts of issues, a pentesting team must quickly understand the application framework, how it routes to code, and how built-in security defenses are supposed to work.

7. Leverage instrumentation

Organizations can dramatically accelerate penetration testing by getting visibility into exactly what happens inside the application code or API when an attack is sent. Security instrumentation tools (like IAST) are very effective at tracking things like data flows, control flows, backend connections, and configuration files. Application security teams should install an agent before starting pentesting, which can then provide an inside view of all actual vulnerabilities present in the code during the application runtime. This visibility can dramatically accelerate penetration testing coverage and accuracy.

8. Deliver security test cases

Communicating with development teams and other groups that need to know about security is tough. Rather than delivering a traditional PDF report with arcane findings, application security teams should consider using Jira tickets to make their recommendations easier to consume. Even better, application security teams can deliver findings as test cases that run continuously with every build to prevent future instances of each discovered vulnerability from ever reoccurring. Security that natively integrates with ticketing systems can have an even broader impact – helping to improve the accuracy of testing, incentivize the remediation, and accelerate development cycles – all while helping to deliver secure code to production.

The Evolution of Penetration Testing

Ideally, the goal of modern pentesting should be to figure out new application technologies and how to test them for vulnerabilities. Penetration testing teams should be the advance guard for SDLC – driving the state of the art in security forward. But there simply are not enough skilled individual application security researchers to perform penetration testing on everything. So, we must continuously take the manual test approaches designed by penetration testers and support them with automation.

That said, unlike premature prognostications a decade ago, penetration testing is not on its deathbed. In one form or another, it will always be a valuable part of application security. And as applications continue to expand and grow more complex, security must evolve pentesting for each new layer that is added.

For more details on next-generation pentesting, make sure to register for the upcoming webinar – “How to Streamline AppSec with Interactive Pentesting.”

Jeff Williams