I have often been brought in to oversee the de-commissioning of deprecated hardware. Often said hardware isn’t that old and the organization wishes to either repurpose it elsewhere – often in a different area of the business (and in an environment of differing risk) or alternatively they may wish to donate the hardware or perhaps even just take it to the e-recyclers safe in the knowledge that they aren’t endangering their corporate security.
You must consider any area within the hardware where data and/or configuration information could potentially be stored. In desktop PCs this might be obvious but in embedded equipment like routers there may not be an obvious means of assuring data destruction.
With SATA (and some late model PATA) and SAS HDDs and SSDs your best bet is to use the drive firmware’s own erasure technique via the ATA_SECURE_ERASE command set. Unfortunately vendor support is somewhat spotty and some motherboard BIOS’s may “freeze” the drive on boot to prevent malware from setting ATA passwords or executing their own erasure command. There are ways around this, of course and Google is likely your friend.
Users of old HDDs will be forced to do a block level erase. Perhaps the simplest way of doing this is to use dd to pump /dev/zero into the disk until it is full. The truly paranoid will perhaps do multiple iterations, perhaps using the Gutmann method of writing differing patterns to reduce the risk of forensic recovery using techniques like magnetic force microscopy. Writing just a single pass of zeroes may not be enough. That said, at least at data densities common in disks used in the past decade, it is generally sufficient to do two passes – first with pseudorandom data, and the second with zeroes.
The unfortunate thing about block level tools is that – no matter how thorough they are and how many passes they make – there will likely be data left behind, and not just in known hiding places like the DCO. Modern disks will remap suspect physical blocks transparently, hence the need for tools that query the firmware via SMART to determine drive health. Only when this process fails to preemptively remap (or where there is no drive administrative space available anymore for remapping) and a block is encountered that can’t be read will the OS end up knowing about it. Thus the administrative area of the drive could contain (admittedly small chunks) privileged information. SSDs are even worse with their wear leveling.
Essentially it all depends on who your adversary is and how far you wish to take it. I try and repurpose hard drives where circumstances allow but there are some times where threat model will simply not allow any risk – no matter how intangible.
Where this is the case I advocate incineration above the Curie point. Degaussing with all but the most powerful units will require removing the platters from the metal enclosure. Unfortunately when using a degausser on HDDs there is no way to field verify erasure has taken place. Remember that even corrupting a few bytes of the drive firmware will cause the drive to “fail” but the data may still be recoverable by a well funded adversary. Incineration solves these issues and results in a drive that is uh, visually confirmable as being cactus.