The paper proves that despite numerous studies in the field of improving the reliability and security of system and application software, conducted over the years, despite building a variety of approaches by many leading scientists in the field, vulnerabilities and software failures still exist and manifest. An actual task now is to predict software failures and vulnerabilities, for which the problem of classification of software failures and vulnerabilities should be solved first. The purpose of this study is to: build mathematical models of software failures and vulnerabilities; construct criteria and production rules for the classification of software failures and vulnerabilities. The classification of software failures and vulnerabilities depending on their manifestation, mathematical models of software failure and vulnerabilities, as well as criteria for the classification of software failures and vulnerabilities, which allow formulating rules for classification of software failures and vulnerabilities, were developed. The proposed rules for the classification of software failures and vulnerabilities provide an opportunity to facilitate the process of identifying errors in the software. A promising area of research is to build a method and algorithm for predicting software failures and vulnerabilities based on developed mathematical models of failure and vulnerabilities, classification criteria, and rules for software failures and vulnerabilities.
In terms of the reliability and security of the computer as a whole, system software errors are the biggest threat. For example, a buffer overflow error can cause the system to fail completely (reliability issue) or allow a professionally written virus to intercept control of the computer (security issue). Application software also contains many defects, but these errors can cause only limited damage if the system software does not contain errors.
The modern system software has features that make it unreliable and dangerous – it is huge and has a very weak localization of errors [1]. For example, the Linux core has more than 2.5 million lines of code, and the Windows core has twice as many. The operation system (OS) contains hundreds of thousands of procedures, which are assembled together as a single binary program operating in core mode.
The study conducted in [2] shows that as the size of the software increases, the error rate in the software increases, and for software larger than 512K is 4-100 errors per 1000 lines of code. Another study [3] provides a density of 2 to 75 errors per 1000 lines of executable code, depending on the size of the module. Using a moderate estimate of 4 errors per 1000 lines of code, we have 10,000 possible errors in the Linux core and 20,000 possible errors in the Windows core. An even bigger problem is that usually, about 70% of the operating system consists of drivers that have 3-7 times more errors than simple code [4], so the calculated number of errors is probably much underestimated. It is clear that finding and correcting all these errors is not feasible. Analysis of the Android mobile OS showed 359 software bugs, including 88 high-risk bugs and 271 medium-risk bugs, which is a serious threat to OS security [5].
As for the weakness of error localization in the OS, each of the millions of lines of core code can overwrite the basic data structures used by its independent components, disabling the system in ways that are difficult to detect. In addition, if a virus infects one core procedure, there is no way to keep it from spreading quickly to other procedures and prevent it from invading the computer as a whole.
Currently, there are various approaches used to increase the reliability and security of the OS: 1) the Nooks approach [6], which protects the core from device drivers by placing each driver in a shell of protective software; 2) paravirtualization approach [7], which allows the simultaneous launch of several operating systems on one computer using the mechanism of virtual machines; 3) the approach of creating multi-server operating systems [8], in which only the micro core is run in core mode, and the rest of the OS works in user mode as a set of completely isolated server processes and drivers; 4) Microsoft Research approach [1], which rejects the concept of OS as a single program running in core mode, with some set of user processes running in user mode, and replaces it with a system written in new type languages that provide the security of types. All of these approaches are based on preventing a complete system failure caused by multiple errors in device drivers, but are not aimed at predicting and resolving system software failures and vulnerabilities.
Despite numerous studies in the field of improving the reliability and security of software over the years, despite building a variety of approaches by many leading scientists in the field, vulnerabilities and software failures still exist and manifest themselves in the form of OS crashes, inability to load, "loss" of certain peripherals, information leaks, financial losses, environmental and man-made disasters [9-14]. The consequences of insufficient software security are presented in Table1.
allowed attackers to gain access to 50 million profiles of users of the social network Facebook The Uber taxi app was hacked and information about 600,000 drivers and 57 million user accounts was stolen. Instead of reporting the incident, Uber paid the attacker $ 100,000 for his silence
Therefore, software behavior is indeterminate due to errors, the success of software security attempts is possible only by improving the quality of software and reducing the number of errors, for this process of identifying errors should be facilitated, so the actual task now is to predict software failures and vulnerabilities, for which we must first decide the task of classifying the software failures and vulnerabilities.
In this case, the purpose of this study is to: 1. Develop mathematical models of software failures and vulnerabilities 2. Construct criteria and production rules for the classification of software failures and vulnerabilities
leads to leakage, unauthorized disclosure, illegal access, or use of any information.
The information availability vulnerability Iav will be called the functional feature of the software, which leads to a state in which entities that have access rights to information cannot implement them without hindrance.
Obviously, vulnerabilities can be complex - for example, vulnerabilities that simultaneously threaten the integrity and confidentiality of information, or vulnerabilities that simultaneously threaten the correct operation of software, integrity, confidentiality, and availability of information, etc.
Given the above, let's develop a mathematical model of software vulnerabilities in terms of manifestations of vulnerabilities: = {
∀( ∀( ∀( ∀( ∩ ∩ ∩ ∩ ∩ ∩ ∩ ∩ ∩ ∩ ∩ ∈ ∈ ∈ ∈
) ∩ ∃( ) ∩ ∃( ) ∩ ∃ ( ) ∩ ∃ (
→ ) → (
≠ −1)) → (
≠ −1) ∩ ( > −1)) → (
≠ −1) ∩ ( < −1)) ∩ ∩ ∩ ∩ ∩
∩ where: FT = {ft1,…,ftm } – set of all software functional features; m is the total number of all software functional features; j – the time after performing the functional feature with the vulnerability; (j-1) – the time before performing the functional feature with the vulnerability; Dj – set of data after the execution of the functional feature with the vulnerability; Dj-1 – set of data before performing the functional feature with a vulnerability; Ij is the set of data that can be used after performing a functional feature with a vulnerability; Ij-1 – set of data that can be used before performing the functional feature with a vulnerability; A
j – set of data that can be freely used by an entity that has access to them, after performing a functional feature with a vulnerability; Aj-1 is a set of data that can be freely used by an entity that has access to them before performing the functional feature with a vulnerability.
As proved in Section 1, the current challenge is to predict software failures, for which the problem of classification of software failures should be solved first. To solve the problem of software failure classification, it is necessary to formulate failure classification criteria. Given the proposed definitions of failure types, let’s propose the following failure classification criteria: 1. Loss of operability (ability to function) of the software 2. Loss of data (all or part) of the software 3. The need to restart the computer
Given the proposed definitions of types of vulnerabilities, let's propose the following criteria for classifying the vulnerabilities: 1. Occurrence of software failure 2. Loss of completeness of data 3. Leakage of unauthorized information 4. Impossibility to obtain permitted information
Using the developed mathematical model of failure, and also the proposed criteria of classification of failures of the software, let's construct rules of classification of failures: 1. If the state si of the software after cessation of operation is operational (si ϵ S) and during the cessation of operation there was no data loss, i.e. Di = Di-1, the failure is insignificant 2. If the state si of the software after cessation of operation is operational (si ϵ S), but during the cessation of operation there was a loss of data, i.e. Di < Di-1, the failure is significant 3. If the state si of the software after cessation of operation is not operational (si is not an element of the set S), the failure is critical
Using the developed mathematical model of vulnerability and the proposed criteria of classification of vulnerabilities, let's construct rules of classification of vulnerabilities: 1. If during the execution of the h-th functionality of the software it stopped functioning for a time th, which exceeds the specified for the software of this type threshold time tlim (th > tlim), then the h-th functionality of the software is correct work vulnerability 2. If after the execution of the h-th functionality of the software there was a loss of completeness of data, i.e. Dj (h) ≠ Dj-1 (h), then h-th functionality of the software is information integrity vulnerability 3. If after the execution of the h-th functionality of the software there was a data leak, i.e. Ij (h) ≠ Ij-1 (h), and Ij (h) > Ij-1 (h), then h-th functionality of the software is information confidentiality vulnerability 4. If after the execution of the h-th functionality of the software there is an impossibility to obtain the information allowed by the user, i.e. Aj (h) ≠ Aj-1 (h), and Aj (h) < A-1 (h), then h-th functionality of the software is information availability vulnerability 5. If during the execution of the h-th functionality of the software it stopped functioning for a time th, which exceeds the specified for the software of this type threshold time tlim (th > tlim), there was a loss of completeness of data, i.e. Dj (h) ≠ Dj-1 (h), then the h-th functionality of the software is correct work and information integrity vulnerability 6. If during the execution of the h-th functionality of the software it stopped functioning for a time th, which exceeds the specified for the software of this type threshold time tlim (th > tlim), and there was a data leak, i. e. Ij (h) ≠ Ij-1 (h), and Ij (h) > Ij-1 (h), then the h-th functionality of the software is correct work and information confidentiality vulnerability 7. If during the execution of the h-th functionality of the software it stopped functioning for a time th, which exceeds the specified for the software of this type threshold time tlim (th > tlim), and there is an impossibility to obtain the information allowed by the user, i.e. Aj (h) ≠ Aj-1 (h), and Aj (h) < A-1 (h), then the h-th functionality of the software is correct work and information availability vulnerability 8. If after the execution of the h-th functionality of the software there was a loss of completeness of data, i.e. Dj (h) ≠ Dj-1 (h), and there was a data leak, i. e. Ij (h) ≠ Ij-1 (h), and Ij (h) > Ij-1 (h), then h-th functionality of the software is information integrity and information confidentiality vulnerability 9. If after the execution of the h-th functionality of the software there was a loss of completeness of data, i.e. Dj (h) ≠ Dj-1 (h), and there is an impossibility to obtain the information allowed by the user, i.e. Aj (h) ≠ Aj-1 (h), and Aj (h) < A-1 (h), then h-th functionality of the software is information integrity and information availability vulnerability 10. If after the execution of the h-th functionality of the software there was a data leak, i. e. Ij (h) ≠ Ij-1 (h), and Ij (h) > Ij-1 (h), and there is an impossibility to obtain the information allowed by the user, i.e. Aj (h) ≠ Aj-1 (h), and Aj (h) < A-1 (h), then h-th functionality of the software is information confidentiality and information availability vulnerability 11. If during the execution of the h-th functionality of the software it stopped functioning for a time th, which exceeds the specified for the software of this type threshold time tlim (th > tlim), there was a loss of completeness of data, i.e. Dj (h) ≠ Dj-1 (h), and there was a data leak, i. e. Ij (h) ≠ Ij-1 (h), and Ij (h) > Ij-1 (h), then the h-th functionality of the software is correct work, information integrity and information confidentiality vulnerability 12. If during the execution of the h-th functionality of the software it stopped functioning for a time th, which exceeds the specified for the software of this type threshold time tlim (th > tlim), there was a data leak, i. e. Ij (h) ≠ Ij-1 (h), and Ij (h) > Ij-1 (h), and there is an impossibility to obtain the information allowed by the user, i.e. Aj (h) ≠ Aj-1 (h), and Aj (h) < A-1 (h), then the h-th functionality of the software is correct work, information confidentiality and information availability vulnerability 13. If during the execution of the h-th functionality of the software it stopped functioning for a time th, which exceeds the specified for the software of this type threshold time tlim (th > tlim), there was a loss of completeness of data, i.e. Dj (h) ≠ Dj-1 (h), and there is an impossibility to obtain the information allowed by the user, i.e. Aj (h) ≠ Aj-1 (h), and Aj (h) < A-1 (h), then the h-th functionality of the software is correct work, information integrity and information availability vulnerability 14. If after the execution of the h-th functionality of the software there was a loss of completeness of data, i.e. Dj (h) ≠ Dj-1 (h), there was a data leak, i. e. Ij (h) ≠ Ij-1 (h), and Ij (h) > Ij-1 (h), and there is an impossibility to obtain the information allowed by the user, i.e. Aj (h) ≠ Aj-1 (h), and Aj (h) < A-1 (h), then h-th functionality of the software is information integrity, information confidentiality and information availability vulnerability 15. If during the execution of the h-th functionality of the software it stopped functioning for a time th, which exceeds the specified for the software of this type threshold time tlim (th > tlim), there was a loss of completeness of data, i.e. Dj (h) ≠ Dj-1 (h), there was a data leak, i. e. Ij (h) ≠ Ij-1 (h), and Ij (h) > Ij-1 (h), and there is an impossibility to obtain the information allowed by the user, i.e. Aj (h) ≠ Aj-1 (h), and Aj (h) < A-1 (h), then the h-th functionality of the software is correct work, information integrity, information confidentiality and information availability vulnerability
For example, let's consider the software for traffic light control at the intersection of streets, developed by one of the IT companies in Khmelnytskyi (Ukraine).
Two failures occurred during the test operation of this software. After the first failure f1, the software remained operational, but data was lost during the failure. After the second failure f2, the software stopped working at all.
Using the developed rules of classification of failures, it was established that: 1. Failure f1 is significant, i.e. f1 ϵ Sf 2. Failure f2 is critical, i.e. f2 ϵ Cf
A detailed study of software for traffic light control at intersections showed that the failures were due to a number of vulnerabilities in the analyzed software. Thus, one of the available functional features v1 led to the termination of the software, another functional feature v2 led to the loss of data completeness, the third functional feature v3 led to the impossibility of obtaining the information allowed by the user, the fourth functional feature v4 led to the loss of data completeness and the inability to obtain the authorized user information at the same time, and the fifth functional feature v5 led to the termination of the software, loss of data completeness and the inability to obtain the information allowed by the user at the same time.
Guided by the developed rules of classification of vulnerabilities, it is established that: 1. Functionality v1 is correct work vulnerability, i.e. v1 ϵ Cwv (rule 1) 2. Functionality v2 is information integrity vulnerability, i.e. v2 ϵ Iiv (rule 2) 3. Functionality v3 is information availability vulnerability, i.e. v3 ϵ Iav (rule 4) 4. Functionality v4 is information integrity and information availability vulnerability, i.e. v4 ϵ Iiv Iav (rule 9)
Vulnerabilitites
Correct work vulnerability (functionalities v1, v5) Information integrity vulnerability (functionalities v2, v4, v5) Information availability vulnerability (functionalities v3, v4, v5)
Therefore, the proposed rules for classifying the software failures and vulnerabilities provide an opportunity to facilitate the process of identifying errors and incorrect functionality in the software.
The paper analyzes the current state of the field of software reliability and security, as a result of which the features of the software that make it unreliable and dangerous are identified. An analysis of the approaches currently used to improve software reliability and security has shown that the approaches are based on preventing complete system failure, but are not aimed at predicting and resolving software failures and vulnerabilities. The paper proves that despite numerous studies in the field of improving the reliability and security of system and application software, conducted over the years, despite building a variety of approaches by many leading scientists in the field, vulnerabilities and software failures still exist and manifest.
The classification of software failures and vulnerabilities depending on their manifestation, mathematical models of software failure and vulnerabilities, as well as criteria for the classification of software failures and vulnerabilities, which allow formulating rules for classification of software failures and vulnerabilities, were developed. The proposed rules for the classification of software failures and vulnerabilities provide an opportunity to facilitate the process of identifying errors in the software.
A promising area of research is to develop a method and algorithm for predicting software failures and vulnerabilities based on developed mathematical models of failure and vulnerabilities, classification criteria, and rules for the classification of software failures and vulnerabilities.
Practical areas of application of the proposed approach are predicting the failures and vulnerabilities of both application and system software, as well as the classification of failures and vulnerabilities of both application and system software.
[1] A. Mitrokotsa, M. Rieback, A. Tanenbaum, Classifying RFID attacks and defenses. Information
Systems Frontiers 12 5 (2010) 491-505. doi: 10.1007/s10796-009-9210-z. [2] S. McConnell, Code complete, Microsoft Press, Redmond, 2013. [3] T. Ostrand, E. Weyuker, Predicting bugs in large industrial software systems. Lecture Notes in
Computer Science 7171 (2013) 71-93. doi: 10.1007/978-3-642-36054-1_3.