Software management based on mobile agents Mâamoun Bernichi and Fabrice Mourlin Paris 12 University LACL (CRNS FRE 2673) Créteil, France
[email protected],
[email protected]
Abstract— there is a need for better management of company’s software. It means global access control and hierarchical version control for all the software, used in a project environment. This management involves control of the software reuse even if it is free access software. The directives, we present in this document are designed to set traceability of used software from the project creation until its last evolution. Because this kind of information belongs to the project itself, it has to be saved closely to the core data of the project. A software management directive improves the quality of the project and insures a better maintainability. Our management system is based on mobile agent system. The agents observe the use and context of any software. Such mobile agent system is able to create reports about the activities of the software but also, the agent collect data, which will be the basis of a software map of the company. It will also increase the opportunity for software reuse and consequent productivity improvements. Keywords: software management, mobile agents, data collect, traceability, activity reports.
I.
INTRODUCTION
Today, software is essential to each small or large company; it helps to increase both productivity and benefit. However, to obtain the most out of the software, we must control well as for any other invaluable social good. An absence or mismanagement of this software strips the company of those advantages mentioned above, also it makes it possible to hide easily the installation or the use of software unauthorized. We also know that this step belongs to the lifecycle of the project and can have very expensive consequences for the business. Using illegal software invalidates our computers and all data or information, and this is because we cannot expect at any guaranty or support. The validation of used software is essential and our projects need tools, which preserve data and their integrity [1]. Our solution SMAMA (Software Management Approach with Mobile Agent), which is not a pledge against software piracy, stands to help the company avoiding these serious problems with software management practice and to keep private project feature throughout project lifecycle. This overview covers the following topics so we can better understand why such a solution is beneficial and how to do it:
The benefits of effective software management
How to manage software properly
The use of mobile agent does all controls. The mobility allows us to adapt our control strategy to new context, new rules as well new software. II.
THE BENEFITS OF EFFECTIVE SOFTWARE MANAGEMENT
Probably a correct management of software has several advantages. The most significant one is the control costs. The software can represent approximately 25% of the budget of information technology. The public sector in France spent nearly 6 milliard euros in software and IT services in 2006, an increase of 10% compared to 2005 [2]. Therefore, it seems reasonable to keep a close eye on the costs of software, the support, the staff train up and the procurement costs. A good project means that the company buys needed software, uses required licenses and pays only useful upgrade. By budgeting software as separate expenditure, we can easily control the costs. This separation offers us two advantages. Initially, we can plan purchases and upgrade software following a road map or in an ordered way to anticipate needs. Nevertheless, how to avoid excessive spending or unexpected costs, our first observation was to trace the concrete use of upgrade software. The second advantage is that we will be able to track accurate purchases to prevent unauthorized copies. This point can be achieved by spying all software use. Controlling software purchases and upgrades can mean savings on hardware as well. By placing software only on the computers of developers who need it, we can avoid having to upgrade, add, or replace hardware for employees who do not need the capacity. Because, employee does not work on the same computer every day, adaptive control is necessary. Moreover, by checking unneeded software on developer computers, we can find future perturbation. With planning for acquiring and upgrading software, the project team will also stay informed about the deployment of software throughout project life. They had better anticipate change to be more productive, thus remaining efficient. The process also accounts for any training and support needed as new software or developer introduced. The users can build software maps more easily; these maps are a perfect observation of the state of used projects and platforms.
Therefore, software management directive saves time, money, makes developers more productive, keeps software and information compatible throughout the projects, and makes it easier for project to adapt to any change. In our approach, a group of mobile agents realizes the observation of all the activities of used software. One group deployed when new software installed over the network of our company. These agents give us information about the load, the use, as well as about what it is not used. III.
HOW TO MANAGE SOFTWARE PROPERLY
For better managing software, we proceed in five step, each step is a whole of task managed by a component or an agent. For the first step, the agent can be immobile but not the others, we do think that by integrating the mobility we will optimize the data collection and decrease the data exchanges. By integrating the mobility, we will also give the agents the opportunity to move and work collectively. However, the implementation of the mobile feature has to be robust, simple, and easily understandable; that is why we decide to use our previous mobile agent pattern for two mains raison: To find a use or an applicability of our mobile agent communication scheme also to have an easiest context to develop an agent based application. This topic about agent-based application has numerous applications, however, only few of them have a systematic approach. Our experience highlights some recurrent aspects:
How an agent can move from one host to another with respect to the acceptance of these hosts?
How an agent can realize a task on a platform and save results locally or keep them in its memory?
Since it is essential to apply a valid solution and have a logical view of the question of mobility, we have chosen to build a new behavioral pattern. In a previous study, D. Bonura, R. Culmone, and M. Angeletti have already defined a “pattern for reactive mobile agent” that could be applied to a large database [3]. We finds also a similar approach on project Seven [4] an implementation of the Jini Service Container Specification. Our behavioral pattern describes a context that resembles to the context of a company in which a given person is waiting for a precise mission. Once the mission is given, the person goes to the place where he or she has to accomplish it. When the mission is over, the person becomes available for another one. We have to add that the experience acquired by this person during his or her mission will be very useful for the coming ones. To describe the mobility we have chosen the following strategy: each host willing to receive an agent has to reveal its intention. Each agent that can move through the network has to reveal its ability. In the event that an agent leaves a host for somewhere else, the agent host has to announce its eventual leaving. Even more, we define our mobile agent as an aggregate of two mains entities:
Sender part: its responsibility is exporting the agents.
Receiver part: to receive the mobile agent and help it to achieve it task on the local platform also to communicate with the other agent.
For the communication approach, we have chosen a solution that is a direct association between mobility and communication. A solution based on mobile messenger. Because a mobile agent knows its road map or a part of it, it is able to create or prepare a messenger before leaving an agent host. The role of that one is to propagate a kind of message from an agent host to another one. Our communication canvas has several components:
Messenger layer: is a mobile agent who is waiting for an incoming message and its task, is to propagate the message until a next step.
Event dispatcher: is a process to achieve the message.
Local behavioral: is a mailbox to exchange two kinds of message. A first one is about the state of the mobile agent itself. Second, one is about the chain of messengers, which constituted a soft link between the sender and the receiver.
We are trying to be short in the presentation of implementation because it was approached previously [5]. However, the figure below highlights all the parts of a mobile agent with their responsibilities.
Figure 1. mobile agent has 4 concurrent activities
It is essential to note that only the first step “Initialization step” is essential for the execution of the other except the “Guardian step” which is autonomous. on the other hand the order or frequency of the execution of "Configuration step", “Runtime step” and “Reporting step” steps is not important it’s depend on software’s use or parameters. A. Initialization step When new software is installed, the prerequisite is to attach a security agent. Its basic task is to observe legal and illegal use; also, the agent has to have a clear statement of policy. It means that the agent has the rights to control the access for new software. This agent is called JAAS mobileagent for Java Authentication and Authorization Service agent. It plugged in under applications to provide a particular type of authentication for the future users. JAAS provides a powerful mechanism for integrating any authentication scheme into a Java control application. But using JAAS for mobile agent applications is not as simple as just plugging in a standard JAAS module, because of the limited security functionality of the mobile
specification (users and roles), versus JAAS's more flexible approach to granting principals (one view of the user as seen by the mobile application).
good for controlling access to resources like sockets and files, but has no concept of URLs. Thus, to apply JAAS to a mobile application, a new permission class must be created.
Depending on the application, it observes, the authentication strategy needs login modules. One thing is that we will need to determine is whether the login modules will require some form of user interaction (retrieving a user name and password, for example). If so, the agent will need to call callback handler. A login module can be considered as a particular authentication algorithm. In addition, a Strategy pattern allows choosing the right algorithm.
The authorization agent, which ensures the authenticated caller, has the access control rights (permissions) required to do subsequent security-sensitive operations. Then, its role is to authorize the current client. Who grant the permissions based on code characteristics: where the code is coming from, whether it is digitally signed, and if so? An example of such grant is given below
The login module invokes the callback handler specified by the application itself and passed to the login module's initialize method. The login module passes the callback handler an array of appropriate callbacks. It is possible for login module implementations not to have any end-user interactions This agent needs a configuration file that describes the authentication algorithm /** Login Configuration for the JAAS mobile agent **/ JAASMobileAgent { jaas.module.MobileAgentLoginModule required debug=true; }; The JAASMobileAgent authentication scheme has one required module. JAASMobileAgent implemented by the jaas.module.MobileAgentLoginModule class. Both the class name and a token indicating the relationship of the module to the scheme are mandatory. Here the required token indicates that the JAASMobileAgent module must validate this login or the scheme as a whole fails. It is also possible to pass additional information to the login module in this configuration file. This module needs to know where its password file is located for instance. One login module cannot be enough if the role check is complex. It is possible to chain the authentication algorithms. The next configuration file describes a more complex authentication algorithm JAASMobileAgent2 { jaas.module.MobileAgentLoginModule required; com.sun.security.auth.module.NTLoginModu le sufficient; com.extension.SmartPhone requisite debug=true; com.device.Kerberos optional debug=true; }; For instance, when new software is installed like MySQL, it is attached with a JAAS mobile agent for authenticating user. Permissions are the heart of authorization; they control access to resources. However, the JAAS permissions are built on top of the existing java security model. This model is very
grant codebase "file:./mobileAgent.jar"{ permission javax.security.auth.AuthPermission "createLoginContext.JAASMobileAgent"; permission mobile.security.MobilePermission "jini://host"; }; This grants the code in the mobileAgent.jar file, located in the current directory, the specified permission. The authorization augments the existing code-centric access controls with new user-centric access controls. Permissions can be granted based not just on what code is running but also on who is running it. When our mobile agent uses JAAS authentication to authenticate the client (or other entity such as a service), a Subject is created as a result. The purpose of the Subject is to represent the authenticated user. A Subject is comprised of a set of Principals, where each Principal represents an identity for that user. For example, a Subject could have a name Principal ("John Deuf") and a Social Security Number Principal ("123456789"), thereby distinguishing this Subject from other Subjects. Permissions can be granted in the policy to specific principals. After the user has been authenticated, the application can associate the Subject with the current access control context. For each subsequent security-checked operation (a local file access, for example), the mobile agent runtime will automatically determine whether the policy grants the required permission only to a specific Principal and if so, the operation will be allowed only if the Subject associated with the access control context contains the designated Principal. We create a custom Permission class, called MobilePermission that understands URLs. There are two ways to do this. Extending java.security.BasicPermission is one option. Using this would tie permissions to literal URLs (e.g., one could say that the admin principal should have access to the /host/admin page). However, the other option would be better: to create a MobilePermission class extended the java.security.Permission class and handled wild cards in a manner similar to the java.io.FilePermission class [6]. Then, one could say that the admin principal should have access to the /admin/ directory and all the resources below it. In either case, since URLs are read only, there is no need for any of these permissions to have an action attribute. On the
other hand, it may be useful to specify an attribute of a Permission to determine whether a given URL may be viewed over a secure connection [7]. However, since this is a proof of concept, a BasicPermission implementation is fine. For a production system, subclassing Permission would be required. This mobile agent is now the reference for all the accesses of the users. B. Configuration step When the JAAS mobile agent is installed with the new software, it is essential to configure the agent to accept users under some conditions. For instance, the user (John Deuf) can access to the software until the end of his project and no more. This assertion is a condition on the eventual accesses of a user. Two approaches are used:
A RuleSetter agent set up a list of security rules, which are essentials for new software's users.
A Profiler agent computes the needed rules, which will be used by the software's users.
a simple rule parser to aggregate, format, and output the rules in a readable format, sorted and grouped by codebase. Therefore, we see again that the ProfilerAgent satisfies both our design goals: * Our application runs under a security manager with a well-defined application-specific policy * We determined that policy programmatically How does ProfilerAgent work? ProfilerAgent overrides both versions of java.lang.SecurityManager's checkPermission method. The two forms of this method are the central chokepoints for examining to which resource or action the application requested access. The overridden checkPermission methods always return without throwing exceptions -- essentially meaning "access allowed" -- but not until they build and output the rule to allow the action responsible for their being called in the first place Because configuration is not always well known, RuleSetter and Profiler agents are complementary. The figure below (Figure 2 configuration step) highlights a sequence of configuration of new rule and discovering need.
We introduce a custom security manager mobile.security.ProfilerAgent. This class extends java.lang.SecurityManager, but does not enforce a security policy; it reports what that security policy would be if the application were granted access to everything, it requests runtime. We can then take that reportage and cast it into a starting point for a runtime security policy. Thus, both our goals are satisfied. To use ProfilerAgent, we first compile and strategically place it by itself in its own jar file. Placing ProfilerAgent alone in its own jar file will allow us to filter and suppress outputting rules that arise from actions originating in its own jar file codebase. Before we proceed too much further, we should note something about how to activate ProfilerAgent as our application's security manager. We forced our applications to run subject to the default Java security manager by setting the system property java.security.manager specifically without a corresponding property value. We need to take this one-step further and specify the custom security manager as the security manager by assigning a value to the system property: -Djava.security.manager= mobile.security.ProfilerAgent Thus activated, ProfilerAgent will write to a log file (we use The FileLock object a part of the java.nio.channels package to restrict access to the log file) the rules needed in a policy file that will allow the application to run without throwing security violation exceptions. However, these rules cannot be processed into a final, useable form until the application has completed its run under ProfilerAgent. The observed application has finished requesting access to checked resources, so the essential grants are known. Therefore, for processing the rules when the application has finished running under ProfilerAgent, we create
Figure 2. Configuartion step,
C. Runtime step This step is essential for software management process; it is like a runtime interface, which allows us to use the monitored applications in order to control their access better. We chose an agent peer host for overall applications; this agent can be either immobile for local applications, like text editor, or Web navigator… or mobile for the remote applications like database server. When a user, wants to use "MySQL" instance to run a query, he or she uses the client agent for that. The agent moves to concerned host and assigns the request to monitoring agent that performs the task and returns the result. The client agent comes back to the original host and displays the result to user. The following figure (Figure 3. Runtime step) schematizes a general sequence of use of applications using client agent. The subtlety of this mechanism is not only controlling access or applications use, it is also control of treatments, for example: a user, who has “UPDATE” privilege on a database, we can be rejected updating some tables. Unfortunately, it is not valid for all the applications, only the open applications that
have an application programming interface (API) or Extension allow us to handle them using other program.
Figure 3. Runtime step Figure 4. Reporting step
D. Reporting step The main idea is to have a mobile agent, which collects periodically, overall hosts, log files to centralize them in order to better supervise adhesions, to protect from the use of the illegal software, to keep up to date the list software and to envisage or plan the future needs. Thus, we manage effectively the software. This operation can be a simple programmed task at a predefined time; on the other hand, to be more reactive in front of critical situations the monitoring agent may notify the mobile agent for stepping in and retrieve the critical events. Sometimes the size of the log files is large in this case; it will be difficult or almost impossible to transport them through the network especially when we have several enormous files. Then we choose an agent analyst, which reacts as the mobile agent above mentioned, the different is that the analyst agent merges the data from all various logs file present on the host into only one then it analyzes it to keep and retrieve only the indispensable events. It important to say that the access to the log files is done via the monitoring agent to ensure the log files integrity and to avoid all malevolent attempts that eliminate or modify some traces. In addition, we think define an additional task for the analyst agent, this task consists in checking for each visited hosts the installed software without monitoring agent. Nevertheless, this additional task may overload and/or occupy the host's resources. That why we decide to add a new stage of observation and control. The following diagram (Figure 4. Reporting step) show the various stages of an agent analyzes.
E. Guardian step This new stage which is not commonplace, also we still studying some algorithm for an optimal solutions, consists in sending a mobile agent on each host in order to find all applications installed without any monitoring agent in order to react as guardian and remove them or to warn the administrator about their existence. However, the difficulty of this approach is to find the best and easiest way to search applications and also to decide on the action to perform. 1) Search For searching application, we consider three solutions; each one of them has its advantages and its disadvantages:
Elaborate search, it is the most confident manner. It consists in seek on the entire disc, but its execution time is proportional to the size of the disc and the number of files in this one.
Fast search, it is the fastest way but dependent on the operating system. It consists in analyzing the applications log access. That implies a strategy of system audit, which can reduce the performances of the host.
Target search, it is more confident than fast search and faster than elaborate search. It consists to compare the host to another model host (using a pattern matching) to define specific location to search in.
The last solution is certainly fast, but less effective. For this reason, we plan to couple it with elaborate search to obtain an optimal solution. The execution of those solutions will be on batch mode and at different frequencies like back-up systems: a weekly or monthly for complete search and daily planning for target search. 2) Decision Regarding decision action, we had the choice between three solutions to keep only one at the end:
Artificial intelligence: it is a good idea but it can make the stage more constraining and perhaps less effective in the case that we remove an essential application.
Behavioral: the agent passes by a training period to constitute a knowledge base (the host name, the user, the installation date, the number of use…).Then thanks to these data collects in its training period and some functions it can determine the action to do. Signature: A solution seems to us more adequate to this kind of treatment. It is not an innovation; it is methods that result form Snort system the reference of Intrusion Detection System (IDS) signature-based [8]. It consists in setting up signatures as decision rules so that the agent can react; in the case that the agent does not find the appropriate rule corresponding to the situations it warns the administrator therefore he or she update the referential signatures. This update, permit to the agent to react next time. Admittedly, this solution is not automatic but remains dynamic and flexible, that implies a rigour and big responsibility for the person in charge.
In the same way as Snort, the signatures must be completely contained on only one line to facilitate the analysis. The rules have a single identifier; they are divided into two logical sections: the heading, and the options (Figure 4. Rule example). The heading section contains the action to perform, the source that corresponds to the host and the user or his/her group. The option section contains the name of the application, the operating system, its version, the time of the installation, and the frequency of use if the operating system allows it (Example: Windows enables us to know the frequency of use of an application. Generally, it is Rarely, Occasionally or frequently, it is not reliable information but remains significant).
Alert: generate an alert,
Pass: Ignore the application,
Agent: install a monitoring agent,
Erase: Remove the application.
The second element is the host known by its IP addresses or its host name. For the rest, it corresponds to the user or his/her group membership. b) The rule option The options section corresponds to decision criteria combining facility of use and flexibility. All the options are separate from/to each other by a point comma “;”, the criteria keys are separated from their arguments by two points “:”. Five options optional are distinguished:
Appl: the application name,
OS: the operation system name,
Version: the operation system version,
Date: installation time,
Use: use frequency.
It is essential to say that the action Alert and Pass are not difficult, on the other hand the deployment of a monitoring agent and erasing application which isn’t monitoring by JAASAgent remains complicated. Currently, we are working on JMX technology (Java Management Extensions) to facilitate the deployment. Concerning removing action, we’re trying to use operation system to restrict access to the application instead of removing it. Also it involves new permission to guardian agent. IV.
CONCLUSION
Proper software management takes time and effort. Nevertheless, the payback is well worth it. If we have followed the process outlined in this document, we have taken the steps necessary to get the full benefit from our software – and to eliminate our company’s exposure to penalties for illegal software use. The benefit of mobile agent is the adaptability: the observers against the context of users. Mobility allows agent to react and to propagate information to the decision center without any perturbation. Because the set of permission rules is huge, it could be interesting to have language that is more powerful for permission expression. In our work, we have to define permission classes for any new software. That implies management that is more complex.
Figure 5. Rule example
a) The rule heading: The heading section contains information which defines “who, where and what”. The first element in the rule is the action to perform when an application corresponds to the criteria of rule. We enumerate four types:
REFERENCES [1]
[2] [3]
[4] [5]
[6] [7] [8]
Rapid Recovery Techniques: Auditing Custom Software Configuration By Richard Elling – Enterprise Engineering Sun BluePrints™ OnLine February 2000. Source: International Markess, February 2007 (journaldunet.com) D. Bonura, R. Culmone and M. Angeletti, A Pattern for Reactive Mobile Agent in Genome Database Annotation (Poster), NETTAB02 Agents in Bioinformatics, Bologna, 2002. Seven implementation of the Jini Service Container Specification http://www.cheiron.org/seven/index.html M.Bernichi, F.Mourlin, Mobile Agent Communication Scheme (An Evolving Canvas), in International Conference on Systems and Networks Communications, Papette, Tahiti, French Polynesia, 29 October-3 November 2006, IEEE Computer Society Press, 2006, pp 6-9. Java Web Services Developer Pack http://java.sun.com/webservices/docs/1.6 The Java Authentication and Authorization Service (JAAS) http://www128.ibm.com/developerworks/library/j-jaas Martin Roesch, “SNORT - lightweight intrusion detection for networks,” in LISA ’99: USENIX 13th Systems Administration Conference on System administration, Seattle, Washington, Nov. 1999, pp. 229–238.
