Introduction
| Easy heading | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
...
The GYTPOL team will setup the SaaS infrastructure and the tenant. The relevant license, including device count and modules, will be allocated as per the agreed terms between the parties involved.
Client Sensor Deployment and Execution:
Deploy the GYTPOL Client Sensor on each endpoint/server device.
The GYTPOL Client Sensor executes once daily, at randomly chosen times, following a predefined sequence of actions.
The scanning process typically completes within 5-7 minutes.
Data Collection during Scan:
The GYTPOL Client Sensor collects data on misconfigurations and unpatched zero-day vulnerabilities during its scanning routine.
For Microsoft devices, it also gathers Group Policy data (Resultant Set of Policy - RSOP) and Intune data
...
Subsequent to data collection, the GYTPOL Client Sensor compresses and encrypts the gathered data.
Data Transmission Attempt:
The GYTPOL Client Sensor creates a connection with the GYTPOL Server to transmit the encrypted and compressed data.
The data transmission is conducted using port 443 for communication. This approach ensures that the encrypted and compressed data collected by the GYTPOL Client Sensor is securely transferred to the GYTPOL application, enhancing data privacy and protection during transit.
Once data is received from a GYTPOL ClientSensor, the GYTPOL application undertakes an analysis using our exclusive GYTPOL Analyzer. This Analyzer not only examines the data thoroughly but also stores the results in a designated database. To ensure data privacy and security, customers are segregated within the database. This proactive approach ensures that you are promptly informed about any possible security threats, helping to keep you well-informed about potential risks.
After the GYTPOL Client Sensor completes its scan and data is transmitted to the GYTPOL application, the IT and Security teams access the findings through the Web User Interface (UI). This interface is compatible with Chromium-based web browsers such as Google Chrome or the new Microsoft Edge.
The GYTPOL application is equipped with several integrations to enhance its functionality and facilitate seamless operations:
It interfaces with various public APIs to support data exchange and integration with external systems.
Integration with Ticketing Systems like ServiceNow is established, streamlining the process of generating and managing tickets based on GYTPOL's findings.
Notably, the GYTPOL Server also integrates with Security Information and Event Management (SIEM) systems. Selected events and data are sent from GYTPOL to SIEM platforms, such as MS Sentinel, or Splunk. This integration enhances the security ecosystem by aggregating GYTPOL's insights into the broader context of security events and monitoring.
...
Sensor Server Communication
The interaction between the client Sensor and the server operates in a one-way manner: the client Sensor initiates its task either on a daily or hourly basis (the clientSensor's tasks are elaborated upon in the client Sensor section). Following the task execution, the gathered data is transmitted to the GYTPOL server, where it undergoes analysis and subsequently appears in the user interface for review.
Should a GYTPOL operator execute a remediation action or any other task from the console, the client Sensor conducts periodic checks for new tasks every hour through its hourly task execution. Upon initiating the task locally, the client Sensor provides feedback to the server regarding the outcome, indicating either success or failure.
...
Sensor
GYTPOL provides support for Windows, Linux, and macOS operating systems. For a comprehensive overview of the supported platforms, please refer to the client Sensor installation guide available at this link: GYTPOL Client Sensor Installation Guide
The GYTPOL Client Sensor operates on a daily basis for a brief duration. Within this operational window, it accumulates data related to misconfigurations, unattended zero-day vulnerabilities, and outdated third-party software. This information is collected during the run and subsequently processed for further analysis.
GYTPOL
...
Sensor for Windows
Language-Code: GYTPOL is developed using a combination of C# and signed PowerShell.
...
Communication Protocol: GYTPOL employs the latest Transport Layer Security (TLS) version supported by the device for secure communication. All communication occurs over HTTPS to ensure data privacy and integrity.
GYTPOL
...
Sensor for Linux/macOS
Language-Code: GYTPOL is implemented using the Go programming language (Go-lang).
...
By selecting this option, you can request logs from GYTPOL's client Sensor on the device. This can be useful when further analysis of the device is required by GYTPOL to resolve a problem with GYTPOL's Agent on the device. The target agent will submit its logs, and when finished, a notification will appear in the System Notifications panel, under System Health. These logs can then be downloaded and submitted to GYTPOL for analysis.
...
For more comprehensive details and explanations about the user interface and its various features, please refer to the dedicated UI overview section within GYTPOL's documentation. This section will provide an in-depth understanding of how to navigate and utilize the interface effectively. It's a valuable resource to make the most of GYTPOL's capabilities and insights.
...
| Anchor | ||||
|---|---|---|---|---|
|
| Anchor | ||||
|---|---|---|---|---|
|
...
Sensors were successfully deployed
You can confirm a successful GYTPOL client Sensor deployment in two ways:
Local Device Check: Verify on the device where the client Sensor is installed to ensure proper functioning. For more details, you can refer to the Client Sensor Installation Guide here: Client Installation Guide
...
Red (High): Represents high-severity misconfigurations that require immediate attention due to their critical impact on security.
Orange (Medium): Indicates medium-severity misconfigurations that should be addressed promptly to mitigate potential risks.
Yellow (Low): Denotes low-severity misconfigurations that may not pose an immediate threat but should still be resolved to enhance overall security posture.
Green (Complied): Signifies items that are in compliance and meet the expected security standards, resulting in no alerts generated.
...
Defining Remediation Actions: Remediation Actions outline the corrective measures to be applied based on parameters like OU, Domain, or specified computer groups. The actions are grouped into topics, such as the SMB and Sharing topic including SMBv1 removal.
Pending Status and Acknowledgment: After a GYTPOL admin initiates an action, it remains in a pending status until the client Sensor device checks in (hourly) and confirms the task for local application.
Client Sensor Acknowledgment and Feedback: Once the client Sensor applies the task locally, it sends feedback to GYTPOL regarding the outcome. This feedback includes information on success, failure, and the reason for failure (e.g., timeout or access denial).
Revert Capability: Numerous remediation actions can be reverted to the original state directly from the GYTPOL UI. This streamlines the process and eliminates the need for third-party tools or scripts. All reverts are executed on the device within an hour, maintaining consistency with the hourly check-in schedule.
...
Identify the Finding: Start by identifying a particular misconfiguration or security finding that needs to be addressed.
Choose the Target Group: Select the group of devices on which you want to apply the remediation action. This can include specific devices, a group based on OU, Domain, or custom computer groups.
Initiate the Remediation Action: Define the specific action or fix that needs to be implemented to address the finding. This action can involve changes to configurations, settings, or other relevant parameters.
Pending Status and Client Sensor Check-In: After initiating the action, it enters a pending status. The respective client Sensor devices periodically check in (hourly) to receive and acknowledge the action.
Client Sensor Acknowledgment and Feedback: Once the client Sensor applies the action locally, it sends feedback to GYTPOL indicating the success or failure of the task, along with reasons for any failures.
Revert Capability (if applicable): If the action supports reversion to the original state, GYTPOL allows you to revert changes directly from the UI.
...
Auto Re-apply: This option ensures that the same remediation is automatically applied to new GYTPOL clients Sensors reporting for the first time or meeting the defined criteria.
...
Accessible from the homepage, you can access the corresponding dashboard on the left pane, by selecting the relevant standard. Once clicked, the CIS or NIST dashboard will be displayed, presenting the benchmark results. Here's a breakdown of the color codes used:
Green: Indicates that the settings within your organization are compliant.
Red: Denotes that the settings within your organization are not compliant.
Orange: Indicates that the settings are not managed in your organization, and there is no detectable Group Policy Object (GPO) containing the relevant setting.
...
This screen provides a comprehensive overview of reporting clientsSensors, including their status, the timestamp of their last successful scan, version information, operating systems, and the client Sensor scope (Endpoint, Server, or VDI).
Devices that are missing from reporting are color-coded as follows:
Light Blue: Devices reported within the last 24 hours.
Navy Blue: Devices that have not reported in the last 3 days.
Purple: Devices that have not reported in the last week.
Dark Blue: Devices that have not reported in 7-14 days.
...
GYTPOL High Level Architecture and Design - To access the GYTPOL HLD documentation, please get in touch with your GYTPOL Account Manager.
GYTPOL Client Sensor Installation, Client Sensor GPO deployment and Upgrade Guide
GYTPOL API documentation
GYTPOL Splunk Integration documentation (soon)
GYTPOL ServiceNow Integration documentation (soon)
| Anchor | ||||
|---|---|---|---|---|
|
| Anchor | ||||
|---|---|---|---|---|
|
...