Sten Vesterli's Blog

Making IT Live up to its Promise

Tag: Security

Do You Let Convenience Trump Security?

IT Leadership, Technology That Fits,

Personal data on anyone is available from all the large U.S. social media platforms and ISPs to anyone who cares to ask. The mechanism is an Emergency Data Request (EDR). When law enforcement doesn’t have time to wait for a court order because someone’s life is in imminent danger, they send an EDR. This is simply an email from a law enforcement mail address. To send a fake EDR, you simply purchase a legitimate government email address from a hacker who has breached one of the more than 15,000 police forces in the U.S.

You would never divulge information on your customers based on just a plausible-looking email. But how do you ensure that expediency has not trumped security somewhere in your organization?

How are you Vetting New Packages?

IT Leadership,

Some of the code you depend on was written by Ukrainians, Russians, and hacktivists. Deep in the dependency tree of NPM packages your software depends on, you will find node-ipc. That package was recently drafted into the ongoing war in Ukraine. If you are in Russia or Belarus, it will delete your files. Otherwise, it will only write an anti-war message to stdout and put it on your desktop.

As a professional organization, you are surely not just getting the latest software packages directly from a repository on the internet. But what is your procedure for vetting new versions you incorporate into your blessed repository? With the current threat level, having a single overworked developer do this in addition to his normal development tasks is not a good idea.

Cybersecurity Insurance: Read the Fine Print

IT Leadership

When are you in a war? Your cyber security policy probably contains the standard exclusion: It does not cover acts of war. But when the war is being fought partially in cyberspace, it can be hard to tell if you are part of it.

Insurers tried to use the war clause to wriggle out of a cybersecurity claim lodged by Merck. Merck was hit by the NotPetya attack that spilled over from Ukraine into the systems of global shipping giant Maersk as well. They insurers claimed it was war, but a judge recently dismissed that argument and ordered insurers to pay up.

The insurance industry is tightening up their exclusion language with new definitions from Lloyd’s Market Association. If you recently got an email from your insurance company with a boring “we have clarified the terms” subject line, read it carefully. You just might find that your insurance company has re-defined your cyber security coverage to be worthless.

Cybersecurity must be risk-based

IT Leadership, Technology That Fits,

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.

Check your defenses

IT Leadership

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.

Shooting the messenger

IT Leadership,

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.

We are Still Building our IT on Shaky Ground

IT Leadership,

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.

The Horror of not Testing

IT Leadership, Technology That Fits

In the classic 1983 John Carpenter horror movie “Christine,” the radio on the possessed 1958 Plymouth Fury can only play old rock and roll stations. Owners of 2016 Mazdas in Washington State now have the same experience. They don’t even get rock’n’roll but are instead forced to endure NPR.

Their cars are not possessed by evil spirits but suffer from a software bug. It turns out that the local NPR station sent out “now playing” album images without a .jpg extension. That was enough to send the radio and navigation unit into an endless loop, making it impossible to use navigation or Bluetooth – or change the station. Embarrassed, Mazda is offering a free replacement of the $1,500 connectivity master unit.

This incident illustrates the dangers of casual testing. A professional tester would have sent the unit all kinds of corrupted or misnamed files, files with zero length, and very large files. That would have uncovered the bug. Do you have testing professionals on your teams? If you let developers test their own software, you’ll end up where Mazda is – or worse.

Do you have control over the libraries that go into you projects?

IT Leadership, , ,

Yet again, a rogue developer took down thousands of applications that depended on his library. Unhappy with the fact that open source developers work for free and companies use open source to make lots of money, he deliberately broke the faker.js and colors.js NPM libraries.

Interestingly, the more than 20,000 projects that depend on these two libraries download them almost 30 million times per week. That means a lot of projects are downloading the code from the NPM repository for every build.

In a professional IT organization, all your projects don’t just pull the latest version, they pull a specific version. And you don’t pull straight from the internet, but from the “blessed repository” with the officially approved version of everything. Are you sure you don’t have projects that just pull the latest libraries down from wherever?

Accidental Publication

Beneficial Intelligence

Beneficial Intelligence is out. This week: Accidental publication. Some data leaks are IT’s own fault. We should be able to prevent developers and users from leaking our data through unsecured cloud storage. We should not roll out systems that leak data if the user edits the URL or views the web page source. Are you sure every system your organization rolls out has been subject to a security review? If not, you might be the next organization to find that you have accidentially published confidential data.

Listen here or find “Beneficial Intelligence” wherever you get your podcasts.