A Novel Event-Oriented Architecture for Logging and Auditing in

A Novel Event-Oriented Architecture for Logging and Auditing in

Distributed Systems

1

Elnaz B. Noeparast, 

Reza Ravani 

Department of Computer Engineering, Islamic Azad University, Central Tehran Branch,

Tehran, Iran, [email protected] 

2 

Department of Computer Engineering, Islamic Azad University, Central Tehran Branch,

Tehran, Iran, [email protected] 

Abstract

Due to widespread communications and unsafe accesses in distributed systems, controlling and auditing of events are considered as one of the major challenges to achieve security goals. Several methods have been introduced with some drawbacks such as the integrated information accuracy concern, server overhead and impossibility of client management in emergency situations. This paper presents a new architecture for logging and auditing systems. Tampering and losing data prevention, reducing server overhead during data collection and integration and notifying the clients' status to server to apply suitable security policy are the main goals of the proposed architecture. In our system architecture, system events are classified to four categories, negligible, marginal, critical and catastrophic. Only the information of critical and catastrophic events will be sent to the server during emergencies. Also, this paper presents a method for data encryption which has a validity period and it will be updated periodically from the server.

Keywords:

1. Introduction

With extensive operations between different systems in distributed systems, we need a mechanism that provides essential and necessary information for keeping track of important events. This is informed us about the status of each system during its operations and its operation’s accuracy. This mechanism is system logs auditing which is considered as a necessary and valuable part of each system. Since recording events in distributed systems are performed in various and unsecure systems, on one hand, it is difficult to integrate information for analysis and on the other hand, it is possible to loss or manipulate information.

The previous researches have provided methods such as using public key cryptography [1][2], tamper-resistant hardware [3][4] and information symmetric encryption [3][5][6][7]. The main problems of these methods are their high implementation cost, need for being online during logging operations and the probability of the detection of encryption algorithm keys. As mentioned above, another problem is the information integrating from all systems for auditing and tracking system errors or detecting hacker attacks and illegal entries into the system. So far, the methods that have been proposed to resolve these problems are divided into two groups. In one group, each system's logs are stored locally and alerts are generated on client-side, then the local information is transmitted to a central server through methods like network-based sensors [8]. In second group, in addition to storing data locally and generating warning on the client-side, some parts of audit operations are performed on client-side and then required result will be sent to server for analysis [9].

According to the mentioned problems, we need a method and system architecture that provides data integration from all systems (which may work offline), and also ensures the integrated information accuracy.

This paper organizes as follows: in the next section, first the Event- Driven Architecture is explained and then features of the proposed auditing system are presented. After that, a high-level architecture will be provided based on these features. This section also covers the description of the structure and the function of this architecture. In section 3, we will evaluate and compare our new

architecture with previous methods. Finally we finish the paper with concluded remarks and future works.

2. System architecture

Event-Driven Architecture (EDA) is an architectural style which includes two or more software components related together based on the events with minimal dependencies. Here, minimal dependency means that the relationship between sender and receiver is unidirectional and the sender doesn’t transmit any data to receiver by receiving a request [10], rather when an event occurs, a notification is generated and sent to receivers which have subscribed for it before [11]. Accordingly, three components publisher, subscriber and communication infrastructure play the fundamental roles in this architecture [12]. Publisher is a software component that produces information and publishes them on communication infrastructure. Subscriber is the consumer (receiver) of some information that is produced and published by various publishers. This information is events and the method of providing them is called notification. The communication infrastructure is a service bus which manages events. Subscribers register in this bus for events that they want to have notified about their occurrence, without having any information about their publishers. The subscribed information is stored in the bus and is not sent to publishers. By creating an event, the publisher notifies the bus about its happening through the publishing operation, and the bus informs the event subscribers through notification [13].

The architecture is presented in this paper is an EDA. By an event occurrence, server services are invoked which have registered for that event. This reduces the dependencies between server and client application and enhances the security, because communication infrastructure sends a message to the system which has registered for this event. Logging and auditing system proposed in this article has additional features and advantages as follows:

1- Protecting the security of local data

To increase auditing data security in a client system and preventing the destructive manipulation, it is necessary to store this information in encrypted formed and after sending it periodically to server, decryption will be done on the server-side. Instead of receiving the encryption key which has been stored in the client system in specific time-intervals, it is necessary that servers receive a signed encryption algorithm via a web-service. But since there is the probability to detect the encryption algorithm, data is still at risk. The encryption algorithm should be different for each client and could be changed and updated in regular time-intervals. To achieve this goal, this article applies Aspect-Oriented Programing (AOP) [14] on the client-side to utilize an encryption algorithm. Therefore, storing logs structure which contains an encryption algorithm is received from the server as a file in specific time-intervals. Then, the program stores it in a specific local path and uses it to store logs (audit data). Each time the new algorithm is sent to a client, its decryption algorithm and the relevant timing information are stored in the server database. So, whenever the server receives information from clients, it uses the decryption algorithm to decrypt data according to the recording time of data on the client-side.

2- Storing messages and preventing the lost

In distributed systems, sometimes it may not be possible to have a communication between server and client for some reasons such as the communication lines traffic, busy servers, the offline clients and etc. Thus, a mechanism should have used in such situations that can store messages and prevent losing messages. Since the role of service bus is enabling essential cooperation between various service components in a range of different platforms and it can also store messages inside the related queues [15], so it is a suitable option for this purpose. The proposed architecture uses this infrastructure for communication between the client and the server.

3- Reducing overhead due to audit data transmission from client to server

If transmitting audit data to the server is performed in short time-intervals, it increases overhead and server communication buses traffic. On the other hand, if this interval is long, it causes that the server does not aware of issues that happens on the client side. Thus, it is necessary to classify the events and audit data types, so each data is sent to the server at a specific time according to its classification. Therefore, audit data (different types of system events) are divided into the following four categories in this paper.

 Negligible events: An event that effects on non-operational functions and slightly enhanced the cost and time.

 Marginal events: This is an event that reduces the system functionality and its technical performance.

 Critical events: An event that not only causes the delay of system performance and increasing operating costs, but also it causes that some parts of the non-essential functions do not work properly.

 Catastrophic events: The events which prevent the normal operation of the essential parts of the system are catastrophic. Some of these events may even lead to disconnect the client completely.

If the audit data type is critical or catastrophic, it is sent to the server as soon as it occurs. The difference between these two types of data is the transfer mechanism. In catastrophic events, audit data will be sent through HTTP protocol in text-based format to reduce transmission time, but sending critical audit data will be done again through the HTTPs protocol but in encrypted format. In the latter case, if the message is received by a third party, it could not be aware of the semi-safe situation of the client. Sending periodic audit data based on the time intervals is specified in the configuration file and it includes marginal, critical and catastrophic data. Negligible audit data is sent to server only when critical or catastrophic data is available in the local database. In this case, these audit data will be transmitted together with critical or catastrophic data. This information may help for more accurate analysis of the critical or catastrophic incidents on the server-side.

4- Increasing the client flexibility due to server changes

The configuration file contains information about the address of services which are offered by the server, the specific scheduling for client to send date periodically to server and service names that are subscribed for various types of events. This file can be received from the server whenever a client connects to the server. This increases the client flexibility to updates itself if the scheduling policies and service addresses changes on the server side. Also, the type and priority of the audit data could be changed on server-side based on analysis on the received audit data from clients. So, it is necessary for clients to receive updated data type configuration and recognition settings in regular time-intervals from the server.

Till now, we have presented our system architecture features and characteristics. Now, we will more focus on the client-side and server-side detailed architectures and workflow.

2.1. Client-side architecture

Auditing system in client-side follows component-oriented design. For this purpose, this system includes 8 different components which are explained as follows. The block diagram and relationship between different components has been shown in Figure 1.

 Organizer component: This component is responsible for five major following tasks:

o Receives configuration file from the server: Each time the client system is connected to the network, Organizer component sends a request to the server via Service Provider component and based on SSL protocol. After receiving the configuration file, it saves this file in a specific local path for future purpose.

o Receives encryption algorithm from the server: This component receives Logger component assembly file from the server in regular time-intervals periodically and saves it to the program installation path. This assembly file contains the encryption algorithm to encrypt the log data. o Receives the audit data type recognition settings: Organizer component sends a request to

server in regular time-intervals via Service Provider component for requesting this file. Then it will received an XML file which will be saved in a specific local path.

o Publishes critical and catastrophic data: as soon as Organizer component detects a critical or catastrophic type of audit data (which indeed has been acquired by Auditing component and forwarded to Organizer), it publishes this data via Service Provider component. The detection configuration settings is based on XML pattern recognition file.

o Publishes audit data periodically: According to the scheduling which is listed in the configuration file, Organizer component publishes audit data to the server via Service Provider component.

 Service Provider component: This component communicates with server through HTTP and HTTPs service protocols. It consists of two types of service calls. Invoking services which subscribe for special events and calling services that are invoked directly. Calling subscription services is for sending critical and catastrophic event data when it happens and sending audit data periodically. Invoking methods directly is used for receiving Logger assembly settings, configuration and pattern recognition files from the server via HTTPs protocol.

 Service Provider Interface: This component will handle the communication with services offered by server through the addresses and "service contracts" that have been registered before.

 Auditing Interface: This interface provides methods for recording the information related to an action or changing an object. Since Audit component is considered as a part of a software system in this paper, an explicit call to Audit component is required for performing relevant operations.  Logger component: This component is responsible for encryption and storing data in local

database. This component is an assembly file which is generated by the server based on each request and has a validation time-interval.

 Event Aggregator component: In case of critical or catastrophic event, this component invokes related subscribed service from Service Provider component. This component also sends audit data periodically whenever the system timing will be equal to schedule timing stored in configuration file [16].

 Auditor component: This component is responsible to analyze and refine the information which is provided by the system software. This information is converted to data audit after analysis.  Aspect Loader component: This component operates based on the AOP rules and standards. It

loads the Logger component assembly from a specific path of the installed program and then stores an encrypted audit data into the local database.

The workflow diagram of client-side auditing system is shown in Figure 2. By initializing Audit module, the software system sends required information to the Audit component by a method call whenever an action is performed by user or an object is changes. After analyzing and refining information in Audit component, the audit data is sent to the Organizer component through a method call. Then the Organizer component publishes an audit data according to the pattern recognition file if the data type was critical or catastrophic. The Event Aggregator component extracts the service address which is subscribed for this event from the configuration file. Then it sends a notification to the server via Service Provider component. Parallel to this operation, the Auditor component sends an audit data to the Aspect Loader component by a method call. After that, this component initializes Logger component by using AOP methods and stores an encrypted audit data in the local database. This operation repeats if the Auditor component's method is called again.

Figure 2.Workflow diagram of the client-side auditing system

2.2. Server-side architecture

The server’s Auditing system is responsible for the information collection and integration from clients and the management/coordination of clients audit process. It includes 6 different components which are explained as follows. The block diagram and relationship between different components has been shown in Figure 3.

 Decision Maker component: This component makes decision about clients which a critical or catastrophic events has been occurred during their operation. Considering different condition, this decision could be notifying system administrator, disconnecting client temporary or etc. based on the configuration files have been specified by system administrator in the server's database as security policies.

 Analyzer component: This component analyzes the reasons of a specific event based on the collected auditing data and original configuration data in the database. Then it sends the results of this analysis to the Decision Maker component through a method call.

 Service Provider Interface: This interface shows the service addresses and contracts for invoking services offer by server by clients Auditing component.

 Service Provider component: This component provides following services: o A secure service for receiving audit data periodically

o A secure service for receiving critical type of audit data

o A text-based service for receiving catastrophic type of audit data o A service for providing client requested files

 File Generator component: This component generates a configuration file, an event type recognition Pattern file (XML file) and an assembly file of client’s Logger component which consists of the encryption algorithm. These file will be generated according to the time and the client specifications like client’s identifier code, username and password.

 Logger component: By receiving auditing data, this component retrieves its decryption algorithm from the database based on the data creation time and client specifications. Then, it decrypts the data and stores it in the database. For critical or catastrophic audit data types, its creation time is equal to the receiving time. But if an audit data has been sent periodically, its creation time is the last time when the client has received a Logger assembly file (this data is encrypted by the last assembly).

Considering above details specification of server-side auditing system, the auditing system workflow is explained on the following way (Figure 4). When a service from the server is invoked by a client and it is about a receiving file request, then the desired file is generated by File Generator component and will be sent to the client. But if this is a request for data collection and integration invoked by server itself, then this data is decrypted by the Logger component and stored in database. After that, it is sent to the Analyzer component by a method call. Analyzer component receives this data and analyzes it based on the information which has been stored in database. If the reasons of the problem are unauthorized entry, data manipulation or hacker attacks, then a request is sent to the Decision Maker component. This component makes a decision according to the stored security policies in database which the server administrator has defined them in advanced.

3. Architecture analysis and evaluation

As mentioned in Introduction section, there are different methods for the audit data protection. One of the simplest techniques is to use a bug-free tamper-resistant hardware (to prevent audit data manipulation) and maintaining a secure communication channel between clients and the server (to upload runtime data) [17]. Forwarding secure signature is another proposed scheme for storing secure information. In forwarding secure signature, a sender digitally signs each data item as soon as it is stored. Then the sender improves its secret keys, removes previous ones and uses new keys for signing next data items [18]. A group of these schemes relies on the use of the symmetric cryptography and the others utilizes the Public Key Cryptography (PKC). Each of these methods has its own benefits and drawbacks that are comparable with our proposed architecture in this paper.

 Efficiency: A group of schemes which relies on the symmetric cryptography uses Message Authentication Codes, semi-random number generation or one-way hash chain for data encryption, all of these methods result to computational complexity [17]. The proposed algorithm for encryption could generate better (in worse case equal) performance results, depending on the encryption policy.

 Storage and Communication Overhead: Due to accumulating signatures from data items in forwarding secure signature method and also the need to maintain and transmit an authentication tag for each log, signing data items continuously causes to significant communication and storage overheard [17]. But in the proposed architecture, encryption algorithm is generated according to each client in the Logger file, which is replaced the previous one on the client-side. So it is not required to store any information about this algorithm, because its generated time would be store in the server database. With this method, the client storage overhead is decreased. Also in this architecture, only essential data is sent to the server as soon as it happens, as a result, the communication overhead is reduced.

 Ability of Public Audit: Methods use symmetric encryption could not offer public audit. Because they need a complete symmetric keys distribution or an online TTP support. The complete symmetric keys distribution brings a significant storage overheard for system entities. Supporting online TTP causes architectural difficulties, increases the communication overhead and makes vulnerabilities against the system attacks [17]. But in our architecture auditing operations will be done on the client-side and the results of this process will be sent to the server for analyzing. By this method, operation overhead on the server-side is reduced. Essential filtered information is sent to the server, so the server doesn’t process unnecessary or insignificant information of clients.  Applicability: Maintain a secure communication channel between the clients and server for

modern computer systems is impractical. Because in distributed systems, it is not possible to reserve an end-to-end real-time communication channel between the client and server. Also, it could not be assumed that a tamper-resistance hardware (which must be bug-free) will guarantee

systems and by all distributed applications, because of its low structural/data coupling between client and server. Also, this architecture could be implemented on all platforms as long as they support programing languages which supports AOP, Event and Service concepts. In this architecture, the server information is easily updatable on the client-side, so it is possible to change or extend the information to the multiple servers.

4. Conclusions and future works

In this paper, an event-oriented architecture in a distributed system for log, collecting/integrating and analyzing of audit data has been proposed to manage and coordinates separate nodes with different tasks. In this architecture, Aspect-Oriented Programming (AOP) will be utilized on the client-side to encrypt audit data. This encryption algorithm has a limited validation time and after expiration new configuration for another algorithm will be generated and transmitted by server to client to update its current algorithm. During audit data collection and integration, server decrypts each audit data with a specified algorithm considering to its encrypted time. So, the possibility of unauthorized access to encryption algorithm and consequently audit data will be decreased.

We have also presented a classification and transmission method of audit data to server to reduce the server overhead due to receiving different types of audit data from different clients while it could be informed when an important event happens in a client. As a result of comparing our architecture and previous methods, it can be easily understood and verified that the proposed architecture has a more general applicability than previous ones. Also, the proposed method provides ability of public audit in distributed systems and causes less communication and memory overhead for these systems. The infrastructure service bus details has not been mentioned in this paper, because this bus can be any of-the-shelf (COTS) bus depends on the platform.

A high-level architecture for a logging and auditing in distributed system has been discussed in this paper. In the near future full implementation of this architecture considering system-level design limitations and concerns will be presented. Using autonomic computing for the Decision Maker component in server or anticipating the weakness points of distributed systems by applying the integrated audit data analysis results, are some of the challenges that need to be studied more.

5. References

[1] Rafael Accorsi, “BBox: A Distributed Secure Log Architecture”, Proceedings of the 7th European conference on Public key infrastructures, services and applications (EuroPKI'10), vol. 6711, pp.109-124, 2011.

[2] Wensheng Xu, David Chadwick, Sassa Otenko, “A PKI-based Secure Audit Web Service”, Proceedings of the IASTED International Conference on Communication, Network, and Information Security (CNIS 2005), Nov 2005.

[3] Di Ma, Gene Tsudik, “Forward-Secure Sequential Aggregate Authentication”, IEEE Symposium on Security and Privacy, vol. 2007, pp.86-91, 2007.

[4] Daniel Halperin, Thomas S. Heydt-Benjamin, Kevin Fu, Tadayoshi Kohno, William H. Maisel, “Security and Privacy for Implantable Medical Devices”, Pervasive Computing, IEEE, vol. 7, no. 1, pp.30-39, Jan 2008.

[5] Mihir Bellare, Bennet Yee, “Forward-security in private-key cryptography”, Proceedings of the 2003 RSA conference on The cryptographers' track (CT-RSA'03), pp.1-18, 2003.

[6] Bruce Schneier, John Kelsey, Bruce Schneier, John Kelsey, “Cryptographic support for secure logs on untrusted machines”, In Proceedings of 7th USENIX Security Symposium, vol. 7, pp.53 -62, 1998.

[7] Bruce Schneier, John Kelsey, “Secure audit logs to support computer forensics”, ACM Transactions on Information and System Security (TISSEC), New York, NY, USA, vol. 2, no. 2, pp.159-176, May 1999.

[8] Ambareen Siraj, Rayford B. Vaughn, Susan M. Bridges, “Intrusion Sensor Data Fusion in an Intelligent Intrusion Detection System Architecture”, Proceedings of the 37th Hawaii International Conference on System Sciences (HICSS'04), pp.279-288, Jan 2004.

[9] Mike Davis, Ed Coyne, Craig Winter, “Security Audit architecture For Audit As A Service”, Office of CIO, Health Information Architecture Office, Feb 2006, http://hssp-security.wikispaces.com/file/view/HIA_20060310_Security+Audit+Architecture+V1.doc, Downloaded on [28 04 2012].

[10] K. Mani Chandy, “Event-Driven Applications: Costs, Benefits and Design Approaches”, Presented at the Gartner Application Integration and Web Services Summit, Jun 2006.

[11] K. Mani Chandy, W. Roy Schulte, Event Processing: Designing It Systems for Agile Companies, McGraw-Hill, 2010.

[12] David Trowbridge, Ulrich Roxburgh, Gregor Hohpe, Dragos Manolescu, E.G. Nadhan, Integration Patterns, Patterns & Practices. Avail. at www.microsoft.com, 2004.

[13] Patrick Th. Eugster, Pascal A. Felber, Rachid Guerraoui, and Anne-Marie Kermarrec, “The many faces of publish/subscribe”, ACM Computing Surveys, ACM, vol. 35, no. 2, pp.114-131, Jun 2003.

[14] Dharma Shukla, Simon Fell, and Chris Sells, "Aspect-Oriented Programming Enables Better Code Encapsulation and Reuse", MSDN Magazine, Microsoft, Mar 2002.

[15] David A. Chappell, Enterprise Service Bus, O'Reilly Media, 2004.

[16] Martin Fowler: Information on http://martinfowler.com/eaaDev/EventAggregator.html

[17] Attila Altay Yavuz, Peng Ning, “BAF: An Efficient Publicly Verifiable Secure Audit Logging Scheme for Distributed Systems”, Proceedings of the 2009 Annual Computer Security Applications Conference, pp.219-228, 2009.

[18] Attila Altay Yavuz, Peng Ning, “Hash-Based Sequential Aggregate and Forward Secure Signature for Unattended Wireless Sensor Networks”, Proceedings of the Sixth Annual International Conference on Mobile and Ubiquitous Systems: Computing, Networking and Services (MobiQuitous 2009), pp.1-10, Jul 2009.

[19] Attila Altay Yavuz, Peng Ning, Michael K. Reiter, “Efficient, Compromise Resilient and Append-only Cryptographic Schemes for Secure Audit Logging”, in Proceedings of 2012 Financial Cryptography and Data Security (FC 2012), vol. 7397, pp.148-163, 2012.