Skip to content

Incident process

Email support@rhinorelay.com with “Security” in the subject. Tell us:

  • what you saw, and when (with the time zone),
  • your tenant ID, from the console,
  • any requestId values from our responses, and CloudTrail event IDs from your account,
  • how to reach you.

Don’t send contact data, API keys or other secrets. If a key may be exposed, revoke it first on the console’s API keys page. We reply to security reports within 1 business day.

If you need to stop us now, do any of these, strongest first:

  1. In IAM, open the role rhino-relay-access-<TenantId> and choose Revoke active sessions. Every session issued before that moment stops working at once.
  2. Set Disconnect to true on your stack. From then on we can’t open a new session, the forwarding rules stop sending us your events, and sessions already open lose their permissions within minutes. Your data stays. See Disconnecting.
  3. Delete the stack. Your tables and buckets are kept.
  1. Triage. We confirm what happened and which customers are affected.
  2. Contain. Within minutes we can stop all of our code in every Region, turn off every queue trigger, and attach a deny policy to our execution role, so no new session into any customer’s account can be opened. We then rotate the secrets involved, such as the keys that encrypt unsubscribe links and the secret API keys are hashed with. If we rotate the API-key secret, your keys stop working and you create new ones in the console. We’ll ask you to revoke active sessions on the role, as above, if sessions already issued might have been misused.
  3. Notify. We notify affected customers within 72 hours of becoming aware of an incident that affects their data, by email to your console admins (and your subscriber address, if you subscribed through AWS Marketplace): what happened, when, what could have been accessed in your account, what we’ve done, and what we recommend. We also tell AWS Marketplace when Marketplace customers are affected, and send updates as we learn more.
  4. Recover. We fix the cause and restore normal service.
  5. Report. Within 14 days we publish a post-incident report on this site: the timeline, the cause, the impact (by kind of data, never naming customers), what we changed, and the test that now covers it.

Every session our service opens in your account is in your CloudTrail, with the function that opened it as sourceIdentity. See Every call is visible.

Status updates during an incident are posted on the status page.