Last updated: 
1 day 18 hours ago
Blog Manager
One of Jisc’s activities is to monitor and, where possible, influence regulatory developments that affect us and our customer universities, colleges and schools as operators of large computer networks. Since Janet and its customer networks are classified by Ofcom as private networks, postings here are likely to concentrate on the regulation of those networks. Postings here are, to the best of our knowledge, accurate on the date they are made, but may well become out of date or unreliable at unpredictable times thereafter. Before taking action that may have legal consequences, you should talk to your own lawyers. NEW: To help navigate the many posts on the General Data Protection Regulation, I've classified them as most relevant to developing a GDPR compliance process, GDPR's effect on specific topics, or how the GDPR is being developed. Or you can just use my free GDPR project plan.

Group administrators:

Analysing Malware lawfully

Wednesday, October 17, 2012 - 13:22

Malicious software, generally shortened to malware, is involved in a wide variety of security incidents, from botnets and phishing to industrial sabotage. Analysing what malware does and how it can be detected, neutralised and removed from infected computers is an important part of keeping networks and computers secure.

However there are many millions of different items of malware. Many are variants of a single program, others form families apparently derived from or inspired by each other, some may be unique. Teams analysing malware therefore need to be able to work together both to avoid repeating analysis of a sample or family that has already been done, and to allow specialists in particular areas to combine their skills on particularly complex samples. Malware repositories, where samples can be submitted and kept securely for collaborative analysis and documentation, are increasingly important. A common model is for any member of the public to be able to submit a malware sample to a repository but only analysts trusted not to misuse samples or information are given access to read and analyse the submissions.

Malware is also regulated by criminal law. For example the Council of Europe Convention on Cybercrime requires that states regulate the

production, sale, procurement for use, import, distribution or otherwise making available of ... a device, including a computer program, designed or adapted primarily for the purpose of committing any of the offences ...

as well as the possession or use of such programs. Fortunately for malware analysts and all those who benefit from their work the Treaty and most laws in this area allow circumstances when production, possession, supply and use will be lawful. Malware repositories involve both the possession and supply (to analysts) of malware; the analysis process may well involve using malware against test systems and creating malware samples to check defences. It’s therefore important that laws designed to discourage and punish criminal uses of malware also recognise and allow the vital work of defending computers, networks and users against it.

The EU is currently discussing a proposed Directive on Attacks Against Information Systems which includes provisions on malicious software. Article 7 of the Commission’s draft has similar wording to the Cybercrime Treaty:

Member States shall take the necessary measure to ensure that the production, sale, procurement for use, import, possession, distribution or otherwise making available of the following is punishable as a criminal offence when committed intentionally and without right for the purpose of committing any of the offences referred to in Articles 3 to 6

Well-run malware analysis and repositories should fit comfortably within that, as their activities are definitely not “for the purpose of” committing the defined offences. Indeed the European Parliament’s committee scrutinising the proposal explicitly recognised the problem:

Given the possibility to use programmes in dual forms, i.e. for legal as well as criminal purposes, the possession of a tool should as such not be punishable. In addition, the purpose of the actions described in this article should only be punishable when it is clearly aimed at committing an offence.

and proposed amending Article 7 to remove possession entirely and require “clear purpose” to commit an offence. This draft legislation seems to be heading in the right direction.

The UK amended its Computer Misuse Act in 2006 in a less satisfactory way. The new Section 3A of that Act has different requirements for making, supplying and obtaining to each be a crime:

  • For making a software program, s3A(1) requires the person to “intend” to commit an offence;
  • For obtaining a program, s3A(3) requires them to have “a view to” commit an offence;
  • But for supplying a program, s3A(2) only requires that they “believe that it is likely” that it will be used to commit an offence.

[mere possession of malware is not an offence; under s3 of the Act testing it will not be an offence so long as a the tester is authorised by the owner of the system (preferably, the tester will be the owner of the system) and takes appropriate measures to prevent the test infection spreading]

Guidance to prosecutors published by the Crown Prosecution Service recognises that there may be both good and bad reasons for having the same software, and gives a number of factors that may indicate the intention (relevant to the acts of “making” and “obtaining”) of an organisation when deciding whether or not to prosecute. 

Robust and up to date contracts, terms and conditions or acceptable use policies...

and awareness of the law are good signs that responsible malware repositories should already have. However “supplying”, which a malware repository does each time an analyst downloads a sample, needs a bit more thought, as here the test is not the supplier’s intention but whether recipients are “likely” to use the sample to commit an offence. It would seem hard to argue that an open repository that let anyone download samples was not “likely to be used” to commit offences, but restricting access to trusted analysts should be enough to change that to “unlikely”. The CPS guidance confirms that prosecutors should consider

what, if any, thought the suspect gave to who would use it; whether for example the article was circulated to a closed and vetted list of IT security professionals or was posted openly.

Written policies and records on granting access to the repository are likely to be valuable evidence of appropriate care being taken.

Thanks to CIRCL for asking an interesting question.