Triggerfish, also known as cell-site simulators or digital analyzers, are nothing new: the technology was used in the 1990s to hunt down renowned hacker Kevin Mitnick. By posing as a cell tower, triggerfish trick nearby cell phones into transmitting their serial numbers, phone numbers, and other data to law enforcement. Most previous descriptions of the technology, however, suggested that because of range limitations, triggerfish were only useful for zeroing in on a phone's precise location once cooperative cell providers had given a general location.

This summer, however, the American Civil Liberties Union and Electronic Frontier Foundation sued the Justice Department, seeking documents related to the FBI's cell-phone tracking practices. Since August, they've received a stream of documents—the most recent batch on November 6—that were posted on the Internet last week. In a post on the progressive blog Daily Kos, ACLU spokesperson Rachel Myers drew attention to language in several of those documents implying that triggerfish have broader application than previously believed.

First, I enjoyed DeepSec conference and I am grateful for the invitation to speak there. I love European conferences – and not only for having infinitely (with that being an under-statement of the year) superior coffee during breaks :-)  In particular, I liked the audience for my presentation (slides will be posted here soon) and I think the audience liked my material and myself too :-)

What also impressed me a lot was Ivan Ristic speech, which was the second day keynote. He started by simply stating that ‘security industry has failed’ and that ‘a desktop is lost.’ His proof was in typical numbers like “75% of corporate systems are infected with at least 1 malware piece per system”, “1 million of malware types” and “25,000 unique malware samples a day seen.”  However, he then broadened the subject and talked about how not only “a trusted desktop” is gone, but the entire world of “trust everything [on a system], all the time” is gone (his ideas were similar to what I planned to present in my HITB 2008 presentation about “the 0wned world”)

I also like how he positioned all those “security user prompts” (in Vista and even before) as a proof that security technologies have failed and now we have to rely on the user to make security decisions (which will obviously fail as well since users are now fully conditioned to “see a chunk of technical mumbo-jumbo, then click OK”)

It was also interesting how he connected a lot of security failures to his “#1 reason: all programs run with all privileges of the user that runs them.”  In fact, he illustrated it by reminding the audience that “everybody runs untrusted code every day today [web browser + Javascript, etc] while nobody did this 30 years ago.”  He also beat up blackisting as an approach to security (but then again, everybody does it today :-)) - what was interesting that he opined that “we will spend the next 10 years proving that whitelisting will fail just as we spent previous 10 years proving that blacklisting fail.” His main point was that global “onslaught” of whitelisting and code signing will kill all sorts of useful things AND provide little security.

He then called for everybody to think about solving the hard, possibly non-sexy problems. This is the part where I could have used more details :-)

So, a fun speech (even though my telling of it is a bit jumbled… check out his slides whenever they are posted) – and a fun conference overall. Worth a 12 hour flight :-)

These “take-down” companies are generally specialist offshoots of more general “brand protection” companies, and are hired by banks to handle removal of fake phishing websites.

When we examined our data more carefully we found that we were receiving “feeds” of phishing website URLs from several different sources — and the “take-down” companies that were passing the data to us were not passing the data to each other.

So it often occurs that take-down company A knows about a phishing website targeting a particular bank, but take-down company B is ignorant of its existence. If it is company B that has the contract for removing sites for that bank then, since they don’t know the website exists, they take no action and the site stays up.

Since we were receiving data feeds from both company A and company B, we knew the site existed and we measured its lifetime — which is much extended. In fact, it’s somewhat of a mystery why it is removed at all! Our best guess is that reports made directly to ISPs trigger removal.

The paper contains all the details, and gives all the figures to show that website lifetimes are extended by about 5 days when the take-down company is completely unaware of the site. On other occasions the company learns about the site some time after it is first detected by someone else; and this extends the lifetimes by an average of 2 days.

Since extended lifetimes equate to more unsuspecting visitors handing over their credentials and having their bank accounts cleaned out, these delays can also be expressed in monetary terms. Using the rough and ready model we developed last year, we estimate that an extra $326 million per annum is currently being put at risk by the lack of data sharing. This figure is from our analysis of just two companies’ feeds, and there are several more such companies in this business.

Not surprisingly, our paper suggests that the take-down companies should be sharing their data, so that when they learn about websites attacking banks they don’t have contracts with, they pass the details on to another company who can start to get the site removed.

We analyse the incentives to make this change (and the incentives the companies have not to do so) and contrast the current arrangements with the anti-virus/malware industry — where sample suspect code has been shared since the early 1990s.

In particular, we note that it is the banks who would benefit most from data sharing — and since they are paying the bills, we think that they may well be in a position to force through changes in policy. To best protect the public, we must hope that this happens soon.

On 13 August, jcorey asked about how to deal with those who firmly believe that the only answer to any security problem is to inspect everything at the edge. This is an important question, and I wanted to give Joe an answer. (You might have to scroll down when you click the previous link, it seems that linking to individual comments is broken.)

Today, 15 October, I wrote a little thesis as an answer to his question. I’m calling it out in a separate post because I want to make sure those of you with aggregators that don’t update when posts receive new comments still have a chance to reply with your thoughts. I’ll also repost it here:

jcorey-- You've nailed the biggest obstacle to deploying something like direct connect. Many security professionals have been taught that there simply is, and never will be, a process or technology that allows you to trust anything that originates from outside your corpnet. These professionals cling to this belief, and have been the cause that allowed the whole “detection” market to bloom.

Let me be clear: this total lack of trustworthiness is no longer absolutely true. Of course there will be times when unknown machines will be used by known and unknown people to access your information. But what about one particular subset -- known humans, with known portable computers -- can't we do something better than treat them as toxic invaders?

Indeed we can. And that's what I'm proposing with direct connect. The technology -- managed, of course, with the right processes -- exists so that you can extend the trust to known computers even though you don't trust the network they're connected to. This is because you have mechanisms that:

1. Allow you to configure the machine according to your requirements (domain join, group policy)

2. Dictate computer and user authentication requirements (IPsec policies, smart cards)

3. Limit what the users of these machines can do (UAC, non-admin, Forefront Client Security, Windows Firewall, even software restriction policies)

4. Validate the health of machines initiating incoming connections and remediate if necessary (NAP, System Center Configuration Manager)

5. Limit the threat of attacks against stolen computers (domain logon, smart cards, BitLocker with TPM)

With the robust authentication, validation, configuration, and control mechanisms available to you, I simply don't see that there's any need to fall back to “detection” now. Detection technologies were -- and remain -- necessary for the times when we have no clue about the health of client computers and when we had no way to gauge the intent of the users. But it is truly reflective of a head-in-the-sand mentality to assume that this is a complete description of what's capable today.

You know, someone once asked me what it takes to be a security professional. I answered that there are two primary elements: become a networking/packet wonk, and be willing to change your opinions when the right evidence comes along. Indeed, I suspect that many security folk have forgotten the need to keep their wonikness updated, which in turn makes them resist new ideas regardless of the strength of the evidence. I'm not very proud of what I just wrote, because I loathe generalities, but I'm not sure what else to think here. Sigh.

Joe’s question is important and strikes at the foundation of what it means to be a security professional today. I’m eager to continue this conversation, because it’s reflective of what I sense to be a radical shift in our jobs—we are, or should be, no longer the wolf-crying propeller-head who sits in the basement and twiddles with the firewall. Instead, our job should be defined as one who’s charged with protecting the organization’s information from attack, while maximizing its utility to authorized users, according to the principles of least privilege. Your thoughts?