Information Security and Privacy — Trust = Vulnerability

I committed a crime in order to write this column. I stole Kevin Mitnick’s book. You know Kevin Mitnick. He’s the famously felonious weasel who lies, cheats and steals his way into other people’s computer systems. He’s a hero to hackerdom. But rather than contribute to his royalties or sales, I used his suggested techniques of “social engineering” to filch a copy from his publisher. It felt good. Thanks, Kevin.

In fact, reading Mitnick’s book was a powerful experience. Not because the book was well-written?although it’s not bad?but because it tells story after painful story of people who got digitally screwed because they trusted jerks such as him. They tried to be helpful; they tried to be responsive; they tried to be kind. That was their fatal mistake. When a Kevin “Klone” pretends to be from a help desk, you know who’s really getting helped. The essential Mitnick message is that “trust” creates vulnerability. Trust is the gift that makes Mitnicks possible.

That’s what makes implementing network security so hard. It isn’t that people are always the weakest link, or that the code has more holes than Swiss cheese, or even that Russian mobsters now have the resources and incentive to crack any system they choose. It’s that effective network security means building systems that tell people they can’t be trusted.

Most reasonable people?your customers, your employees and your suppliers?resent being treated as untrustworthy. The natural human tendency is to resist initiatives that presume we are potential liars, cheats and thieves. Yes, we’ll tolerate memorizing a password or two, but how many hoops do you seriously want us to jump through? You’re kidding, right?

Computer security is doomed to become even more cumbersome and costly. Why? Because the more dependent organizations become on their networks, the less trusting they can afford to be. That’s the Net-centric enterprise security paradox: The more access I need to be more effective, the more effectively I need to be monitored. The more network access we give to our customers, suppliers and ourselves, the more network protection we all need. Everyone becomes more vulnerable to being Mitnicked or SQL Slammed.

This is where CIOs get screwed. Unlike virtually every other facet of network economics, computer security doesn’t enjoy economies of scale. Security inflicts diseconomies of scale. Giving more people more passwords hardly represents an “economy of scale.” To the contrary. It represents new complexity that has to be managed, tracked and audited. That’s both computationally and organizationally expensive.

Network security costs disproportionately accelerate as organizational Net-centricity increases. I’ve personally witnessed recognition of how this reality infuriates top management. By the time one bank calculated the costs of making certain databases available to both customers and loan officers, the proposal’s ROI was ruined. Security killed its CRM. Executives spoiled by favorable network economics believe their security spend should, at worst, be a relatively fixed percentage of the network budget. Never happens.

Security costs almost always spike and surge beyond expectations. The underlying dynamic is inescapable. When more people have more real-time access to more data of ever more value, the risks associated with security breaches exponentially increase.

Those problems can’t be solved. They can only be managed. Most companies manage them by telling the CIOs that they’re in charge of network security. Thanks a lot.

The serious question is, how should CIOs manage these excruciating trade-offs between network economies of scale and network security’s diseconomies of scale? My answer is that CIOs should tell their operating committees and their boards that it isn’t up to IT to define what “trust” means or what it’s financially worth.

It’s Not Your Job

Simply put, CIOs should never, ever be put in charge of their organizations’ computer security policies. CIOs are in the worst position to evaluate security trade-offs precisely because they know better than anyone else the technical trade-offs between making their networks more cost-effective and making them more secure. They’re inherently biased to technical solutions because that reflects both their budgets and their expertise. But because security almost always becomes a people issue, most CIOs have neither the organizational standing nor the interpersonal skills to assure enterprisewide compliance.

Put it another way: Unless CIOs and IT have the explicit power to fine or fire any employees who violate security, they shouldn’t be made responsible for security. Fortunately, CIOs have a more important role to play in security policy debates.

While CIOs shouldn’t say how much trust is worth, they have every obligation to insist that legal and finance do. CIOs need to push and challenge marketing about just how much customer inconvenience for “improved” security is too much. The CIO’s goal must be to get the organization to align its investments in network security to reflect perceived risk. The entire enterprise, not just IT, then has to decide how to manage that risk.

Security for the sake of security is inherently wasteful. It’s bad business. More dangerously, it breeds contempt from those who hate complying with inefficient and ineffective security protocols. The best counter is for IT to insist people put in writing scenarios of what they want their security interactions to look like in 18 to 24 months. Security is a process to be managed rather than a goal that’s achieved. Thus, people must be pushed to decide how far they want to go in enforcing trust. The notion that computer security is whatever IT says it is is the abdication of professional responsibility.

Should individuals, teams or departments be encouraged to design their own computer security regimes? How should employee breaches of security protocols be disciplined? Does the organization have the right?indeed, the obligation?to stress-test its security systems by trying to trick its employees into breaking the rules? In other words, should an organization Mitnick itself as a way to immunize itself against the real Mitnicks? The harsh fact is that security systems work only if you institutionalize a certain degree of distrust.

But how much distrust is too much? When does the cost of distrust outweigh its business benefits? CIOs have no way to know the answer to those questions. They do, however, have every opportunity and obligation to collaborate with every function and department to find out. Savvy CIOs will insist their organizational partners demonstrate how well they can enforce the security protocols they deem so vital. IT’s job should be to help them do that, not do it for them. CIOs aren’t members of the CIA.

Yes, CIOs need to be abreast of the tools, technologies and techniques like honeypots and PKI to assure an appropriate portfolio of security options. In the final analysis, however, organizations determine what’s worth protecting and what’s not. The organization must declare what levels of trust and openness are dangerously inappropriate. It’s up to CIOs to make organizations cognizant of that.