Share your product feedback!

Please tell us what we can do to make INKY’s Email Security Platform the best product for you.

Native Integration with SaaS Alerts / Kaseya SIEM for IoC Telemetry

We’d like INKY to provide native telemetry integration with SaaS Alerts and Kaseya SIEM to forward actionable Indicators of Compromise. RocketCyber previously integrated with Graphus, allowing phishing telemetry to feed directly into the SOC for correlation and response. That level of ecosystem alignment should exist with INKY. Currently, INKY threat intelligence remains siloed in the console. For MSPs standardising on the Kaseya stack, this limits SOC visibility and cross-platform correlation. Requested capability: β€’ Real-time event forwarding via API/webhook β€’ Structured IoC data including: – Sender domain / envelope-from – URLs and attachment hashes – Threat classification and confidence – User interaction signals where available β€’ Direct ingestion into: – SaaS Alerts – Kaseya SIEM Why this should be prioritised: β€’ Restores ecosystem parity with prior Graphus + RocketCyber integration β€’ Strengthens Kaseya-stack alignment β€’ Enables SOC correlation and automated response β€’ Increases MSP platform stickiness This positions INKY not just as email filtering, but as a SOC-grade telemetry source within the Kaseya ecosystem.

Imraan Sathar 26 days ago

πŸ“§

Email Security

Inky admin permissions - allow granular control

It appears that Super Admin is required for onboarding customers. This also allows full access to the Inky product. This means that 10+ engineers in our MSP need Super Admin permissions, with the most of rest of the team effectively needing policy management (the second highest tier). Best practice is to provide only the minimum amount of access to do the job required. There should be more granular permissions: -There should be a separate role for user management at MSP level (i.e. an internal MSP IT person owns this role - this typically would not be someone servicing customers day to day) -There should be a separate role that allows for onboarding new customers (i.e. The professional services/projects/onboarding teams should be able to onboard customers without relying on internal MSP support) -Permissions should be separated for access to mail security and signature management (to ensure different staff can be provided access based on their skillset to reduce risk of access to settings they shouldn’t modify)

Steven Richardson About 2 months ago

1
πŸ“§

Email Security