Sie sind auf Seite 1von 11

Risk Analysis for Software Security and Quality Faculty Of Software Engineering Tshwane University Of Technology matetesekhwela@gmail.

com SEKHWELA MJ 209137038

ABSTRACT Measuring the security of a software system is a difficult problem. Analysis of software security risk in the early development phase is very important to validate and secure the software system to ensure quality. Specifically, software evaluation is very useful to determine the software security and to estimate the risk. The risk factor can be determined as a combination of the probability that a software system may be failed through security threat and the damages caused by an attack, usually by hackers. The risk factor can also be due to human factor, like human error. The term Risk refers to a problem or situation that can threaten the success of the software project but has not happened yet. Risks are uncertain. The main objective of most organizations is to provide very high quality software to their customers with minimum risks involved. The term Quality is a value to the person. But there is a long list of software risks that can have adverse impact on the quality of the software. It is necessary to address all the risks; otherwise, they may lead to undesirable results. All kinds of human factors can deeply affect the results and efficiency of software risk and security. Human error can have a great impact in affecting the system and cause software risks. The human factors are identified and classified for the categories of individual, team, management and stakeholder, as well as for the activities of security risk identification, analysis and mitigation Shareeful Islam, Wei Dong 2008. The purpose of this article is to help identify risk related to software security and quality. To ensure that software is secured, developers must ensure that systems are developed with proper caution to avoid vulnerability and to be easily hacked. Vulnerabilities in software can jeopardize intellectual property, consumer trust, and business operations and services. Additionally, a broad spectrum of critical applications and infrastructure, from process control systems to commercial application products, depend on secure, reliable software. It is estimated that 90 percent of reported security incidents result from exploits against defects in the design or code of software. Ju An Wang, Hao Wang 2009 .Security Metrics for Software Systems. Therefore, ensuring the integrity of software is critical to protecting the infrastructure from threats and vulnerabilities, and reducing overall risk to cyber attacks. In order to ensure system reliability, integrity, and safety, it is critical to include provisions for built-in security of the enabling software. With the advances of computer hardware, the security and dependability of a computing system rely heavily on its software. The current state of the arts of software technology has not reached the same level as its hardware counterpart in terms of reliability and security [20].

KEY WORDS: Risk analysis, Software security, Software risk analysis, Security threat, Security risk

1. INTRODUCTION Security vulnerabilities are discovered every day in commonly used software. Software security is very difficult to determine. Systems are neither secure nor insecure. Security is often described in relative terms. A system is more, or less, secure than something else. This is caused by the difficulty of specifying how secure a certain software system is. Complexity, connectivity and extensibility make security decisions very difficult [11]. One of the major questions organizations often faced with is how secure their systems are? Answering the question is difficult. Despite extensive research in security engineering, measuring security is still a difficult problem [11]. Part of the problem is attributed to the unpredictability of software systems vulnerabilities. Add to this an ever-increasing complexity, lack of awareness and unwillingness to share data on security attacks, and the problem quickly becomes intractable. While we do not have security measurements with absolute certainty, we often rely on measurement of risk in assessing security. The difficult part lies in providing accurate information on attacks and their likelihood [2]. Since systems are typically exposed to constant changes, associated risks are often affected by such changes. However, risk assessments are not typically repeated as often as changes are introduced into systems. Over time, initial risk estimates become outdated possibly leading to less secure systems and software unsecured. As we have matured in the area of perimeter protection mechanisms, so have the attackers. Security attacks are moving higher in the traditional network stack from automated network level attacks to complex application-level attacks [12]. We cannot improve security if we cannot measure it. However, measuring security is hard because the discipline itself is still in the early stage of development. To date there are few documented resources and existing work on software security metrics. There are a great variety of different vulnerabilities existing for different kinds of software. Each vulnerability or exposure has different impact on the quality and security attributes of the software product such as confidentiality, integrity, availability, and so on. Another challenge is to validate the defined security metrics, comparing different metrics definitions [20].

Many organizations have the objective to provide high quality software to the customers within budget and schedule, but high quality software doesnt come without a risk. It requires an organization to plan for risks. The term Quality refers to the degree to which a system meets specified requirements of a particular customer. In other words, Quality means a value to someone [7]. Quality consists of all the features to provide product satisfaction [7]. But, it is not always possible to fulfill all the customers requirements by a particular system. Risks may arise

during the development process and can have adverse affects on the quality of the software and that can lead unsecured software [8]. So, there is a need to control all the possible risks. Although controlling risks has a cost, if the risks are not addressed in a timely manner, they may result in undesirable results. There is no magic solution that overcomes software risks and security [9]. Risks occur due to errors made by software programmers and can cause software vulnerability that can also result in unsecured software. The causes of software errors can be due to faulty requirements, communication gap between clients and developers, deliberate deviations from software requirements, logical design errors, wrong documentation, shortcoming in testing process and procedure errors. Risks are always uncertain and do not have any exact value. There is a long list of risks that always reduce software quality. IT security is becoming increasingly important. Software security is an essential aspect thereof. Software bugs and flaws provide the entrance doors for many malicious attacks. Organizations must take measures to secure their software against threats in order to ensure quality delivery software. Microsoft has developed Security Development Lifecycle (MS-SDL) for companies to secure their products. By use of Microsoft Security Development Lifecycle (MS-SDL) this will improve security for their software and also eliminate threats to their software. Microsoft has introduced security and privacy early and throughout all phases of the software development process. Security related vulnerabilities in the design, code, and documentation should be minimized and detected as well as eliminated as early as possible. The resulting Microsoft Security Development Lifecycle (MS-SDL) aims at reducing the number and the severity of security vulnerabilities and improving privacy protection. The MS-SDL adds several steps to the software development process and introduces additional roles. These improvements of the development process can be applied incrementally and do not require radical changes of existing development processes. A variant for agile development has also been suggested [14]. Metrics are quantifiable measurement. Security metrics are quantitative indicators for the security attributes of an information system or technology. Metrics helps us understand quality and consistency [20]. Security metrics can also help in eliminating the software risks and software vulnerability. 1.1 RISK IDENTIFICATION It is expected that critical security risks can be identified before they will introduce some problems into the systems. Security risk is a threat that would cause harm to critical assets. Generally, people have different views while conducting the risk identification. Some common variations of the human perception while identifying the security risks include [17]: People generally prefer risks that they know or concern individually Too much attention is paid to identify the hidden, new, unfamiliar or uncertain risks Less attention is paid to the common, anonymous, less discussed risks

Overestimating the hidden risks and underestimating the common risks Misunderstanding or neglecting the threat environment Overconfidence of internal systems Considering more on external attacks that can exploit the security breaches Considering less on internal users who can sometimes also exploit severe security vulnerabilities Underestimating the risks from some controlled or trusty external sources, etc. Due to these factors, actual risks may not be properly or completely identified initially[17]. 1.2. SECURITY VULNERABLILITIES Human factors are underlying reasons for many attacks on information systems. Hackers, intruders, virus writers and all other malicious users may exploit the human factors to penetrate the systems. To improve the software security, each layer of the information systems is required to be perfectly secure. Users still think computer as a black box. They dont understand that using the software which contains vulnerability can bring the genuine security risks. Sometimes users may simply ignore following the minimum responsibilities, such as opening email attachments from anonymous users, irregularly updating the antivirus software, etc. This lack of security consciousness helps hackers to complete the successful attacks via malicious activities. Most users are also not aware of how to correctly treat confidential information, such as choosing weak password, writing password in plain paper and laying it on the desk, not following the clean desk policy, sharing ID, etc. All these issues can be helpful for the social engineers to breach the confidential information. Not only ordinary users, but also the security professional can violate the security policies. These risk factors concern the human rather than technologies, and may cost a lot even using the best technologies. These factors can be concluded as [18]: Deficient security awareness Inadequate considerations of security issues more than virus and worms Ignoring security alerts Lack of security analysis before choosing products Ignoring users responsibilities 1.3 RISK ANALYSIS. Risk is anything that threatens the successful achievement of a projects goals. Specifically, a risk is an event that has some probability of happening, and that if it occurs, will result in some loss [27]. 1.4 SOFTWARE SECURITY. Software security is very difficult to determine. Systems are neither secure nor insecure. Security is often described in relative terms. A system is more, or less, secure than something else. This is caused by the difficulty of specifying how secure a certain system or component is. Complexity, connectivity and extensibility make security decisions very difficult [11]. One of the major questions organizations

often faced with is how secure their systems are? Answering the question is difficult. Despite extensive research in security engineering, measuring security is still a difficult problem [11]. 1.5 SECURITY AWARENESS Security awareness can be defined as the knowledge that members of an organization possess regarding protection of the physical and information assets of that organization. It also reflects the attitude and motivation of the members of an organization towards understanding and addressing various security issues. Awareness of security promotes a cultural and behavioral change among the members of an organization. Being security aware means that there is an understanding that some people may intentionally and deliberately or unintentionally and accidentally steal, damage or misuse the data and other resources of an organization [22]. Security awareness can also be defined as the concentrated and focused attention of an employee towards maintaining the confidentiality, integrity and availability of information assets. Security awareness helps and encourages an individual or a group to recognize the various security concerns and how to deal with them when they arise with an appropriate response [23]. Fortifying software applications from attack is an effort that occurs late in the software development process. Applying patches to fix vulnerable software in the field is a common approach to securing application software [19]. 1.6 SOFTWARE SECURITY There are many possible measures of software security. Counting the number of weaknesses is not satisfactory because some weaknesses can never result in a failure. Exploits of vulnerabilities are more concrete, but are not widely reported and are affected by adversaries tactics, which may change dramatically. To use the number of reported vulnerabilities as a measure of security because vulnerability is a real problem and it depends less on the choice of the adversary. One of the major problems in software security is the lack of knowledge about security among software developers. Even if a developer has good knowledge about current software vulnerabilities, they generally have little or no idea about the causes and measures that can avoid those vulnerabilities. Now it is established fact that most of the vulnerabilities arise in design phase of the software development lifecycle.

2. BACKGROUND This article focuses on the software security and risk related to system software in organizations. The article also helps to identify and eliminate risk related to software security and provide quality of software in their organization. One of the major problems in software security is the lack of knowledge about security among software developers. Challenges faced by many organizations especially IT industry is software security and software vulnerability. Software failure and hackers. To ensure that

software is secured, developers must ensure that systems are developed with proper caution to avoid vulnerability and to be easily hacked. To do that it requires lots of research on security and regular system testing by experienced developers. Security vulnerabilities are discovered by users and developers every day in commonly used software. Software security is very difficult to determine. Systems are neither secure nor insecure. Security is often described in relative terms. Ensuring the integrity of software is critical to protecting the infrastructure from threats and vulnerabilities, and reducing overall risk to cyber attacks. Study of Risk Factors Risk analysis is the process of gathering all the risks and focusing on all the risks individually [28]. Risk analysis evaluates all the risks and the impact of each risk on softwares success. Risks can be categorized as Very Low Risk, Low Risk, Medium Risk, High Risk, Very High Risk [29].

2.1 DEFINATIONS The following definitions are adapted from [24]. Any event which is a violation of a particular system's security policy is a security failure, or simply a failure. Vulnerability is a property of system security requirements, design, implementation, or operation that could be accidentally triggered or intentionally exploited and result in a security failure. Vulnerability is the result of one or more weaknesses in requirements, design, implementation, or operation. Sometimes we use term defect to refer to code weakness [24]. Risk - is anything that threatens the successful achievement of a projects goals. Specifically, a risk is an event that has some probability of happening, and that if it occurs, will result in some loss John D. McGregor 2001. Failure The inability of a software system or component to perform its required functions within specified performance requirements [11]. Fault - An incorrect step, process, or data definition in a computer program. Note: A fault, if encountered, may cause a failure [11]. Vulnerability - An instance of a [fault] in the specification, development, or configuration of software such that its execution can violate an [implicit or explicit] security policy [16]. Software security risk management - is a process which includes step by step activities, such as asset identification, threat and risk identification, risk measurement, consequence quantification and evaluation, risk reporting and mitigation[17]. Security risk is a threat that would cause harm to critical assets [17]. Security metrics are quantitative indicators for the security attributes of an information system or technology [20]. Vulnerability refers to flaws or weakness in a systems design, implementation, or operation and management that could be exploited to violate the systems security policy [20].

Security awareness - is defined as the knowledge that members of an organization possess regarding protection of the physical and information assets of that organization.

3. CONCLUSION To date there are few documented resources and existing work on software security metrics. There are a great variety of different vulnerabilities existing for different kinds of software. Each vulnerability or exposure has different impact on the quality and security attributes of the software product such as confidentiality, integrity, availability, and so on. Another challenge is to validate the defined security metrics, comparing different metrics definitions [20]. This article is made to help avoid errors that cause software vulnerability and ensure to provide quality software and security. Eliminate the risk related to software and raise software awareness to users to help educate them in system security and software risks. Help eliminate vulnerability to software. This paper deals with the representation of generic software risk analysis knowledge using the software risk analysis. Researchers are working to get the more and knowledge of how risk factors can be measured and integrated into the project management process to ensure quality products. So that negative impacts can be avoided or we can plan out how to tackle such kind of risks during the management of the development process. Risk analysis is a structured mechanism to provide the visibility of threats to project success. Researchers are concerned by sharing which risk factors does directly and which risk factors does not directly affect among multiple projects will help upcoming software projects to avoid reiterating the issues of the past. As researchers are working in the area of risk management and as more and more data is collected, the refined the models and techniques will become in the future. Risk Analysis Methods There are various approaches to risk analysis depending on the industry and target of analysis. For example: IT industry analyses risks with different tools and from a different angle compared to how a security manager handles company security risks. IT industry approaches risk evaluation through mathematical tools and probability theories (e.g. [34]). The theories can be mathematically very complex the main principle from IT companys point of view is that the cost of claims should not exceed the income from the IT fees. Corporate security manager again might want to develop an Information Security Management System (ISMS) based on ISO27001 and evaluate risks from corporate perspective. Company IT security risk analysis typically approaches risk analysis through first identifying the valuable assets and then studying the possible threats to the assets [31]. IT system risks can also be analyzed with guidance from the NIST published guide given the current status of the different risk analysis methods, there would seem to be need for improved risk identification methodology for solution security evaluation. Particularly needed would be a method, which would systematically take into account the system aspects, system environment aspects, and socio economical factors.

Risk Identification Risk Analysis methods typically have rather limited guidance as to how Risk Identificationshould be done. Very often, however, the methods - or the users of the method - employ a brainstorming session with the system experts to identify the risks. How the brainstorming is arranged, varies from method to another. Reference material (e.g. [30], [31], [32] & [33]) base the Risk Identification work typically on analysis of the following items: Identifying assets, identifying Threats and Vulnerabilities (Risks) to the assets and subdividing risks to confidentiality, integrity, and availability risks. Studying security features (countermeasures) of the system under study. Studying security checklists (known threats/vulnerabilities/risks). General system scrutiny trying to think like the bad guy Efficient risk identification can best be achieved, when the security expert performing risk analysis is equipped with experience from risk analysis and typical risks, company knowledge base, checklists, appropriate methodology and tools, and experts of the system under study. There have been attempts to systematize risk identification. For example Failure Mode Effect Analysis (FMEA) starts with the smallest system components and builds on them, asking how a failure of a subcomponent affects the overall system [34]. The issue with that method in conjunction with the Risk Analysis is that it has only failureas a risk. Risks can realize without a component actually failing: For example a hacker can get access credentials to a system through social engineering rather than forcing the authentication system to fail. Systems thinking has also been applied to systematizing security weakness finding process [35]. The complexity of the system, however, increases so rapidly that thorough systems analysis for system security becomes prohibitively expansive and expensive. In practical security work, the risk identification depends significantly on the expertise of the security expert and on the best practices and the knowledge base developed by the company. In addition to the knowledge base information, there exists to number of practical tools (e.g. questionnaires) for identifying risks. Quite often a security expert from outside of the organization can help the organization to identify the most significant risks invisibleto the insiders. A comprehensive systematic method for Risk Identification is unlikely to emerge in the near future. This study attempts to develop a new methodology to identify risks, based on the VCDT.

REFERENCES [1]. LAKS, V. S. LAKSHMANAN and RAYMOND, T. NG GANESH RAMESH 2008. On Disclosure Risk Analysis of Anonymized Data. ACM TransactionsonKnowledgeDiscoveryfromData,Vol.2,No.3,Article13. [2]. Hyunsang Youn, Cheolhyun Park, Eunseok Lee 2011. Security based Survivability Risk Analysis with Extended HQPN [3]. Yanping Chen, Robert L. Probert, D. Paul 2004. Sims Specification-based Regression Test Selection with Risk Analysis.

[4] John D. McGregor, and David A. Sykes, A Practical Guide to Testing Object-Oriented Software, Addison Wesley Inc., 2001. [5] . Mary Jean Harrold, James A. Jones, TongyuLi, and Donglin Liang, Regression Test Selection for Java Software, Proceedings of the ACM Conference on OO Programming, Systems, Languages, and Applications (OOPSLA 01), 2001. [6]. Nitin Bhatia, Namarta Kapoor 2011. Fuzzy Cognitive Map based Approach for Software Quality Risk Analysis. ACM SIGSOFT Software Engineering Notes [7]. Petrasch, R. 1999. The definition of software quality: a practical approach. In Proceedings of the 10th International Symposium on Software Reliability Engineering. 1999. 33 34. [8]. Boehm, B.W. 1981. Software engineering economics. Prentice Hall. 1981. [9]. Charette, R.N. 1989. Software engineering risk analysis and management. McGraw-Hill, New York. 1989. [10]. Zaid Dwaikat, Francesco Parisi-Presicce 2005. Risky Trust: Risk-Based Analysis of Software Systems. Software Engineering for Secure Systems-Building Trustworthy Applications (SESS05), May 1516, 2005, St. Louis, Missouri, USA. [11]. Hoglund, G. and McGraw, G., Exploiting Software: How to break Code, Addison-Wesley, 2004. [12] Hoglund, G. and McGraw, G., Exploiting Software: How to break Code, Addison-Wesley, 2004. [13]. S. Chandra, R. A. Khan, Software Security Metric Identification Framework (SSM) 2009. International Conference on Advances in Computing, Communication and Control (ICAC309). [14]. Michael Kainerstorfer, Johannes Sametinger, Andreas Wiesauer 2011. Software Security for Small Development Teams A Case Study.

[15]. ISO/IEC 24765, "Software and Systems Engineering Vocabulary," 2006. [16]. Vulnerability - An instance of a [fault] in the specification, development, or configuration of software such that its execution can violate an [implicit or explicit] security policy. [17]. Bruce Schneier. The psychology of Security, http:// www.schneier.com/ eassy-155.html, 2008.

[18]. Shareeful Islam, Wei Dong 2008.Human Factors in Software Security Risk Management. [19]. Michael Gegick, Laurie Williams 2001. Matching Attack Patterns to Security Vulnerabilities in Software-Intensive System Designs. [20]. Ju An Wang, Hao Wang 2009 .Security Metrics for Software Systems. ACMSE '09 March 19-21, 2009, Clemson, SC, USA. [21]. C. Banerjee, S. K. Pandey 2010.Research on Software Security Awareness: Problems and Prospects. ACM SIGSOFT Software Engineering Notes [22]. http://en.wikipedia.org/wiki/Security_awareness [23] http://it.toolbox.com/blogs/adventuresinsecurity/strengthen-security-wi th-an-effective-security-awareness-program-870 [24]. [3] P.E. Black, M. Kass, and M. Koo, Source code security analysis tool functional specification version 1.0, NIST SP 500-268, May 2007. [25]. Vadim Okun, William F. Guthrie, Romain Gaucher, Paul E. 2007.BlackEffect of Static Analysis Tools on Software Security: Preliminary Investigation: QoP07, October 29, 2007, Alexandria, Virginia, USA. ACM 978-1-59593-885-5/07/0010. [26]. S. Rehman & K. Mustafa 2009 .Research on Software Design Level Security Vulnerabilities. ACM SIGSOFT Software Engineering [27]. John D. McGregor, and David A. Sykes, A Practical Guide to Testing Object-Oriented Software, Addison Wesley Inc., 2001. [28]. Dash, R., Dash, R. 2010. Risk assessment techniques for software development. European Journal of Scientific Research. 42, 4 (2010), 629-636. [29]. Galorath, D. 2006. Risk analysis and prioritization. PM World Today. 8, 9 (September 2006). [30]. Anon. 2005. First edition. ISO/IEC 27001. International Standard: Information technology Security techniques Information security management systems Requirements. [31] Anon. 2008. First edition. ISO/IEC 27005. International Standard: Information technology Security techniques Information security risk management. [32]. Anon. 2009. Version 3.1. Third revision. Common Criteriafor Information Technology Security Evaluation. Part 1:Introduction and general model.

[33]. Stoneburner, Gary; Goguen, Alice & Feringa Alexis. 2002. Risk Management Guide for Information Technology Systems, Recommendations of the National Institute of Standards and Technology. NIST Special Publication 80030,US Department of Commerce. Booz Allen Hamilton ltd. [34]. Beard R.E.; Pentikinen T. & Pesonen E. 1984 [1969]. Third edition. Risk Theory. The Stochastic Basis of Insurance. Chapman and Hall Ltd, USA. [35] Halla, Antti. 2006. Masters Thesis: Applying a Systems Approach to Security in a Voice Over IP System. Helsinki University of Tehcnology.

Das könnte Ihnen auch gefallen