Check your defenses

Your risk profile just changed dramatically. You might think the war in Ukraine will not affect you, but your risk is higher than you think.

Do you know who ultimately writes the code your vendor delivers? Your contract is with a large system integrator in your own country. They outsource actual coding to several subcontractors, who sub-subcontract until the actual code is written by a team of three people in a basement in Kyiv. And right now, an adversary with nation-state resources is out to destroy the Ukrainian software industry along with the rest of the country.

Remember the attack that hit Maersk Lines a few years ago? They are the world’s largest container shipping company and have strong cyber defenses. Nevertheless, they suffered a two-week outage and lost $300 million because an attack on their Ukrainian subsidiary got through their defenses.

Revisit your risk management plan. You need stronger network security towards your all your suppliers.

Are You Prepared?

This morning, the citizens of Ukraine woke up to the sound of a Russian invasion. After weeks of saber-rattling, some people were prepared and some were not. You might not live in a place where a Russian invasion is likely, but you can still be affected by natural and man-made disasters. Even if you are not consciously thinking about it, your unconscious mind is continually evaluating your risk.

The better prepared you are for the unexpected, the more your mind will be is at ease. The events of today are a reminder to find out how to prepare yourself. In Sweden, every household recently received a 20-page folder called “If crisis or war comes.” Find the official recommendation for emergency preparedness from your local authorities and prepare yourself a little better. It will calm your mind.

Shooting the messenger

Even though the clueless Governor of Missouri tried to shoot the messenger, he missed. Last year, a reporter published his findings that private data on more than 100,000 teachers was available to anyone who knew how to click “View Source” on a web page. The Governor held a widely-ridiculed press conference where he vowed to prosecute the “hackers” who had told the world about the incompetence of the state IT department.

A thorough report by law enforcement now roundly exonerates the journalist. It also exposes that personal information on more than half a million people had been available for a decade to anyone who care to look.

Even professional IT organizations occasionally fail like the state of Missouri did here. You have a little simple system, you are under schedule pressure, and you forgot to book time with the security team. So you roll it out without a security review. The antidote to this is to maintain a complete systems inventory with a field for the name and email of the person who did the security review. That will show you if this step got skipped, and allow you to quickly ask questions about any alleged security issues before you start shooting at the messenger.

Single Tasking Day

Today 2/22 is “Single Tasking Day.” You might think you are able to multi-task, but that is an illusion. You are simply emulating multitasking with your single-processor brain by task switching. And just like a computer, you lose a little (or a lot) of time before you are productive on the new task.

Celebrate Single Tasking Day by selecting one task from your long list of half-finished tasks, and work on that one until it is complete. Every incomplete task takes up valuable RAM in your mind. Notice how you feel more in control of your life once you can cross that task completely off your list. #SingleTaskingDay

User Blaming

The IT industry has its own version of victim blaming. I call it user blaming. That is what happens when you build an IT system without proper regard for the users’ reality. When the purported benefits do not materialize, the vendor points to the convoluted and impractical instructions given and claims that if only the users would follow the instructions, the system would work as advertised.

I was reminded of user blaming this weekend. I had worn out the burrs on my coffee grinder, and as is sadly often the case, a replacement part was more expensive than a new machine. Being a professional, I always read the instructions. They told me to clean the machine after each use. Since I only grind what I need, that would mean several cleanings a day. And the cleaning involved six steps, washing everything in lukewarm water, emptying out the beans, disassembling the grinder, cleaning the burrs with the supplied cleaning brush, and much more.

That is an abdication of responsibility. Just like when an IT vendor provides unrealistic and impossible-to-follow CYA instructions. Take responsibility. Build a quality product that works in real life.

Book review: The New Map by Daniel Yergin

I picked up this book after reading an interview with Daniel Yergin where he came across as very insightful into how oil and gas have affected the recent past and how it will affect the future. Unfortunately, such skill is not very apparent in this book.

Covering America’s shale, Russia’s resources, China’s needs, the Middle East’s troubles, the future of cars, and the maybe-coming energy transition, Yergin does cover the whole spectrum around oil and gas. The writing flows well with anecdotes and cute vignettes, but the whole is just a recapitulation of the history of the past couple of decades.

I was hoping for more insights, analysis, and opinion, but he does not share any in this book. For that, it seems you will have to hire him and his expensive colleagues from IHS Markit as consultants. If you are well-read on current affairs (say, if you are a regular reader of The Economist), this book contains little you don’t already know and will not be worth your time.

We are Still Building our IT on Shaky Ground

Once again, researchers have demonstrated the shaky foundation under our IT infrastructure. A lot of modern code is being built with Node.js, making use of Node Package Manager (npm) to pull in libraries that your code depends on.

There is no evidence that evil Russian hackers built npm. But if it didn’t exist, it would be a priority for the cyber-warfare command of our adversaries to build something like it and tempt us to use it.

The problem is that it is easy to use npm wrong, and hard to use it right. We’ve already seen many cases where organizations simply pull the latest packages from npm when they build. That means that as soon as the central package in the npm repository is corrupted or taken down, that failure will ripple through many layers of code that depend on it.

The latest discovery is that 8,000 packages have maintainers with an expired email domain. That allows any hacker to purchase that domain, re-create the maintainer email and take over the package.

Ask your CISO or other security function how your IT organization makes sure that every project only pulls npm packages from your official repository of security-vetted packages.

How Much Time do you Have?

You never know when it’s your time. Last year, a woman in Canada awoke to a loud noise in the middle of the night. Jumping out of bed, she turned on the light and saw a hole in her ceiling right above the bed. And on the bed was a 3-pound meteorite that had punched right through her roof, missing her head by inches.

It is exceedingly rare for people to get killed by space rocks. But disease and mundane accidents also strike without warning. Make sure you use every day well. How will you have improved your life or the world at the end of today?

Reliability Engineering

Coinbase just spent 16 million dollars on a 30-second Superbowl ad. It seems like the ad worked, because their website was promptly overwhelmed with traffic and crashed. Maybe they should have spent a bit on resilient network infrastructure as well.

The problem with many of the IT infrastructures I see is that they are brittle. Each component can be resilient with load balancing and database failover without making the overall system robust. Reliability engineering is a cross-domain discipline, and it is not enough that each team builds robustness into their little piece of the total landscape. Who is responsible for the overall reliability of your systems?