Do You Trust Amazon?

The default is no trust. You shouldn’t trust a random USB stick you pick up in the parking lot, and your customers and users don’t trust you. If you want trust, you have to be transparent in a way your users understand and appreciate.

Somewhere in the Amazon terms & conditions it probably says in illegible legalese that everything you say to your Alexa smart speaker can and will be used against you. Researchers have shown that your interactions with Alexa are reported to dozens of advertisers, and Amazon says the research is flawed. Who do you believe?

Amazon have hundreds of lawyers and are probably within the law. The problem is that they are not complying with users’ expectations. If you want any kind of goodwill from your users and customers, you have to meet their actual expectations. Hiding behind reams of legalese doesn’t cut it.

Do You Let Convenience Trump Security?

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?

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.

Do People Believe You?

How is your credibility balance? Will your employees, partners, and customers believe you in a crisis?

The information war accompanying the kinetic war has been resoundingly won by Ukraine. Many of the stories coming out of the conflict zone are false, but Ukrainian stories are given the benefit of the doubt while Russian stories are immediately disbelieved.

Honest communication adds to your credibility balance. Trying to sweep your failures under the carpet and hitting your critics with spurious DMCA takedowns and questionable lawsuits detracts from it. If you are in a credibility deficit when the next crisis hits, it will become orders of magnitude worse.

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

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?

Are you Trusted?

Trust is a fragile thing. The University of Minnesota (UMN) broke it and are now struggling to contain the fallout. How do you ensure your IT organization remains trustworthy?

UMN researchers submitted a Linux patch containing a known bug in order to see whether the Linux community would spot the problem. This kind of uninvited security testing is ethically a gray area and is frowned upon by most IT professionals. The researchers wrote a paper with their findings and then submitted more buggy patches.

The Linux community was not amused by being experimented on, and decided to block all further contributions from the University of Minnesota. Furthermore, they decided to rip out several hundred past contributions to the Linux kernel by the UMN because they no longer trusted them. University leaders are belatedly scrambling to apologize, but the community has rejected their apology.

As a CIO or CTO, do you know if your users trust the systems you roll out? One unhelpful supporter unable to explain a data discrepancy can make the entire Finance department lose trust in your expensive Business Intelligence dashboard. IT only creates business value if it is used and trusted. Make sure you measure trust.