We describe several threats faced by any alert sharing scheme, in the order of increasing severity. The attacker may launch attacks of several types simultaneously.
Casual browsing. Alerts published by a repository may be copied, stored and shared by any Internet user, and are thus forever out of control. The mildest attack is casual browsing, where a curious user looks for familiar IP prefixes and sensor IDs in the published alerts. This attack is easy to defend against, e.g., by hashing all sensitive data.
Probe-response. A determined attacker may attempt to use the alert repository as a verification oracle. For example, he may target a particular system and then observe the alerts published by the repository to determine whether the attack has been detected, and, if so, how it was reported. By comparing IP addresses contained in the reported alert with that of the targeted system, the attacker may learn network topology, sensor locations, and other valuable information.
Dictionary attacks. The attacker can pre-compute possible values of alerts that may be generated by the targeted network, and then search through the data published by the repository to find whether any of the actual alerts match his guesses. This attack is especially powerful since standard hashing of IP addresses does not protect against it. For example, the attacker can simply compute hashes for all 256 IP addresses on the targeted subnet and check the published alerts to see if any of the hash values match. Using semantically secure encryption on sensitive fields is sufficient to foil dictionary attacks, but such encryption also makes collaborative analysis infeasible because two encryptions of the same plaintext produce different ciphertexts with overwhelming probability. A polynomially-bounded analyst cannot feasibly perform equality comparisons unless he knows the key or engages in further interaction with the alert producer.
Alert flooding. If the repository publishes only the highest-volume alerts (or those satisfying any other group condition), the attacker may target a particular system and then ``flush out'' the stimulated alert by flooding the repository with fake alerts that match the expected value of the alert produced by the targeted system. This involves either spoofing source addresses of legitimate sensors, setting up a bogus sensor, or taking over an existing sensor. Flooding will cause the repository to publish the real alert along with the fakes. The attacker can discard the fakes and analyze the real alert.
Repository corruption. Finally, the attacker may deliberately set up his own repository or take control of an existing repository, perhaps in a manner invisible to the repository administrator. This attack is particularly serious. It eliminates the need for alert flooding and aggravates the consequences of probe-response, since it gives the attacker immediate access to raw reported alerts, as well as the ability to determine exactly (e.g., by inspecting incoming IP packets) where the alert has arrived from. We describe several partial solutions in section 6. Solutions based on sophisticated cryptographic techniques such as oblivious transfer [26] currently appear impractical. They provide better theoretical privacy at the cost of an unacceptable decrease in utility and performance, but the balance may shift in favor of cryptography-based solutions with the development of more practical techniques.