Open Source Scientific Journal
Vol.1, no.1, 2009
Open Source Security – Quality Requests Mihai DOINEA Economic Informatics Department, Academy of Economic Studies, Bucharest, Romania
[email protected] Abstract: The basic open source concept is presented. Security is evaluated in the context of open source concept. Ways of increasing security are discussed. Security characteristics are evaluated for open source projects. Keywords: security, distributed applications, open source, optimization, characteristics. 1. Open Source – basic concepts Open source software is a freely distributed program in which the programming code is open and visible. In the history of information technology, protection was a primary goal established by the developers in their attempt to build faster, performant and reliable applications. Protection always was assumed to secrecy which meant security. Developers want that their programming source code to be private and secured against their competitors or other malicious users. The open source project had begun in 1998, being derived from another concept called free software. Open source represents any kind of informatics product, which grants rights to users that would otherwise be reserved by copyright law to the copyright holder. An example of this kind of distribution is the GNU, General Public License or GPL. In [*02] are presented the main aspects of an open source product, because open source is not just free access to source code, but: • free distribution – license must not restrict under any form, any part from selling or giving away the software as a component of an aggregate software distribution; • source code – products distributed under open source license must include their source code; • derived work – license must allow modifications and must allow them to be distributed under the same terms as the license of the original product; • author’s code integrity – the license may restrict source-code from being distributed in modified form only if the license allows the distribution of patch files with the source code for the purpose of modifying the program at build time; the license must explicitly permit distribution of software built from modified source code; the license may require derived works to carry a different name or version number from the original software; • no discrimination – the license must not discriminate any group or person or discriminate any field of research in which the product is wanted to be utilize; • distribution of license – the rights attached to the program must apply to all to whom the program is redistributed without the need for execution of an additional license by those parties; • license generality – the rights attached to the program must not depend on the program's being part of a particular software distribution; if the program is extracted from that distribution and used or distributed within the terms of the program's license, all parties to whom the program is redistributed should have the same rights as those that are granted in conjunction with the original software 126
Open Source Scientific Journal
Vol.1, no.1, 2009
distribution; • license must not restrict other software – the license must not place restrictions on other software that is distributed along with the licensed software; • license must be technology-neutral - no provision of the license may be predicated on any individual technology or style of interface. Open source has many benefits but has and drawbacks. The main assets are: • many developers can access the source code making it better and using it for their own purposes; • changing code for adding new extra features like security ones; • discovering any kind of mall intentions in the source-code; The principle drawbacks are: • free access to the source code including potential attackers; • open source not always means that someone would review the code and give a feedback or a patch. Open source products can produce quality if only the need for exploit is present. Otherwise, open source is developing hard when no interest is presented for the product discussed. 2. Security demands Security demands for open source software respect the rule of licensed software in terms of requests. All forms of security tests are applied with no other modification on the structure, more, the results are more accurate than the licensed form because of the availability of the source code. The security demands must assure all the stages to which software is put to test. Accordingly open source programs must satisfy the request of an auditing process of security by complying with the following types of testing methods: • blind method; a suppose attacker engages his target with no prior knowledge of its defense, assets or channels of attack, but the target is prepared knowing all the attacker’s details in advanced – what it can do and how much efficiency it has; • black-box method; the attacker engages his target with no prior knowledge about its defense at all and the target isn’t prepared for the attack; this kind of attack is more impartial as the victim doesn’t know what the attacker may search; also the attacker doesn’t know what to test; • gray-box method; the attacker engages the target with limited knowledge of its defense and assets, fully knowing only the channels of the attack; the target is prepared knowing in advanced all the details of the attack; this kind of attack tests the efficiency of both the attacker and target; • white-box method; like the gray-box method, the attacker has limited knowledge about the target defense mechanisms and assets and full knowledge of the attack’s channels; the target is notified in advanced but not completely on the variables of the attacker but only on the period and the scope of the attack; • crystal-box method; this is a mutual contract between the attacker and the target, both knowing a priori all the details of the attack; this kind of testing method is used for verifying the thoroughness of both the attacker and the target; • reversal method; is the mirrored process of blind testing method, meaning that the attacker knows all about his target and establishes what he will do based on the target’s weaknesses; the target knows nothing about the attacker’s potential being completely unprepared for what may come. The results are measured using an indicator that represents the deviation between the 127
Open Source Scientific Journal
Vol.1, no.1, 2009
results expected and those measured. The deviation, DEV is has the following formula: DEV = I MEASURED − I EXPECTED , where: I MEASURED – the value measured with one of the previous methods; I EXPECTED – the optimal value which is expected to be measured in order to have a safe level of security; If DEV indicator belongs to the (−∞;0) interval than the open source program which has been tested with a method of testing described has security breach, otherwise if DEV indicator belongs to the [0;+∞) than the security level is in accordance with the testing techniques used by the attacker. For an open source program to correspond to security demands it has to pass a wide range of security tests as follows: • information security; tests the security of data throughout the channels aiming to keep the quality characteristics of information intact: confidentiality, availability, authenticity, integrity and non-repudiation; • physical security; tests the whole frame in which open source programs are running testing control access, monitoring techniques, physical protective measures, alarm triggers and others physical protection techniques; • process security; tests whether or not there are security breach at the processing level; • communication security; tests the remote capability of programs and authentication procedures; • wireless security; deals with EMR, 802.11, RFID, Bluetooth and infrared communication standards testing the security of the programs; • internet technology security; verify all the aspects of internet technology that may cause security breach for the open source program questioned like: network surveying, system port scanning, services interception, operating system vulnerabilities exploiting by means of the open source program which runs on it. Security demands are defined accordingly to the existent technologies and the level of vulnerability calculated for that respective area of utilization. An open source program isn’t efficient unless, according to [01], it: • covers whole range of difficulties/problems that a user deals with; • minimize the effort of user interaction; • closes the success-usage rate to 100%; • minimize as much as possible the number of steps and selections for completing a successful workflow. 3. Risks and vulnerabilities In [02] the vulnerability is defined as a weakness that could be exploited in order to create a security breach into the system and have unauthorized access to information for different purposes either active or passive. Open source vulnerability is defined as a concept that covers the whole range of threats, given by its openness to the public. Due to this characteristic vulnerability must be a priority in the development stages of an open source product. In order to determine vulnerability level for an open source product an audit evaluation must be made and the frame in which the procedure will take place must be isolated. Open source products, by vulnerability level, can be classified in: 128
Open Source Scientific Journal
Vol.1, no.1, 2009
•
products with a high level of vulnerability – are those products which have a high level of visibility; besides the fact that their source code is at hand, they work in a network environment and the level of accessing them is highly favorable for all kinds of threats; • products with a medium level of vulnerability – are products in which developers through entire stage of evolution had added code source without managing entirely and unitarily the security aspects, everyone just taking care about their security breach; • products with a low level of vulnerability – are products developed in an organized context, with different levels of management like: security, vulnerability assessments, data and risk management; this products have the advantage that they are developed in a well defined frame. Vulnerabilities can be classified by various criteria. One of them is the level on which vulnerabilities appear. After this, vulnerabilities can be classified as follows: • information vulnerabilities – due to inconsistent of source code many information can be offered to the attackers; • physical vulnerabilities – defined as vulnerabilities which can exploit the main frame in which open source products are running to gain access to resources; • processing vulnerabilities – given by the usage of untested instructions or processing sequences; • communication vulnerabilities – due to bad implementation of communication protocols or to different forgotten aspects of communication. The vulnerability level, LV can be measured using the following formula presented in [03]: N
VL = ∑ i =1
N pi fi M
pi f i and M
N
∑p i =1
i
= 1 , where:
– the number of vulnerability types constituting the size of the vulnerability list described in the specifications; – the coefficient of importance for vulnerability of type i; – the frequency of type i vulnerability events; – the number of application activations.
If VL approaches 1, the vulnerability level is higher. Value of 1 means that all vulnerabilities are exploited every time when the application runs and the risks related is high. Vulnerability level has a cost associated with it, VC, and this it’s calculated with the following formula: N
VC = ∑ f i ci × VL , where: i =1
ci – the cost for a type i vulnerability occurrence. Open source programs may serve as a basis for developing other licensed products. The profit based on the vulnerability costs associated with the open source product, NP will be calculated based on the initial profit, P and the vulnerability costs, VC as follows: NP = P − VC
129
Open Source Scientific Journal
Vol.1, no.1, 2009
Open source vulnerability could determine organizations which had implemented open source solution to hire senior specialist for taking care of the eventual problems that may occur on the product life cycle. By doing sow, organizations reduces the costs caused by the development of their own products, avoiding as well the lack of knowledge that appear if the developers are moving to another work sector.
4. Quality characteristics Open source programs must present the following characteristic described in figure 1: MAINTAINABILITY
EFFICIENCY
FUNCTIONALITY
ISO/IEC 9126
PORTABILITY
RELIABILITY
USABILITY
Fig.1 – Product characteristics As presented in [03] the characteristics presented above are described as follow:
Maintainability represents the capacity of software to be kept in proper use after modifications at the level of instructions and databases were carried out, in order to reflect the algorithm changes, changes of reporting and inputs according to the new requirements of the organization management. The software maintainability index is defined by: IM = (L0 – LE + LA) / (L0+LM+LE+LA) where: L0 – number of instructions that are part of the software product before the maintenance process being started; LM – number of instructions from the software product that suffer modification due to the changes at the level of operands and operators; LE – number of instructions eliminated from the source text that is subject to the maintenance process; LA – number of source lines added to the existing software product. Accordingly, maintenance index are designed also at the level of databases, by taking into consideration: • modifications of the field type; • additions of new articles in the field; • elimination of fields from the article’s structure. Example: a program with L0 = 500 the number of initial instruction from which LE = 50 instructions were eliminated, and to which LA = 150 instructions were added and LM = 50 instructions were modified, for the maintainability indicator the value obtained is IM = 0,8. Reliability shows the level in which a program conducts to correct and complete results. An estimated reliability is found which refers to the software product comportment who is in one of the phases of development and more than that the effective reliability, IF, which is calculated as a report between the success running, NS, and the total number of iterations, NT, of software product: IF = NS / NT 130
Open Source Scientific Journal
Vol.1, no.1, 2009
The testing phase of a product through the process of running NT = 630 examples and the results obtained specified in NS = 487 cases leads to a value for effective reliability of IF = 0,77. Portability is the characteristic of product software of being launched in execution on a different configuration system with other operating system or using other database than the actual ones in which it was developed. The portability indicator IP shows the percentage of the actual costs, CA, necessary for modifications made in the initial program for it to can be launched in execution in the context of the new configuration and the cost CP, used for the acquisition of the program. The actual formula is: IP = 1 - CA / CP
If the costs for passing a software product on a new system configuration, hardware and software implicit, are CA = 120 and the initial cost of acquisition is CP = 480, then the indicator which give the value of portability for this program is IP = 0,75 (75%). Complexity is a measure of interdependences between instructions, procedure and diversity of constructions identified in a software program. The complexity on the source code, KT, takes into consideration the operands, N1, and the operators N2, used, having: KT = N1log2N1 + N2log2N2 The complexity on statistic graph, KS, take into consideration the graph associated to a software program, in which the nodes, NN, correspond to the executable instructions and the arcs, NA, to the dependences between those instructions, resulting: KS = NA – NN + 2 The complexity on dynamic graph, KD, associated to the software program has as goal the development of a structure which depends directly to the number of iterations and the way in which the instructions are composed inside the repeating sequences. Efficiency shows the level of resources needed for launching and maintaining in execution the software product in normal condition environment. It describes the way in which the software product determines and returns final results. It refers to the behavior in time of the application, exactly to the response time on types of processing, the actual time of a transaction on different conditions of loading and different configurations hardware and software. Functionality describes the minimum specifications used for running the application when it can not be assured the optimal condition for it to work. It refers to knowing and respecting some software standards which assures the correct level of applications quality. As well it describes the quality of software program to respect the product specifications as well as other characteristics which can facilitate work: network communication, software communication, protection using cryptography and saving data. Usability is the capacity of a software program to be used by a lot of different users. It describes the effort of a user for actual learn and understand the application and running a full cycle of it. Usability is greater as the effort of un-homogeneous users has slightly variations are from a user to other user. In the context of defining those distributed application quality characteristics will be defined the characteristics for the security, being necessary to follow step by step the process of integration of components security process for the distributed application:
131
Open Source Scientific Journal
Vol.1, no.1, 2009
•
assuring the availability at any moment of time through the implementation of security methods for informatics systems: the secure access to the building in which are found those systems; • the protection of distributed application systems by introducing new levels of security based on password for assuring the integrity; • preventing unauthorized access to the distributed applications to avoid any lesion by defying the information’s confidentiality; • implementing cryptography systems for signing distributed application’s information for not having to disclaim something from the system at the same time assuring the confidentiality. These characteristics accordingly to standards presented in [*01] can be divided in other subcharacteristics, table 1:
Table 1 – Product subcharacteristics Characteristics Subcharacteristics Definitions Attributes of software that bear on the presence and Suitability appropriateness of a set of functions for specified tasks. Accurateness
Attributes of software that bear on the provision of right or agreed results or effects.
Interoperability
Attributes of software that bear on its ability to interact with specified systems.
Compliance
Attributes of software that make the software adhere to application related standards or conventions or regulations in laws and similar prescriptions.
Security
Attributes of software that bear on its ability to prevent unauthorized access, whether accidental or deliberate, to programs or data.
Maturity
Attributes of software that bear on the frequency of failure by faults in the software.
Fault tolerance
Attributes of software that bear on its ability to maintain a specified level of performance in case of software faults or of infringement of its specified interface.
Recoverability
Attributes of software that bear on the capability to reestablish its level of performance and recover the data directly affected in case of a failure and on the time and effort needed for it.
Understandability
Attributes of software that bear on the users’ effort for recognizing the logical concept and its applicability.
Learnability
Attributes of software that bear on the users’ effort for learning its application.
Operability
Attributes of software that bear on the users’ effort for operation and operation control.
Time behaviour
Attributes of software that bear on response and processing times and on throughput rates in performances its function.
Functionality
Reliability
Usability
Efficiency
132
Open Source Scientific Journal
Vol.1, no.1, 2009
Attributes of software that bear on the amount of Resource behavior resource used and the duration of such use in performing its function. Analyzability
Attributes of software that bear on the effort needed for diagnosis of deficiencies or causes of failures, or for identification of parts to be modified.
Maintainability Changeability
Attributes of software that bear on the effort needed for modification, fault removal or for environmental change.
Portability
Stability
Attributes of software that bear on the risk of unexpected effect of modifications.
Testability
Attributes of software that bear on the effort needed for validating the modified software.
Adaptability
Attributes of software that bear on the opportunity for its adaptation to different specified environments without applying other actions or means than those provided for this purpose for the software considered.
Installability
Attributes of software that bear on the effort needed to install the software in a specified environment.
Conformance
Attributes of software that make the software adhere to standards or conventions relating to portability.
Replaceability
Attributes of software that bear on opportunity and effort using it in the place of specified other software in the environment of that software.
All characteristics and subcharacteristics presented must be met by any open source product in order to be validated someone who wants to use it. This assumption applies even more to open source products as their source code can be viewed by anyone.
5. Conclusions Open source concept wants to help users better understand internal functioning of open source products or develop software related but with others functionality added. Open source products permit to anyone who’s interested to make modifications, port it to new operating systems and processor architectures creating a new set of rules regarding the development, testing and maintenance stage, lowering budgets and not wasting precious time. The idea of open source had contributed to the development of certain products for the fact that anyone could post comments, make modifications, optimizing performances of the release product without any authorization. In this way open source products had developed wisely and rigorously having in any moment a group of developers that are writing, testing or using the source code. Open source security is widely discussed because of its primary characteristic, openness, which make some developers to say that this is a security breach, and others to say that if a product is free-source, security holes are less. This idea is equally true because if the product isn’t developed properly and that’s the case for a lot of licensed software, even more being open source, presents a high level of vulnerability. On the other hand if the open source program is developed properly, tested by many different programmers with different visions, 133
Open Source Scientific Journal
Vol.1, no.1, 2009
covering a wide range of vulnerabilities then certainly the vulnerability level is lower, and much lower than a licensed software.
Bibliography [01]
Ion IVAN, Mihai DOINEA, Sorin PAVEL, Sorin VINTURIS – Security management in distributed IT applications, The Proceedings of the Ninth International Conference on Informatics in Economy, IE 2009, May 7-8, 2009, Bucharest, Romania, ASE Printing House, ISBN 978-606-505-178-2
[02]
Victor Valeriu PATRICIU, Ion BICA – Semnaturi electronice si securitate informatica, All Printing House, Bucharest, 2006
[03]
Ion IVAN, Mihai DOINEA – Vulnerability optimization in distributed applications, Economic Growth and E.U. extension process International Conference, ASE, Bucharest, 2008
[04]
Ion IVAN, Mihai DOINEA, Leonard SĂCUIU – Evaluating security of non-homogenous distributed applications, 4th International Conference on Applied Statistics, Bucharest, November 2008, ISBN 1018-046x
[05]
I. Lungu, Gh. Sabău, I. Velicanu, M. Muntean, S. Ionescu, E. Posdarie, D. Sandu – Sisteme informatice. Analiză, proiectare şi implementare, Economica Press, Bucharest, 2003
[06]
Victor Valeriu PATRICIU, Ion BICA – Securitatea comerţului electronic, All Printing House, Bucharest, 2001
[07]
Ion IVAN, Cătălin BOJA – Practica optimizării aplicaţiilor informatice, ASE Printing House, Bucharest, 2007, ISBN 978-973-594-932-7, 483 pg.
[08]
Craig WRIGHT – The IT regulatory and standards compliance handbook, Elsevier Printing House, June, 2008, 750 pg.
[*01]
http://www.iso.org/iso/catalogue_detail.htm?csnumber=22749
[*02]
http://en.wikipedia.org/wiki/Open_source_software#Philosophy
134
Open Source Scientific Journal
Vol.1, no.1, 2009
Mihai DOINEA attended the Faculty of Economic Cybernetics, Statistics and Informatics of the Academy of Economic Studies, graduating in 2006, Computer Science specialization. Having a master degree in Informatics Security, promotion 2006-2008, he is currently a PhD candidate, Economics Informatics specialty in the same university, also teaching as assistant to Data Structure and Advanced Programming Languages disciplines. Following are the fields of interests in which he wrote a number of papers in collaboration or as single author concerning: security, distributed applications, e-business, security audit, databases, and security optimization.
135
