Several folks have only followed my work in the drone scene, and fail to realize I have about 2 decades of research work under my belt surrounding public vulnerability disclosures in various software and hardware implementations. Drones has just been the latest market vertical that I participate in, and inject my knowledge into. I did find the commentary on my choice to focus on DJI products being primarily as a means to bolster my work at D13 a bit humorous. I honestly took up that line of work specifically to target the misinformation and inaccurate statements surrounding the “is my DJI product spying on me” conversations that began over the past few years.

 I have always been driven by the desire to take things apart, see how they work, and share what I have found with others. It is just in my nature. When potential security issues come into play this natural desire often makes other people uncomfortable. Many would prefer to remain ignorant to certain issues. Vendors often would rather see their feature functionality pushed, rather than the inadvertent weaknesses that have arisen along the way during software and infrastructure development.

 If you were to look in my office right now you’d see an old pinball machine that I am in the process of restoring, and incrementing my understanding of old solid state gaming machines as I go. The only way to restore an old pinball machine, is of course to take it apart.

I should likely start off this by mumbling something about a threat model, and asking you to produce one that we are using to frame this discussion with. To me threat is often in the eye of the asset beholder, or the person protecting the $thing that you are worried about. In your autonomous car example, the shear mass of a vehicle in and of itself may be one aspect in a calculation of risk.

Now to your software risk question, the function and utility of the specific code in question will come into play with regard to calculating how risky it’s actions, or flaws in them can be. To address the SDLC aspect, regardless of the market vertical I have found that many companies do not value proactivity with regard to addressing potential flaws, often times being reactive is what happens. In other words until there is an issue, there may not be development cycles spent on trying to ensure something can not happen in the first place. In the context of a “drone” or autonomous vehicle, in my humble opinion an end user can be just as risky as autopilot software, since I think that is what you are hinting at. Now the moment an end user makes the decision to rely on an autopilot, or “software feature”, the risk does indeed shift to the quality of the code the person is relying upon.

I try really hard to keep risk framed in the context of specifics, attempting to subjectively inject risk into a generic contrived conversation sans a risk model, and predetermined boundaries doesn’t help anyone out.

Without going into details have you found any exploits on any popular drones that might make the media this year? 

My research into DJI was driven by public concerns, and a combination of what I call “talking heads” making inaccurate statements. These statements come both in the form of PR from DJI themselves, and from “industry experts” that like to conceptualize.  The resulting community that formed around this work was more coincidence than a specific focus.

Most of the actual “exploitation” that I do, I am unfortunately not able to discuss, as it tends to manifest itself in the D13 MESMER product as a “mitigation” feature in the platform.

I usually live tweet my work, and it is often picked up by the press after the fact, if you want to stay in tune with what is hot, follow me on Twitter!

You can read Kevin’s Department 13 white paper on DJI’s Drone ID implementation here.

If you want to see how easy it is to create mayhem with Drone ID check out the code here.