Cyber insurance endpoint control questions, answered

Do you have endpoint detection deployed across all endpoints?

ET Ducky runs ten always-on behavioral rules against the kernel event stream on both Windows and Linux. The rules cover mass file access, mass file rename to ransom extensions, ransom-note patterns, shadow copy and backup deletion, suspicious execution chains, reverse-shell heuristics, privilege escalation from non-interactive parents, unusual outbound traffic from system daemons, a crypto-miner heuristic, and a kill-chain meta-rule that fires when two or more of the other components occur within five minutes.

Detection runs on events already streaming from the kernel, which means the agent evaluates what the operating system observed rather than what a user or a script reported.

Can you isolate or quarantine an endpoint remotely?

Yes, and it happens without an operator when a detection meets the configured confidence threshold. The default threshold is High.

On isolation the agent sets the Windows Firewall default outbound action to Block across the Domain, Private and Public profiles, then adds explicit allow rules prefixed ETDucky-Isolation- for:

• The ET Ducky agent process, so the management channel survives cloud-side IP rotation
• The ET Ducky API endpoint, as a backup address-based rule resolved at isolation time
• DNS resolution on port 53 from the Windows DNS Client service
• Loopback traffic
• An operator-configured security vendor allowlist, so an existing EDR agent keeps reporting

Isolation is idempotent. The agent writes its isolation state to %ProgramData%\ETDucky\isolation.state on every transition and reconciles that state against the rules on disk at startup, so isolation survives a reboot and a crashed prior run does not leave stale rules behind. A ticket is opened in the connected ticketing system with the full alert detail and a note that isolation was applied.

How is isolation removed?

Removal uses dual approval. An authenticated request from the dashboard is necessary but not sufficient. A person physically at the device must independently approve before firewall rules come down. Two paths satisfy this: a single-use HMAC-TOTP code generated by an org admin and entered on the device, or a dashboard-initiated command that spawns an approval prompt in the active console session and waits up to five minutes for the person at the device to approve.

This is worth calling out to an underwriter, because it means a stolen dashboard session cannot silently un-isolate a device.

Do you log endpoint activity, and how long is it retained?

Retention is set per agent, and the tier determines the steady state:

Purging runs as a scheduled background service. Purged data is permanently deleted and no archival copy is kept unless the customer configures one at the infrastructure level.

One exception suspends the purge. When a security incident is raised against an organization, that organization is placed on a legal or security hold and every purge skips it so the evidence trail survives the investigation. A held organization therefore accumulates data past its purchased window for as long as the hold lasts. Automatic holds expire 365 days after placement. Manual holds remain until an administrator releases them. If a retention assessment asks for a guaranteed maximum age, the tier is not that guarantee and the hold behavior should be disclosed.

What is written to the audit trail?

• Authentication attempts, with failures returning no information about valid agent identifiers
• Agent connection and disconnection events with agent, organization and connection identifiers
• Alert rule evaluations, logged per agent with timestamps
• Script creation and modification, with user identity, organization, timestamp and a SHA-256 content hash
• Every command execution, with risk score, matched indicators, user identity, target agent, command hash and the execution decision

Is multi-factor authentication enforced on the management console?

Identity is handled entirely by Clerk, a SOC 2 Type II certified provider. ET Ducky does not store passwords, manage sessions, or handle MFA directly. TOTP, SMS and passkey factors are available, session lifetime and idle timeout are configurable, and SAML or OIDC single sign-on is available on Clerk's enterprise plan.

Enforcement is a customer configuration. An application answer should state that the factor is available and whether it has been turned on, not that it is enforced by default.

What ransomware-specific controls are in place?

Four of the ten behavioral rules target ransomware behavior directly: mass file rename to ransom extensions, ransom-note patterns, shadow copy and backup deletion, and mass file access. The kill-chain meta-rule fires when two or more of those co-occur within five minutes, which is the condition that triggers automatic isolation at default settings.

Because detection is behavioral rather than signature-based, a sample that has never been seen before is evaluated on what it does to the file system and the shadow copy service.

Do you detect unauthorized or altered software?

Two mechanisms, both shipped default-off with a shadow mode so they can be tuned before they alert:

• Approved-app binary integrity. Agents report a SHA-256 hash of each approved application's primary binary. The cloud keeps a per-organization hash ledger on a trust-on-first-use basis, with the reference hash elected by agent majority. A later divergent hash for the same application, version and architecture raises a detection once. Reference hashes never cross organizations.
• Fleet behavioral baselines. The cloud learns a per-application behavioral profile from the organization's own fleet in 15-minute rollups and flags hosts where an application behaves as an outlier.

Endpoint posture reported in the heartbeat also covers Defender status and definition age, firewall state, BitLocker, UAC and Secure Boot, which are the fields most application forms ask about separately.

Who can run commands on endpoints, and is it logged?

Command execution, script execution, file browsing and live sessions are all initiated by authenticated dashboard users within their own organization scope. Every command is evaluated against 18 risk indicators before it runs. Indicators cover known malicious patterns, command-and-control infrastructure, credential harvesting tools, obfuscation techniques and dangerous system operations. Commands matching indicators from prior incidents receive the maximum score automatically.

Executions are rate limited to 30 per user per organization per hour. Every execution decision is logged with its full risk assessment.

On Linux, privilege escalation requires explicit operator authorization with an audit trail. The agent never silently escalates.

Where is the data stored, and who else touches it?

All infrastructure runs in DigitalOcean's United States regions. Data does not leave the United States for storage or processing, with one exception: when a user explicitly triggers an AI analysis, aggregated telemetry summaries are sent to Anthropic's API. AI analysis is user-initiated, never automatic, and no personally identifiable information, credentials, file contents or raw event data is included.

The platform does not collect end-user content, browsing history, keystrokes, file contents or employee activity. What it does collect is documented in the security whitepaper under Data Collection Scope.

What can ET Ducky not attest to?

Two things belong in any honest submission.

ET Ducky is not SOC 2 audited. The whitepaper maps controls to the SOC 2 Trust Services Criteria, ISO 27001 Annex A, NIST CSF and GDPR Article 32. A mapping is not a certification and is not presented as one. See SOC 2 endpoint logging controls for the mapping itself.

ET Ducky is not an antivirus or a signature-based malware scanner. If a policy requires a named anti-malware product, ET Ducky does not remove that requirement, and Defender status reporting is how the two coexist.