This also only works "in theory". The list of drives with hopelessly broken "SATA secure erase" implementations is a long one.

There is commercial software available and certified by the government for destruction of sensitive data and "confidential" classified data.

The use of free software is not an approved method of data destruction for bulk personal data in the UK, and its use could technically lead to legal problems. In practice, if it was used correctly, then no one would ever know.

The problem is that the legal onus is on the person in possession of the data to provide documentary proof that the data has been destroyed in an approved manner. If you can't provide proof of the use of an authorized method and validation of success, then you could be prosecuted. For this reason, normal practice is to hire an independent contractor who will provide a certificate stating the method used.

In a previous case where a certifed contractor was hired to destroy the data, but sold theequipment on ebay, the NHS hospital was fined, not the contractor. The reason given by the information commissioner's office, was that the NHS staff should have supervised the contractor and independently verified the destruction.

It was left for the NHS hospital to sue the contractor for breach of contract.

but leap microseconds?

Actually, I think that might be a good idea. There's likely to be money in rewriting time stacks to cope with 1000001 microsecond seconds.

This type of scanning key cutting machine has been around for ages - the storing of the key bitting is new.

In general, this type of machine designed for public use, is only loaded with blanks for "unrestricted" keys.

"Do not duplicate" keys are not protected by just being labelled, they are physically a different shape (often with patented curves and bends), and genuine blanks can only be bought by registered locksmiths who have signed an agreement with the manufacturer not to duplicate keys without proof that the customer is authorised to duplicate that key.

Manufacturers do cut off supply to locksmiths that engage in unauthorized duplication (if they find out). Similarly, the manufacturers will use patent laws to block sale of 3rd party key blanks.

You can still get unauthorized copies made, but it's more difficult. The higher end manufacturers part-key the key blanks to a locksmith's unique code (using difficult to copy modifications - e.g. holes drilled to a specific depth along the length of the key, or curves engraved on the side of the key); a locksmith can only obtain blanks to duplicate keys that he himself sold, making it much easier to trace unauthorized duplication.

Could this be the first case of public key encryption getting broken?

The problem with implantable devices is that they are severely power constrained, as typically a battery life of less than 5 years is considered unacceptable, with 10 years wanted for something like a cardiac pacemaker.

This leaves very little power for CPU/communications/encryption functions. Any kind of crypto hardware, or any kind of unnecessary complexity in the firmware (e.g. duplicated bound checking, etc.) is likely to increase energy consumption and shorten battery life.

This is becoming less of a problem with modern silicon which is more power efficient, and the use of NFC and induction coils can support the energy required for communication; so there is less excuse for including some form of well designed security on the device.

I have managed to reboot an implanted nerve stimulator once, by scanning the patient it was implanted in, in a top-end 3 Tesla MRI scanner. Interestingly, everything other than program code, was stored in RAM, rather than flash (including stuff like serial numbers, electronically readable model number!!, as well as treatment parameters). After the device rebooted all these settings were lost. The manufacturer had anticipated this, and the MRI instructions for the device, specifically said that these must be read-out of the device and a hard copy made, with instructions to how reprogram the device if it did reboot.

There are different constrants with non-implanted devices (e.g. laboratory equipment, scanners, servers, etc.) Traditionally, all the specifications for these devices were made at the time when they would be connected a clean, isolated network. As a result, security has been a very, very late arrival to these specifications. TLS support was ratified into the DICOM specification a few years ago (storage and transmission of X-ray/CT/MRI,etc) - but I've never come across a DICOM TLS installation in the field. So little installed software supports it, and the replacement cycle is so long (many hospitals are signing 10 year contracts for a particular version of the software) that it is, at present, completely useless. Even basic level network security is made difficult by certain aspects of the protocol - e.g. DICOM network connections cannot traverse NAT (due to a classic-FTP-like protocol for initiating file transfers, and due to the fact that both client and server nodes must be on pre-configured static IPs) and has enough tricks up its sleeve that it will catch out unwary net admins when they try and configure firewall permissions, or unwary sysadmins who try and set up clustered servers

This adds a number of significant additional risks:
It adds a delay.
It adds the risk that the human will mix records, or will fail to do the job without reporting back.
It generates confidential waste that needs to be managed.

I work a specialist hospital, which gets patients from over a wide region, including neighbouring states. The normal way of transferring X-ray/MRI/CT records is by file transfer from one hospital's server to the other. However, for hospitals which are not common "feeders", which haven't gone to the expense of setting up the particular VPN connections required to connect into our site, a different approach was required.

So, when a patient is transferred to have their brain haemorrhage removed, the scanning hospital must first prepare a CD (using a proprietary encryption tool, to meet local regulations regarding confidentiality - a standard encryption format (including public key encryption to simplify key management) for medical image files has finally been introduced in the 2013 update to the specification, but is useless due to zero support in existing devices, and a typical device replacement period of 8-15 years), the CD has to be labelled, sent with the patient, taken to an admin office, the password has to be obtained by phone call, the proprietary encryption decrypted, the clear files burned to a new CD, and the clear CD loaded into the server (which has a specification conforming medical device is not permitted to load files except from a specification-conforming medium - i.e. an unencrypted CD or single layer DVD-R (with the files recorded in clear in a specific directory structure).

This adds substantial time, and frequently goes wrong. I've had blank (unrecorded CDs) sent with patients; CDs for the wrong patient; CDs labelled correcly, but with some other patient's images on; Some where the password has been lost, and a new disc has to be burned and couriered over; I've had episodes where the technologist on a 3 am, doesn't know how to burn a CD, or doesn't know how to the work the new proprietary encryption package that they're now seeing for the first time; we've had problems with permissions, where the technologist on-call cannot burn a clear CD, because their group policy has blocked CD burning under their user profile, etc. I'm aware of a number of cases, where patient's have gone for emergency brain surgery, where the only scan the surgeon has to guide the surgery, is a photo of a computer monitor taken with a cameraphone and sent by MMS (let's not even start on the privacy aspects of that).

Of course, with care, this procedure work, and we use it during network downtime (planned and unplanned). Similarly, we have backup plans when out CT scanner can't connect to the regional patient registry to verify identities, etc. However, in audits of data quality problems and data mix-up incidents, pretty much 100% can be traced to the use of a manual intervention.

It depends. A/V software can hook large parts of the OS.

Most commercial A/Vs these days hook into the network stack at the packet-driver level (below the TCP stack), into the keyboard driver (anti keylogger, the hardware driver is hooked, and an encryption routine hooked. When a browser extension, or supported tool detects confidential data such as access to online banking, the encryption hook is enabled, and the key presses are encrypted at hardware driver level, and then decrypted by the browser extension; any keylogger running at anything higher than hardware driver will see only encrypted data).

For kernel bugs, it would likely be possible to hook the calls into the kernel at the appropriate point, and block "suspicious" activity. Similarly, for remote network attacks, an A/V system could simply drop packets known to contain an attack, before they get very far into the networking stack.

This probably won't fix all vulnerabilities, but pro-active A/V companies could certainly reduce the attack surface significantly.

Then, don't forget modern firewalls with deep packet inspection - many are capable of sophisticated protocol or application specific filtering.

Indeed. I have had a 1080p 30fps dash cam with wide-angle lens, sound, GPS, accelerometers, etc. with sophisticated recording management for nearly 18 months.

In the last 12 months, cameras with wifi, android/ios apps, to view and manage video/records/configuration while the camera is still operating (e.g. following a collision, the video of teh incident can be shown to an attending police officer, without the need to switch off the camera and install the memory card in a reader) are now standard fayre - available off the shelf.

Interestingly, this is the opinion that the UK courts had, over a legal case about just what "unlimited downloading" means in a residential broadband contract.

A customer had restrictions put on his account after purchasing what was advertised an "unlimited downloads" ADSL package. However, it turned out that this package actually had a 1 GB/month data cap, after which the connection would be throttled to approximately 32 kbps.

He sued the ISP for mis-selling, but the courts agreed with the ISP, that technically his connection was unlimited, as it had not been cut off completely, merely throttled, and that the 1 GB cap was sufficiently high that it did not need to feature in the advertising material.

Yes, they are well aware of that fact. Their argument was that open source was a security risk, because it would make probing for vulnerabilities easier. And because open source was a risk, the source had to be closed and only shown to persons on a strictly need to know basis.

The problem wasn't so much with virtualized IO. The problem was the way in which the middleware communicated with the *client* software on the workstation. It did some horrible hackery where it loaded the other apps DLLs and directly called various interfaces exposed by the DLLs in the software to send messages. No RPCs or pipes in this software (which says something about the quality of the middleware).

No one could find a way of doing that unless the client software ran in the same VM as the middleware. This would have been an option, but these workstations did *nothing* else apart from run these half-dozen apps.

It was decided that it was better to just run XP on the bare metal, than load win 7 with nothing except VMware, which would then run the fully loaded XP.

The problem is customers. I work at a major hospital and a local consortium is looking to purchase some new medical records software, worth about $10 million.

We've been drafting the new contract for tender, and line 1 of the tender instructions is "The software will run on Windows Server 2008 R2 or Windows Server 2012 64-bit on the servers, and on Windows XP, 7 and 8 32-bit and 64-bit on the client side". I protested at this, but was told by the technical chair, that this term was not negotiable as it was a critical part of the spec; they simply did not have the in-house experience to manage a *nix system.

Later on, there was another line in the tender instructions. "The distribution of the source code of the product must be strictly controlled with appropriate audit trails for persons who have seen it, includes the source code of any 3rd party components used within the product". Again, I protested about this, but the chair of information governance and security said, that this term was non-negotiable due to the large volume and the critical nature of the data stored in this system!!

True. However, there may be issues of vendor support. Some business apps are, and this includes specialist medical apps, mission critical, or at least sufficiently important that business may be compromised in the event of failure.

I know one hospital that recently upgraded their hardware. However, some of the middleware needed to make their various medical records applications work together, was only supported by the vendor on XP SP1. There were several problems:
1. The critical nature of this middleware, and the fact that the vendor would not support windows 7 (or even XP SP3) with their version of the software.
2. The complex interaction of this middleware with so many other apps meant that they could not run the middleware in VM as it would not connect to the other apps via OLE/COM or whatever non-networkable protocol it used.
3. The prohibitive cost of sourcing an updated version of what was effectively a custom built solution, and the fact that the original vendor had been bought-out by a new company who were desperate to kill the original product, but were tied into a 10 year support contract. So, although they were contracted to provide 10 years of support, they were only going to support the original config.

The result was that when the original hardware reached end-of-life and had to be updated late last year, the hospital had shiny new quad-core Xeons with 8 GB ECC RAM, and 15k RPM SAS RAID workstations with 2 GB Quadro cards running XP SP1.