How to secure your security research? Six tips.

As a security-researcher, you might just be itching to investigate the security of a product. That doesn’t come without risk: you can get into trouble with companies and possibly even with the public prosecutor, especially when the stakes are high. How do you do security research while minimising the legal risks? Some tips.

(These tips concern the (semi-)offline hacking of hardware, so not the remote research of online systems. The latter activity carries specific risks, which deserve a separate discussion.)

Tip 1 – Document your research well

A core concept in all these tips is the idea that you’ve got a stronger defence if you can show that you’veĀ  done serious, relevant research. It helps if you describe every step of your research: the preparation, the acquisition, the research, the communication with the producer and the publication. Describe this preferably in a way that others can also understand it.

Tip 2 – Buy the product second-hand

Products are sometimes sold under the condition that it is prohibited to investigate their internal working. If you reverse engineer such a product, you might breach the general terms and conditions. Where possible, it is better to buy a product at places like eBay, in order to be able to state more easily that the terms and conditions do not apply to you. Otherwise, you can have a friend buy the product for you and have the friend sell it to you.

Tip 3 – Demonstrate the public interest of your research

Attempt to clarify beforehand why your research is in the public interest and document this. This is useful if you get questions from the media: it allows you to show with which intentions you’re doing this research. It might also be useful in a possible court case.

The reasoning regarding the public interest may differ: sometimes, a product is used often and a vulnerability may expose a lot of users, sometimes research will enable legitimate use which is prohibited by security measures, sometimes the research is intended to enable interoperability, etc. On the other side: if a vulnerability is already discovered and your research only replicates this, it is less easy to defend your research as being in the public interest.

If your research allows this, it is also a good idea to describe the research design before you start. This way you can make clear you’re serious.

Tip 4 – Formulate a policy for handling private data

It cannot be excluded that you collect data about private persons in the course of your research (although the chances are limited if you only focus on products). It is a good idea to already think about how to deal with these data and take measures to restrict the collection and analysis of these data to the minimum necessary. Ask yourself: how much data do you need to demonstrate that something is broken? You don’t need to collect the rest. Also ensure that the data you collect are deleted after having done the research.

Tip 5 – Allow the producer time to patch the vulnerabilities

Usually, you will want to publish interesting research results. Immediate publication might, however, be unlawful. It is in most cases important to allow producers to patch their products, so as to avoid damage as much as possible. Also, it is a good idea to discuss the moment of publication with the producer. A producer should of course not abuse this by blocking publication of your research, so set clear and fair deadlines.

Tip 6 – Publish your results on relevant media

The next question is: where do you publish your research? In order to demonstrate that publication is in the public interest, it helps to publish them in a generally accepted forum – scientific magazines or relevant blogs, and possible even a responsible disclosure mailinglist. It also helps if you can combine your publication with attention from the media: apparently your research is ‘news’, so it is relevant.

In doing so, decide consciously how much information you will publish and restrict yourself to what is strictly necessary. The copying of code which you derived by reverse engineering may for example be unlawful. This requires careful deliberation per case.

Every research is different and the rules are complex. It is therefore good to ask for advice when in doubt. Questions? Please contact Ot van Daalen, 06 5438 6680, ot.vandaalen@digitaldefence.net.