Part 3. Technology -Enabling governance structure & process
In my previous related articles, I talked about what is wrong with the current state of pentesting, and the first part of the solution – the governance structure & process.
This article is going to focus on how, in my view, the technology component of the solution should look like. And again - I want to highlight that NO technology alone would be sufficient. We need to get all three components right – process, technology and people.
A centralized security team with a governance structure (see previous article) would be able to run a sizeable pentesting program. And like with everything - they would do a far better job if equipped with the right tools.
Let’s see what these tools should look like and what features they need to have. And no - I am not going to mention any specific vendors or products.
Here is what the tools should provide:
Place to collaborate. For all involved parties – security, engineering and business.
Collaboration is important to make sure that scope, methodology, visibility and language are right.
However collaboration is absolutely necessary to improve remediation and long-term improvement of security posture.
There has been a lot of talking about collaboration between security, engineering and business. But not many tools have been built to facilitate this. For example:
Collaboration with engineers helps to share vulnerability information faster - so they can remediate vulnerabilities faster. Collaboration also helps to interact with pentest teams so engineers can ask the right questions and share right information;
Collaboration with business helps to understand the business impact of the vulnerabilities pentesters have found, and help to make better decisions on where to remediate; and
Collaboration within security teams helps to define scope & establish methodology that is in-line with organization risk profile and risk appetite.
Place to establish, maintain and enforce methodologies and vulnerability library.
Methodologies and libraries need to be established and made available to pentesters. Organizations could do it now in the form of internal policies and processes. However, this approach alone would not be sufficient to support pentesters in using them. And it does not enforce consistency for all pentests done across business units and multiple vendors.
Like it is with change management, or every other testing activity – the tool has to enforce the process, and the use of approved methodologies and libraries.
For example:
Enforcing consistent & pre-approved methodologies/checklists for every pentest project helps to ensure that the testing coverage satisfies organizational requirements & policies.
Enforcing consistent & pre-approved methodologies/checklists helps to identify and document what was not tested, to identify gaps in testing coverage.
Enforcing consistent & pre-approved methodologies/checklists helps to keep those dreadful auditors at bay – by providing them with an auditable trail of consistent pentesting activities – from methodology to remediation.
Enforcing consistent & peer reviewed vulnerability library helps to maintain consistent language and terminology across different pentest projects, teams, and external vendors. This helps to ensure the business can measure pentesting outcomes (comparing apples with apples).
Enforcing consistent & peer reviewed vulnerability library saves pentesters time and frustrations when documenting vulnerabilities.
Enforcing consistent & peer reviewed vulnerability library support junior pentesters with their professional growth.
The overall efficiency gains of enforcing consistent methodologies and libraries can be re-invested into further pentesting, red-teaming and other high-value security testing activities.
Place to track remediation and analyse pentest results and trends
We all know OWASP Top 10 vulnerabilities. But what about MY organizations most common vulnerabilities? Or which test cases MY applications are constantly failing? Just imagine how the analysis of this data could improve your organization security! How much simpler would it be to justify the security investment if you would be able to support it and measure the future success using real data?
The tool needs to be able to provide access to pentest results and trends outside of static reports. This will allow the organization to track remediation and perform analysis. There is a wealth of knowledge in that data. If data is stuck in static reports - the data is useless.
The tool should gather information on test case outcomes, vulnerabilities, remediation time-frames and link them to the relevant assets, business units, development teams, compliance frameworks and external vendors.
For example:
Accessing vulnerability information in a tool means engineers can see it faster, so they can fix it faster.
Accessing vulnerability information in a tool means engineers can record their remediation activities, and organization can track progress on closure.
Gathering vulnerability information in a tool allows the organization to understand their security posture for their pentesting program.
Gathering remediation information in a tool allows the organization to track and measure the effectiveness of remediation activities across organization, business units, etc.
Analyzing information on pentesting activities and linking to assets, business units, and teams, helps to determine the root causes, measure improvements, and make informed decisions on security investments.
There are several tools available that would fit the requirements listed above (to a different degree). Some of them are more focused on large enterprises, and some are better suited for a smaller organization. Select a tool for your teams that meets YOUR requirements, and they will be more productive and much happier!
Now the last topic I would like to cover is People component of the solution. The next article will be focused on that.