Summary
Conducting penetration testing is a critical component to learning about your organization. A penetration tests simulates a cyberattack against your organization, typically scoped to critical components of your infrastructure that your business relies on to function and provide valuable services. Examples could include your network infrastructure, customer facing applications, or internal administration services.
I’ve found that there is value beyond what is immediately presented in the final report deliverable. Some organizations may be mandated by compliance requirements to perform this exercise.
If you’re already at it, might as well get the most from it. In my experience, you can maximize the value from this exercise by making observations in the following areas:
- Security program health
- Onboarding efficiency
- Organizational Structure
1. Security Program Health
When you are reviewing your pentest results, go beyond their face value. Pentest findings serve as symptoms to weaknesses in your security processes. Use this information as input to determine what’s not working well for you.
You can attempt to patch up every finding so you can get a clean retest report back. However, going down this route with no other plans could result in a never-ending whack-a-mole game.
Time-boxed pentest assessments have their gaps too. Different vendors, different methodologies all provide a variety of results. Not every vulnerability is going to be identified.
Imagine your pentest resulted in several instances of SQL injection. If you just validate the inputs for those endpoints and parameters, you’ll likely see similar issues surface again in the future because you haven’t addressed the root of the problem in your security process.
Instead, you may want to:
- Identify and provide guidance for implementing an effective input sanitization library for your engineering teams to use
- Follow this with SAST tooling to identify related issues, such as instances where parameterized queries are not used
- Configure tooling to ensure that this sanitization library is in use and notify engineering teams on PRs if not
- You can take this as far as your risk tolerance cares to, such as DAST implementation, developer training, and so on.
If you do end up seeing the same vulnerability classes resurfacing over time, don’t fret. It happens.
Use this as a learning lesson to pivot your security strategy and find a more effective solution. It could be that the tools are in place, but they are hard for non-security folk to use. Think outside the box here and talk to your stakeholders when analyzing your results. As security professionals, we should be making our functions as easy and accesible as possible to our organization’s counterparts.
2. Onboarding Efficiency
Depending on your organization, you may not have the opportunity to bring on new team members often. When you bring on a pentest vendor, they often don’t any context to your application. You’ll need to guide them on how to interact with your app, service, and even code repos (in white-box assessments).
Measure the time it takes to get your pentest kicked off and firing.
If you find that this is taking a significant amount of time, imagine how confusing it must be for new team members to onboard and take ownership of existing services and applications.
Maybe your documentation isn’t up to date, clear, or even existent. Could there be too many dependencies and complexity to get your testing environment set up?
If any team wants to scale, be it new teammates or temporary contract work, reducing the time to onboard with easy to digest documentation and examples is going to be key to maximizing the individuals experience and value to the organization.
3. Organizational Structure
One way to identify potential issues in this area with a pentest is with vulnerability remediation SLA (service level agreement) adherence. Defined SLA times set expectations for teams to remediate issues, such as 30 days for High severity issues.
In an ideal world, pentest findings should follow your existing vulnerability management process and be remediated within the same SLA as what you have for others.
However, you may find that the remediation for a vulnerability is multifaceted and complex. This may cause delays in remediation time as your team tries to identify stakeholders and risk owners.
This likely is even out of the security department’s control, but this SLA discrepancy between your “regular” vulnerabilities as opposed to pentest identified vulnerabilities serves as a great source of input to identify structural organizational issues outside of the security department’s immediate scope.
If this happens, identify what the bottleneck was and how you can help facilitate a smoother process or organizational change to alleviate similar concerns in other areas.
Conclusion
Being technical-minded, my default thinking pattern is identifying technical issues and their solutions. As I learn more, sometimes these organizational changes are what can make a bigger impact.
Expanding that breadth provides a route to reduce the volume of technical issues down the road. Let me know what other lessons you’ve learned from conducting your penetration tests!
Originally published at https://www.linkedin.com.
