Posted on

Supply Chain Management: Averting a Covid-19 Catastrophe

Yossi Sheffi is a supply chain management expert who moves freely between business and academics. He founded several companies, and he sits on the boards of large corporations. He teaches engineering at MIT and has authored a half-dozen books that are read by engineers, economists, and business people. When I heard about his latest book, The New (Ab)Normal, in which he tackles the covid-19 disruption of the global supply chain, I got a copy as soon as I could, stayed up late reading, and got up early to finish it.

gosling-supply-chain
The gosling supply chain management system

The New (Ab)Normal

New (Ab)Normal was worth it. Sheffi’s insider views are compelling. He has talked with the executives and engineers who struggled to put food and toilet paper on supermarket shelves, produce and distribute medical protective gear, and prevent manufacturing plants from foundering from supply disruption.

Supply chains and the media

Sheffi has harsh words for some media. For example, he says empty supermarket shelves were misunderstood. Food and supplies were never lacking, but they were often in the wrong place. Until the lockdowns in March, a big share of U.S. meals were dispensed in restaurants, schools, and company cafeterias. These businesses purchase the same food as families, but they get it through a different supply network and packaged in different ways.

Cafeterias buy tons of shelled fresh eggs in gallon containers, but consumers buy cartons of eggs in supermarkets for cooking at home. When the eateries shut down or curtailed operations and people began eating at home, plenty of eggs were available, but someone had to redirect them to consumers in a form that was practical for a home kitchen. Sheffi says food shortages appeared in dramatic media video footage and sound bites, but not in supply chains.

Bursty services

Changing buying patterns worsened the appearance of shortages. Supermarket supply chains are adjusted to dispense supplies at a certain rate and level of burstiness. These are terms I know from network and IT service management. A bursty service has bursts of increased of activity followed by relatively quiet periods. At a bursty IT trouble ticket desk, thirty percent of a week’s tickets might be entered in one hour on Monday morning when employees return to work ready to tackle problems that they had put off solving during the previous week. A less bursty business culture might generate the same number of tickets per week, but with a more uniform rate of tickets per hour.

Bursty desks must be managed differently than steady desks. The manager of a bursty service desk must devise a way to deploy extra equipment and hire more staff to deal with peak activity on those hectic Monday mornings. Experienced managers also know that an unpredicted burst in tickets on a desk, say in the aftermath of a hurricane, will cause havoc and shortened tempers as irate customers wait for temporarily scarce resources. The best of them have contingency plans to deal with unanticipated bursts.

Cloud computing to the rescue

The rise of cloud computing architectures in the last decade has yielded increased flexibility for responding to bursts in digital activity. Pre-cloud, managers who had to provide service through activity bursts had to deploy purchased or leased servers with the capacity to handle peak periods of activity. Adding a physical server is a substantial financial investment that requires planning, sometimes changes in the physical plant, often added training and occasionally hiring new personnel.

Worse, the new capacity may remain idle during long non-peak periods, which is hard to explain to cost conscious business leaders. Some businesses are able to harvest off-peak capacity for other purposes, but many are not. Cloud computing offers on-demand computing with little upfront investment, greatly reducing the need to pay for unused capacity to improve service during peak periods.

The food supply

Covid-19 caused an unanticipated increase in the burstiness of supermarket sales. Under the threat of the virus, consumers began to shop once a week or less, buying larger quantities. Folks accustomed to picking up a few vegetables and a fresh protein on their way home from work began arriving at the store early in the morning to buy twenty-five-pound sacks of flour and dry beans, cases of canned vegetables, and bulk produce.

On the supply end with the farmers and packers, the quantities sold per month stayed fairly constant because the number of mouths being fed did not change, but in the stores, by afternoon, shelves were bare waiting for shipments arriving in the night because consumers were buying in bursts instead of their “a few items a day” pattern. This made for exciting media coverage of customers squabbling over the products remaining on the shelves. The media seldom pointed out that the shelves were full each morning after the night’s shipments had arrived and were on the shelves.

Toilet paper

The infamous toilet paper shortage was also either illusory or much more nuanced than media portrayals. Like restaurants and cafeterias, public restrooms took a big hit with the lockdowns. Like food, toilet paper consumption is inherently constant, but toilet paper purchasing burstiness and where the product is purchased varies.

Commercial toilet paper consumption plummeted as shoppers began to purchase consumer toilet paper in the same bursts that they were purchasing food supplies. There may have been some hoarding behavior, but many shoppers simply wanted to shrink their dangerous trips to the market by buying in bulk. Consumer toilet paper is not like the commercial toilet paper used in public restrooms, which is coarser and often dispensed in larger rolls from specialized holders. This presented supply problems similar to food supply issues.

Supply disruption

Supply chains had to respond quickly. Unlike digital services, responding to increased burstiness in supermarket sales required changes in physical inventory patterns. Increasing the supply of eggs by the dozen at supermarkets and decreasing eggs by the gallon on kitchen loading docks could not be addressed by dialing up a new batch of virtual cloud computers. New buying patterns had to be analyzed, revised orders had to be placed with packers, and trucks had to roll on highways.

Advances in supply chain management

Fortunately, supply chain reporting and analysis has jumped ahead in the last decade. Consumers see some of these advances on online sales sites like Amazon when they click on “Track package.” Unlike not too long ago when all they were offered was Amazon’s best estimated delivery date, they see the progress of their shipment from warehouse through shipping transfer points to the final delivery. Guesswork is eliminated: arrival and departure is recorded as the package passes barcode scanners.

The movement data is centralized in cloud data centers and dispensed to the consumer on demand. Many people have noted that Amazon shipments are not as reliable as they were pre-covid. However, the impression of unreliability would be much stronger without those “Track package” buttons.

Supply chain managers have access to the same kind of data on their shipments. In untroubled times, a shipping clerk’s educated estimate on an arrival time of a shipment of fresh eggs may have been adequate, but not in post-covid 2020, with its shifting demands and unpredictable delays. Those guesses can’t cope with an egg packing plant shut down for a week when the virus flares up or a shipment delayed by a quarantined truck driver.

Good news

Fortunately, with the data available today, these issues are visible in supply chain tracking systems. Orders can be immediately redirected to a different packing plant that has returned from a shutdown or dispatch a fresh relief driver instead of leaving a shipment to wait in a truck stop parking lot. Issues can be resolved today that would not have been visible as issues a decade ago. Consequently, supply chains have been strikingly resilient to the covid-19 disruption.

Supply chains were much different in my pioneer grandparents’ days. They grew their own meat, poultry, and vegetables, and lived without toilet paper for most of their lives. Although supply was less complicated, the effects of supply disruption, like a punishing thunderstorm destroying a wheat crop, was as significant as today’s disruptions.

In November of 2020 with steeply rising infection counts, predictions of new supply disruption occasionally surface. The response of supply chains so far this year leave me optimistic that we have seen the worst.

Posted on

Home Network Security: RedLINK™

In a previous post, I said that the Internet of Things (IoT) has increased the size and complexity of home networks. We had a new heating system installed recently that added a new dimension to our home IoT network: RedLINK ™, which, on the whole, was good for our home security.

Home network security sunrise
Home network security sunrise

IoT and network complexity

As networks increase in size and complexity, they become more difficult to manage and secure. Businesses hire technicians who are trained in security to manage their networks, which is usually a spendy proposition, but there is a lot at stake and security is one of many justifiable costs of doing business that accountants and managers prepare for.

Working from home network security

At home, we are in a different position. I’m not an accountant or a tax expert, so don’t take my word for it, but if your income is from a regular paycheck, the IRS probably will not allow you to deduct expenses derived from working at home. You might be able to convince your employer to reimburse you for these expenses, but be sure that the reimbursement will not be considered taxable income. In other words, in most cases, you secure your home network on your own nickel.

When I was working from home, most years, my employer, CA Technologies, permitted me a fixed amount on my expense account that I could request for working-from-home outlays. Not all employers do that, but take advantage if you can.

Since I retired and began writing books for extra income, I have deducted some for computing, network, and office overhead every year. I keep records of business expenses and have an accountant go over them to be sure they’ll pass an audit.

Home network security challenges

As a businessman, I don’t think I could justify investing much cash in our home network security. We are not juicy hacker bait. Although a successful attack could throw us in a world of hurt, it would not give a hacker much of a payday compared to even a moderately large business or agency.

Nevertheless, I worry about the security of our network. That means home network security is a DIY project for me. Fortunately, forty or so years in the computing industry has prepared me for this.

Securing HVAC

I’m working on methods to secure home networks that folks can do for themselves. In this post I will say something about securing home heating, ventilation, and air-conditioning systems (HVAC). This is an important topic for me because we just had a new heating system installed.

I was pleased to discover that our new system uses an alternative to standard Wi-Fi for communications. Sensors and controls connect wirelessly, but not the same way the rest of our computing gear connects.

IoT and Wi-Fi

Wi-Fi, the wireless network standard that almost every home network relies on, was designed with the capacity for data flows like streaming video, which is massive overbuilding for most IoT purposes. The data passing to and from IoT devices, with the exception of remote cameras and speakers, is typically miniscule compared to Wi-Fi loads.

There are several IoT platforms available that support low bandwidth communications. Our heating system uses the Honeywell RedLINK ™ platform specifically designed to support residential heating, ventilation, and air conditioning (HVAC) systems. It uses the 900 MHz band, which is a lower frequency than most Wi-Fi.

Lower frequencies have longer range and penetrate barriers like walls more easily than higher frequency signals. Thus, lower frequencies are more reliable and cover more area. The downside of lower frequency is lower data transfer rates, but for applications that don’t transmit a lot of data, like HVAC, lower data rates are fine.

A heating system that reports temperatures and humidity every 2 minutes from several sensors spread through a house is transmitting data at a trickle compared to streaming video, audio, and even sending a moderate size word-processing file. At 900 MHz, RedLINK ™ has better wall penetration and range than Bluetooth or typical Wi-Fi, which use 2.4 GHz and higher frequency bands. Even if Wi-Fi were unreliable in our house, I would expect RedLINK ™ to be solid.

Interference on the 900 MHz band

But the 900 MHz band is crowded. To begin, it’s designated for scientific, industrial, and medical device connectivity. Some cell phone and walkie-talkie type communications use it. Wireless telephone handsets often use the 900 MHz band. Amateur radio hobbyists also are permitted to use 900 MHz band signals. Consequently, in a residence, several devices might attempt to send a signal at the same frequency within the band at the same time. Colliding signals garble the message. This shows up as interference, which could be a big problem.

Frequency hopping

RedLINK ™, like Bluetooth, and the actress Hedy Lamar’s torpedo guidance system, has another trick: frequency hopping.

The military began to develop frequency hopping before WWI to protect battlefield radio messaging. By switching frequencies quickly in unison, the signal from transmitter to receiver never lingers long enough at a given frequency to degrade the overall message.

In addition, modern communication systems divide data into small chunks called packets that can be checked for consistency and resent if necessary. The combination of packet data and frequency hopping practically eliminates interference at low data volumes.

Canada geese
Canada geese sound a little like hopping frequencies

Changing frequencies also discourages interception and listening in on messages, but, unfortunately, the technology to follow most frequency hopping schemes is freely available now, so hopping is weak security, but it does effectively squelch interference on crowded bands.

Power consumption

The 900 MHz band consumes less power than higher frequency transmissions and batteries last longer. Since I don’t relish crawling into odd corners to change batteries on remote sensors, battery life is more important to me for IoT than other applications.

Proprietary protocol

A proprietary network protocol like RedLINK™ installs more easily and reliably than Wi-Fi for HVAC, but it tends to lock consumers into a single vendor. A version of the public Wi-Fi standard designed for low volume data transmission, called Wi-Fi HaLow, exists. But I haven’t found any HaLow equipment on the market.

Hacking RedLINK ™ could be devastating, essentially allowing a malicious invader to take over our heating system, making our lives uncomfortable, possibly wrecking our heating system, or setting our house on fire. I have no doubt that a diligent enough hacker could gain entrance to a RedLINK ™ network, but it would require detailed knowledge of a proprietary system, which would require a lot of effort for a low money skill.

A sigh of relief

In fact, I breathed a sigh of relief when I found that our thermostat doesn’t use Wi-Fi to communicate with our furnace. I am far more concerned with hacking our Wi-Fi system than RedLINK ™.

Issues remain

Our smart thermostat is attractive and easy to use because it’s a small but powerful  computer. This has drawbacks. For example, I found instructions on the internet for running the video game Doom on a model similar to the thermostat in our dining room. I worked on an application twenty-five years ago to rid corporate networks of that very game.

It’s not as bad as it may appear, but rogue Doom installations bear some scrutiny, which I will do in a future post.  More important, I have not enabled or begun to explore the app that connects a smartphone or other computer to the thermostat. This is a subject for a future post and an area for caution.

Posted on

Election Tampering: Y2K Fears Redux?

For the last few days, I’ve been reading reports on the Trickbot takedown. U.S. Cyber Command and Microsoft have been hitting the large botnet, called Trickbot, that is controlled from eastern Europe, most likely Russia, and appears to have been maneuvering to interfere with the November 3rd U.S. election. The takedown steps apparently were planned strategically to give the botmasters little time to rebuild before the election. I sincerely hope the strategy succeeds. And I hope, and believe, that the Trickbot takedown is only the tip of an iceberg in a battle that is freezing out cyberattacks on our election.

We survived Y2K fears.

Trickbot

Trickbot, a botnet, is a multi-purpose covert criminal supercomputer cobbled together from thousands of hacked Windows computers. The botnet’s design offers few clues to hack victims that their devices are secret participants in criminal cyber attacks. The Trickbot crimes are mostly ransomware exploits for illegal profit. For some background on botnets see Home Network Setup: Smart Kitchen Crisis.

Y2K fears

The reports reminded me of Y2K fears, the year 2000 computer scare of 20 years ago. I hope those efforts are as successful as the Y2K remediation, which were so successful, Y2K was called a hoax by those who did not understand the computer industry.

Y2K and Bolivian basket weavers

I remember the Y2K affair well. It was no hoax. Everyone in the computing industry knew trouble was coming. Already in the early 1980s the issue was a hot topic among engineers. The problem went back to the early days of computing when data storage was expensive. It’s hard to believe today, but in the early days, the fastest and most reliable computer memory was hand-crafted by weavers from copper wire and tiny donut shaped ferrite magnets called cores. My meatware memory is not entirely reliable, but I remember hearing that Bolivian basket weavers were recruited to manufacture woven core memory. The computers on the Apollo moon mission were based on hard-wired ferrite cores.

Today, we talk about terabytes (trillions of bytes) but in those days, even a single K (1012 bytes) of memory cost thousands of dollars. I guess everyone today knows that a byte is eight bits, a sequence of eight 0s and 1s. Each donut magnet in core memory represented a single 0 or 1. The costing rule of thumb for handcrafted core memory was $1 a bit. At that price, a terabyte of memory would cost 8 trillion dollars, roughly the market price of 8 Amazons.

In the 1960s and 70s, programmers did not waste storage. They saved a few bytes by storing the year as two digits. 1913 was “13” and 1967 was “67.”

Most business programs used “binary coded decimal.” Storing the year as 2 digits instead of 4 was a savings of 8 bits: at near eight bucks a bit, close to $70 in 2020 dollars. Put another way, today, the price of those two 1970 bytes will buy 2 terabytes of flash memory, delivered to your door by Amazon. That flash memory would have cost 16 trillion dollars in 1970, filled several warehouses, and probably generated enough heat to warm New England for the winter.

Dates and the year 2000

Dates are used heavily in business computing, somewhat less in scientific computing. Accounting, scheduling, supply chain management all depend on date calculations. Today most of these calculations are handled in a few standard code libraries that are used over and over, but those libraries did not exist when the programs that ran the world’s business in 1999 were written. Each time a program needed a date calculation, a programmer wrote code.

Man, did they write code. Programmers delight in rolling their own, writing their own code. Coming up with an entirely original mundane date calculation will make a skilled coder’s heart sing. And there is joy in writing code that looks like it does one thing and does something quite different. These tastes decree that given an opportunity, coders will come up with many obscure and abstruse ways to calculate and analyze dates.

When I was hiring coders, I challenged candidates to describe an algorithm to determine the late fee on an invoice payment if 1% was to be added for each calendar month that had passed after the date the invoice was cut. If you think that description’s a little vague, you’re right. A hidden part of the challenge was for the coder to determine exactly what I had asked for. I don’t believe I ever got two identical solutions, and some would have behaved wildly if the calculations had crossed the Y2K boundary.

The industry took Y2K seriously

For good reason, in the late nineties, the industry got serious about the approaching crisis.

Y2K was a big deal. By 1995, I, along with many of my colleagues, had intentionally forgotten how to code in COBOL, the mainframe programming language of most 20th century business programs that were at the heart of Y2K issues. I won’t say that COBOL is a bad language, but few programmers cared for its wordy style. The scarcity of COBOL programmers elevated the language to a money skill in the last days of the century.

Y2K in my products

At that time, I was managing the development of a service desk product that I had designed several years before. I was coding almost exclusively in C++ on Unix and Windows, which uses an internal representation for dates and times that would not, in theory, have Y2K problems.

Nevertheless, management, who didn’t know that our product was theoretically immune to Y2K, declared my Fiscal Year 2000 bonus would depend on the absence of Y2K errors in our code. I smiled when I read the letter that described my bonus terms. Most years, fickle market conditions that I could not influence decided my bonus. This time, my bonus was in the bag due to a wise previous decision to build on a platform that sidestepped the central Y2K issue.

Still, I don’t mess around with my bonus. I started feeding Y2K use cases into our test plans, just to be sure.

I’m glad I did. Management, bless their bottom-line focused hearts, were right to worry about Y2K. It’s been a long time, but I estimate my team spotted and fixed a dozen significant Y2K defects that could have brought the product down or caused crippling errors.

Our defects were not COBOL style issues, but they stemmed from the two-digit year mindset that then pervaded business coding. For example, serial numbers often embed a two-digit year somewhere. A clever developer might use that fact and create a Y2K defect from it.

If those dozen defects had kicked in simultaneously on New Year’s Eve, service desks would have begun failing mid-Pacific in a pattern that would repeat itself as New Year’s Day followed the sun around the globe to Hawaii the next day. That was in a product running on platforms that were supposedly immune to Y2K errors. The devil in it was that a service desk would be used to manage the response to incidents that arose from other Y2K system crashes, compounding the chaos.

A real threat

People who are not responsible for building and maintaining computer systems probably don’t realize what happens when a raft of defects appear at the same time. Troubleshooting the origin of a malfunction caused by a single mistake can be difficult. With two mistakes, the problem becomes more complex and confusing. Each added source compounds the difficulty. At a certain point, the system seems to behave randomly, and you want to delete the whole thing and start over.

In the bad old days, we often saw large software projects break in dozens of places at once when we fired up them up for the first time. We used to call it “big bang” testing. Since writing code is more fun than testing code, many developers embraced the methodology and put off testing. But untested code is buggy code. Those big bangs were intractable messes of defects that could take weeks and months to untangle. We soon learned to test small units of code early and often, before mild-mannered projects became monsters.

As testing proceeded in development labs, engineers began to recognize that Y2K threatened to be a mass conflagration like those big bang debacles. Worse. Y2K bugs were everywhere. Their corruption extended to hundreds of systems. Unremediated Y2K threatened software mayhem like I have never seen and hope to never to see.

The reaction

Some engineers seized the limelight by overreacting. Doomsday prophets got wind of what was happening in development labs all over the globe. They went to the media with predictions of the imminent collapse of financial systems, communications, and power grids, which threatened to halt the economy and provoke the mother of all economic disasters. ATMs and traffic lights were about to go out of control. The preppers stockpiled guns, freeze-dried chili, and toilet paper enough to isolate for months.

Y2K at CA Technologies

I checked in to the CA Technologies (then Computer Associates) development lab in Kirkland on the Seattle east side early in the morning of December 31, 1999. As the senior technology manager in Seattle, I had orders to gather a team of developers and support people to man an emergency response hotline. The idea was that any Computer Associates customer with any Y2K problem could call the hotline and get expert help. Most engineers thought this was a transparent marketing ploy to take advantage of fears that had been whipped to a frenzy by the doomsday crowd.

Highly publicized orders were issued that development teams were on the hook until the last Y2K customer issue was resolved. The company supplied special Y2K tee-shirts. A buffet of sandwiches and periodic deliveries of pizza and other snacks were set up in a large conference room we called the board room. A closed-circuit television feed from headquarters in New York was beamed onto a then-rare wall-sized flat video screen. Rumor said champagne was scheduled to arrive at midnight.

The big letdown

I honestly can’t remember if the bubbly ever appeared. Late in the afternoon, I told all my crew they could leave if they wanted. I had to stay until midnight, but there was no reason to spoil their New Year’s celebration.

Why? On the Pacific Coast, we were among the last time zones to flip to 2000. In the morning, a customer called to headquarters in New York with a minor problem in Australia. It was fixed in minutes–mostly a user misunderstanding as I recall. The Kirkland team was not called on once. Typical developers, the crew loaded up on free sandwiches and pizza, took the loot to their cubicles and silently worked on code. A few salespeople wandered in to check on the action; there was none.

After all the buildup, why the big meh? Because humans aren’t stupid. The industry responded to the danger with testing and fixing. I’ve seen and believe estimates that upwards of $200 billion were spent on Y2K remediation in the 1990s. That was money well-spent. Consequently, Y2K came and went with barely a ripple.

The Y2K hoax

I take it back about humans not being stupid. We immediately began to hear about the Y2K hoax, a conspiracy and scare tactic for whatever purpose the speaker or writer found convenient. I’m sure the loudest criers of hoax were the same loudmouths who screamed computer Armageddon. I’d like to roll back the calendar and give the world a taste of what would have happened if Y2K had been ignored.

Actually, I wish Y2K had been ignored outside the industry and the people who understood the problem were allowed to quietly fix it without all the noise.

But that wouldn’t be right either. We were not heroes. The cost of the Y2K remediation was the price of poor judgement. Acting as if it did not occur would only encourage future bad choices. The remediation was nothing to be proud of. The industry should be called to account.

Nonetheless, in my dark moments, I have no patience for people who broadcast opinions but don’t carry water, put out fires, and make things work. Not everyone was fortunate enough to be in on the action of Y2K, not everyone has the training and experience to know what it takes to keep our computer-dependent society viable.

Y2K and the general election

Which brings us back to the Trickbot takedown. November 3rd 2020 has begun to smell to me like the approach of January 1st 2000. I see real danger and a dead serious response. I’m not an active member of the cybersecurity community, but I keep up. I have no doubt that criminals, extremists from every corner of the political spectrum, and foreign nation-states are planning cyber attacks to extort payments from election agencies, stop people from voting, slow vote tallies, and question results.

Election tampering hoax

But I also see the seriousness and competence of the efforts to prevent and neutralize these bad actors. Some signs point to success. Already, two weeks before the election, 29 million voters have voted, almost five times the number that had voted at this point in 2016. I’m sure election day will be tough, but I will not be the least surprised to hear another big meh on November 4, followed by cries of “election interference hoax!” from every direction, but from my vantage now, it’s clear it is no hoax.

But I hope it looks like a hoax.

Posted on

Home Network Setup: Smart Kitchen Crisis

You may call it a smart kitchen. I call it a home network setup disaster: four hackable Linux computers installed and configured by kitchen appliance designers who are, at best, inexperienced in computer security. And I am ashamed to admit I didn’t put them through a security audit before we chose them. We wanted a convenient and efficient kitchen; I knew full well that my security worries would not have a voice in any decision.

Home network setup
Cool cat in smart refrigerator

Last week, Rebecca and I went shopping for new kitchen appliances: a refrigerator, range, hood, and microwave. We are not much attracted by network-connected kitchen appliance features—I supposed we’re old-fashioned in our cooking habits—but the appliances we chose all have Wi-Fi.

We had no choice. Appliances that are not networked are scarce in 2020. You either accept that your kitchen will be networked, or you shop for used appliances. Since replacing one set of used appliances with another set of used appliances was not on our agenda, we have four Internet of Things (IoT) devices scheduled for delivery.

IoT device security

Now, I am forced to think seriously about securing the home network setup of our kitchen against cyber-attack. Forty years ago, when the industry began to hook computers together with TCP/IP and Ethernet, I would never have guessed that home kitchen security would become a topic in 2020.

Why am I worried? I am not as frantic as my well-known colleague, Bruce Schneier, who wrote a popular book about the Internet of Things called Click Here to Kill Everybody, but I share his concerns. Most IoT devices are full-fledged multi-purpose computers: as powerful, versatile, and hackable as the workstations of only a few years ago.

The computer in our new three-speed range hood is more powerful than the coveted Sun SPARC that sat on my desk at Boeing Computer Services in the 90s. The computer in that range hood is also subject to almost any hack reported in the news over the last decade. Ransomware has shown up on a coffeemaker, of all places.

IoT botnets

To top it off, some security professionals expect large IoT botnets will be used in attempts to disrupt the U.S. national election next month by scrambling voter registration or bringing down vote tallying software.

A botnet is a collection of compromised computers under the central control of a botmaster who orchestrates the hacked devices. Thus, botnets are huge covert supercomputers that execute crimes like sending out waves of spam or jamming websites with meaningless traffic. Before the IoT, criminal gangs grabbed control of personal computers and enrolled them in botnets by tricking users into fiddling with fake email or installing bogus doctored applications. It’s easier now.

IoT devices have simplified criminal botnet recruiting. Some of these devices are so poorly secured, criminals can scan the network for vulnerable targets, then take over using default accounts and pathetically weak default passwords. In this way, enormous IoT botnets can be formed quickly with automated scripts.

Users don’t notice that their IoT devices have been invaded because they seldom interact directly with the device. We might never notice that our sleek new smart refrigerator has become a robot thug at the beck and call of a foreign national in a dacha overlooking the Volga river.

The IoT is growing uncontrollably

Log on to your home network router and look at the list of connected devices. I imagine our list is longer than most because my home office is practically a development lab with an assortment of Windows 10 lap and desktops and a Linux tower I use as a server. Both Rebecca and I have two smart phones each (one for phone calls, another without a cellular card for fun), and we also have several tablets distributed in various rooms. We also have smart TVs, Amazon Fire Sticks, and Alexas.

Every time I look at the router’s device list, it has grown longer. What used to be a cute two-line list of his and hers computers has become a configuration management database worthy of a fair-sized business. In the old days, I could glance at the list and know instantly that some bright neighbor kid was filching bandwidth. Now, puzzling it out is a job in itself. When our new appliances are installed, I imagine making sense of the network will get more difficult.

Home network setup crisis

Frankly, I’ve reached a home network management crisis. I no longer feel in control. I’m not sure I will know if I’ve been hacked.

This must change.

Fortunately for me, I’ve helped large enterprises manage their networks for a long time. My quiver has some razor sharp arrows. I can figure this out. No three-speed range hood will bring down our network.

I’ll keep you posted. In the mean time, basic computer hygiene will have to do. Check it out the six rules. They go a long way toward keeping you safe.