modelling security web services for monitoring and ...

2nd International Conference “From Scientific Computing to Computational Engineering” 2nd IC-SCCE Athens, 5-8 July, 2006 © IC-SCCE

MODELLING SECURITY WEB SERVICES FOR MONITORING AND REPLICATION Ivo I. Georgiev1, Iliya K. Georgiev2 1

JetEye Technologies, Inc. 244 Jackson St., Suite 200, San Francisco, CA 94111, USA E-mail: [email protected] 2

Department of Mathematical and Computer Sciences Metropolitan State College of Denver, campus box 38, Denver, CO 80217-3362, USA E-mail: [email protected] Keywords: web services, security model, trustworthiness, monitoring and replication. Abstract. In the paper we address the trustworthiness of computational engineering distributed systems based on semantic web services. We present a security model with three components: web service messaging, monitoring and replication. Web service messaging has well standardized scenarios that we use as a foundation of our work oriented to trust monitoring and replication control. The model incorporate two types of trust web services: local trust web service in every node to expose its trustworthiness, and monitoring web service to collect the state of the system. Prototyping these web services we consider approaches to establish the trustworthiness level of systems and to control secure replication of the engineering data.

1

INTRODUCTION

All engineering fields, including computational engineering (CE), are accepting and deploying higher-level distributed systems based on web services. The designers are at a dominating trend to implement semantic web technologies in different domains. In that sense, we recognize that the distributed engineering process is often integrating several apparently disparate concepts to create solutions to existing scientific problems. One approach to computerizing the engineering process is creating ontological models of the problem domain and reasoning about them with highly structured pre-existing knowledge of possible approaches to a solution. Ontologies can give uniform understanding and access to the pool of engineering models. Moving forward, we address the security as a key area to implement engineering distributed architecture. Ensuring the integrity, confidentiality and security of web service messaging is focused by the software vendors that provide standard-based secure message protocols. We pursue other two avenues: monitoring the trust level of the distributed system, and replication of the critical engineering information. For this paper, we propose an approach for modelling of multi-tier secure CE system that is based on analyzing the machine-understandable semantic web information that establishes the trustworthiness level of each system in a distributed CE. The web services of the participating nodes communicate with a variety of nodes in order to properly exchange information about the security solution space. Contribution of the paper. We have concentrated: • to security model, exposing the role of untrusted and trusted CE users, trusted CE servers, trusted administrators, untrusted communication media, etc. • and to prototyping of functional web services that control the replication and the monitoring. 2

WEB SERVICES AND SECURITY

Web service technologies [15] are becoming a standard that delivers integrated interoperable solutions to most of the engineering distributed system. The basic idea of the web services is based on two classical models of Internet applications: the web model (web browsers request from the web servers to receive some document), and the remote method invocation (a host invokes a method from other host). In the web services model, the web document retrieval plays the role of method invocation, arguments are encoded into URI, and results are packed in a document that the server sends back. The requests are encoded into SOAP (the web services XML standard for service invocation), the information is structured into WSDL (the web service description language), and the

Ivo Georgiev, Iliya Georgiev

service is discovered and identified using UDDI specification. In addition, the web service architecture incorporates functions that are important for distributed computing: transaction processing, request queuing, publish-subscribe event notification, standards for encoding the type information into, and so on. From the security perspective, web services, combined with the recent rampant online threats, are an untrustworthy technology and contains the seed of a future debacle. The correspondence between browser and web site remains very visible. Moreover, developing malicious web services is easy using any standard development tool. In our research, we claim that the security of the web service architecture has the following components: 1. Web message secure technologies that define core facilities for protecting the integrity and confidentiality of the messages [10]. It is a R&D problem that is addressed in the initiatives of computer vendors like IBM and [8] Microsoft . In their joint project they have created practical frameworks that bring together incompatible security methods such as public key infrastructure, Kerberos authentication, digital signatures, and others. 2. Trustworthy technology for monitoring the security health of a massive critical infrastructure at hundred or thousands of locations, with fault diagnosis occurring automatically and in real time and all of this secures against intrusion [1]. 3. Replication technologies in a robust and secure manner that ensure geographically distributed access to the critical engineering data in the event of a fault and offer a means to build components that react in a coordinated way after disruption [1]. In Web-driven engineering computing, it was observed that the servers are powerful and fault-tolerant, but are still vulnerable to an unexpected catastrophe such as natural disaster or planned attack. All of the stored data could be destroyed instantly. In order to make mission-critical data operational even after a devastating strike, it is highly imperative to have distributed information and remote disaster recovery. In this research we present a security model of web driven engineering system and concentrate to the relatively new second and third technologies – monitoring and replication. 2.1 Security Model Today's web service engineering systems include a broad combination of nodes: mobile devices, engineering workstations, manufacturing numerical control computers and servers, wireless laptops in workshops, networked attached storage, outsourced data centres, and others. All of these Internet hosts communicate according to the classical client server paradigm - the client is a requester; the server is a web service. Because every node runs several applications, it could present several requesters and web services to the partner node. Further, we will consider the following configuration of an engineering distributed system: • Sensors, stationary or mobile devices, and other computerized equipment that select data in real time; • Personal workstations (design stations, manufacturing group NC computers, control equipment, etc.) with local databases that provide different product models; • Distributed servers with global remote databases; • Supercomputer clusters that solve computational intensive scientific and engineering tasks; • Trusted authentication servers that provide security tokens to the other computers. The security presented model (Figure 1) is a generalization of other existing models and is based on the establishment of the degree of trustworthiness of each system node [3,4] . The system nodes can request for web services only if their request incorporates so called security token. We define a security token as a representation of security-related information (e.g. user name/password, public key certificate, Kerberos tickets and authenticators, mobile device security tokens from SIM cards, username, etc.) that declare the identity of the partners[8] . Untrusted partners (requesters). Real time equipment and personal workstations are inherently untrustworthy, in the physical sense, since they can be easily moved, connected to arbitrary network addresses, or run an unknown operating system that can access the network. The same observation applies to some servers. Web services run on behalf of application software. It is untrusted because one cannot rely on it to make only the legitimate authorized requests on behalf of the application. Unless physical control of a client workstation is assured and cryptographic signatures are used during the operating system booting process, one cannot determine whether the client workstation runs a trusted o. Untrusted communication media and untrusted intermediate systems. Communication media (twisted copper pair, coaxial cables, satellite links, etc.) can generally be assumed to be untrustworthy. Measures can be taken to detect some attacks at this level, such as wiretapping, but they cannot be prevented. Gateways, routers, and network front ends can fall into this category. A single security request, such as authentication, may have to be sent across multiple domains to reach the required service. The web service has no control over the intermediate nodes and can make no assumptions about their physical security.


Administration Server One way security token

Engineering Data Base; Application server

Two way security tokens

Trusted Partner

Multilevel access control

Internet

Authentication Trusted Centre

Untrusted Partner

Security tokens: PKI certifícate, Kerberos tickets Figure 1. Security Model of web-driven distributed system

Trusted user/requester identity. When an application and/or client operate, they do so under a unique identity. This identity is usually associated with the human operator at the workstation. The distributed system provides a way of establishing this trusted identity, typically by a trusted authentication function. Trusted server (web service) identity. Trust must be established with servers in order to guarantee that they correctly perform the requested function. The trust established with a server must be two-way exchange of security tokens. The server must trust the identity of the requester, and the requester must trust the identity of the web service. Trusted administration (Security Trust Centre). Administration of the distributed system assumes trusted operation. The administrative applications, the systems on which they run, and the network connection to the servers must be trusted in order to maintain the integrity of the security-relevant information maintained at each server (access control and audit information). In some cases the administration could be the duty of a separate authentication server that deploys trusted third-party authentication. Here we can mention two popular standards. First, the PKI model that involves certificate authorities issuing certificates with public asymmetric keys and authorities which assert properties other than key ownership (for example, attribute authorities). Owners of such certificates may use the associated keys to express a variety of claims, including identity. The web services security model supports security token services issuing security tokens using public asymmetric keys. PKI is used here in the broadest sense and does not assume any particular hierarchy or model. The Kerberos model relies on communication with the trust centre to broker trust between parties by issuing symmetric keys encrypted for both parties and "introducing" them to one another. The Web services model, again, builds upon the core model with security token services brokering trust by issuing security tokens with encrypted symmetric keys and encrypted testaments. Some components of a distributed system cannot consistently be assigned but rather migrate between categories depending on their trustworthiness but also on the overall policy and sensitivity of proper trust assignment. An extreme example can be a super computer cluster, or even a database server. Any of them can be assigned to the security administrator category, at the highest level of trust, or to the untrusted partner category, at the lowest level. 2.2 Secure web service messaging In web messaging, a web service can require that an incoming message prove a set of claims (e.g., name, key, permission, capability, etc.). If a message arrives without having the required claims, the service may ignore or reject the message. A requester can send messages with proof of the required claims by associating security tokens with the messages. Thus, messages both demand a specific action and prove that their sender has the claim to demand the action. When a requester does not have the required claims, the requester or someone on its behalf can try to obtain the necessary claims by contacting other web services. These other web services, referred to as security token services, may in turn require their own set of claims. Security token services broker trust between different trust domains by issuing security tokens.


The messaging trust value is important to select the secure request-web service communication. Some of the possible approaches, proposed in the joint work of IBM and Microsoft [8], are explained below. a. The trusted or untrusted partners establish direct trust using one-way security token (username/password) and transport-level security mechanisms. The requester opens a connection to the web service using a secure transport (e.g. SSL/TLS). It sends its request and includes a security token that contains its username and password. The service authenticates the information, processes the request, and returns the result. This scenario assumes that the two parties have already used some mechanism to establish a shared secret—the requester password. Further, the trust may be established manually, by configuring the application, or by using a secure way to exchange keys. By secure key management we mean that a transfer such as SSL (or other mechanism or process) can be used as a way for a trusted partner to assert the validity of a key or security token to a recipient party. The requester sends a message to a service and includes a signed security token and provides proof-ofpossession of the security token using a signature. The service verifies the proof and evaluates the security token. The signature on the security token is valid and is directly trusted by the service. The service processes the request and returns a result. b. The security token used isn't passed as part of the message. Instead, a security token reference is provided that can be used to locate and acquire the token from a trusted centre. The requester issues a request to the service and includes a reference to the security token and provides proof-of-possession. The web service uses the provided information to obtain the security token from the token store service and validate the proof. c. Firewalls remain a critical component of the web services security architecture—they enforce boundary processing rules. For instance, the firewall examines incoming SOAP messages and only allows those from "authorized" requesters to enter. In this scenario there are two requesters sending messages to a web service inside a firewall. The firewall examines the messages to determine if the requester is "authorized" to send messages to the specified web service inside the firewall. In this scenario, the firewall makes this decision by examining the security token used to sign the message. If the signature is valid, and the signing authority for the security token is trusted to authorize messages into the firewall, and the token says that it does authorize messages into the firewall, then the message is allowed; otherwise it is rejected. In some cases, a signature may specifically reference the firewall as a SOAP actor. In other scenarios the firewall could also act as a security token issuing authority and only allow messages that include proof-of-possession of a security token issued by the firewall. d. Authentication by a trusted partner based on issued security token. The requester communicates with a certifying authority (trusted centre) to obtain a security token, specifically a signed statement of assertions attesting to the requester's identity. The requester obtained a security token because the web service has a policy requiring that a security token of the appropriate type was needed (in this case, proof of identity). The requester next sends a message, with the security token and a proof of possession attached to the message (think authenticator or signed challenge), to the web service and receives a response. To obtain an identity security token, requesters may use existing security protocols or they may leverage the web services security specifications. If we assume the requester is using the web services security specifications, then the system would operate as follows: the identity service describes its requirements in a policy, and the requester can then request a security token along with its proof of identity. The identity service is just a security token service. Moreover, the symmetry of web services allows for any web service to also encapsulate a security token service. Finally, note that web services can obtain security tokens on the requester's behalf (from a security token service) and return them to the requester for use on subsequent messages. e. In several engineering system the security is enforced by specific system policy that requires multiple-level tokens. Here several scenarios could be given, in all of them there are untrusted partners, trusted partners, and administrator servers/trusted secure centre. Let us consider the following example. An untrusted NC computer (untrusted because it is physically located in a manufacturing environment) makes request to some engineering database to get detail geometrical model and processing program. The system policy requires security tokens for the detail program to be issued by two servers: the database server and the administration/trusted centre server. Let us assume that the administration and the database server have exchanged public key certificates in order to perform security-token chain. We further assume that the NC computer only supports symmetric key technology. Based on the policy, the requester needs to acquire a security token that can be used to access the security token service at database server. Because NC machine is using symmetric key security tokens, it first contacts her security token trusted centre to acquire a security token that is intended for the database security token service. Note that this security token will contain a symmetric key, encoded with the public key of the database security token service. Using the security token intended for the database security token service, the NC machine requests a security token for the detail program web service. The trusted centre provides the NC machine with a symmetric key, and a security token (ticket) for the detail service. Using the security token intended for the detail service and the associated symmetric key, the NC computer makes requests to the service.


3 MODELS OF WEB SERVICES THAT CONTROL THE SECURITY In this paper we propose a secure engineering architecture that is oriented to provide two important characteristics: monitoring of the trustworthiness of the system nodes, and secure replication of the critical information. 3.1 Monitoring Web services are commonly build using composable components like HTTP containers, Java-based applications, and others. These components are distributed across tiers – web tiers, application and database. In currently existing systems, security services are provided on two levels, operating system and application. Operating system (OS) driven security services are integrated into the operating system running on the distributed system node machines. They run in kernel mode and are therefore executed at maximum speed for any service. Kernel level is also the hardest to attack that makes this level ideal for implementing security policies. The drawback is that the OS-level security policies are often very generic and cannot be modified to accommodate any particular distributed system scenario. Web-service based applications are being deployed rapidly over the web and were envisioned as an open environment for free information exchange. However, the design that fit these requirements has proven treacherous for online business and other more sensitive applications. Web browsers collect user profiles, often without soliciting explicit user consent, raising serious privacy and security concerns. Executable services are a constant vulnerable point as they can completely expose user’s machines to malicious attacks. The scripting approach for information processing (CGI, Hypertext, XML, etc.) on which the WWW is based requires function-blind interpretation and is intrinsically very insecure. Software agents that are essential in the efficient use of web can also introduce serious security threats. In this paper we present a method for using semantic web to create web services that select security information internally and estimate the level of the trustworthiness (Figure 2). The first type of web service – local trust service - uses ontologies to analyze parameters from the OS, firewalls, antivirus components, database invasion and so on. The second type, monitoring web service, is incorporated in a trusted centre. It corresponds with the system nodes and selects confirmation that they are not object of security threats. Trusted Center Web service for trust monitoring

Two-way security token exchange

Local trust service System node (trusted or untrusted)

…

Local trust service System node (trusted or untrusted)

Figure 2. Web services for security monitoring In our model, the observed node trust has two components. The first component has typically referred to mechanisms of authentication, security, and privacy. Web trust specifications describe how existing direct trust relationships may be used as the basis for brokering trust through the creation of security token issuance services. These security token issuance services build on WS-Security [10] to transfer the requisite security tokens in a manner that ensures the integrity and confidentiality of those tokens. The trust model could explicitly allow for, but will not mandate, delegation and impersonation by principals. Note that delegation is consistent with impersonation, but provides additional levels of traceability. The second component is some estimation of the stable functionality of the system node. Stable functionality means no viruses and other attacks, predictable access to the engineering data, relatively good performance of the engineering processing, and so on.


The local trust service is incorporated in every system node (trusted or untrusted partner) and utilizes trust data incorporated into different tiers (web tier, engineering logic tier, database tier). The monitoring web service collects the data from the local web services and could inform some misbalances to the system administrators. 3.2. Replication Replication in engineering system is an important technique to keep the information geographically distributed and secure. The system nodes request and receive information by web services according to some engineering logic. During the lifecycle of the engineering product the information has to be distributed through the system to prevent fatal loss of information. In our model we suggest to incorporate separate replication web service that transmit or retransmit information following specific policy. The replication web service could be autonomous or could be controlled by some administration server. Such trusted replication could be organized different way using security token trust centres. Figure 3 shows a scenario that a node issues a request for a replication. The replication policy is controlled by replication administration centre. The requester applies for security token to the trusted centre. After that with the received token it requests replication web service. The replication web service sends to the replication administration centre the following information: the security token, some signature block, and its computation of the digest that was signed. The latter exchanges a confirmation messages with the trusted centre to prove the trust level of the security token used within the replication request. The validation service, which is trusted by the web service, then issues a valid/invalid decision. It should be noted that the validation service could indicate its decision by issuing a security token on behalf of the requester that asserts the appropriate claims. Trust?

Trusted Centre

Replication centre

Security token assignment

Request for validation Request for replication

Replication Web service

Requester Figure 3. Replication web service 3

USING SEMANTIC WEB FOR TRUST AND REPLICATION WEB SERVICES

Engineering systems combine several software components that have been used separately in the past. The trust and replication web services need to access software agents that were built in different tiers for use in unanticipated contexts. Without a way to discover the meaning of terms and relationships, the trust web services cannot adapt to internal dynamically changed state of the system. Semantic interoperability problems are caused by polysemy (a word has multiple meanings), synonymy (different words have similar meanings), and inconsistent engineering model assumptions and granularity. Semantic web technology, based on ontologies[2,13], solves the polysemy and model assumption/granularity problems by allowing a developer to mark up a document, database schema or legacy software interface by linking concepts (i.e., classes, relationships, instances) to other concepts defined in the ontology. Each concept is referenced by means of a unique Uniform Resource Identifier (URI). The synonymy problem is solved by allowing explicit declarations that term A in one ontology or markup document is equivalent to term B in another ontology or different markup structure. Establishing an internal ontology over the marked-up information pathways plays a key role for numerous engineering tasks such as comparing models to understand the semantic differences, mapping terms and entities to ensure product data integration, or simply reusing entities and queries to product data to prevent duplication of work. Trust web services also use the mark-up structure of such hierarchy of ontologies and interpret the related to trust and security information. Such information is provided by the operating system, application programs,


firewall, and diagnostic subsystem. Traditionally it is disparate and not related to each other. Ontologies can give common trustworthiness state of the system. Figure 3 is an illustration of our idea and understanding of web-based trust monitoring and replication using semantic web services and ontologies. Computers that participate in the system are connected to the web and expose their trust characteristics by local trust web services.

Replication web service Application Server

Web server

Internet

Storage

Engineering Models

Database Server

Local Trust Web service

A trusted or administration centre. Functions: Searches trust changes; Gives permission for replication.

Ontology Modeler

Figure 3. Web-based configuring of secure system Acting as a semantic translator, ontologies also can insulate each system from changes occur on the other side of the interface. A new component in such systems is the ontology modelling software, used at all stages of ontology development, implementation, maintenance and replacement. On the other side of the figure is the administration or trusted centre. This might be an upgrade of an existing system or brand-new application for this specific purpose. It selects information about the trust of the system nodes and controls the replication of critical information. 4 RELATED WORKS Our sources fall into several distinct areas. Web service security, trust. Web services security is object of several initiatives in W3C, whose authors are from the leading software vendors. Leading documents are WS Security [10], WS Security architectures [8] and WS Trust language [9]. There do not give exact recommendations how to estimate trust. Trust is referred to mechanisms of authentication, confidentiality and privacy. Interesting consideration is the trust in social networks, which could in the future influence trust analysis in web-driven distributed systems [6]. Monitoring and replication. These techniques are use in several large scale distributed systems. The solutions are specific and system-dependent and the vendors do not offer their approaches to consumers and application developers. Some authors [1] place special emphasis upon monitoring and replication importance. Semantic Web technology, ontology modeling. Experience in prototyping of bottom-up semantic web technology and explanation of challenges and corresponding research is given in [11]. Formal ontology frameworks are proposed in [12]. In addition, our work is partly based on previous research [5].

5 CONCLUSIONS AND FUTURE WORK In this paper, we claim that the security of the web-service CE system has three important components: web service messaging security, monitoring of the trust dimensions and replication of the critical information. Web service messaging security is well standardized and already offers experienced solutions. For monitoring we propose architecture with two types of web services: local trust services that collect security information from the tiers and monitoring web service that collect information about the trust level of the distributed system. Distribution of the critical engineering information is controlled by replication web services.


Our approach is conservative. First, the definition of the trust follows precisely the trust consideration in web society that is related to web messaging trust. Open and future (maybe lifetime) problem is to create trust definition which can dynamically change as a social trust. Second, the trust of the system nodes is defined statically usually by some administration experts. The ontologies for the local trust web services are created by bottom-up approach as uniform interfaces to the well proved data presentation. Next step is to try to manipulate trust level using web service reasoning using semantic web rule language [7]. The declared future works are challenging as scientific problem and very controversial as implementation for many reasons. First reason is the performance issue. The developers are very sensitive to have in their system software web services that select data at higher rate and could influence the concurrent multithreaded processing specially in real time environment. Other reason is related to the fact that the security and also trust definitions are application dependent. In conclusion, our research work has proved important trustworthy technology for monitoring very large systems as a tool to share a status report and coordinate a consistent response when disruption occurs. Similarly, many aspects of trust and security reduce to data replication that can ensure access to critical data in event of fault. REFERENCES [1] Birman, K. (2006), “The Untrustworthy Web Services Revolution”, Computer, February, pp.98-100. [2] Connolly,D., Harmelen, F., Horrocks, I., McGuinness, D., Patel-Schneider, P., Stein, L.A. (2001), “DAML+OIL Reference Description”, http://www.w3.org/TR/daml+oil-reference [3] English,C., Nixon P.,Terzis S., McGettick A., Lowe, H. (2002). “Security Models for Trusted Appliances”, Proceedings of the 5th IEEE International Workshop on Networked Appliances, October 2002. [4] Georgiev, Il., Georgiev, Ivo, (2001), A Security Model for Distributed Computing. The Journal of Computing in Small Colleges, v.17, No.1, pp.172-180. [5] Georgiev, Il., Georgiev, Ivo (2005), “Ontology Modeling for Semantic Web-driven Application”, Proceedings of the International Conference CompSysTech 2005, Varna, 16-17 June, pp.67-72. [6] Golbeck, J., Parsia, B. (2006) “Trust network-based filtering of aggregated claims”, International Journal of Metadata, Semantics and Ontologies, Vol. 1, No.1 pp. 58 – 65. [7] Horrocks, I., Peter F. Patel-Schneider, Harold B., Tabet, S., Benjamin G., Dean, M. (2004) “SWRL: A Semantic Web Rule Language Combining OWL and RuleML”, http://www.w3.org/Submission/2004/SUBMSWRL-20040521/ [8] IBM and Microsoft Developer Centers (2002), “Security in a Web Services World: A Proposed Architecture and Roadmap”, v.1.0 05, http://msdn.microsoft.com/library/default.asp?url=/library/enus/dnwssecur/html/securitywhitepaper.asp

[9] IBM Developer Works (2005), “Web Services Trust Language”, http://www128.ibm.com/developerworks/webservices/library/specification/ws-trust/

[10] IBM Developer Works (2002), “Web Services Security”, http://www-106.ibm.com/developerworks/webservices/library/ws-secure/ [11] Kogut P., Heflin, J. (2003). “Semantic Web Technologies for Aerospace”, Proceedings of IEEE Aerospace Conference, vol. 6, pp. 6_2887 - 6_2894. [12] Pahl, C., and Casey, M. (2003). “Ontology Support for Web Service Processes”. ACM SIGSOFT Software Engineering Notes, vol. 28, issue 5, pp. 208-216. [13] Smith, M., Welty, C., and McGuinness, D. L. (2004). “OWL Web Ontology Language Guide”, W3C Recommendation, http://www.w3.org/TR/2004/owl-guide/ [14] Salim, S., K. Hetherington-Young, and S. Frey (2004), “Ontology Engineering: An Application Perspective”, The MITRE Corporation Publishing, http://www.mitre.org/work/tech_papers/tech_papers_04/04_0847/. [15] W3C Working Group (2004), “Web Services Architecture”, http://www.w3.org/TR/2004/NOTE-ws-arch-20040211/