Risks of digital infrastructures

Risk is the flip side of value. For everything that is of value, there can be circumstances threatening that value. While value is realized in the past and the present, risk is what can happen with that value in the future. Risk in a digital world is not always easy to think through. While we can borrow a lot from the real world, certain important differences exist. At the core of every risk assessment there is the thing we worry about the most: the ‘asset’. In a digital world, this is often the data. Think of business-critical data, like our database of customers. Think of data that we have a compliance obligation on, such as personal data. ...

Let’s dive a little deeper into assets. The most relevant asset in information security is data. That is what users of information care about most. In addition, we can also see the processing power that we need as an asset. Here are some examples of data assets: A customer record in a business system An MRI scan A browser cookie (on the server) A logfile entry As you can guess from these examples, many involve regulatory concerns due to the type of data that they consist of. One of the tasks of a risk analyst is to figure out what regulations apply exactly. ...

I have found that no discussion on risk is going to lead anywhere if it does not make clear who suffers from it. Make clear who has the pain. For my phone and laptop it is easy: if I lose them, I suffer. In a larger organization it is less clear. Suppose a server dies. Whose application then no longer runs? Who has to pay for a new server? This gets increasingly harder if we are talking about shared services, because the owner and the consumer are now decoupled. ...

From the moment a security vulnerability is discovered, it represents a negative value to its potential victims. When it gets exploited, it can lead to loss of data or loss of integrity of the data. This in turn impacts the victim’s business processes. For example, if personal data is leaked, reputations will be damaged, financial losses and fines can be expected. Credit card abuse forms another example of loss. This “damage potential” increases as the vulnerability becomes well-known, progressing from nation state actors, to organized crime, to script kiddies, just to name one example pathway. At first, few people know about it, but gradually more people will be able to inflict damage with it. Over time, each step adds to the likelihood of that vulnerability being exploited and causing real damage. The likelihood starts at near zero, and ends at close to 100% as the vulnerability is completely public. This only stops when an investment is made to mitigate the vulnerability, for example by updating the software. And hopefully, that investment is less costly than the damage potential. ...

Zero Trust Architecture is an approach to better cybersecurity. To many, it seems daunting to implement. But it does not have to be hard to start. Consider this hypothetical situation. You have an application with hundreds of thousands of sensitive records, let’s say client records. We assume that in this example it seems hard to implement MFA (Multi Factor Authentication) on it. What other controls can you implement to reduce the assumed trust? We can use the Kipling method, which is at the core of Zero Trust architectures, to engineer better controls. In short, the Kipling method is about the ‘who’, ‘what’, ‘when’, etcetera of allowed communication. ...

Imagine that you are part of the government of an average nation, and you have just realized that IT has become a substantial factor in your operation. Or you have a similar position in a manufacturing industry, or in the financial sector. As IT increased in volume, you have tried to keep its costs down, it was just a facility. Outsourcing to more experienced partners was an option, and so was the use of cloud computing, for example for your Office applications. ...

Many people think we are overly dependent on big tech, and we should be more autonomous and sovereign. Fewer can say what exactly is the risk here. Digital autonomy and sovereignty form a wicked problem: its parts are intertwined with many other issues and conflicting interests, so there is no clean solution. Before reaching for solutions, it pays to be precise about the risk. At risk is our power to decide which data flows where, a power exercised through control over digital infrastructures such as cloud and social media. The risk, then, is what happens when that power sits with someone else. ...

Autarky Implicit in many discussions on digital autonomy is the quest for ‘autarky’, being completely independent from other actors, for example those actors whose objectives may be in conflict with ours. This is driving the call for national cloud providers, local manufacturing, and more open source, to name just a few. Autarky, however, is just one tool for establishing autonomy, and a very difficult one as well. Economic history shows that no well-developed country is in a state of autarky. For example, in World War II, England was heavily dependent on transatlantic shipping convoys for its supplies, including food. This should be familiar to anybody who has studied the role of Alan Turing and others at Bletchley Park in deciphering the German military code (Enigma) that threatened those convoys. ...

Suppose you are a government, a regulator, or a concerned cloud consumer. What can you actually do to mitigate sovereignty risks and achieve adequate autonomy? The honest starting point is that full digital autonomy, autarky, is not achievable, and not worth pursuing. Read here for more on that. No well-developed country is fully independent of others. The goal is not independence, but resilience: reducing the negative effects of dependence, and preserving options. ...

Where do you start your IT security journey? It is important, but it can be confusing. For many organizations, the trigger is a compliance obligation to show that confidential information remains confidential. Maybe their customers are asking for an ISO/IEC 27001 certification, demonstrating that an IT risk management system is in place. Maybe they are handling credit cards and therefore need to worry about compliance to PCI DSS. Controls The common theme in these is that they are control based. The process is that you realize compliance by implementing a set of controls, such as defining a password policy, or implementing a type of firewall. ...