By Lance Eliot, the AI Trends Insider 

Ransomware is being continually mentioned in the daily news and appears to be an unstoppable fiendish craze.   

Perhaps the recent attack of ransomware on the Colonial Pipeline received the most rapt attention since it led to concerns over gasoline shortages and caused quite a stir among the general public. When ransomware is used against a particular bank or hospital or school, this normally doesn’t have quite the same widespread disruption as did the fuel pipeline incident.  

The thing is, we are probably going to see a lot more ransomware being fielded and doing so against all manner of businesses and governmental entities. Some would assert that we are only so far at the tip of the iceberg when it comes to ransomware hacks.  

Part of the reason why you can expect more use of ransomware is that it is relatively easy for an evildoer to deploy the computer hacking scourge. Whereas the perpetrator used to need to have some keen computer skills, that’s not the case anymore. Sadly, ransomware programs can be cheaply purchased online via the so-called dark web, opening the floodgates to just about any determined villain.   

As a point of clarification, not every use of ransomware is successful. There are innumerable attempts that get rebuffed by cybersecurity protections or that are otherwise caught by alert computer security specialists. The rub is that the ransomware ploy only has to succeed one time. If a malicious hacker tries a hundred different attempts at various entities, and only one of those takes hold, the crook still wins. 

This is reminiscent of a popular catchphrase in the cybersecurity field: system protective measures need to be successful all of the time, while the intrusion approaches only needs to be successful one time.  

You may be aware that law enforcement authorities advise ransomware victims should refuse to pay any ransom. The logic is pretty straightforward. If ransoms are not paid, there won’t be any money or profiteering by those employing ransomware as a form of attack. Once the dough dries up, presumably the preference to use ransomware will accordingly evaporate.  

But some would contend that the ransomware attackers are not solely about the money. Some evildoers simply relish doing evil acts. Some like to get publicity and notoriety for what they have fiendishly accomplished. You could argue quite stridently that even if there was no payment at all, there are going to be those that will use ransomware anyway, joyfully seeing the resultant chaos.  

And, there is the possibility too of wanting to showcase computer hacker prowess. In essence, if a ransomware attack is successful regardless of gaining money, the person or group responsible has shown their hand or proffered their calling card. In theory, they could switch to other forms of cyberattacks and attempt to get money via other means, such as siphoning off funds from companies, and so on.  

Up until now, much of the ransomware attack has been done on a kind of Goldilocks basis. 

The notion is to go after entities that will be more inclined to pay the ransom. If there is a tremendous amount of public attention to a ransomware attack, this can stiffen the resolve by the entity to not pay the ransom. Meanwhile, if the ransomware attack is relatively unheralded and only the entity knows about it, this can allow for a quietly paid ransom that isn’t especially burdensome to the entity.  By carefully picking the intended targets, there is a bit of a sweet spot of entities that are bound to pay. 

If a criminal is going to launch a hundred different attempts (referred to as “spray and pray” or some suggest “spray and prey” is more applicable), they maximize the chances that ransomware shots-in-the-dark will be moneymakers. Avoiding the highly visible instances, such as a fuel pipeline, would generally make more sense in terms of increasing the probability of achieving the ransom. Once a high-profile target of ransomware gets outed as being infected, tremendous pressures are exerted to avoid paying the ransom, though this is somewhat counterbalanced by the outrage that ensues and the desperate need to rectify the ransomware attack at the soonest moment and in whatever manner might well do so.  

That’s why the paying of ransom by the newsworthy instances is especially telling and sends a signal of sorts to the ransomware fiends. A greed factor can enter into the picture. Rather than trolling after lots of quieter ransomware targets, maybe the big fish could be profitable. The problem for the ransomware attackers is that the notable instances also tend to draw more cybersecurity sheriffs to town, meaning that there will be a more determined and intense effort to find and bust the cyber hackers.  

Admittedly, many of the cyber hackers put little stock in getting caught, so this idea that a dangling sword hangs over their heads if they seek to disrupt a larger target is not something they typically give much credence. They are often self-assured in their belief that they cannot be tracked down. It is an ongoing cat and mouse game, for which the mouse does indeed at times get caught, though it might think it won’t.  

I wish it weren’t so, but the reality is that eventually, you can expect that AI-based true self-driving cars will be disrupted by the ransomware blight. Those exciting and state-of-the-art self-driving or driverless cars that we are hoping will someday be cruising all of our highways and byways are going to, lamentably, get in the gun sights of ransomware.  

Yikes!

Before I share some cybersecurity insights on topic, allow me a moment to bring up some related points.  

Whenever I write about cyber-security, there are some that right away complain that by doing so, the indications proffered are allowing cyber-hackers to gauge what kinds of cyber protections are being devised and what kinds of cyber vulnerabilities exist. 

The worry is that writing about these topics helps the cyber-hackers, arming them accordingly.  

Please realize that this is the now-classic head-in-the-sand posturing regarding discussing cybersecurity and related matters. Some believe that we should not talk about, nor write about, and not in any manner even whisper the nature and avenues of cybersecurity and cyber-hacking, since it tips a hand to the evildoers.  

This is a misguided notion, though one can certainly sympathize with their logic.  

Here’s the conundrum. It is plainly the case that cyber-hackers are going to figure out these same facets, one way or another, and by trying to hide such discussions it does little good. It tends to undercut the preparations for and awareness about cyber-hacking. 

A head in the sand translates into getting kicked in the rear, as the old saying goes.  

Meanwhile, there is another reason to not discuss such matters: that doing so will cause mass hysteria. Again, the logic for this is certainly understandable. When those writing about cybersecurity and cyber-hacking do so irresponsibly, attempting merely to fan the flames of angst, there is no question that such efforts are sad, hurtful, and do not advance sensibly the battle between cyber-security and cyber-hacking. 

With that crucial contextual indication, let’s next take a serious look at what ransomware is about. After doing so, we can explore how ransomware will be used against AI-based self-driving cars. 

For my framework about AI autonomous cars, see the link here: https://aitrends.com/ai-insider/framework-ai-self-driving-driverless-cars-big-picture/  

Why this is a moonshot effort, see my explanation here: https://aitrends.com/ai-insider/self-driving-car-mother-ai-projects-moonshot/  

For more about the levels as a type of Richter scale, see my discussion here: https://aitrends.com/ai-insider/richter-scale-levels-self-driving-cars/  

For the argument about bifurcating the levels, see my explanation here: https://aitrends.com/ai-insider/reframing-ai-levels-for-self-driving-cars-bifurcation-of-autonomy/  

Ransomware And Assorted Details  

The term “ransomware” comes from a mash-up of the words ransom and malware and denotes a circumstance wherein a computer malware (a type of computer virus) is used to infect a computer so that the extorter can then try to extort something from the victim.  

As you will shortly see, it is sometimes also called “scareware,” since it tries to scare the victim into paying a ransom. Sometimes the ransomware is more puffery than harmful, but it tries to scare a business into paying, either because the business does not realize that the ransomware really hasn’t done much but they fear that it has, or the business wants to keep hidden that it got attacked and so is willing to pay hush money.   

Unlike the more commonly known destructive computer viruses that we all dread and hate, a ransomware infection is not particularly used for destructive purposes as much as it is used for obstructive purposes. Obstructions include making various business files and data unusable (but with the chance of turning them back into being usable) or obstructing access to a series or a set of computer systems. 

Ransomware will typically undertake one of two approaches. Either it will try to lock up the computers being infected and take them hostage from access by the business or entity, or the ransomware will try to encrypt the data on the computer system and take the data hostage so that even if accessed by the business or entity it will be unusable (essentially scrambled and for which only a special key will unscramble the mess).  

Usually, trying to lock up the computer is not going to be very effective and can be more readily overcome by cybersecurity specialists. Indeed, the lock-up attack is usually more scare than serious per se, and it is an attempt to intimidate those that rely upon that computer. The hope by the extortionist is that the entity will get frightened and then be amenable to paying a ransom as a preventive measure and avoid suffering additional attacks.  

Often, in lieu of the lock-up attack, the other form of ransomware attack involves encrypting the data that resides on the computer systems. The ransomware program usually uses a relatively standardized form of encryption to encode the data, and the key that could decode the encoded data is presumably known only by the extorter. A ransom is then sought to purchase the key that will decode the data. 

Notice that the extortionist is usually not “stealing” the data per se, and instead is just locking it up. Stealing the data would involve “taking it” (or, perhaps more like copying it), which either involves making a copy and then threatening to release it or distribute it or making a copy and then deleting the data from the original location so that you then no longer have that data available. The extorter could certainly seek to steal the data, but more often they just lock it in place.  

You might wonder why the extorter would not always want to steal it. 

One reason is that trying to copy the data would usually involve pulling lots of data across a computer network and this could take a lot of time, increasing the chances of the infecting program getting detected and stopped, and it could also reveal the infecting program by detection mechanisms that would realize the computers are sending out a huge chunk of data.  

Do not though be misled into thinking that ransomware cannot be destructive. It can be.  

Sometimes the ransomware deletes some of the files and data, perhaps inadvertently at times, or even intended as a show of strength by the extorter to impress the victim about what power the extorter has over the situation. You might think of this as a variant of kidnapping and the extorter decides to harm the kidnapped hostage by wounding the leg to prove they are willing to play rough. 

The extorter might even provide a snippet of the data to you, doing so to prove that they have it or can unlock it, which might be analogous to say taking a picture of a kidnapped victim while holding today’s newspaper, essentially proving that they have the hostage currently in their possession and for pressuring to get a ransom.  

You might be puzzled as to why anti-virus software doesn’t right away detect ransomware and stop it cold before it can take hold.  

Some anti-virus software packages don’t look extensively to find ransomware. Some ransomware is so well hidden or masked that anti-virus fails to detect it. In fact, ransomware programs are continually being updated and modified by the perpetrators so that the anti-virus community has a hard time keeping up with the ransomware signature hide-and-seek. (There is a field of study known as cryptovirology that focuses on computer viruses.)  

And many organizations are ill-prepared for ransomware. As the old saying goes, an ounce of prevention is worth a pound of cure. If you get your business in shape to prevent becoming a victim of ransomware, you can save a ton of headaches and potential loss of company money, data, and reputation.  

Most businesses sadly won’t undertake the right precautions upfront, and only after the fact will they devote the needed resources toward computer security that can reduce their chances of a ransomware infection. It is like earthquakes and not doing anything to prepare for one, but after one hits and causes damage and havoc that only then will precaution be put in place for the next earthquake that comes along. 

Of course, at that point, the horse was already let out of the barn. 

The ransom demand by the extorter will usually start high. They shoot for the moon as a negotiating tactic, knowing that they will likely settle for a lot less. 

To push along the negotiations, most extorters will provide a time limit. They will say that if you don’t pay within 48 hours that they will never provide you the key. Or, they might say that after 24 hours the price doubles for each of the next 12 hours. Similar to what you have seen in movies and TV shows, this is old-fashioned extortion at this point. The digital part of it is the new twist in terms of taking a hostage, but the rest of it is the same sort of blackmail tactics that have plagued mankind forever.   

Of course, even if the extorter says they will provide the key when paid for, you have no assurance that they will ever provide the key. Some firms have made a payment that the extorter assured would get them the key, and then the extorter made a second demand saying that they now wanted more money. 

Suppose you do get the key? This does not guarantee that you can fully decrypt your data and nor that all of your data is still there.  

During the infection process, some of your data might have been deleted or changed by the infecting program, and so the key only decrypts some of your data or there isn’t even your data left to be decrypted. It is doubtful that the extortionist will provide you any guarantee that the key will work and that your data still exists (sometimes this provides a ploy for follow-up ransom demands, in a never-ending cycle).  

Overall, once you’ve been infected by ransomware, all bets are off as to whether you will be able to reclaim your data. The allure or illusion that the cyber hacker will enable you to do so is quite enchanting. This again is a tradeoff practice. Some ransomware attackers believe that if they don’t provide the proper key, subsequent entities that are attacked will realize that paying the ransom is useless. As such, it might make sense to gain a reputation as a reasonable ransomware purveyor (a rather outlandish calling!), to try and increase the odds of getting paid ransoms later on.  

Let’s next shift our attention to how ransomware is going to adversely impact the advent of AI-based true self-driving cars. Keep in mind that self-driving cars are driven via an AI driving system. There isn’t a need for a human driver at the wheel, and nor is there a provision for a human to drive the vehicle.  

Here’s an intriguing question that is worth pondering: In what ways will ransomware be used against AI-based true self-driving cars and how can we all be prepared to try and avert such dastardly cyber threats?  

Before jumping into the details, I’d like to further clarify what is meant when referring to true self-driving cars.  

For why remote piloting or operating of self-driving cars is generally eschewed, see my explanation here: https://aitrends.com/ai-insider/remote-piloting-is-a-self-driving-car-crutch/  

To be wary of fake news about self-driving cars, see my tips here: https://aitrends.com/ai-insider/ai-fake-news-about-self-driving-cars/  

The ethical implications of AI driving systems are significant, see my indication here: https://aitrends.com/selfdrivingcars/ethically-ambiguous-self-driving-cars/  

Be aware of the pitfalls of normalization of deviance when it comes to self-driving cars, here’s my call to arms: https://aitrends.com/ai-insider/normalization-of-deviance-endangers-ai-self-driving-cars/  

Understanding The Levels Of Self-Driving Cars  

As a clarification, true self-driving cars are ones where the AI drives the car entirely on its own and there isn’t any human assistance during the driving task.  

These driverless vehicles are considered Level 4 and Level 5, while a car that requires a human driver to co-share the driving effort is usually considered at Level 2 or Level 3. The cars that co-share the driving task are described as being semi-autonomous, and typically contain a variety of automated add-on’s that are referred to as ADAS (Advanced Driver-Assistance Systems).  

There is not yet a true self-driving car at Level 5, which we don’t yet even know if this will be possible to achieve, and nor how long it will take to get there. 

Meanwhile, the Level 4 efforts are gradually trying to get some traction by undergoing very narrow and selective public roadway trials, though there is controversy over whether this testing should be allowed per se (we are all life-or-death guinea pigs in an experiment taking place on our highways and byways, some contend).  

Since semi-autonomous cars require a human driver, the adoption of those types of cars won’t be markedly different from driving conventional vehicles, so there’s not much new per se to cover about them on this topic (though, as you’ll see in a moment, the points next made are generally applicable). 

For semi-autonomous cars, it is important that the public needs to be forewarned about a disturbing aspect that’s been arising lately, namely that despite those human drivers that keep posting videos of themselves falling asleep at the wheel of a Level 2 or Level 3 car, we all need to avoid being misled into believing that the driver can take away their attention from the driving task while driving a semi-autonomous car. 

You are the responsible party for the driving actions of the vehicle, regardless of how much automation might be tossed into a Level 2 or Level 3.  

For more details about ODDs, see my indication at this link here: https://www.aitrends.com/ai-insider/amalgamating-of-operational-design-domains-odds-for-ai-self-driving-cars/ 

On the topic of off-road self-driving cars, here’s my details elicitation: https://www.aitrends.com/ai-insider/off-roading-as-a-challenging-use-case-for-ai-autonomous-cars/  

I’ve urged that there must be a Chief Safety Officer at self-driving carmakers, here’s the scoop: https://www.aitrends.com/ai-insider/chief-safety-officers-needed-in-ai-the-case-of-ai-self-driving-cars/  

Expect that lawsuits are going to gradually become a significant part of the self-driving car industry, see my explanatory details here: https://aitrends.com/selfdrivingcars/self-driving-car-lawsuits-bonanza-ahead/  

Self-Driving Cars And Ransomware  

For Level 4 and Level 5 true self-driving vehicles, there won’t be a human driver involved in the driving task. All occupants will be passengers; the AI is doing the driving.  

One aspect to immediately discuss entails the fact that the AI involved in today’s AI driving systems is not sentient. In other words, the AI is altogether a collective of computer-based programming and algorithms, and most assuredly not able to reason in the same manner that humans can.  

Why this added emphasis about the AI not being sentient?  

Because I want to underscore that when discussing the role of the AI driving system, I am not ascribing human qualities to the AI. Please be aware that there is an ongoing and dangerous tendency these days to anthropomorphize AI. In essence, people are assigning human-like sentience to today’s AI, despite the undeniable and inarguable fact that no such AI exists as yet.  

With that clarification, you can envision that the AI driving system won’t natively somehow “know” about the facets of driving. Driving and all that it entails will need to be programmed as part of the hardware and software of the self-driving car.  

Let’s dive into the myriad of aspects that come to play on this topic. 

The two primary cybersecurity threat vectors underpinning AI-based true self-driving cars consist of the onboard computer systems and the cloud. The onboard computers are within the autonomous vehicle and provide the computing resources needed to run or perform the AI driving system software. Outside the self-driving car and connected remotely would be various cloud-oriented computing systems that are allied to the operational aspects for making active use of a self-driving car.  

From a cloud perspective, self-driving cars will likely be connecting with a cloud-based service for purposes of scheduling and the dispatch for providing rides.  

It is generally assumed that most self-driving cars will be used on ridesharing or ride-hailing basis. This does not necessarily have to be the case, though it does make sense. If you individually owned a self-driving car, you might be tempted to have it make money for you while you are at work or home sleeping at night. Rather than sitting idly parked in your driveway, you could list the autonomous vehicle on a ridesharing network and it would go back and forth providing money-making rides for you.  

The same can be said for fleet operators that decide to make use of self-driving cars for large-scale ridesharing activities. Some argue that only fleet operators will own self-driving cars and there won’t be any individual ownership taking place. I disagree. My viewpoint is that there will indeed be individual ownership, along with large fleets too (see my column for in-depth debates on this matter). 

In any case, for a self-driving car to be used on a ride-hailing basis means that there have to be some means for the AI driving system to become informed about where to pick up a ride and where to drop off a ride. This is likely going to be done via electronically connecting to a ridesharing network. 

Another use of the cloud entails employing an OTA (Over-The-Air) electronic communications capability for self-driving cars.  

When software updates are needed for the AI driving system, the OTA can be utilized to download and then install the patches from the cloud. In addition, the self-driving car can upload data into the cloud via the OTA. For example, there will be data uploaded that has been temporarily stored onboard the vehicle such as recently captured video camera data, radar data, LIDAR data, and so on. The type of cloud being used for this purpose is sometimes referred to as a DevOps cloud, a mashup of the development efforts for the self-driving car and the operational aspects.  

With those background setting indications, we can consider the highest vulnerability exposures for ransomware attacks.  

Ransomware in the Scheduling/Dispatch Cloud  

A ransomware attack might be focused on the scheduling/dispatch cloud. Envision that the ransomware has locked up the data underpinning the scheduling and dispatching of self-driving cars. Pretend that the data is scrambled and essentially unusable. 

This suggests that this particular cloud will no longer have viable data accessible about the registered riders that are using the ridesharing network. Nor will the data about which self-driving cars are registered be available. The locations of the self-driving cars would no longer be readily ascertained due to the data about their geographic positions being unreadable. And so on. 

In short, the ability to schedule and dispatch self-driving cars is pretty much frozen.  

Keep in mind that none of the self-driving cars are directly affected. The ransomware has not touched the AI driving systems. The self-driving cars could presumably still be driving around just fine. Of course, the question arises as to where they are going, since they would no longer be actively able to use the scheduling/dispatching cloud for purposes of getting assigned rides.

In theory, passengers could directly tell the AI driving system where to go. If a self-driving car is being used for ridesharing, perhaps the AI driving system would proceed as requested by a passenger and merely record that a ride was provided (which later on would be uploaded for purposes of charging the rider for the ride). On the other hand, if the scheduling/dispatch cloud isn’t able to confirm taking on the ride, the AI driving system might simply emit a message to the passenger that the cloud system is currently unavailable and therefore no further rides will be allowed (until the scheduling/dispatch cloud becomes properly available once again).  

This use of ransomware would disrupt the ridesharing use of whatever set of self-driving cars are listed on this particular cloud-based ridesharing network. The money possibly lost due to the self-driving cars being idle and awaiting ride assignments could be relatively significant. But this is not likely an especially onerous use of ransomware, since it could be that the self-driving cars might relatively readily be switched over to another clean cloud and continue working while the ransomware inflicted cloud is rectified. 

Ransomware in the DevOps Cloud 

A ransomware attack might be focused on the DevOps cloud. Envision that the ransomware has locked up the data and some of the source code underpinning the development and operations aspects of self-driving cars. Pretend that the data is scrambled and essentially unusable.  

This means that any pending patches or software fixes that were supposed to be downloaded into the self-driving cars are no longer readily available. Likewise, the data being collected onboard the self-driving car such as video camera data, radar data, LIDAR data, and the like is not able to be uploaded at that time.  

If there were pending patches that were urgently needed for ensuring the ongoing safety and use of self-driving cars, this disruption could be significant. It could undermine the safety of self-driving cars. 

The odds though are that the existing software that was already installed is doing fine and the patches are more akin to improvements or minor corrections, and otherwise, the self-driving cars are okay while waiting eventually to get the fixes. This is logically the case much of the time, especially since doing the OTA updates is a matter usually done after-hours and when the self-driving cars are not otherwise actively booked for rides.  

In terms of being blocked from uploading data that is onboard the self-driving cars, it could be that the data can sit onboard for a while. Usually, self-driving cars are equipped with sufficient disk storage to keep on-hand the data, doing so until a convenient time arises to use the OTA for uploading purposes. One supposes that this could eventually be exceeded as to the amount of onboard disk storage, which would suggest that some data might be “lost” due to not being able to either store it locally nor upload it to the cloud.  

Generally, none of this would stop self-driving cars from continuing to drive. The odds are that this use of ransomware would have a greater scare tactic effect than actually undercutting the use of self-driving cars.  

That being said, if the DevOps cloud is the only place that the developers are storing the source code and patches (yikes!), they are in for a lot of trouble and would be unable to appropriately maintain the AI driving systems. That would be more than a scare, that’s for sure. As well, if the uploaded data is being monetized, this use of ransomware could surely cut into the money-making use of that data.  

Ransomware in the Onboard AI Driving System 

This is the most chilling portrayal of self-driving cars, consisting of the ransomware somehow attacking the onboard AI driving systems. Presumably, this would render the impacted self-driving cars useless, and they would become no more than a hefty doorstop or multi-ton paperweight.  

One would hope that at least the AI driving system was able to get the vehicle into what is known as a Minimal Risk Condition (MRC) posture before the ransomware took hold. The MRC is usually associated with coming to a safe stop and doing so in a manner and place that is considered relatively prudent.  

This type of ransomware would certainly be the most worrisome and the height of danger for these scenarios. Note that ransomware is not trying to take over the control of the AI driving systems. It is just locking up the AI driving system, which of course is still a bad thing, for sure. Worryingly, there are other kinds of computer viruses that are being targeted toward taking over the driving controls (see my discussions about this in my columns on cybersecurity and self-driving cars).  

Conclusion  

You might be wondering why there haven’t been significant ransomware attacks against self-driving cars already. 

First, we don’t know that there haven’t been. Would an automaker or self-driving tech firm want the world to know about it? Likely not. Also, there are undoubtedly lots of ongoing attempts to use ransomware attacks, which have been variously mentioned or rumored among those in the cybersecurity and self-driving cars arena. There are ongoing debates taking place about whether the makers and operators of self-driving cars will be required by regulation or law to report cybersecurity intrusions, including the use of ransomware (see my column coverage).  

The other somewhat obvious aspect is that self-driving cars are not yet pervasive. You could argue that the money to be made from ransomware at this time in this market space is too little. Only once self-driving cars become more pronounced would it seem they are a worthy target for the fiends that exploit ransomware uses. 

Bottom-line is that the automakers and self-driving tech firms need to be on their toes. The silence that they might hear right now from the ransomware striking thugs is not to be taken as a sign that self-driving cars are not on the hit list. Self-driving cars assuredly are. 

Make a serious-minded note right now, avoid ever getting a ransom note by making sure that your systems are ransomware resilient or impervious. Those are words to live by.  

Copyright 2021 Dr. Lance Eliot   

[Ed. Note: For reader’s interested in Dr. Eliot’s ongoing business analyses about the advent of self-driving cars, see his online Forbes column: https://forbes.com/sites/lanceeliot/] 

http://ai-selfdriving-cars.libsyn.com/website 

PlatoAi. Web3 Reimagined. Data Inteligence Amplifed.
Click here for Free Trial.
Source: https://www.aitrends.com/ai-insider/ransomware-cyberattacks-are-heading-toward-ai-autonomous-cars/