Overview
Third Party Application Security Testing Vendors can help identify security weaknesses and vulnerabilities in a third person perspective which has no or little knowledge how the application is developed and test its resiliency in a simulated threat actor role.
This document aims to establish defined security testing requirements, scope, procedures, and process in 3rd Party engagements with the vendors.
Testing Procedures
The testing may include any, or combination of the following:
Vulnerability Assessments (VA)
Penetration Testing (PT)
Secure Code Review (SAST)
Testing Requirements
The testing should:
be performed in a gray box technique unless otherwise required.
be unbiased and non-intrusive for all kind of test.
be performed in a test environment. No testing should be allowed in production environment unless otherwise required.
be performed in a controlled manner. All testing scripts, data, executables, and etc. should be cleaned after the engagement.
immediately report critical severity vulnerability findings to point of contact during the engagement.
Testing Scope
The testing should have:
Code Review (if engagement has SAST requirement)
Vulnerability scanning
Web Application Security Testing
Mobile Application Security Testing
Penetration Testing
Vendor may used the OWASP Testing Guide Checklist for web and mobile application security tests.
Engagement Process
The engagement should have the defined list of requirements for the security testing. Vendor should be able to raise questions and clarifications based on the requirements and addressed prior to request of quotation. Once all questions and clarifications were addressed, vendor should provide the service quotation based on the agreed requirements. If quotation is approved, the procurement of the service will follow internal procurement process. All contracts should be completed and signed before the start of engagement.
Vulnerability Reporting
Vulnerability reports should be treated as strictly confidential and disclosed privately. The documents including their artifacts (if available) should be encrypted. Decryption key, passphrase, or password, should be sent in separate mail.
Vulnerability report should have a comprehensive technical details including screenshots and artifacts (if needed) to support the remediation. Technical details should composed of:
Vulnerability description
Risk associated based on its impact
Vulnerable feature, services, and/or ports
Severity of the findings
Sufficient details how it is reproduced, and
Should have a recommendation to resolve the issue.
For more information, Vendor may follow the OWASP vulnerability reporting procedures.
Vulnerability Management
Vulnerabilities found from the results of the engagement should follow the internal vulnerability management process to manage the remediation and target timeline to release the fix.