Data handling is a safety-crtical exercise.
I'd therefore like to briefly describe a number of points on this subject to lay out which areas of focus need to be made. These guides should be adapted to local context and applied regardless of data content, despite how benign the data might appear [1]:
Collection
- data collection should be minimised and avoid superfluous, unnecessary datapoints. In particular data pertaining to race, ethniticty, health, sexual persuasion and politics are to be avoided except in certain well-defined cases such as personel records or particular kinds of ethnographic research.
- be aware of the possibilities of cross-referencing the data and the accuracy at which certain data points can be collected, eg: street name vs GPS coördinates
- the data subject must be informed about the collection of any personal details
- be clear for what purposes and usages this data is being collected and stick to those purposes and usages
- the storage of the data must have the necessary, relevant protections in place such as encryption at file system, database and/or field level as necessary
- be aware of the location of the storage and whether this is in-house or in-cloud. Certain jurisdictions take a dim view of data leaving their countries for example
- data in transit should be over secure medium and/or encrypted
- emailing or moving data by physical media is as much transmission of data as is downloading via web browser and the like
- be very, very careful about using email, instant messaging and other common messaging systems. Some systems support security classification and encryption, be sure to know how and when to use those mechanisms. Even internal company email is not secure!
- data deletion should always be made to appropriate standards such as that detailed in the DoD 5220.22-M and AFSSI-5020 standards
- if data is deleted then ensure that certifcates of destruction for the data and any hardware including backups is obtained
- virtual machines, "cloud" and hosted services are always problematic - only use those which have a detailed and sufficient data deletion procedures
- don't forget about email archives, backup devices, "forgotten" memory sticks, cameras etc...
- all data must be assessed for its sensitivity and marked appropriately
- a simple Secret-Confidential-Public-Unclassified system suffices with approriate defined requirements for each level
- further classification such as content marking may also be employed
- ensure that everyone knows what these clasifications mean
- only persons who have a need to view and hold the data are given access
- access control here is primarly a back-office procedure which may have a technical implementation
- auditing a logging of accesses, grants of access and revokations should be made
- a revokation of access must be made as soon as it becomes necessary, eg: someone leaving the company.
- ensure in the above case that any data still held by that person, eg: backups, memory sticks, laptop contents etc is also dealt with
- are you procedures documented sufficiently and in compliance with necessary standards, eg: ISO9000 etc? Even if you don't need to be certified you can still apply good practice!
- when data is extracted from a database ensure that the appropriate security handling, markings and requirements are preserved on the extract. If the database is Secret then so should be all extracts from that data
- extracts should be sanitised - stripped of unnecessary fields - and anonymised/obfuscated as necessary - these processed extracts need to be reclassified!
- a safe environment is one where the above security controls can be enforced, eg: a company's intranet, and even here the movement of data by phsyical means (memory stick etc) or electronic means (emails) must be minimised
- internal email systems are not necessarily secure
- clean desk and locked office policies may be required in some instances
- can an audit trail of access be established?
- outside of the safe environment, eg: in public, on the train or at conference, precautions must be made to ensure the data remains unavailable to non authorised parties through mechansims such as full disk encryption or file encryption
- use of removable media such as memory sticks should be discouraged
- printing of data similar so, especially when it comes to disposal of printed media
- the data and the handler should not be parted unless it is absolutely necessary, for example, packing the laptop into the checked baggage on an aircraft; and even this situation might not be safe in all cases
- a procedure for handling loss of data needs to be defined
- such a procedure needs to establish: the handler, the data set, the media on which the data was stored, the contents, the amount, the time of loss and location. For example, were the company's financial statements for the coming year lost on an unencrypted memory stick on a train late a night versus was an encrypted laptop stolen?
- the necessity to inform authorities (eg: police, data breach announcement) must be established
Note the analogies between handling data and the procedures for handling chemicals in an industrial context or patients in a medical context. Of course, the above guides are just guides and incomplete as we can not foresee every situation and context - local customisation of the implementation of there is always required.
Notes:
[1] The UK's Health and Safety Executive COSHH guidelines on handling water - these might surprise you for a such an "inert" substance, for example: Portable Water and Legionella Control and Hot and Cold Water Systems.
No comments:
Post a Comment