Centros de Capacitación de Educación Especial (CECADEE)

The first thing to clarify here is that any notification sent to customers is considered a public notification. It is public because the vendor cannot effectively control the informa- tion. In a more narrower sense, public notification means broadcasting information to the general public, users, and nonusers. The following text uses public notification in this nar- rower sense.

After a vendor produces the remedy, the goal is to inform affected users about it hoping that users will take appropriate remedial actions. There are multiple ways how to approach this notification, and for a change, these approaches are not conflicting. It all boils down to whether it is possible to identify all affected users.

If a vendor can identify all users affected by the security vulnerability and be sure that these contacts are technical people who can evaluate the notification, it is sufficient to send a notification only to them. This model of notification is called "selected recipients" because only affected users are targeted. This model is often used, among others, by startups or small vendors. They can do that because such vendors tend to have close ties with their customers and know most of them by their names. Another class of vendors that can use this notification model is when a product is a service. Examples of this cate- gory are Cisco WebEx, Google Mail, and all Software-as-a-Service (SaaS) and cloud com- puting offerings. Extending this notification model further, you can also argue that the

vendor needs to notify only users who use the affected component or feature and not all users. A fictitious example of this scenario would be notifying only users that actually deploy Border Gateway Routing Protocol in their networks rather than all users of Cisco routers. Alternatively a vendor can notify only customers that fit into a certain profile, such as a large ISP or a financial institution. This profile of who will be notified does not need to be permanent and can change depending on the vulnerability.

Detractors of a notification model in which only selected user are informed about securi- ty vulnerability would often say that the vendors who use that model are hiding their vul- nerabilities. Furthermore, prospective customers cannot gauge by themselves how such vendors are handling vulnerabilities in their products. Often such arguments are voiced by researchers and academia. Taking into account researchers' motivations, it is easy to see that this notification model deprives them of information and impedes their work. On the other hand, this notification model also provides less information to miscreants.

Prospective customers of vendors who publish notifications only to their users can, pre- sumably, ask these vendors to disclose details about the vulnerability handling process and list of recently handled vulnerabilities. Responsible vendors should not have problems disclosing that kind of information. Conversely, if the vendors will not disclose any details related to the vulnerability handling, that would almost certainly signify a vendor that does not handle vulnerabilities well or at all. The vulnerability handling policy should be public irrespective of the notification model used by the vendor. The prospective user should also consult policies by other vendors (for example, Cisco, Microsoft, or Oracle) to see how responsible vendors with mature processes handle security vulnerabilities. The number of vulnerabilities that actually affect a product is not relevant by itself. A product can indeed be affected by two to three vulnerabilities in the past 24 months. What is more important is to ask for evidence of how many reports on potential vulnera- bilities have been handled and the reasons why these reports do not affect the product. Returning to the notification models, the second model is public notification. In this model, the vendor provides notices on its public website visible to everyone. Additionally, such vendors would often mail the notice to various public mailing lists. The reason why vendors would like to use this model lies in the inability to identify all affected cus- tomers. This situation can arise if products are sold via third parties (for example, part- ners and retail), and it is not possible to identify the actual users.

Advocates of this notification model compliment its openness, whereas critics point out that a) miscreants are learning about vulnerabilities and are able to create exploits, b) not all customers receive the notification, and c) some customers receive too much irrelevant information. Now look at the critic's arguments more closely.

The argument that miscreants also learn about vulnerabilities is correct. For a discussion of why that might not be too big of a problem, see the previous section, "Disclosing Internally Found Vulnerabilities." In short, if users know that miscreants are in a position to misuse vulnerabilities, this might provide additional impetus to an upgrade or apply workarounds.

It is also true that even with public notification, not all users receive the information. However, all reputable vendors that employ this notification model provide sufficient

information on how to access notifications on security vulnerabilities. This is clearly visi- ble from the product's documentation and, where applicable, the product itself might have features to display security notifications to the user. So, although it is not possible for a vendor to identify all customers, the vendor must provide the means for customers to view and receive that information.

The last critic's argument is that users receive irrelevant information that distracts them from their daily work. If you look at the volume of notifications that users might receive, and assuming a heterogeneous environment, you can estimate that number to be approxi- mately 200 messages per year. That would translate to, approximately, one notification per working day. Hardly a high volume. Second, if users would like selective notification, they would need to provide vendors with sufficient details on used products and their configuration. That information would enable vendors to notify users only on relevant events, but the onus is on users to provide and maintain that information. However, a majority of users cannot provide and maintain that information.

To conclude this section, both notification models—public and selected users only—are mandated by the vendor's ability to identify affected users. Methods are not mutually exclusive, and the vendor can use both of them if they are adequate for the purpose. And, to repeat, the purpose is to notify affected users. Any other fringe benefits that notification may bring (for example, advancing research) are certainly a bonus but are secondary to helping users.