Purpose
CI-ISAC Australia coordinates the responsible disclosure of security vulnerabilities affecting our members and the broader Australian critical infrastructure community. This policy sets out how we receive vulnerability reports, how we handle and verify them, and how and when we coordinate their disclosure.
It applies to vulnerabilities reported to us by external researchers, to vulnerabilities our members ask us to coordinate, and to vulnerabilities our own analysts identify. It also serves as our public vulnerability disclosure policy as a GCVE Numbering Authority (GNA).
2. The two roles we play
CI-ISAC operates in two distinct capacities, and our obligations differ in each.
As a coordinator. Researchers and members approach us to disclose a finding on their behalf and with our support. We act as a trusted intermediary between the finder and the affected vendor or operator, manage the disclosure timeline, and reduce the friction and risk that finders often face when reporting directly. We can carry a report under our name and preserve the finder’s anonymity where they ask us to.
As a finder. Our analysts identify and investigate vulnerabilities directly, and we verify findings reported to us rather than relaying them unexamined. When we do this we act in good faith, we prioritise the safety of users and patients above the convenience of the investigation, and we limit our testing to the minimum necessary to confirm a finding. We do not exploit a vulnerability beyond what is strictly required to establish that it is real.
3. How we verify
When we verify a finding, the following constraints are absolute and override any investigative benefit:
- We test only on systems we own or control, or systems we have explicit written authorisation to test. We do not test live third-party systems, production member environments, or internet-exposed instances we do not own, even where doing so would settle a question faster.
- We confirm existence and impact to the lowest degree that proves the finding. We do not pivot, escalate, persist, or access data beyond that point.
- We do not access, copy, modify, or retain personal information, health information, or credentials beyond what is unavoidable to demonstrate the issue, and we redact sensitive values from our records and reports.
- Where confirming reachability or exploitability would require touching a system we are not authorised to test, we stop and ask the vendor or operator to confirm it instead.
This means some reports reach a vendor as “demonstrated in our lab, reachability unconfirmed in your environment” rather than as a tested live exploit. That is deliberate.
4. How to report to us
Send vulnerability reports to intel@ci-isac.org.au.
A useful report includes: the affected product, service, or system and its version; a clear description of the vulnerability and its impact; the steps, artefacts, or evidence needed to reproduce or confirm it; whether you believe the issue is being exploited; whether the affected component is exposed to the public internet; and how you would like to be credited, if at all.
Please redact live credentials, personal information, and patient or health data from your report. If proof-of-concept or exploit material is necessary, tell us it exists and let us agree a handling method with you before you send it. Do not include it in an initial unsolicited email.
5. Handling of your report
We treat reports as confidential. We share the details only with the parties necessary to remediate the issue, and only to the extent necessary, on a need-to-know basis.
We do not currently operate a public encryption key for inbound reports. Until we do, do not transmit exploit code, live credentials, or sensitive datasets in plain email. Contact us first and we will agree a secure channel for any sensitive material. We treat any such material as exploit-grade and restrict its handling accordingly.
If you are disclosing on the condition of anonymity, tell us, and we will not identify you to the vendor, the operator, or in any published advisory without your consent.
6. What happens after you report
- Acknowledgement. We aim to acknowledge your report within five business days.
- Triage and verification. We assess severity and, where appropriate, verify the finding within the constraints in section 3.
- Vendor or operator notification. We notify the affected party and seek to agree a coordinated remediation and disclosure plan.
- Coordination. We keep the finder and the vendor informed through to remediation or to the end of the disclosure window, whichever comes first.
7. Disclosure timeline
Our default coordinated disclosure window is 60 to 90 days from the date we notify the affected vendor or operator. We apply the shorter end of that range where the vulnerability is exposed to the public internet, is trivially exploitable, or shows signs of active exploitation, and the longer end where remediation is genuinely complex and the exposure is contained.
These timelines are defaults, not guarantees. We will extend a window where a vendor is engaging in good faith and a fix is in progress, and we will shorten it where users are at active risk.
Vendor acknowledgement: We expect the affected vendor or operator to acknowledge our notification within 14 days. If we receive no response within 14 days despite reasonable attempts to make contact, we may:
- escalate the matter to a relevant national authority, such as the Australian Signals Directorate’s Australian Cyber Security Centre, where the exposure warrants it; and
- proceed toward publication of a limited public advisory at the end of the disclosure window.
The 14-day acknowledgement clock and the 60-to-90-day disclosure clock are separate. Silence does not pause the disclosure window.
8. Publication and GCVE identifiers
As a GCVE Numbering Authority, we may assign a GCVE identifier to a confirmed vulnerability and publish a security advisory through our public advisory source.
What we publish: the affected product and versions, the nature and impact of the vulnerability, remediation or mitigation guidance, and a CWE classification. Where a CVE identifier also applies, we cross-reference it.
What we withhold: working exploit code, credential values, live host or instance identifiers, and any detail that materially eases attack against unpatched systems. We will withhold technical detail beyond the nominal window where releasing it would endanger users before a fix is widely adopted. Verification tooling that derives or dumps credentials is never published.
9. Recognition
We are glad to credit researchers and members who report in good faith, by name or handle, with their consent. We will not name a finder who asks to remain anonymous. We do not currently operate a paid bug bounty.
10. Good-faith assurance and legal boundaries
If you report a vulnerability to us in good faith and in accordance with this policy, CI-ISAC Australia will not pursue or support legal action against you in connection with that report, and we will treat your report as a constructive contribution to the security of the community we serve.
This assurance has limits we cannot exceed, and you should understand them clearly:
- CI-ISAC does not own or operate the products, services, or systems that reports concern. We cannot authorise you to access or test any system, and nothing in this policy grants you that authorisation.
- You are responsible for ensuring that your own research is lawful. Australian law, including the computer offences in Part 10.7 of the Criminal Code Act 1995 (Cth) and equivalent state and territory legislation, applies to your conduct regardless of this policy. Test only systems you own or are explicitly authorised to test.
- We cannot bind any third party. Our assurance does not commit a vendor, operator, or other party to refrain from acting, although we will advocate for good-faith researchers in our coordination.
- We will decline to accept or act on a report where it appears to have been obtained through unauthorised access, and we may be obliged to refer serious matters to authorities.
This section is a statement of our approach and is not legal advice. If you are unsure whether your research is lawful, obtain your own advice before proceeding.
11. Out of scope
This policy concerns security vulnerabilities. It does not cover general IT support requests, reports against systems where you have no authorisation to test, or the submission of unauthorised access to data as though it were a vulnerability report. Reports that depend on social engineering of staff, physical intrusion, or denial-of-service testing against live systems are outside the conduct we will support.
12. Contact
CI-ISAC Australia – National Intelligence Office Email: intel@ci-isac.org.au Phone: 1300 556 210 Web: CI-ISAC Australia | Collective Cyber Defence for Critical Infrastructure
This policy is published at https://www.ci-isac.org.au/vulnerability-disclosure-policy and is referenced from our security.txt file at https://www.ci-isac.org.au/.well-known/security.txt. We review it at least annually.
