Act V — Staying in control on Digital Infrastructures at Scale

How My Site Got Hacked

Sat, 29 Mar 2025 15:35:53 +0000

Detection

I should have acted on the first signals more aggressively. But let’s talk about that later in this story. Here is the story of my site being infected with malware, viewed by a professional cloud security expert. So I am going to apply all that cloud security theory to it.

The hack led to business damage at the end of one of my webinars. In 2016, on a Friday, I did a webinar, at the end of which I had two links to my site as a call to action.

Introduction to Risk

Wed, 12 Mar 2025 13:13:35 +0000

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.

Who Suffers?

Tue, 15 Apr 2025 21:27:25 +0000

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.

Information Security Assets

Sun, 11 May 2025 08:37:01 +0000

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.

Lean Risk and Economics

Tue, 27 May 2025 19:58:41 +0000

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.

Data, Risk, or Controls: where to start?

Mon, 01 Sep 2025 19:48:55 +0000

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.

Compliance is a Risk

Fri, 22 Aug 2025 09:18:35 +0000

For people who care about risk in IT, compliance is a mixed blessing. Compliance regulations can lead to better risk management, but sometimes it is more of a hindrance than a help.

Compliance in IT generally means compliance with regulations that are set up to reduce risk, for example, across a chain of actors. A great example is the PCI/DSS regulation, which governs everybody who touches a credit card transaction. The objective of this regulation is to protect card holders and card issuers from credit card fraud. The reason why the regulation exists in the first place is because negligence at one actor can lead to damages at another actor.

Retrofitting Zero Trust on an existing application: an illustration

Fri, 28 Feb 2025 14:15:21 +0000

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.

Why lawyers need to understand cloud

Thu, 03 May 2018 13:54:48 +0000

Cloud is too important to leave to technical people.

Cloud distributes responsibility for IT services across an IT supply chain. This supply chain is composed of independent providers. This implies that there are these companies have technical boundaries that are matched by organizational and contractual boundaries. This is new, we did not have that before the digital revolution. Amazon calls this the shared responsibility model for cloud security. I would simplify that as: what do I do, and what do you do? For example, who is responsible for patching the Operating System in an IaaS service model?

Technology architecture for non-techies

Fri, 02 May 2025 08:07:42 +0000

Understanding the technical architecture of digital infrastructures is critically important, in particular for non-technical professionals.

I have spent more than a decade educating people on cloud security, for example through certifications such as the Certificate of Cloud Security Knowledge (CCSK), organized by the Cloud Security Alliance (CSA), and the Certified Cloud Security Professional (CCSP), as organized by (ISC)2. These bodies of knowledge cover a lot of ground, and most of it is related to digital infrastructures at scale.

Digital autonomy: The risks

Wed, 13 May 2026 00:00:00 +0000

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.

Digital autonomy: Autarky

Mon, 18 May 2026 00:00:00 +0000

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.

Digital autonomy: Controls

Sun, 14 Jun 2026 00:00:00 +0000

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.

A guide to digital sovereignty, autonomy, and business resilience

Fri, 11 Jul 2025 14:57:31 +0000

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.