ICANN ICANN Email List Archives

[gnso-ff-pdp-may08]


<<< Chronological Index >>>    <<< Thread Index >>>

Re: [gnso-ff-pdp-may08] Definition V4.2: concern about "consumer-grade"

  • To: Eric Brunner-Williams <ebw@xxxxxxxxxxxxxxxxxxxx>, Joe St Sauver <joe@xxxxxxxxxxxxxxxxxx>
  • Subject: Re: [gnso-ff-pdp-may08] Definition V4.2: concern about "consumer-grade"
  • From: Dave Piscitello <dave.piscitello@xxxxxxxxx>
  • Date: Fri, 1 Aug 2008 10:53:32 -0700

Eric,

If you feel we have dismissed your assertion, then let's discuss it now.

I asserted that we should "use multiple markers and anomalous behaviors to 
characterize malicious activity."

I think operating system is a reasonable, additional marker. We can disagree 
whether this is the root cause of one of many but that doesn't make this marker 
any less valuable.

We have strong evidence that (unpatched or unlicensed) Windows versions have a 
higher incidence of hosting malware than other OSs (we may even get this from 
Microsoft, I recall they presented this information at some conference I 
attended). We've discussed the possibility of having ISP's employ NAC or an 
equivalent "agent free" admission control mechanism. We could add this to a 
list of desirable/best practices.

Several methods of determining operating system (OS fingerprinting nmap style) 
exist even if NAC is not implemented. I can imagine a scenario where an access 
provider non-intrusively determines the OS of a subscriber and uses this as a 
factor in assessing that endpoint's behavior. We could study this.

I don't think singling Microsoft out is necessary or sufficient. I think that 
we need something more than a boolean "MS or not" here so I'd want to add a 
weighting factor that today lends more suspicion to various Windows versions 
over others, that acknowledges that other operating systems can host bots today 
and that the exploitation of OS by malware writers will change over time.


On 8/1/08 12:49 PM, "Eric Brunner-Williams" <ebw@xxxxxxxxxxxxxxxxxxxx> wrote:



is this for my benefit joe, or are you just spouting off?

if it is for my benefit, then you have to be addressing the assertion,
mine, that autonomous system is less determinitive of risk than whether
the network attached device is a microsoft operating system product, and
therefore a poor substitute, if the root cause is not to be ignored.

reputation has been discussed more than once on nanog, which i know even
if you don't.

hold the "regards", i prefer real ones over what's available.


Joe St Sauver wrote:
> Eric mentioned:
>
> #Further, using AS as determinative is vastly less accurate to the root
> #problem than using if-MS-then-NO as a gating mechanism, regardless of
> #how much corporate chrome there is on the AS and its commercial
> #operations. Since I don't think people want to go down the
> #if-MS-then-obvious-conclusion path, the AS-is-guilty false equivalent
> #should be dismissed.
>
> In general, ASNs do accumulate reputation, just as domains accumulate
> reputation, and just as netblocks accumulate reputation. One particularly
> notorious example of this from recent years would probably be the "RBN"
> case, although there are others.
>
> The real value of ASN-based reputation accumulation, however, is that:
>
> -- there are relatively few ASNs (at least until 4 byte ASNs get
>    widely deployed)
>
> -- it is possible to mechanically and scalably map IP's to ASNs
>
> -- if you route a network block, you also have the option of not routing
>    all or part of that block (e.g., there is a connection between an
>    ASN associated with an activity, and the ability to control that
>    activity)
>
> Most ASNs live somewhere on the vast continuum rightward of clean-as-
> the-driven-snow and leftward of dirty-as-a-deep-rock-coal-miner-at-
> end-of-shift, although there are some AS's that truly do anchor the
> extremities of that scale. (Arguably, a trivial example of a
> "100% guilty ASN" is one that has been hijacked, for example.)
>
> Regards,
>
> Joe
>
>
>
>




<<< Chronological Index >>>    <<< Thread Index >>>

Privacy Policy | Terms of Service | Cookies Policy