oriented applications as a result of a secure development process lifecycle. Key words: Service Oriented Architecture, Service. Oriented Product Line, software ...
Towards a Secure Service Oriented Product Line Achour Ines1, Sheima Khadouma2, Lamia Labed3 and Henda Ben Ghezala1 Computer Science Department, Manouba University/ ENSI/ Lab. RIADI-GDL, Manouba, Tunisia 2 Computer Science Department, Tunis University/ ISG/ Lab. SOIE and RIADI-GDL, Tunis, Tunisia 3 Computer Science Department, Tunis University / ISG / Lab. RIADI-GDL, Manouba, Tunisia 1
Abstract - In this work, we are dealing with service oriented applications which are based on service oriented architecture style. Also, we are interested on the large scale reuse paradigm which deals with a service line. This former envisions a family of similar service oriented applications. This approach promise gain in productivity and time to market. Combining SOA and service line is called SOPL (Service Oriented Product Line). The services which are autonomous play a fundamental role in SOPL. Assuring secure services is vital in establishing a climate of trust and confidence between Internet users and services providers. In this context, this paper deals with an attempt to extend the SOPL phases with security activities in order to produce secure service oriented applications as a result of a secure development process lifecycle. Key words: Service Oriented Architecture, Service Oriented Product Line, software security, secure domain engineering, secure application engineering.
1
Introduction
In a connected and open world, the confidence of Internet users is aligned to the provision of safe and secure services. We consider a family of service software applications that share common features where they differ from some others. This will enhance a better reuse and assure best productivity and time to market as promised by product line engineering in general. SOA architecture [1] provides applications with greater flexibility and a remedy to interoperability and heterogeneity problems. But thinking about family of such applications leads to a new concept known as SOPL. The security of the service oriented applications goes through integrating security requirements upstream (early in the software development process). Several studies [2, 3, 4] have shifted their interest from secure applications to the development process leading to their construction. Security concerns become proactive instead of reactive. In this paper, we propose to enrich the Service Oriented Product Line
(SOPL) process by security activities in order to produce secure applications. Section 2 concerns a small outline of the software security. In Section 3, we elaborate an introduction to the Service Oriented Product Line process. In Section 4, we introduce the secure SOPL process. Section 5 deals with detailing the security activities in the domain engineering which is the first phase of the SOPL process. In Section 6, we highlight the security activities in the application engineering which is the second phase of the SOPL process. We then present in Section 7 a general discussion about related works and position our proposed approach. Finally, Section 8 summarizes our work and presents a discussion before outlining our long term future work.
2
Software Security
Security applications are added as features and mechanisms at the end of the development process independently of the other features of the system to protect the application against potential threats (reactive security). In contrast, secure applications are applications resulting from a development process in which most security problems are addressed and resolved in advance [5] (proactive security). They are designed and implemented so that they can function correctly in the presence of attacks. As we focus on the development of secure services, we cannot ignore efforts in strengthening the assurance of services security. Indeed, several studies in [6] and [1] have been developed such as WS-security [1], etc. But, this does not prevent us from noting that security is more robust if it is structured and integrated throughout the service development cycle.
3
SOPL Process
Service Oriented Architecture (SOA) is an approach that aids solving integration and interoperability problems [7]. Nevertheless, it does not provide support for systematic planned reuse as does Software Product Line engineering. This latter has the principles of variability, customization and systematic planned reuse and can be used to assist
SOA to reach its benefits. Hence, it appears a recent approach called Service Oriented Product Line (SOPL) which is introduced at the 11th edition of the International Conference SPLC (the ‘Software Product Line Conference’) in 2007. The SOPL approach is a combination of Software Product Line engineering and Service Oriented Architecture approach providing thus solutions to many common software problems as reuse and interoperability issues [7]. It allows developing applications oriented SOA as Software Product Lines (SPL). Thus, the term Service-Oriented Product Line is used for service oriented applications that share commonalities and vary in an identifiable manner. Therefore, we deal with a service line which is a group of services sharing a common set of features. In fact, SOPL process introduces variability management concepts into Service Oriented Architecture and applies SPL engineering life cycles as shown in figure 1:
list identified in the domain engineering. The selection responds to the functionalities required by the application to develop. Next, the configuration and the specialization of selected components, services and composite services, and architecture specification are performed during the application design. Product construction, in the application implantation phase, concludes the SOPL process.
4
Secure SOPL Process
In what follows, we present the life cycle of an SOPL based on [10, 11, 12, 13, 14], and essentially on Medeiros and al [7] and Helali [9] works to which we integrate security activities. As depicted in figure 2, these activities strengthen the security throughout the development process. We have inspired by security activities proposed by three validated secure development processes which are Touchpoints, CLASP and SDL [15, 2, 3, 4]. These processes are the most used, validated and proven in this field. Our secure SOPL inherits from the classic SOPL its two principle phases which are the domain engineering and the application engineering phases.
Figure 1: Service Oriented Product Line process The domain engineering phase defines the development for reuse. The application engineering phase presents the development with reuse. The SOPL process begins with a domain engineering phase [7]. It uses the feature model [8] and the business process model as inputs, in order to produce during the domain analysis a list of components, services and composite services candidates for reuse. Afterward, during the domain design, a variability analysis is executed through components and services identified previously. It defines the variability that will be implemented within the services and components. Subsequently, in an architecture specification activity, the components, services, and their flows will be specified using different views. During the application engineering [9], in the application analysis phase, components, services and composite services are selected from the
Figure 2: Secure Service Oriented Product Line process
5
Secure domain engineering
Secure domain engineering is divided into four phases namely: training and awareness, domain analysis, domain design and domain implantation.
5.1
Training and awareness
Touchpoints, CLASP and SDL processes emphasize the importance of training and education in security software to every member of the project. Thus, during this phase, the team member should be given a baseline education in software security in order to get knowledge in security engineering basics. It increases their awareness of the importance of the domain problems on which they operate and its broad scope. In this sense, it is essential to: - Plan regular courses for the development team [4]. These courses cover the latest security software issues since it is an evolving field where it frequently reflects the emergence of new threats. - Promote sharing and communication artifacts such as security threat models within the development team [3]. - Assign a security adviser to the project. This adviser helps developers with security related issues and possibly serves as a gateway between developers and a dedicated security team (if available) [3].
5.2
Domain analysis
For the domain analysis, we begin first by identifying and analyzing business requirements as in classical product line approaches [16]. We then conduct functional security requirements of the domain more deeply than in product line approaches. Then, we move to identify components, services and composite services candidates for reuse to analyze their variability thereafter. Finally, we conduct a risk management for each element of the reuse candidate list. Note that we adopt in this phase, the Risk Management Framework (RMF) proposed by the Touchpoints approach [2]. This choice is motivated by the robustness offered by this process in terms of risk management. But this doesn't exclude the use of other risk management techniques which are numerous in the security domain field. 5.2.1
Functional requirements identification
We apply, at this stage, the first activity of the RMF process called the business context understanding [2] to which we integrate activities related to SOPL. This activity helps to better assimilate functionalities and the domain of study by the developers community for reuse. It also presents the starting point for other activities measurement and risk analysis. This step includes the following activities: - Resources and artifacts gathering [2]: it comes to identify resources and possible artifacts of the service line that we intend to develop (such as data used, etc.). - Business processes representation: these processes are used to identify candidate services for reuse [7].
- Feature Model development by the application of the Feature Oriented Domain Analysis method (FODA) [8]: this model is used to identify candidate components for reuse. 5.2.2
Security requirements identification
The security requirements elicitation is performed by using a threat modeling and the commercial and political requirements related to the environment. We note that the threat modeling gives rise to a threat model document for the members of the development team helping them understand eventual threats and how to treat them. Threat modeling is an iterative process [17] spanning the entire cycle of our secure SOPL. This is explained by the impossibility of identifying all threats at once and by the dynamic aspect of applications faced to the need for an adaptation to changes. Threat modeling is a fundamental task for any security-oriented effort. In order to reinforce this point, we opt for several approaches to perform the threat modeling [3, 18]. During use case driven threat modeling, attacks to all functional use cases of the domain are identified. Resource driven threat modeling focuses on legal use of resources. Finally, through knowledge driven threat modeling, known attacks are assessed whether they can be valid and useful for the domain at hand. Apart from the aforementioned threat modeling, extra security requirements can be specified based on laws and regulations, contractual obligations and commercial considerations [2]. Before proceeding to the next step, developers must not forget to enrich the Feature Model with results obtained through abuse cases. 5.2.3
Components, services services identification
and
composite
This stage is based on the Feature Model and Business Process Models already established for determining the list of components, services and composite services that support business processes. 5.2.4
Variability analysis
The variability analysis activity starts with an analysis of similarities and variabilities between components and services with the purpose to reduce the number of service candidates. The similarity analysis consists in comparing the functionalities of components and services in order to join similar services with the fine-grained variability [7]. Indeed, variability is the ability to change or adapt software systems. Several mechanisms of variability management are available in the literature [19] such as parameterization, inheritance, conditional compilation, etc.
5.2.5
Risk management
Once the components, services and composite services list is established, we apply at this stage the risk management process RMF. Thus for each component, service and composite service, we proceed to: - Business and technical risks Identification: a component, a service or a composite service is based on two aspects. First, a business aspect represents the purpose and the role of a component, a service or a composite service in relation to the global business context. Second, a technical aspect evokes the technical methods used for an element construction. So during this process activity [2], we identify business risks and technical risks that could have a negative impact on the items above. Thus, the analyst must begin by developing risk questionnaires [2] to ask about risks threatening the domain. These questionnaires are sent to the entire team of developers for reuse. Then, the analyst, based on results of questionnaires, focuses on identifying business objectives, business risks while trying to identify indicators of the latter, their occurrence probability, their impact, their cost, etc [2]. Then, the analyst proceeds to identify the technical risks (risk indicators, their probability of occurrence, their impact and severity level) [2]. - The synthesis and prioritization of risks: to better understand and manage a particular risk, the analyst is required to establish relationships between business requirements, business risks, and technical risks of the component or the service to be secured in a Goal-torisk relationship table [2]. The prioritization process must take into account which business goals are the most important to the organization and which goals are the most threatened.
5.3
Domain design
For the domain design, we start with the security principles definition which will be adopted in the construction of the reference architecture. Then, we specify the architecture and finally we perform an architectural threat modeling. 5.3.1
Security principles definition
The robustness of a system proceeds imperatively by security choices undertaken during the architecture specification. Thus, according to [20] several security principles can be considered such as the assumption that any interaction with a third-party product is risky and so by considering incoming data as suspect and by isolating critical assets, etc.
5.3.2
Reference architecture specification
The reference architecture of the service line is built following security principles and architectural decisions taken at the variability analysis. During the architecture specification, different architectural views can be produced [7]: - A structural view for representing the static structure of the architecture specified. - A layer view for representing components and services organized in their layers. - An interaction view showing communications and interactions between components and services when achieving a particular functionality. - A dependency view showing the dependence information among services and components. - A concurrency view showing parallel communication among services and components. - A physical view showing the communication protocols and distribution of components and services. 5.3.3
Architectural threat modeling
During architectural threat modeling, it is essential to pursue threats identification started in the domain analysis. So, it is recommended to: - Identify threats using the STRIDE method [18] which provides a classification of types of threats. - Create attacks models that describe the attacker target, the attacker motivation and the used techniques [2]. - Evaluate threats identified using the DREAD model [18]. - Define the risk mitigation strategy: given a set of risks and their priorities, the next stage is to create a coherent strategy for mitigating (remove the feature, solving the problem, etc.) [2]. The risks mitigation takes into account cost, implementation time, likelihood of success, and impact over the entire corpus of risks.
5.4
Domain implantation
Domain implantation consists in: 1) the implementation of identified components, services and composite services and in 2) the verification of their adherence to specified business requirements and functional security requirements. 5.4.1
Components, services and services implementation
composite
During this stage, developers for reuse build components, services and composite services of the asset base. They should respect a set of practices [21] to improve the security code such as: choosing a secure programming language (e.g J2EE [22]), using security standards dedicated to services (e.g WS-
Security [1]), using code analysis tools [23], etc. Also, developers for reuse are expected to prepare documentation to the development community with reuse by defining security software practices used during the secure engineering domain. 5.4.2
Components, services services testing
and
composite
After finishing the coding stage, the development team for reuse focuses on components, services and composite services testing. We suggest, therefore, applying two different approaches for testing: - White-hat approach [15]: this approach allows testing business functionalities of components, services and composite services such as "Request for birth certificate" service in the case of an administration on line. - Black-hat approach [15]: this approach allows testing security features and the resistance to possible attacks discovered during the risk analysis. Black-hat approach takes into account the worst case scenario of use cases. In this case, we suggest performing penetration tests [24]. Testing-related security activities should be documented and made available for the development team with reuse. Such documentation can be used for instance as a reference point for corrective actions oriented security.
6
Secure application engineering
Secure domain engineering produces reusable artefacts such as secure services and secure reference architecture. Now, for a given application, secure application engineering will instantiate and specialize the secure reusable assets. Note that new applications security issues emerge through assembling application’s components, services and composite services. Hence, they can lead to security risks and damage the application. Secure application engineering is divided into four phases: training and awareness, application requirements analysis, application design and application implantation. We are not going to present all of them because of space constrains.
6.1
Application requirements analysis
The application development team identifies, first, security requirements of the application derived from the service line. These security requirements are elicitated from use cases and the operational environment. Application security requirements are specified at the host level and the network level. Then, the security requirements are prioritized based on threat levels such as protecting sensitive data,
features that require privileges, etc. At this level, we propose to apply Common Criteria method (Common Criteria for Information Technology Security Evaluation) [25]. This method presents functional requirements in the form of a components catalog to meet certain security objectives, and assurance requirements which provide actions to ensure compliance with these objectives. Based on this analysis, components, services and composite services are selected from the asset base built in the secure domain engineering.
6.2
Application design
The application design includes the configuration and the specialization of candidates for reuse previously selected, a risk assessment of thirdparty products (if available) and a threat modeling by identifying appropriate defense mechanisms. After selecting components, services and composite services, the developers team may use third-party components or services (external to the asset base). This integration can lead to security risks that could damage the application security [15]. Developers can apply the RMF process to assess such risks. We note that this step is not really mandatory, but it may be possible. The architecture specification is performed by instantiating the reference architecture and that by keeping only components, services and composite services required by the derived application. An audit of the consistency constraints set at the secure domain engineering should be conducted to ensure the compliance of the application architecture with the reference architecture. It is appropriate to check with the threat model built during the application design phase the possible emergence of new threats that may arise through assembling components, services and composite services. This is explained by the fact that the threat modeling in the secure domain engineering is conducted for each component, service and composite service. It refers to a local threat modeling. However, the threat modeling in this phase must be performed on the whole set of components, services and composite services required by the derived application from the service line. It refers to a global threat modeling. In case of identification of a new threat, this latter is categorized as STRIDE categories [18] and developers must develop appropriate security strategies.
6.3
Application implantation
For the application implantation, developers begin by constructing the application. Then, they proceed to test its security features and its resistance to attacks and finally they elaborate the appropriate documentation.
To validate the developed application, we recommend to developers to perform integration tests [26] and acceptance tests [27]. Integration tests allow validating that components, services and composite services developed independently communicate together coherently. These tests can be automated by tools such as Eggplant [28] and JUnit [29], etc. Regarding acceptance tests, they allow testing the application in its real environment by the end user. The client in this case may provide the development team with a feedback from performed tests. After ensuring that the developed application meets the specified business requirements and the functional security requirements, the development team with reuse produces the documentation and guides for security administrators and end users.
7
Discussion
Several works have been conducted for securing web services [1,6] such as WS-security, WS-Trust, WS-Conversation [1], etc. But, security is more robust if it is structured and integrated throughout the service oriented application development cycle. The SDL, CLASP and the Touchpoints approaches [4, 3, 2, 15], which are the most used, proved and validated approaches for producing secure applications can be used for service oriented applications. But, we want to use the systematic large scale reuse paradigm which causes the creation of another secure development process. For that, we have added secure activities in the SOPL process and we have inspired by those of the three mentioned validated processes. So, the resulted process is theoretically validated. It appears to be too high level and very descriptive because we need to add all the security activities. But when conducting an example to illustrate the use of the secure SOPL process, the process usage will be more concrete with more details. We in fact, apply it to a family of e-vote applications where security issues are numerous. We have identified several reusable services and components for different e-vote systems such as presidential election, laws elections, etc. In fact, similarities and differences appear in the e-vote systems. The secure domain engineering phase permits to obtain a secure reference architecture where the security attributes were deeply taken into account and produces several secure artifacts such as secure services. The secure application engineering phase allows obtaining different secure e-vote applications. The limitation of our proposed approach is that dealing with security issues involves the use of a lot of security techniques and methods which can be perceived by the user as difficult and boring but this is the price to pay for obtaining secure service oriented applications.
8
Conclusion
The principle aim of this work is to integrate security activities in the Service Oriented Product Line process in order to produce secure services proactively. In this work, we have inspired by the SDL, CLASP and the Touchpoints approaches [4, 3, 2, 15], which are the most used, proved and validated approaches for producing secure applications. So, we have added several security activities in the SOPL process and also advocate the use of different security methods, concepts and frameworks (such as RMF, STRIDE and Common Criteria) which are well suited for such context. This does not exclude the use of other security mechanisms which are numerous in the security field. This work aims to ensure the development of an application (service based in our case) by taking advantages of three concepts contributions: a large-scale reuse system that’s product line engineering, service oriented architecture and software security. Our perspectives are first the application and the use of our secure SOPL in different E-Government domain applications, where we adopt SOPL reference architecture for a family of E-Government services. As mentioned previously, we have begun with a family of e-vote applications. Second, we would like to validate our proposed secure SOPL process and its use in different contexts such as e-commerce, e-learning, etc.
9 Acknowledgment This work has been supported by the Tunisian project S2EG (Secured Systems for the EGovernment) which presents the collaboration of three research structures: SOIE, CRISTAL and RIADI and financed by the ministry of communication technologies of Tunisia.
10 References [1] Ort E., “Service-Oriented Architecture and Web Services: Concepts, Technologies, and Tools”, Technical Report, SUN, 2005. [2] MacGraw G., “Software Security: Building Security In”, Addison-Wesley Professional, ISBN: 978-0-321-35670-3, 2006. [3] OWASP Corporation, “CLASP Comprehensive Lightweight Application Security Process”, 2006. [4] Lipner S., “The trustworthy computing security development lifecycle”, Computer Security Applications Conference, 2004. 20th Annual Publication, ISSN: 1063-9527, ISBN: 0-7695-2252-1, pp. 2-13, 2004.
[5] Goertzel K., Winograd T., McKinley H., Oh L., Colon M., McGibbon T., Fedchak E. and Vienneau R., “Software Security Assurance”, State-of-the-Art Report (SOAR), 2007. [6] Guruge A., “Web Services: Theory and Practices”, Digital Press, 2004. [7] Medeiros F., Romero S. and Santana E., “Towards an Approach for Service-Oriented Product Line Architectures”, 13th International Software Product Line Conference (SPLC 2009), San Fransisco, CA, USA, 2009. [8] Kang K., Cohen S., Hess J., Novak W. and Peterson S., “Feature-Oriented Domain Analysis (FODA) Feasibility Study”, Technical Report CMU/SEI-90-TR-21, Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PA, 1990. [9] Helali R., “Product Lines approach for the derivation of software applications in E-Government”, Master, university of Tunis, 2010. [10] Berger T. and Gunther S., “Service-Oriented Product Lines: Towards a Development Process and Feature Management Model for Web Services”, 12th International Software Product Line Conference (SPLC 2008), Limerick, Ireland, 2008. [11] Heferich A., Herzwurm G. and Jess S., “Software Product Lines and Service-Oriented Architecture: A Systematic Comparison of Two Concepts”, Proc. of the First Workshop on Service-Oriented Architectures and Software Product Lines, pp. 31-37, 2008.
[16] Clements P., and Northrop L., “Software product lines: practices and patterns”. Addison- Wesley, Boston, MA, 2001. [17] Meier J.D., Mackman A. and Wastell B., “Patterns & practices Library”, Microsoft Corporation , 2005. [18] Meier J.D., Mackman A., Vasireddy S., Dunner M., Escamilla R. and Murukan A., “Improving Web Application Security: Threats and Countermeasures”, Microsoft Corporation, 2003. [19] Gomaa H., “Designing Software Product Lines with UML: From Use Cases to Pattern-Based Software Architectures”, Addison-Wesley Professional, ISBN:0201775956, 2004. [20] Stoneburner G., Hayden C. and Feringa A., “Engineering Principles for Information Technology Security (A Baseline for Achieving Security), Revision A”, Recommendations of the National Institute of Standards and Technology, 2004. [21] Howard M. and Microsoft Corporation, “Fundamental practices for secure software development”, Stacy Simpson, SAFECode, 2008. [22] Batchelli A., “A Brief Introduction to J2EE”, 2006, http://www.voneicken.com/courses/ucsbcs290f-fa06/images/d/df/Lecture17.pdf, [12 Feb 2011]. [23] Security Innovation Corporation, Report: Static Analysis Tools”, 2004.
[12] Lee J., Kim M., Muthig D., Naab M. and Park S., “Identifying and Specifying Reusable Services of Service Centric Systems Through Product Line Technology”, Proc. of the First Workshop on ServiceOriented Architectures and Software Product Lines, pp. 57-67, 2008.
[24] AppLabs, Testing”, 2009.
[13] Mannisto T., Myllarniemi V. and Raatikainen M., “Comparison of service and Software Product Family Modeling”, Proc. of the First Workshop on Service-Oriented Architectures and Software Product Lines, pp. 47-57, 2008.
[26] Bradley T., “Integration Testing”, 2008.
[14] Wienands C., “Synergies between ServiceOriented Architecture and Software Product Lines”. Siemens Corporate Research Princeton, NJ, 2006.
[28]http://www.testplant.com/products/eggplant_funct ional_tester, [26 Feb 2011].
[15] De Win B., Scandariato R., Buyens K., Grégoire J. and Joosen W., “On the secure software development process: CLASP, SDL and Touchpoints compared”, Information and Software Technology, Vol.51, No. 7, pp. 1152-1171, 2009.
“Web
Application
“Hacker
Penetration
[25] Common Criteria Recognition Agreement, “Common Criteria for Information Technology Security Evaluation”, 2009.
[27] “Software Testing - Acceptance Testing”, http://www.buzzle.com/articles/software-testingacceptance-testing.html, [26 Feb 2011].
[29] http://www.JUnit.org, [26 Feb 2011].
