26 April 2009

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

26 July 2008

Welcome to the Zero-Day Defense blog

Welcome to Zero-Day Defense. This blog will be officially launched at DEFCON, so consider this a teaser post.

Unlike most other infosec/ITsec blogs (hereinafter "infosec" rather than "ITsec"), this blog will not focus on news items; this blog is already providing links to the five most recent items from an aggregated feed that I run covering several dozen infosec news blogs.

Instead, this blog will focus on infosec R&D, split roughly between emerging endeavors over the next 1-2 years and 3-5 years. If you want to know how Worf thwarts nanobots, read Kurzweil's stuff; this blog is focused on practical apps.

Volume will be relatively low (1-2 items each week) and each post will be relatively brief (about 200-300 words), usually an original article summary with a bottom line recommendation.

Sample topics:
  • PEI framework for collaborative computing
  • Securing a desktop data grid
  • Trust-by-wire in IP networks
  • WLAN steganography
  • Behavioral modeling of ideologically-motivated snowball attacks
Sample sources:
  • ACM Transactions on Information and System Security
  • Computers & Security
  • Journal of Parallel and Distributed Computing
  • International Conference on Availability, Reliability and Security (ARES), Proceedings of the
  • IEEE International Symposium on Applied Machine Intelligence and Informatics (SAMI), Proceedings of the
Sample affiliations:
  • IBM Thomas J. Watson Research Center
  • Sandia National Laboratories
  • Thomson R&D, Security Laboratory
  • Philips Research Europe, Information & System Security Group
  • Fraunhofer IESE (Institut Experimentelles Software Engineering)

Once again, welcome to Zero-Day Defense.

- David Scott Lewis