Hi everyone.
Given the various questions and directions we've been exploring
through the list here and on the calls, I thought I'd try to help
focus things in a bit as things get chewed on over the next few
weeks. A lot of people have been asking great questions about scope
of the issues, how things can be addressed in a variety of ways, and
why the ICANN community is looking at this issue at all. When the
conversation last week postulated that the APWG should be taking care
of this issue, I thought that's the sign that we've come full circle
on this and need to take a deep breath! We seem to be trying to solve
the entire spectrum of online fraud and e-crime issues with our little
group now - there's certainly no need for that, there are plenty of
other groups, companies, governments and people that are working on
these broader issues. Many of us in the working group here are
members of half a dozen or more other independent efforts, and we all
run into the same issues from time to time, where the problem seems
simply overwhelming, as we're the type of people who like to take on
and solve problems and there's just so much to do!
Anyways, I think we're struggling with definitions, solutions,
policies, ideas, etc. that are well beyond what is needed here. The
APWG and many, many other organizations are all doing lots of great
work on attacking the on-line e-crime problem through lots of the ways
brought up on this list (spam control, multi-factor authentication,
user education, black lists, more secure code, and on and on). We're
talking about major government and industry collaborative efforts, not
to mention the hundreds of millions of dollars in "security" services
and products sold annually to address all these issues. So in
general, the problems with on-line fraud/crime are being addressed by
multiple efforts, and we are getting better at it (though it doesn't
seem like it all the time!)
So what's the problem with "flux" and why are we coming to ICANN to
try to help us solve it? Quite simply it is THE most effective
technique for keeping fraudulent sites active on the Internet for the
longest period of time, and it requires a domain registration as it's
primary component for success. The anti-fraud/spam/crime/phishing/
(whatever) industry has gotten pretty good at getting people and
providers to deal with sites on compromised servers or that use fake
user accounts - both after getting a report in, and in preventing them
in the first place. Note that the institutions being attacked are
spending millions on site mitigation efforts, and the ISPs/hosts are
doing the same when it comes to intrusion detection, spam prevention,
anti-virus, and other vectors that lead to these types of malicious
sites. We still have lots to do, but those kinds of issues are
getting dealt with relatively quickly these days. However, what has
consistently proven more difficult to mitigate are sites using
fraudulently registered domain names supported by networks of
compromised computers (bots) that flux from place to place either
automatically on a pre-planned schedule, or in response to a bot being
removed. We can mitigate bots all day long, but without killing (or
preventing) the fraudulent domain, the malicious sites live on and
on. We're seeing more criminal groups using these techniques, and one
that has even targeted a major member of the registrar community with
such an attack. So this is becoming a more important e-crime issue
that is also affecting members of the ICANN community directly as well.
So what kind of difference are we talking - flux vs. "standard" fraud
content hosting? That's a key question for why this does or does not
deserve special attention. Well a very typical answer you will see in
the security community is that a "flux" domain attack lasts about
twice to SIX times longer than any other kind of phishing site.
Here's a reference to an excellent paper on this by Tyler Moore and
Richard Clayton of Cambridge from last year on the topic of phishing
site uptimes that breaks this out based on hard data:
http://www.cl.cam.ac.uk/~rnc1/ecrime07.pdf
So these flux techniques keep a site up at least twice as long, much
longer on many occasions. That's a problem. But what does that mean
for monetary/social/other impact? Well, let's stick with just a
"hard" data example to give some financial impacts, as they are
actually measurable - other stuff, while perhaps much more important,
is harder to measure and leads the observer to interpret the way they
want to. Here's some results of a study just done by a major US Bank
on "losses per hour" due to phishing site exposure. Note these are
very conservative estimates as they are bottom-line MEASURED loss
impacts and don't factor in unseen losses through untracked channels
or impact of ID theft on the customer:
Cost of stolen bank access credential (on-line account access/debit
card/etc.): $400
Credentials stolen per hour: .75 (two every three hours)
Hourly cost = $300
Impact holds throughout the first 72 hours of site uptime.
Typical phishing site median uptime - 9 hours = $2700
FLUX type attack median uptime - 22 hours = $6600
FLUX "profit margin" = $3900 per site (domain).
And that's just for phishing. Other fraud types may not net as much
pure profit per site, but for pharma and botnets for instance, there
are a heck of a lot more sites (an order of magnitude or two the data
will show).
How many flux sites? Well we're still gathering data, but a very
solid report from RSA we've gotten in shows for PHISHING type flux
attacks, we're looking at over 1200 per month over the first six
months of 2008. That would extrapolate the "profit" of phishing using
flux to nearly $5 million per month = $60MM/year.
Those are supportable hard dollar figures that can be seen as a FLOOR
for losses. Note that the bank numbers in that study are for attacks
that don't include ROCK phish attacks (a flux technique) that
typically net far higher loss numbers per site (domain). For example,
one institution targeted by ROCK for 6 months had a lot more losses
just itself than the annual figure mentioned above - all directly
traced to those ROCK attacks.
Personally, I believe the number of flux domains for phishing are
likely about 2-3 times greater, and the impacts much higher to the
Internet community because of ID theft and other losses incurred by
individuals. So soft dollars, we're talking much more, and again,
that's just phishing alone.
OK, so we've got a $60MM problem that's supportable with measured
numbers, that is in reality quite a bit larger for phishing alone, and
a heck of a lot bigger when all forms of online fraud are figured in.
And remember, this is attributing it solely to the property of FLUX
attacks being more effective than other attacks, not the fact that
attacks are occurring.
So that brings us back to the original questions of why we are
addressing FLUX within the ICANN community? First, it's because the
technique is doing significantly more harm than others in the on-line
crime space. Second it requires the actions of the domain
registration community to effectively mitigate through quick
mitigation or prevention. The uptime numbers show this second point
empirically, and the experience of the first-responders is fairly
universal in support of the notion that it is more difficult to
mitigate a flux attack because *in general* the domain registration
community is less responsive/proactive than the ISP and hosting
communities that are affected by other types of e-crime attacks.
We've been working on this FLUX problem in the anti-e-crime community
for over two years now, and things aren't getting a lot better
attacking it one registrar/registry/rsp at a time, so we hope that a
centralized effort can make a real difference.
So perhaps a realistic "goal" metric would be to try to get FLUX
attacks to be no worse than other types of online crime events in
impact and/or lifetime, and a stretch goal would be to nearly
eliminate them.
Anyway, there you go, some thoughts on why we're here and trying to
keep focused. There are people and institutions (including many ICANN
constituency members) around the world being harmed quite
significantly because of this e-crime methodology, and we are in a
position to potentially do something about it.
Thanks for your contributions!
Rod Rasmussen
Co-Chair, Internet Policy Committee, APWG
No virus found in this incoming message.
Checked by AVG - http://www.avg.com Version: 8.0.138 / Virus
Database: 270.6.3/1612 - Release Date: 8/14/2008 6:03 PM