MaxPatrol O2
Company: Positive TechnologiesBug bounty program for MaxPatrol O2
Rewards are paid to individual entrepreneurs and self-employed persons
Program description
Bug bounty program for MaxPatrol O2
MaxPatrol O2 is designed to automatically detect and handle security incidents in an organization's IT environment.
MaxPatrol O2 streamlines the work of cybersecurity teams by automating incident detection and much of the incident management workflow. Its web interface provides detailed visibility into attacker activity and includes tools to investigate incidents quickly. This improves incident response efficiency, supports timely remediation of security threats, and strengthens overall IT infrastructure security.
Limitations
When the program launches, access to the product's test environments will be limited.
Broader access will be provided later, once the supporting infrastructure and operational procedures are finalized.
Broader access will be provided later, once the supporting infrastructure and operational procedures are finalized.
General information
Types of vulnerabilities eligible for review. We accept vulnerability reports in the following categories (including, but not limited to):
1. Web interface and API
- Authentication/authorization bypass in the O2 management interface that results in access to another tenant's or administrator's data and functionality.
- Cross-site scripting (XSS) in any input field that allows an attacker to hijack an administrator's session.
- Server-side request forgery (SSRF) in integration features that allows attacks against internal O2 components or connected sensors.
- Insecure deserialization in an API used to exchange data between O2 components and sensors, which may result in remote code execution (RCE).
2. Analysis core (Threat Modeling Engine)
- Tampering with Threat Modeling Engine data in a way that causes an incorrect attack graph and creates defensive blind spots.
- Bypassing event correlation so that malicious activity is not detected (for example, crafting events that O2 cannot reliably correlate into an attack chain).
- Altering or corrupting asset, vulnerability, or network topology data, leading to incorrect risk scoring of activity chains.
3. Integrations and sensors
- Tampering with data delivered to O2 from sensors (MaxPatrol SIEM, EDR, PT NAD, or other tools), leading to false alerts or concealment of attacks.
- Remote code execution (RCE) through the processing of files received from integrated systems (for example, if files are analyzed in PT Sandbox).
- Weaknesses in context enrichment functionality, such as SSRF when O2 queries external services to validate IP addresses or file hashes.
4. Automated response
- Unauthorized execution of response playbooks that may disrupt business processes (for example, disabling network nodes or user accounts via the integrated EDR tool).
- Evasion of response playbooks that enables an attacker to persist even after detection.
Note. Findings that do not present a practical security risk (for example, purely theoretical issues or reports without exploit validation) may be rejected or treated as informational and are not eligible for a bounty payout.
Rewards
Payout amounts are listed in the table below:
| Severity | Payout amount |
|---|---|
| Critical | RUB 300,000–500,000 |
| High | RUB 150,000–300,000 |
| Medium | RUB 50,000–150,000 |
| Low | RUB 0–50,000 |
Rewards are paid only for attack scenarios that can be reproduced on an officially supported product version that is fully patched with all available updates. Reports for end-of-support versions are accepted as well, but a payout for such issues is not guaranteed.
Vulnerability severity is assessed during triage and validation based on the issue's impact on the product security.
The product security team makes the final severity determination.
The product security team makes the final severity determination.
Participation requirements
Participants must be at least 18 years old.
Researchers aged 14–18 are allowed to participate only if they can present the written consent of a parent or a legal guardian.
Current Positive Technologies employees, as well as former employees whose employment ended less than three years ago, may take part in the program but are not eligible to receive a bounty payout.
Researchers aged 14–18 are allowed to participate only if they can present the written consent of a parent or a legal guardian.
Current Positive Technologies employees, as well as former employees whose employment ended less than three years ago, may take part in the program but are not eligible to receive a bounty payout.
Participant obligations:
- Follow the vulnerability disclosure rules of the Positive Technologies program and the Standoff 365 Bug Bounty platform.
- Follow the rules related to the handling of sensitive information. Do not gain access to data belonging to another user without the user's permission, change or destroy the data, or disclose any sensitive data obtained inadvertently during the vulnerability testing process or exploit demonstration. Deliberate access to sensitive data is prohibited and can be deemed illegal.
- Maintain communication with the security team, send them reports on discovered vulnerabilities according to the program requirements, and provide feedback if they have questions about the report.
- Do not publicly disclose any details of the vulnerabilities discovered. Positive Technologies retains the right to decide if and when information about the reported vulnerability will be published.
- Public disclosure of a vulnerability is allowed only after a fix is released and a publicly registered CVE/BDU identifier has been assigned.
- If a researcher requests disclosure of the report, Positive Technologies will initiate the coordination process to register a vulnerability identifier.
Rewards for reported vulnerabilities
No reward will be given for:
- Reports generated by security scanners and other automated tools.
- Disclosure of non-sensitive information (such as software name and version or technical characteristics and metrics of the system).
- Information about IP addresses, DNS records, and open ports.
- Reports of issues and vulnerabilities based on the product version without demonstrating exploitation.
- Reports of vulnerabilities whose exploitation is prevented by security tools, if the researcher does not demonstrate how to bypass the security tools.
- Reports of insecure SSL/TLS ciphers without demonstrating exploitation.
- Reports indicating the lack of SSL or other best current practices (BCPs).
- Reports of vulnerabilities already reported by other participants (duplicate reports).
- 0-day or 1-day vulnerabilities identified by our security team based on information from open sources.
- Reports of brute-force vulnerabilities without providing an attack method that is significantly more efficient than a straight-forward brute-force approach.