# Secure Internal Data Markets
## 4 A Generalised Model for Secure Internal Data Markets
### Model Overview  
In this section, we discuss the proposed generalised model for internal market places. Figure 1 provides an overview of the model. Contrary to other models, e.g., that proposed in [12], in this basic model, we formally only distinguish between data owners and data consumers (users) and do not model Value Added Service Providers (VAS-providers) as specific identities. In our case, this does not represent any limitation in the modelling of so-called prosumers (who both provide and consume data), as well as external VAS providers, due to the following:  
* Depending on the data record, prosumers act both on the owner's side and on the consumer's side, always according to the rules of the respective company. Therefore, it can also be modelled that a data owner acquires their own data, which can be useful with regard to the pre- and post-processing methods. * VAS providers--actors who use data from others, develop it further by, for example, enriching it with other data, or perform additional calculations--also act in both roles: they purchase the data to be processed as consumers, and act as owners when passing on the data. Any kick-backs to the owners of the original data are simply handled via policies, just as they are when used by a normal consumer. The core data market (referred to as Core Data Market in the figure) is, therefore, in contrast to the basic model in [12], the sole data hub in our concept, i.e., we do not provide for any data traffic outside the brokerage platform as part of the data market model. This is especially important with regard to the security concept since this is virtually negated by a planned second communication channel outside of the brokerage (which, of course, does not mean that no further data transfer takes place, but rather that it does so outside the data market on your own responsibility). Additionally, the core data market in the basic model consists of three different parts:  
* The storage entity, a secure, hardened and highly efficient database containing all data held in the data market. * The brokering module, an engine that maps the trading of the data. This includes not only the provision of information about the data to enable a trade, but also the necessary methods for billing, payment and policy management. In addition, the brokering module has to call on the selected post-processing routines that need to process the data before actual delivery to the respective data recipient. * The pre- and post-processing modules (marked in yellow in Figure 1) are of special importance for the pre- and post-processing of the data, as they are quasi internal VAS providers for important tools that a data market should provide. The main difference between these two types of methods is the time of application--the pre-processing methods are executed before the data is stored in the repository, whereas the post-processing methods are executed at the time of data delivery by the brokering module. While the pre-processing module do not need additional intelligence included, as they are invoked on the raw data and never run again on any data residing in the storage entity, the controller for the post-processing modules requires far more control over the whole brokering process; in many anonymisation techniques, it is of vital importance to keep track of the data that the specific recipient has already received at the time of provisioning with a new batch of data. This is especially important for fingerprinting, as receiving two differently fingerprinted copies of the same data set might enable a recipient to remove parts of the fingerprint. Especially when using fingerprinting methods based on anonymisation [33], this also requires tracking capabilities on the side of the post-processing modules. Of course, interfaces are necessary to connect the data market to owners and consumers.