Beware of Asymmetric Risk/Reward Profiles

Would you continue to sell a lock based on technology that has been known for 14 years to be trivially easy to hack? Of course not! But Scantron in Denmark has merrily been foisting insecure locks on unsuspecting Danish apartment administrators. Even after a worried renter told them about the problem in several emails and even physical letters (!), they ignored the problem. It took a media shitstorm to make them realize the errors of their ways.

Digital locks have an asymmetric risk/reward profile. The reward is small – you save a little by not having to administer physical keys and re-key locks. The risk is huge – someone might copy a key, turn it into a master key, and rob hundreds of apartments.

When you are evaluating digitalization projects, be very careful about those with such an asymmetric profile. Almost every organization has digitalization projects with a better risk/reward balance than digital locks…

There are Many Reasons Not to Move to the Cloud

You don’t save anything by moving to the cloud. Ask around – how many of the organizations you know who moved to the cloud have reduced operations headcount? Some things are simpler in the cloud, but many others are more complicated.

You enforce some good security practices because there is no way to NOT install the latest security patches. And you can quickly spin up an extra testing environment.

But unless you really have a highly variable load, or you are starting something new where you don’t have a clue how much power you’ll need, the cheapest option is to buy some hardware and put it in your server room.

The next time one of the vendors tells you how much you save by moving to the cloud, take a really good look at the calculation. I’ll be happy to help you. You will likely find out that there isn’t a business case for moving.

It’s Expensive to Try to Get By With the Cheapest Resources

Talent is expensive. Not paying for talent is more expensive. Microsoft gets that. The U.S. Department of Defence doesn’t.

The Microsoft bug hunting program has a maximum payout of $250,000, and they did pay out $200,000 this year. You would think a crucial national defence vulnerability would merit a bigger bounty that finding a flaw in the Microsoft hypervisor, wouldn’t you? The DoD pays out $500 for a high-severity bug, and a whopping $1,000 for a critical issue.

Your developers are rewarded for shipping functionality. They don’t have the mindset to find the vulnerabilities. To build secure systems, you need to offer a bug bounty, or hire outside experts to do security review, or create your own internal white-hat hacker team. It does cost money. But security breaches cost much more.

The Antidote to Value-Destroying Vanity Projects

Choosing the solution that is 100 times more expensive sounds absurd. Nevertheless, that is what the U.S. Congress has decided, which is why NASA is struggling to get its SLS rocket off the ground. It has nothing to do with putting a man on the moon and everything to do with keeping the big NASA factory in Alabama running. They don’t have the technology to compete with newer space companies like SpaceX but are cobbling together old Space Shuttle parts. They’ve actually been going around to museums in the U.S., taking out old space shuttle engines for the quixotic project foisted upon them by Alabama Senator Richard Shelby.

Some organizations face a similar challenge: The CEO or someone else in senior leadership has an idea for some technology, and IT is ordered to deliver it. It doesn’t matter if such a vanity project is practical, feasible, or cost-efficient. You cannot fight this kind of project individually because they are highly connected with the ego of one individual.

The solution is to establish a standard evaluation process for technology projects. Every project needs a business owner responsible for calculating the business benefit. Every project also has a technical owner responsible for calculating the cost, including the ongoing running costs after completion. If the benefit comfortably exceeds the cost, the project is qualified to enter the competition with other claims on company investment.

You might not have such a process because a rational decision might also kill some of the IT department’s most beloved resumé-enhancing projects…

Cybersecurity must be risk-based

Good cybersecurity is based on risk analysis. It is not based on locking down everything as tightly as you can.

I’ve been discussing the consequences of the war in Ukraine with several cybersecurity experts. Some argue that if you have to strengthen your defense now, it means it was too weak before. That is a fundamental misunderstanding of security. Security, like availability, reliability, and many other aspects of your technology is a trade-off. Higher security costs more money and slows your organization down. You don’t need maximum security always. You need a security level that is appropriate to your risk.

Right now, cyber-warriors and vigilantes are firing indiscriminately in all directions. You might get caught in the crossfire even if you have nothing to do with either side in the war. That’s why your risk has increased and you need to strengthen your cyber security posture. When the war is over, you can reassess your risk again.

Do you Really Need Blockchain?

It is reported that the IBM blockchain team has been gutted, even though IBM vehemently denies it. Enterprise blockchain seems to be in retreat across a wide range of industries.

Organizations with high value maturity have solid processes in place to calculate the business benefit of new technologies, and only a few of those invested in blockchain. But organizations with a lot of legacy technology who felt the need to jazz up their tech portfolio enthusiastically embraced blockchain and started vaguely defined projects

If you are a CIO, take a look at your project portfolio. If you have blockchain projects on the list, have an experienced analyst from outside the project team take a good look at the business case. If she reports back that it is based on overly optimistic assumptions, it should be re-evaluated. If that means the costs outweigh the benefits, the project should be cancelled.