Security by Design for Analytics Platforms: What Changes When Your Users Face State-Level Threats

Many data projects start in the same way. An organization wants to understand how its offering is used: what reaches whom, what works, what doesn’t, and where to invest next. The plan is reasonable: consolidate usage data from a handful of source systems on one analytics platform, build data products on top of it, and give the decision-makers numbers instead of assumptions. Somewhere in the architecture document there’s a security chapter, and it says what security chapters usually say: encryption, backups, access control, GDPR.

For most companies this chapter is about the risk to the organization. If data leaks, there will be a fine, a headline and an uncomfortable board meeting. This hurts, but the company survives it.

Now let’s change one assumption: your users can go to prison for using your product.

Unfortunately this isn’t a thought experiment. There are countries where reading or sharing independent journalism is a criminal offense. If it is the mission of your organization to reach people in these countries, a log line which connects a person to a piece of content is more than a usage metric, as it can be used as evidence against this person. And once you build a platform which aggregates these log lines, you have changed your own threat model, whether you are aware of it or not.

So what does this mean for the architecture of an analytics platform?

From Source Protection to Audience Protection

I’ve spent a large part of my career in and around newsrooms. In environments like Al Jazeera shortly after 9/11, the Guardian shortly after the Snowden publications, or the Frontline Club in London, source protection is part of the craft. Nobody discusses whether the identity of a whistleblower deserves attention in the architecture. The systems, the processes and sometimes even the building are designed around it.

So I thought I knew this problem, but I only knew half of it. Now imagine that, in addition to your sources, you need to protect your audience just as much. I don’t mean the few people who bring you information, but the many people who consume it and who may need protection from their own governments. To be honest, I found this thought quite unsettling when I first came across it, as the analytics of an organization could be the thing which puts the people it wants to reach in danger. At the same time it became clear to me that this is an architecture problem.

And it’s not a problem of media organizations alone. NGOs, health platforms and any other service where the usage data alone can incriminate, expose or endanger a user are in the same situation. In the public breaches which illustrate this best, the product database was rarely the problem. An analytics environment leaked, and suddenly the most sensitive information about millions of people was their usage history and not their password.

Are We the Security Risk Now?

When you build an aggregation platform, you consolidate data from many source systems in one place, because having it in one place is valuable. I think every architect of such a platform should ask the following question out loud at some stage, even if nobody at the table likes it: are we ourselves the security risk now?

In most cases the answer is yes. By design, an analytics platform concentrates the information which an adversary would otherwise have to collect system by system and breach by breach. Each source system holds a fragment, while your platform holds the joined picture. For an attacker it may be more attractive, and at the same time easier, to attack the aggregate than any single source. You built the platform because aggregated data is more valuable, so you shouldn’t be surprised when adversaries see it the same way. The following diagram shows the difference:

This is why the work needs to start with a threat model and not with a list of tools. The most important question in this threat model is who the adversary is. A commercial data thief wants data which can be turned into money with little effort, and moves on when attacking you becomes too expensive. A state is a different kind of opponent: it is patient, it has plenty of resources and legal instruments in addition to the technical ones, and it’s interested in specific people.

When the adversary changes from “someone who wants data” to “someone who wants your users”, the most valuable asset changes, too. It’s no longer the product data or the revenue numbers, but the link between a person and their behavior. All design decisions which follow try to make sure that this link is stored rarely, only in a coarse form, or not at all.

Data Minimization Is an Architecture Decision

Every data organization says it practices data minimization, as the GDPR requires it. In many organizations this means there is a retention policy document and an audit once a year. With a state-level threat model, minimization becomes part of the architecture itself. I use three design rules:

• Collect only what current analyses need, and not what might be useful someday. The data you collect for “someday” is what an attacker wants and what a court can compel you to hand over. If no data product needs it today, don’t collect it today.
• Persist even less than you collect. Some questions can be answered in passing: aggregate at the edge, keep the count and drop the event. For everything which ends up in storage there should be a reason why it needs to be kept.
• Avoid personally identifiable information by design. The most effective control is to make the dangerous join impossible: no user accounts in the analytics path where you can avoid them, aggregates instead of individual trails, and cohorts instead of profiles.

For every incoming analytics requirement I ask one question: can we answer this without knowing who? In my experience the answer is yes in almost all cases. Let’s say a product owner wants to know how many female users between 18 and 24 used a certain piece of content in June. For this, a usage event has to be logged with a few attributes: gender, age segment and the ID of the content, maybe also the country and the time of use. But we don’t need to know who exactly the person was.

Product owners and analysts want to know how many, where, how long, and which parts of the offering. These are questions about groups of people and not about individuals. Most of the individual-level data which piles up in analytics platforms is there because collecting it was the default, and not because someone needs it. Changing this default is what security by design is about.

This has a nice side effect: data you never collected is the safest data you can have. No breach can expose it, no insider can sell it, and no legal order can force you to hand it over.

Design Access as if Someone Is Already Inside

The data you do collect still needs protection, and here I assume that some of the protection will fail at some stage. The following patterns help the most:

• Authorization per data product and not per platform: access is granted to one data product for one purpose, down to table and column level where the data requires it. An analyst who needs aggregated metrics doesn’t get access to raw events automatically.
• Global access for no one. This includes the platform team, the admins and the CEO. If a single account can read everything, this account is the target, and at some stage someone will hold it who should not. The answer to the question “Who can see all of it?” should be: nobody.
• The basics: two-factor authentication everywhere, encryption at rest, and joiner-mover-leaver processes which work. None of this is new, and still it’s missing in many places.
• Placement as a threat model decision: when your adversary is a state with legal reach, the question of where the platform lives physically and legally (on-premises, in a cloud, in which cloud and under which jurisdiction) is more than a question of cost or convenience. It’s part of the security design and should be decided together with the threat model and not afterwards.

None of these patterns is exotic. Yet, with this threat model you cannot give them up in exchange for delivery speed anymore, as a failure costs much more than a fine.

Residual Risk

There’s one more thing which belongs in the architecture document, although nobody likes to write it down: complete protection isn’t possible. There are endpoints you don’t control, networks you don’t operate and platforms you don’t run. Parts of the path between you and your users are outside of your reach, and a state-level adversary can work on all of them. So a residual risk remains, no matter how good your design is.

I do not think that saying this is defeatist. An architecture which claims full protection won’t be designed carefully enough. An architecture which assumes that parts of it will fail at some stage ends up with the properties you want: a successful breach yields aggregates instead of identities, no single credential opens everything, and the most dangerous data has never been collected.

Security at the Shared Table

One last point about the organization, as none of the above is a one-time review. Which data may be collected, how long it’s kept, who may access which data product and where the platform runs are the questions which, as I described in Meet Once, Not Twice, belong at the single, shared governance table and should be answered once for data and AI together.

With a serious threat model security cannot be a gate at the end of this process. It needs a permanent seat at this table, as every new data product, every new analysis and every new AI use case on top of the platform raises the same question again: does this create a new way to link a person to their behavior?

Conclusion

If your users only risk embarrassment, you may get away with treating security as a chapter in the architecture document. If your users risk prison, security needs to be part of the design from the very first workshop.

The good news is that, from what I have seen, the resulting architecture doesn’t have to be slower or poorer. It even becomes leaner, as it doesn’t collect what was never needed. And as an architect of an aggregation platform you can then explain that you know you are a target, and why your organization and the people who trust it can live with that.