Olusegun Ajigini

The 9th International Conference for Internet Technology and Secured Transactions (ICITST-2014) Towards a Model on Security Challenges during Closed Source Software to OSS Migrations Olusegun Ademolu Ajigini John A. van der Poll School of Computing, University of South Africa (UNISA), Florida, South Africa- Professor, Graduate School of Business Leadership, University of South Africa (UNISA), Midrand, South Africa- Jan H. Kroeze Professor, School of Computing, University of South Africa (UNISA), Florida, South Africa-Abstract—Open source software (OSS) allows users and developers to, amongst others, study, modify and redistribute the source code. At the other end of the spectrum, closed source software (CSS – the antonym of OSS) disallows users and developers to access and modify any source code. This paper presents an overview of security challenges during closed source systems (CSS) to open source systems (OSS) migrations and proposes a Model to address such challenges. A comparison of OSS security and CSS security aspects, and an overview of security challenges during migrations to OSS are presented. On the strength of these comparisons, and using summative content analysis, a model to address security challenges during migrations to OSS is proposed. The model is developed through enhancements of previous models aimed at addressing security threats and protecting sensitive information during system migrations. Keywords- Open source software, Closed source software, Information security, Summative content analysis, Information protection, sensitive information, security model. I. INTRODUCTION The perpetual rise of Open Source Software (OSS) has been a feature of the software industry during the past ten years [18]. Subsequently, there has been an increasing interest in the open source movement as a new paradigm for software development in recent years [25]. One such example is the South African Government who has been in the vanguard of using OSS since 2001 by adopting policy recommendations in 2003 [21]. The gradual proliferation of articles and reports in the mainstream media spearheaded evidence for an increased awareness of, and interest in open source [29]. This is also the view of [14] that there are many publications on OSS advantages and disadvantages. It is estimated that at least 80% of all commercial software solutions would have had substantive open source components by 2012 [9]. -/1/$25.00©2014 IEEE Open Rubric A recent study conducted by the International Data Corporation (IDC) indicates that the OSS market will grow at an annual rate of 22.4% and would reach US$8.1 billion in 2013 [16]. However, it has been pointed out by [11] that low acceptance rates of OSS continue to reduce its share of the market. In later work, it is emphasised that OSS benefits would not be fully realised until it is accepted and used by the mainstream software users [11]. The issue of the security of OSS was highlighted by two events, namely, a report released by Fortify Software in July 2008 [23], claiming that necessary standards were not achieved by OSS developers, and that Linux kernel developers had covered up security vulnerabilities [20]. It was recommended in this report that OSS should be viewed warily due to alleged high risks involved by government and commercial organisations. The report further recommended the conducting of risk analyses and code reviews on any OSS code running in business-critical applications. According to [20], the US Department of Homeland Security as part of the US Government’s Open Source Hardening Project, backed Coverity Software to investigate security issues affecting OSS products [22], and they came up with a report that disagreed with the Fortify findings. Coverity Software analyzed 55 million lines of code across 250 (amongst other Linux and Apache) projects and concluded that OSS quality and security are improving. OSS should be evaluated from a security perspective to ascertain the level of security robustness or potential exposure to threats [2]. They also stressed that the increasing use of OSS may pose several security challenges to organisations. In this paper we propose a model to address a number of security challenges during the migration from CSS to OSS. Our model is constructed from the Aner and Cid framework proposed in [2] and part of the rudimentary framework to 274 The 9th International Conference for Internet Technology and Secured Transactions (ICITST-2014) protect sensitive information during system migrations, suggested in [1]. The layout of the paper follows: In the early sections, we consider some definitions of closed source software (CSS) and open source software (OSS). This is followed by a comparison of the possible benefits of OSS over CSS. In a similar vein, the second to the last section considers and compares security aspects in both CSS and OSS. The last section presents an overview of some security challenges in migrating from a closed source to an open source environment, followed by our model aimed at addressing some of these challenges. The paper concludes with references to future work in this area. II. WHAT IS OPEN SOURCE SOFTWARE (OSS) Open source is described as software of which the source code is distributed along with the executable program [13]. Such software is free to use and it includes a license allowing users and developers to modify and redistribute the software. OSS refers to any software that is distributed under OSS licensing formats ([12]; [30]). Open source code is accessible to the users and such code may be enhanced for added functionality [30]. Possible errors in the code can be corrected and overall improvements to the source code can be done. Open source is a term of art which is the opposite of closed source in the sense of having its source code freely available for anyone to make enhancements or correct errors [24]. A comprehensive definition of open source software is defined by the Open Source Definition (OSD) and they list eight requirements of OSS as: (a) Free Redistribution, (b) Source Code availability, (c) Derived Works, (d) Integrity of the author’s source code, (e) No Discrimination against Persons or Groups, (f) No Discrimination Against Fields of Endeavor, (g) License Must Not Restrict Other Software, (h) License must be Technology-Neutral. There are many classifications of open source and closed source in the literature e.g. ([12]; [13]; [30]). In this paper, we define open source software as software of which the source code is distributed along with the executable program, having the right of redistribution, open standards, free to use, but could be paid for (e.g. paying for the medium on which such software is distributed) as illustrated in Table 1. In Table 1, our definition for open source covers both Quadrants A and C. Examples of open source and closed source programs are listed in each of the four quadrants. For example, Ubuntu Linux is a free, open source program in Quadrant A, while MS Office is closed source software that is paid for and resides in Quadrant D. -/1/$25.00©2014 IEEE TABLE I. CLASSIFICATION OF OPEN AND CLOSED SOURCE SOFTWARE Open source software Closed source software Free Quadrant A e.g. Ubuntu Linux, Apache Quadrant B e.g. Internet Explorer, Adobe Acrobat Reader Paid For Quadrant C e.g. Red Hat, MySQL Quadrant D e.g. MS Office, MS Windows operating systems III. WHAT IS CLOSED SOURCE SOFTWARE (CSS) Closed source software (CSS) is a term invented as an antonym for OSS and is used to refer to any program whose licensing terms do not qualify as OSS. This implies that a user will have the binary version of the software they are licensed to without any copy of the program’s source code. A user of closed source software cannot render modifications to the software. CSS is based on the assumption that software development is a highly specialised process that is managed by a team of specialised developers and best practices project management, all of which result in new releases and enhancements from time to time [25]. In this paper, we define closed source software (CSS) as software that users cannot render modifications to and can be free or paid for as illustrated in Table 1. An example of closed source software that is free as shown in Table 1 is the Internet Explorer which can (e.g.) be downloaded from the Internet. IV. BENIFITS OF OSS VS. CSS – A COMPARISON Table II is a comparison of the benefits of OSS and Closed Source Software by different authors. This Table reveals that there are more profound benefits of OSS than for closed source software. TABLE II. Benefit / Characteristic Reliability COMPARING THE BENEFITS OF OSS AND CSS Open Source Software (OSS) OSS has increased reliability over closed source software. The reason is that OSS is usually critically examined by many independent and enthusiastic developers during all its developmental Closed Source Software (CSS) The reliability of some closed source software is lower than that of OSS. The reason is that CSS is produced by a smaller number of developers who work against tight deadlines under much pressure. Author [24] [7] [8] 275 The 9th International Conference for Internet Technology and Secured Transactions (ICITST-2014) stages. Sense of Urgency Quality There is little sense of urgency in OSS projects; there are little or no strict deadlines, and no hierarchical team structure in OSS developments. Due to stringent deadlines to be met, there is a sense of urgency of CSS projects. There is a hierarchical team structure in closed source projects – the corporate world. [17] The quality of OSS is perceived to be higher than that of CSS. This is because many developers examine the software, facilitating the detection of errors. CSS is perceived to have a lower quality than OSS. Developers outside the closed group cannot detect errors because the source code is generally not publicly available. [7] The quality of OSS products should be higher than for CSS if there is competition between them in the market Innovation & Flexibility Quality of CSS could be higher than quality of OSS if there is no competition in the market. [19] Software Requirements [8] [25] Vendor-Lock Ins Generally there are no formal inspections in the quality of OSS programs and no broad testing. There is little evidence to support rigorous measurements in OSS. There are formal inspections conducted in CSS projects as well as broad testing. Rigorous measurement is performed in CSS implementations. OSS has more flexibility than CSS – source code is publicly available. CSS has less flexibility than OSS due to its code being closed. By providing users with the freedom and Users are not allowed to see the source code -/1/$25.00©2014 IEEE [17] Cost [7] [8] flexibility, OSS enables innovation to modify the software without any restriction. and this restricts innovation. But it facilitates the security and reliability of the software. They have targeted innovation that is business focused rather than technology focused. [4] Requirements are mostly absent in OSS projects. There is little systematic effort in addressing Capability Maturity Models (CMMs). There is also little evidence of using the Unified Modeling Language (UML) or any form of systematic modeling in OSS. Requirements are used in CSS projects. The Capability Maturity Model (CMM) is well addressed in CSS projects. Closed source projects make use of UML or other modeling techniques. [17] There is no Vendor-Lock In associated with OSS. The user is independent of the vendor. CSS is dependent on the Vendor. Therefore, there is vendor-lock in. [7] OSS tends to be free; and have low acquisition cost, except for having to pay for the media on which the software may be distributed (e.g. on a CD). Most CSS are not free and have a higher acquisition cost than OSS. However, in some situations closed source Total Cost of Ownership (TCO) is lower than that of open source. [7] The total cost of ownership may roughly be the same as for TCO for closed source and open source software [8] [8] [30] [25] [4] 276 The 9th International Conference for Internet Technology and Secured Transactions (ICITST-2014) Adherence to Standards Usability / Ease of code errors identification and problem solving Operating Systems some closed source programs. could roughly be the same. The use of standards is limited to data formats like the Hypertext markup language (HTML), or the Extensible markup language (XML). Closed source projects normally adhere to most IT standards during implementation. Most OSS products offer code error reporting tools. These tools assist in the faster detection of errors and the rapid finding of solutions. Generally, it requires a much longer period to resolve errors in CSS, due to non-availability of code error reporting tools. OSS usually lacks usability because it is developercentric. Ability to correct errors is limited to users with technical expertise. Closed source programs do not lack usability. They employ expert usability testing techniques and usability is ranked quite higher than in OSS. OSS products are supported with operating systems that surpass the operating systems that support CSS due to the availability of source code which can be altered. Users can adapt the OSS to their operating systems. The cost of such a diversity of operating systems tends to be higher in closed source systems due to It is more expensive to change the operating system source code of a CSS. Development costs are generally high. Users usually have to wait for a next release of the software. -/1/$25.00©2014 IEEE their high development costs. [17] Documentation [30] Personalisation [4] [19] [30] Service and Product Support Most OSS projects are weak on documenttation. Most CSS projects produce manual and quality documentation. [17] OSS are not legally bound to produce documenttation such as manuals or guides. Closed source programs are legally required to supply documentation such as user manuals, guides etc. [4] This is the degree to which developers are able to write applications in the way they want the application to look and are used. OSS developers use personalisation a lot in their work in order to change the look and feel of a product, so that it can integrate seamlessly with their working environment. This enhances their efficiency and mood. CSS developers are generally not allowed to attach personalisation to their work. Company standards and policies have to be adhered to and CSS is designed to accommodate the generic software market. [30] OSS products come with many learning materials obtainable from the developer’s site or other locations supporting the OSS product. Large community of users and developers support OSS products by designing tutorials and short articles Closed source systems are supported by a support team and they usually make use of printed material or books which come at a cost. [30] 277 The 9th International Conference for Internet Technology and Secured Transactions (ICITST-2014) on how the product should be used. User groups are available and support is delivered via forums and blogs. Issues may, or may not be resolved soon. Plug-in functionality Highly specialised Applications Best-practices Project Management quality. Closed source programs have a high response service. Ongoing support is provided to the customer. Support to the users of CSS is arguably the greatest advantage of using CSS. Is readily available for OSS products. OSS developers and users can extend the functionality of their product by using Plugins to write their own modules which can be integrated with the OSS product. It is more difficult to write Plug-ins for Closed Source systems than OSS because documentation is not as rich as the OSS. The source code is also not readily available. OSS programs are less likely to be used to develop highly specialised applications. CSS can be used effectively to develop highly specialised applications. [30] Most closed source projects follow release management guidelines. [17] Discussion of Table II The reliability of some CSS may be lower than that of OSS owing to fewer programmers that develop closed source software, working against tight deadlines and under a fair amount of pressure ([24]; [7]; [8]). Closed source software is perceived to have a lower quality and lower flexibility than OSS due to the non-availability of the source code ([7]; [8]; 19]). However [25] and [17] argue that CSS is of a higher quality than OSS, provided that there is no competition in the market. Most CSS implementations make use of a modeling language like Unified Modeling Language (UML), as well as incorporating the Capability Maturity Model (CMM). In contrast, OSS implementations usually do not make use of any modeling techniques like UML; neither do they use the CMM [17]. [25] There is little evidence that formal specifications are used in OSS projects and this limits the use of OSS in safetycritical software. Formal specifications are used in closed source projects and this enhances their use in safetycritical software. [17] PM practices are usually lacking in most OSS projects and this could undermine the product’s Most closed source projects use bestpractices project management techniques, all of which [25] -/1/$25.00©2014 IEEE Release management guidelines are informal in OSS and there are often version proliferation and implementation issues. [4] enhance a product’s quality. The Total Cost of Ownership (TCO) of both OSS and closed source software are roughly the same [4]. Closed source programs do not lack usability, documentation or service/product support, whereas OSS programs usually lack usability and documentation ([4]; [17]). There is no vendor lock-in associated with OSS but closed source software is characterized by vendor lock-ins ([7]; 8]). According to [25], the comparisons of open source and closed source are not conclusive, or in a finer analysis are slightly in favour of open source. This is also the view of [19], namely, that OSS yield more benefits than CSS. More enthusiastic developers are involved in developing, testing and evaluating the code of OSS programs. V. COMPARING OSS AND CSS SECURITY The importance of analyzing a whole OSS system when performing an extensive security investigation has been emphasised by [13]. Such analyses include the application software, its source code, and the tools used for developing the object code. Examples are compilers, operating systems, hardware and the whole development environment. Different authors have different perceptions when they compared OSS security with that of CSS as shown in Table III. The table reveals that the security of OSS is roughly of the same quality as that of a CSS system. 278 The 9th International Conference for Internet Technology and Secured Transactions (ICITST-2014) TABLE III. Characteristic Publishing of Designs and Protocols Finding and correcting security vulnerability Checking and Testing of code Controlled Environment Development COMPARING OSS AND CSS SECURITY OSS security CSS security Author OSS designs and protocols are published and these contribute to the security of the systems. This may reveal logical errors in the security of the system. Closed source designs and protocols are not published. [14] It is easier to find and correct code errors in OSS than in CSS owing to the openness factor. Open and closed approaches to security are rather similar. Correcting errors in CSS is dependent on the programming team that developed the program – the source code is not publicly available. [5] OSS users have the freedom to validate and test the code of the OSS product that they want to use so as to ascertain its quality and security. Because users do not have the choice to validate and test the code in closed systems, the author stresses that OSS initial coding tends to be of a higher quality than CSS. [20] OSS is often viewed as having security issues because OSS is not necessarily developed in a controlled environment. CSS is perceived as being more secure because it is developed in a controlled environment by a concentrated team with a common direction. The source code may be viewed and edited only by this team. The [4] -/1/$25.00©2014 IEEE software is comprehensiv ely audited, eliminating the risk of back door Trojans and reducing the risk of code errors or other software issues. Closeness or openness of software code – security through obscurity It is maintained that OSS improves software transparency, security and trustworthiness because users and developers can validate an OSS program's functionality and security, due to the availability of its source code. The authors stress that the security of software is dependent on the user and not necessarily its closedness or openness. CSS can also be as secure as OSS. [13] They highlight that it is easier to correct bugs in OSS systems thereby enhancing the quality of code. This could also lead to the use of better project management and quality control. Open source users can independently evaluate the security for themselves. The real exposure of the system can be assessed and the gap between perceived and actual exposure is diminished. CSS does not allow users of such software to evaluate its security for themselves. This does not allow users to easily discover weaknesses and 'patching' is not possible by users. [14] 279 The 9th International Conference for Internet Technology and Secured Transactions (ICITST-2014) Analysis of published vulnerabilities There are no significant differences in terms of vulnerability severity found between open source and closed source. More and faster patches can be found in open source systems. Patches for open source systems are released faster than for closed source systems. Patch management is harder to coordinate in open source systems because OSS comes in many different versions. Patches will not be available for some distributions and they may be vulnerable to attacks while others are being patched. OSS products are more secure than CSS products. However, their general pattern of vulnerability detection is similar. The vulnerability severity found between open source and closed source are perceived to be the same. Patches for vulnerabilities of closed systems are released weeks or months after the discovery of the vulnerabilities and this increases the risk of using the system. The authors claim that it is easier to manage patches in a closed source system than in an open source system. [26] [14] Discussion of Table III Closed source designs and protocols are not published, whereas the OSS designs and protocols are published enhancing the security of OSS programs since logical errors may be revealed [14]. This is also the view of [5] that due to the openness of OSS code, it is easier to find and correct errors in OSS than in CSS. This is also pointed out by [14] that more and faster patches are found in OSS whereas patches are not released as fast in CSS, thereby increasing the risk of using the system securely. OSS users have the freedom to validate and test the code in order to ascertain its quality and security [20], therefore OSS initial coding tends to have higher quality and security than CSS. However, [4] argues that CSS is perceived to be more secure than OSS because it is developed in a controlled environment by a dedicated team of developers with a common direction. The view of [13] is that CSS can be as secure as OSS because the security of software is dependent on the user and not on its openness or closedness. The severity of vulnerabilities found between OSS and CSS are similar as pointed by [26]. While our view is that OSS is more secure than CSS, there are, however, security challenges that have to be overcome when migrating from a closed system to an open system [10]. VI. [3] SECURITY CHALLENGES DURING MIGRATION TO OSS A list of items that can be migrated is presented by [10] and these are: (a) Language or code migrations, (b) Operating system migrations, (c) Data migrations, (d) User Interface migrations and (e) Architecture migrations. He points out that the challenges to migration from Legacy systems to OSS include: (i) Qualification and selection of OSS, (ii) Human factors such as: Fear of the new software; Knowledge is power; Cost of training personnel for the new tools; reduced productivity of the personnel and (iii) Technical challenges. The technical challenges include: Usability; Software Development Service and support; Security; Data migration; and OSS Code Maintenance and Management [6]. According to [10] and [6], the security challenges during migration to OSS are: (a) Detecting security risks, bugs, and errors, (b) Eliminating the bugs and errors and (c) Obtaining metrics for measuring software security for real-time and mission critical software. CSS products are less secure than OSS products. -/1/$25.00©2014 IEEE [31] VII. A MODEL FOR ADDRESSING THE SECURITY CHALLENGES DURING MIGRATION TO OSS Summative content analysis was used as the research method to explore the model for addressing the security challenges during migration to OSS. During summative content analysis, the keywords (derived from review of literature) are identified before and during data analysis [15]. Keywords are extracted from the literature and mostly from the two articles written by [2] and [1]. An open source assessment framework and a threat modelling methodology, 280 The 9th International Conference for Internet Technology and Secured Transactions (ICITST-2014) pioneered by Microsoft since 1999 have been highlighted by [27], this is then proposed by [2] to overcome the security challenges of OSS. The aim is to reduce the risks to confidentiality, integrity and availability and to identify and reduce threats, vulnerabilities and risks to an acceptable level. They mention that alternative methods to reduce risks include: (a) Code auditing (b) Penetration testing, and (c) Using Statistical analysis tools. As per [2], the threat modelling process consists of four stages, viz: (i) Application Analysis/Diagramming (ii) Threat Enumeration, (iii) Threat Rating, and (iv) Mitigation Options. They point out that the threat modeling approach with slight modifications can assist with the identification of security vulnerabilities, as well as investigating coding issues and implementation mistakes. A Rudimentary Management Framework to protect sensitive information during the migration to an open source system is suggested by [1]. The model we propose in this section for addressing the security challenges discussed in this paper in migrating to OSS, is based in part on the threatmodeling framework in [2] and the sensitive information migration framework in [1]. Our model is illustrated in Fig. 1 and is discussed below: During the Application Analysis/Diagramming phase (A), the applications are analyzed from a flow of data perspective. All the aspects that make up the applications are catalogued and the relationships between the assets in terms of data exchange are identified through a UML Classoriented structure. The Threat Enumeration phase (B) consists of analyzing each element in the Class-oriented UML against a list of potential threats depending on the element type using the STRIDE Taxonomy [28]. STRIDE is used as a classification schema to characterize known threats in accordance to the attacker motivation. The risk levels for each of the enumerated threats are determined and ratings of all threats are established during the Threat Rating phase (C). During the Mitigation Options phase (D), all functionality and patching are removed and other security controls are added and redesigned. The business rules and the data classification system are used to classify migrated data during the Data Categorisation phase (E). Data protection tools and Privacy enhanced technologies are used to encrypt the data during the Data Encryption phase (F). The encrypted data is now migrated during the Data Migration phase (G). -/1/$25.00©2014 IEEE Figure 1. Modelling security challenges during OSS migration Implementing the Proposed Model The following processes are proposed to implement the model in Fig. 1: Phase A: Application Analysis/Diagramming Phase – (a) Identify security objectives – user identity protection, privacy and regulation, availability guarantees of applications. (b) Catalogue all the applications. (c) Analyse all the application designs and architectures to identify the components using Data Flows. (d) Identify UML component diagrams. (e) Identify the relationships between the assets using data exchange by using Class-oriented UML structures. Phase B: Threat Enumeration Phase – (a) Analyse each element in the Class-oriented UML diagram against potential threats by using the STRIDE Taxonomy. (b) Analyse data movement across trust boundaries (e.g. from Internet to Web tier). (c) Identify the features and modules with a security impact that need to be evaluated. (d) Investigate how data enters modules, how modules validate and process the data, where the data flows to, how the data is stored and what fundamental decisions and assumptions are made by the modules. 281 The 9th International Conference for Internet Technology and Secured Transactions (ICITST-2014) Phase C: Threat Rating Phase – (a) Identify threats using Bugtraq tools and techniques. (b) Determine the risk levels of each threat. (c) Establish the ratings of all the threats. (d) Use either a threat graph or a structured list to write the threats. Phase D: Migrations Options Phase – (a) Remove the functionality and patching. (b) Add other security controls. FUTURE WORK Future work in this area may be pursued along a number of lines: The framework proposed in [1] for protecting sensitive information during system migration has to be further integrated with the security-protection model proposed in this paper. In particular the classification of sensitive information in phase 5 – Data Categorisation has to be further developed. Having implemented our model, we have to validate it in industry at companies that have migrated to OSS, as well as those who are yet to undertake such migration. REFERENCES (c) Redesign other security controls. Phase E: Data Categorisation Phase – [1] O. A. Ajigini, J. A. Van der Poll, and J. H. Kroeze, “Towards a management framework to protect sensitive information during migrations”, The 2nd International Conference on Design and Modeling in Science, Education and Technology (DeMSet), pp. 6-13, 2012. [2] Y. Aner, and C. Cid, Open-Source security assessment, Royal Holloway Series, 2010. [3] R. Clake, D. Dorwin, and R. Nash, “Is open source software more secure?” Homeland Security / Cyber Security, 2009, from: (a) Develop business rules. (b) Develop a Data classification system. (c) Classify data based on business rules and the above data classification system. Phase F: Data Encryption Phase – (a) Deploy Data Protection Tools. (b) Deploy Privacy Enhancement Technologies. (c) Use secure Tools to encrypt the data. Phase G: Data Migration Phase – (a) Ensure that data to be migrated are encrypted by using verification techniques. http://www.cs.washington.edu/education/courses/csep590/05au/w hitepaper_turnin/oss%2810%29.pdf. (Access Date: 2 February, 2003). [4] (b) Migrate the encrypted data. VIII. CONCLUSIONS In this paper we investigated the notions of closed source software (CSS) and open source software (OSS); we discussed the respective advantages of each and considered comprehensively the security aspects underlying each approach to software development. A comparison of the benefits of OSS and closed source software by different authors was explored. The comparisons of the benefits of open source and closed source are slightly in favour of open source. Additionally, a comparison of OSS and CSS security was undertaken and our view is that OSS is more secure than CSS. Using summative content analysis, the challenges in migrating from a closed system to an open system were identified, and these, together with two frameworks – one for threat modelling [2] and another for protecting sensitive information during system migration [1]) were used to propose a model for addressing the various security aspects in migrating from an open system to a closed one. Our model is based on a seven-phase process as presented in Fig. 1. It is anticipated that this model may be useful as a basis for mitigating the security challenges in moving from a closed (CSS) to an open (OSS) system. J. Daniel, “Open source vs. closed source software: The great debate”, 2009, from: http://www.articlesbase.com/internet-articles/open-source-vsclosed-source-software-the-great-debate-.html (Access Date: 1 February, 2013). [5] B. Dwan, “Open source vs. closed”, Network Security, vol. 5, pp. 11-13, 2004. [6] H. M. A. ElHag, and H. M. Abushama, “Migration to OSS: readiness and challenges”, 2009. [7] B. Fitzgerald, “The transformation of open source software”, MIS Quarterly, vol. 30(3), pp. 587-598, 2006. [8] M. D. Gallegoa, P. Lunab, and S. Bueno, “User acceptance model of open source software”, Computers in Human Behaviour, vol. 24(5), pp-, 2008. [9] Gartner, “Gartner highlights: Key predictions for IT organisations and users in 2008 and beyond”, 2008. [10] S. Geetha, “Possible challenges of developing migration projects”, International Journal of Computers & Technology, vol. 3(3), pp. 463-465, 2012. [11] K. L. Gwebu, and J. Wang, “An exploratory study of free open source software users’ perceptions”, The Journal of Systems and Software, vol. 83(11), pp-, 2010. [12] K. L. Gwebu, and J. Wang, “Adoption of open source software: The role of social identification”, Decision Support Systems, vol. 51, pp. 220-229, 2011. -/1/$25.00©2014 IEEE 282 The 9th International Conference for Internet Technology and Secured Transactions (ICITST-2014) [13] M. Hansen, K. Kohntopp, and A. Pfitzmann, “The open source approach – opportunities and limitations with respect to security and privacy”, Computers & Security, vol. 21(5), pp. 461-471, 2002. [14] J. Hoepman, and B. Jacobs, “Increased security through open source”, Communications of the ACM, vol. 50(1), pp. 79-83, 2007. [15] H. Hsieh, and S. E. Shannon, “Three approaches to qualitative content analysis”, Qualitative Health Research, 2005, from: http://qhr.sagepub.com/content/15/9/1277 Date: 19 September, 2014). (Access [16] G. Little, and E. Stergiades, Worldwide Open Source Services,- Forecast, 2009. [23] Open Source Security Study, Fortify Report, 2008, from: www.fortify.com/ossreport.html (Access Date: 1 February, 2013). [24] H. E. Pearson, “Open source licenses, open source – The death of closed source Systems?” Computer Law & Security Report, vol. 16(3), pp. 151-156, 2000. [25] S. Raghunathan, A. Prasad, B. K. Mishra, and H. Chang, 2005, “Open source versus closed source: Software quality in monopoly and competitive markets”, IEEE Transactions on Systems, Man and Cybernetics – Part A: Systems and Humans, vol. 35(6), pp. 903-918, 2005. [26] G. Schryen, “Security of open source and closed source software: An empirical comparison of published vulnerabilities”, AMCIS Proceedings, Paper 387, 2009. [17] P. Kamthan, “A perspective on software engineering education with open source”, IGI Global, 2007. [27] A. Shostack, “Experiences threat modelling at Microsoft”, In Modelling Security Workshop, Dept. of Computing, Lancaster University, UK, 2008, from: [18] R. Kemp, “Current developments in open source software”, Computer Law & Security Review, vol. 25, pp. 569-582, 2009. http://blogs.msdn.com/sdl/attachment/-.ashx Date: 2 February, 2013). [19] A. Khanjani, and R. Sulaiman, R., “The aspects of choosing open source versus closed source”, IEEE Symposium on Computers & Informatics, pp. 646-649, 2011. [20] S. Manfield-Devine, “Open source: does transparency lead to security?”, Computer Fraud & Security, pp. 11-13, 2008. [21] G. Miscione, and K. Johnston, “Free and open source software in developing contexts, from open in principle to open in the consequences”, Journal of Information & Ethics in Society, vol. 8(1), pp. 42-56, 2010. [22] Open Source Report, Coverity Report, 2008, from: http://scan.coverity.com/report/ (Access Date: 1 February, 2013). -/1/$25.00©2014 IEEE (Access [28] F. Swiderski, and W. Snyder, 2004, Threat Modelling, Microsoft Press, 2004. [29] The Guardian, “‘Open invitation taken up at last”, 2004, from: http://society.guardian.co.uk/epublic/ story/-,00.html. (Access Date: 2 February, 2013). [30] B. Vintila, “Citizen oriented open source security”, Open Source Science Journal, vol. 2(3), pp. 57-64, 2010. [31] N. Walia, B. Rajagopalan, and H. Jain, “Comparative investigation of vulnerabilities in open source and proprietary software: An exploratory study”, Americas Conference on Information Systems (AMCIS), vol. 108, pp. 848-857, 2006. 283