An Open Process for Software Development in Classified Environments as Prerequisite for Military App Stores Thomas Kudla∗ , Markus Esch∗ , Daniel Ota∗ and Gerhard Schwarz† ∗ Fraunhofer
Institute for Communication, Information Processing and Ergonomics FKIE Wachtberg, Germany Email: {thomas.kudla, markus.esch, daniel.ota}@fkie.fraunhofer.de
† Federal
Office of Bundeswehr Equipment, Information Technology and In-Service Support Koblenz, Germany Email:
[email protected]
Abstract—Development of military software is mainly done by large companies specialized on the military domain. For security reasons high barriers for market entry exist, which excludes small companies and independent developers. This leads to monopolization inducing long development cycles as well as labored and cost-intensive development processes. The idea of a military app store as a distribution platform for military software could be one way to overcome these issues. Enabling independent developers and small companies to develop software for such an app store fosters agile and fast software development targeted to the users demands. However for security reasons this is not possible today. This paper presents a concept for a development process that enables independent developers to write software for the military domain. Our concept lowers the barrier for market entry significantly while keeping the high security standards. Opening the development process in such a way is an important prerequisite for the realization of military app stores.
I.
I NTRODUCTION
This paper addresses software development for classified environments. Developing software for classified environments involves several hurdles. Companies and developers need to participate in a security clearance process. Moreover an environment for design and development, which is equally classified as the target environment, is required [1]. Finally the software needs to be audited by some authorized institution, in a tedious and costly process. All this adds up to high barriers for market entry, which excludes small companies and especially independent developers from implementing software for classified environments. Consequently the market is dominated by large companies with the immanent risk of monopolization and involves long and inflexible development cycles. For this reason software for classified environments is often not stateof-the-art in terms of technology [2], functionality, quality as well as user experience. Thus the user acceptance is typically low. Enabling independent developers to provide software for classified environments and creating a free market for such software can help to overcome this problem. Since independent developers compete for the best solutions, applications will be
developed much faster and more focused to the current demand of the end users. By this means the flexibility and creativity of independent developers is utilized also in classified environments. Providing an app store as software distribution platform could be one way to facilitate such an approach. The Apple App Store and the Google Play Store are good examples, how the creative potential of independent developers can be utilized to create innovative solutions in a short period of time by opening a platform for developers. In 2007 Apple released IOS and opened the platform for individual developers. Moreover an app store has been provided as software distribution platform. One year later Google released the Android operating system and allowed developers to do the same for this platform. Right now there are about 2.3 million individuals working as mobile application developers worldwide [3]. Those create an enormous amount of innovative applications for every aspect of daily life. Today there are more than 1.2 million applications just on the Apple App Store. Additionally the competitive situation leads to a continuous improvement and optimization of the applications. This process is driven by the integration of an easily usable payment system that ensures the compensation of the developers. Given the amount of military budgets, the provision of an app store for the military domain, where developers can offer their applications for sale, could yield similar effects as on the public market. Some nations are already taking first steps into this direction. The United States Department of Defense (DoD) spent 2.9 million dollars to build an app store [4] and the smartphone Galaxy S4 got a DoD clearance to be used within the US military [5]. In the Netherlands a system based on off-the-shelf smartphones and tablets called PROMISE [6] is used to test operational activities. Also Germany pursues the idea of a military app store [7]. On European level, the EDA [8] identified that the setup and hosting of a military app store for software leads to cost savings of 10% to 25% in the procurement of vehicle mission systems. The TactialNAV App [9] developed by a member of the US army shows that individuals can have the required know-how to developed apps
that are used in theater. Although mobile applications are a prominent type of software, where the app store approach has shown to work, the general approach is not limited to this area. Desktop and server applications can also be developed by small companies as well as individuals. The main issue for the realization of such an approach is the aforementioned barrier to develop software for classified environments. There are good reasons for such barriers, especially security related ones. One needs to make sure that untrustworthy individuals do not get access to any security critical information. For this reason, it is not trivial to provide individuals the opportunity to develop software for classified environments. However this is a prerequisite to successfully realize military app stores. This paper presents the concept of an open process for software development in classified environments which supports the idea of a military app store. The approach builds on the interface-based software development paradigm [10][11][12][13] and gives independent developers the opportunity to implement applications for classified environments without the need of disclosing confidential information to them. Additionally we propose the creation of a so-called community open environment where developers are able to share source code within a community. This facilitates a common development process similar to open source development and finally enables open source business models in classified environments. Such a community open environment also adds to the realization of the military app store idea. The remainder of this paper is organized as follows: We first give a thorough problem statement in section II and afterwards present our concept in section III. Section IV provides an outlook on how this concept could be realized and what is need for this purpose. The paper concludes with a discussion of the main contributions, open issues and future work in section V. II.
M OTIVATION
Currently we observe a huge shift of application development from monolithic applications to small specialized applications running on embedded devices like smartphones, tablets and even smartwatches. A similar trend can be noticed for server applications with the emergence of so-called microservices [14]. Many applications are no longer developed by large companies but by small teams [15] or even individuals [9]. This is enabled by the availability of appropriate libraries and services which reduces the development and maintenance effort significantly. Decentralized development can further be facilitated by the provision of an app store as distribution channel for software. This enables every developer to reach a large audience without the need of a sales organization. Realizing this approach for a given environment necessitates two things: •
Offering developer libraries that allow the integration of applications into the given environment.
•
Availability of additional libraries and services that implements common functionalities.
Both prerequisites can currently not be provided by classified environments due to organization specific security guide-
lines, which induce limitations in terms of information accessibility. For this reason developer libraries can not be provided publicly to any developer, not even as binary since reverse engineering is possible. For example the implementation of encryption algorithms or data transmission mechanisms needs to be concealed. To ensure this, owners of classified environments protect themselves by applying elaborated security screenings before developers get access to the needed libraries. Moreover classified development environments are typically required to implement and test the software. This constitutes a huge barrier for small companies as well as independent developers and finally excludes them from developing software for classified environments. To reconcile the requirements of developers and classified environment owners, we propose a concepts where developers are able to implement software for such environments without the need of security screenings and classified development environments. At the same time the high security standards are maintained. This is achieved by applying the interface-based software development pattern. Details are presented in section III. Our concept can be used to realize a military app store as software distribution platform where any developer can provide applications that are fit for a particular purpose to military customers. This fosters fast and agile development according to the particular demands of a given military community of interest. The second aspect that distinguishes classified environments from open environments is the availability of specialized libraries and services. As mentioned above, in the public domain open source libraries exist for most common use cases, which makes software development faster and more economic [16]. Similar libraries for domain specific use cases do not exist in the military domain or for classified environments in general. The reasons are security aspects, intellectual property rights as well as limited public interest due to a high degree of specialization. Companies developing for the military domain have no interest in making their libraries available since their business model relies on selling complete solutions. In opposite to that in the public domain open sources business models have been established, selling development and support service [17]. To facilitate similar business models in the military domain our concept contains the idea of community open environments, where registered developers are able to share libraries. By this means the second prerequisite we mentioned above can be fulfilled. Military organizations like NATO could foster the provision of libraries within such a developer community in order to benefit from the creative potential of the community. Another advantage for military organizations is the prevention of vendor lock-ins. Relying on community open solutions simplifies the exchange of providers and improves the maintainability of the software base. III.
C ONCEPT
Our concept builds on the interface-based software development methodology [10][11][12][13]. This methodology separates software into interface definitions and implementations of the interface. By means of interfaces it is defined how software components interact, which functionality they provide and which application programming interfaces (APIs) are exposed to external entities. Since interface and implementation are separated, it is possible to have several implementations for
the same functionality. Software developed this way is easier to maintain and to extend [18]. In order to integrate a software into a classified environment it is necessary to implement the software against libraries and implementations used in this environment. Many of them are security relevant and hence cannot be published, not even as binaries. In this scenario interface-based programming can be used to have multiple implementations of security related functionalities such as encryption-, authentication- or authorization-algorithms. At least two different implementations for security relevant APIs are required. One implementation is classified and will not be open to the public. The second implementation is non-classified and will be made available publicly or within a developer community along with the API. Application developers can develop and test their software against the non-classified implementation. For this reason developers do not need to work in a classified environment and a laborious security screening for independent developers is not needed. The owner of a classified environment can later on adopt the software to a classified environment. For this purpose the non-classified implementations are exchanged by the actual classified implementations during the build process. For our concept to work effectively a community open source software approach is recommended. This means, that source code is shared within a certain developer community. This entails the advantage that implementations can be reused and improved by others, which increases the efficiency of the development process and avoids vendor lock-ins. Such an approach for classified environments is enabled by our concept since security related implementations can stay hidden from the public. Our concept based on interface-based programming and a community open source approach is presented in section III-A. We describe the proposed open software development process and its stakeholders. Afterwards in section III-B we introduce several development environments with different classification and address concerns regarding security policies. A. Development Process The software development process we propose involves different stakeholders and several development environments. For each environment it is defined which stakeholders have access and for each step in the development process it is determined in which environment it has to take place. By this means a clear separation of concerns and access rights is achieved. The roles of the stakeholders are described in the following: 1)
Developer An entity with the competence to develop software is a developer. In the context of our scenario, a developer has no access to the software components in the classified environment. This includes independent individuals as well as companies with the same restrictions. Both either work on contract to implement software for the classified environment or develop some software of their own accord to provide it to the owner of the classified environment. In both cases the software needs to be integrated into the existing software ecosystem of the classified
2)
environment consisting of applications, libraries and services. The challenge is to enable this without access to the classified environment. Owner In our context we denote an organization with certain security requirements that runs a classified environment as owner. The goal of the owner is to enable developers to write software for the classified environment without the need of providing access to the environment.
We define four different development environments. Those are depicted in Figure 1 and will be described in detail in section III-B. The environments are briefly introduced in the following: 1) 2)
3)
4)
Open Environment The open environment is the public space. Closed Environment A closed environment is the application development environment owned and controlled by a given developer. Classified environment A classified environment is owned by organizations with certain confidentiality obligations and is only accessible by authorized persons. Community Open Environment Owners of classified environments can manage a community open environment. Registered developers providing applications for the given closed environment can access the community open environment to share source code and libraries.
Some software components in the classified environment are security relevant and hence cannot be released to the community open environment. The owner of the classified environment has to provide an API for these software components along with a non-classified implementation to the community open environment. Developers can implement new software using the API and test the software based on the nonclassified implementation. By this means an integration into existing software of the classified environment is possible. To realize this approach, the following items need to exist for a classified software component: 1)
2)
3)
An API for a software component. This API was audited and signed[19] such that it complies with the security policies and describes the desired functionality for the component. This API is available in the classified and the community open environment. For example a Signed Streaming API that describes the interface and the functionality of a streaming software. A non-classified implementation of the API providing the desired functionality in such a way that it does not have to be classified. This implementation is available in the community open environment. For example a Non-Classified Streaming Library that implements the Signed Streaming API. An classified implementation of the API which has been audited in order to make sure that it complies to the security policies. This implementation is only available in the classified environment and will never
Classified Enviroment Closed Environment
Community Open Enviroment
App Adoption Process
Community Open Application Source Code Repository
Closed Application Source Code Repository
fetch
Application X Source Code
D eveloper Area
Classified Application Source Code Repository Application X Source Code
saves
Application Code
«Uses» Signed Streaming API
Application X Source Code
«device» O n e-way S ecurity G atew ay
«Uses» Signed Streaming API
p rovides
«Uses» Signed Streaming API
P arser API
«Uses» Non-Classified S treaming Library
«Uses» Non-Classified Streaming Library
Application Code
«Uses» Non-Classified Streaming Library
P arser Library
Application W Source Code
Application K Source Code
Application Code u ses P arser API
Classified Library Repository
Community Open Library Repository
u ses P arser Library
Signed APIs
Signed APIs u ses
u ses
Signed Streaming API
Signed Streaming API
Signed Messaging API
Signed Messaging API
Signed Other API
Open Enviroment
Signed Other API u ses
N o n -Classified Libraries
Open Library Repository Im plem ents
C lassified Libraries im p lements
Non-Classified Streaming Library
C lassified Streaming Library
Public APIs Logging API P arser API
u ses
im p lements
C lassified Messaging Library
Non-Classified Messaging Library
C lassified Other Library
Non-Classified Others Library
Other API u ses P u b lic Libraries Im p lements
u ses Logging Library
«device» C lassified Build System
«device» Community Open Build S ystem
P arser Library O ther Library
Code Analyzer
Code Analyzer
Application Builder
Application Builder
saves
Commnuity Open Application Repository
Application Code
Dummy Streaming Library
Application K
Classified Application Repository A pplication X (Classified)
Application X Signed Streaming API
saves
Signed Streaming API
Application Code
C lassified Streaming Library
Application W
Application K (Classified)
Fig. 1: Environment and Process Overview: The figure shows the development process for some example application X. Development starts in the closed environment of a developer and uses libraries from the open and the community open environment. After adding the application to the Community Open Application Repository it can be transferred to the Classified Application Repository using the Application Adoption Process.
be disclosed during the entire development process. For example a Classified Streaming Library that implements the actual classified streaming algorithm. The APIs need to be signed in order to ensure that no modifications can be made after release. By this means it is ensured that the application build process in the community
open environment behaves the same way as in the classified environment. This is important for the developer in order to be certain that an application implemented and tested in the community open source environment also builds in the classified environment.
The open development process we propose is depicted in Figure 1. The figure shows how an example application X is first developed in the closed environment, then build in the community open environment and finally adopted to the classified environment. The development process starts with the developer implementing a new software. This is either initiated by a commission of the owner or through the developers own initiative. At first the developer works primarily in its closed environment. Within that environment the developer has access to all publicly available resources. Given that a resource is subject to a license which is appropriate for the intended use, it can be used for the software development. This enables the developer to rely on already existing software components. For this purpose an API and its implementation can be copied from the open environment to the closed environment. In case the source code of the resource is available, the developer can also make necessary changes. Additionally libraries published within community open environment can be used. For this purpose the developer needs to register for this environment. The access is granted by the owner. Once the developer has access to the community open environment any source code released in this environment can be used. Additionally the APIs and non-classified implementations provided by the owner are available. Those resources can be copied to the closed environment for development and testing purposes. In case changes, improvements or bug fixes have been applied to the source code retrieved from the community open environment, those should be synchronized back in order to improve the code base of the community. To release a finished software to the classified environment, the source code first needs to be copied to the source code repository of the community open environment.
checks. The crucial step in the build process is the exchange of the non-classified libraries by the classified implementations. Due to the separation of functionality and implementation, guaranteed by the interface-based programming paradigm, the build system is able to do this exchange. Finally, the classified application will be release to the classified application repository. If an implementation of a signed API has been adopted to the classified environment it only needs to be reviewed again if it is changed. If applications use existing libraries to a large extent, the review process is accelerated since just newly implemented parts need to be audited. Another benefit is that along with more applications being reviewed, more and more libraries used by those applications are transfered from the community open source environment to the classified environment. By this means the amount of reviewed libraries successively increases. Hence the efficiency of the review and audit process is continuously improved. B. Environments Our concept involves different development environments that are used by different stakeholders during the software development process. Each environment has a specific purpose and distinguishes who is allowed to access that environment. An overview of the environments and there coherence is provided in Figure 1 and will be described in more detail in the following.
Open Enviroment Open Library Repository
In the community open environment either the developer or the owner can trigger the community open build system. The build system uses the signed APIs and the non-classified libraries from the library repository and builds the application. By taking the signed API and the non-classified libraries from the repository it is ensured that no modifications have been made. During the build process static or dynamic code analysis can additionally be applied to ensure a certain level of software quality. Once the build process is finished the application is release to the community open application repository. The infrastructure in the community open environment needs to be similar to the classified environment in order to make sure that the same source code builds in both environments. The final step of the process is to release the desired application to the classified environment. Therefore the owner triggers a one-way security gateway to fetch the applications source code from the community open source code repository. By this means the source code is copied to the classified source code repository. The one-way security gateway is the only way to bring data into the classified environment and to start the Application Adoption Process, which transfers some software to the application repository of the classified environment. Once the source code is in the classified source code repository the owner is able to review the source code and to make sure that it is in compliance with the security policies. Afterwards the build process in the classified environment can be triggered. The build process in the classified environment can be extended by introducing more security and compliance
Public APIs Logging API P a rser API Other API
P ublic Libraries Implements Logging Library P arser Library Other Library
Fig. 2: Open Environment: The figure shows an open library repository with some example APIs and corresponding libraries that implement those APIs.
1)
Open Environment The open environment as illustrated in Figure 2 is the public space. Everybody can access all publicly available resources as libraries and source code. No access restrictions apply. In the context of our scenario it is recommended to use only source code that is subject to licenses that do not restrict the later use within a closed environment as for example the MIT license [20][21]. In order to conform to our concept,
interface-based programming should be applied also in the open environment. Software available in this environment is often hosted in software repositories that can be accessed by build systems. Stakeholder of this environment is the open source community that continuously provides new implementations. Additionally stakeholders from the closed and community open environment may retrieve open source software from this environment.
Community Open Enviroment Community Open Application Source Code Repository
Application X Source Code
fetch
«device» O n e-way S ecurity G atew ay
Application Code
«Uses» Signed Streaming API
P arser API
«Uses» Non-Classified S treaming Library
P arser Library
Application W Source Code
Closed Environment
u ses
Closed Application Source Code Repository
Community Open Library Repository
Developer Area
Signed APIs Application X Source Code
Signed Streaming API
«Uses» Signed Streaming API
Signed Messaging API Signed Other API
«Uses» Non-Classified Streaming Library
Application Code
P a rser API
P arser Library
N o n -Classified Libraries Im plem ents
u ses
Non-Classified Streaming Library
Non-Classified Messaging Library
Non-Classified Others Library
u ses
Fig. 3: Closed Environment: The figure shows the components of some example application that has been developed within the closed environment. The application exists of signed APIs and libraries from the community open source environment, the actual application code as well as some other libraries used by the application.
«device» Community Open Build S ystem Code Analyzer
Application Builder
saves
2)
3)
Closed Environment A closed environment as depicted in Figure 3 is an environment, where independent developers and companies develop applications. The owner of such a closed environment is the only stakeholder that has access to the sources within the environment. In case they are registered for the community open environment, they can transfer signed APIs from this environment into their closed environment in order to build applications. Community Open Environment The community open environment as shown in Figure 4 is an environment, where registered developers share source code within a certain community. The community is defined by a common customer. In our case the owner of a classified environment, e.g. a military organization. The owner of the classified environment controls the access to the community by setting up a registration process and enforces sharing of source code within the community. For this purpose the development of required libraries and applications is commissioned on condition that the
Commnuity Open Application Repository Application X Signed Streaming API
Application Code
Dummy Streaming L ibrary
Application K
Application W
Fig. 4: Community Open Environment: The figure depicts the components of the community open environment and how applications are build and added to the Community Open Application Repository using the Community Open Build System.
sources are shared within the community. Unless this is prohibited by security concerns. Resources from a community open environment can only be used to develop applications for the respective customer of the environment.
Security relevant libraries are provided by the owner of the classified environment. Instead of providing source code or binaries of these libraries, just APIs along with non-classified implementations are made available. These libraries are needed to integrate applications into the existing software of the classified environment. To enable the adoption of source code into the classified environment, licenses which do not prohibit use in closed source software need to be applied [21]. 4)
Classified Environment The classified environment is depicted in Figure 5. The owner of such an environment is an organization with confidentiality obligations as for example armed forces. For this reason only authorized stakeholders are able to access the software and its implementations within this environment. All software within the classified environment must be available in source code to enable code audits. This needs to be done in order to ensure that the software is secure and does not leak any information. Furthermore the software must be build using the build system of that environment. This ensures that the final application is build from the audited source code and no modifications have been made after the audit. Consequently building an application for the classified environment requires full control over the source code, the build tools and the build system.
Classified Enviroment App Adoption Process
«device» O n e-way S ecurity G atew ay
Classified Application Source Code Repository Application X Source Code
saves
«Uses» Signed Streaming API
Application Code
«Uses» Non-Classified Streaming L ibrary
Application K Source Code
Classified Library Repository Signed APIs Signed Streaming API Signed Messaging API Signed Other API u ses
im p lements C lassified Libraries im p lements C lassified Streaming Library C lassified Messaging Library C lassified Other Library
u ses
IV.
O UTLOOK
The implementation of the concepts described in the previous section requires several courses of action by military organizations like NATO or national procurement offices. The respective organizations need to manage and govern the provided community open environment, the provided APIs as well as the adoption of code into the classified environment. To ensure a development in line with the strategy of the organization, the military software ecosystem has to be governed centrally by the corresponding military authority. Consequently the military organization has a greater level of responsibility for the software development process than traditionally with the procurement of end-to-end solutions. This involves especially the following duties: •
Definition of a strategy for the library and service portfolio in line with operational demands.
•
Alignment of the library development to the strategy. This includes determination of gaps and demands as well as the commission of corresponding implementations.
•
Provision, maintenance and enhancement of APIs that allow the integration of applications into the military software environment.
•
Maintenance of the library portfolio, i.e commission of advancements, bug fixes and updates.
•
Controlling the adoption of code into the classified environments, including establishment of a code review process.
«device» C lassified Build System Code Analyzer
Application Builder
saves
Classified Application Repository A p p lication X (Classified) Signed Streaming API
Application Code
C lassified Streaming Library
A p plication K (Classified)
Fig. 5: Classified Environment: The figure shows a classified environment along with its components. An Application Adoption Process is used to transfer applications into the classified application repository in a safe manner. New source code enters the classified environment though a One-way Security Gateway only. The Classified Build System exchanges nonclassified API implementations by the corresponding classified implementations from the Classified Library Repository.
•
Administration of registered developers.
With our concept in place development management is more challenging for the public authority. Instead of procuring complete end-to-end solutions, single functionalities are commissioned. This requires a deep knowledge and understanding of the technical details and coherences. While this poses huge organizational challenges, it opens up excellent opportunities. Especially since the developer base is enlarged significantly. This fosters innovative solutions targeted to specific demands and avoids monopolization by few large companies. Additionally implementations provided in the community open environment can be reused, which increases the efficiency. Our concept can finally be adopted for the realization of a military app store. For this purpose a military organization needs to run a distribution platform for military applications. Contributing an application to the app store is done according to the process outlined above. Especially the establishment of a review process that ensures the quality of the software (functional correctness) provided to the app store is a challenging task for the owner of the app store. It needs to be ensured that the applications correspond to a given quality standard. Additionally software quality is ensured by rating mechanisms of the app store. Poor applications get quickly rated as inappropriate by the users, which prevents other users from using the software. However a certain minimum standard needs to be enforced by the app store owner in order to prevent harm. Moreover it needs to be ensured that the functionality provided by the applications is in line with the overall strategy and corresponds to certain rules. For example games are certainly not welcome in a military app store. Setting up an effective review process requires an appropriate test environment and corresponding human resources. Figure 6 shows the process for releasing applications to the military app store. Applications are developed and tested within the community open environment by the developer. Once the developer has a stable version of a new application that should be released to the app store, the application is submitted to the App Review Process. This review process takes place within the community open environment. It checks the functionality of the application and makes sure that the application is in line with the military organization’s strategy as well as the app store guidelines. The guidelines define, which kind of applications are allowed to be provided in the app store. In case the application passes this review, it is submitted to the classified environment. Here the application adoption process as described in Section III-A is triggered to adopt the application in the classified environment. Here the application souce code is audited, now focusing on data integrity and confidentiality. In the course of this process a classified version of the application is build and submitted to the app store. Authorized military users can access the app store and retrieve applications for mobile devices as well as for desktop computers and servers. Depending on the number of downloads the developer is automatically payed. In general our concept fosters open source business models in the military domain. Traditionally companies in the military domain rely on selling closed-source end-to-end products. This involves drawbacks for the military organizations that procure these products, since there is a risk of monopolization and
Community Open Environment
Classified Environment
App Review Process
Application Adoption P rocess
Devices Mobile Devices
Desktop Computers
Application for App Store
S ervers App Store
Revenue
App Store Repository
Download
Developer Military User
Fig. 6: Military App Store Process: The figure shows how applications can be offered in a military app store to military customers based on our open process for software development in classified environments.
vendor lock-ins. In the public domain this can be avoided by opting for vendors with an open source business model. These companies earn money by providing development, maintenance and support services, not by selling finished products. Companies with such a business model rarely exist in the military domain, since independent development is not possible today. In a first step several projects have been completed following a similar business model and providing their source code as open source. However the lack of a formal process prevented the forming of an open development community so far. With our concept and the provision of an community open source environment the formation of an open source business model in the military domain can be supported, which finally bears the aforementioned advantages for military organizations. V.
C ONCLUSION
Today the idea of a military app store is widespread and popular. The realization is however prevented mainly by security concerns. High barriers for the contribution of software into a military environment exist. However an effective app store as distribution platform for software requires a large developer base. Especially independent developers and small companies contribute a lot to a prosperous app store as they contribute a high degree of flexibility and innovation. Consequently the developer base is able to react quickly to new demands. Moreover the software quality is continuously improved in order to be ahead of the competitors. The concept proposed by this paper can be adopted in order to realize a military app store. It tackles the immanent problem in classified domains that access to security relevant implementations needs to be restricted, which excludes many developers. The main idea is to provide an API along with nonrestricted implementations as well as a community open development environment. Using the interface-based programming paradigm, developers are able to implement software without knowledge of security relevant libraries and implementations. In the course of the adoption of software into the classified environment, libraries can be exchanged by the classified
implementations. By this means the barrier for market entry is lowered significantly and makes software development for the military domain attractive for independent developers. An app store combines two advantages for its owner. On the one hand a large developer base that provides software for its environment can be addressed. On the other hand the owner has full control since the app store is the only way of deploying software. By the establishment of a review process, software content and quality can be controlled. Additionally the concept of a community open environment, where libraries can be shared fosters a rapid and cost-efficient application development process. A community open environment supports the reuse of software components developed for the military domain, improving the efficiency of software development. Moreover the dependence on certain companies and providers is reduced. In our future work we aim to extent this approach to classified data and process models. In addition to the public release of non-classified libraries the approach needs to separate also in the field of data and process models. Data models as well as process models can leak internal information needs as well as procedures and hence may result in an operation security breach. Therefore, the encapsulation of data and process models as configurable elements along with the libraries needs to be investigated as well. Non-classified sample configurations for data and process models could be included to the non-classified libraries while the operational models remain part of the classified environment. R EFERENCES [1] [2]
[3]
[4]
[5]
[6]
[7] [8]
NATO, “Security within the north atlantic treaty organisation (nato),” Document C-M(2002)49, 6 2002. W. J. Lynn, III, “Defending a new domain the pentagon’s cyberstrategy.” [Online]. Available: http://www.defense.gov/home/features/2010/0410 cybersec/lynn-article1.aspx A. Sethuraman, “Mobile app development trends worldwide: What you need to know,” 6 2014. [Online]. Available: http://blog.newrelic.com/ 2014/06/13/mobile-app-development-trends-worldwide-need-know/ American Forces Press Service, “DOD awards contract for device management system, app store,” 6 2013. [Online]. Available: http://www.defense.gov/news/newsarticle.aspx?id=120388 Samsung, “Samsung knox approved by department of defense for use in us government,” 6 2013. [Online]. Available: http://www.samsung.com/sg/business/insights/news/samsungknox-approved-by-department-of-defense-for-use-in-us-government Ministerie van Defensie, “Promise belooft innovatie in operatiegebied,” Online, 1 2014. [Online]. Available: http://www.defensie.nl/actueel/ nieuws/2014/01/31/promise-belooft-innovatie-in-operatiegebied G. Schwarz, “Appstores: Potenzial auch f¨ur die Bundeswehr,” Europ¨aische Sicherheit & Technik, pp. 68–71, May 2014. EDA, “Land vehicle with open system architecture,” 12.R&T.OP.336, March 2014.
[9] [Online]. Available: http://tacticalnav.com/ [10] J. A. Rowson and A. Sangiovanni-Vincentelli, “Interface-based design,” in Proceedings of the 34th Annual Design Automation Conference, ser. DAC ’97. New York, NY, USA: ACM, 1997, pp. 178–183. [Online]. Available: http://doi.acm.org/10.1145/266021.266060 [11] R. Niekamp, “Software component architecture.” [Online]. Available: http://congress.cimne.upc.es/cfsi/frontal/doc/ppt/11.pdf [12] A. Sangiovanni-Vincentelli, P. McGeer, and A. Saldanha, “Verification of electronic systems,” in Design Automation Conference Proceedings 1996, 33rd, Jun 1996, pp. 106–111. [13] “Software engineering,” Conference Report, 1 1968. [Online]. Available: http://homepages.cs.ncl.ac.uk/brian.randell/NATO/nato1968. PDF [14] J. Lewis and M. Fowler, “Microservices,” 3 2014. [Online]. Available: http://martinfowler.com/articles/microservices.html [15] T. Hoff, “The whatsapp architecture facebook bought for $19 billion,” Online, 2 2014. [Online]. Available: http://highscalability.com/blog/2014/2/26/the-whatsapparchitecture-facebook-bought-for-19-billion.html [16] W. Scacchi, “When is free/open source software development faster, better, and cheaper than software engineering?” in BETTER, AND CHEAPER THAN SOFTWARE ENGINEERING? WORKING PAPER, INSTITUTE FOR SOFTWARE RESEARCH, 2003. [17] F. Hecker, “Setting up shop: The business of open-source software,” Software, IEEE, vol. 16, no. 1, pp. 45–51, Jan 1999. [18] E. Gamma, R. Helm, R. Johnson, and J. Vlissides, Design Patterns, Elements of Reusable Object-Oriented Software. Addison Wesley, 1995. [19] A. J. Menezes, S. A. Vanstone, and P. C. V. Oorschot, Handbook of Applied Cryptography, 1st ed. Boca Raton, FL, USA: CRC Press, Inc., 1996. [20] J. Brun, F. Kobelt, R. Aeberhardt, and M. St¨urmer, “Open source software in business-critical environments,” Online, Ernst & Young, 2011. [Online]. Available: http: //www.opensource.ch/fileadmin/user upload/opensource.ch/knowhow/ 2011 OpenSourceSoftwareInBusiness-criticalEnvironments.pdf [21] Massachusetts Institute of Technology. (1988) MIT-license. [Online]. Available: http://opensource.org/licenses/mit\newline
