Our Approach to Security Testing
Our security testing approach is built around the concept of 'continuous assurance' – that complements a point-in-time penetration test approach.
Bugs are an unavoidable part of the development process - the question is not whether we have bugs, the question is how effectively and quickly we find them and address them. This doesn’t mean we like bugs or aren’t constantly innovating ways to reduce their frequency and severity, but when it comes to software bugs, denial is not an effective approach.
We aim to increase the cost of finding and exploiting vulnerabilities in our products and services - through rapidly identifying and resolving issues we aim to increase the economic cost of finding security bugs. By increasing the cost of exploiting a vulnerability – by making it take longer, require more knowledge and more resources from the bad guys – we reduce their return on investment. If we can reduce it far enough, it becomes prohibitive or not attractive to them.
We support and use industry standards - standardisation in our terminology and approach helps us ensure we’re covering everything, and helps customers understand how to understand what we do. For example, common ratings of vulnerabilities using the Common Vulnerability Scoring System (CVSS) ensures clarity for severity of a particular vulnerability between us and our customers.
Ongoing security assurance
Penetration testing
We do use specialist security consulting firms to complete penetration tests on high risk products and infrastructure on a regular basis.
Testing will focus on a particular threat scenario, such as assuming a compromised instance exists, and testing lateral movement from that starting point.
Vulnerabilities we seek to be identified include common types captured in the Open Web Application Security Project (OWASP) and Web Application Security Consortium (WASC) threat lists. They include:
- Cross Instance Data Leakage/Access
- Remote Code Execution (RCE)
- Server-Side Request Forgery (SSRF)
- Cross-site Scripting (XSS)
- Cross-site Request Forgery (CSRF)
- SQL Injection (SQLi)
- XML External Entity Attacks (XXE)
- Access Control Vulnerabilities (Insecure Direct Object Reference issues, etc)
- Path/Directory Traversal Issues
Vulnerability reporting
When a vulnerability is identified by one of our users during the course of their standard use of the product (as opposed to being identified through a specific attempt to test the system, which we require to occur via our bug bounty program), we welcome notification via our Support Team. We respond promptly to any vulnerabilities submitted and will keep inquiring parties up to date as we investigate and respond to the issue.
Before disclosing an issue publicly we ask that researchers first request permission from us. SmartWinnr will process requests for public disclosure on a per report basis. Public disclosure requests will only be considered once the reported vulnerability is fixed.
Measuring the right things
When categorizing bugs, we use the Common Vulnerability Scoring System (CVSS version 3), which helps communicate the severity of vulnerabilities to our customers. We attempt to meet the following timeframes for fixing security issues:
- Critical severity bugs (CVSS v2 score >= 8, CVSS v3 score >= 9) should be fixed in product within 4 weeks of being reported.
- High severity bugs (CVSS v2 score >= 6, CVSS v3 score >= 7) should be fixed in product within 6 weeks of being reported.
- Medium severity bugs (CVSS v2 score >= 3, CVSS v3 score >= 4) should be fixed in product within 8 weeks of being reported.
These timeframes are re-evaluated on an annual basis and adjusted as needed based on the changing threat environment.
Request demo
Log in