• Enforcement: Defines how the security policies, i. e. access control, process control and granularity control policies are enforced. An important fact is the enforcement scalability.
In a distributed environment the enforcement should not happen at a single site but should rather be done in a distributed manner to avoid bottlenecks or single point of failures.
These protection goals build the basis for the comparison of related work in the section that follows. The protection goals also define the main functionalities of our security framework which is the foundation of our system implementation as shown in Section 5.5.
5.3 Related Work
This section introduces some well-known security concepts in the context of DSPS and pro-vides a comparison according to the protection goals raised in Section 5.2.2. A DSPS is charac-terized by an asynchronous and distributed execution of long running queries. This represents a major challenge since access policies might change at runtime which require the use of ap-propriate measures in order to ensure changed security policies being enforced. These changes should not influence ongoing operations as this would affect currently running queries neg-atively. On the other hand, new policies should be enforced as quickly as possible to avoid unwanted visibility of data while avoiding centralized structures, as they constitute a single point of failure. Table 5.1 provides a comparison of well-known concepts in this area w.r.t.
the protection goals presented in Section 5.2.2. These single concepts are described in detail in the following. An overview of these systems can be seen in Chapter 3. However, in this chapter we focus on the security aspects and therefore wrap up the state-of-the-art of security mechanisms in the context of DSPSs.
In the year 2005,Secure Borealis[88, 89]—which extended Borealis [2]—was one of thefirst DSPS which had an integrated security concept to control data access. The security concept is based on a general DSPS architecture to which additional components that enable access control were integrated. The query processing in Secure Borealis is performed in a distributed fashion. Communication between the single computation nodes is encrypted to ensure data integrity and to prevent data from being read by third parties. In contrast to the query pro-cessing, the security concept of Secure Borealis is based on a centralized structure to enforce security policies. This circumstance is a potential bottleneck and represents a possible single point of failure since all data first has to pass through this component before it can be for-warded to subsequent operations or the target. This centralized component enforces access control and consists of two parts, an Object Level Security (OLS) and a Data Level Security (DLS) component. The OLS component is active before the runtime of queries and the DLS component is active during query runtime. The OLS component is linked to a role model that assigns to each subject (e. g. a user) a specific role that holds its associated access permission.
Subjects are identified by a username and password combination. Based on this information the OLS component decides whether a subject is allowed to access objects (e. g. data). All
ob-System AuthenticationAccessControlProcessControlGranularityEnforcement
AuthenticityActionLiabilityIntegrityConfidentialityAcceptanceDataExtent Control SecureRoleSubjectEncryption Centralized——"AllorNothing" CentralizedBorealisControlSupervisor
ACStreamSubjectSubjectPredicatePredicate— Time-based"AllorNothing"RewriteQueriesWindows FENCESubjectSubjectPredicateSS+Operator——"AllorNothing" RewriteQueries/SecurityPunctuations
NexusDSRoleSubject Encryption/SIFilter ComputationParametrizableLoDFilters AugmentQueries/CertificatesNodeSetWindowsSecurityPunctuations
Table5.1:Systemcomparisonw.r.t.theprotectiongoalsauthentication,accesscontrol,processcontrol,thepossibilityofcontrollingtheaccessgranularityofcontextdata,andhowtheprotectiontargetsareenforcedbytherespectivesystem.
5.3 Related Work 159 jects a subject is not allowed to access are hidden. The DLS component enforces the security policies at query runtime and consists offilters that are applied to thefinal result of the queries to remove objects (data elements) from the resulting data streams, to which the subject has no access. This in turn means that the access control enforcement is performed after thefinal data elements are determined, i. e. the entire query processing is done. This strategy might discard costly calculated data resulting in a waste of resources.
The access controls in ACStream [29] can be defined on a data stream level for data ele-ments and their attributes. ACStream builds upon Aurora [3]. Access control restrictions are defined by expressions that describe an explicit assignment of access rights to certain subjects.
To illustrate this, imagine a data stream holding positions where each data element has an ID-attribute and a location-attribute. An expression in ACStream can define read access for a subject A, if the ID-attribute has a certain value, or the position is within a defined quadrant.
A special feature of the concept is the possibility to define temporal constraints. A temporal restriction allows access to data elements which are situated in a certain time interval. The start time and end time can be explicitly defined and the time interval is provided by defining the absolute time interval size and the interval step size. ACStream enforces access control by rewriting queries. The rewrite process selects security operators instead of regular operators to carry out the defined access control constraints. Four different types of security operators are available: Secure View processes an input stream by applying the access restrictions and returning a view of the data stream with only data elements meeting the access restrictions. Se-cure Readoperatorsfilter data elements and remove attributes,Secure Joinoperatorsfilter the output data streams composed of multiple input data streams, andSecure Aggregateoperators control aggregate functions.
FENCE [98, 99] usessecurity punctuations to enforce access control to data streams. A se-curity punctuation2 is a data element within a data stream that defines the access policies on the respective data stream. The security punctuations are woven into the original data streams when access restrictions are to be supported. If at some point in time the GPS position stream is restricted to a certain subset of subjects (users) a corresponding security punctuation is gener-ated and is woven into the output stream to tell subsequent operations about the access restric-tion setting which has changed. Security punctuarestric-tions are implemented by two punctuarestric-tion types: A data security predicate which controls access to data elements and a query security predicate which controls access to queries. To control data access two possible approaches are proposed. The first approach is a security filter approach which provides the use of the so-called security shield plus operator (SS+ operator). SS+ operators are integrated into the original query and filter data elements according to security punctuations. Here filtering for security punctuations is directly integrated within the query processing. The second strategy consists ofrewriting the query and relying on existing operator implementations. To support thefiltering of security punctuations the query predicates must be rewritten such that—beside
2Recall: A punctuation is a data element within the data stream which carries arbitrary information useful for the DSPS. It may carry information about the characteristics of the data stream. Punctuations have been introduced in Section 3.3.
the original predicate condition—the selection operatorfilters out data elements which do not meet the access restrictions defined by the security punctuations.
5.3.1 Discussion
The considered approaches propose interesting features and give valuable directions. How-ever, the approaches are not suitable for NexusDS. The query rewriting to enforce the security policies is a major drawback since a complete rewrite functionality presupposes the query processor to know semantically all involved operators. NexusDS is open and extensible, thus allowing arbitrary operators. The centralized approach in Secure Borealis guarantees that security policies are enforced, but it is not feasible since it represents a potential bottleneck limiting the amount of queries that can run in parallel. Secure Borealis and ACStream in prin-ciple allow to integrate custom operators into the system. However, no precautions are taken to prevent uncontrolled outflow of data. Moreover, the data access granularity is not adjustable to domain-specific needs. Some data providers generally permit other subjects to use any of their objects (e. g. context data such as GPS positions). But eventually a subject may also want to restrict the access to and processing of the exact objects to an exclusive set of subjects, by at the dame time providing the data to others, only less accurate. Finally, the approaches pre-sented only consider access control mechanisms. However, the way data is being processed is also of importance. E. g., certain data should not cross certain administrative boundaries and thus processing should be limited to a certain set of processing nodes.
Our augmentation approach is an extension on the SP graph level and shows some important advantages compared to the other approaches presented:
• The semantics of the operators need not be known in order to adapt the SP graph to meet the security restrictions.
• The operator model presented isflexible in the way it embeds the operator within a box.
Thus also operators which are not designed to work with the security framework are still usable.
• Our approach allows to define and integrate arbitrary granularityfilters to adapt the data details and to still allow processing them at the cost of some reduction in data quality.
In the following sections we present the architecture and the characteristics of our security framework as well as the augmentation technique that is implemented as part of NexusDS.