የደኅንነት ክፍተት ማሳወቂያ

This policy governs the receipt, the handling and the disclosure of vulnerabilities affecting the assets named below. It follows ISO/IEC 29147:2018 for the receipt and disclosure of vulnerability information and ISO/IEC 30111:2019 for its handling. It is maintained by Group Security, which receives reports, determines whether an asset falls within the scope, conducts the handling of a report to its conclusion, and coordinates disclosure. The assets within the scope are:

• •www.parousiagroup.com and parousiagroup.com.
• •westafrica.parousiagroup.com, eastafrica.parousiagroup.com, europe.parousiagroup.com, americas.parousiagroup.com, middleeast.parousiagroup.com and apac.parousiagroup.com.
• •The HTTP endpoints those sites expose, including the contact and newsletter endpoints, and the assets they serve.

An asset that does not appear in that list is outside the scope of this policy. The following exclusions are stated expressly.

• •The product domains of the six solutions — among them netvoxintelligence.com, globaltechnologyafrica.com, afrikaplaza.com, pagexpress.com and pagpay.com. A report concerning them is received at the address given below and is transmitted by Group Security to the operator concerned; the deadlines and the commitment not to pursue set out in this document apply to the assets within the scope above and to no others.
• •Services the group does not operate: email, DNS, certificate, hosting and content delivery providers, social network accounts, and any third-party platform. A report concerning them is addressed to their operator; testing them is not authorised by this policy, and the group has no standing to authorise it.
• •Physical premises, staff, telephone systems and postal mail. Nothing in this policy authorises access to a building or an approach to an employee as a test.
• •Any finding that requires an already compromised account, a rooted or malware-infected device, a physically stolen device, or an obsolete browser that the user would have to install deliberately.
• •Findings with no demonstrated impact: missing security headers, cookie flag preferences, TLS configuration preferences, software version disclosure, absence of rate limiting on an unauthenticated endpoint, self-inflicted cross-site scripting, clickjacking on a page with no state-changing action, mail configuration records on domains that send no mail, and raw output from an automated scanner. A demonstrated impact brings any of these within the scope.

A question on the scope of this policy is addressed to Group Security. A question on the effect of the commitment not to pursue, and any request arising from a claim brought by a third party, are addressed to the Legal Department. Both functions are reached at contact@parousiagroup.com.

Testing carried out within the rules below is authorised by the group. Compliance with those rules is the condition of the commitment not to pursue set out in the following section; activity carried out outside them falls outside that commitment.

• •Test only the assets within the scope, and only with accounts and data that belong to you.
• •Use the least interaction that establishes the vulnerability, and stop as soon as it is established. The demonstration is limited to what proves the finding; retrieving further records, accounts or files is neither required nor authorised.
• •Keep a record of what you did: dates and times in Coordinated Universal Time, the source addresses you tested from, and the requests that mattered. A distinctive User-Agent string identifying your research allows your traffic to be distinguished from an attack.
• •Report promptly, and allow the group the coordination window set out below before publishing.

• •Denial of service is not authorised, in any form: volumetric attacks, load or stress testing, resource exhaustion, and mass automated requests that degrade the service for others.
• •Social engineering is not authorised: phishing, pretexting, or any approach to staff, customers, partners or suppliers, whether by email, telephone, message or in person.
• •Accessing, altering, deleting or exfiltrating data belonging to another person is not authorised. Where such data is reached, testing stops at the point of proof, the data is not copied, and the fact is stated in the report.
• •Establishing persistence, installing a backdoor, pivoting to another system, or leaving any artefact behind is not authorised.
• •Brute force and credential stuffing against real accounts, and the use of credentials obtained from a breach dump, are not authorised.
• •Physical attacks, attacks on the supply chain of the group, and attacks on the personal devices or accounts of staff are not authorised.
• •Demanding payment for a vulnerability, or making the disclosure of its detail conditional on payment, is not authorised, and the commitment not to pursue does not extend to it.

Where testing degrades a service, affects a third party, or cannot be distinguished from an attack in progress, Group Security may require it to stop, and that requirement is complied with without delay. Any departure from these rules, including an unintended one, is stated in the report.

Where the researcher acts in good faith, within the scope and the rules set out above, the group gives the commitments below. They are given to the researcher, who may rely on them.

• •The group treats that activity as authorised, and will not commence, support or encourage a civil claim or a criminal complaint against the researcher on account of it, nor request a public authority to prosecute the researcher for it.
• •The group will not treat that activity as a breach of its terms of use and, for that activity, waives any provision of those terms that would otherwise prohibit or restrict it.
• •Where a third party brings a claim or lodges a complaint against the researcher for activity that complied with this policy, the group will state — publicly, and to the court or authority concerned if it so requests — that the activity was authorised by the operator of the systems.
• •The group will not require a non-disclosure agreement as a condition of a report being received or handled, and will not make the handling of a report conditional on the researcher’s silence beyond the coordination window set out below.
• •A good-faith error as to the scope — a subdomain the researcher could reasonably believe to be included, a test stopped as soon as its effect became apparent — does not withdraw these commitments, provided the researcher reports it.

A request for the statement provided for above, and any question on the effect of these commitments, are addressed to the Legal Department at contact@parousiagroup.com. The Legal Department answers in writing and states the version of this policy under which the report was handled.

A report states the following particulars. A report that omits one of them is received and assessed all the same.

• •The affected asset: the exact host, path and parameter, and the request that triggers the behaviour.
• •The date, time and time zone of the testing, and the source addresses it was carried out from.
• •A description of the vulnerability, the steps to reproduce it, and a non-destructive proof of concept.
• •An assessment of the impact: what an attacker obtains, and what they need in order to obtain it.
• •Any account used, and whether data belonging to another person was reached — including data seen unintentionally.
• •Whether the finding has been shared with anyone else, and whether it is already public or subject to another timeline.
• •Whether public credit is wanted, under what name or handle, and the preferred means of contact.

Group Security acknowledges each report, assigns it a reference, and conducts the correspondence under that reference. The deadlines set out in the following section run from that acknowledgement. Where a report concerns an asset outside the scope, the acknowledgement states so and identifies the operator to whom the report has been transmitted.

Handling follows ISO/IEC 30111:2019: receipt, verification, assessment of severity, development and verification of a fix, release, and monitoring after release. Severity is scored with CVSS v4.0. Group Security communicates the score and the vector on which it rests to the reporter; the reporter may contest it in writing, and Group Security states the grounds on which the score is maintained or amended.

Where a deadline cannot be met, Group Security informs the reporter before it expires, states the reason and gives a new date. A report is closed when the fix is released, or when the group determines that no change will be made; in either case the reporter is informed, with the grounds for the decision. Where the vulnerability lies in a component the group does not maintain, the deadlines above apply to the measures within the group’s control.

The coordination window is ninety days from the acknowledgement of receipt. The group asks that the detail of a vulnerability not be published before the fix is released or before that window closes, whichever comes first. After it closes the researcher is free to publish, whether or not the vulnerability has been fixed, and the group will not treat that publication as a breach of this policy or as a ground for a claim.

• •An extension is requested only with a reason and a date, never as an open-ended delay, and the researcher is free to refuse it.
• •Where a vulnerability is being actively exploited, the group may publish before the window closes in order to warn users, and informs the researcher beforehand.
• •The group publishes what a reader needs in order to act: what was affected, what an attacker could have done, what was done about it, and when. It credits the reporter where the reporter asked to be credited.
• •Where the vulnerability lies in a third-party component, the group reports it to the maintainer, coordinates with them, and informs the researcher of the timeline agreed with that maintainer.
• •Where personal data have been exposed, the Data Protection Office, with Group Security, discharges the notification duties in Articles 33 and 34 of Regulation (EU) 2016/679; where an entity of the group falls within Directive (EU) 2022/2555, its incident notification duties apply in addition. Neither duty is affected by an agreement between the group and a researcher.

Article 12 of Directive (EU) 2022/2555 organises coordinated vulnerability disclosure in the Union and provides for a CSIRT designated as coordinator between the person reporting a vulnerability and the entity concerned, as well as for a European vulnerability database. A researcher may report through that coordinator instead of, or in addition to, the address given above, and the group cooperates with a CSIRT acting in that capacity. Nothing in this policy transfers to the group a right over the text a researcher publishes.

The group operates no bug bounty programme and pays no reward for a vulnerability report. What it offers is recognition, and recognition is given on request: a researcher who does not ask to be named is not named.

Credit states the name or handle chosen by the researcher, the date the report was received and the severity retained, and it appears in the published disclosure of the vulnerability concerned. On request, Group Security also issues a written confirmation of the finding, of the severity retained and of the way the report was handled, addressed to the researcher. A researcher who asks for anonymity is granted it, including in the published disclosure, and a request to be credited may be made or withdrawn at any time before publication.

RFC 9116 defines a file, served at /.well-known/security.txt, stating where a report is sent, where the policy is found, which languages are read and when the file expires. That file is not published for the assets within the scope: the reporting address, the languages and the deadlines that apply are those set out in this document. Where the file is published, it will be maintained by Group Security, will carry the Contact, Expires, Policy, Preferred-Languages and Acknowledgments fields, and will refer to this document.

This policy is amended by Group Security. Each amendment carries a new version number and a new review date, both shown at the head of this document. A report is handled under the version in force on the date it was acknowledged, and an amendment does not withdraw a commitment given under an earlier version in respect of a report already received.

This document covers the web estate within the scope and does not stand in for a product-level policy. Where the group places on the market of the European Union a product with digital elements within the meaning of Regulation (EU) 2024/2847, that product carries its own coordinated vulnerability disclosure policy and its own reporting obligations, and the policy applicable to the product prevails for that product.