All Posts in Industry Commentary

|In: Business Ethics|Last Updated:

A quick poll: Which recent disaster was the worst: (A) Hurricane Harvey; (B) Hurricane Irma; (C) the Equifax data breach?

Equifax said its systems were breached starting in mid-May until it discovered the hack on July 29. It informed the public on September 7.

The United States is home to about 240 million adults. Equifax provided enough personal details to make 143 million of them vulnerable to identity theft. Add all the other remaining big breaches, account for overlap, carry the one, and you end up with, in round numbers, everyone.

The bad guys have something in common with the Social Security Administration: They both know your social security number.

It’s long past time to fix this mess. And since nobody is stepping up to the plate, it’s time for a modest proposal from the Keep the Joint Running Think Tank, otherwise known as yours truly with a bottle of beer in his hand and a keyboard in front of him.

Okay, “fix” might be going too far, but there are some steps we could take that, if not simple, would at least be straightforward. Share them with your senators and congressperson. Starting with the most obvious and working our way down through the list of nearly-as-obvious:

> SSN 2.0: The Social Security Administration should issue each of us a brand-spanking-new social security number that nobody other than it and you know about. Except, that is …

> Business access to SSN 2.0: Some businesses do have a specific need for some individuals’ social security numbers. SSN 2.0 redefines business use of social security numbers. As of now it’s a right. Under SSN 2.0 it becomes a privilege — soliciting and storing an individual’s social security number will be illegal, except for businesses that have a demonstrable need. Any other company caught storing social security numbers in any company database will be immediately liquidated.

> SSN 2.0 certification: In order to be awarded the right to store social security numbers, applicants must prove compliance with the agency’s data protection requirements. Chief among these:

– Universal encryption of every bit of stored data. No, not just personally identifiable information (PII). Everything. That eliminates the possibility of the “Oops — we missed that one! Sorry …” factor. Too expensive? Don’t be ridiculous. Compare this expense to the cost of fixing the massive level of identity theft we’re in for.

Oh, by the way … does anyone reading this think the data Equifax lost was encrypted? Me neither. Which leads to this question: What? And this one: Seriously?

– AI-based intrusion detection: Companies that encrypt all their data can still be breached, and decryption keys can be stolen — through social engineering techniques if not hacking.

Even with stolen decryption keys a breach isn’t that big a deal. An undetected breach is a big deal. The use of AI techniques to detect intrusions is in play right now. There’s simply no valid reason other than bad budget priorities for failing to detect and address a breach for a month or more.

– The fundamentals: Keeping current with patches, rotating encryption keys, role-based identity management applied to all employee transitions, white-hat hacking … you know, not even best practices, as if there was such a thing. Just the minimum standards of basic professionalism.

– Keep the PR department out of it: I don’t care if the breach makes the company look bad. The company’s image really isn’t the issue.

> FBMA: For hurricanes, tornadoes, floods, and earthquakes we have FEMA. For massive data breaches we have bupkis. It’s time to create the Federal Breach Management Administration. FEMA in Houston has, I think, demonstrated the validity of federal government intervention in disasters of a certain size and scope. This is just as logical in the virtual world as the physical one.

I know many of KJR’s subscribers have a libertarian bent, and don’t think the Federal government has any business regulating or involving itself in the financial transactions between two parties.

After all, immediately after reporting the breach (which is to say about four months after the breach itself), Equifax offered everyone affected a free identity theft monitoring service.

Because of course I’m going to trust the company that lost my data to let me know my data has been stolen.

And oh, by the way, as reported by The Denver Post’s Tamara Chuang, (“Clearing up confusion on the Equifax data breach, no thanks to Equifax,” 9/8/2017) those foolish enough to sign up inadvertently gave up their right to sue.

Just an opinion here: One important role for government is evening out a hopelessly asymmetrical balance of power.

Like, for example, the imbalance between Equifax’s power to collect data about you and your power to avoid doing business with it.

Comments

|In: Industry Commentary|Last Updated:

It’s always more complicated than it looks.

Case in point: Houston

Your hypothetical challenge: Bring the city back on line. What does this entail?

Lots and lots of lots and lots, that’s what.

Understand, I know nothing at all about civil engineering, or emergency management, and not all that much about enterprise risk management. What I do know is that nobody else can keep the list of everything that has to come back on line in their head either, let alone the interdependencies that could lead to creating a proper Gantt chart.

Oh, by the way, a half hour of Googling failed to uncover anything resembling a disaster recovery plan for the city of Houston. An emergency management plan yes, a recovery plan no.

Which isn’t necessarily bad management. As with IT’s ancient habit of trying to create comprehensive software designs before beginning to write any code, so disaster recovery plans of metropolitan scale or larger for disasters of inordinate magnitude are probably pointless. If, that is, they do much more than list the organizations that need a recovery plan, specify what one should encompass, and insist they have them.

Even then there are limits. As everyone who’s involved in disaster recovery and business continuity knows, a plan that isn’t tested isn’t a plan.

And along came Harvey.

Case in point: New York City.

I worked with a client there several years ago, enough that a corporate apartment made more sense than staying in hotels. The result, though, was that for a couple of years I qualified as a resident, meaning I owed New York City taxes. These were (1) substantial, and (2) business expenses, not directly deductible from my Minnesota state tax bill.

This sawed me off. Until, that is, I saw a sign in the midtown Whole Foods that explained New York City creates enough garbage every day to fill the Empire State Building.

It occurred to me then that I had not the slightest idea how to go about removing that quantity of garbage every day, and that garbage removal is far from the most complicated challenge in running New York City.

As I had no idea how to run NYC I certainly had no idea how to run it at a lower cost, which meant I should put up and shut up. I benefited from services I didn’t even know were being provided. My New York City tax burden was how I paid for them.

Case in point: Any legacy retirement

Over and over again, companies make this mistake: They decide to retire the ancient mainframe batch COBOL system the whole company has been running on for forty years. And from this decision comes a logistical nightmare, because no matter how you go about it, you can’t shift the entire company from the old system to a replacement at the flip of a switch. It has to be phased and staged.

And no matter how you go about the planning it turns out many business areas will be running in a mixed environment for a year or more.

But unlike New York City or Houston, a lot of this complexity is a self-inflicted wound, the result of looking at exactly the wrong end of the horse.

The problem is the decision to retire the mainframe. Not that the company should stay on it. No the problem is that this focuses everyone’s attention on what they’re migrating from. In addition to the logistical migraines this thought process creates, it results in something even worse than the planning nightmare: When the project is done and the mainframe has been retired, the business runs pretty much the same as it ran before it invested the zillion or so direct dollars, plus sweat and opportunity costs, that were needed to make it all happen.

Much of which would have been avoided had everyone focused on the opposite question: What to migrate to.

Even better, they should be focused on how each business manager at every level wants to run his or her part of the business differently and better, leading to an applications portfolio plan that will mostly let them do so.

Taking this approach, things still aren’t simple. They are, however, simpler — a lot simpler, because (for example) moving Sales to a modern CRM system is, at a minimum, clear in what has to happen.

And moving Sales to a better sales process that’s possible because of the modern CRM system’s features has actual business benefit beyond a modest reduction in the IT operating budget.

Comments