Security in the Development Process of Mobile Grid Systems

- For instance, authors in (Steel et al., 2005) present a methodology for the integration of the security on software systems.
- is very specific and it is applicable only to certain stages of the development process.
- This architecture does not support the dynamic behaviour of the Grid..
- Other of the approaches is the Surrogate approach wich defines a middleware that will allow handheld devices, e.g.
- This is due to the fact that none of the approaches defines a systematic development process for this specific kind of systems that incorporates security from the earliest stages of the development.
- Neither of them offers solutions that integrate mobile devices as own resources of the Grid under a global security environment..
- The structure of the process which we propose follows the classical cycle (see Fig.
- 3.2 Models of the process.
- ii) the reference security architecture used in the design activity, which ensures the fulfillment of the security requirements for these systems and that is service-oriented (Rosado et al., 2010a.
- and finally, iv) the reusable elements of the repository that are used in the different tasks of the process and that help us build artifacts in an easy, fast and reliable way (Rosado et al., 2009a.
- 3.3 Activities of the process.
- This obtains, builds, defines and refines the use cases of the secure Mobile Grid systems which represent the functional and non-functional.
- The analysis activity is based on use cases in which we define the behaviour, actions and interactions with those implied by the system (actors) to obtain a first approach to the needs and requirements (functional and non-functional) of the system to be constructed.
- UC Repository Defining UC of the application.
- Tasks and artifacts of the Secure Mobile Grid System Analysis activity.
- 2 shows a graphical representation of the analysis activity tasks using SPEM 2.0 diagrams.
- Initially, in the “Defining UC of the application” task, we define the functional use cases of the application identified from the stakeholder needs and study the interactions with the user without considering the specific aspects of Mobile Grid environments.
- “Identifying secure Mobile Grid UC” task, we study the security aspects of the application within the Mobile Grid context and identify the possible security use cases and misuse cases that can be reused from those defined in the repository, for the system in development.
- We can also reuse and integrate some diagrams with common features of the repository which have been previously built for Mobile Grid environments.
- In the “Supporting with UML models” task, we complete the analysis model with different UML models such as the sequence and collaboration diagrams according to use cases and scenarios, or class diagrams for an initial structural description of the system from the use cases diagrams built in previous tasks.
- Finally, the “Specifying Requirements” task consists of the formal definition of the requirements identified in previous tasks (functional requirements and non-functional requirements including security) in natural language (though a template of requirements specification will be defined in the future)..
- In our approach, this activity is supported by a reference security architecture which covers and fulfills the security requirements of the Mobile Grid system specified in the analysis activity.
- The design activity is centred on building the secure software architecture of the system through UML views, services and a reference security architecture stored in the repository..
- graphical representation of the design activity tasks using SPEM 2.0 diagrams.
- “Designing Mobile Grid Software Architecture” task designs a software architecture following the steps, methods and techniques of the typical development processes (as the Unified Process (Jacobson et al., 1999), TOGAF (Open Group, 2009), etc.) using UML diagrams, views and realizations of use cases from the use cases model and analysis model defined in the analysis activity for Mobile Grid systems.
- The “Designing Mobile Grid Security Architecture” task defines the security architecture using the reusable elements of the repository and following the security Requirement-Service association rules of use cases to security services from the use cases of the analysis model.
- Tasks of the Secure Mobile Grid System Design activity.
- In the repository the most used tools to build this kind of systems together with common services implemented in different programming languages, generated in other executions of the process are available.
- Tasks of the Secure Mobile Grid System Construction activity.
- The construction activity is composed of tasks which implement the designed secure software architecture for obtaining an executable final product with the help of the tools and technologies available for Mobile Grid computing.
- 4 shows a graphical representation of the construction activity tasks using SPEM 2.0 diagrams.
- The tests and security tests of all components of the implemented system have to be checked in the.
- This tool is focused on the construction and definition of secure Grid use cases diagrams, and on the management of the repository that stores reusable artifacts which can be reused in the construction of diagrams..
- SMGridTool performs automatically the validation of the use cases diagrams, checking the constraints defined by the GridUCSec-profile for each use case and relationship.
- The tool automates the analysis activity of the development process for Secure Mobile Grid Systems, but our objective is that in future versions it will also support the design activity.
- In short, the SMGridTool has been developed to facilitate building and managing specific use cases diagrams for Mobile Grid environments which are necessary for carrying out an exhaustive and deep analysis of the needs and requirements of this kind of systems..
- In the next iterations, that have been omitted here, this part of the system will be refined and extended with new elements and the process will again be applied to obtain a new version of the product.
- In this case, we will describe the first iteration of the process for a set of initial needs, not all, and we will obtain in the analysis activity the functional and security requirements of the case study using the defined model GridUCSec-profile and the SMGridTool which help us build security use cases diagrams for Mobile Grids.
- The set of requirements have to be incorporated into the secure software architecture in the design activity and later, we will implement from this architecture, a first version of the product.
- 4.1 Application of the analysis activity.
- The aim of this first iteration in the analysis activity is to define a set of requirements of the system (most of them) through the use cases diagrams built with the help of the SMGridTool and the repository of reusable elements of the process.
- Defining UC of the application.
- Once we have identified the functional use cases of the application, now, we must identify all the use cases and security use cases for the Grid system that are related to the functional use cases of the application.
- We use the reusable artifacts of the repository where many of these use cases for Grid systems and diagrams that can be easily used in this application and that help us obtain use cases, actors and associations that are necessary in this application are defined..
- To define the Grid use cases we will use the GridUCSec-profile defined as a model of the process and using the repository where a large set of Grid use cases are defined, we can build the Grid use case diagram, with the SMGridTool, where security use cases and misuse cases oriented to Mobile Grid are present..
- In the repository we have a set of generic use cases which have a common behaviour for any Grid systems and have been identified in other executions of the process and that can be used in this application.
- Generic Grid Use Cases of the repository.
- Identify security Assets of the application in a Mobile Grid environment.
- Identify Threats, Attacks and Risks of the application in a Mobile Grid environment.
- In the repository, the main security use cases for Mobile Grid environments, and misuse cases that capture the behaviour of the main threats identified in these environments are defined.
- In Table 1 we define the impact and risk for some of the threats identified previously.
- In previous tasks, we have been studying and analyzing artifacts of the repository (use cases) that define common features for Grid environments and that can be usable for this specific application, as it is.
- These reusable artifacts have been identified and used in the previous tasks in an isolate way resolving the tasks suggested and obtaining concrete results of the application analysis.
- Now we have to add all these defined artifacts to the use cases diagram of the application and define the relationships, according to the GridUCSec-profile, between functional use cases, generic Grid use cases, security use cases and misuse cases..
- These properties are defined with the GridUCSec-profile model that has been elaborated for capturing the specific features and values of the use cases for Mobile Grid systems.
- As the overall diagram is complex to define here, we will describe a sub-diagram for showing how the GridUCSec-profile is used in the definition of the use cases and relationships involved..
- 7 shows a sub-diagram of the overall diagram which will be used for describing its elements according to the GridUCSec-profile model..
- We also have the “«MisuseCase» Alteration info” misuse case that threatens the modification or alteration of the information exchanged in the messages every time that a request is sent to the system.
- “«GridSecurityUC» Ensure Integrity” UCs which are part of the reusable sub-diagram stored in the repository.
- Finally, the “«MobileUC» Search News” UC is identified as a mobile UC due to the possible mobility of the user who requests information from the system from the mobile devices.
- Sub-diagram of the overall diagram of the application.
- This validation is automatic using the SMGridTool that is responsible for controlling the constraints of the use cases, the relationships between elements and that the possible values selected are within the range specified in the GridUCSec-profile..
- With these models we can define the actions between actors and use cases, and the flow of events produced between the elements of the diagram.
- “«GridSecurityUC» Ensure Integrity” of the reusable repository, which has also a generic sequence diagram associated that we have to instantiate with the actors involved in this scenario.
- To finish this task, besides of interaction diagrams, other diagrams that completely define the behaviour of the use cases and facilitate the specification of requirements are defined.
- In this step, we will follow the analysis stage of the Unified Process, which defines classes diagrams, use case realizations, and initially describes packages and development diagrams which will be used and refined in the design activity..
- This is the last task of analysis activity and it specifies the set of requirements extracted from the use cases identified during all the previous tasks obtaining a description of functional and non-functional requirements of the system.
- generated in this activity can be summarized and formally described in a document which will be part of the analysis model in future works.
- A first vision of security requirements that can be extracted from the functional use cases and security use cases of the application are: System requires authentication mechanisms for user identification.
- Single authentication process is required for accessing the functionality of the system.
- Manish Parashar et al., 2005), this step presents the non-functional requirements, which should be considered during the development of the Grid system: Performance.
- The output artifacts of this task are: “Requirements” artifact that defines all requirements (functional and non-functional) specified in this task, and “Analysis conflicts” artifact that identifies the possible conflicts or errors found in the specification of requirements and in the building of the use cases diagrams.
- 4.2 Application of the design activity.
- This task defines the software architecture of the system using traditional methods and mechanisms of software engineering as the Unified Process, OPEN, OpenUP, etc.
- The software architecture is designed from functional requirements and use cases of the application that have been analyzed following the techniques and guides offered by some development processes but its input artifact is the analysis model elaborated in the previous activity of this process..
- This task defines the security architecture where all security aspects of the application are taken into account.
- In this first iteration of the process, we are working with a reduced set of security use cases for simplicity, so that the same security use cases identified in the analysis activity will be selected for developing the different tasks of the design activity of the process.
- Each one of these security use cases are associated with some or many security services of the reference security architecture which will be identified in the next step..
- We cannot forget the Grid Security Policy service and the Mobile Policy service which are needed to manage the different policies of the system.
- These security services are obtained of the relationship with the security requirements which are defined as tagged values in the GridUCSec-profile..
- We must have security policies associated with each Grid security service of the instantiated architecture (for example, the security policy of the authorization service).
- Grid Security Policies govern and control the overall security of the Grid system and are associated with the security services, with inter-, intra- organizational partnerships, with.
- The output artifact is a part of the security architecture designed from the set of use cases selected and with the help of the reference security architecture..
- Elements of the security architecture should be integrated into the software architecture because many software elements have to make use of the security elements, and the security elements have to act over the software elements to provide security in the system..
- Systems Architect and Security Architect created an initial version of the document of secure software architecture in which all the information outlined in the previous points is widespread.
- Therefore, artifacts of the activity analysis are needed as input to the design activity and are the basis for developing the artifacts of the design model..
- 4.3 Application of the construction activity.
- Finally, in the construction activity, a possible implementation of the elements previously designed is carried out.
- We have as input artefact, just one element of the design model (the authorization service, we have omitted the rest) and all grid components identified and installed previously.
- The authorization service of the reference security architecture designed in the design activity defines one operation for PIP interface and two operations for PDP interface.
- Therefore, if we define the interfaces of Globus for the security services of the architecture, we can easily implement a robust authorization service.
- As output artifacts, we obtain a part of the secure Mobile Grid system artifact (the part corresponding to the implementation of the authorization service), and the implementation structure of the authorization service..
- We can validate that the security services of authentication, authorization, confidentiality and integrity which have been designed in the previous activity are implemented with security mechanisms that carry out the protection of the system complying with a set of requirements specified in the analysis activity.
- The tests of the system are carried out once the system has been completely built..
- This paper has proposed a development process for secure Mobile Grid systems (SecMobGrid), which enables to develop in a systematic and secure way a Grid system with mobile devices incorporating security from the earliest stages of development and based on the reuse of artifacts which have been generated in the different applications of the process..
- This is an iterative and incremental process and exploits the reusability of the different artifacts that are generated during the process.
- and the construction activity that is in charge of the implementation of the system using the existing tools for the development of Grid systems..
- As future work, we will concrete and refine the generic tasks of the used development processes that have been incorporated into the SecMobGrid process.
- Grid resource management:state of the art and future trends: 73-98..
- The Physiology of the Grid: An Open Grid Services Architecture for Distributed Systems Integration