CD Encryption Directive: Practical Implementation Challenges

Transcription

1 CD Encryption Directive: Practical Implementation Challenges Dr William Saywell MA, BM, BCh (Oxon), Dip Med Inf(RCS Ed), FRCR Consultant Radiologist and CfH Clinical Lead

2 David Nicholson s letter (Extract 1) September 2008 Dear Chief Executive DATA SECURITY Further to my letter of 20 May 2008 I am writing to ask you to conduct a review to ensure that your organisation has fully implemented the policy that all removable data must be encrypted. I would also like to draw your attention to the report of the Cabinet Office Data Handling Review that was published on 30 June 2008, which contains mandatory security standards for the public sector. A second report, the Thomas/Walport Data Sharing Review, is also relevant and whilst the government response to the recommendations in this report has not yet been finalised, it is likely that all will be accepted. PACS encryption The encryption mandate applies equally to PACS images whether on CD or back-up tapes. There could be occasional exceptions on patient safety grounds such as a severely ill patient being transferred to another hospital where the time to encrypt could cause a danger to the patient and a risk assessment will need to be made.

3 David Nicholson s letter (Extract 2) How not to do it? At present, it is typically a three or four step process to encrypt images onto a CD from a PACS system: 1. PACS burns an unencrypted CD which is then loaded into a PC. 2. SafeBoot(the centrally procured software) encrypts the files on the PC. 3. The PC burns a new CD with the encrypted files. The unencrypted CD should then be destroyed in line with the guidance at Annex A PACS viewer can be incorporated with the CD to enable the image to be opened on any PC information regarding this will be made available to trusts shortly. The CD and the password MUST be transferred by different routes. If compression is used to reduce the size of a PACS image, it must be Lossless compression, otherwise image quality may be affected (some applications combine encryption and compression which may have created the myth about encryption). It may be that other, locally procured software is being used but you will wish to check that all trusts are using encryption appropriately. NHS CFH is working with PACS suppliers and McAfee to make changes to PACS systems to enable encrypted CDs to be burned directly from the PACS systems. In addition, following a successful pilot, it is intended to rollout a nationally scaled solution for bulk secure file transfer by January This will allow any file between 20MB and 1GB to be transferred securely across N3 (smaller files can be transferred via NHSmail).

4 And at the other end? Viewing by clinicians is quite easy but what about import to PACS? GE PACS If you decrypt the CD on the RA600 workstation the viewer opens. Whilst this is still open, browse to C:\NHS_CfH_DICOM_Images\ Find the DICOMDAT folder (if a GE CD) or the variably-named folder containing the DICOM files (if a SectraCD) and copy to the PACS import folder. SectraPACS Decrypt the CD and with the viewer open navigate as above. Copy the files to another (3 rd!) CD and insert in Sectraworkstation's CD drive (D:)

5 What about Passwords? From the CfH PACS FAQs: 12. What happens if the password for the CD is lost? The creator of an encrypted CD will need to implement processes and procedures to ensure that the password can be recovered. These should address such issues as ensuring that: The passwords are stored securely and backed-up appropriately. The passwords are retained as long as they are needed. Requests for passwords are sufficiently authenticated to be legitimate. Requests for passwords can be serviced in an appropriately timely fashion.

6 Alternatives to CDs DICOM communications PACS Exchange (London) 3rd party solutions (egbb Rad) SFTP PACS Webview (especially if facilitated by the PACS Portal) Future developments GE Broadview XDSi Etc However, few of these are currently useable outside the N3 environment.

7 Alternatives to Encryption The guidance has been relaxed a little, subject to Trust risk assessment. Unencrypted by hand of patient Unencrypted by Secure Courier subject to: the risks being understood, accepted and owned by the trust board; the number of patients involved is no more than four in the case of each transfer; and the media is tracked in transfer with robust signatory processes for despatchand delivery. Expensive, and still an administrative overhead for Tracking matching despatches against confirmed receipt. To and from Independent Sector excluded Unencrypted where patient safety might be compromised.

8 How best to do it? What is required? Sender From PACS workstation (or perhaps a connected PC). Minimal extra user input Easy procedure for non-technical admin staff Password management built in Doesn t need extra consumables (CDR or CDRW)

9 How best to do it? What is required? Recipient Access to help on the CD Technical instructions How to obtain missing password Security no files retained on hard drive Clinical Users Ease of viewing will it pass the orthopodtest? PACS Administrators Ease of importing to PACS Retain flexibility

10 Options for CD encryption PACS Vendor solution EgGE Ultima( 20k) 3 rd Party Vendor Several have posted on the forum Probably cheaper than PACS vendor, but still costly McAfee/Safeboot Free of charge (apart from extra consumables), but time-consuming. Or...

11 DIY solutions Using freeware applications for scripting, encrypting and burning Pro: Free Con: needs sad old geek to compile it! DOI I am that SOG! Those here earlier will have seen my solution demonstrated at lunchtime. Currently it works on GE and SectraPACS (and nearly ready for E-Film stand-alone burner). Agfa????? Certainly not at present but I d be happy to try.

12 Features

13 Passwords An essential element of encryption Public/Private key systems are an alternative NHSIA once had a plan for key escrow, but it never got off the drawing board Need to consider Strength Management

14 Password Strength There are extant NHS guidelines s/nsts/security/batch/ Password.rtf

15 NSTSPassword/phrase guidelines for batch encryption to AES 256 bit strength While it has been reported that it might be necessary to use a password/phrase as long as 64 characters to take full advantage of AES 256-bit encryption, we recommend that a passphrase of no less that 12 characters is used for encryption of NSTS batch trace files. This achieves a good compromise between security and usability. For optimal effect, a password/phrase should therefore: Be at least twelve characters long; Contain a mix of alphabetic, numeric and special characters (such as ; - <? #); not use an alphabetic or numeric series, either backwards or forwards (i.e. ABCDEFG, GFEDCBA, ABCABCABC or , ); not use a string of identical letters or numbers (i.e. AAAAAAA or ); not use a common keyboard shortcut (i.e. ASDFG or QWERTY). A pass-phrase is to be preferred and might be something like: A pseudo phrase such as 5pm_Go_Walking (please don t use this!); A word using the first one or two characters from a sentence plus some added special characters (such as evgo_bode fashort for every good boy deserves favour which some of you may recall from music lessons); A sentence, perhaps with additional characters, selected from a book or newspaper. Passwords/phrases should, of course, be changed regularly and not less frequently than every month. For batch encryption one can use a fresh pass-phrase for each batch, of course. NSTS Service Management Team December 2007

16 Password Strength There are extant NHS guidelines atch/ Password.rtf 7-zip provide an illustration of how length affects decryption time Here is an estimate of the time required for an exhaustive password search attack, when the password is a random sequence of lowercase Latin letters. We suppose that one user can check 10 passwords per second and an organization with a budget of about $1 billion can check 10 billion passwords per second. We also suppose that the processor in use doubles its performance every two years; so, each additional Latin letter of a long password adds about 9 years to an exhaustive key search attack. The result is this estimate of the time to succeed in an attack:

17 Password Length Single User Attack Organization Attack 1 2 s 1 s 2 1 min 1 s 3 30 min 1 s 4 12 hours 1 s 5 14 days 1 s 6 1 year 1 s 7 10 years 1 s 8 19 years 20 s 9 26 years 9 min years 4 hours years 4 days years 4 months years 4 years years 13 years years 22 years years 31 years years 40 years

18 Password Practicalities Strength appropriate to the threat NSA or GCHQ will be able to crack it regardless! Need not be OTT like SFTP site Practical to set Practical to transcribe into DOS text box Cryptography isn t the biggest threat anyway Social engineering Rubber hose cryptography

19 Finally, a Word of Warning! Regulation of Investigatory Powers Act 2000 RIPA Part III Part III of the Regulation of Investigatory Powers Act 2000 (RIPA) came into force on 1 October Key points to note: Part III provides a statutory framework that enables public authorities to ensure that protected or encrypted electronic information which they have obtained lawfully or are likely to obtain lawfully can be put into intelligible form. It is a criminal offence to refuse requests for such disclosure and encryption codes.

20 Unlikely to apply to medical users? Recent case of terrorist bomber who was a doctor. Suspicion fell on colleague (subsequently acquitted). Having encrypted data on the PC, with a lost or forgotten password would not have made the defence case easier! So shred those PCs once they ve been imported to PACS or have been finished with.

21 Any Questions?