02-18-2026, 01:19 AM
(This post was last modified: 02-18-2026, 01:26 AM by mrwebfeeder.)
GetOverX Shield implements detection logic informed by publicly available security guidance and frameworks such as CISA advisories, NIST recommendations, and MITRE ATT&CK technique mapping. Rules are validated for stability and are intended to support a defense-in-depth posture.
Where applicable, GetOverX Shield aligns its default policies and recommended rule sets with widely adopted defensive measures promoted for private-sector and home environments in public guidance from these organizations (e.g., hardening practices, suspicious execution patterns, and monitored behaviors).
These references are used as guidance sources, and any publicly available guidance from U.S. agencies can be used to build rules. Just keep in mind that overly restrictive rules may increase false positives, so we recommend starting in “log-only” mode and tightening gradually.
Examples:
{
"id": "P-LOG-USERZONES",
"enabled": true,
"name": "Log suspicious execution from user writable zones",
"match": { "pathInSuspiciousZones": true },
"action": "logOnly",
"notifyUser": true
}
{
"id": "P-ALLOW-SIGNED",
"enabled": true,
"name": "Allow signed baseline apps",
"match": {
"processNameIn": ["chrome.exe", "msedge.exe", "onedrive.exe"],
"requireSignature": true
},
"action": "allow"
}
{
"id": "P-KILL-CONFIRMED",
"enabled": true,
"name": "Kill confirmed unwanted tool",
"match": {
"processNameIn": ["psexec.exe"],
"pathInSuspiciousZones": true
},
"action": "kill",
"notifyUser": true
}
As a corporate user, you can request additional rule sets through a support ticket in your Client Area. Tell us your environment (endpoints, critical apps, and desired enforcement level), and we’ll provide the rules you need in a stable, validated format.
Where applicable, GetOverX Shield aligns its default policies and recommended rule sets with widely adopted defensive measures promoted for private-sector and home environments in public guidance from these organizations (e.g., hardening practices, suspicious execution patterns, and monitored behaviors).
These references are used as guidance sources, and any publicly available guidance from U.S. agencies can be used to build rules. Just keep in mind that overly restrictive rules may increase false positives, so we recommend starting in “log-only” mode and tightening gradually.
Examples:
{
"id": "P-LOG-USERZONES",
"enabled": true,
"name": "Log suspicious execution from user writable zones",
"match": { "pathInSuspiciousZones": true },
"action": "logOnly",
"notifyUser": true
}
{
"id": "P-ALLOW-SIGNED",
"enabled": true,
"name": "Allow signed baseline apps",
"match": {
"processNameIn": ["chrome.exe", "msedge.exe", "onedrive.exe"],
"requireSignature": true
},
"action": "allow"
}
{
"id": "P-KILL-CONFIRMED",
"enabled": true,
"name": "Kill confirmed unwanted tool",
"match": {
"processNameIn": ["psexec.exe"],
"pathInSuspiciousZones": true
},
"action": "kill",
"notifyUser": true
}
As a corporate user, you can request additional rule sets through a support ticket in your Client Area. Tell us your environment (endpoints, critical apps, and desired enforcement level), and we’ll provide the rules you need in a stable, validated format.
