Security Disclosure Policy

ASEC greatly appreciates investigative work into security vulnerabilities which is carried out by well-intentioned, ethical security researchers. We are committed to thoroughly investigating and resolving security issues in our platform and services in collaboration with the security community. This document aims to define a method by which ASEC can work with the security research community to improve our online security.

Scope

Vulnerabilities in ASEC products and services are only within scope of the Bug Bounty Program when they meet the following conditions:

• They have not been previously reported or have not already been discovered by our own internal researchers
• It can be demonstrated that there would be a real impact to ASEC, its users or its customers should the vulnerability reported be exploited by a malicious actor. The existence of a vulnerability does not necessarily demonstrated that such a potential impact exists: theoretical impacts will not be considered as within the scope of the program;

Below is a list of in-scope and out-of-scope assets. Please note that this list is not exhaustive and may be updated at any time.

• asec.io (In-Scope)
• www.asec.io (In-Scope)
• app.asec.io (In-Scope)
• shop.asec.io (Out-of-Scope)

The following security issues are currently not in scope (please don’t report them):

• All vulnerabilities that are not direct application dependencies, do not have a direct ASEC user impact and are the result of a third party will be considered informative
• Open redirects without demonstrating additional security impacts (such as stealing auth tokens)
• Clickjacking on pages with no sensitive actions
• Unauthenticated/logout/login CSRF
• Attacks requiring MITM or physical access to a user’s device
• Previously known vulnerable libraries without a working Proof of Concept
• Volumetric Denial of Service vulnerabilities (i.e. simply overwhelming our services with a high volume of requests);
• TLS configuration weaknesses (e.g. “weak” cipher suite support, etc.)
• Host header injection where the resulting impact is minimal

Bug Bounty

Unfortunately, ASEC is not currently offering a paid bug bounty program. We would like to offer a token of our appreciation to security researchers who take the time and effort to investigate and report security vulnerabilities to us according to this policy. Reporters of qualifying vulnerabilities will be offered a unique ASEC reward. Please note: swag rewards are only available for shipment within North America, and no monetary bounties are offered.

Reporting a Vulnerability

If you have discovered an issue which you believe is an in-scope security vulnerability (please see the section above for more details on scope), please email [email protected]. Provide as much information as possible about the potential issue you have discovered. The more information you provide, the quicker ASEC will be able to validate the issue.

The following should be included in your report:

• A concise title of the vulnerability
• The asset, website or page of the issue
• Type or category of weakness (e.g. XSS, SQLi, etc.)
• Estimated severity of the issue (low, medium, high, critical) based on the CVSS v3 Calculator
• A thorough description of the vulnerability, including reproduction steps
• Outline of the impact an attacker could achieve
• Time spent discovering the vulnerability

PGP Key

ASEC does not require your submission to be encrypted, however if you want to send us a vulnerability using PGP we still want you to have this option.

Please realize that using PGP will likely slow down our response to your submission. Under normal circumstances, a member of our team can view security reports and respond immediately. If you PGP encrypt your message, only core members of the security team will be able to triage your submission. Please be aware that if we receive an encrypted submission, unless your submission has a significant impact, we will likely not reply utilizing PGP.

Still, if you feel your vulnerability submission requires the use of PGP, then you can find our public key here.

What to expect

In response to your initial email to [email protected] you will receive an acknowledgement reply email from the ASEC Security Team, this is usually within 24 hours of your report being received. Following the initial contact, our Security Team will work to triage the reported vulnerability and will respond to you as soon as possible to confirm whether further information is required and/or whether the vulnerability qualifies as per the above scope, or is a duplicate report. Next, necessary remediation work will be assigned to the appropriate ASEC teams and/or supplier(s). Priority for bug fixes and/or mitigations will be assigned based on the severity of impact and complexity of exploitation. Vulnerability reports may take some time to triage and/or remediate, you’re welcome to enquire on the status of the process but please limit this to no more than once every 14 days, this helps our Security team focus on the reports as much as possible.

Our Security Team will notify you when the reported vulnerability is resolved (or remediation work is scheduled) and will ask you to confirm that the solution covers the vulnerability adequately. We will offer you the opportunity to provide us with feedback on the process. This information will be used in strict confidence to help us improve the way in which we handle reports and/or develop services and resolve vulnerabilities on our acknowledgements page and we’ll ask for the details you wish to be included.

Guidance

Security researchers must not:

• Access unnecessary amounts of data. For example, 2 or 3 records is enough to demonstrate most vulnerabilities (such as an enumeration or direct object reference vulnerability)
• Violate the privacy of ASEC users, staff, contractors, systems, etc. For example by sharing, redistributing and/or not properly securing data retrieved from our systems or services
• Communicate any vulnerabilities or associated details via methods not described in this policy or with anyone other than your dedicated ASEC security contact
• Modify data in our systems/services which is not your own
• Disrupt our service(s) and/or systems; or
• Disclose any vulnerabilities in ASEC systems/services to 3rd parties/the public prior to ASEC confirming that those vulnerabilities have been mitigated or rectified. This does not prevent notification of a vulnerability to 3rd parties to whom the vulnerability is directly relevant, for example where the vulnerability being reported is in a software library or framework - but details of the specific vulnerability of ASEC must not be referenced in such reports. If you are unsure about the status of a 3rd party to whom you wish to send notification please email [email protected] for clarification.

We request that any and all data retried during research is securely deleted as soon as it is no longer required and at most, 1 month after the vulnerability is resolved, whichever occurs soonest.

If you are unsure at any stage whether the actions you are thinking of taking are acceptable, please contact our security team for guidance (please do not include any sensitive information in the initial communications): [email protected].

Legalities

The policy is designed to be compatible with common good practices among well-intentioned security researchers. It does not give you permission to act in any manner that is inconsistent with the law or cause ASEC to be in breach of any of its legal obligations. ASEC will not seek prosecution of any security researcher who reports, in good faith and in accordance with this policy, any security vulnerability on an in-scope ASEC service.

Feedback

If you wish to provide feedback or suggestions on this policy, please contact our security team: [email protected]. This policy will evolve over time and your input will be valued to ensure that it is clear, complete and remains relevant.

Acknowledgements

• ROCK PRATAP SINGH