According to the Justice Department, he forged email addresses, invoices, and corporate stamps in order to impersonate a large Asian-based manufacturer with whom the tech firms regularly did business.
Of all the companies in the world, I expected Google to have established some method of identification of their suppliers more secure than email addresses, invoice formats, and corporate stamps. PGP is now 26 years old, and the algorithms it implemented are older yet. It's really really time for businesses to start using those algorithms, if not PGP itself.
I'm envisioning a system where, during the meeting when a contract is signed, the principals exchange public keys, maybe going so far as printing them out as QR codes that are included beneath the signatures on the signature page. It takes a fairly dense QR code to represent 4096 bits with any redundancy, but there is a standard that can accommodate it.. These keys are specific to the contract; no reason to create a One True Corporate key, that if compromised, all is lost. Generating keys is cheap and easy, so make new ones at some convenient level of granularity. Per contract is best, per relationship is tolerable, per division is less good but might work, per organization should be avoided, but maybe if you're a small business it's ok. Store the private keys on one of those tamper-resistant secure storage thingies with a USB interface. (Google already uses those things internally. Why weren't they using them for invoices?)
When invoicing, sign the invoice with the correct private key. The system should preferably also encrypt with that private key, and encrypt with the recipient's public key already on file. This prevents interception of invoices in transit, and also makes it extremely clear to the recipient's Accounts Payable department whether or not an invoice is legitimate. If it won't decrypt, Accounts Payable won't try to be helpful and pay the invoice anyway, since all they'll see is guck. Maybe allow signing only, but it should be buried deep in the options, and default to off.
What needs to be done, which as far as I know is missing, is software integration to make this process as frictionless and foolproof as possible. PGP (and gpg) have email client integration, but last I looked, it worked only indifferently well, and wasn't available in all clients. What's missing, and what really needs to exist, is integration with accounting software. The relevant public keys should be on file inside the accounting software, and plugins should be written to know what to do with them, be it GnuCash, Peachtree Accounting, Quicken, or (heaven help you) SAP. The private keys (locked with a pass phrase) should be carried on the secure storage physical device by the authorized signer, and plugged in and unlocked only when that person is actually submitting invoices.
This is where I see a business opportunity. In order to be accepted, the system must be ubiquitous, reliable, and as unintrusive as possible. That means writing, testing, and seriously grinding the rough edges off of plugins, helpers, and apps to support every version of every OS, every version of every accounting package, and every device. This requires dozens of individual pieces of software, and integration work with existing code that is only barely friendly at best, and outright hostile at worst. A customer should be able to buy into the system and get whatever they need to work with the systems and software they already use, be it a small business running a seven year old version of Peachtree on Macs to a billion dollar behemoth with a tailored SAP Solution(TM)(R)(May God Have Mercy On Your Soul). When two small business owners meet in a bar to sign a ten thousand dollar contract, their smart phones should have apps that can offer up appropriate QR codes, and take pictures of them, to be funneled into the accounting software when they get home. (Etiquette suggests that the invoicer should present her QR code first, followed by the invoicee, but of course the software works either way.) When two CEOs meet in a boardroom with an army of VPS, lawyers, and administrative assistants to sign a $100 billion contract, a whole series of keys should be exchanged for the various billing amounts and contract stages involved in the deal, with on the spot verifications quickly generated and checked.
To make all this work, I think a business is required. Open source vendors are pretty bad at removing rough edges, and rough edges simply aren't acceptable. Being widely accepted enough that a network affect kicks in requires reasonably low price points, an in-house customer service department that can do much better than follow a script, and a fairly large number of software engineers who have the unenviable task of writing plugin code for abandoned APIs from hostile vendors.
I also think it can't be done by one of the usual suspects. The IBM Solution(TM)(R)(All Is Lost) would cost 1 MEEELLION dollars and only work on alternate Tuesdays after you light the black candles and sacrifice a chicken. The SAP Solution(TM)(R)(Doom Is At Hand) would cost 1 BEEELLION dollars and require you to sacrifice a goat. The Microsoft Solution(TM)(R)(Many Eyes) would only work with Windows 10 and www.o365financials.com (Ha. That's an actual thing. Who knew.) and would delete the day's transactions every time the unstoppable auto-update kicked in. The Google Solution(TM)(R)(Super Slick) would work magnificently well as long as you use Gmail and Hangouts, then be abandoned and shut down after two years.
So who wants to fund my startup? I think the business case is a lot more compelling than a fucking $600 juicer.