User Guide Functional Overview Requirements Architecture System Installation NetEye Additional Components Installation Setup The neteye Command Director NetEye Self Monitoring Tornado Business Service Monitoring IT Operation Analytics - Telemetry Geo Maps NagVis Audit Log Shutdown Manager Reporting ntopng Visual Monitoring with Alyvix Elastic Stack IT Operations (Command Orchestrator) Asset Management Service Level Management Cyber Threat Intelligence - SATAYO NetEye Update & Upgrade How To NetEye Extension Packs Troubleshooting Security Policy Glossary
module icon Cyber Threat Intelligence - SATAYO
Introduction Getting Started SATAYO Items Settings Managed Service Mitre Attack Coverage Changelog
ntopng Visual Monitoring with Alyvix Elastic Stack IT Operations (Command Orchestrator) Asset Management Service Level Management Cyber Threat Intelligence - SATAYO Introduction to NetEye Monitoring Business Service Monitoring IT Operation Analytics Visualization Network Visibility Log Management & Security Orchestrated Datacenter Shutdown Application Performance Monitoring User Experience Service Management Service Level Management & Reporting Requirements for a Node Cluster Requirements and Best Practices NetEye Satellite Requirements TCP and UDP Ports Requirements Additional Software Installation Introduction Single Node Cluster NetEye Master Master-Satellite Architecture Underlying Operating System Acquiring NetEye ISO Image Installing ISO Image Single Nodes and Satellites Cluster Nodes Configuration of Tenants Satellite Nodes Only Nodes behind a Proxy Additional NetEye Components Single Node Cluster Node Satellites Nodes only Verify if a module is running correctly Accessing the New Module Cluster Satellite Security Identity and Access Management External Identity Providers Configure federated LDAP/AD Emergency Reset of Keycloak Configuration Advanced Configuration Authorization Resources Tuning Advanced Topics Basic Concepts & Usage Advanced Topics Monitoring Environment Templates Monitored Objects Import Monitored Objects Data Fields Deployment Icinga 2 Agents Configuration Baskets Dashboard Monitoring Status VMD Permissions Notifications Jobs API Configuring Icinga Monitoring Retention Policy NetEye Self Monitoring 3b Concepts Collecting Events Add a Filter Node WHERE Conditions Iterating over Event fields Retrieving Payload of an Event Extract Variables Create a Rule Tornado Actions Test your Configuration Export and Import Configuration Example Under the hood Development Retry Strategy Configuration Thread Pool Configuration API Reference Configure a new Business Process Create your first Business Process Node Importing Processes Operators The ITOA Module Configuring User Permissions Telegraf Metrics in NetEye Telegraf Configuration Telegraf on Monitored Hosts Visualizing Dashboards Customizing Performance Graph The NetEye Geo Map Visualizer Map Viewer Configuring Geo Maps NagVis 3b Audit Log 3b Overview Shutdown Manager user Shutdown Manager GUI Shutdown Commands Advanced Topics Overview User Role Management Cube Use Cases ntopng and NetEye Integration Permissions Retention Advanced Topics Overview User Roles Nodes Test Cases Dashboard Use Cases Overview Architecture Authorization Elasticsearch Overview Enabling El Proxy Sending custom logs to El Proxy Configuration files Commands Elasticsearch Templates and Retentions El Proxy DLQ Blockchain Verification Handling Blockchain Corruptions El Proxy Metrics El Proxy Security El Proxy REST Endpoints Agents Logstash Elastic APM Elastic RUM Log Manager - Deprecated Overview Authorization in the Command Orchestrator Module Configuring CLI Commands Executing Commands Overview Permissions Installation Single Tenancy Multitenancy Communication through a Satellite Asset collection methods Display asset information in monitoring host page Overview Customers Availability Event Adjustment Outages Resource Advanced Topics Introduction Getting Started SATAYO Items Settings Managed Service Mitre Attack Coverage Changelog Before you start Update Procedure Single Node Upgrade from 4.41 to 4.42 Cluster Upgrade from 4.41 to 4.42 Satellite Upgrade from 4.41 to 4.42 DPO machine Upgrade from 4.41 to 4.42 Create a mirror of the RPM repository Sprint Releases Feature Troubleshooting Tornado Networking Service Management - Incident Response IT Operation Analytics - Telemetry Identity Provider (IdP) Configuration Introduction to NEP Getting Started with NEPs Online Resources Obtaining NEP Insights Available Packages Advanced Topics Upgrade to NetEye 4.31 Setup Configure swappiness Restarting Stopped Services Enable stack traces in web UI How to access standard logs Director does not deploy when services assigned to a host have the same name How to enable/disable debug logging Activate Debug Logging for Tornado Modules/Services do not start Sync Rule fails when trying to recreate Icinga object How to disable InfluxDB query logging Managing an Elasticsearch Cluster with a Full Disk Some logs are not indexed in Elasticsearch Elasticsearch is not functioning properly Reporting: Error when opening a report Debugging Logstash file input filter Bugfix Policy Reporting Vulnerabilities Glossary 3b

Managed Service

The content described in this page is valid for the customers who possess the SaaS & Managed version of SATAYO. If you don’t have it you won’t see this features in SATAYO, but you can read here anyway to understand how it works.



General info

After the initial scan is completed, SATAYO allows you download a report at any time in which the Exposure Assessment Index Value is calculated based on the evidences found. The procedure on how to do it was already explained in the section How does SATAYO work. This applies to all the modalities in which SATAYO is offered, but with the SaaS & Managed version our team will periodically schedule a one-hour meeting with you to discuss the findings, align on what the platform is tracking, discuss any new domain to be added to the organization or any new keywords to be inserted.



Help Center

The Help Center of Wuerth Phoenix, is the place where you can open tickets or requests for malfunctions, informations, help with configurations or anything you need.

The Help Center is based on Atlassian Jira and you need a Jira account to open requests. In case you don’t have it, it can be easily created here. Simply enter your email address and you will receive a link to finalize the registration.

SATAYO evidences are analyzed by our analysts and the analyses are communicated to you through this portal. The opening of tickets and their possible statuses is explained in the next section.



Tickets in SATAYO

Jira has been integrated into SATAYO, and in some sections such as domains, vulnerability, market, open bug bounty, general social and sandboxes, you will see a column called Status.

This column may show different options, depending on the status of the ticket. The possible scenarios you can encounter are the following three:

../../../_images/ticketCustomer.png


  1. Status and ticket number: When a ticket is opened, progress and status changes are shown. The link points directly to the ticket in Jira. The status varies as the analysis proceeds.

  2. Status Acknowledged: The evidence was reviewed by an analysts and marked as acknowledged. An acknowledged status opens an internal ticket, that can be shared with the customer if requested.

  3. Blue icon: This evidence doesn’t have an associated ticket. Clicking on the icon allows you to open a ticket for the selected evidence, where further analysis can be requested.

The Acknowledged status indicates that an analysis was performed and the evidence was classified as false positive or not dangerous. This means there was no need to bother the client with a ticket and only an internal note was created. If requested, the internal ticket containing the analysis can be shared.

Note

Our analysts follow a logic and open tickets for suspicious evidences by prioritizing the most dangerous ones. You will be informed via email notification when a new analysis is available.

Status of the tickets can be checked from Settings -> Status Managed. Here detailed information about tickets are shown. There is a link for each ticket that brings you to the Help Center where you can directly interact with it. When the status of the ticket is in Waiting for Customer it means it’s your turn to open it, read what we analyzed and the mitigation we proposed and comment.


How to open tickets

In order to open tickets, your must have a Jira account associated to your SATAYO account. From Settings -> Support you can check if your account is correctly activated.

../../../_images/registered.png

If you see REGISTERED it means you won’t have problem to open tickets.



Tickets in Jira


Ticket interface

When you open a link to a ticket, you will see an interface similar to this one:

../../../_images/helpCenter.png

  1. Ticket details may be hidden if there are multiple comments under it, but they can be easily expanded with the Show details button.

  2. From this section the current status of the ticket is shown and you have the option to edit it.

  3. Participants (people who can see and interact with the ticket) are listed here. Additional people can be added if necessary.

  4. From here it is possible to comment on the ticket. After a customer comment, the status automatically changes and becomes Waiting for Support. Similarly, after an analyst comment, the status becomes Waiting for Customer. Your action in required when the ticket is in this status.


Ticket statuses

The following image shows the workflow of the different statuses of a ticket:

../../../_images/ticketStatuses.png

  • OPEN, marked in GREY, is the first status of each ticket

  • IN PROGRESS, IN PROGRESS FOR CUSTOMER, WAITING FOR CUSTOMER, WAITING FOR SUPPORT, marked in BLUE, are the statuses that show the ticket is managed by someone, either a customer or an analyst.

  • RESOLVED, CANCELED, RISK ACCEPTED, FALSE POSITIVE, marked in GREEN, are the final statuses of each ticket. When the ticket is closed, it’s in one of these four statuses.


Ticket fields

In addition to the status, every opened ticket has other important values: Priority, TLP and Indicators.

  • The priority value can range from Lowest, Low, Medium, High, Highest, and refers to the severity of the evidence.

  • The TLP is the Traffic Light Protocol value, a standard created by FIRST that provides a simple and intuitive scheme for defining the level of sharing of potentially sensitive information. There are four levels of sharing: TLP:RED, TLP:AMBER, TLP:GREEN and TLP:CLEAR. The default level of the tickets is TLP:AMBER.

  • Indicators are a collection of IoC and IoA and can belong to different categories. They are explained below.

Indicators

Analysis activities may allow IoC or IoA to be identified. Sometimes it is sufficient to monitor these indicators, while at other times it is important to take active defensive actions against them. When found, IoC and IoA are inserted in two ticket fields called Indicator and Blacklist Indicator.

The indicators inserted in the Blacklist Indicator field are collected by an automatic phase (which runs every 10 minutes) that populates a SATAYO table. The table can be reached from Settings -> Indicators. The collected indicators are divided into several files and made available to you.

An example of the types of indicators and the related links that can be used to download resources is shown below:

Indicator Type

Access for the customer

IP

https://indicatorblacklist.satayo.cloud/<customer_hash>_IP

Domain

https://indicatorblacklist.satayo.cloud/<customer_hash>_Domain

Email

https://indicatorblacklist.satayo.cloud/<customer_hash>_Email

HASH

https://indicatorblacklist.satayo.cloud/<customer_hash>_HASH

URL

https://indicatorblacklist.satayo.cloud/<customer_hash>_URL

Other

https://indicatorblacklist.satayo.cloud/<customer_hash>_Other

It’s recommended to configure a schedule capable of downloading indicators every few minutes and automatically integrating them within your own infrastructure.

Some suggestions about possible usages:

  • IP - Integrate them within traffic drop rules on firewalling devices, to deny the ingoing/outgoing traffic to/from the IPs

  • Domain - Use them within traffic drop rules on mail servers

  • Email - These may come from SATAYO market evidences or Brute Force attempts. A suggested usage could be to convert the emails to the proper format in order to reset the password on authentication servers (e.g. AD server)

  • HASH - Use them on EDR software to filter out malicious software or within DFIR scenarios

  • URL - Use them on proxy to block malicious connections or on mail server to block links

  • Other - The usage of this type of evidence may vary as it may contain several different elements