Why Hackers (Should) Love Academic Research

Welcome back! I was a featured speaker at the China IT Security Forum held last week in Shanghai. My talk, as listed on their program schedule, was on "Zero-Day Desktop Defense," although it was really on zero-day PERSONAL defense. In other words, it wasn't limited to desktops. OTOH, I just glossed over ubiq/pervasive devices, spending no more than a few minutes on mobile platforms. Hence, I guess my talk was really on zero-day desktop AND laptop defense. (Yes, this would have been a more accurate title.)

What's not noted on the program schedule linked above is that I was also on the enterprise security panel that followed my talk. During the intro, since everyone had already heard me talk for the past hour, I simply mentioned that my comments during the panel session would be focused on zero-day OFFENSE rather than defense, taking a hacker's worldview of things.

My panel comments covered the underground world of hacker forums -- a world not frequented not just by most CIOs, but even most CSOs. This is where hackers come to life, where CSOs can get a good idea of what might be coming next. I also mentioned the vulnerability of SMEs (small and medium enterprises). Let's face it, the "IT guy" in many smaller companies is responsible for fixing Windows (and Windows-related) bugs, and making sure a user can get access to the Internet and their company print server. Not a lot of emphasis on ITsec in SMEs, especially those that have less than 50 employees. This, of course, plays into the necessity of personal defense even within a corporate setting. But my most useful comment, a comment that I really haven't seen made in print, is that the most fertile ground for cultivating new exploits are academic papers and reports. Let me explain.

Each academic paper has essentially three parts, with the first and last parts the most important to hackers. The first part is the juiciest. The first part explains which vulnerabilities are addressed. In essence, every scholarly paper starts off by noting vulnerabilities, vulnerabilities that could be exploited by hackers. This is key. Some smart guys (or gals) say, "Hey, here is a vulnerability!" They then follow with the second and longest part of their paper, i.e., their proposed solution(s). What they've really said is that there is a vulnerability that hasn't been addressed and that they're addressing it. Yet, since nobody is using their proposed solution(s), after all, they're too new, the takeway for hackers are vulnerabilities that can be exploited. Furthermore, by reviewing the proposed solution(s), hackers can get a good sense of how difficult it might be to create an effective exploit. The conclusion section may contain some juicy nuggets, too. Since researchers are producing what in reality are progress reports, often for the point of seeking additional funding, other vulnerabilities and issues that (still) need to be addressed are usually noted.

So here's the sequence:

• A vulnerability is stated. And sometimes it's not just "a" vulnerability, but vulnerabilities. Fodder for hackers.
• A solution is proposed. But, in fact, nobody uses this solution since it's still in an academic peer review phase.
• The conclusion notes other issues that remain to be addressed, thereby noting the vulnerability/ies that still exist, even if the proposed solution is implemented!

This is incredibly useful information for lone hackers, organized crime and intelligence agencies, although it's the kind of stuff that should give CSOs heartburn, keep them up at night.

As I eventually getting around to regular posting on this blog (sorry, my "day" job has kept me extremely busy these past several months), I'll continue on my original mission of producing original article summaries culled from scholarly research. And my three sections:

1. Vulnerability/ies Addressed
2. Proposed Solution(s)
3. Bottom Line

I have to admit that I'm having almost no luck whatsoever in getting my hands on reprints or preprints. I've sent a couple of dozen requests; no favorable responses to date. However, when I did this for papers on AI, for example, I had a 90% response rate. Also, the idea of paying $15-50 for a single paper doesn't thrill me, especially since I'm not really sure of the paper's research quality until I read it. (I can make a guesstimate, but that's all I can do with a recently published paper. And my desire is to focus on newly published papers rather than on research that makes a "Top 25" list over a 3 year period via impact or immediacy factors, or number of times purchased.) Access to digital libraries helps, but is hardly a perfect solution, maybe not even a good solution. Anyway, I'll have to work this out. In a worst case scenario, I'll publish once or twice a month. This is hardly optimal, but better than nothing. And it might fit my lifestyle a bit better, too.

- David Scott "Lightman" Lewis