Security Testing FAQs
1. What security testing does Guidewire do for the out-of-the-box (OOTB) ski releases?
Guidewire aligns with industry best security practices for out-of-the-box (OOTB) product development and ski releases to implement a secure development lifecycle. In addition to the security tests performed as part of this life-cycle, Guidewire leverages carefully selected independent third-party experts to perform security testing of all releases. This testing process uses automated tools and manual testing to maximize the thoroughness of the test. Assessed vulnerabilities include, but are not limited to:
- Open Worldwide Application Security Project (OWASP) TOP 10 andSysAdmin, Audit, Network, and Security (SANS) Top 25
- Unauthenticated or unauthorized access to functionality (privilege escalation)
- Cross-customer data access.
- Access to the underlying services through the application, server infrastructure, or network ports
All vulnerabilities identified in the process are tracked, remediated, and revalidated for closure following Guidewire’s vulnerability management policies and procedures.
2. How do customers gain knowledge of our responsibilities related to security testing?
Guidewire is responsible for conducting out-of-the-box (OOTB) security testing. During product development, Guidewire uses various techniques to identify vulnerabilities. All identified vulnerabilities are tracked, prioritized, and addressed following our policies and procedures.
Customers are responsible for conducting all security testing for modifications to the OOTB code, including the addition of Marketplace content and collateral from solution partners. They are also responsible for identifying, tracking, and addressing any security issues their implementation introduces. Furthermore, customers are responsible for procuring and maintaining appropriate licenses for their security tools.
3. How will customer security tests impact legitimate traffic, or will they be conducted during business hours?
Customers must notify Guidewire by submitting the security testing Information form before conducting a security test. The product security incident response team (PSIRT) will coordinate the activity with internal teams.
4. Is the customer required to conduct security tests before going live?
At their discretion, customers may conduct security tests driven by their security and compliance needs.
5. How should the customer handle potential vulnerabilities identified during a security test?
Customers are required to reasonably validate all findings before submitting them to Guidewire. The validation should be conducted by a qualified security resource (especially for automated scan report output) before submission.
6. With regard to customer security testing, how is GW protecting against shared tenancy?
The test scope is validated for tenancy during authorization.
7. Can customers attempt to exploit any vulnerabilities found?
Guidewire permits manual testing/evaluation of vulnerabilities; however, the testing must be limited to acquiring sufficient evidence of the vulnerability's existence.
8. How does Guidewire approach security testing for out-of-the-box (OOTB) ski releases?
Guidewire aligns with industry best security practices to implement a robust Secure Development Lifecycle for OOTB product development and ski releases. In addition to all the security tests we perform as part of this life-cycle:
- Guidewire leverages carefully selected independent third-party experts to perform comprehensive security tests of all releases.
- The objective and scope of such a test are to assess implemented security controls in Guidewire Cloud OOTB releases in a test environment. This testing process uses both automated tools and manual testing techniques to maximize the thoroughness of the test.
- Assessed vulnerabilities include, but are not limited to:
- OWASP TOP 10, SANS Top 25,
- Unauthenticated or unauthorized access to functionality (privilege escalation),
- Cross Customer Data access and
- Access to the underlying services through the application, server infrastructure, or network ports. All vulnerabilities identified in the process are tracked, remediated and revalidated for closure following Guidewire vulnerability management policy and procedure.
9. Can you provide links to helpful security testing resources?
10. What consideration is made regarding vulnerability's criticality (high/medium/low) and its system/business impact?
Customers are required to reasonably validate all findings from the security test. The validation should be conducted by a qualified security resource (especially for automated scan report output).
For vulnerabilities affecting customer implementation, customers should utilize a risk-based approach, leveraging industry best practices (including the Common Vulnerability Scoring System (CVSS)) to score the vulnerabilities and prioritize remediation based on their criticality and impact.
Customers will submit reports for vulnerabilities that impact the out-of-the-box product or platform to Guidewire. Guidewire will triage all reports, and any confirmed vulnerabilities will be tracked in a centralized vulnerability management system. They will be prioritized using a risk-based approach (CVSS), remediated, and revalidated for closure in accordance with Guidewire’s Vulnerability Management Policy and Procedure.
11. What facilities, such as a test bed, would be provided to test patches before applying them to a live environment?
Customers will continue leveraging the same process they follow for testing and deploying patches in their environment.
12. What's the difference between GW's out-of-the-box tests and "customer added/custom" testing? For example, when a new product is introduced, all capabilities added use Guidewire-provided constructs (e.g., APD, IG, generated cloud APIs, etc.).
Guidewire’s out-of-the-box releases undergo rigorous testing to ensure the highest level of security assurance. Any customer-introduced changes to code, configuration, and APIs are considered custom code.
13. Who should perform risk assessment/threat modelling of identified vulnerabilities?
Customers are responsible for the risk assessment of vulnerabilities introduced from their own implementation. At the same time, Guidewire is responsible for the risk assessment of any vulnerabilities impacting the out-of-the-box product or platform.
14. Can Guidewire provide more details on its testing methodology?
Guidewire conducts web application and network security tests for each out-of-the-box major release or at least once annually (if no major release). Guidewire employs industry-standard security test approaches and best practices that align with publicly available authoritative sources and international standards. The scope of the tests includes unauthenticated and authenticated user access. The testing approach layers human expertise on top of automated security testing tools. The objective is to provide complete coverage for standard vulnerability classes and other design, business logic, and compound flaw risks that can only be detected through manual testing.
- Assessed vulnerabilities include, but are not limited to:
- Access to the underlying services through the application, server infrastructure, network ports, or other such access
- Cross-customer data access
- Open Web Application Security Project (OWASP) Top Ten
- SANS Top 25 Software Errors
- Unauthenticated or unauthorized access to functionality (privilege escalation)
15. We do not have the resources to conduct this test. Can we request that Guidewire perform the test on our behalf?
Unfortunately, we are unable to make an exception as this is an important element of shared responsibility on the cloud. Our out-of-the-box releases are pre-tested to provide security assurance, and we can share our certifications to attest to our practice. Customers can conduct additional tests as required for their implementation using internal security resources or preferred third parties using the guidelines provided here.
Was this page helpful?