FIRST Victim Notification Service

Victim Notification

FIRST is working with Randy Pargman to assume ownership of his early warning system. The FIRST Victim Notification service will be an information security emergency alert mechanism that is open to vetted individuals on an invitation-only basis.

It will allow responders to register IP addresses and ASNs under their responsibility. If a breach is detected the system automatically notifies the appropriate responders. The intention is to implement this as a FIRST resource, open to members and non-members. As a global, non-political, non-profit organization, we believe we are well placed to offer this service.

The original service is currently running and is available for use. If you are interested in registering your IP ranges or ASNs please let us know at Victim Notification. Please Note that the system currently runs on a trust basis. FIRST plans to continue development of the product as an open-source project. For this we would like to start a SIG with interested people. The SIG will guide the development of the system and discuss governance aspects.

If you would like to request to join the SIG please do so here:

Request to Join

More information

For more information on the FIRST Victim Notification service, please contact Victim Notification.

FAQ

Q: What is this system designed for?
A: The primary focus is to rapidly notify victims of ongoing breaches that require immediate action. For example, many cloud storage operators see victim data exfiltrated and can use this system to alert the victim of a pending encryption.

Q: Why do you not use existing contact databases?
A: First and foremost we believe in opt-in. We may, at some stage and after discussing with resource owners, ingest or integrate with other contact databases. Furthermore this system uses other channels beside e-mail for notification (Signal, Slack, Microsoft Teams, ServiceNow, etc).

Q: Won't this duplicate existing services?
A: No, most existing services are either closed to the operators for sending out notifications, or are contact databases. APIs are great but your system should be usable to people that don’t want to use APIs.

Q: Why don’t you use X’s address list?
A: See above, but most contact lists are either proprietary or local in scope. Some databases list resource owners and not the responsible incident handler.

Q: But others, such as Team Cymru or Shadowserver, send out such information already. Why do you compete?
A: We don’t compete. Our projects allows responders to quickly inform relevant peers of an ongoing breach, without going through a third-party service. Our service is not suitable for large scale vulnerability reporting.

Q: Why are you not collaborating with others?
A: We are happy to do so. This tool was born out of a need, and it currently focuses on one problem: Rapid victim notification to stop an ongoing breach. Other services do different, although similar things.

Q: Why don’t you support feature Y?
A: The system was designed to solve one problem: Rapid notification of victims of an ongoing breach. We may in the future add other use cases.

Q: How do you ensure data stays up to date?
A: This is a good question, for which we don’t yet have a scalable answer. But it is something we will look at, and we are happy to learn from others.