> This is part 1 of 2 of the full documentation (pages 1–100 of 150). > The content is paginated: fetch every part to see all of it. > Next part: https://docs.inopli.com/llms-full.txt/1 > Page index: https://docs.inopli.com/llms.txt # Understanding Inopli Inopli represents the forefront in security incident management platforms, integrating efficiency and cutting-edge technology into a unique centralized system. Meticulously designed, the Inopli solution transforms the monitoring and administration of alerts and incidents, providing a comprehensive and detailed perspective of security vulnerabilities. This platform is an ally for organizations of any scale, maximizing productivity and reducing operational costs. Inopli alert management engine was specifically created to enhance the accuracy of manual work. It acts as an advanced filter, drastically reducing the incidence of false-positive alerts, an innovation that not only boosts the efficiency of security teams but also optimizes resources, resulting in a substantial reduction of operational costs. {% embed url="" %} Inopli Solution {% endembed %} *** # First Access After your account is created by your administrator, you will receive an email to set up your access password.

Video demonstrate how create your password into Inopli — How create your password

Once set, you can log in to Inopli using your credentials. {% embed url="" %}

Video doing login into Inopli — Doing login into Inopli

Now you are able to use and there are not additional configurations required to access the system. *** # Modules # Response Module ## SIEM Management Inopli revolutionizes the way SIEM solutions are configured and deployed. With an innovative approach, Inopli offers automated installation, minimizing the need for manual intervention and significantly reducing errors. Provide an easy and effective integration with any existing SIEM solution, unifying the management and visibility of active SIEMs.

*** ## Automated Triage Inopli’s automated triage engine leverages artificial intelligence to process and analyze alerts with exceptional precision. With its advanced capability to eliminate up to **97.5% of false positives**, Inopli intelligently identifies and discards duplicate or irrelevant alerts, transforming the triage process into a fully automated and highly efficient operation. AI-driven correlation models continuously learn from historical data and analyst decisions, improving the platform’s ability to detect meaningful patterns and prioritize what truly matters. The response and investigation of alerts are also automated, guided by adaptive rules that accelerate the workflow and eliminate redundancies, resulting in a substantial reduction in operational workload. This efficiency is achieved through **six critical behavioral criteria** used by Inopli to determine the relevance and automation potential of each alert. These criteria, combined with the AI treatment process, allow the platform to adapt dynamically to each client’s operational context, delivering a more **accurate, agile, and reliable cybersecurity environment** for organizations of any size.

Critical criteria to identify the need for automation

* Is the same attack generating a considerable number of alerts? * Is the alert associated with a larger-scale attack? * Does the alert refer to an incident waiting for resolution, currently being treated, or a previously resolved incident? * Can the alert be evaluated based on existing security intelligence? * Is the alert related to a documented correlation rule? * Is the documentation of the correlation rule adapted to the impacted client?

These criteria allow Inopli to accurately identify the nature and relevance of each alert, ensuring a **rapid and precise response.** At the same time, the platform adapts its functionality to meet the specific needs of each client. The result is a more effective, agile, and reliable cybersecurity environment for organizations of all sizes.

Dashboard for management of processed alerts

*** ## Incident Management **Inopli** enables meticulous tracking of SLAs, ensuring that each incident is managed in strict accordance with established service priorities. Through its sophisticated interface, users can follow the complete lifecycle of every incident, observing all changes and updates in real time. Inopli stands out for its ability to organize the priority queue based on a severity model that dynamically adapts to each client’s specific context. This ensures that the most critical incidents receive immediate attention, optimizing both response and resolution times. To enhance operational intelligence, Inopli introduces the **Post-Incident Assessment** feature, powered by artificial intelligence. This module automatically performs an initial evaluation of each incident, identifying potential root causes, affected assets, and incident patterns. The AI’s assessment is directly added to the incident record, providing analysts with an informed starting point for investigation and reducing the time required for manual analysis. In addition to offering both macro and micro perspectives of the service process, Inopli links incidents directly to their corresponding playbooks, ensuring consistent, guided response actions. This integration, combined with AI-driven assessments, significantly accelerates response time and enables analysts to focus on effective problem resolution with maximum precision and efficiency.

*** ## Documents Management Inopli empowers users to efficiently create and manage correlation rule documentation. These rules are vital for classifying and prioritizing incidents, enabling more effective monitoring and a quick, accurate response to potential threats. Thanks to its flexible and adaptable design, Inopli's correlation rules can be easily integrated into any SIEM (Security Information and Event Management) system, significantly enhancing interoperability with various security monitoring solutions. Furthermore, Inopli offers robust features for creating and managing incident response playbooks. These playbooks cover all stages of the incident response lifecycle, from initial detection and analysis to containment, eradication, and recovery. Having detailed and well-documented procedures is crucial not only for providing clear guidance to security analysts but also for ensuring the uniform application of best security practices. This not only increases operational efficiency but also ensures compliance with corporate regulations and industry standards.

*** ## Process Automation By automating the Threat Hunting process, the Security Operations Center (SOC) team is liberated to focus on more complex challenges and high-level tasks. Inopli plays a crucial role in this respect, adopting a proactive strategy in identifying new correlation rule opportunities. Utilizing advanced and predefined scripts, it analyzes large volumes of data from monitored sources, searching for innovative and significant correlations. Upon discovering a potential correlation, Inopli integrates this finding into its rich knowledge base and signals to the specialized team the need to develop and implement the rule in the system. In the SIEM (Security Information and Event Management) Management phase, Inopli employs a specialized agent to oversee the health of servers running solutions like SIEM. This aspect is fundamental for the early identification of failures or disruptions. Through carefully crafted scripts, Inopli performs detailed health assessments, detecting anomalies with exceptional precision. In adverse situations or upon the emergence of problems, Inopli ensures immediate communication with the responsible team, providing a quick and efficient response, crucial for maintaining the security and integrity of the system.

*** ## Quality Management It is possible to track the efficiency and performance metrics of the system and the team through performance indicators already configured in the Inopli dashboards. Among these indicators, there are:

MTTD (Mean Time to Detect)

This is the average time required to detect a problem after it has occurred. A reduction in this time implies faster identification and response to incidents, minimizing potential damages.

MTTR (Mean Time to Respond)

This is the average time it takes to respond to an incident after it has been detected. A shorter MTTR indicates a more agile and prepared team to handle incidents.

MTTC (Mean Time to Contain)

This is the average time to contain an incident once it has been identified. A reduction in this time limits the spread of damage.

MTTR (Mean Time to Repair)

This is the average time required to fix an issue after it has been contained. A reduction in this time can lead to quicker recovery and fewer service interruptions.

Compliance with SLA (Service Level Agreement)

This metric highlights the proportion of cases where the agreed-upon service levels were met. It plays a vital role both in ensuring customer satisfaction and in preventing contractual issues.

Number of Incident Response Playbooks

This is the total number of Incident Response Playbooks implemented in Document Management, reflecting the team's ability to handle a variety of situations.

Workload Reduction

This metric shows the amount of work saved through automation and other efficiencies.

Incident Response Playbooks Coverage

This indicator measures the percentage of Correlation Rules that have documented Incident Response Playbooks. A high percentage reflects thorough preparation and a more structured response system.

Qualitative Assessment in Inopli

For a qualitative assessment, Inopli has implemented a feedback system within Incident Management. This system tracks the progress of operational maturity through adaptable metrics, allowing leadership and senior cybersecurity staff to thoroughly assess team performance. The assessment process is divided into 3 stages for a comprehensive and fair analysis.\ \ An incident response rating, ranging from 1 to 5 stars, is generated based on this assessment. This rating serves as an immediate indicator of performance and response quality. Inopli uses this data to establish quality indicators for each analyst's incident response. These indicators support ongoing, in-depth analysis of team effectiveness, help identify areas for improvement, and track progress over time.

*** ## Request Management Inopli features an advanced automated system for evaluating standard requests, offering instant and accurate analyses. This functionality ensures that all client requests are handled with agility and efficiency, maximizing customer satisfaction and operational effectiveness. Through centralized management, we facilitate collaboration and communication within your team, providing continuous and high-quality service to clients. This system ensures that the entire cybersecurity operations team acts in a synchronized and cohesive manner, addressing client needs with a unified and well-coordinated strategy. Therefore, our integrated approach optimizes the management of client requests, making the process more efficient and less prone to errors or delays. Our solution is designed to simplify and speed up customer service, ensuring fast and precise responses to all requests.

*** ## MITRE Integration The automated assessment of MITRE ATT\&CK provides a clear and comprehensive view of your organization's cybersecurity landscape. Consequently, all security incidents are tagged with the MITRE domain, aligning with the customer's individualized MITRE map. This enables your cybersecurity team to: * Evaluate and enhance the maturity of your continuous monitoring. * Gain in-depth knowledge of Tactics, Techniques, and Procedures (TTPs). * Implement proactive threat hunting measures, increasing the chances of prompt breach detection. This strategic perspective on monitoring maturity offers valuable insights into the organization's readiness to handle existing and emerging threats. It empowers security teams to focus on continuous improvements, thereby strengthening the overall cyber resilience of the organization.

*** # DRP Module # Configuring the MSS Inopli has been designed to offer customization and scalability, meeting the specific requirements of the MSS. This platform allows for flexible configuration and efficient management of a wide range of customizable parameters. This approach ensures that the system provides a more assertive and efficient visualization of performance indicators and other items that enhance the security routine. With Inopli, users can easily adapt the system to align it with their strategic objectives, facilitating the monitoring and analysis of vital data. Moreover, the intuitive interface and the robustness of Inopli's data analysis tools aid in making evidence-based decisions, optimizing processes and promoting more effective management. *** # Configuring the MSP's profile ### Identification In the identification field, you will be able to view key information about your MSS, including details such as the name, corporate name, and CNPJ. Additionally, contractual information, such as the contract number, MSS exclusivity, and level, is managed and edited by Diazero Technologies administrators. If any of this information is incorrect, please contact us. We are here to assist any issues.

*** ### Default SLA A default SLA is a dedicated storage space for the standard SLAs of MSS client companies. You can register values by severity for incidents and requests.

*** ### Incident Management The Incident Management area defines the necessary values for customizing the automation of various workflows related to the handling and treatment indicators of incidents. 1. **Automatic Incident Reminder:** Specify after how many days a reminder message should be sent to prompt the analyst to interact with the open incident. 2. **Automatic Incident Completion:** Specify after how many days an open incident without interaction should be automatically marked as complete. 3. **Reasonable Time To Respond An Incident:** Define an ideal time parameter, in minutes, for responding to an open incident. 4. **Incident Inactivity Notification Time:** Specify the daily time at which the processing of notifications or closure of open incidents without activity should be executed.

*** ### Rule Identification Code This is where you define the customized prefix for correlation rules to be created in the system. Typically, it consists of 2 or 3 letters.

*** ### Preferences Reserved space for general system preferences. 1. **Rules Status:** Indicates whether correlation rules with an incomplete status can be activated. 2. **Ideal Time For Support Assistance:** Define, in minutes, the ideal response time to a customer's message in the chat.

*** ### Logo The MSS logo will be uploaded, which will be used throughout the system.

*** # Request Categories Request Profiles screen is a dedicated interface for creating and editing request profiles. These profiles can be filtered, activated, deactivated, deleted, and linked to companies, offering 100% customization to meet client-specific needs. It enables the mapping of the most frequent requests and the definition of the information flow required from the user. This approach streamlines problem resolution, making it faster and more efficient. Additionally, the system allows for configuring the responses to assign a level of criticality to each request.

List of Request Profiles

*** ### Creating a Request Profile When creating a profile, it's essential to provide a name and description. The flowchart outlines the user's journey when initiating a request, aiding in retrieving relevant information. Certain stages allow defining the criticality of the ensuing request. Adding a new stage to the flow is as simple as clicking the '+' sign. In every stage the user's response is mandatory. #### Types of Stages {% tabs %} {% tab title="Title" %} This is the first stage of the flow, where a standard question is posed. The user's text response forms the title of the request.

{% endtab %} {% tab title="Question" %} This second standard stage, where you can set the main question to be answered for different 'Response' stage types.

{% endtab %} {% tab title="Response" %} At this stage, the criticality of the request is determined. It presents the user with fixed response options to the 'Question' stage, typically in a select format.

{% endtab %} {% tab title="Text" %} A stage for open-ended questions.

{% endtab %} {% endtabs %} To complete this flow, connect all stages to form a continuous sequence leading to the 'Create Request' stage. Once the flow is finalized, it can be linked to companies that will use it as their request flow. {% hint style="warning" %} Remember: Each company can only be linked to one request profile. {% endhint %} *** # Policies Policies section in Inopli offers an advanced text editor, specially designed for the development and documentation of business policies. This tool is focused on the operational area, acting as an essential guide for the execution of specific processes. In Inopli, users can customize policies for two main workflows: 1. Incident Response: establishes clear procedures for incident handling. 2. Creating Correlation Rules: guides the structuring of internal rules. The editor itself is intuitive and similar to text editing platforms, offering a range of text formatting options, including bold, italic, lists, and much more. These features allow users to highlight the most critical parts of the policies, ensuring that important points are easily identifiable and understood. With this tool, Inopli facilitates the creation of clear and effective guidelines, which are fundamental for the safe management and operationalization of business activities.

*** # Managing Integrations The Inopli integration system is very flexible, offering compatibility with the most popular and widely used systems. Each integration is designed to amplify the functionalities of Inopli, providing an even more productive experience. In the this section, users have the capability to configure and manipulate various types of integrations. These integrations can be filtered, activated, deactivated and deleted, offering 100% customization to meet client-specific needs.

To enable ChatGPT in Inopli, you need to register the access token number provided by your ChatGPT account. See below which field to enter the access token:

*** # Slack Slack is implemented as a solution for notifying and auditing events that are triggered by predefined triggers on the integration page. These triggers are activated through a simple selection. Ensuring agile and precise communication within the team. To set up the integration with Slack, it is essential to provide the pre-configured Bot Token and Chat Id from Slack.

Following this step, simply choose from the predefined options which events you wish to monitor through the integration, tailoring the setup to your specific needs and preferences.

Predefined options to monitor through integration.

*** # Telegram Telegram is implemented as a solution for notifying and auditing events that are triggered by predefined triggers on the integration page. These triggers are activated through a simple selection. Ensuring agile and precise communication within the team. To set up the integration with Telegram, it is essential to provide the pre-configured Bot Username and Bot Token from Telegram.

Following this step, simply choose from the predefined options which events you wish to monitor through the integration, tailoring the setup to your specific needs and preferences.

*** # Google Chat Google Chat is implemented as a solution for notifying and auditing events that are triggered by predefined triggers on the integration page. These triggers are activated through a simple selection. Ensuring agile and precise communication within the team. To set up the integration with Google Chat, it is essential to provide the pre-configured Key, Token and Space from Google Chat.

Following this step, simply choose from the predefined options which events you wish to monitor through the integration, tailoring the setup to your specific needs and preferences.

*** # E-mail The integrated email sending system in Inopli allows for notifications and auditing of events triggered by predefined triggers on the integration page. The activation of these triggers is simplified, ensuring agile and accurate communication within the team. Additionally, it offers the [possibility to configure automatic emails for reports](/) on vital system indicators, with flexibility in both the frequency and content of these reports, adapting to the specific needs of the user. For the email system configuration, simply enter the emails that should receive the information.

Following this step, simply choose from the predefined options which events you wish to monitor through the integration, tailoring the setup to your specific needs and preferences.

{% hint style="info" %} For more information about [**Automated Reports**](/) access our article. {% endhint %} *** # Data Sources In the this section, users have the capability to configure and manipulate various data sources, which generate information in the form of events. These data are captured by the Security Information and Event Management (SIEM). Once collected, they are processed and analyzed to determine whether they constitute a security incident or not. This decision depends on the analysis conducted by the alert handling engine, which is configurable to meet specific criteria.

Users can view a paginated list of all created data sources. This screen provides the functionality to filter data sources based on their status, whether active or inactive. This initial dashboard is designed to facilitate the administration of data sources, allowing users to change the status, edit the settings of a specific data source, or delete it with just a few clicks. {% hint style="info" %} **Data Source** is any location, system, or device where data is generated or stored. This includes servers, network devices, applications, databases, file systems, and even cloud services. It is used as feeding security tools and systems with real-time or near-real-time information. This includes Intrusion Detection and Prevention Systems (IDS/IPS), Security Information and Event Management (SIEM) systems, and network behavior analysis solutions. {% endhint %} *** ### Creating a Data Source #### Identification When creating a data source, it's essential to provide a name and description.

#### Event Types It is possible to associate patterns of events (event types) detected in a data source, which share a history or similar behavior, with the goal of identifying and mapping anomalies. These patterns will serve as a reference in the development of correlation rules. This significantly enhances the efficiency of processing and uniformity in incident generation, contributing to a quicker and more accurate response to potential threats.

{% hint style="info" %} **Event Type** is a classification used to describe the nature of an event detected by data sources. Help security analysts understand what happened, why it happened, and how it should be addressed. It can be classified into various categories, such as unauthorized access attempts, system failures, configuration changes, suspicious network activities, application errors, and others. Each category represents a distinct event type with specific implications for security. {% endhint %} #### Config Files It functions as a repository containing files used to ensure normalization and standardization among clients during the implementation of the SIEM, which will be involved in processing correlation rules. It is possible to load files in .xml, .config, or .json formats. Additionally, the system allows for the consultation of previously modified versions of these configuration files, facilitating the management of changes over time.

*** # Roles Users can view a paginated list of all created roles profiles. This screen provides the functionality to filter roles based on their status, whether active or inactive. This initial dashboard is designed to facilitate the administration of roles, allowing users to change the status, edit the role profile, duplicate a role profile, or delete it with just a few clicks. ### MSP's Roles It is possible to create specific roles for each MSP, allowing for more detailed and centralized administration.

### Roles for Companies It serves as a pre-configured set of access rule standards, established by the MSS. These standards act as access profile templates for companies, significantly simplifying the access management process for clients. With this repository, businesses can quickly implement access profiles, ensuring a more efficient and standardized administration of security policies in their operations.

{% content-ref url="/pages/sjSZv5OtsQFxq84UvAqi" %} [Creating a Role](/system-settings/configuring-the-mss/roles/creating-a-role) {% endcontent-ref %} *** # Creating a Role ### Identification When creating a role, it's essential to provide a name and description.

### Permissions Where detailed configurations are made regarding which permissions will be granted to a specific profile, among the options of product, category, or functionality. This area provides filtering tools, allowing users to search for and select permissions either by name or through direct selection. This system facilitates the assignment of permissions, ensuring more precise control over access to different parts of the product.

*** ### Companies (Only for Roles for Companies) This space is dedicated to the activation of clients who can use the profile as a template. In a practical way, through a switch, it is easy to select which companies will have access to this template model as an option for use.

*** # Managing Companies Inopli offers a great solution for company management, providing an intuitive control panel that allows access to an organized and paginated list. This panel includes useful filters, such as activity status (active or inactive), specific roles, and a search bar for custom queries. It also simplifies the editing and deletion of companies. This functionality eases administration, allowing for the customization of the experience according to the unique needs of each client.

*** # Configuring the Company's profile ### Identification In the identification section, a view of the important information of the companies is provided, including details such as name, corporate name, CNPJ (Brazilian National Registry of Legal Entities), telephone number, postal code, and full address. This area facilitates quick and efficient access to the essential data of each company. This information is managed and edited by Diazero Technologies administrators. If any of this information is incorrect, please contact us. We are here to assist any issues.

Company's Profile Identification Section

*** ### SLA The Service Level Agreement (SLA) section provides the option to customize SLA values for resolving incidents and requests, based on the severity and/or criticality of each case. Additionally, it's [easy to adopt the SLA standards previously set in the company's MSS profile](/system-settings/configuring-the-mss/configuring-the-msps-profile#default-sla), using an activation switch for a simplified and efficient setup.

*** ### Logo With an intuitive drag-and-drop feature, it's possible to personalize the company profile by uploading its logo in either .png or .jpg formats.

*** # Company's Roles In addition to the standard roles provided by the MSS, it is possible to create specific roles for each company, allowing for more detailed and centralized administration. Both types of roles - those provided by the system and those custom-created - will be displayed in a paginated list, with advanced filtering options. Furthermore, these roles come with practical functionalities for activation/deactivation, editing, and deletion, simplifying the management and customization of system access.

{% content-ref url="/pages/sjSZv5OtsQFxq84UvAqi" %} [Creating a Role](/system-settings/configuring-the-mss/roles/creating-a-role) {% endcontent-ref %} *** # Managing Company's Integrations The setup of integrations with major messaging services enables the client to have control over notifications and/or auditing. The process to establish these integrations [is similar to that already configured for the MSP profile](/system-settings/configuring-the-mss/managing-integrations), ensuring a user-friendly experience.

{% content-ref url="/pages/VIc1NTrGFoYrk3gU9ByE" %} [E-mail](/system-settings/configuring-the-mss/managing-integrations/e-mail) {% endcontent-ref %} {% content-ref url="/pages/wSLd0oVFHe52mqeQFMqg" %} [Google Chat](/system-settings/configuring-the-mss/managing-integrations/google-chat) {% endcontent-ref %} {% content-ref url="/pages/RVAUa8DSXGdG2Sp234gv" %} [Slack](/system-settings/configuring-the-mss/managing-integrations/slack) {% endcontent-ref %} {% content-ref url="/pages/JXpaITAcaLc4i2scbMJq" %} [Telegram](/system-settings/configuring-the-mss/managing-integrations/telegram) {% endcontent-ref %} *** # Monitoring Systems This interface in question is designed to efficiently manage the monitoring systems associated with the company. It offers comprehensive compatibility, ***allowing integration with any vendor***. This interface facilitates the management of each SIEM individually. Users can view all the integrations established with the company in an organized and paginated manner. Furthermore, the interface provides simplicity in editing the activation status, in deleting existing integrations, and in adding new integrations. {% hint style="info" %} **Monitoring System** is designed to function as a central repository, collecting and processing all events from various data sources. It plays a crucial role in the organization and analysis of these events. A powerful correlation mechanism, built on the principles of Boolean algebra, continuously searches for patterns indicating anomalies. Once detected, these anomalies trigger alerts with unique identifiers based on the used Boolean algebra. These identifiers are integrated into our relational system to link the detected events to their respective correlation rules. {% endhint %}

*** ### Creating a new monitoring system integration #### Identification When creating a monitoring system integration, it's essential to provide a name and description.

#### Vendor Each vendor has their own standard for configuring integrations, and our system is versatile enough to connect with any SIEM.

#### Servers Our system enables the registration and continuous monitoring of the status of servers supporting the monitoring solution. This feature allows Inopli to have a detailed understanding of the architecture and function of each server. Management is optimized through a paginated listing interface, which includes advanced filtering features, as well as options to maintain, edit, or remove the 'active' status of servers. Additionally, Inopli provides a specialized agent to be installed on the servers. This agent is responsible for constantly monitoring the server's health, ensuring its continuous operation. In case of any issues, Inopli automatically intervenes to make corrections, ensuring that the server remains functional without interruptions.

To register a new server in our system, it is necessary to provide essential information such as the agent's token, a fullname of the server, and its intended function. After this step, it is possible to link Threat Hunting and Health Check profiles to the server, as needed. These profiles are essential for ensuring efficient monitoring and maintaining the server's health.

*** # Managing User Access # Creating MSP's user accounts Viewing all registered users in an MSP is efficient and organized. The interface allows for paginated navigation and offers intuitive filters for activation status, access profile, and language. There is also a quick search functionality for the user's name. User management operations allow for easy activation, deactivation, deletion, password resetting, or profile editing.

To register a new user, it is mandatory to provide a first name, last name, and an email address. Additional information, such as phone number, preferred language, and avatar, can be added to enhance profile identification. {% hint style="warning" %} The email must be unique on the platform. {% endhint %}

The concept of 'roles' is crucial, defining the access levels and responsibilities of the user on the platform. After setting up the profile, the user will receive an email with the necessary details for the first access.

{% content-ref url="/pages/0mjABzcxr7BsAE7w5LHJ" %} [First Access](/getting-started/first-access) {% endcontent-ref %} *** # Creating end user accounts Viewing all registered users in a company is efficient and organized. The interface allows for paginated navigation and offers intuitive filters for activation status, access profile, and language. There is also a quick search functionality for the user's name. User management operations allow for easy activation, deactivation, deletion, password resetting, or profile editing.

{% content-ref url="/pages/0mjABzcxr7BsAE7w5LHJ" %} [First Access](/getting-started/first-access) {% endcontent-ref %} *** # Rules Inopli serves as a central hub for operational documents, used to optimize incident processing. This centralization facilitates the documentation and management of correlation rules, making them more accessible and efficient in the operational context. The system integrates with the alert engine, using the information from the correlation rules to initiate incident procedures. This integration not only allows the automatic opening of incidents based on the generated alerts, but also supports incident grouping strategies. This ensures compliance with recognized market frameworks, ensuring best practices and operational standards. It is mandatory that the correlation rules are properly configured and active. In the absence of these rules, the system cannot identify the necessary information to open an incident, ignoring the alerts. *** #### **Dashboard:** Provides a view of the indicators related to the status of the correlation rules. Users can identify which rules are active and which are inactive, crucial information in the listing of the set of registered rules, and it is possible to add, edit, remove, and deactivate rules, facilitating management and real-time monitoring.

*** #### **Mind View:** Mind View presents an intuitive visual interface for the correlation between the structure of monitored data sources and the types of events detected during the threat hunting process. Allowing the visualization of the correlation rules registered in the environment. Through this visualization, it is possible to identify gaps resulting from the absence of correlation rules, preventing relevant incidents from going unnoticed. In the context of MSPs, Mind View plays a critical role, becoming a valuable deliverable for customers.

*** # Main It is the first stage for create a rule correlation. *** ### **Identification** **ID:** Each rule is automatically identified by an ID, which [is generated according to the prefix set during the MSP configuration.](/system-settings/configuring-the-mss/configuring-the-msps-profile#rule-identification-code) **Language:** The system allows versions in different languages within the same profile, providing a customized consultation according to the user's language preference. **Name:** Serves for the direct identification of the rule. **Attack:** Defines the attack vector that the rule aims to prevent or mitigate. {% hint style="info" %} The name and attack fields are essential for integration with systems like ChatGPT, facilitating the automatic filling of playbooks and rule details. {% endhint %}

*** ### **Data Source** **Data Source:** Identifies the data source of the selected correlation rule. **Event Type:** There are two main types of events in information security: * **Security Intelligence Events:** Associated with data sources that have security intelligence (e.g., endpoint protection or application firewalls) and are usually linked to specific threats. These do not require complex correlation rules for anomaly identification. * **Non-Security Intelligence Events:** Related to data sources without security intelligence (e.g., operating systems), which require more complex correlation rules. In these cases, the analyst must create custom event types for these data sources.

*** ### **Integration** It is possible to prepare the rule for one or more monitoring solutions. The selection of vendors directly impacts the listing of relationships and grouping rules (grouping rules).

*** ### **Relations** This functionality provides the system with information about which SIEM rule relates to the correlation rule. This allows for more efficient management and an integrated view of security policies.

*** # Monitoring Systems ### **Rule Profile** Offers the ability to customize rules according to the specific needs of the company using the service. This customization ensures that the rule is aligned with the operational and security requirements of the organization.

*** ### **Documentation** **Description**: specific details of the applicability of the correlation rule. **CVSS (Common Vulnerability Scoring System):** an open standard for assessing the severity of security vulnerabilities in information systems. It provides a numerical score that reflects the severity of the vulnerability based on various criteria, such as impact and ease of exploitation. Integrating CVSS into monitoring systems helps prioritize responses to potential threats.

*** ### Monitoring System Profiles It is possible to create specific monitoring system profiles that can later be used to configure the details of each client company.

*** **Vendors** Documents all the details of the SIEM correlation rules from different suppliers. The configuration for each SIEM vendor is done in such a way as to directly reflect the internal configurations of the SIEM. This allows for precise and effective integration between the monitoring system and the specific solutions of each vendor.

*** # Rule Details ### **Incident Description** **Incident Description:** a designated space to insert the description of the incident that will be opened by this correlation rule. **Disable Alert Grouping:** This option, when activated, instructs Inopli to open an independent incident for each unique value identified in the grouping field. If this option is deactivated, Inopli will identify multiple attackers responsible for the same incident and group them together.

*** ### **Grouping** Extremely necessary for the activation of the rule. It determines which field is necessary for Inopli to use in the treatment process, usually the field identifying the origin of the attack, with the possibility of configuring one or more for each SIEM.

*** # Mitre Techniques It is possible to link specific techniques and/or sub-techniques to a correlation rule, enabling the mapping and indicators of security coverage.

*** # Playbooks The dashboard integrates with the correlation rules, providing management of responses to security incidents. Through a paginated list, the dashboard allows for the addition, editing, deletion, and activation of playbooks in an intuitive and organized manner. The ability to activate or deactivate playbooks as needed ensures that responses to incidents are prompt.

*** ## Creating a Playbook ### Identification * **Nome:** Must be descriptive, clearly reflecting the purpose and scope of the playbook. * **Visibilidade:** 1. **DEFAULT:** This category includes general use playbooks. They are designed to be applicable in a wide range of scenarios and companies. 2. **ADVANCED:** Playbooks in this category are customized for the specific needs of a company. They are detailed and focused on particular scenarios, reflecting the policies, infrastructure, and specific security risks of the company.

*** ### Phases of Incident Response It is possible to manage treatment steps for each of the incident response phases, as outlined by the most renowned market frameworks, with the possibility of assigning the responsibility of the stage to the MSP or the company. The stages are: 1. **Preparation:** Prepare the incident response team to efficiently deal with potential threats. (E.g., Team training, creation and updating of documentation). 2. **Identification:** The first active response stage, where the veracity of the incident is determined. Detailed analysis to confirm whether the incident is a false positive or a real threat. 3. **Containment:** Implemented only if the incident is confirmed. Execute measures to prevent the spread of the threat (e.g., isolation of systems or network segmentation). 4. **Eradication:** Identify and eliminate the root cause of the incident (e.g., Removal of malware, correction of vulnerabilities, and strengthening of security controls). 5. **Recovery:** Take the necessary measures to return the environment to normal operation (e.g., Verification of system integrity, data restoration from backups, and post-recovery monitoring).

*** ### Lessons Learned Reserved space to describe strategies in the post-incident analysis to identify improvements in the playbook and security practices.

*** ### Comments Space for the security team to leave notes and important observations about the playbook.

*** ### Versioning Space to document the revision with each update of the playbook, providing a detailed history and an audit trail. {% hint style="danger" %} Whenever the playbook is updated, it is necessary to provide a description of the new version. {% endhint %}

*** # Companies It is possible to activate rules for specific companies tailored to their needs. Each company can select one or more 'Rule Profiles' and 'Monitoring System Profiles' that align with their security policies and operational needs. There is also the option to apply one or more whitelists or blacklists for each company.

*** # Knowledge Lists Knowledge Lists are essential for enhancing the processing of the alert engine, aiming to reduce false positives in an advanced and customized manner. In the user interface, it's possible to add, edit, filter, delete, and activate conditions as needed.

*** ### White List Prioritized in the handling of alerts, its purpose is to filter the information contained in the alerts. If an alert triggers a mechanism defined in the White List, it will be processed, otherwise, it will be discarded. This helps in identifying legitimate events, reducing interruptions caused by false alerts. *** ### Black List Used to eliminate alerts that trigger any of its mechanisms. This list is effective in discarding alerts associated with events already known to be non-threatening or irrelevant, optimizing the efficiency of the monitoring system. *** ### Creating a List Both lists follow same creation process, with a form that includes a name, description, and a list of entries, which can be managed independently.

Each entry must contain: * Name: Identifies the entry. * Monitoring System: Defines which Security Information and Event Management (SIEM) system the rules will be applied to. * Check All: Enables the identification of the value in any field within the alert payload. If deactivated, the identification follows the key-value rule. * Regex: If activated, it detects patterns based on regular expressions in the alert payload; if deactivated, it can search for plain text. * It is possible to add key-value fields to create validation groups using logical operators (and/or), thus establishing a boolean rule scheme.

For the lists to be effective, [they need to be linked to a correlation rule in the "Companies" tab during rule editing.](/response/rules/companies) This link ensures that the knowledge lists are applied appropriately. # Managing MITRE The MITRE ATT\&CK® (Adversarial Tactics, Techniques, and Common Knowledge) is a well-known global framework used for understanding and categorizing tactics, techniques, and procedures (TTPs) associated with cyber threats. In Inopli, it is integrated into a dynamic and adaptable dashboard for security system administrators. This control panel offers an interactive interface, allowing administrative users to add or remove techniques and sub-techniques from the MITRE ATT\&CK framework. This functionality is crucial for keeping the system's database aligned with the latest strategies and changes in the cyber threat landscape. When a new technique is added to the system through the dashboard, it becomes immediately available for use in various functions. This includes application in correlation rules, which are essential for detecting and responding to incidents. Additionally, the newly included technique is also integrated into the MITRE coverage indicator generator, to evaluate the effectiveness of the implemented security measures. The inclusion of updated techniques and sub-techniques ensures an increase in security, as it allows administrators to keep up with emerging trends in cyber attacks. This approach ensures that the team not only keeps its threat database updated, but also strengthens its ability to prevent, detect, and respond to security incidents more effectively.

*** ### Creating a Technique To ensure that the documentation always remains up-to-date, the team has the ability to add new techniques and/or sub-techniques, as well as to delete those that are no longer necessary. In the addition process, a detailed form is used, in which all essential information is requested for the accurate mapping of a new technique, sub-technique, and its respective version. This procedure ensures that each entry is complete, thus facilitating the management and location of information within the system.

*** # Incidents The incidents reflect events that, after being processed, generate alerts and are linked to specific correlation rules. In the initial dashboard, a graph displays the incidents opened in the last 24 hours by severity, as well as a general overview of the incident status and a paginated list. Users can filter incidents by severity, responsible analyst, status, creation date, update date, or search by the name or ID of the incident. The default view lists urgent incidents in an optimized manner, without predefined filters or sort orders.

{% hint style="warning" %} The prioritization in the list follows a standard: incidents with 'NEW' status and the shortest remaining SLA time are shown first, followed by those that had interactions with Mss/Company, and finally, the rest are listed by ID in descending order. {% endhint %} A color palette indicates special situations: * Red: SLA exceeded. * Yellow: SLA 1 hour about to be exceeded. * Green: Incident with a new unread interaction.

*** #### **Important columns into dashboard include:** * SLA: The time agreed with the client, which stops counting when the incident is addressed. * Severity: Organized from INFO to CRITICAL, according to the parent correlation rule. * Status: Indicates the stage of resolution, varying from active, pending, under treatment, and closed. * Rate: The average user feedback, based on various parameters. *** #### Available actions into dashbord: * Escalate Incident: Increases the incident's priority in the list, reducing the SLA. * [Alerts](/response/incidents/alerts): Displays all the alerts that led to the incident. * [Messages](/response/incidents/messages): Allows analysts to follow and participate in the resolution process, sending messages and files, and includes system messages about changes in the incident. * [Rate](/response/incidents/rate): Displays feedback for each analyst involved. *** ### Incident Details Presents important information, links, message history, and activities related to the incident, allowing individual or mass changes in various parameters.

{% content-ref url="/pages/nYykzOSxr93bxfVOZi15" %} [Alerts](/response/incidents/alerts) {% endcontent-ref %} {% content-ref url="/pages/m0oNicfjqfB5lp8ULeIy" %} [Messages](/response/incidents/messages) {% endcontent-ref %} {% content-ref url="/pages/OL60S6SBanae7JG2O7Wy" %} [History](/response/incidents/history) {% endcontent-ref %} {% content-ref url="/pages/eft3Y28tOoDXTxfvkBvk" %} [Playbooks](/response/incidents/playbooks) {% endcontent-ref %} {% content-ref url="/pages/GQ4GQ6IueU8FdATB4uWj" %} [Rules](/response/incidents/rules) {% endcontent-ref %} *** # Alerts All alerts that originated the specific incident are listed, allowing searches for parts of the payload and enabling quick and practical viewing of it.

*** # Messages This functionality is used for communication between analysts and clients. It enables file attachments and tracking of the incident's change history through automatically generated messages. Searches can be conducted for parts of the message or the user's name. Additionally, the status can be changed to AWAITING SERVICE when a response is required to resolve the incident.

*** # History This tool facilitates communication between analysts at the end of shifts or during the handover of responsibilities, providing essential context to the new person in charge of the incident.

*** # Rate After an incident is completed, it's possible to provide feedback to the responsible analysts, with options for detailed viewing and evaluation by both Mss users and Company clients. The rate is between 1-5 points.

*** # Playbooks Users can view all the playbooks applicable to resolving the incident, accessing their versions and downloading the necessary documentation.

*** # Rules The correlation rule that defines the open incident is presented clearly, including a summary of the profile and the most relevant information of the rule.

*** # Requests Users categorized as 'company' make requests directed to 'mss' type users, following a process defined by 'mss' itself. Once created, the requests are organized in a paginated list, prioritized according to established criteria. Additionally, there are filtering and sorting options to facilitate the management of these requests. On the home screen, users can also view a control panel that displays the current status of the treatment of each request, allowing for efficient and organized monitoring.

{% hint style="warning" %} The prioritization in the list follows a standard: requests with 'NEW' status and the shortest remaining SLA time are shown first, followed by those that had interactions with Mss/Company, and finally, the rest are listed by ID in descending order. {% endhint %} A color palette indicates special situations: * Red: SLA exceeded. * Yellow: SLA 1 hour about to be exceeded. * Green: Incident with a new unread interaction.

*** #### **Important columns into dashboard include:** * SLA: The time agreed with the client, which stops counting when the incident is addressed. * Criticality: Organized from LOW to CRITICAL, according to the parent correlation rule. * Status: Indicates the stage of resolution, varying from active, pending, under treatment, and closed. * Rate: The average user feedback, based on various parameters. *** #### Available actions into dashbord: * Escalate Request: Increases the request's priority in the list, reducing the SLA. * [Messages](/response/incidents/messages): Allows analysts to follow and participate in the resolution process, sending messages and files, and includes system messages about changes in the request. * [Rate](/response/incidents/rate): Displays feedback for each analyst involved. *** ### Request Details Presents important information, links, message history, and activities related to the resquest, allowing individual or mass changes in various parameters.

{% content-ref url="/pages/m0oNicfjqfB5lp8ULeIy" %} [Messages](/response/incidents/messages) {% endcontent-ref %} {% content-ref url="/pages/OL60S6SBanae7JG2O7Wy" %} [History](/response/incidents/history) {% endcontent-ref %} *** # Dashboards # Operational Dashboard The operational dashboard, available to 'company' and 'mss' type users, provides up-to-date and detailed information about incidents and requests, facilitating real-time operational monitoring without the need for date filters.

*** ### **General Information** * **Total Incidents/Requests:** Displays the total number of incidents and requests recorded in the system. * **Average Resolution Time:** Calculates the average time from the creation of the incident to its closure. * **Idle Time Between Messages:** Shows the time interval between sending a message and receiving a response.

*** ### Incidents/Requests by Status Presents the distribution of incidents and requests by different statuses.

*** ### **Recent Incidents/Requests** Lists the most recent incidents and requests in the system.

*** ### Incidents/Requests Queue Organizes, by order of priority, the incidents and requests with 'NEW' status.

*** ### General Chart Visually represents the severity and status of incidents/requests received in the last 24 hours.

*** ### Treatment by Severity Groups information of incidents/requests by severity and treatment status.

*** ### Responsibility by Severity Summarizes incidents/requests by severity and current responsible party.

*** ### Interactions Waiting for Response Lists incidents/requests that are marked as 'waiting for response', from the oldest to the most recent, including the waiting time in the queue.

*** ### Analysts by Availability Displays the online/offline status of analysts linked to 'mss/company' users accessing the dashboard.

*** # Executive Dashboard This dashboard, accessible to MSS or company type users, offers detailed indicators on system health and alert processing, with the ability to filter by date ranges. It provides a comprehensive overview of the main aspects of security and operational efficiency.

*** #### **Overall Health** Indicates, in a scaled format, the overall average of Info Security, Risk Exposure, Maturity, and Mitre indicators.

*** #### **Info Security** Average of coverage indicators for relations, event types, and private playbooks.

*** #### **Risk Exposure** Checks the coverage of the time for first treatment, measuring its compliance with the standards set in the setup. The closer to 0%, the better the indicator.

*** #### **Maturity** Average of indicators in the Security Operation graph, rated on a scale of up to 5 points.

*** #### **Mitre** Calculates the coverage of correlation rules for techniques and sub-techniques listed in Mitre.

*** #### **Attack Vector** Visual representation of the treatment of events by data source, their attack vectors, and related results in the confusion matrix.

*** #### Events x Incidents Visual representation of confirmed incidents, arising from events received by the monitoring system, demonstrating effectiveness in reducing manual labor.

*** #### Quality KPIs: * Average Time To Detect An Incident (MTTD): The average time to identify an incident from the generation of the alert. * Average Time To Respond To An Incident (MTTR): A performance indicator of the security team measuring the time from the opening of the incident to the start of treatment. * Average Time To Contain An Incident (MTTC): The time it takes the team from identification to the start of the threat blocking phase. * Average Time To Repair (MTTR): The time required to fix the problems and eradicate the threat, returning the environment to a safe state.

*** #### Incidents By Status Number of incidents distributed by each type of status.

*** #### Confusion Matrix The number of alerts in each status of the confusion matrix.

*** #### Security Operation Visual representation, with a color rule, indicating the compliance level of various indicators, with descriptions available when hovering over their titles.

* **Continuous Monitoring** * **Monitoring Systems** * **Relations:** Coverage of treatment of relations in the correlation rules. * **Data Sources** * **Correlation Rules:** Coverage if each event type is linked to at least one correlation rule. * **Mitre Framework** * **Tactics:** Coverage if each technique has at least one correlation rule. * **Techniques:** Coverage if there is at least one correlation rule linked to the technique. * **Incident Response** * **Playbooks** * **Initial Playbooks:** Coverage if each correlation rule has at least one initial playbook. * **Advanced Playbooks:** Coverage if each active customer has at least one advanced type playbook. * **Continuous Operation** * **SLA:** Contracted SLA coverage percentage coverage. * **Quality of Service:** Maximum average rating coverage. * **Response Time:** Optimal response time coverage. * **Customer Management** * **Continuous Operation** * **Requests:** Coverage of request processing, considering open/closed. * **SLA:** Contracted SLA coverage percentage coverage. * **Response Time:** Optimal response time coverage. * **Automatic Response** * **Automatic Treatment Engine** * **First Response:** Mean Time To Treatment an Alert. * **Workload Reduction:** Workload Reduction in Percentage. {% hint style="warning" %} **Color Standards for Performance Indicators:** * **Green (Excellent Performance):** Indicates a performance that is equal to or greater than 90%. This green color standard is used to represent high efficiency or compliance, signifying that the indicator is operating at an optimal level. * **Orange (Moderate Performance):** Represents a performance between 60% and 89.99%. The orange color is used for indicators that are performing moderately, suggesting there is room for improvement, but the performance is still acceptable. * **Red (Insufficient Performance):** Used for performances below 60%. The red color alerts to an unsatisfactory performance, indicating that the indicator is below an acceptable level and needs immediate attention for improvement. * **Gray (Inactive):** Applied to indicators that are currently inactive. The gray color signals that the indicator is not in use or does not have sufficient data for performance evaluation at the moment. {% endhint %} *** # KPIs Dashboard This dashboard efficiently compiles key performance indicators (KPIs), focusing on engine performance and team productivity. Available for MSS and Company users, it offers date filters for detailed analysis.

*** #### Average Time To Detect An Incident (MTTD) The average time to identify an incident from the generation of the alert. *** #### Average Time To Respond To An Incident (MTTR) A performance indicator of the security team measuring the time from the opening of the incident to the start of treatment. *** #### Average Time To Contain An Incident (MTTC) The time it takes the team from identification to the start of the threat blocking phase. *** #### Average Time To Repair (MTTR) The time required to fix the problems and eradicate the threat, returning the environment to a safe state. *** #### **SLA (Service Level Agreement)** Displays the percentage of services delivered within the [contracted SLA ](/system-settings/managing-companies/configuring-the-companys-profile#sla)parameters. *** #### Workload Reduction Shows the percentage of workload reduction, comparing alerts processed by the initial engine with generated incidents. *** #### Incident Response Procedure Indicates the number of advanced playbooks registered in the system. *** #### Procedure Compliance Compares the total number of rules with those having associated advanced playbooks. ***

*** #### Monitoring System A column chart displays the total number of alerts generated by the solution (SIEM), with a line highlighting the proportional workload reduction.

*** #### Timeline Automatically evaluates all incidents handled over a defined period (30 days or customized), indicating the average response time and related KPIs.

*** #### Data Sources Each column in the chart represents a data source, contrasting the total received alerts with those that are actually relevant.

*** [Confusion Matrix](/response/dashboards/alert-management-dashboard/confusion-matrix#confusion-matrix-indicators)

*** # Alert Management Dashboard This dashboard provides a comprehensive monitoring interface for system-generated alerts. It displays metrics for alerts generated over the past 24 hours and allows users to track the status of alert processing to pinpoint potential errors. Users can annotate alerts to highlight any anomalies and utilize the confusion matrix to identify false positives and true positives, thus assessing the accuracy of the alert generation system. The dashboard is designed to facilitate quick responses with an average alert treatment time prominently displayed, ensuring that issues can be addressed promptly.

*** ### Alert Details Users can view the current processing status of each alert and examine the contents of the payload. Furthermore, it is possible to [adjust the classification in the confusion matrix](/response/dashboards/alert-management-dashboard/confusion-matrix) to refine the system's accuracy and add specific comments to each alert. Should an alert fail, the tool enables reprocessing, ensuring that none are lost or overlooked due to processing errors.

*** # Confusion Matrix "Machine learning" refers to advanced computational systems capable of performing automated analysis and decision-making based on artificial intelligence rules. These systems, programmed to identify patterns and detect anomalies, are essential in various applications, including information security. In the context of our system, we have integrated an alert evaluation engine that uses machine learning. This integration enhances our ability to analyze and respond to security events efficiently. We use the confusion matrix to measure the effectiveness of this technology, a crucial tool in assessing the system's accuracy in correctly identifying specific events. In information security, the confusion matrix is used to evaluate the efficiency of monitoring systems, which use Boolean algebra to automatically identify potential threats. These are then appropriately classified and managed. Commonly in information security, we emphasize the 'true positive' and 'false positive' parameters. True positives indicate real threats correctly identified by the system, while false positives represent erroneous alerts. In our application, we have fully implemented the confusion matrix, which improves quality and increases operational control. These indicators allow us to evaluate the accuracy and maturity of the correlation rules, contributing to the system's evolution. In Inopli, the indicators for the alerts are generated automatically, given by monitoring the entire trajectory of the incident during its treatment. However, we also value flexibility and accuracy. Therefore, [we allow manual updates for each alert. In situations of inconsistencies, analysts can intervene, adding detailed comments that reflect the specific context and characteristics of the incident.](/response/dashboards/alert-management-dashboard#alert-details) *** ## **Confusion Matrix Indicators** This matrix not only categorizes alerts into 'true positives' and 'false positives' but also incorporates other crucial parameters such as Accuracy, F1-Score, Precision, False Positive Rate (FPR), Recall, and False Negative Rate (FNR). [Each of these topics plays a vital role in the detailed analysis of the system's effectiveness:](/response/dashboards/kpis-dashboard) * **Accuracy:** This indicator measures the proportion of correct predictions (both true positives and true negatives) relative to the total number of cases analyzed. It is a general measure of the system's effectiveness. * **F1-Score:** This metric is the balance between Precision and Recall. It is particularly useful when classes are unbalanced. The F1-Score is the harmonic mean of Precision and Recall, providing a consolidated view of the system's performance. * **Precision:** Refers to the proportion of true positives relative to the total number of cases classified as positive (true positives and false positives). This metric indicates the accuracy of the system's positive predictions. * **False Positive Rate (FPR):** This index shows the proportion of false positives relative to the total number of actual negative cases. A high FPR can indicate many false alarms, a critical aspect in information security. * **Recall (Sensitivity or True Positive Rate)**: Measures the proportion of true positives relative to the total number of actual positive cases (true positives and false negatives). It is a crucial metric to understand the system's ability to correctly identify threats. * **False Negative Rate (FNR)**: Indicates the proportion of false negatives relative to the total number of actual positive cases. A high FNR can mean that the system is failing to detect real threats, a significant risk in information security.

By integrating these indicators, Inopli not only efficiently categorizes alerts but also offers a comprehensive view of the system's performance and reliability. These indicators are necessary for ongoing evaluation and improvement of security strategies, ensuring that the system maintains a high rate of accuracy and efficiency in detecting and treating security incidents. *** # Custom Reports The **Custom Reports** feature allows MSSPs and end users to automatically extract structured data from Inopli, focusing on **Incidents** and **Requests**. It ensures full data portability, enabling the export of all relevant records from the platform whenever needed, supporting external analytics, billing, compliance, and audit purposes. **What It Does** * **Automates data export****:** schedules recurring reports so incident and request data is generated without manual CSV/Excel exports. * **Scopes the dataset****:** lets you select the **company** and **reference period** that should be included in each report. * **Defines frequency****:** supports **daily, weekly**, or **monthly** generation at a specific time, aligning exports with operational and reporting routines. * **Notifies stakeholders****:** sends a notification with the generated report to the configured recipients, using the chosen subject for easy identification. * **Controls the schema****:** provides a column selector where you choose the **type** (*Incidents* or *Requests*) and the fields to include, such as `id`, `name`, `severity_name`, `status_name`, `created_at`, `updated_at`, `sla_expiration_time`, and `closed_at`. **How It Works** * In **Report Info**, activate the report, select the **Company**, choose the **Period** you want to export, and add a short **Description** to identify the purpose of that report. * In **Frequency**, choose whether the report will run **Daily, Weekly**, or **Monthly**, and set the exact time (and day, when applicable) for generation. * In **Sent notification to**, define the **Subject** and add the **Recipients** who should be notified every time the report is generated. * In **Columns**, set the **Type** (e.g., *Incidents*) and select the fields that will compose each row of the export, tailoring the dataset to the consuming system or audience.

**Why This Matters** Because the exported data contains the **entire treatment trail of incidents and requests**, each generated file can also serve as a **complete audit trail export**, providing traceability over every recorded action, update, and resolution stage. This capability ensures that operational data stored in Inopli does not remain locked inside the platform. By automating the export of incidents and requests with precise control over scope, frequency, and schema, organizations can integrate Inopli data into BI tools, client reporting, audit processes, and long-term records, maintaining full visibility and ownership over their security operations data. # AI for Incident Analysis Inopli Response incorporates native **Artificial Intelligence (AI)** capabilities designed to support and enhance the incident management lifecycle. The AI engine operates as an analytical layer that assists security analysts by evaluating alerts, correlating security signals, and providing contextual insights to support accurate and timely decision-making. The primary role of the AI within Inopli Response is to perform a **first-level assessment** of alerts and security events. When alerts are received, the AI automatically analyzes related events, historical data, indicators of compromise (IOCs), and contextual attributes to assess relevance, severity, and potential impact. This assessment is generated before formal incident handling and is presented to analysts as a structured reference to guide investigation. The AI engine correlates alerts with previous incidents, ongoing investigations, and known activity patterns. By linking related events through shared attributes such as hosts, users, sessions, and IOCs, the platform reduces alert noise and highlights meaningful security activity. This correlation capability supports faster triage and more efficient prioritization of incidents. In addition to contextual correlation, the AI supports **behavioral and predictive analysis**. By continuously evaluating patterns and trends across security data, the AI identifies deviations from expected behavior that may indicate emerging threats or abnormal activity. This predictive capability enables early visibility into risks and supports proactive security operations. AI-generated insights are fully integrated into the incident management workflow of Inopli Response. The AI does not replace analyst judgment, but augments it by providing consistent assessments, correlations, and analytical context. Analysts use these insights as a foundation for validation, escalation, and response actions, ensuring that decision-making remains controlled, transparent, and auditable. By combining automated assessment, contextual correlation, and predictive analysis, Inopli Response delivers an AI-driven approach to incident analysis that improves efficiency, reduces false positives, and strengthens the overall effectiveness of security operations. # Monitoring Catalog (Overview) Digital Risk Protection (DRP) refers to the continuous monitoring of external digital environments to detect threats that could harm a company’s reputation, executives, brand, or exposed assets. It operates across the open web, deep/dark web, messaging platforms, forums, social media, and app stores seeking signs of impersonation, data leaks, credential exposures, fraud attempts, and other forms of digital risk. Unlike reactive tools that only alert once a breach is underway, DRP is designed to act upstream, flagging risks before they escalate, by identifying early signals in unstructured content such as posts, media files, domains, and digital certificates. The Inopli DRP module applies this principle in a fully automated and scalable manner. It collects and analyzes content from dozens of external sources and transforms it into actionable findings tied to monitored entities like brands, VIPs, and sensitive strings. Through techniques like language detection, entity recognition, similarity analysis, metadata extraction, OCR, and transcription, it enriches each signal with relevant context to support prioritization. Findings are classified by severity and type, enabling security teams to focus on what matters most, before damage occurs. ## What DRP Monitors ### [Communication channels](/drp/comm-channels-monitoring/messaging-and-chats) * Public semi-open and private messengers and chat networks, including Discord, Telegram and IRC. Coverage includes text, links, and shared media (documents, images, audio). Findings are correlated to monitored companies, VIPs, and sensitive strings. ### [Deep/Dark web monitor](/drp/deep-dark-web-monitoring/deep-dark-web) * Monitors relevant resources, crawling pages and scanning internal content (text and media). It applies the same enrichment used elsewhere—OCR for images, archive inspection, metadata analysis, and transcription—to surface findings tied to brands, VIPs, and sensitive strings. ### [Surface web & exposed assets](/drp/surface-web-monitoring/surface-web) * Domain and certificate monitoring via Certificate Transparency (CT) logs to surface new certificates and domain look-alikesand inspects surface content for phishing and leaked or sensitive data, similarity, typosquatting, and bitsquatting analyses highlight impersonation risks. ### Core Detection Themes * Mentions of monitored companies and VIPs across sources, with structured findings that include evidence and context. ### Sensitive strings and secrets * Detection of emails, phone numbers, IPs, payment data patterns, and other sensitive strings; context is used to prioritize alerts. * Purpose-built detection for credential leaks (e.g., user:password pairs), with noise reduction and correlation to monitored entities. ### Threat indicators * Identification of phishing and malware indicators, suspicious commands, and attack patterns in messages, with severity-based prioritization. ### Links and infrastructure clues * URL extraction and parsing (including t.me variations), plus domain/channel derivation to enrich context. ### Media intelligence * **OCR on images** to extract text for correlation. * **Archive inspection** (ZIP/RAR/7z/tar.gz) with recursive extraction and text analysis. * **EXIF/metadata** analysis (e.g., GPS, capture time, device) to add geospatial/temporal context. * **Audio transcription** with multilingual support; transcripts are analyzed like text. ### Language & entity understanding * Automatic language detection across text, OCR, and transcripts. * Multilingual Named Entity Recognition (people, organizations, locations, dates, monetary values, etc.) to enrich findings. # Comm Channels Monitoring The Communication Channels Monitoring component of the DRP module focuses on identifying early signs of digital risk by observing public and restricted conversation spaces such as messaging platforms, group chats, and online forums. Its purpose is to detect potential threats or reputational issues related to brands, executives, and sensitive terms through ongoing analysis of what people are saying and sharing in these channels. The monitoring is continuous and designed to avoid overloading sources, preserving the natural flow of the data being collected. This module captures both text and shared media, including documents, images, and audio. All content is automatically examined to identify names of people or companies, mentions of confidential information, and any indications of malicious activity. Even when this information is hidden inside files, images, or audio clips, the system is capable of interpreting and analyzing them. This allows it to uncover leaks, suspicious conversations, or early signs of coordinated attacks that may not be immediately visible. Each relevant finding is organized in a structured way, with context such as where it was found and how serious it might be. This helps teams quickly understand what matters most and take action when needed. The goal is not just to collect raw data, but to transform unstructured chatter into clear, actionable insights that support digital risk teams in staying ahead of emerging threats. ### **Where DRP looks.** * **Messaging & chats****:** DRP inspects messages and attachments (documents, images, archives, audio), extracts URLs and domains, and correlates mentions to monitored entities. It extends visibility with OCR for images, archive inspection, EXIF/metadata review, and audio transcription. * **Forums & IRC-style communities****:** DRP processes real-time messages and linked media to detect entity mentions (companies/VIPs/Sensitive Srings), sensitive strings, and other indicators. Multilingual entity recognition is applied to add context to each finding. ### Next pages * [Messaging & Chats](/drp/comm-channels-monitoring/messaging-and-chats) * [Forums & Communities](/drp/comm-channels-monitoring/forums-and-communities) * [Risk Signals Detected](/drp/comm-channels-monitoring/risk-signals-detected) * [Enrichment Strategies](/drp/comm-channels-monitoring/enrichment-strategies) # Messaging & Chats The *Messaging & Chats* module is part of the DRP solution focused on identifying digital threats that emerge in informal, high-velocity communication channels. These environments, such as **Telegram**, **IRC**, and **Discord****,** are often used to discuss vulnerabilities, coordinate attacks, or circulate leaked data before such activity becomes visible on broader platforms. By maintaining active monitoring in these spaces, the module helps organizations anticipate and respond to security incidents in their earliest stages. ### What We Monitor This module tracks conversations and shared content in public and private groups where threat actors, hacktivist communities, or information leakers may be active. * On Telegram, it follows discussions in large public channels and groups known for spreading sensitive information. * IRC remains relevant among certain technical circles where tactics, tools, and exploits are often exchanged. * Discord, with its diverse range of communities, also includes servers where information security topics are discussed, sometimes, including confidential or malicious content. ### Why This Matters Real-time chat environments are where many threats first surface, often, hours or days before appearing in traditional intelligence feeds. For security teams, having visibility into these spaces is critical for early detection and proactive defense. This module enhances an organization’s ability to identify and respond to threats involving leaked data, impersonation attempts, exposed credentials, and reputational risks, all in alignment with a broader digital risk protection strategy. # Forums & Communities The *Forums & Communities* module monitors open discussions across the surface web as well as in deep and dark web environments. These spaces, often structured as discussion boards or hidden marketplaces, are widely used by cybercriminals to share techniques, leak stolen data, advertise access to compromised systems, or coordinate fraudulent activities. These forums are a critical source for identifying early-stage threats and emerging attack trends. ### Where We Look On the surface web, the module tracks publicly accessible forums and community platforms where information related to cybersecurity, social engineering, or illicit data exchange may appear. This includes niche websites focused on specific technologies, underground sharing platforms, and open repositories of exposed information. In parallel, the system monitors **hundreds of forums in deep and dark web environments**, where threat actors are more active and less inhibited. These include invite-only communities, marketplaces, and anonymous boards often associated with data leaks, malware distribution, and discussions about targeted attacks against companies or individuals. These forums operate in hidden networks and tend to be volatile, which makes structured monitoring essential for maintaining situational awareness. ### Why This Matters Forums and online communities, particularly, those in the deep and dark web are where much of the cyber threat landscape is openly discussed. Actors share tactics, collaborate on exploits, and leak stolen data, often before such information reaches the public domain or intelligence reports. By actively monitoring these spaces, this DRP module helps organizations detect threats earlier, validate incidents, and understand how they are perceived or targeted within underground circles. This visibility is key for anticipating attacks, mitigating reputational damage, and accelerating response. It enables security teams to take informed actions based on concrete findings, not speculation, strengthening the organization’s posture against digital risks that originate beyond the perimeter. # Risk Signals Detected Risk signals are the core output of the DRP monitoring process. These signals are the tangible results of observing informal, high-velocity digital spaces where early indicators of security threats frequently emerge. They represent findings that may require attention, investigation, or immediate action depending on their severity and context. ### Understanding Risk Signals A risk signal can take many forms: leaked credentials being shared or sold, confidential documents exposed in chat groups, mentions of executive names or internal systems in dark web discussions, or even planned attacks circulating among threat actors. What defines a signal is not just *what* is said, but *where* and *how* it appears. A file shared in a closed forum known for cybercrime has a very different meaning than a message posted in a public channel. The system identifies and interprets these signals by analyzing patterns of communication, the relevance of the content to monitored entities, and the nature of the platform where it was found. It distinguishes casual commentary from coordinated threats or sensitive data exposures ensuring that only the most actionable intelligence reaches the security team. ### From Raw Content to Actionable Insight Risk signals are not simply extracted data points, they are enriched findings. Each one is contextualized to explain the type of threat involved (e.g., data leakage, impersonation, credential exposure), its possible impact, and the environment in which it was detected. This gives incident response teams a clear, prioritized view of what matters most, allowing them to act quickly when necessary by consolidating signals from disparate sources and translating them into structured, security-relevant insights. # Enrichment Strategies The enrichment stage transforms raw material gathered from messaging platforms, forums, and other communication channels into intelligence that security teams can act on. Instead of passing along unstructured text or files exactly as they appear, the DRP platform adds layers of meaning that clarify who is involved, what is being discussed, and why it could matter to the organisation’s security posture. ### Why Enrichment Matters Messages and posts rarely arrive in a neat format. They may be written in different languages, include shorthand or emojis, reference people or systems only insiders recognise, or hide sensitive information inside attachments. Without additional context, an analyst must spend time deciphering each fragment before deciding whether it poses a real threat. Enrichment automates that effort: it cleans and normalises content, detects its language, and attaches relevant metadata so that analysts can focus on judgement rather than translation or formatting tasks. ### Layers of Context Applied First, linguistic processing determines the language of every message and converts unusual encodings into a standard form, ensuring nothing is lost to garbled characters. Next, the system identifies names of people, companies, products, locations, and monetary values to reveal who or what is being discussed. References are then matched against the organisation’s monitored assets, brands, executives, domains, or technologies so that even indirect mentions surface as potential concerns. Attachments receive similar attention. Documents are read for embedded text, images are scanned for on-screen words, and archives are unpacked so that hidden material cannot slip past unnoticed. Throughout this process, duplicate items are removed and timestamps are aligned, allowing conversations to be viewed in sequence rather than as isolated snapshots. Finally, each finding is assigned an initial relevance score that reflects its probable impact, helping security teams decide what to investigate first. ### Outcome for Analysts When enrichment is complete, every finding includes enough context for immediate triage: the original evidence, a concise explanation of its significance, and indicators such as language, entities mentioned, and preliminary severity. # Deep/Dark Web Monitoring Deep and dark web spaces host some of the most valuable early-warning signals for information-security teams. Hidden marketplaces, invitation-only forums, leak sites, ransomware blogs and covert communication channels are often where stolen data is advertised, access to compromised networks is sold, and plans for future attacks are discussed. The Deep / Dark Web Monitoring component of the DRP solution maintains ongoing visibility across these environments so that organisations can detect emerging threats long before they surface in conventional intelligence feeds or mainstream media. ### Where We Look Coverage includes a wide range of hidden services reachable via Tor or similar anonymity networks, as well as closed communities that operate behind registration barriers or trust-based vetting. This span of sources captures posts offering credentials, corporate documents, customer records, exploit kits, or discussions about targeting specific brands, executives or technologies. Because many of these sites appear and disappear unpredictably, continuous observation is essential to avoid blind spots. ### How Findings Are Generated Content gathered from these channels is examined for indicators that matter to the organisation: leaked data sets, mentions of proprietary systems, references to privileged accounts, or negotiations to buy and sell illicit access. Context such as the reputation of the poster, the forum’s focus, and the type of asset being traded is factored into each finding. Only material that could present a plausible risk is elevated, helping security teams focus on genuine exposures rather than background chatter. ### Next pages * [Deep/Dark Web](/drp/deep-dark-web-monitoring/deep-dark-web) * [Risk Signals Detected](/drp/deep-dark-web-monitoring/risk-signals-detected) * [Enrichment Strategies](/drp/deep-dark-web-monitoring/enrichment-strategies) # Deep/Dark Web The Deep / Dark Web section of the DRP concentrates on hidden parts of the internet. Sites and forums that are deliberately excluded from mainstream search engines and often require special networks such as Tor for access. These spaces host a steady trade in stolen data, privileged-access offers and discussions about forthcoming attacks. #### What We Monitor * **Leak and dump sites**: repositories where attackers publish or sell credential collections, internal documents, or customer records. * **Underground marketplaces**: listings that advertise remote-access tools, exploits, or corporate assets for sale. * **Ransomware and extortion blogs**: pages where criminal groups announce victims, publish sample data, and negotiate payments. * **Closed technical forums**: invitation-only boards where threat actors exchange tactics or crowd-source vulnerabilities. #### Why This Matters Activity in deep and dark-web communities frequently precedes high-profile breaches or reputational crises. Early awareness allows security teams to validate whether their data is exposed, understand adversary intentions and launch containment measures before damage escalates. Continuous monitoring of these hidden environments therefore forms a critical layer of defence within a comprehensive Digital Risk Protection strategy. # Risk Signals Detected The *Risk Signals Detected* section explains the types of findings generated through deep and dark web monitoring. These findings emerge from underground forums, ransomware blogs, leak sites, and hidden marketplaces, where threat actors share, sell, or discuss content that may indicate exposure or targeting of an organization. Each signal is collected, interpreted, and structured to support early detection and response. #### What We Detect This monitoring layer identifies different types of digital risk that may impact a business, including: * **Credential leaks****:** mentions or listings of usernames, passwords, or authentication tokens tied to corporate systems, domains, or key individuals. * **Data exposure****:** internal documents, customer records, or confidential files posted publicly or offered for sale. * **Access-for-sale offers****:** discussions or listings advertising unauthorized access to systems such as VPNs, RDPs, panels, or inboxes. * **Extortion activity****:** ransomware victim announcements, sample leaks, negotiation details, or countdown pages linked to payment demands. * **Targeting and impersonation****:** posts referencing executives, employees, partners, or customers in the context of fraud, social engineering, or doxxing. * **Attack planning****:** threat actor conversations related to tools, exploits, or infrastructure used by the organization or its supply chain. #### Why This Matters These findings offer early visibility into events that can lead to serious incidents often appearing days or weeks before any public disclosure. By identifying signals of compromise or malicious intent at the source, security teams can act proactively: containing the threat, notifying impacted stakeholders, or initiating response efforts. Each signal is presented with clear context: what was found, where it was found, and why it may pose a risk. This helps transform hidden, fragmented activity into actionable intelligence, supporting a stronger and faster digital risk response. # Enrichment Strategies The *Enrichment Strategies* applied to deep and dark web findings ensure that raw, often fragmented content is transformed into clear and actionable intelligence due to the nature of these sources like forums, leak sites, and underground markets. Many posts include informal language, encrypted references, or hidden data within files. Enrichment adds the necessary context to help security teams understand the significance of each finding. #### What We Do This process begins by standardizing and cleaning the content. The language of each item is identified, and relevant entities such as people, companies, domains, or technologies are extracted and linked to the organization’s monitored assets. Files and archives are unpacked, images are scanned for on-screen text, and audio is transcribed when necessary. This allows buried evidence to be revealed and included in the analysis. In addition to the content itself, metadata such as timestamps, links, and file information is collected to complete the picture. If the same leak appears in different places, duplicates are removed and the information is consolidated to present a single, unified view to analysts. Findings are also prioritized based on relevance and severity. #### Why This Matters Without enrichment, deep and dark web content remains difficult to interpret and full of noise. With it, each signal becomes easier to understand, compare, and act on. The process allows analysts to quickly identify exposed credentials, leaked documents, access-for-sale offers, or active threats, all with enough context to support immediate decision-making. # Surface Web Monitoring The *Surface Web Monitoring* section of the DRP program focuses on open, searchable parts of the internet where security-relevant traces frequently appear first. It looks for brand misuse, exposed data, and infrastructure signals that indicate phishing, impersonation, or operational exposure well before these issues turn into incidents. #### What We Monitor * **Open web & targeted searches****:** public pages and indexed content using OSINT queries to surface mentions of companies, VIPs, and sensitive strings, as well as exposed API specs or cloud resources. * **Public code repositories****:** GitHub, GitLab, and Bitbucket for credentials, configuration files, and proprietary material committed by mistake. * **Domain ecosystem & certificates****:** newly issued TLS certificates and domain permutations that resemble official brands, helping reveal phishing sites and look-alike infrastructure. * **Look-alike domains (abuse)****:** detection of typosquatting and related variants that exploit visual or keyboard similarities to mislead users. * **App stores and extensions****:** listings that impersonate brands, misuse trademarks, or bundle malicious functionality. * **DNS and subdomains****:** public records and subdomain enumeration that reveal misconfigurations or unintended exposure of services. #### Why This Matters Surface-web signals often foreshadow phishing campaigns, fraud, and data exposure. Early visibility into look-alike domains, leaked code or credentials, risky app listings, and misconfigured services enables faster takedown, containment, and stakeholder notification. ### Next pages * [Surface Web](/drp/surface-web-monitoring/surface-web) * [Domain & Brand Look-Alikes](/drp/surface-web-monitoring/domain-and-brand-look-alikes) * [Risk Signals Detected](/drp/surface-web-monitoring/risk-signals-detected) * [Enrichment Strategies](/drp/surface-web-monitoring/enrichment-strategies) # Surface Web The *Surface Web* monitors open, searchable parts of the internet to uncover brand misuse, exposed assets, and security-relevant traces that often precede incidents. Coverage spans public sites, code repositories, domain/certificate ecosystems, DNS and subdomains, cloud storage, and official/third-party app stores. The goal is to turn open-web noise into concrete findings tied to your brands, people, and infrastructure. ### What We Monitor * **Public web & targeted searches****:** Open pages and indexed content are queried for sensitive strings, exposed API documentation (Swagger/OpenAPI, Postman collections), and other security artefacts. Crawling of corporate sites helps reveal credentials, configs, and unintended data exposure. * **Public code repositories****:** GitHub, GitLab, and Bitbucket are scanned for secrets, configuration files, and proprietary material, including, checks across recent commit history. * **Domains, certificates & look-alikes****:** Subdomains and newly issued certificates are tracked to surface fresh assets and attack infrastructure. Look-alike risks are identified using domain-variation techniques and similarity analysis. * **DNS & infrastructure signals****:** DNS records are validated to catch misconfigurations; exposed hosts/services are mapped and fingerprinted to identify technologies and versions in use. * **Cloud storage exposure****:** Publicly accessible buckets and containers across S3, GCP, and Azure are discovered through optimized permutation strategies and assessed for sensitive content. ### How We Detect Findings are produced by combining OSINT scanning with validation steps that reduce false positives. Web searches feed into structured analysis pipelines; subdomains are enumerated. Domain look-alikes are generated and ranked by similarity models. DNS checks and service fingerprinting validate real exposure. cloud buckets are enumerated and verified for public access and sensitive files; app-store look-alikes are confirmed with textual and visual similarity methods. #### Why This Matters Open-web traces frequently foreshadow phishing, fraud, data leakage, or abuse of brand and infrastructure. Early visibility into misconfigured services, leaked secrets, look-alike domains, risky app listings, and exposed cloud storage enables rapid takedown and containment, strengthening the organization’s overall digital risk protection posture. # Domain & Brand Look-alikes The *Domain & Brand Look-alikes* covers surface websites and domains that imitate official brands to enable phishing, fraud, or traffic hijacking. It focuses on domain variations, deceptive registrations, and cloned pages that resemble legitimate assets closely enough to confuse users. #### What We Monitor * **Domain permutations and IDNs****:** variations created via typosquatting, homograph/Unicode swaps, bitsquatting, TLD swaps, and subdomain tricks that resemble official domains. * **New certificates & subdomains****:** certificate issuance that mentions brand domains (via Certificate Transparency) and subdomain discoveries. * **Live site clones****:** pages that copy branding, layouts, or flows from the official site to collect credentials or payments. Similarity is checked against the legitimate site. * **Registration & DNS signals****:** WHOIS data, name servers, and DNS records that indicate newly activated or misconfigured look-alike infrastructure. #### How We Detect Candidates are generated with multiple domain-fuzzing strategies. They’re then compared to monitored brands using weighted similarity measures to highlight the closest matches. \ To catch active infrastructure early, the system watches CT logs for certificates that include monitored names and extracts SAN entries to reveal new hostnames; subdomains are also enumerated via search engines and CT sources. \ Each candidate is validated with DNS/WHOIS checks and content analysis. Pages are fingerprinted (screenshots, perceptual hashes and fuzzy hashing) and compared to the official site to spot clones even when HTML differs. #### Why This Matters Look-alike domains are a common foundation for phishing, credential theft, brand abuse, and malware delivery. Detecting them at the moment of appearance when a certificate is issued, DNS goes live, or a clone is first published gives security teams time to block, takedown, or warn users before large-scale impact. Continuous coverage of permutations, certificates, subdomains, and page similarity reduces blind spots and strengthens brand and user protection within the DRP program. # Risk Signals Detected The *Surface Web Monitoring* layer produces findings tied to exposed data, brand misuse, and signs of operational risk found in publicly accessible sources. These signals help identify early traces of compromise, misconfiguration, or abuse that may escalate if left unaddressed. Findings in this layer typically fall into one of the following categories: * **Leaked credentials and sensitive files****:** authentication keys, passwords, API tokens, internal documentation, and configuration files exposed through public code repositories like GitHub or embedded in company websites. * **Exposed APIs and data schemas****:** public access to Swagger/OpenAPI specs or Postman collections that reveal the structure of internal systems, sensitive endpoints, or production data samples. * **Open cloud storage****:** public S3, GCP, or Azure buckets containing log files, backups, or confidential documents inadvertently exposed. * **Brand impersonation and misleading domains****:** look-alike domains registered to exploit visual or keyboard similarity with official assets, often used in phishing or fraud campaigns. * **Certificate and DNS anomalies****:** new TLS certificates or subdomains linked to monitored brands, which may indicate shadow infrastructure or asset misuse. Each finding is linked to a specific risk category such as phishing, data leakage, infrastructure exposure, or brand fraud and is enriched with supporting evidence and context to support investigation and response. # Enrichment Strategies Each piece of collected evidence undergoes normalization and classification. Language is detected and content is cleaned to eliminate false positives from formatting issues or irrelevant matches. When credentials, keys, or tokens are identified in code or web pages, the enrichment process cross-checks them against known brand domains, employee emails, or infrastructure patterns to confirm the likelihood of real exposure. In cases involving domains or subdomains, WHOIS metadata, certificate transparency records, and DNS responses are added to determine whether the asset is newly registered, active, and potentially malicious. **Additionally, ****all suspicious domains are validated against the Inopli internal threat feed**** and public phishing repositories to confirm known malicious infrastructure and reduce false positives.** This step enhances the ability to quickly identify phishing threats and supports prioritization based on confirmed reputation signals. When findings involve **cloud storage**, enrichment confirms whether the exposed content is publicly accessible, identifies the cloud provider, and examines the filenames and content types to highlight sensitive data such as internal documentation, logs, or customer information. For **public code repositories**, commit metadata and author information are included to support traceability. Findings are enriched with indicators such as repository visibility, timestamps, and file paths to help prioritize which exposures require immediate attention. # VIP Monitoring VIP Monitoring focuses on protecting executives and other high-profile individuals by identifying early signs of digital risk tied to their names, roles, and personal context. Coverage spans the monitored surfaces of the DRP program messaging platforms, forums and communities, and the open web so mentions and exposures are detected even when they appear in fast-moving or niche venues. Multilingual analysis and entity recognition ensure that person names and related details are captured consistently across languages and formats. #### Where We Look Monitoring includes real-time chat ecosystems and community boards where VIP references often emerge first. Mentions in Telegram, Discord and IRC are correlated to tracked VIP profiles, with direct and indirect references detected even when names are abbreviated or altered. Findings from these streams are packaged with context for downstream triage alongside other DRP outputs, keeping VIP-related activity aligned with wider risk monitoring. #### What We Monitor VIP-related findings typically involve four exposure patterns. **Identity and impersonation** signals include name misuse, look-alike profiles, and social-engineering set-ups that reference a VIP to build trust or pressure targets. **Data and credential exposure** covers leaks of email/password pairs and documents that include VIP identifiers, with correlation to monitored entities to raise priority. **Personal context in media** extends detection beyond plain text: text inside images (OCR), content within archives, and speech transcribed from shared audio are all scanned for VIP mentions. **Location or sensitive metadata** in shared images can add time/place clues around a VIP reference, improving assessment of potential physical-world risk. #### How Findings Are Produced Mentions of VIPs are detected in text, images, documents, and audio, enriched with multilingual NER, and correlated to the monitored VIP catalogue to distinguish casual references from security-relevant ones. Each validated observation is emitted as a structured finding with the evidence, source context, and an initial severity to support rapid triage and response by security teams. #### Why This Matters Threat actors frequently exploit VIP identities for phishing, extortion, fraud, or doxxing. Early, cross-surface visibility into VIP mentions backed by multi-format analysis helps reduce time to detect, confirm, and contain incidents that could escalate into reputational, legal, or physical-security harm. # Keyword / Query Monitoring Keyword / Query Monitoring strengthens DRP coverage by tracking brand names, VIPs, and **sensitive strings** across monitored sources and languages. It focuses on meaningful mentions and security-relevant patterns—credentials, URLs, and other indicators, turning scattered references into structured findings with context and initial severity. #### What We Monitor The watchlists include organization names, executive identities, product terms, domains, and **sensitive strings** tied to confidentiality or access. Detection considers both direct and indirect mentions and correlates them to monitored entities to surface true relevance. \ Signals are captured in **multiple languages**, ensuring that references in different regions or communities are not missed. #### How Queries Are Applied Queries operate across text and shared media so that **evidence inside files** is discoverable. Text found in images (OCR), documents, and archives is extracted and evaluated against the same watchlists used for messages. Security-oriented patterns such as **malicious URLs**, commands, and phishing artefacts are included to detect early threat coordination alongside brand or VIP references. #### Why This Matters Mentions of brands, executives, and **sensitive strings** often precede data leakage, credential exposure, or social-engineering campaigns. By unifying multilingual queries with entity correlation and media-aware discovery, the monitoring reduces noise and delivers **actionable findings** what was found, where, and why it matters for security. # Social Media Monitoring The *Social Media Monitoring* section focuses on public and semi-open networks where impersonation, fraud, and data exposure frequently appear first. Coverage spans multiple platforms and languages, correlating mentions of brands, companies, and VIPs to produce security-relevant findings rather than raw posts. #### What We Monitor Social profiles and content are evaluated for signals that matter to information security: * **Profiles and account behavior****:** creation date, followers, posting activity, inactivity, and patterns that indicate newly created or suspicious accounts are assessed to spot likely impersonation or abuse. * **Text and bio indicators****:** usernames, names, bios, and posts are checked for risky elements such as suspicious links, emails, and phone numbers that can support phishing or scams. * **Mentions of monitored entities****:** references to companies and VIPs are correlated across languages to prevent missing region-specific or obfuscated mentions. * **Media and links in posts****:** embedded URLs are extracted and associated with the finding; text inside images and documents is read so that signals hidden in media are not overlooked. * **Tasked searches****:** targeted lookups by username, personal name, company, or VIP are supported to surface impersonation attempts and brand misuse efficiently. Each validated observation is published as a structured finding with type, severity, and contextual metadata to support rapid triage alongside other DRP outputs. #### Why This Matters Abuse of brand identity and VIP personas on social networks enables phishing, fraud, doxxing, and misinformation. Early, cross-language visibility into suspicious profiles, risky content, and media-embedded signals shortens time to detect and contain incidents, improving digital risk protection without overwhelming teams with noise. # Page Reference Monitoring The **Page Reference Monitoring** feature enables proactive detection of phishing and brand impersonation attempts through embedded JavaScript code. This mechanism identifies when legitimate websites are cloned and deployed under unauthorized or suspicious domains, allowing the security team to react before reputational or financial damage occurs. This feature is particularly effective for detecting **look-alike sites**, credential harvesting pages, or infrastructure reuse targeting users of a known web service or brand. *** #### How It Works 1. **Script Deployment**\ The Inopli platform provides a unique JavaScript snippet for each monitored domain. This script is embedded directly into the HTML of selected web pages (typically login portals, user dashboards, or transaction pages). 2. **Silent Beaconing**\ When the legitimate page is loaded, the script performs passive fingerprinting and silently confirms the origin via a secured beacon back to the Inopli DRP backend. 3. **Clone Detection**\ If the same HTML and JavaScript are reused or mirrored under a different domain—typically during phishing or impersonation attempts—the beacon is still triggered but now exposes a mismatch in origin. This event is logged and surfaced as a **Finding** in the DRP console. 4. **Threat Attribution**\ The suspicious or unauthorized domain is then enriched and flagged using all standard enrichment processes: WHOIS, DNS, phishing feeds, and the Inopli internal threat graph. If confirmed as malicious, it is escalated via the Response module. *** #### Benefits * Early detection of phishing sites before wide distribution * Passive monitoring, no active scanning required * Lightweight, no impact on page performance * Automatic correlation with brand and infrastructure profiles * Seamless integration with existing DRP findings and workflows # App Stores The *App Stores* section of the DRP monitors official and third-party catalogues to uncover brand impersonation, malicious or misleading listings, and unauthorized distribution of software tied to the organization. Coverage includes major stores as well as alternative Android repositories with capture of listing details, icons, screenshots and basic metadata for assessment. #### What We Monitor * **Impersonation in names and publishers****:** app titles and developer identities that closely resemble official brands or company units, suggesting attempts to mislead users. * **Visual misuse of brand assets****:** icons and screenshots that reuse or mimic official logos, layouts, or design elements to increase credibility. * **Cloned or repackaged apps****:** listings whose package contents or structure strongly overlap with legitimate apps, indicating republishing or tampering. * **Unauthorized distributions****:** appearances of corporate APKs or SDKs outside approved channels, including mirrors in third-party stores. * **Suspicious listing context****:** anomalies in listing metadata (e.g., name/developer mismatches, inconsistent descriptions, recycled imagery) used to prioritize review. #### Why This Matters Abusive or counterfeit apps enable credential theft, malware delivery and brand fraud at scale. Early detection of impersonation, repackaging and unauthorized distribution provides time to request takedowns, warn users and remediate exposure, strengthening overall digital risk protection across mobile ecosystems. # Client Onboarding and Configuration # Company Setup The activation of Inopli's Digital Risk Protection (DRP) module for a monitored entity begins with the configuration of its monitoring profile. This is a required first step before any data collection or threat detection can begin. The monitoring profile provides the baseline identity data and digital presence of the company, allowing the DRP system to contextualize and correlate findings accurately. The process must be initiated by the authorized partner or designated contact for the monitored company. A formal monitoring activation request must be submitted, including a complete set of required profile information. Once validated, this data is used to guide and personalize all DRP monitoring tasks across surface web, social media, deep/dark web, and app ecosystems. #### Required Information The following fields must be provided when requesting DRP activation: * `brand name` — Display name of the monitored brand * `legal name` — Official registered name of the entity * `tax id` — Legal tax identifier of the organization * `country` — Country of registration or operations * `language` — Primary language used in brand presence and communication **Social & Digital Presence** These informations are essential for monitoring across communication channels and public platforms: * `facebook`, `instagram`, `twitter`, `linkedin`, `youtube`, `tiktok`, `threads`, `telegram`, `whatsapp`, `wechat`, `qq`, `reddit`, `snapchat`, `pinterest`, `tumblr`, `medium`, `vk`, `flickr`, `vimeo`, `stackoverflow`, `discord` * `github`, `gitlab`, `google_play_id` #### Process Notes * Once activated, the system begins entity correlation and enrichment tasks for threat detection. * Any changes to this profile after activation must be submitted via the update workflow. # Monitoring Profiles The DRP module defines the customized perimeter of each monitored entity within it. These profiles serve as the operational scope for threat detection, data enrichment, and prioritization. They allow organizations to configure what should be monitored, such as domains, high-risk individuals (VIPs), and sensitive keywords or identifiers (strings) tailoring detection efforts to their unique risk surface. Each profile is fully self-managed by the user through the configuration interface under the respective company settings. Authorized users can add, edit, or remove items at any time. The DRP engine continuously ingests and correlates these elements across surface, deep/dark web, and communication platforms to identify brand impersonation, credential leaks, reputational threats, and fraud campaigns. #### Profile Types There are three types of items that can be configured within a Monitoring Profile: * **Domains:** Used for tracking company-owned domains, subdomains, and web infrastructure. * **VIPs:** Includes executives, public figures, or employees with a high exposure or risk index. * **Strings:** Covers sensitive keywords, identifiers, or custom tokens such as product names, legal terms, internal project codes, or PII patterns. Each of these categories can be managed independently and updated as the threat surface evolves. *** **Pages in this section:** * [Domains](/drp/client-onboarding-and-configuration/monitoring-profiles/domains) * [VIPs](/drp/client-onboarding-and-configuration/monitoring-profiles/vips) * [Strings](/drp/client-onboarding-and-configuration/monitoring-profiles/sensitive-strings) # Domains Domains are foundational elements in digital risk monitoring. By registering organizational domains, the Inopli DRP module is able to detect impersonation attempts, typo-squatting, subdomain enumeration, phishing campaigns, certificate transparency anomalies, and data leaks linked to the organization’s web infrastructure. The configuration process is straightforward and requires only the input of a domain name. Once registered and marked as active, the DRP engine continuously monitors external sources such as surface web, WHOIS records, SSL certificates, paste sites, and malicious DNS entries for threats tied to the domain. Findings are enriched with context, risk level, and exposure metadata. If validated as true positives, they trigger response actions in the Inopli Response module for incident tracking and remediation. *** #### Domain Configuration Fields Each domain entry contains only one required field: * `domain` – The fully qualified domain name (e.g., `example.com`) to be monitored *** #### User Interface Example Below is the platform interface used to manage and monitor domains:

Each Domain can be toggled on/off, and actions include edit or remove. Only active Domains are monitored in real time. # Sensitive Strings Sensitive Strings are user-defined keywords, patterns, or identifiers that represent critical data elements for the organization. These may include API keys, internal project codes, client tokens, legal references, employee identifiers, or any proprietary string whose exposure could lead to risk scenarios such as data leakage, impersonation, or regulatory violations. The Inopli DRP module allows companies to configure these strings directly from the platform’s settings panel under the `Sensitive Strings` tab. Once registered and activated, each string becomes a monitored entity. The DRP engine will continuously inspect indexed content (surface, dark web, and other channels) for signs of exposure, correlation, or misuse involving these terms. Findings are enriched with metadata, including context of exposure, severity, and source, and may trigger incident creation through the Response module if confirmed as valid by the analyst or an automated policy. *** #### String Configuration Fields Each entry includes the following fields: * `type` – Category of the string to be monitored. Accepted types are: `API Key`, `Password`, `Token`, `Secret`, `Other` * `value` – The actual keyword or string to be monitored * `regex_pattern` – Optional field to define a custom regular expression pattern * `case_sensitive` – Boolean that defines if the match is case-sensitive * `exact_match` – Boolean to specify if only exact string matches are accepted * `category` – Optional logical grouping (e.g., Legal, DevOps, HR) * `severity` – Risk impact associated with string exposure (e.g., Low, Medium, High) *** #### User Interface Example Below is the platform screen used to manage and edit sensitive strings for monitoring

Each Sensitive String can be toggled on/off, and actions include edit or remove. Only active Sensitive Strings are monitored in real time. # VIPs VIPs are individuals within the organization who hold strategic, public, or high-risk roles and therefore require targeted monitoring across external digital environments. These profiles are typically associated with executives, spokespersons, board members, or key personnel whose names, identities, or credentials could be exploited in impersonation, fraud, or reputational attacks. In the Inopli DRP module, VIPs can be configured directly by the user in the **company’s DRP settings** **panel** under the `VIPs` tab of the Monitoring Profile section. Each registered VIP becomes a reference point for correlation across deep/dark web, social networks, forums, and other external data sources. Once a VIP is configured and marked as active, the DRP system continuously searches for signals that may involve or target the person, including mentions, leaks, fake profiles, and social engineering indicators. Confirmed threats tied to a VIP will trigger the escalation workflow through the **Response module**, creating incidents for operational response if marked as true positive. *** #### VIP Record Fields Each VIP entry consists of the following fields: * `full_name` – The individual’s full name as it appears in official or public records * `department` – The department or unit the VIP belongs to * `position` – The role or job title (e.g., CEO, CISO, Board Member) * `risk_level` – Optional classification of risk exposure (e.g., High, Medium, Low) * `notes` – Optional comments or context for identification * Social media handles (optional):\ `linkedin`, `twitter`, `facebook`, `instagram`, `tiktok`, `youtube`, `github`, `gitlab`, `snapchat`, `threads`, `tumblr`, `medium`, `stackoverflow`, `pinterest`, `reddit`, `telegram`, `wechat`, `qq`, `vk`, `vimeo`, `flickr` * National identifiers (optional, if relevant):\ `cpf`, `rg`, `cnh`, `passport`, `ssn`, `driver_license`, `national_id`, `residence_permit`, `eu_passport`, `nif`, `nie`, `dni`, `identity_card` – These are used only if legally allowed and justified by the risk profile *** #### User Interface Example Below is a screenshot of the VIP configuration screen used to add, edit, or deactivate VIPs from the monitoring scope:

Each VIP can be toggled on/off, and actions include edit or remove. Only active VIPs are monitored in real time. # Integrations # Response Module The Inopli DRP module is tightly integrated with the Inopli Response module to ensure that identified threats are not only detected but also managed through structured operational workflows. Once a monitoring profile is active and findings begin to surface, each signal is enriched and classified. Findings presented to the security team or analysts can be marked as true positives, false positives, or benign. When a **true positive** is confirmed by an analyst or an automated rule, the system automatically triggers an escalation process by interfacing with the **Response module**. This process results in the **automatic creation of a security incident**, which is then assigned to the operations team for handling and resolution. Each incident contains: * The original finding and all correlated evidence * Enrichment metadata from the DRP engine (e.g., entity match, severity, exposure level) * Audit logs of analyst action (who validated and when) * Links to response playbooks and historical context if applicable This seamless integration ensures that threat signals are actionable and traceable, closing the loop between **detection and response**. It also helps maintain response consistency and reduces the likelihood of missing relevant threats due to manual friction or communication delays. # Notifications # SMS The SMS integration allows the Inopli platform to send real-time alerts and notifications via SMS using AWS Simple Notification Service (SNS). This is useful for reaching key stakeholders in high-priority situations, such as critical incident detection, VIP exposure, or urgent compliance findings. This feature is optional and can be enabled by the user within the **Settings > Integrations** section of the platform. *** ### How It Works Once activated, the Inopli platform uses the provided AWS credentials to publish messages to AWS SNS. SMS alerts are sent to the list of configured recipients based on predefined triggers such as validated findings, severity thresholds, or incident escalations. All delivery attempts are recorded in the platform’s audit logs. *** ### Required Configuration To enable this integration, users must provide the following: * `AWS Access Key ID` – IAM user access key with SNS publish permissions * `AWS Secret Access Key` – Secret key for the IAM user * `Region` – AWS region where SNS is active (e.g., `us-east-1`) * `Recipients` – One or more phone numbers in E.164 format (e.g., `+14155552671`) that will receive SMS alerts * `Topic ARN (optional)` – If integrating with a pre-existing SNS topic * `Notification Triggers` – Event types that should trigger SMS alerts (e.g., confirmed VIP exposure, credential leak, etc.) > 📌 **Security Note**: Credentials are stored securely with encryption. Only users with the appropriate permissions can modify or delete them. *** #### Example Use Cases * A VIP exposure is confirmed → SMS sent to the crisis response lead * High-severity keyword leakage triggers an alert → SMS sent to compliance manager * SOC team receives SMS when a domain impersonation finding is escalated # E-mail The Email integration enables the Inopli platform to send automated alerts and notifications via email using its built-in delivery service. No SMTP setup is required. This integration is ideal for keeping internal teams, stakeholders, or external partners informed of key security events such as confirmed findings, incident escalations, and monitoring anomalies. This feature can be configured directly in the **Settings > Integrations** section of the platform. *** ### How It Works The platform sends emails using its internal notification engine. Users only need to define the recipients and select the event types that should trigger email alerts. Each message includes structured metadata, contextual insights, and direct links to the relevant event or incident inside the platform. All emails are logged for audit purposes and delivery visibility. *** ### Required Configuration To enable email notifications, users must define: * `Recipients` – One or more email addresses to receive alerts * `Notification Triggers` – Select which types of events will result in email notifications (e.g., true positive finding, incident creation, keyword exposure) * `Notification Format` – Choose between compact summary or full context (when available) > 📌 **Note**: All emails are sent from a trusted Inopli system address. No email server or credential setup is required. *** #### Example Use Cases * Security analysts receive an email when a VIP is targeted in a confirmed threat * Legal or compliance teams are alerted when a sensitive string appears in an external data source * External partners are notified of relevant incident stages without platform access # API The API integration allows external systems to retrieve findings, incidents, and other security events generated by the Inopli platform. This enables seamless integration with third-party systems such as SIEMs, dashboards, GRC platforms, or custom automation workflows. Access to the API is **read-only** and secured through a private token provided by the platform. No configuration is required on the user’s side. *** #### How It Works Each company receives a **private API token** generated by the Inopli platform. This token is scoped to the organization and must be included in the `Authorization` header of all API requests. The API provides structured, RESTful endpoints for accessing: * Confirmed findings * Incident records * VIP exposure data * Asset and profile information All requests return data in JSON format, and the platform logs all access attempts for security and auditing purposes. *** #### Access Details * **Token Delivery**: The token is issued by the Diazero Technologies team and delivered securely to the company * **Rate Limiting**: Access is rate-limited per company * **Expiration**: Tokens do not expire by default but can be manually rotated by the platform administrator upon request > 📌 **Security Note**: This token provides access to sensitive organizational data. It must be stored securely and treated as a credential. *** #### Example Use Cases * Pull all true positive findings in the last 48 hours for correlation in a SIEM * Retrieve open incidents to auto-create tickets in an ITSM platform * Export VIP-related alerts into a GRC system for continuous risk monitoring # Hunt The **Hunt** feature in Inopli DRP enables users to search and investigate threat indicators across the platform’s internal intelligence base and correlated public feeds. Designed for both proactive threat hunting and reactive validation, it supports security teams in identifying malicious infrastructure, leaked assets, and suspicious behaviors across multiple dimensions. This module provides immediate visibility into known threats and related findings, allowing analysts to trace attacker footprints, validate detection signals, and enrich investigations with contextual threat data. *** #### Searchable Indicator Types Hunting can be performed using the following categories: * **IP Address** – Malicious or suspicious network indicators * **Hash** – Known malware or leaked file signatures * **Domain** – Phishing domains, typo-squats, and rogue infrastructure * **Email** – Exposed, spoofed, or attacker-attributed email addresses * **URL** – Hostnames or full links used in phishing or malware delivery * **Username** – Aliases used in forums, dumps, or credential leaks *** ### Interface Overview Users initiate a search by selecting the indicator type and entering the corresponding value. The Hunt engine returns results enriched with reputation signals, detection history, threat relationships, and classification.

# Search Results Once a hunt query is executed, the **Results** page displays all matched threat intelligence entries based on the selected indicator and search term. The returned findings are enriched with metadata to support prioritization and further investigation. Each result represents a correlated threat signal found within the Inopli DRP database or across integrated external sources. The system aggregates and categorizes findings to streamline triage and decision-making. *** ### Result Summary Overview At the top of the Results screen, summary indicators are displayed: * **Total Results** – Total number of matching threat records * **Search Time** – Time taken to complete the query (in milliseconds) * **Search Term** – The query string used during the hunt *** ### Result Table Fields Each result row contains: * **ID** – Unique incremental identifier for visual sorting * **Category** – General threat category (e.g., Malware, Phishing, InfoStealer) * **Type** – Specific sub-type within the category (e.g., Ransomware, Email, Domain) * **Values** – IOC(s) matched against the hunt query (e.g., domain, email, hash) * **Confidence** – Estimated confidence level (e.g., 85%) based on correlation signals and source reliability * **UUID** – Internal unique identifier for traceability and pivoting * **Threat Data** – Origin scope of the intelligence (e.g., Global, Regional, Tenant-based) Each result can be expanded or clicked to view full details, including the source, enrichment layers, relationship graph, and timestamps.

All search results can be **exported** in multiple formats to support external analysis, reporting, or archival. Supported formats include **CSV** for structured data handling, **PDF** for static reporting, and **HTML** for easy sharing or offline review. Exports preserve metadata such as confidence level, threat category, and UUID for traceability. # Findings The **Findings** feature represents the core output of Inopli DRP’s threat detection engine. Each finding is the result of active surveillance across multiple layers of the internet including surface, deep, and dark web and is produced when content is matched against elements from the organization's monitoring profile. Monitoring inputs may include corporate domains, names and identifiers of VIPs, internal project names, sensitive strings, and keywords associated with infrastructure, clients, or proprietary data. Once a match is detected, it is processed through enrichment and validation routines to determine its legitimacy and severity. Findings serve as the central intelligence object of the DRP workflow. They are not static records but dynamically enriched entities that support decision-making and escalation. Verified findings automatically integrate with the **Response** module, allowing operations teams to initiate containment, attribution, or takedown procedures when applicable. The system ensures full traceability for each finding by associating metadata such as detection source, confidence level, enrichment context, matching rule (when applicable), and timestamps. Every finding also includes the raw evidence, which can be reviewed by analysts for verification or false positive dismissal. *** #### Detection Categories Findings are classified according to the source and type of exposure. The following categories are supported: * **Exposed Credentials**\ Leaked username/password pairs found in public pastes, dumps, or chat logs. * **Leaked Documents**\ Internal presentations, spreadsheets, contracts, or technical documents referencing the company’s domain or VIP names. * **Cloud Bucket Exposure**\ Files publicly accessible in cloud storage such as S3, Azure Blob, or similar, containing sensitive or proprietary content. * **Phishing & Lookalike Domains**\ Domains that imitate official company websites, including typo-squatting and phishing kits. * **VIP Mentions**\ Sensitive or malicious references to executive names or internal personnel in open or criminal forums. * **Sensitive Strings Detected**\ Predefined strings (e.g., internal project names, client references, tokens, credentials) detected in web pages, code, or chats. * **Threat Actor Discussions**\ Targeted discussions involving the brand, products, infrastructure, or VIPs in threat actor communities or deep web sources. * **Code Repository Exposure**\ Exposure of keys, tokens, employee emails, or internal comments in public Git repositories. * **Dark Web Artifacts**\ Data related to the company found in dark web marketplaces, leaks, or ransomware listings. * **Clone Alerts (JS Probe)**\ Sites that have embedded the Inopli JavaScript and were detected as clones based on unauthorized propagation. * **Automated Rule Matches**\ Findings generated from correlation rules created by analysts using Structured, XML, YARA, or Sigma detection logic. *** #### Lifecycle Each finding passes through the following stages: 1. **Ingestion** – Raw evidence is collected from open, dark, and proprietary sources. 2. **Correlation** – Content is matched against the company’s monitoring profile. 3. **Enrichment** – Metadata is added (WHOIS, DNS, internal feeds, etc.). 4. **Classification** – Automated severity scoring and tagging. 5. **Response** – If marked as a true positive, the finding triggers an incident in the **Response** module. # Results The **Results** interface displays enriched and correlated information about each monitored entitywhether it is a **company-level configuration**, a specific **VIP**, a **sensitive string**, or a **domain**. This is the primary view for analysts to investigate entity-level exposure and track all findings linked to that asset across surface, deep, and dark sources. Each record consolidates contextual metadata, historical findings, enrichment details, and automation outputs. Analysts can use this interface to monitor ongoing exposure, review detection history, and evaluate risk signals tied to the selected entity. *** #### Sections per Entity Type * **Company Profile Results**\ Displays the company name, tax identifiers, social media handles, and configured monitoring profile. Shows a chronological list of all findings that matched any item from the company configuration, including domain-based leaks, impersonations, and VIP exposures. * **VIP Results**\ For each registered VIP (executive, stakeholder, or key individual), this section presents their identifiers, aliases, and custom metadata. Findings are grouped by type (e.g., mentions, credential leaks, impersonation attempts), with timeline and severity indicators. * **Sensitive String Results**\ Lists each configured keyword, tag, or expression, along with matches detected across monitored sources. Results include context snippets, source links, and whether the string was found in code, documents, or threat actor discussions. * **Domain Results**\ Displays all findings associated with the domain, including leaked documents, phishing lookalikes, code repository exposures, and clone detections from the JS monitoring probe. The view also includes domain enrichment (WHOIS, DNS records, certificate transparency, etc.). *** #### Available Data Points Each result includes: * **Enriched metadata** (source, first seen, last seen, risk level, matched pattern) * **Finding preview** (summary, evidence type, threat category) * **Linked incidents** (if the finding triggered a response case) * **Automated rule matches** (if any structured rule matched the entity) * **Tags and classification** (automatically assigned by the DRP engine) * **Visual timeline** (showing recurrence and frequency of exposure) *** #### Exports Results for each entity can be **exported** in **CSV**, **PDF**, or **HTML** format to support audits, reporting, or integration with external systems. Exports preserve all metadata and finding references for traceability. # Advanced Features # Automatic Search Rules **Automatic Search Rules** allow security teams to define and deploy custom correlation logic that continuously monitors the Inopli DRP dataset for matching patterns, indicators, or behaviors. These rules operate on top of the internal threat intelligence index and can proactively trigger incidents without requiring manual validation. When a rule matches a new entry, whether it's a domain, string, IOC, or correlation pattern the system automatically escalates it to the **Response** module, where an incident is created with full context and enrichment. This feature is designed to reduce reaction time, automate repetitive detection tasks, and encode organizational threat models into reusable and auditable rules. *** ### Rule Types Inopli supports three types of rule syntaxes, each suited to different detection needs: * **Structured Query Rules**\ Human-readable logic designed for analysts to define conditional search patterns based on values, fields, and Boolean logic. * **YARA Rules**\ Used for defining byte-level or string-level conditions. These rules support **regular expressions (regex)** for advanced matching of malware signatures, credential formats, file patterns, or encoded strings. Regex enables the detection of complex obfuscation techniques or variable content structure in payloads. * **XML Match Rules**\ Designed to match specific tags, attributes, or values in structured XML content. These rules also support **regex** within node values or attribute conditions, allowing flexible pattern recognition in feeds, form submissions, or structured artifacts. * **Sigma Detection Rules**\ YAML-based rules inspired by the Sigma standard, allowing analysts to write abstract, backend-agnostic detection logic. Inopli parses these rules and translates them into native queries over the DRP dataset. This format is especially useful for expressing multi-field correlation patterns and structured IOC detections. *** ### Detection & Escalation Flow 1. The analyst defines a rule and saves it in the rule engine. 2. The engine continuously scans new DRP entries in real-time. 3. When a match is found, it is enriched and validated. 4. If thresholds or severity conditions are met, an incident is automatically created in the **Response** module. *** **Pages in this section:** * [Structured Query Rules](/drp/advanced-features/automatic-search-rules/structured-query-rules) * [YARA Rules](/drp/advanced-features/automatic-search-rules/yara) * [XML Match Rules](/drp/advanced-features/automatic-search-rules/xml) * [SIGMA Rules](/drp/advanced-features/automatic-search-rules/sigma) # Structured Query Rules **Structured Query Rules** allow analysts to define custom detection logic using a readable query syntax that filters and correlates threat signals based on field values, Boolean conditions, and pattern matches. This format is ideal for teams that want to express precise conditions over the normalized threat intelligence dataset without relying on low-level syntax. These rules operate continuously over incoming findings within the DRP module and are capable of triggering automated incidents in the Response module when a match is detected. *** ### Rule Syntax Overview Structured Query Rules support logical operators, field-based filters, and nested conditions. Supported constructs include: * Field equality:\ `type = "domain"` * String containment:\ `value contains "gov.br"` * Lists and sets:\ `category in ["phishing", "malware"]` * Boolean logic:\ `type = "email" AND confidence >= 80 AND threat_data = "public"` * Negation:\ `NOT type = "hash"` *** ### Use Cases Some examples of how Structured Query Rules can be used: * Detect newly registered `.zip` domains with medium or high risk:\ `value endswith ".zip" AND risk_level in ["medium", "high"]` * Match credentials leaked from specific business units:\ `value contains "@diazero.com" AND department = "Finance"` * Flag phishing emails targeting executives:\ `type = "email" AND target_group = "executive" AND category = "phishing"` *** ### Rule Behavior Once a rule is saved and enabled, it will run in real-time against all new entries ingested by the DRP engine. If a match is found, the result is enriched, validated, and, if eligible, escalated as an incident in the **Response** module. *** To create a new rule, users can access the **Structured Rule Editor** via the platform’s interface. This editor supports live syntax validation and preview of matching entries. # YARA **YARA Rules** allow analysts to define pattern-based detection logic using string matching and binary-level conditions. Originally designed for malware classification, YARA is also highly effective for detecting suspicious strings, tokens, and structural markers in exposed content within the Inopli DRP dataset. YARA rules operate continuously on findings involving text bodies, source code, cloud storage leaks, and other artifacts where content analysis is meaningful. *** ### Rule Structure A basic YARA rule consists of three main sections: * **Meta** (optional)\ Contains descriptive fields like `author`, `description`, or `severity` * **Strings**\ Defines patterns to match, including plaintext strings, hexadecimal byte patterns, or **r****egular expressions (regex)** * **Condition**\ Boolean logic that defines when the rule should trigger ### Regex Support YARA natively supports **regular expressions** using the `/regex/` syntax within the `strings` section. This enables analysts to detect: * Obfuscated credentials * Token formats (e.g., JWT, OAuth, API keys) * File path structures * Encoded indicators like Base64 or hex Regex can be combined with modifiers like `nocase`, `wide`, or `ascii` to refine detection logic. *** #### Use Cases * Detect password patterns in HTML or JS sources * Identify obfuscated malware strings in leaked ZIPs * Flag exposure of client secrets in public cloud storage * Match encoded backdoor calls in script-based payloads *** ### Incident Triggering Once a YARA rule matches content in a DRP finding, the result is automatically enriched. If classified as a threat based on rule severity or context, it triggers an **incident in the Response module** for operational follow-up. # XML **XML Match Rules** are designed for detecting threats or patterns within structured data sources that use XML formatting. This rule type is ideal for processing feeds, form submissions, third-party alerts, and content with hierarchical tagging such as threat reports, leak disclosures, or machine-readable submissions. These rules allow analysts to define precise conditions over specific XML nodes, attributes, or values. They support **regular expressions (regex)** for flexible pattern matching within content and provide fine-grained control over structured data inspection. *** ### Rule Structure Each XML rule includes: * **Target Element(s)**\ The XML node or attribute to inspect (e.g., ``, ``, `@type`) * **Condition**\ Logic defining what should be matched. Conditions can include: * Exact value match * Partial string match * **Regex match** * **Severity**\ Optional impact classification (`low`, `medium`, `high`) ### Regex Support Regex can be used to: * Identify email domains, credential patterns, or encoded values * Detect naming conventions in tags or attributes * Match variations in formatting across data sources Regex is defined inside `` and supports common expressions such as: ```xml high ``` *** ### Use Cases * Flag indicators in external CTI feeds * Match credentials or tokens in structured breach dumps * Detect abuse types in standardized incident formats (e.g., STIX, TAXII) * Monitor custom fields in partner submissions or open disclosure reports *** ### Incident Triggering When an XML Match Rule finds a match in newly ingested structured content, the result is classified and enriched. If it meets the predefined criteria, it triggers an **incident in the Response module** automatically. # SIGMA **Sigma Detection Rules** bring a flexible and standardized way to define detection logic using YAML-based structures. Inspired by the open Sigma format but adapted to Inopli’s internal data model, these rules allow analysts to describe correlations and matching conditions in a clear, human-readable form that abstracts away backend query language dependencies. This rule type is especially useful for analysts familiar with SOC practices or SIEM rule writing, enabling fast onboarding and reusable logic across clients and use cases. *** ### Rule Structure Each Sigma rule is written in **YAML format** and includes: * **Metadata**\ Descriptive fields like `title`, `id`, `description`, `status`, `level`, `tags`, and `author` * **Detection Logic**\ Conditions are expressed using field-value maps, lists, and logical operators. Inopli supports `selection`, `filter`, `condition` blocks. * **Trigger Definition**\ Conditions evaluate the presence of fields or values in the DRP dataset. When a rule is matched, it is escalated following the defined severity level. Example: ```yaml yamlCopiarEditartitle: Suspicious domain with sensitive keyword id: 8c7a-fake-1234-5678 status: stable description: Detects domains containing sensitive internal keywords level: medium author: drp.team@inopli.com detection: selection: type: domain value|contains: "internal" condition: selection ``` *** ### Detection Model Sigma rules are translated internally into structured queries compatible with Inopli’s data engine. They can be applied over: * IOCs (domain, IP, hash, email) * Content fields (value, description, source, category) * Context metadata (tenant, risk level, enrichment tags) All supported operators include: * Exact match * `contains`, `startswith`, `endswith` * Lists (`field: ["a", "b"]`) * Field modifiers (`value|contains`) *** ### Use Cases * Match known IOCs from shared threat intelligence * Detect exposure of internal identifiers or keywords * Alert on findings linked to specific attack techniques * Build reusable rules for sector-specific monitoring *** ### Incident Triggering Once matched, Sigma rules follow the same workflow as other rule types: they enrich the finding and, if not filtered as false positive, **trigger an ****incident in the Response module**. # Overview The RPA module in Inopli provides a centralized and visual environment for orchestrating automated actions in response to security events, repetitive tasks, and operational workflows. Built with flexibility and scalability in mind, it empowers SOC teams to define playbooks using a no-code editor, reducing response time and human intervention. This section introduces the core components of the RPA module, organized into distinct functional areas that work together to enable automation at every level of security operations: *** * **Automations**\ Full workflow definitions executed based on triggers such as timers, detection rules, or analyst actions. Each automation can contain branching logic, error handling, and multi-step processing. There is no limit to the number of playbooks that can be created, allowing the SOC team to automate both recurring processes and complex incident responses without restriction. * **Components**\ Reusable building blocks used inside automations. These are modular actions or sequences that can be shared across different workflows to ensure consistency and reduce duplication. * **Integrations**\ This area manages all third-party connections used by the playbooks. Inopli RPA supports a growing library of connectors, with dozens of native integrations available out-of-the-box. Whether connecting to SIEM platforms, messaging tools, ticketing systems, or cloud providers, each integration is configurable and can be used in multiple automation flows simultaneously. * **Appliances**\ Remote execution units for running automations in isolated or controlled environments. These are typically used when actions must occur in segmented networks or require direct access to internal infrastructure. * **Tasks**\ A kanban-style monitoring interface showing the current state of every automation task, grouped into categories such as inactive, pending, running, failed, and successful. This area gives visibility into execution flow and allows analysts to audit task lifecycles and outcomes. * **Dashboard**\ A visual hub summarizing the overall status of the automation framework. It includes real-time insights into automation coverage, task success rates, component health, and new custom logic or knowledge deployed by the team. Inopli RPA is built to support enterprise-scale automation, allowing SOCs to create and manage hundreds or thousands of workflows without architectural limitations. The modular design, deep integration capabilities, and visual flow editor make it possible to rapidly deploy new automations and adjust existing ones as threats and operational demands evolve. # Integrations The **Integrations** section of the Inopli RPA module provides a robust and extensible framework for connecting with third-party platforms, internal systems, cloud services, security tools, and external APIs. This integration layer is essential for executing automated actions across the security ecosystem during playbook execution. Each integration is implemented as a **connector** that can be customized and reused across multiple workflows. These connectors support granular configurations, including credentials, endpoint mappings, API keys, headers, and response handling, ensuring secure and efficient interaction with the external system. Currently, Inopli supports over **200 native connectors**, enabling comprehensive orchestration and automation across a wide range of use cases such as ticket creation, enrichment, threat hunting, alerting, asset isolation, and more. *** ### Available Connectors * **Security Tools & EDR** * CrowdStrike Falcon * SentinelOne * Microsoft Defender ATP * Carbon Black Cloud * Cynet * Trend Micro Vision One * **Threat Intelligence & Enrichment** * VirusTotal * URLVoid * Talos ThreatSource * AbuseIPDB * Recorded Future * DomainTools * ThreatQ * Shodan * JoeSandbox * **Email & Collaboration** * Microsoft Teams * Slack * Exchange * Mimecast * Cisco Email Security * Twilio * **Ticketing & ITSM** * Jira * ServiceNow * BMC Remedy * Freshservice * SysAid * ConnectWise * **Cloud & Infrastructure** * AWS EC2, IAM, S3, GuardDuty, Security Hub * Azure AD, Security Center * Google Cloud API, Armor, Pub/Sub * Docker, Kubernetes, VSphere * **SIEM & Logging** * Splunk * ElasticSearch * Azure Sentinel * QRadar * ArcSight * Devo * Exabeam * **Vulnerability Management** * Nessus * Tenable.io * Orca Security * Qualys (via HTTP API) * **Data Sources & DBs** * MongoDB * PostgreSQL * MSSQL * MySQL * Redis * **Other Utilities** * SSH * WMI * REST API * CSV / JSON input * Custom HTTP v2 *** New connectors are added regularly, and custom connectors can be developed using Python. This allows teams to integrate with internal systems or proprietary APIs when required. # Dashboard The **Dashboard** page of the Inopli RPA module serves as the central monitoring interface for all core areas of automation activity. Through an intuitive and visually engaging layout, it provides a high-level overview of the operational state of each key category **Automations**, **Tasks**, **Knowledge**, and **Customizations** allowing teams to instantly assess system health, execution status, and areas requiring attention. *** ### **Purpose and Design** * **Visual Summary of Automation Ecosystem**\ The dashboard presents a circuit-brain layout with interconnected nodes representing major functional areas. Each node displays a summary status (e.g., Complete, Error, New) with contextual messages to indicate ongoing operations or issues. * **Status Indicators**\ Color-coded signals (green, red, blue) quickly communicate the current state of executions or configurations, helping operators identify successful completions, recent updates, or errors in need of intervention. * **Categorical Drilldown Access**\ Each dashboard section links directly to its corresponding feature page—such as **Tasks**, **Automations**, or **Knowledge**—enabling a seamless workflow from high-level monitoring to granular configuration or review *** This centralized view is particularly useful for large environments where multiple automations, tasks, and knowledge resources are actively maintained and executed. # Automations The **Automations** feature of the Inopli RPA module is where incident response and operational workflows are transformed into structured, repeatable, and fully automated processes. At its core, this feature allows organizations to create and manage **an unlimited number of playbooks**, each representing a complete automation flow tailored to a specific detection, incident, or business requirement. *** ### Key Capabilities * **Visual Workflow Builder**\ Analysts can build complex routines using a **graphical no-code editor**, enabling them to model processes without needing to write or modify code. Each playbook is structured as a visual canvas of connected actions and decision nodes, supporting conditional logic, parallel execution, retries, and customized transitions between stages. * **Ready-to-Use and Customizable Templates**\ The system includes **preconfigured playbook templates** designed to address common security operations tasks. These templates can be adapted or new ones created from scratch, supporting use cases ranging from incident triage and escalation to enforcement and documentation workflows. * **Integrated Execution Logic**\ Playbooks can react automatically to detection events, specific triggers, or scheduled intervals. Automated actions can include asset isolation, enrichment queries, ticket generation, policy application, or communication with third-party platforms, all performed without human intervention unless configured otherwise. * **Form-Based Configuration**\ For each automation, users can define **custom forms** to guide execution and input collection, allowing context-specific controls and structured decision-making criteria, all managed directly through the interface. *** ### Monitoring and Reporting * **Operational Dashboards**\ Real-time dashboards offer a centralized view of automation performance. Analysts can track executions, error states, timings, and the outcome of each step, ensuring transparency and operational oversight. * **Scheduled Reporting**\ The module supports **automatic and scheduled delivery of executive and operational reports**, configured per playbook, user group, or organizational unit. Reports are available in various formats and include graphical insights on workflow activity, effectiveness, and exceptions. *** ### Process Control and Auditing * **Standardization and Oversight**\ Playbooks can embed approval steps, checkpoints, and branching logic aligned with internal governance and response protocols. Each automation step is fully auditable, supporting compliance and post-incident reviews. * **Built-in Validation Mechanisms**\ Automation flows can incorporate **status verification routines**, cross-system checks, and correlation conditions to ensure that each action aligns with security and business requirements. *** The image below illustrates the Inopli automation builder, showcasing how analysts define multi-step workflows visually, with full access to actions, conditions, and integrations configured within the platform.

# Components The **Components** feature of the Inopli RPA module enables the creation of **reusable automation blocks**, encapsulating logic, conditions, and actions into modular units. These components act as micro-playbooks that can be referenced across multiple larger automation workflows, ensuring consistency, efficiency, and simplified maintenance. *** ### Purpose and Design * **Encapsulated Logic**\ Each component is built to perform a specific function such as enriching data, validating inputs, triggering notifications, or interacting with third-party systems. Once created, the component behaves as a **self-contained automation object**, with its own input/output structure and execution context. * **Drag-and-Drop Integration**\ Components are available directly within the **visual automation builder**, where they can be dragged into larger playbooks and reused across various steps and branches without the need to redefine their logic. * **Parametrization and Input Binding**\ Each component can accept **dynamic parameters** at runtime, making them adaptable to different scenarios. Inputs and outputs are clearly defined, enabling clean interfacing with other playbook elements. *** ### Benefits * **Reusability Across Automations**\ By modularizing recurring logic into components, teams reduce duplication and improve scalability. A single update to a component reflects across every automation that uses it, streamlining change management. * **Faster Playbook Assembly**\ Analysts can rapidly assemble new automations using a growing library of existing components, focusing on business logic instead of low-level implementation details. * **Operational Consistency**\ Components enforce **standardization of procedures**, ensuring that critical actions (like asset tagging, email notifications, or escalation triggers) follow approved, centrally managed workflows. # Tasks The **Tasks** section within the Inopli RPA module serves as a **dedicated environment for managing and automating daily SOC routines**, combining operational visibility with workflow-based automation. Presented in a **kanban-style interface**, this feature is designed to streamline recurring analyst activities through structured task flows and automated execution. *** ### Operational Flow * **Predefined Columns**\ The task board follows a fixed column structure: *Backlog*, *To Do*, *In Progress*, *Under Review*, and *Done*. This standardization ensures alignment across teams and supports consistent operational reporting. * **Card-Based Automation**\ Each task card has it's own **dedicated automation workflow**, allowing routine actions such as notifications, data validation, ticket creation, or escalation to be executed automatically when the task progresses. The workflow is fully visual and built with the same no-code interface used in the main Automations module. * **Recurring and Triggered Tasks**\ Teams can schedule **recurring task****s** (e.g., daily log checks, threat feed reviews) . *** ### Designed for SOC Operations * **SOC-Centric Templates**\ The module includes task templates for **routine SOC activities** including shift handovers, IOC hunting, asset verifications, and healthchecks enabling fast setup and standardized execution. * **Status Tracking and SLAs**\ Each task can carry metadata like **priority, deadline, SLA**, and assignment to specific analysts. The system tracks progress and flags overdue or blocked tasks automatically. * **Integrated Audit Trail**\ All task actions and transitions are logged and auditable, ensuring compliance with internal operational procedures and facilitating post-incident reviews. # Appliances The **Appliances** section of the Inopli RPA module provides full lifecycle management for **virtual execution environments**, enabling the distribution of automation workloads across physical servers or cloud-based infrastructures. Each appliance acts as a remote executor for playbooks, tasks, and integrations. *** ### Overview * **Virtual Appliance Deployment**\ Appliances are provisioned using **Docker-based images**, ensuring consistent and lightweight deployments across heterogeneous environments. Installation can be performed on bare-metal servers, virtual machines, or public cloud instances. * **Unlimited Scaling**\ There is **no limit to the number of appliances** that can be registered. Organizations are free to create as many as needed to support distributed automation, high availability, or multi-region operations. * **Centralized Control**\ All appliances are managed centrally within the Inopli interface. Admins can register, monitor, and remove appliances at any time, with visibility into their operational status and assigned workloads. *** ### Use Cases * **Distributed Execution**\ Appliances can be installed **close to the data or systems they need to interact with**, reducing latency for sensitive automations (e.g., internal AD changes, on-premises security controls). * **Workload Isolation**\ Different appliances can be dedicated to specific workflows, tenants, or departments — providing **logical and operational separation** where needed. * **Cloud-Native or On-Prem Ready**\ Whether deployed in a **Kubernetes cluster**, a **cloud VM**, or an **on-premises appliance**, the setup process remains the same, using containerized infrastructure with minimal prerequisites. --- [Next Page](https://docs.inopli.com/llms-full.txt/1)