Multilevel Security: Why the Ideal Model Rarely Works in the Real World

Multilevel Security (MLS) is one of the most fundamental concepts in the history of information security. It is here that strict mathematical models of information flow control emerged, many of which are still used today.
MLS embodies the hedgehog approach – a system built around one big universal idea that is supposed to explain and solve all security problems. However, the real world rarely fits into the framework of a single concept. Therefore, the history of MLS is simultaneously a history of brilliant theoretical achievements and painful practical compromises.

Why MLS Was Born

Originally, multilevel security was developed for military and intelligence systems, where a single computing environment could process data of different classification levels:

• Unclassified
• Confidential
• Secret
• Top Secret

The main challenge was not only to prevent a user with a lower clearance from reading classified information. It was equally important to prevent the reverse problem: to eliminate any way of leaking classified data into less protected areas of the system.
To solve this problem, the Bell–LaPadula (BLP) model was created, which became the foundation of mandatory access control.

Bell–LaPadula: Protecting Confidentiality through Information Flow Control

The Bell–LaPadula model, developed in 1973, is based on the idea that information flows should move only in permitted directions.
Unlike traditional access control systems, BLP is a rigorous mathematical model founded on the notion of security lattices.
Each subject in the system (user or process) and each object (file, database, device) is assigned a security label consisting of two components:

1. Classification level:
   - Unclassified
   - Confidential
   - Secret
   - Top Secret

2. Categories or compartments:
   - {CRYPTO}
   - {NUCLEAR}
   - {FOREIGN}
   - and other specialised areas of access.

Dominance Rule

One label dominates another if both conditions are met simultaneously:

• the classification level is not lower.
• the set of categories includes all categories of the lower label.

For example:

Top Secret {CRYPTO, NUCLEAR}

dominates:

Secret {CRYPTO}

but does not dominate:

Secret {FOREIGN}

if the category {FOREIGN} is absent.

The Two Fundamental Rules of BLP

Property	Rule	Purpose
Simple Security Property	No Read Up – a subject cannot read data of a higher level	Prevents unauthorised disclosure of information
*-Property (Star Property)	No Write Down – a subject cannot write data to a lower level	Prevents information leaks

The No Read Up principle is intuitive: an employee with Confidential clearance should not be able to view documents marked Secret.
Much more important is the No Write Down rule. It is this rule that protects the system from covert propagation of information. Even if malicious software gains access to Secret data, it cannot store that data in an Unclassified object.
This makes BLP not just an access control mechanism, but a model of information flow control.

It is the No Write Down rule that distinguishes multilevel security from most traditional access control systems.

The Biba Model: A Mirror Image of Bell–LaPadula

If Bell–LaPadula protects confidentiality, the Biba model, proposed by Ken Biba in 1975, is designed to protect information integrity.
The logic of the model is completely opposite to BLP.

Property	Rule	Purpose
Simple Integrity Property	No Read Down	High‑level processes should not use potentially untrusted data
*-Integrity Property	No Write Up	Low‑level processes cannot modify critically important objects

The core idea is that trusted components of the system must not be influenced by less reliable sources of data.
Using a water analogy:

• Bell–LaPadula: dirty water must not get into a clean container.
• Biba: clean water must not mix with dirty water.

Practical Application of the Biba Model

Although Bell–LaPadula is rarely implemented in full, Biba’s ideas have found their way into modern operating systems.
A good example is the Mandatory Integrity Control mechanism introduced in Windows Vista.
Applications are assigned different integrity levels:

• Low
• Medium
• High
• System

For instance, Internet Explorer ran at Low Integrity. Even if an attacker managed to execute malicious code through the browser, that process could not modify objects with a higher level of trust.
In effect, the system applied the principle:

No Write Up – low‑integrity processes cannot modify high‑integrity objects.

Thus, compromising a user application did not automatically lead to compromising the entire system.

The Beauty of Theory and the Complexity of Practice

At first glance, the BLP and Biba models appear ideal. They formalise security, allow mathematical proofs of system properties, and provide clear rules for managing information flows.
However, it is at the implementation stage that it becomes clear that real computing systems are far more complex than formal models.
Most MLS problems stem not from errors in the mathematics itself, but from the fact that users, applications, and business processes constantly violate the assumptions underlying these models.
That is why further development of MLS turned into an exploration of the fundamental limitations of multilevel security.

When Theory Meets Practice: Fundamental Problems of MLS

Despite the elegance of the mathematical models, practical implementation of multilevel security quickly revealed a number of serious limitations. Many of these turned out to be not just engineering difficulties, but fundamental problems that cannot be completely eliminated without sacrificing system functionality.
Let us pay special attention to these issues, because they demonstrate the gap between ideal theory and real‑world operation.

The Tranquility Property

The Bell–LaPadula models originally assumed that the security labels of objects and subjects would remain unchanged. However, real systems are constantly changing:

• new files are created.
• employee responsibilities change.
• processes work with data of different classification levels.
• applications dynamically acquire new privileges.

To describe permissible behaviour, the concept of the Tranquility Property was formulated.

Two forms of this property are distinguished.

Strong Tranquility

Security labels never change after assignment.
This approach ensures simplicity of analysis and formal rigor, but is practically inapplicable. In a real environment, it is impossible to foresee all data processing scenarios in advance.
For example, how can a new Secret document be created if object classification cannot change?

Weak Tranquility

Changes to labels are permitted, but only on condition that they do not violate the established security policy.
This is the approach most often used in practice.

The High Water Mark Principle

To implement weak tranquillity, the concept of High Water Mark was proposed.
Its essence is as follows: if a process gains access to information of a higher classification level, its own level is automatically raised.
For example:

1. A process works with data at the Secret level.
2. It then opens a document at the Top Secret level.
3. The process itself then becomes Top Secret.

From the perspective of confidentiality, this solution seems logical: the process is already contaminated with secret information and should not interact with less protected objects.
However, a serious operational problem arises.
After the upgrade, the process can no longer:

• write data to previously created temporary files.
• update low‑level event logs.
• save results to ordinary directories.

This leads to two negative scenarios:

Gradual Hyperclassification

More and more objects receive high classification levels.
Over time, a significant part of the system becomes marked as Top Secret, which sharply reduces the ability to collaborate and share information.

Fragmentation of the System

The organisation is forced to create many isolated environments between which interaction is practically impossible.
Instead of a single system, a set of disconnected information islands emerges.

Polyinstantiation: When Secrecy Breaks Databases

One of the most unusual problems of MLS is Polyinstantiation.
Consider a simple example.
A user at the Secret level creates a record:

Agent_X

Later, a user at the Unclassified level tries to create a record with the same identifier.
At first glance, the situation seems trivial, but any decision leads to problems.

Option 1: Deny Creation

The system responds:

Record already exists.

But then the low‑level user learns about the existence of a secret object.
In effect, this violates the No Read Up rule.
Even the denial of access becomes a channel for information leakage.

Option 2: Allow Creation

In this case, two records appear in the system:

Level	Object
Secret	Agent_X
Unclassified	Agent_X

From the MLS point of view, this is correct.
From the point of view of database design – it is a disaster.
Traditional uniqueness constraints are violated, query logic becomes more complex, and the likelihood of errors increases.

Approaches to Solving the Problem

Different countries used different strategies.

US Approach: Cover Stories

The system automatically creates plausible false information for users at lower levels.

For example:

Access Level	Displayed Information
Secret	Information about the real agent
Unclassified	Record does not exist or fictitious data

The goal is to hide the very fact that classified information exists.
However, maintaining such mechanisms significantly complicates application development.

UK Approach

When a user tries to access potentially classified data, the system simply returns:

Classified

This variant is technically simpler, but creates a new problem.
Users start requesting higher clearances just in case, because otherwise it is difficult for them to understand the reasons for denials.
This further encourages hyperclassification of information.

Covert Channels: A Fundamental Problem of MLS

The most serious limitation of multilevel security turned out to be covert channels of information transfer.
The Bell–LaPadula model controls only explicit information flows:

• read operations.
• write operations.
• accesses to system objects.

But it cannot fully control the use of shared resources of the computing environment.
That is where covert channels arise.

Storage Channels

Subjects at different levels use jointly accessible system resources.
For example, a high‑level process can encode information by creating or deleting objects.
Data transfer scenario:

1. A process at the High level creates a file – this means bit 1.
2. The file is not created – this means bit 0.
3. A process at the Low level periodically checks for the existence of the file.
4. The sequence of actions is translated into a message.

Formally, the Bell–LaPadula rules are not violated.
In practice, information leakage occurs.

Timing Channels

Even more dangerous are timing channels.
Instead of changing the state of objects, an attacker uses system performance characteristics.
For example:

• high CPU load means 1.
• no load means 0.

A low‑level process measures:

• disk subsystem response time.
• query processing delays.
• availability of CPU time.

Based on these measurements, it reconstructs the transmitted information.
Modern research shows that similar mechanisms underlie many microarchitectural attacks, including the Spectre and Meltdown families, which exploit processor cache behaviour.

Can Covert Channels Be Completely Eliminated?

Theoretically – yes.
Practically – almost never.
To completely eliminate covert channels, it is necessary to ensure absolute isolation of resources:

• separate processors.
• memory.
• I/O devices.
• disk subsystems.
• network interfaces.
• scheduling mechanisms.

In effect, this means abandoning the sharing of resources on which modern operating systems are built.
The price of such security is too high.
That is why most standards focus not on the complete elimination of covert channels, but on limiting their bandwidth.
The US Department of Defense historically used a guideline:

permissible covert channel bandwidth should not exceed 1 bit per second.

This is not enough for rapid exfiltration of large amounts of information.
However, even such a channel allows the gradual transfer of:

• cryptographic keys.
• passwords.
• agent identifiers.
• other critically important data.

Thus, the problem of covert channels remains one of the fundamental limitations of MLS to this day.

The Cascade Problem: Why Secure Systems Are Not Always Secure Together

One of the most unexpected discoveries in the development of multilevel security was the Cascade Problem.
Intuitively, it seems obvious that if two systems are individually secure, then their combination should also remain secure. However, in the field of information security, this assumption is far from always true.

How the Problem Arises

Imagine two certified MLS systems.
System A supports levels:

• Unclassified (U)
• Confidential (C)
• Secret (S)

System B supports levels:

• Secret (S)
• Top Secret (TS)

Each system has independently passed security evaluation and meets its respective requirements.
To exchange information, the systems are connected through the common Secret level.
At first glance, this solution appears secure. But a new path for information propagation appears:

1. In System B, a user at the Top Secret level writes data to an object at the Secret level.
2. This data becomes available to System A through the shared Secret level.
3. In System A, a subject at the Secret level can pass the information further – for example, to the Confidential or Unclassified domain, if the system’s policy allows such transformations.

As a result, information that originally belonged to the Top Secret level may become accessible to users with much lower privileges.

The Main Takeaway of the Cascade Problem

Security of individual components does not guarantee security of the composite system.

This is one of the most important lessons of security engineering.
Formal proof of system security rarely survives after:

• integration with external services.
• combining multiple trusted components.
• adding new data exchange channels.
• changing the architecture.

In essence, the cascade problem is a special case of a more general problem:
compositional security remains one of the most difficult unsolved problems in modern security engineering.

Modern Approaches: How the Industry Adapted MLS Ideas

Practical experience showed that building a universal operating system with full MLS support is extremely expensive, complex, and inconvenient for users.
As a result, the industry gradually abandoned attempts to implement an ideal MLS system and moved to more pragmatic approaches.

Type Enforcement: From Classification Levels to Types

One of the most successful heirs of MLS is the Type Enforcement (TE) model.
Instead of a complex system of clearance levels and compartments, two concepts are used:

• domains – execution contexts of processes.
• types – categories of system objects.

The security policy is defined by an explicit interaction matrix:

• which domains can read certain types of objects.
• which domains can modify certain types.
• which operations are completely forbidden.

For example:

Process	Allowed Access
Web server	Only to web content
DNS server	Only to DNS configuration
Mail server	Only to mail queues

Even if an attacker compromises the web server, they cannot access the DNS server’s data.

SELinux: A Practical Implementation of Type Enforcement

One of the best‑known implementations of this concept is SELinux (Security‑Enhanced Linux), developed by the US NSA.
In SELinux, the primary protection mechanism is Type Enforcement, not the classic MLS model.
This approach has a number of advantages:

More Understandable Security Model

Permissions are tied to component functions, not to abstract classification levels.

No High Water Mark Problem

Process privileges do not change dynamically based on read data.
This avoids gradual hyperclassification of the system.

Improved Service Isolation

Compromise of one process is much less likely to compromise the entire system.

Virtualisation: Separation Instead of Complexity

Another important direction was virtualisation.
Instead of building a single extremely complex MLS system, organisations began to use multiple isolated computing environments.
For example:

Virtual Machine	Purpose
High VM	Working with classified data
Low VM	Internet and public services
Management VM	Administration

Isolation is provided by the hypervisor, which controls interaction between virtual machines.
The advantages of this approach are obvious:

• administration is simplified.
• probability of configuration errors is reduced.
• impact of compromise of individual components is reduced.
• architectural flexibility is improved.

In essence, the industry decided not to complicate a single operating system, but to physically separate different levels of trust.

Unidirectional Gateways: Data Diodes

In some critically important systems, an even more radical approach is used – unidirectional gateways (Data Diodes).
The idea is simple:

• data can be transmitted in only one direction.
• the reverse channel is physically absent.

For example:

Open network  ─────────►  Closed network

Even with complete compromise of the less protected side, data leakage backwards is impossible.
Such solutions are actively used:

• in military infrastructure.
• at industrial facilities.
• in energy systems.
• at critical infrastructure sites.

MLS as a Security Philosophy: Hedgehog versus Fox

Let us recall the well‑known thought of philosopher Isaiah Berlin:

The fox knows many things, but the hedgehog knows one big thing.

MLS is an example of the hedgehog approach.
Its fundamental idea is simple and elegant:

security is achieved through strict control of information flows between classification levels.

However, the real world is much more complex.
Organisations need to take into account:

• business processes.
• human factors.
• collaboration needs.
• information exchange between departments.
• system usability.

That is why many modern security models use a more flexible approach, combining various protection mechanisms.

When Excessive Secrecy Becomes a Security Threat

Paradoxically, excessive adherence to MLS principles sometimes leads to the opposite result.

Hyperclassification of Information

If any information that comes into contact with classified data automatically receives a higher clearance level, a natural tendency arises to classify everything.
Over time, organisations find that:

• most data becomes classified.
• obtaining clearances becomes more difficult.
• information exchange slows down.
• operational efficiency decreases.

Isolated Information Islands

Excessive fragmentation leads to the emergence of many compartments between which there is practically no interaction.
Departments begin to work in information isolation.
Instead of increasing security, a new threat emerges:

critically important information does not reach those who truly need it for decision‑making.

Lessons of 9 september

The inability of various intelligence agencies to effectively share information was considered one of the factors that contributed to the failure to prevent the terrorist attacks of September 11, 2001.
The problem was not a lack of data.
On the contrary, there was enough information.
However, existing organisational and technical barriers prevented the combination of separate pieces into a coherent picture.
This is an important reminder that:

the absence of information sharing is also a security risk.

Human Factors and Complexity of Security Policies

Even the most sophisticated technical mechanisms are ineffective if users do not understand how to use them.
Overly complex policies lead employees to:

• bypass restrictions.
• look for unofficial ways to work.
• disable protection mechanisms.
• make decisions based on convenience rather than security.

As a result, the system becomes less secure, despite the presence of formally correct models.
Security must support the primary purpose of the system, not hinder it.

Conclusions

Multilevel security has become one of the most important milestones in the development of information security.
It was MLS that gave the industry:

• formal models of information flow control.
• concepts of mandatory access control.
• mathematical foundations of security analysis.
• ideas that later underpinned modern isolation mechanisms.

However, practical experience has shown that ideal theory encounters serious limitations:

• covert channels of information transfer.
• polyinstantiation problems.
• the hyperclassification effect.
• difficulties in composing secure systems.
• human factors and organisational constraints.

Modern solutions – SELinux, virtualisation, Type Enforcement, and unidirectional gateways – do not replace MLS ideas, but adapt them to real operating conditions.
The main lesson is that security is not only mathematics and formal models.
It is a quest for balance between:

• confidentiality.
• integrity.
• usability.
• organisational efficiency.
• cost of implementation and maintenance.

MLS remains an outstanding intellectual achievement in security, but at the same time serves as a reminder that even the most beautiful models must withstand collision with the real world.

Questions for Further Research

Despite decades of research, many MLS problems remain relevant.
Among the most interesting directions:

1. How can mandatory access control policies be made more understandable and convenient for administrators?
2. Is it possible to effectively limit covert channels in modern cloud and virtualised environments?
3. How can strict information flow control be combined with organisations’ need for rapid knowledge sharing?
4. How can MLS ideas be applied to safety‑critical systems, where errors can lead not only to data leaks but also to threats to human life?
5. What security models can provide a balance between formal rigour and practical applicability?

Answers to these questions will shape the development of information security in the coming decades.

Multilateral Security: Protecting Interests in a World of Overlapping Trust Relationships

If multilevel security (MLS) answers the question How do we prevent information leakage between different levels of classification?, then multilateral security solves a fundamentally different problem:

How do we organise the joint work of many independent participants whose interests may conflict, but who nevertheless must interact within a single system?

Unlike military security models, which focus on a vertical hierarchy of access, multilateral security operates in a world of horizontal relationships, where it is necessary to simultaneously account for:

• conflicts of interest.
• user privacy.
• legal restrictions.
• organisational processes.
• the economic incentives of various participants.

That is why we will consider this area not only as a technical problem, but also as a socio‑technical problem.

The Chinese Wall Model: Managing Conflicts of Interest

One of the best‑known models of multilateral security is the Chinese Wall Model, proposed by Brewer and Nash in 1989.
It was originally created for consulting companies, investment banks, and law firms, where employees work simultaneously with several clients who may be direct competitors.
The core task of the model is:

to prevent the transfer of confidential information between competing organisations through employees who have legitimate access to both sides.

Key Elements of the Model

The model relies on two key concepts.

Conflict of Interest Classes (COI Classes)

A COI class groups together organisations that compete with each other.
For example:

COI Class	Companies
Oil & Gas Sector	BP, Shell, ExxonMobil
Banking Sector	HSBC, Barclays, Deutsche Bank
Audit Services	PwC, Deloitte, EY

Company Datasets

Each organisation within a COI class has its own dataset.
For example:

Oil & Gas Sector
├── BP Dataset
├── Shell Dataset
└── ExxonMobil Dataset

Rules of the Chinese Wall Model

The model is based on the dynamic change of access rights.

Free‑Choice Rule

A user may access data from any organisation, provided they have not previously accessed data from competing companies in the same COI class.
Example:
* A consultant accesses documents from Shell for the first time.

At this stage, there are no restrictions.

The Chinese Wall Rule

After the first access, restrictions become permanent.
The user may only access:

• data from the same company.
• publicly available information.
• data from organisations that do not belong to the same COI class.

For example:

Access to Shell obtained
        ↓
Allowed:
✓ Shell
✓ Companies from other industries

Forbidden:
✗ BP
✗ ExxonMobil

Thus, the system prevents a conflict of interest from arising.

Practical Limitations of the Model

Despite the elegance of the idea, serious difficulties arise in practice.

Accumulation of Knowledge

The model controls direct access to data, but it cannot control human memory.
An employee may:

• analyse data from different projects.
• remember market trends.
• use accumulated knowledge when working with other clients.

It is impossible to completely eliminate such leaks.

Scalability Problems

Maintaining up‑to‑date COI classes requires ongoing involvement from:

• lawyers.
• compliance specialists.
• information security units.

In fast‑moving industries, lists of competitors quickly become outdated.
As a result, organisations are forced to choose between two extremes:

• excessive isolation of employees.
• weakening of security policy.

Healthcare Information Systems and the BMA Model

If the Chinese Wall model addresses commercial conflicts of interest, healthcare faces a different challenge:

how to ensure the availability of medical information for patient treatment while simultaneously preserving patient privacy?

This is the problem addressed by the British Medical Association (BMA) model.

It is important to emphasise:

the main threat to medical privacy comes not from external hackers, but from internal system users.

These include:

• curious employees.
• dishonest medical staff.
• insurance companies.
• administrative departments.

Main Threats to Medical Systems

Insider Breaches

The most common incidents include:

• viewing the medical records of celebrities.
• accessing data of colleagues and relatives.
• unauthorised transfer of information to third parties.

Centralisation of Data

Creating a single national repository of medical records greatly simplifies:

• administration.
• information sharing.
• research.

However, it simultaneously creates a single point of compromise.
One successful attack can lead to the mass leakage of data from millions of patients.

Emergency Situations

Rigid access control mechanisms can hinder the provision of care.
Doctors may need immediate access to patient data:

• in intensive care.
• when the patient is unconscious.
• during emergency surgery.

An overly strict security policy begins to contradict the primary purpose of the medical system – saving lives.

Principles of the BMA Model

The BMA model is built around several key principles.

Ownership of Information

The patient is regarded as the primary owner of their own medical information.

Informed Consent

Access to data is permitted only with:

• explicit consent.
• implied clinical consent.

Full Audit

All data accesses are logged.
The patient should be able to find out:

• who viewed the records.
• when it happened.
• for what purpose the access occurred.

Isolation of Sensitive Data

Particularly sensitive categories of information require additional protection:

• psychiatric records.
• HIV status.
• genetic information.
• reproductive health data.

Break‑the‑Glass

The system allows emergency access in critical situations.
However, every such instance:

• is mandatorily logged.
• is subject to subsequent review.

This allows a balance to be maintained between privacy and patient safety.

Inference Control: When Statistics Destroy Anonymity

Even the complete removal of identifiers does not guarantee privacy protection.
Attackers can reconstruct hidden information through statistical analysis.
This problem is known as Inference Control.

Tracker Attacks

The attacker issues a series of related queries.
For example:

COUNT(patients with disease X)

COUNT(patients with disease X, excluding patient Y)

The difference between the results allows one to determine whether a specific individual has the disease.

Differencing Attacks

Two almost identical samples are used.
If they differ by only one record, the difference between the aggregated results reveals the hidden information.

Protection Methods for Statistical Databases

Sample Size Restriction

The system prohibits queries that return too few records.
For example:

Minimum group size ≥ 5

The problem is that rare diseases automatically become vulnerable.

Cell Suppression

Sensitive values are hidden.
However, simply hiding one cell is not enough.
Other values in the table allow the missing indicator to be computed.
Therefore, related data must also be suppressed.
As a result, the statistical value of the information drops sharply.

Randomisation

Controlled noise is introduced into the data:

• rounding.
• record permutation.
• differential privacy techniques.

This makes deanonymisation more difficult while preserving overall statistical usefulness.
However, a fundamental trade‑off arises:

the higher the privacy, the lower the analytical accuracy.

An ideal solution does not exist.

Active Attacks and the Limits of Anonymisation

Up to this point, we assumed that the attacker only analyses existing data.
However, more sophisticated scenarios are also possible.

Active Attacks

If the attacker can alter the contents of the database, they can create conditions for subsequent deanonymisation.
There are examples demonstrating that even well‑anonymised databases remain vulnerable when the adversary has the ability to manipulate input data.

Lessons from the deCODE Project

Special attention is given to the Icelandic deCODE project, whose goal was to combine:

• medical data.
• genetic information.
• genealogical records.

It was assumed that anonymisation would ensure citizens’ privacy.
However, researchers showed that a person can be identified by the structure of their family relationships.
Even without a name, the combination of genetic and genealogical data made it possible to reconstruct an individual’s identity.
This case demonstrated an important conclusion:

technical de‑identification cannot always overcome social distrust and the complexity of real‑world data.

Ultimately, public pressure led to changes in the system’s operating principles and strengthened consent requirements for participants.

The Value of Imperfect Protection

Even if privacy mechanisms do not provide absolute protection, they still have enormous practical value.
If an attacker requires:

• significant time.
• specialised knowledge.
• substantial financial resources,

then mass misuse of data becomes economically unviable.
Thus:

imperfect protection is often effective enough to prevent systematic abuse.

It acts as a kind of prophylaxis against uncontrolled use of information.

The Residual Problem: Where Technology Ends and Policy Begins

At this point, it might seem that the main problems of multilateral security have already been solved. We have learned to prevent conflicts of interest, design access models for medical systems, and develop mechanisms to protect statistical databases.
However, it is worth emphasising that the most complex questions arise precisely where technical mechanisms intersect with organisational and economic realities.

This is called the Residual Problem.

The hardest security problems are rarely purely technical. More often, they arise at the intersection of technology, economics, law, and human behaviour.

The Interface Between Medicine and Finance

From an information security perspective, a medical system can be designed almost perfectly:

• strict access control.
• detailed auditing.
• separation of duties.
• protection of statistical samples.
• emergency access mechanisms.

However, there is an area where these measures cease to work.
This concerns the interaction between the healthcare system and the organisations that fund treatment.

Why the Problem Arises

To pay for medical services, information must be transmitted to insurers, government agencies, or other financial intermediaries.
Such data often includes:

• diagnoses.
• information about procedures.
• test results.
• prescribed medications.
• treatment duration data.
• psychiatric and genetic information.

Once transmitted, this information begins to exist in new systems, outside the original medical context.

Conflict of Interest

The interests of different participants differ significantly.

Medical organisations seek to:

• ensure patient treatment.
• minimise disclosure of information.
• limit the retention period of sensitive data.

Financial organisations seek to:

• prevent fraud.
• conduct expenditure audits.
• calculate insurance risks.
• retain data for long periods.

These goals often contradict each other.

Why Technical Measures Are Insufficient

The problem is that the insurance organisation receives the data legitimately.
It becomes a trusted participant in the process.
Consequently, traditional technical mechanisms lose effectiveness:

• encryption protects data only during transmission.
• access control regulates the initial acquisition of information.
• auditing records accesses, but does not prevent legitimate use.

Once data is transferred, the primary protection mechanisms become:

• legislation.
• contractual obligations.
• regulatory oversight.
• professional ethics.

Mission Creep

The phenomenon of Mission Creep – the gradual expansion of the original purpose of an information system.
This process usually happens imperceptibly.

How Mission Creep Develops

A system is created to solve a specific task.
For example:

storing medical data for patient treatment.

Over time, new stakeholders appear.
The information begins to be used:

• for scientific research.
• by insurance companies.
• by government bodies.
• by employers.
• by law enforcement.
• by marketing departments.

Each individual expansion seems reasonable and justified.
However, the cumulative effect leads to the original privacy guarantees gradually being eroded.

Why This Is Dangerous

The main problem is not the malicious intent of the participants.
More often, expansion occurs under seemingly benevolent pretexts:

• increasing efficiency.
• reducing costs.
• improving service quality.
• combating fraud.

But as a result:

data begins to be used in ways that users never gave informed consent for.

The Paradox of Centralisation

There is another important pattern.
Centralisation simultaneously improves management and increases risks.

Advantages of Centralisation

Unified databases allow:

• faster information exchange.
• reduced data duplication.
• improved analytical quality.
• better coordination between organisations.
• simplified administration.

Disadvantages of Centralisation

However, centralised systems have serious vulnerabilities.
They create:

A Single Point of Compromise

A successful attack provides immediate access to a huge volume of information.

High Attractiveness for Attackers

The more data stored in one place, the higher the attackers’ motivation.

Amplified Insider Threats

One privileged employee can access information on millions of users.

Easier Mission Creep

Centralised databases greatly simplify the reuse of data for new purposes.

Economics as a Factor in Privacy

One of the most interesting conclusions is the following observation:

the level of privacy is determined not only by technology, but also by the economic model of society.

Different healthcare financing models create different security risks.

State‑Centric Models

With centralised government funding, there is a natural tendency toward information consolidation.
Arguments usually include:

• increased efficiency.
• reduced costs.
• improved planning.

However, at the same time, the risk of excessive state control increases.

Insurance Models

When private insurers dominate, medical data becomes concentrated in corporate systems.
This leads to new threats:

• commercial use of information.
• aggressive risk assessment.
• secondary use of data for marketing purposes.

Decentralised Models

Systems with a high degree of personal responsibility for financing medical services reduce the incentives for mass data accumulation.
Consequently:

• the volume of centralised repositories shrinks.
• the attractiveness of such systems to attackers decreases.
• opportunities for mass analysis of personal information are reduced.

Why Technology Cannot Solve All Problems

Throughout this text, one key thought recurs.
Multilateral security is not only about algorithms and architectures.
Even the most sophisticated technical solutions are powerless without:

• clear legal constraints.
• understandable ethical norms.
• transparent accountability mechanisms.
• an organisational culture oriented towards protecting users’ interests.

Technology can implement restrictions.
But it does not determine which restrictions society considers acceptable.

Main Lessons

Multilateral security differs significantly from traditional access control models.
If MLS answers the question:

Who can access the information?

then multilateral security poses a much more complex question:

How do we ensure a fair balance between the interests of many participants, each of whom has legitimate but potentially conflicting goals?

That is why technical mechanisms are only part of the solution.

Conclusions

Within this text, several fundamental concepts have been examined.

1. The Chinese Wall Model

It allows conflicts of interest to be prevented by dynamically restricting access to data of competing organisations.
The main problem of the model is the difficulty of scaling and the impossibility of controlling users’ accumulated knowledge.

2. The BMA Model

It demonstrated that healthcare information systems require a special balance between:

• data availability.
• patient privacy.
• the need for emergency intervention.

3. Inference Control

It showed that even anonymised data can be used to reconstruct sensitive information.
An inevitable trade‑off arises:

increasing the level of privacy reduces the analytical value of the data.

4. Active Attacks and the Limits of Anonymisation

They emphasised that absolute anonymity in complex, interconnected datasets is practically unattainable.
However, imperfect protection mechanisms can still significantly reduce the risk of abuse.

5. The Residual Problem

It demonstrated that the most complex threats arise at the boundary between technology, economics, and organisational processes.
It is here that technical solutions cease to be sufficient.

Research Questions

Despite significant progress, many problems of multilateral security remain open.
Among the most promising research directions are the following:

1. How can we design systems that take into account the collective nature of some data, for example genetic information that affects the interests of relatives?
2. Is it possible to create adaptive privacy mechanisms that automatically adjust to the context of data usage?
3. How can we ensure transparency of secondary data use without overly complicating the user experience?
4. What economic models incentivise organisations to protect user data rather than extract maximum profit from its reuse?
5. Can we develop architectures that minimise the negative consequences of centralisation without losing the benefits of shared information use?

Final Conclusion

The main takeaway of this text is that multilateral security is not a mathematical problem, but a socio‑technical compromise.
Confidentiality and privacy are determined not only by the quality of cryptography or the strictness of access models.
They depend on:

• what incentives exist for system participants.
• how power over information is distributed.
• what legal norms operate in society.
• how willing organisations are to limit their own capabilities in order to protect users.

That is why designing secure systems requires an understanding not only of technology, but also of economics, law, psychology, and organisational behaviour.
Without this, even the most sophisticated technical mechanisms will inevitably collide with the limitations of the real world.