In June we were told by the federal OPM (Office of Personnel Management) that as many as four million personal records of government employees who hold security clearances had been compromised by what appeared to be Chinese hackers. We’ve since learned that fourteen million — no, wait — at least twenty-four million records were compromised.
A congressional hearing sounds like a cure for insomnia, but I was fascinated by the hours-long video record of the June 24 hearing by the House of Representatives’ Committee on Oversight and Government Reform. The OPM’s director, CIO, US-CERT representative, Inspector General, and OPM contractors responded to questions by the committee. It’s a long hearing, but filled with revealing glimpses into a bureaucracy that spent over five hundred million dollars on I.T. since 2008. And still failed.
It sounds like OPM has three insecure areas:
- the records within its files aren’t encrypted;
- its perimeter security is vulnerable;
- its management of vendors’ security policies is weak.
Unencrypted records stored in COBOL files
I gather that OPM stores these records in files that were created by applications that were written in COBOL. Apparently over a million records include fingerprints stored as unencrypted graphics images. It’s likely that these COBOL files are ISAM (Indexed Sequential Access Method) files or derivatives. Fields — even numeric fields — within ISAM files are stored as ASCII characters. It’s inefficient, but very easy to read.
As far as I know, COBOL lacks the ability to encrypt fields. I’ve managed a legacy COBOL ERP system that was compiled with MicroFocus COBOL and used the Btrieve record management system. It worked nicely. The underlying Btrieve record manager would allow fields to be encrypted and supplemental indexes added without the permission of the overlying COBOL program. The original COBOL code remained intact, unaware that Btrieve was adding indexes, encrypting, decrypting, etc. Similar adaptations of legacy COBOL programs to Oracle RDBMS exist.
My guess is that the OPM data files are read by more than one application. If the record layouts of these files were changed, all applications that read them would need to be changed. This could be a major task.
I can’t comment on the OPM’s perimeter vulnerability. Their supervision of contractors was inadequate, since poor user management at contractor KeyPoint Government Solutions opened a door to attackers. (Details: Contractor breach gave hackers keys to OPM data).
Data security ain’t easy.
I’m happy to learn that the OPM director and CIO were fired after this hearing. They were clearly in over their heads. It is, though, like closing the barn door after the horses (or data) have fled.
Non-technical people should not attempt to manage technical enterprises. They simply can’t manage processes that they don’t understand. It’s too easy to fool a non-technical person with smoke and mirrors. Case in point: Steve Ballmer, a salesman who mis-managed Microsoft for a decade.
Visit my website: http://russbellew.com
© Russ Bellew · Fort Lauderdale, Florida, USA · phone 954 873-4695
Russ' space 