00:02 Introduction
02:12 Cybercrime on the rise
05:59 Competitive landscape
10:41 The story so far
13:00 9 circles of hell
14:50 Threat model (concepts 1/3)
20:54 Attack surface (concepts 2/3)
25:14 Black radius (concepts 3/3)
30:48 Unsafe hardware (sins 1/3)
38:05 Unsafe software (sins 2/3)
43:42 Supply chain attacks (sins 3/3)
49:22 Common wisdom (virtues 1/3)
57:23 Security inversion (virtues 2/3)
01:03:28 (In)Secure by design (virtues 3/3)
01:09:56 Conclusion
01:12:10 Upcoming lecture and audience questions
Description
Cybercrime is on the rise. Ransomware is a booming business. Due to their physically distributed nature, supply chains are particularly exposed. Moreover, ambient complexity is a fertile ground for computer security woes. Computer security is counterintuitive by design, because it’s precisely the angle adopted by attackers to find and exploit breaches. Depending on the flavors of numerical recipes involved in the supply chain optimization, the risk can be increased or decreased.
Full transcript
Welcome to this series of supply chain lectures. I’m Joannes Vermorel, and today I will be presenting “Cybersecurity for Supply Chain.” Modern supply chains are extensively driven by software and increasingly so every passing day. While software comes with great benefits, such as higher productivity or higher reactivity, it also comes with severe drawbacks. Among those drawbacks is computer security, which is its own entire class of problems and can prove to be exceedingly costly. However, for supply chain, there is no going back to a pre-software era; it is not possible anymore to operate profitably a large-scale supply chain without software. Thus, computer security needs to be addressed frontally.
The first goal for this lecture will be to understand the extent and the magnitude of the computer security challenge, particularly from a supply chain perspective, to understand what it takes to secure a modern supply chain. The second goal for this lecture will be to understand what makes computer security so unique and challenging, because it is deeply counter-intuitive. In particular, from a supply chain perspective, we want to understand what makes the insights that are applicable to computer security so adverse to the common wisdom that is prevalent in most supply chain circles.
Cybercrime has been on the rise for over a decade. The FBI provides very interesting statistics about cybercrime. Last year, the reported losses in the USA for cybercrime amounted to over 4 billion dollars. These numbers probably underestimate the extent of the problem, as companies, for various reasons, are likely to under-report the problems. First, we have the small-scale incidents, which are particularly hard to assess and quantify. For example, if you lose half a day of warehouse operation in one warehouse because of a minor computer security breach, this is hardly the type of incident that is going to warrant an actual report and damage claim, although there was some real damage.
On the other hand, large-scale incidents tend to be under-reported by large companies, if only to avoid causing a market panic if the company happens to be publicly traded. Thus, large incidents tend to be minimized. However, the most important and interesting figures from these reports are the annual growth of the reported losses, which is at roughly 30 percent. The FBI shows that these numbers have been very stable over the last five years. My personal take on this is that this growth is very likely to remain stable in terms of the growing trend for the decade to come. Indeed, the importance of software is still steadily growing, and our modern economy is still becoming even more dependent on software. Thus, I suspect that this trend will keep growing for something like a decade before reaching a plateau.
Now, cybercrime is big and getting bigger; however, it is not the end of the world, especially when we compare it to the magnitude of other problems. For example, if we assume one decade of steady 30 percent annual growth, cybercrime in terms of reported losses would reach something like 50 billion dollars annually in the USA. This would make the scale of this problem about one-third of the illegal drug market. So, while cybercrime is a big problem, it is not exactly an apocalypse-level sort of problem, especially when we compare this figure to the GDP of the USA. Nevertheless, it is a problem that is becoming serious enough to warrant very dedicated attention, especially since most of the cost is borne by the actors who are paying the least attention. This cost is not evenly distributed, and my take is that supply chains, being particularly exposed, are bearing a larger portion of this cost than the rest of the economy. In this portion, the companies who are paying the least attention are actually supporting the bulk of the cost.
In order to create a computer security problem, you can compromise machines, people, or a mixture of machines and people. The techniques that take advantage of people are technically known as social engineering techniques, which can be incredibly efficient at taking advantage of computer security problems. However, social engineering would deserve a lecture of its own, and today the goal of this lecture is to focus on the computer part of the problem. Supply chains are very exposed, pretty much by design. First, supply chains involve many machines. Second, supply chains consist of geographically distributed operations. Third, by design, the machines in supply chains are incredibly interconnected and interdependent. Lastly, many people are involved in supply chains, which means that the applicative landscape is very complex. Where there is complexity, there is also fragility in terms of computer security. In total, supply chains have all the ingredients to be prime targets for computer security problems.
If it wasn’t complicated enough, I would like to immediately point out that computer security is typically conflicting with other types of security, and thus improving the situation on the computer security front may actually create other types of security problems. To illustrate this aspect, which might be quite counter-intuitive, let’s have a look at the case of a data lake. If you introduce a data lake in which you gather all your supply chain data, you create a single point of failure. If there is a breach in this data lake and an intruder can compromise it, then this one attacker will be able to exfiltrate all the data at once. This is something that comes by design with the very notion of a data lake, and there is no workaround.
However, a data lake also has its advantages. If we don’t have a data lake, the company is exposed to another class of problems. Most corporate frauds rely on the fact that, typically in a large organization, the right hand doesn’t know what the left hand is doing, and this lack of communication and synchronization within the company can be used to commit various types of fraud. One way to mitigate these problems consists of putting all the data together so that such frauds become much more evident, just because all the pieces have been put together. In this regard, having a data lake can be a great way to mitigate all sorts of fraud that would otherwise go unnoticed just because the data cannot be reconciled. Thus, we can see that having a data lake creates a computer security problem, but it is also part of the solution to avoid various types of fraud that can be very costly for the company.
We see here that computer security is all about trade-offs, not only between the costs involved with the security mechanisms but also trade-offs with other kinds of security that go beyond the specific scope of computer security.
This lecture is the seventh lecture of this fourth chapter about supply chain, and this fourth chapter is dedicated to the auxiliary sciences of supply chain. Auxiliary sciences represent topics that are not exactly supply chain but are fundamental to a modern practice of supply chain.
Since we started this fourth chapter, we have been going up the ladder of abstraction. We started with the physics of computing and then moved toward software with the most basic element of software, namely algorithms. We then went into two specific types of fairly elaborate algorithms, mathematical optimization and machine learning, which are of key interest for supply chain. In particular, we have seen that both mathematical optimization and machine learning prove to be driven by programming paradigms. Thus, we did a detour through the lecture on languages and compilers, which is probably one of the most under-appreciated topics in supply chain circles as far as computer knowledge goes.
In the last lecture, we delved into software engineering, focusing on leaving the machines behind for a while and focusing on the people who create the software needed to run a supply chain in the first place. Today, after focusing on what it takes to create the software needed by your supply chain to operate, we are going to focus on what it takes to destroy and disable this very software that should make your supply chain operate.
The rest of this lecture will be divided into three blocks. First, we will review three key concepts that are of interest to even apprehend computer security. While computer security is deeply counter-intuitive, it doesn’t mean that it is impervious to rationality and logical analysis. Second, we will analyze and list a series of very common root causes behind many, if not most, computer security problems nowadays. In particular, we’ll see that it’s difficult not to feel overwhelmed considering the sheer scope of the root causes for computer security problems. Lastly, we will have a look at what can be done to, at the very least, mitigate computer security risks. We will see that most of the knowledge to be found on the positive side, or the side of what can be done, is of the type of negative knowledge, emphasizing what is to be avoided rather than what should be done. I will try to cover all these topics from a supply chain perspective; however, there are many aspects that are not incredibly supply chain-specific as far as computer security is concerned.
In order to think about a solution, we need to first clarify the problem that we are trying to solve in the first place. This is the exact line of thinking that I had for the third chapter of this series, which is dedicated to supply chain personnel. Indeed, supply chain personnel try to crystallize the very problems that we are trying to solve, and in computer security, there is a loose equivalent in the form of the threat model. The threat model is literally a tool to crystallize the sort of problem that we are trying to fix security-wise. Computer security is fairly elusive, vague, and diverse; it is very difficult to reason about computer security. When having a discussion about security, it is very difficult not to suffer the problem of moving goalposts through the discussion, even if the people who are taking part in the discussion are doing so in good faith.
For example, if we are discussing the threat of having a password made public by an employee, which is easier than it seems even if the employee is not wrong, the discussion should not deviate to other types of threats, such as having weak or common passwords. Thinking clearly about a threat is essential in computer security because a poorly conceived remediation to a given problem tends to be worse than the original problem. If a company were to decide that, in order to limit the problem of exposed passwords, they would proceed with disciplinary actions taken against employees found guilty of disclosing their passwords, this approach would most likely severely backfire. Instead of seeking support, employees would start concealing the problems they face with their passwords, making the issue worse in the long run.
The interesting thing about threat models is that they force you to choose your battles, to choose the threats you are going to address and the ones that you are not going to address, even if the threat is real. For example, consider the following threat: what about a rogue employee with high-privilege access to the data lake? What would happen if this person were to exfiltrate data, leveraging their high privileges? This is a threat, but do you decide to combat this specific threat or not? You have limited resources and limited time. Addressing this very specific threat can prove to be incredibly costly, and thus, threat modeling also helps you decide that, at some point, there are some threats that are just too costly to address. Your resources and time would be better spent addressing other types of threats, which can be as threatening but much cheaper and easier to address.
In this regard, beware of analogies. The sort of threats that you face in computer security are completely unlike the sort of threats that you face in terms of industrial risk or physical risk. Computer security involves adversaries – people who can think and adapt their actions to your practices and policies. For example, if you have well-documented security processes, an attacker could take advantage of this existing documentation to identify your blind spots. My point is not that you should not have any documentation regarding security; my point is that when it comes to computer security, adversaries are smart and can take advantage of whatever you give them, even if it’s your own security processes. Thus, threat modeling really helps to start thinking about these sorts of problems.
In the physical world, the attack surface is something relatively obvious. If we were to think about a medieval castle, the attack surface would be the walls and the drawbridge. However, in the computer world, the situation is much more complex. In terms of computer security, seemingly insignificant elements can potentially be attacked. One key intuition about attack surfaces is that they are always greater than you think.
A real-world example of this is the OMG cable, which looks like a completely regular USB cable but comes with a microcomputer inside that could compromise any computer by simply plugging the cable in. This inexpensive piece of hardware can be purchased for just $139, demonstrating how accessible these attack surfaces can be.
In terms of attack surfaces, every single piece of hardware and software has its own attack surface, no matter how seemingly insignificant. Furthermore, in the specific case of supply chain, it is very difficult to even identify all the attack surfaces. Shadow IT, which is prevalent in the world of supply chain, and employee-owned devices (bring your own device patterns) are additional entry points for an attacker into your supply chain. It’s not just what is managed by the IT team, but also all the things that are not managed by your IT team but happen to contribute, one way or another, to the operations of your supply chain.
The idea about the attack surface is to clarify what can be attacked, not focusing on how the attack can be performed. Conceptually, the interesting thing about the idea of attack surface is that it forces you to create some kind of mapping of all the elements that can be compromised one way or another. From a specific supply chain perspective, any kind of software with programmable capabilities, such as Excel spreadsheets or Python scripts, comes with an absolutely massive attack surface if the programmability or extensive compatibility is done with a generic programming language. Thus, as far as supply chain is concerned, and considering the amount of configuration that is going on, the attack surface is typically quite massive.
Now, as a third concept, we have the blast radius, which is a way to measure the total potential impact of a security event. When you start thinking in terms of blast radius, you don’t ask yourself if this event is going to happen; you just start thinking, “When it does happen, what will be the actual blast radius of the problem?” The idea is that you try to think about the consequences, regardless of the remediation measures in place. If and when this event happens, what will be the impact?
If we go back to the castle analogy, the blast radius in the world of computers can be incredibly large. For example, in the case of the Colonial Pipeline attack, the compromised system was just a tiny part of the system, merely the billing system. The actual blast radius of having the billing system of a single company compromised affected the entire state of Texas. This gives you an idea of the actual blast radius of computer security problems when you start thinking about supply chains.
With the advent of cloud computing, blast radii have expanded enormously. While cloud computing is extremely competitive as a business model and an IT operational model, it comes with massive blast radii. If an attacker gains administrative control over your cloud computing resources, they can undo your entire application landscape at once, creating a single point of failure with far-reaching consequences. The fact that you are moving apps to the cloud tends to exacerbate the problem of interconnectedness, which leads to larger blast radii.
When you move apps to the cloud, you gain ease in interconnecting them with other apps in the cloud, which has real business benefits. However, in terms of blast radii, you are creating massive interdependencies that can be leveraged by an attacker to generate a blast radius of staggering size.
In terms of supply chain, thinking about the blast radius is a good way to think about ways to mitigate those blast radii. If we go back to another supply chain example, let’s consider that, as I was describing in the previous lecture, we have two types of software elements in supply chain management. We have the transactional elements, which are essentially the supply chain management itself, such as keeping track of stock levels. Then, we have the analytical elements, which involve supply chain optimization, including forecasting, planning, and various statistical analyses of the data.
If we decide to keep all the software elements of an analytical nature strictly isolated from production, so that the analytics part of your application landscape can read the data from the transactional systems but never write anything into those systems, it means that when the analytical systems are compromised, the blast radius will be contained to the analytical part of your application landscape. More bluntly, if your forecasting software is compromised, it doesn’t compromise the piece of software that is keeping track of your stock levels.
Now, let’s review the root causes and sources of computer security issues. Hardware-wise, the state of affairs is absolutely terrible. In short, the barrel is leaking all over the place, and the entire community keeps applying duct tape to hastily fix the problems that are constantly emerging. Nearly everything hardware-wise is broken nowadays.
For example, all modern CPUs are pretty much broken. In 2018, a team of security researchers unveiled two new classes of vulnerabilities in modern CPUs named Spectre and Meltdown. These vulnerabilities take advantage of the branch prediction capabilities found in modern CPUs. As you may recall from the lecture on modern computing for supply chain, we have seen that modern CPUs have very deep execution pipelines, and one way to achieve high performance is through branch prediction. It turns out that this branch prediction mechanism, which is found in every modern CPU on the market, can be exploited to breach security boundaries. This situation is difficult to solve because it is a fundamental design flaw associated with having branch prediction in CPUs in the first place.
CPUs have tons of problems, and I’m not even mentioning those with accidental backdoors due to legacy support. But it turns out that memories are also broken. There is a class of attacks called Rowhammer attacks that take advantage of the physical layout of modern memory cells found in high-density modern DRAM. It is possible to trigger memory errors and exploit those errors to exfiltrate data from machines. There is no real workaround, even if you have ECC DRAM (Error Correction Code), which is the type of memory typically found in production-grade data center machines. ECC only slows down Rowhammer attacks; it cannot prevent them. All it takes to carry out a Rowhammer attack is to get the machine to execute a web page with JavaScript enabled on this webpage, and then you can directly exfiltrate data from the memory of the machine. Not only are CPUs and memory broken, but USB is broken as well. When it comes to USB, it is safe to assume that any USB device you connect to your own device can compromise the connected device. We did see an example with the “Oh My God” cable in a previous slide, but fundamentally, the problem runs very deep. The root cause is essentially very bad decisions that were made decades ago about USB, especially when it comes to plug-and-play.
From a user experience perspective, it is great that when you plug a device into your computer, it can just run out of the box. However, what is happening under the hood is that there is tons of intelligence inside the USB controller to auto-import drivers and auto-enable all sorts of features that can be used as entry points for an attacker to take control of your machine. Thus, all those plug-and-play features are very nice from a user experience perspective, but they are a complete nightmare from a cybersecurity perspective.
By the way, many, if not most, Wi-Fi chipsets also have terrible security flaws. Researchers in 2017 showed that chipsets produced by Broadcom, which were widely used in both iPhone and Samsung phones, were flawed. All it took for an attacker to compromise the device was to be within Wi-Fi range and have the Wi-Fi active to remotely take control of the device.
From a supply chain perspective, we see that not only is the conventional hardware broken to a large extent, but the geographic distribution, which can be further amplified if you have any kind of IoT going on in your supply chain, is subject to all the problems I’ve just described and even more. An attacker can frequently gain physical access to your hardware, or at least it becomes much more difficult to prevent physical access to any device that might be connected to your supply chain. Thus, supply chains are extremely exposed by design as far as hardware is concerned.
As we have seen that the state of affairs in terms of hardware security is terrible, it should not come as a great surprise that the state of affairs concerning software security is also terrible. I’m not going to enumerate all the flaws that can be found in software; the key idea is that every single layer comes with its own computer security woes. We could talk about the operating system, virtual machines, hypervisors, application frameworks, web servers, and so on. All of these layers have encountered a series of severe computer security problems.
However, the one thing I would like to point out is that, software-wise, even the pieces of software that are supposed to protect you can severely backfire. For example, antiviruses represent a whole class of security problems. An antivirus is a piece of software that operates with enormous privileges on the machine, just because it is supposed to be able to scan what all the other processes are doing. By necessity, the antivirus operates with enormous privileges, which means it is a prime target for an attacker. Moreover, the antivirus, if there is any, is going to be present on many machines in the company, so it’s the same software with very high privileges that happens to be present on many machines. This is really a prime target for an attacker, and guess what? A lot of attackers nowadays are directly targeting antiviruses. This is, by the way, what you can see on the screen: security researchers showing how to compromise an existing antivirus on the market to use this antivirus to extract data from the target.
However, the problems with antiviruses run very deep. An antivirus is fundamentally a very resource-intensive computation. As a result, it means that antiviruses invariably involve a lot of low-level programming voodoo to achieve the desired level of performance. Unfortunately, the more low-level shenanigans you have in your software to achieve great computing performance, the more attack surface you get, just because you expose yourself in terms of low-level problems. Furthermore, antiviruses are, by design, software pieces that need to constantly interact with the outside world. Typically, an antivirus is worth nothing if it doesn’t constantly update itself with the latest set of signatures and bits of logic on how to detect the freshest malware. Thus, you end up with a piece of software that increases your attack surface just because it needs to connect itself to the network and many other things.
My own personal take is that most antivirus solutions are doing more harm than good in the present-day enterprise software market. But the reality is that pretty much the same can be said for most security solutions. In the past years, there have been very severe worldwide issues where attackers specifically targeted some security solutions, just because those security solutions share the same key characteristics as antiviruses: high privileges, extensive reach, and high connectivity, which make them prime targets for attackers.
To conclude from a supply chain perspective, I would like to point out that the sort of enterprise software that is prevalent in supply chain circles tends to have abysmal security due to its sheer internal complexity. It is already difficult to secure a piece of software that is very thin and lean; when you are dealing with a very bloated product that has been constantly growing for decades, it becomes an almost impossibly challenging task.
Finally, supply chain attacks are of interest for at least two very distinct reasons. First, supply chain attacks are interesting because they have grown massively during the course of the last few years. My own personal prediction is that these supply chain attacks will probably be one of the dominant forms of computer security attacks in the next decade. Second, the presence of the “supply chain” keyword in the name of the attacks can generate a lot of confusion, especially when discussing with a supply chain audience. A supply chain attack is simply an attack that targets one of your software dependencies. For example, attacking Amazon directly, the software produced by Amazon directly, might prove very difficult. Possibly, the teams at Amazon are very confident and competent, and their software is very well-engineered, with not many security flaws to take advantage of. However, what about all the dependencies or pieces of software that are used by Amazon but were not created or engineered in the first place by Amazon? All of those elements are, for example, the case with open-source software. At present, every single vendor is massively using open-source software. You can name any large company nowadays; chances are, they are extensively leveraging bits of open-source software.
If we go back to the Amazon case, what about compromising one of the open-source components used by Amazon, if I cannot manage to compromise Amazon directly? That’s exactly the essence of a supply chain attack. It turns out that last Friday, there was probably one of the biggest computer security breaches of the decade with the Log4j “catastrophic” vulnerability uncovered. In short, Log4j is an open-source component used to log errors. Essentially, when software encounters an error, you want to be able to backtrack errors after the fact, and when an error occurs, you typically want to log this error. That’s the primary function of a logger, such as Log4j. The “j” in Log4j stands for Java, which, in the enterprise software world, is one of the dominant software stacks. For all the software implemented in Java, the majority of products need a logger, and most are probably using Log4j at this point.
It turns out that a catastrophic vulnerability, classed as 10 out of 10 on a security criticality scale, was found last Friday in Log4j. As this specific piece of software went under a great deal of scrutiny, because there has been large-scale worldwide chaos as a result of this one vulnerability, a second critical vulnerability was found today. This is really the essence of a supply chain attack: a small component, seemingly innocuous, something that you probably never heard of or even realized you were dependent on, just happens to be at the core of your system and can create a huge amount of chaos because it creates vulnerabilities.
From a supply chain perspective, it turns out that supply chains are particularly vulnerable to supply chain attacks. This is the case because modern supply chains are heavily interconnected. Most likely, your company, if you’re running a modern supply chain, is heavily connected in terms of software to both your suppliers and your clients. It can take the form of EDI, but it can also take all sorts of forms with computer integration between companies. In terms of supply chain attacks, it means that it’s not just the software dependencies that you have in order to attack you; chances are that all it takes is to compromise one of the dependencies of one of your suppliers or one of the dependencies of one of your clients. In terms of attack surface, supply chains are very vulnerable and exposed by design.
So far, what we have seen is a fairly bleak picture of the situation, and I believe this is an accurate depiction of present-day computer security. We have tons of problems, and I’m afraid that I will be discussing in this last section what can be done about it. Let me be clear, though; right now, it is an uphill battle and an extremely difficult one that you must be prepared to lose once in a while. Just because this is very difficult doesn’t mean that we shouldn’t try to do better in terms of security.
Let’s start with the common wisdom in terms of computer security. The FBI has a top-five recommendation in terms of computer security. Let’s review these recommendations. The first recommendation is to back up, test your backups, and keep your backups offline. Overall, it’s a good recommendation. However, the idea of keeping backups offline is somewhat unrealistic. It is very costly and difficult. For a backup to be of any use, you need to do it frequently. A backup that is one month old is typically of zero use. If you are backing up very frequently, every day, hour, or even minute, it becomes challenging to have a truly offline backup. My suggestion would be to keep your backups strictly isolated. When it comes to backups, focus on quick recovery. What matters is not having a backup plan but a recovery plan if your applicative landscape ends up compromised.
The second recommendation is to use multi-factor authentication. Again, this is a good recommendation, as passwords are insecure. However, the problem with multi-factor authentication is that very frequently, you only have the illusion of having it. For example, if you have a password and a confirmation by phone, you could say it’s two-factor authentication. But if I can reset the password with the phone in my hand, it’s only a one-factor authentication. With multi-factor authentication, make sure those factors are truly isolated and do not devolve into one-factor authentication because one factor overrules the others.
The third recommendation is to update and patch your systems. This is a good practice; however, too much of a good thing can become a bad thing. One of the most severe problems we have nowadays is supply chain attacks where we depend on automated software upgrades. If an attacker manages to carry out a supply chain attack by compromising a piece of open-source software, and there are thousands of those, it means that by just letting the auto-updates take over, this piece of malware gets into your systems. This is becoming increasingly dangerous. Most of the problems with USB hardware come from auto-update capabilities of the firmware. So, while it’s important to update and patch your systems, always consider whether you’re creating an even bigger security problem.
The fourth recommendation is to make sure your security solutions are up to date. On this recommendation, I’m not too sure what constitutes a security solution. This recommendation feels like it may be the direct product of some lobbying effort from a security company. Most of what is nowadays advertised as security solutions may not make your supply chain or company more secure. Nevertheless, if you have a piece of software, it’s typically better to keep it up to date, whether it’s a security solution or anything else.
The last recommendation is to review and exercise your incident response plan. This recommendation isn’t bad, but in my opinion, it wouldn’t make it to the top five. This sort of thinking is more appropriate for dealing with industrial accidents, like the risk of fire, but not necessarily computer security problems. My own recommendation number four, in terms of security, would be to know your threat models, know your attack surface, and know your blast radius. The very fact that you know how you are exposed in the first place and the sort of things that can happen goes a long way in preventing problems. Knowledge in terms of computer security is key.
My own recommendation number five would be that computer security is a culture, not a process, and not a solution. This is just a reminder that no checklist of any kind will do any good for your company in the long run. It is a culture.
Regarding security inversion, it seems that our intuitive expectations in terms of role models or whom we should trust for computer security are invariably wrong. Organizations that appear the most secure on the outside or in terms of appearance are typically the worst, while organizations that look very gray or shady are often the best. This is the essence of the security inversion paradox.
By way of anecdotal evidence, I would like to point out a talk from 2014 on airport security, where two security researchers showed that in terms of computer security, airports are really bad. The security is so poor that it would almost be comical if it weren’t so serious. You would expect international airports to benefit from incredibly tight computer security, but the reality is the exact opposite. The computer security is literally a complete joke, with an encyclopedia of vulnerabilities, demonstrating complete incompetence, lack of care, and apathy to the problem.
This talk matches my own professional experience. As a professional hobby, I have been conducting technological audits on behalf of investment firms for more than a decade. I have had the chance to audit dozens of tech companies, and my observation is that the more secure the appearance or context of the company, the worse their actual computer security seems to be. Companies that operate in fields of defense and security tend to have incredibly bad security, while those in gray areas, such as betting websites and adult websites, tend to have excellent computer security.
The same problems even occur within one specific industry. For example, in healthcare, I have witnessed the security for devices used by surgeons during operations to be completely dismal, while the computer security for vending machines in the hospital is quite good. Intuitively, you would think that the devices used in surgery must be incredibly secure, but the opposite is true. The vending machine is more secure than the devices used by the surgeon.
This counterintuitive inversion, I believe, stems from a simple matter of Darwinism. No international airport has ever gone bankrupt due to massive computer security problems. These airports are not even allowed to fail and can get away with ongoing computer security issues for years with an impressive degree of apathy. On the contrary, if you run a company operating an online betting app and let hackers exfiltrate money, you’re not going to last long, and nobody will come to your rescue.
By way of anecdotal evidence, I would like to point out a talk from 2014 on airport security. In this talk, two security researchers showed that in terms of computer security, airports are really bad. The security is so poor that it would almost be comical if it weren’t so serious. This is the exact opposite of what you would expect; you would anticipate international airports to have incredibly tight computer security. However, computer security at airports is literally a complete joke. These security researchers showed that it’s not just one vulnerability, but an encyclopedia of vulnerabilities, with many of the problems demonstrating complete incompetence, lack of care, and apathy.
This talk matched my own professional experience. As a professional hobby, I have been conducting technological audits on behalf of investment firms for more than a decade. I have had the chance to audit dozens of tech companies, and my observation is that the more secure the appearance or context of the company, the worse their actual computer security seems to be. For example, companies operating in fields of defense and security tend to have incredibly bad security, while companies operating in gray areas, such as betting websites or adult websites, tend to have excellent computer security.
Interestingly, the same problems even occur within one specific industry. For example, in healthcare, the security for devices used by a surgeon during an operation is dismal, while the computer security for vending machines in the hospital’s hall is quite good. Intuitively, you would think that whatever goes into the operating room must be incredibly secure because the patient’s life is at stake, but the opposite is true. The vending machine is more secure than the devices used by the surgeon.
This counterintuitive inversion, I believe, is a simple matter of Darwinism. No international airport has ever gone bankrupt due to massive computer security problems, and they are not even allowed to fail. As a result, they can get away with ongoing computer security problems for years with an impressive degree of apathy. On the contrary, if you run a company that operates an online betting app, and you let hackers exfiltrate money because they can change the outcomes of the bets, you’re not going to last long, and nobody will come to your rescue.
As a result, those people are essentially survivors. They are the ones who did everything needed to secure their systems. For supply chain, the key takeaway here is that if you are looking for genuine computer security help to assist you in securing your supply chain, don’t look for ex-military officials with impeccable credentials. Instead, look for a system administrator or someone who was involved with an adult website or online betting—those fringe areas where people really needed skills, talent, and dedication to survive. Otherwise, the company would have ceased to exist under their watch.
As a final part about what can be done in terms of computer security, I would like to outline the role of design. When it comes to computer security, many so-called experts would tell you that you need to train your teams. Personally, I’m not so sure, in the sense that you cannot train people not to make mistakes. Even the smartest people are going to be tired, sick, and make very stupid mistakes once in a while. You cannot rely solely on training. Computer security is not like military security; you cannot just put people through intense training so that they can operate on instinct. Most of the time, the situation really requires you to be calm and think hard about what is going on. Otherwise, the remediation is most likely to be worse than the problem that you had in the first place.
My take is that if you have a design problem in your organization when it comes to computer security, no amount of training or duct tape is going to fix the problem. It’s going to be a battle that you cannot win. When you take things from a design perspective, you’re looking for decisions or aspects that can have a massive impact on threat models, attack surfaces, and blast radius. You want to make design decisions that eliminate as many classes of threat models as possible, eliminate entire attack surfaces, and constrain the potential blast radius.
For example, when talking about attack surfaces, consider the design decisions involved. If your organization is picking software vendors with Requests for Proposals (RFPs) or Requests for Quotes (RFQs), you can be assured that you’re going to have massive computer security problems by design due to the RFPs and RFQs. Why is that? Well, if you select enterprise software vendors based on RFPs or RFQs, you are selecting vendors who can tick all the boxes because there will be tons of boxes to be ticked. A typical supply chain RFP is going to have hundreds of boxes to be ticked, and those boxes pertain to the capabilities and features of the software. When you drive your selection of enterprise software vendors through an RFP, you’re actually selecting vendors that have massively bloated products with tons of features and capabilities, which in turn results in a massive attack surface. The more capabilities and features, the greater the attack surface. If every single software vendor you pick is chosen through this process, you end up with an applicative landscape that has an insanely large attack surface at the end of the day or, rather, at the end of the decade, because these are slow-moving problems as far as supply chains are concerned.
The same sort of design decisions can also have a massive impact on blast radius. For example, the way you approach data has fairly dramatic consequences from a supply chain perspective. Most personal data is simply completely useless for any kind of supply chain optimization. If you want to have better forecasts and better planning, you don’t need to know the first name and last name of your customers. The idea, and that’s a practice that Lokad adopted more than a decade ago, is to view personal data as a liability, not an asset. In terms of blast radius, it means that if systems ever get breached, the damage will be much smaller if personal data is not leaked. Yes, it’s bad if all your stock levels are publicly exposed, but it’s not going to have a very big negative impact on your company, unlike leaked personal data. This is a design aspect of organizing your supply chain that can have massive consequences in terms of blast radius.
The very best design decisions are the ones that eliminate entire classes of problems. The role of a computer security culture in a company is to allow the organization to develop the correct insights about what design decisions should be made to protect your company. The correct design insights are the product of a proper culture around computer security.
This brings me to the conclusion that computer security is too important to be left solely in the hands of IT specialists. Computer security is best approached as a culture within the company and is a shared responsibility, not just the responsibility of people who have the security keyword in their job title. As we discussed earlier in this lecture, computer security often competes with other types of security within a company, so it is an illusion to think that a computer security specialist can save you. They may only address one facet of the problem, which is why culture is essential for fostering the emergence of design decisions that bring great security benefits to your company.
The right culture is also essential for instinctively rejecting bad design decisions that would create ongoing problems that can’t be fixed later. Having a great security culture is not just about what you should do but also about what you should not do. One of the most difficult aspects of a healthy computer security culture is getting employees to care sufficiently about the problem so that they are not satisfied with the appearance of security. In a healthy computer security culture, people are looking for genuine security, not just the appearance of security. The illusion of security is often much worse than an actual lack of security.
This was the last lecture of 2021, and the next lecture will take place in 2022, on the same day of the week. In the next lecture, I will start the fifth chapter, which is about forecasting. In particular, I believe it will be a fairly interesting presentation because Lokad managed to achieve a very spectacular result in the M5 forecasting competition. I will be presenting this result, but also discussing the lessons that are attached to this model as far as supply chain is concerned.
Now, let me address the questions.
Question: In general, do supply chain leaders consider cybersecurity irrelevant for them or not?
My feeling is that yes, to a large extent, they do, but it can be worse than that. Apathy is a big problem, but even when supply chain leaders do care, they tend to approach computer security from a risk analysis perspective that would be applicable for industrial risks. This is not the most efficient approach when it comes to cybersecurity. So my point is that supply chain leaders absolutely do not care enough about what can destroy their supply chains nowadays, and they really have to familiarize themselves with the right sort of remediation.
Question: As cybersecurity is on the rise, companies’ investments in this industry grow faster than their budget for other software. Is there a possibility that in the future the benefits of having a software system are counterbalanced by large costs for cybersecurity, and people fall back to pen and paper?
I didn’t say that cybersecurity is on the rise; I said that cybercrime is on the rise. I hope that at some point, cybersecurity will be on the rise. It’s true that companies’ investments in this industry are growing faster than their budgets for other software. The question is whether, in the future, the benefits of having a software system might be counterbalanced by large costs for cybersecurity, and people might fall back to pen and paper again.
As I was saying, because cybercrime is on the rise, people feel the pressure and thus spend money on cybersecurity solutions. Indeed, even the FBI recommends investing in some kind of security solution. My problem with these security solutions is that security cannot be an afterthought; most of it is by design. If your company is selecting software based on RFPs, you have a problem at the very core of your company, which is that you are selecting enterprise software vendors that are going to be exceedingly poor security-wise. Thus, it doesn’t matter if you decide to invest in some fancy security solution afterward—it’s too late. By design, you are compromised.
If we go back to the medieval castle analogy, you can’t engineer a bigger moat on top of a weak drawbridge or make the walls of the castle higher if they are not high enough. In the medieval era, most castles did grow over time and weren’t built at once. The idea of having additive layers of security works if you’re dealing with physical risks, but in software, it doesn’t work. The more lines of code you add, the bigger your security problem becomes.
I agree that cybercrime is on the rise, and cybersecurity spending is increasing. However, if we were to measure cybersecurity as a ratio between reported losses in cybercrime versus GDP, this ratio is getting worse. We have less cybersecurity while spending more to fight it.
As for the possibility of going back to pen and paper, I don’t think the world will revert to the pre-digital era. The cost of doing so is just too great. The benefits brought by software are absolutely gigantic, and even if we consider cybercrime to be a significant issue, in the end, it’s still a problem that, in terms of magnitude, is only one-third the size of the illegal drug problem. Illegal drugs are a significant problem, but they don’t signal the end of our industrial civilization. I don’t believe people will return to pen and paper. However, I suspect many software vendors will start adopting simpler technological solutions.
To illustrate this point, let’s consider the Log4j vulnerability, which hit the world and wreaked havoc among large companies. This supply chain attack-related vulnerability was caused by the complexity and capabilities of the Log4j component. Normally, it should be a small piece of software that logs errors, but it turned out to be a beast in terms of software capabilities. People discovered a way to exploit this beast to achieve unintended consequences.
At Lokad, we’re not using Log4j; our stack is in .NET, and we’re using NLog, the equivalent component in the .NET stack. However, in light of the problems within the Java community, my CTO and I decided to phase out NLog and opt for something much simpler. It won’t be a better NLog, but something with only one percent of the complexity. These loggers are incredibly capable, but their capabilities become a big liability.
The equivalent of going for pen and paper would be to start replacing very powerful and complex pieces of software with software pieces that are much smaller and less capable. This can help alleviate the burden of security costs. At some point, it becomes clear that it’s cheaper to reimplement a small piece of software that does just what you need, even if you have to reinvent the wheel, as opposed to using a free open-source component that incurs a massive extra attack surface due to its size.
Regarding larger known attacks impacting supply chains, there may be biases in the attacks that make the news. Log4j was a massive worldwide problem because it impacted many industries, including banking, supply chain, cloud computing providers, and gaming companies. However, if we look at the Colonial Pipeline attack, it was a ransomware attack targeting one specific billing piece of software. What I see is that the sort of attacks that make the news are the ones that get a lot of coverage, but that doesn’t mean supply chain-specific attacks aren’t happening. While I can’t disclose details about Lokad’s customer base, I have witnessed ransomware attacks among our 100+ customers. It’s evident to us when we don’t receive data for a week or two while the companies struggle to remedy the situation, typically restoring their systems from scratch with backups. Sometimes, Lokad ends up being the only backup they had. Severe attacks targeted at supply chain systems are happening quite frequently.
With a fairly small sample, Lokad has 100+ companies as clients, but it’s not as if we have a million. Even with that, we are currently seeing about half a dozen major incidents per year, which equates to a 5% annualized risk for a significant cybersecurity incident. This is a pretty high risk in my book.
Question: It seems that cybersecurity becomes the digital analog of personal hygiene. Do you think schools should start teaching kids about these skills?
Yes, I understand your point about hygiene. However, in cybersecurity, the attackers are intelligent. Real-life viruses mutate, and it’s challenging to contain pathogens. But there is a significant difference between facing a mindless attack and dealing with people who can think hard and long about how to inflict the most damage on you and your company.
I agree that there is a challenge in teaching and training people, even children, about cybersecurity. My personal belief is that a 12-year-old child is essentially as smart as an adult, just lacking the experience an adult has. So yes, this is something that should be addressed, including fraud and social engineering schemes. Many people still fall victim to obvious scams, such as the infamous Nigerian prince emails.
Schools should prepare young minds and younger generations to face a world that can be adversarial. Even in relatively peaceful times, there are people who wish you harm. The key aspect of cybersecurity is that a person who wishes you ill can be thousands of kilometers away and still manage to do damage to you, your organization, and your relatives.
At some point, schools should address this issue. However, at least in France, it’s still a struggle to find teachers who can teach basic programming skills. This ongoing struggle makes it difficult to find teachers who can teach cybersecurity and digital security to children. Nevertheless, it should probably be done, but I don’t have much hope for this area in the next decade.
As there are no more questions, I’d like to wish you all a Merry Christmas and see you all next year.
