securing manet databases using metadata and context ... - IEEE Xplore

SECURING MANET DATABASES USING METADATA AND CONTEXT INFORMATION Kun Sun, Roger Xu, Julia Deng, Leonard Haynes, Jason H. Li Intelligent Automation, Inc. Rockville, MD

Le Gruenwald, Carlos Sanchez, Gifford Weber School of Computer Science, University of Oklahoma

ABSTRACT Existing commercial database security products cannot guarantee to provide the same level database security in Mobile Ad-Hoc Networks (MANET) as in wired networks. In this paper, we presented a secure MANET database system that uses metadata and context information for database access control. First, we designed and implemented a context-based security model that uses context factors, such as location and velocity, to make security and trust decisions on granting database access. This model can detect the abnormal behaviors from compromised mobile nodes and alleviate the damages from the attackers. Second, we implemented a metadata-based mandatory access control mechanism to achieve multiple security level across different security domains. In summary, we integrated the context-based access control model with the traditional mandatory access control model to ensure access control for MANET databases.1 I. INTRODUCTION Mobile Ad hoc Networks (MANETs) have been widely used in many applications, such as for battlefield communication, in medical experiment, and for scientific exploration. In 1991 the US Army established the concept of Land Warrior [1] in order to integrate small arms with high-tech equipment to increase the command and control of soldiers on the battlefield. One of the components of this system is the Integrated Helmet Assembly Subsystem (IHAS) which is a computer and sensor display mechanism mounted on the soldier's helmet to provide him with not only views of computer-generated graphical data, digital maps, intelligence information, and troop locations, but also the capability of transmitting information back to commanders. A local database on soldiers facilitates data collection, data sharing, and data management.

Michael J. Mayhew, CDIS Group Lead, AFRL/RIEB

bases. However, on the battlefield, there are no general communication protocols that are used to signify to “home base” that a soldier is captured. Therefore, we must face the situation when the electronic devices have fallen into enemy hands and the key material that is used to protect the database is compromised. Existing commercial database security products are either infrastructure-dependent, making them unsuitable for mobile ad hoc networks, or only tackle external attackers and are vulnerable to attacks from compromised nodes in hostile environments. In this paper, we presented a secure MANET database system that can detect compromised nodes using context information (e.g., location, temperature) and prevent information leakage by enforcing the multi-level security mechanism. We designed and implemented a context and trust security model, called ContextTrust, which allows us to evaluate a context based security policy by computing the risk of each context variable according to its changes. It includes a flexible and adaptable architecture and a language for expressing context based security constraints in security policies. Moreover, we implemented a metadatabased multi-level security model by embedding IC Information Security Marking (IC-ISM) standard [7] in the XML files to address classification labeling in databases. IC-ISM gives intelligence producers a vocabulary of agreed-upon XML attributes developed to support the Controlled Access Program Coordination Office (CAPCO) guidelines for security markings. We developed a software prototype that implemented most of the core functionalities specified in the secure MANET database system. The advantages of our approach can be summarized as follows.

Because mobile nodes are more prone to being captured and compromised by the enemy, it is critical to prevent compromised nodes from accessing normal nodes’ data978-1-4244-2677-5/08/$25.00 ©2008 IEEE

1 of 6

•

Insider detection: the context based security model can evaluate a context based security policy by computing the risk of each context variable in the policy, and detect insiders whose behavior deviates from normal.

•

Insider Deterrence: the multi-level security mechanism can deter insiders from obtaining the da-

tabase information that they are not authorized to access.

•

We focused on designing a secure MANET database system using a context-based security model and a metadatabased access control model, and implementing the core functionalities to prove the feasibility, correctness, and robustness of the proposed approach. II. SYSTEM ARCHITECTURE Figure 1 shows the system architecture of our secure MANET database system. It consists of four major components:

•

Metadata-based access control: We used the Intelligence Community Metadata Standard for Information Security Marking standard (IC-ISM) [7] to provide security attributes in the XML-based metadata, which records security related information for the database. We implemented Mandatory Access Control (MAC) using IC-ISM. Our system can accommodate various access control policies (e.g., DAC, MAC, or RBAC) using XML-based metadata. Key management: it is responsible for maintaining all kinds of keys (e.g., public key, secret key, or group key) in the system for communication and database secure operations. We implemented a public key infrastructure using Elliptic Curve Cryptography.

In this paper, we focus on presenting the design and implementation of the context-based security model and the Metadata-based access control model. III. CONTEXT-BASED SECURITY MODEL

Figure 1. System Architecture of Secure MANET Database

•

•

Reference monitor: Whenever a node tries to access another node’s database, it must do so via the reference monitor, which enforces the access control policy. The reference monitor handles all the communications between the client and the database system, so that it can guarantee authentication, authorization and confidentiality for the database. In other words, the reference monitor is responsible for integrating all the security components in the system as a complete secure database solution. Context-based security model: using our context-based security model, a node may maintain a trust value set for other nodes. It only allows the node that has a trust value greater than the predetermined threshold value to access the information in its local database. When the node detects a malicious node with solid evidence (e.g., conflicting commands with signatures), it adds the malicious node into a blacklist and decline its future queries.

We designed a context and trust security framework, called ContextTrust, which allows us to evaluate a context based security policy by computing the risk of each context variable in the policy according to its changes. Moreover, ContextTrust introduces a multi-level trust framework in which trust for an entity is computed using not only the results of past interactions (number of events positive and negative - during a specific time window), but also the recommendations given by other entities and the quality of the context data provided. ContextTrust determines the quality and the validity of a recommendation using statistical measures such as standard deviation and correlations. In ContextTrust, the behavior of a context variable is modeled using a random walk [2] framework (the changes of a variable are assumed to be normally distributed [3]). To simulate future values, a Monte Carlo algorithm is used. Finally, risk is measured using the Percentile function [6] by comparing the current context-variable value with those produced by the Monte Carlo method. The risk evaluation performed in ContextTrust does not take into account the correlation (associations) that the context variables in the policy may have, and we consider it as future work. We defined five roles that are necessary in this contextbased trust security framework: a Context Owner (CO), a

2 of 6

3). The soldier responds to the query in Step 2 by querying the context data database and sending the required context information the commander needs for risk and trust evaluation. If a sergeant has been contacted by the commander, he/she will respond to the commander’s context data request. 4). The risk engine on the commander is invoked to calculate the risk associated with the context data. 5). The commander sends to the soldier the decision to either grant or deny access to the CAO. If the security request has been granted, the commander gives the CAO (which has been loaded from the object database) to the soldier. 6). After the simulation horizon has passed the soldier sends an update for the context data previously sent in Step 3. 7). Upon receiving the context data update from the soldier, the commander invokes the trust engine to calculate the new trust value for the soldier. 8). The commander stores trust (interaction) information in the trust database.

Context Provider (CP), a Context Petitioner (CR), a Context Security Analyzer (CSA) and Context Accessible Object (CAO). • Context Owner (CO): a Context Owner role is played by any entity that owns and possibly collects context data and decides which, when, where, how, and by whom the context data may be stored, distributed, and processed. • Context Provider (CP): an entity playing the Context Provider role not only controls access to the context data according to the CO’s policies and restrictions, but also provides means to index, publish, and create usage and history patterns about the context information. • Context Accessible Object (CAO): any service or object, the access of which is controlled by a security implementation that may have been expanded with context data constraints, is assigned the role of CAO. • Context Security Analyzer (CSA): an entity playing the Context Security Analyzer takes context information (or risk factors/variables) from multiple CPs, and according to a security policy, it either grants or denies access to a CAO. Context Security Analyzers must take into account the level of trust among the different components before rendering a decision. • Context Petitioner (CR): any entity that acts as a security principal and requests access to an object by submitting a request to a CSA. Figure 2 describes the context security framework architecture. The XML based communication between the architecture components has been done through the following eight steps: 1). A petitioner entity (soldier) starts a security transaction by sending a message to a CSA entity (commander) requesting access to a CAO (stored in the object database). 2). The commander loads a security policy that controls access to the requested CAO from the policy database. After reading the policy, the commander then sends a request to the soldier in order to gather the required context information needed by the policy. In addition, the commander may send a context data request to one or more Sergeants acting as context providers (CP) to gather data about the soldier.

Figure 2. Framework Architecture In the following, we present the steps to design and implement the context-based security model. A. Identifying context risk factors A context risk factor is a variable that is accessible to an entity and the movement (value change) of which may impact the accessibility of an object in a context based security system. In other words, a context risk factor is measurable information that surrounds a user, which may have an implication in the outcome of a user’s task. The following context risk factors were identified: (1) Location / Proximity; (2) Velocity; (3) Power Resource/Level; (4) Connection mode / rate; (5) Temperature; (6) Sound; (7) Wind Speed; (8) Altitude; and (9) Acceleration.

3 of 6

B. Measuring Risk We developed a Monte Carlo based algorithm, in which the maximum expected change of a context variable for a given confidence value is measured. Such change is used as input to a constraint in a security policy to restrict or allow access to an object during an evaluation period (horizon). Using the proposed algorithm, we can simulate future values for a context variable and computed the risk (maximum expected change) using the percentile function. Below we describe the main characteristics and definitions of this model. 1). Definition of risk factor time series and operations. A risk factor time series is a collection of observations - made by an entity - indexed by the time (and/or date) of each observation. An entity collects the risk factor data beginning at a particular time (e.g. t = 1) and ending at another (e.g. t = T). 2). Definition of a context variable return. •

rt = ln(1+ Rt ) = ln

Pt Pt−1

3). Definition of context factor value normalization used for context variable aggregation. Because the context risk factors in a policy may have different units (i.e. power level, distance, etc.), it becomes necessary to define a way to aggregate the values of the different risk factors in order to track the overall change in a security policy. Let ς be the linear normalized value of a context security policy (group) G consisting of M risk factors defined as: M

∑

ς =

i =1

5). Definition of a Monte Carlo based algorithm to generate future values of context variable. The process to generate future scenarios is to generate standard normal variants and use the equation Pt = Pt−1e μ +σ tε t , εt ~ IID N(0,1) to produce future values. 6). The risk contribution of a context variable is measured using the percentile function. We use the percentile function to determine the maximum error amount (risk) that would be incurred in the estimation of a context variable change during the evaluation period. C. Computing Trust We proposed a multi-level trust framework in which trust for an entity is computed using not only the results of past interactions, but also the recommendations given by other entities and the quality of the provided context data. The simple trust relationship ( A → B )Wt is a vector with three components – data trust, interaction trust, and recommendation trust – and is represented as follows.

⎛ P

M

⎝ i=1

i=1

P

M

i

i=1

P

M

P ⎞

i

i=1

i

{ςt }t∞=−∞ = (ς1,ς2,…ςM ) = ⎜⎜∑ i,1 ,∑ i,2 , ∑ i, j ∑ M,t ⎟⎟ c c c c i

⎠

where Pi,j is the value of risk factor i at time j. 4). Definition of a random walk model to describe the change of a context variable. • rt = σ t ε t ,ε t ~ IID N (0,1) •

1).

Pt = Pt −1e μ +σ t ε t , ε t ~ IID N (0,1)

4 of 6

A

DB represents the trust between the entities A

and B based on the context data provided by B (or on behalf of B) to A. We modeled the trust component for a context factor C in terms of the volatility of the returns and the percentage of missing elements in a context time series. That is, ContextTrust rewards with more trust a time series whose returns have low volatility (less variability) and low degree of missing observations (higher degree of quality).

Pi ci

where Pi is the value of context risk factor and Ci is the normalized scaling amount for risk factor. It then follows that a time series for ς values can be readily defined as M

(A → B)Wt = [A DB ,A E B ,ϕ RB ]

2).

A

E B represents the trust derived from the expe-

rience or interactions between A and B. ContextTrust incorporates the calculated risk of a context variable C into a trust measure by rewarding with more trust whenever a positive experience occurs. That is, trust is increased when the (actual) future value of a context variable C does not exceed the risk in our prediction. Inversely, whenever our prediction is incorrect, ContextTrust decreases the trust amount for the interacting entities.

3).

ϕ

• Multiple constraint groups are supported. 5). Messages exchanged by entities are XML based done through socket connections 6). Simple GUI interface for two entities (soldier and commander) to demonstrate a security interaction.

RB represents the cumulative effect of all rec-

ommendations that A receives about B. The recommendation component trust is evaluated on the basis of the time series correlations supplied by the context providers of a context variable C. That is, ContextTrust rewards with more trust highly correlated data and penalizes uncorrelated data. 4). Trust computation In ContextTrust we introduced a concept called the value of a trust relationship. This is denoted by the C expression τ A, B and is a number in [− 1,1] ∪ {ψ } .

τ A,C B is computed as follows: C

τ AC,B = W ( A→ B)W = WD ⋅ A DBC + WE ⋅ A EBC + WR ⋅ϕ RBC t

In ContextTrust W is a weight vector of the form W = [WD, WE, WR] - data, interaction, recommendation - such that W D + W E + W R = 1 . These weights represent the level of importance entity A gives to each of the context trust component values in the computation of the overall trust value. Finally, in ContextTrust a trust value can be mapped to a category as follows. τ AC, B

⎧[ − 1, 0 ) ⇒ it is distrust ⎪ 0 ⇒ it is neutral ⎪ = ⎨ ⎪ ( 0 ,1] ⇒ it is trust ⎪⎩ψ ⇒ undecided

⎫ ⎪ ⎪ ⎬ ⎪ ⎪⎭

D. Prototype We developed a Java based prototype for the contextbased security model, in which entities (i.e. soldier and commander) are represented by a service object. Each service implements different functions according to the role played by its assigned entity. The main characteristics of the prototype are: 1). Java Service Oriented Architecture (SOA) 2). Risk Engine. It implements the risk model for multiple independent risk factors 3). Trust Engine. It implements all three trust formulae, but does not invoke recommendation trust as recommender entities were not implemented 4). XML Schema definitions of Context Security Policies • It provides support for multiple context, risk and trust value constraints. • Each constraint belongs to a constraint group.

IV. Metadata-based Access Control Model Metadata is the data about data. Metadata may contain various information about the source data, such as security classification and other security-relevant information. We used Metadata to help provide information assurance in a secure database system. We implemented the multi-level security (MLS) [4] mechanism in our database system using the IC Information Security Marking standard (ICISM) [7] to mark the security classes of the objects in the database. The MLS mechanism can prevent insiders from accessing data in the database that they have no right to access. A. IC-ISM XML Schema The IC Information Security Marking (IC-ISM) standard [7] gives intelligence producers a vocabulary of agreedupon XML attributes developed to support the Controlled Access Program Coordination Office (CAPCO) guidelines for security markings. CAPCO is the authority for the development and use of the classification marking system for the Intelligence Community. The ISM XML schemas consist of a set of 18 XML global attributes and a set of controlled vocabularies from which the values of certain attributes may be selected, distributed as both an XML entity set and W3C XML Schema (WXS). These two forms can be incorporated into any XML document type definition (DTD) or W3C XML Schema. In our system, we used the W3C XML Schema for specification of metadata for classification and controls markings. Because the IC ISM schema is not a standalone construct, we imported it into a parent XML schema called “metaschema.xsd”, which was defined according to the primary category sets in the Department of Defense Discovery Metadata Standard (DDMS, Review Version 1.2 [8]). As shown in Figure 3, our XML schema contains the following elements and attributes:

5 of 6

• • •

Security attribute set: security attributes in ICISM. Table Name: a name given to the table. Table Identifier: an unambiguous reference to the resource within a given context.

• • • • • •

Creator: information about the entity responsible for generating the resource. Publisher: identification of the entity responsible for releasing the data asset. Date: a calendar date associated with an event in the life cycle of the table. Table created: date of creation of the table. Table Posted: date the table is posted to a shared network or system. Table Valid Til: date that the table should be removed from the database and the metadata.

In this paper, we presented a secure database system that can provide secure data distribution and secure data sharing in Mobile Ad Hoc Networks. In particular, our system can detect compromised mobile nodes and insiders by using their context information and deter further information leakage by deploying a multi-level security mechanism. To increase the capabilities of our system on detecting/prevent attacks from malicious nodes in MANETs, new elements such as intrusion detection system could be included into the framework. Acknowledgement This work was supported by U.S. Air Force Research Lab (AFRL) under contract number: FA8750-08-C-0008. References

• • •

Figure 3. XML Schema for Access Control Table Info CutOff: date of the last input, also referred to as Information Cutoff Data (ICOD). Language: primary language of the intellectual content of the table. Description: an account of the content of the resource.

B. XML-based Metadata and Metadata Parser Based on our XML Schema, we were able to generate XML files to provide different classification granularities (i.e., database-level, table-level, tuple-level, and elementlevel) on the data in databases. We implemented a simple table-level classification using XML files to records the security information associated with tables in the database. We used JDOM [5] as the XML parser to process the XML file. JDOM is a Java API for representing XML contents. JDOM complements Simple API for XML (SAX) and Document Object Model (DOM) by simplifying XML document manipulation. The XML parser reads element and attribute information from XML files and help enforce the access control policies.

[1]. FAS Military Network Analysis. “Land Warrior.” Federation of American Scientists, http://www.fas.org/man/dod-101/sys/land/landwarrior.htm, accessed January 2007. [2]. Weisstein E. W. "Random Walk--1-Dimensional." From MathWorld--A Wolfram Web Resource, http://mathworld.wolfram.com/RandomWalk1Dimensional.html, accessed August 2006. [3]. Sanchez, C., Gruenwald, L., Sanchez, M., “A Monto Carlos Framework to Validate Context-Based Security Policies in Pervasive and Mobile Environment”, to appear in SIGMOD International Conference on Data Engineering for Wireless and Mobile Access (MobiDE), June 2007 [4]. D. Bell and La Padula, “Secure computer systems: unified exposition and MULICS”, report ESD-Tr-75306, The MITRE Corporation, Bedford, Massachusetts, March 1976. [5]. JDOM http://www.jdog.org [6]. Uryasev S. “Introduction to the Theory of Probabilistic Functions and Percentiles (Value-at-Risk).” Probabilistic Constrained Optimization: Methodology and Applications, Kluwer Academic Publishers, ISBN 9780792366447, pp. 1-25, November 2000. [7]. IC-ISM https://dnidata.org [8]. Department of Defense Discovery Metadata Standard (DDMS) http://www.afei.org/news/ddms.pdf

V. Conclusion

6 of 6