Subject: [domainrep] Threat Taxonomy (Tentative requirements list)

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Tue, 07 Sep 2010 22:22:27 +0200

Hi, all,

in the series 'Tentative Requirement List' here is a summary of what has 
been discussed on this list regarding a 'threat taxonomy'.

The idea of a threat based taxonomy was launched by Nathaniel on 08/22.

    * Perhaps we should be worrying about taxonomizing threat types
      rather than industry codes?
    * We would confine ourselves to the things we actually care about.
    * We know way more about online threats than we do about categories
      of organizations.
    * A threat taxonomy is a fine idea, but it's orthogonoal to an
      organization taxonomy. There are banks that send spam, and ESPs
      that don't.
    * [...] a few, highly logical top-level categories, with a possible
      proliferation of subcategories.
    * four categories:

       1. sending unsolicited bulk email (subcategories might include fraud)
       2. sending email with false/deceptive sender information
          (subcategory: claiming falsely to be a trusted institution,
          perhaps with financial and other sub-subcategories)
       3. sending active malware content (several subcategories possible)
       4. failure to maintain best practices for email servers (possible
          subcategories for open relays, Non-responsiveness (or
          unacceptably slow response) to abuse reports, etc.)

Comments:

    * Ad 1: Bulk and fraud are separate.
    * Ad 2: I see those as functionally separate; fraud to sneak
      unwanted but otherwise harmless content into inboxes (Gevalia type
      spam) vs. fraud to enable crime.
    * So to get back to the threat taxonomy, I suggest to define it in
      the context of a large query system, but not in the context of the
      small one.
    * [...] we may be more successful if we skip that part, and focus on
      a protocol which could communicate a value for ANY information
      regarding a particular identifier (likely a domain name.) Then,
      let the Reputation Providers and Reputation Clients work out which
      information they want to provide or consume.
    * Something along the lines of RFC5070 would likely represent a
      better starting point for general purpose reputation services.

      http://tools.ietf.org/html/rfc5070

      See section 3.10.1 Impact Class

Questions:

Say we've got a DKIM d= domain in each of these categories. How/why 
would an MTA treat them differently?

---

It seems there is no consensus yet on whether a threat taxonomy is to be 
part of the reputation query protocol.

/rolf

---

From: Douglas Otis <[email-masked]>
Date: Tue, 07 Sep 2010 14:23:54 -0700

On 9/7/10 1:22 PM, Rolf E. Sonneveld wrote:
> Hi, all,
>
> in the series 'Tentative Requirement List' here is a summary of what 
> has been discussed on this list regarding a 'threat taxonomy'.
>
Yes. I also suspect recipients may want an estimate of the volume of 
domain traffic, where the requester can then draw their own conclusions 
in how this relates to incidents being reported.  Examples of this 
information could be seen in sender base, however log e rather than log 
10 represents a more applicable scale having better resolution.
>     * We would confine ourselves to the things we actually care about.
Perhaps confine the work to things that most care about.
>
>     * We know way more about online threats than we do about
>       categories of organizations.
>
Agreed.  There could be different extensions specific to different 
protocols being monitored.
>       organization taxonomy. There are banks that send spam, and ESPs
Agreed.
>
>     * [...] a few, highly logical top-level categories, with a
>       possible proliferation of subcategories.
>     * four categories:
>
>        4. failure to maintain best practices for email servers
>           (possible subcategories for open relays, Non-responsiveness
>           (or unacceptably slow response) to abuse reports, etc.)
>
RFC5070 already provides a reasonable breakdown where policy incidents 
could relate to 1. unsolicited messages of any volume. 2. could fall 
into social-engineering.  3. Malware could fall into "admin, user, file, 
or info-leak depending upon the nature of the threat.  Item 4 could fall 
under policy, misconfiguration, dos, or recon.  One might also want to 
know whether both directions of port 25 are being blocked, except to 
designated MTAs.  Open replays and open proxies might also include CGNs 
to support IPv6.  Not being responsive to abuse reports should have its 
own category, assuming all reports authenticated the domain before 
having originated the abuse reports.

>     * Ad 1: Bulk and fraud are separate.
Of course.

>       unwanted but otherwise harmless content into inboxes (Gevalia
>       type spam) vs. fraud to enable crime.
>       the context of a large query system, but not in the context of
>       the small one.
>
Would large represent pushing hashes for threat categories rather than 
supporting individual queries?  The use of hashes en masse would better 
protect the privacy of the requestor.

>     * [...] we may be more successful if we skip that part, and focus
>       on a protocol which could communicate a value for ANY
>       information regarding a particular identifier (likely a domain
>       name.) Then, let the Reputation Providers and Reputation Clients
>       work out which information they want to provide or consume.
>
There are already many proprietary services offering nothing that would 
permit data comparisons l.  Measurements need definite
> would an MTA treat them differently?
Ask the question the other way around.  When d= domain is within one of 
these categories, an MTA is less likely to accept their messages.  There 
could be a neutral category used to indicate the domain traffic volumes 
and when the domain was first detected.  Depending upon the measurement 
interval, this might encompass hundreds of millions of different domains.
> It seems there is no consensus yet on whether a threat taxonomy is to 
> be part of the reputation query protocol.
An extension of RFC5070 should offer a good starting point.

-Doug