ANALYSIS OF SOFTWARE THREATS AND SOFTWARE SECURITY Dr. Deepshikha Jamwal Bhawana Sharma
Research Scholar Research scholar
Department of Computer Science & IT University of Jammu,
Jammu ABSTRACT
Security is often an afterthought when developing software. That is a formal approach in the software lifecycle is essential to protect corporate resources. Security process is a continuous process and works at each phase of software development life cycle. We believe that security needs to be building into the software from the beginning, and those security activities needs to take place through out the software life cycle. To accomplish this effectively requires structured approach combining a detailed understanding on what causes vulnerabilities, and how to prevent them. The purpose of this paper is help to understand the important role that security plays in the Software development and to evolve the software development process so that threats are prevented. The process encompasses the addition of a series of security-focused activities. This paper focuses on finding the various software threats effected areas and the analysis done by the authors shows that increasing growth rate of threats year by year.
KEYWORDS
Software security, Software flaws, software threats
SECURITY ENVIRONMENT AND OBJECTIVES
The first step in any development is to clearly define the software expected
behavior. The same rule applies to security, for which the concepts of security environment and its objectives must be defined in the stages of development.
Secondly topropose the process which is flexible, straightforward and well adapted to the need of most businesses. METHODOLOGY
Project life cycles generally follow an iterative process of analysis, design, implementation, testing and maintenance. By the means of this paper the authors are focusing on how to adapt the methodology to produce a trustworthy application. Figure 1 depicts the approach that we insert security concerns at each step of lifecycle and trying to build an improvement program.
Fig 1. Software security in the SDLC.
Static analysis (tools) Penetration testing Risk-based Security Tests Security requirements Design Review Risk Analysis Design Test Plans Code Test Results Field feedback Code Review Requirements
Bharati Vidyapeeth’s Institute of Computer Applications and Management, New Delhi 1. INTRODUCTION
Software is said to be secure if it can perform properly despite of vulnerabilities. Software is a general term for the various kinds of programs used to operate computer, related devices and the development is the determination of the best techniques for applying a process to production of goods or services. It is clear electronic world is now a far more dangerous place. This means the existence of vulnerabilities in the software reflects that software can be compromised at any point of time. Computers are increasingly networked, making it easier for attackers to target nearly anyone in the world, sometimes with very little risk .Even a simple application that displays or edit local files must be secure ,because user might displays or edit high-risk files received through electronic mail. Unfortunately, many software developers have never learned how to write secure applications. With computer crime on the rise, Software security has become an important concern for system administrators and computer users.
As a result the final product should cost less over its lifetime, be of higher quality and reliability, and be simpler to maintain. Security must be built-in while the product is being developed, not included as an add-on at the end of the product development [1]. 1.1 Current State of software Security There are several reasons for the current state of software development. Two key issues are,
1) “The attitude today is that one can write any piece of code and compiler will run diagnostics”.
2) The constant demand for novelty means that software is at the bleeding edge phase, when products are inherently less reliable to these reasons should also be added lack of skilled developers and training, and lack of resources such as code analyzers that can check the security of software and systems [2].
1.2 Analyzing Security
Security analysis consists of several steps. Firstly it must be define the project’s security environment and objectives, and then list the application’s potential threats and prioritize them. These results in a security policy that can be evaluate risks [3].
1.3 Security policy
The definition of an application’s threat model should help to flesh out a security policy - a set of security requirements that can prioritize according to the information’s sensitivity.
1.4RISK EVALUATION
An analysis typically ends with a risk evaluation. Obviously, all threats don’t include the same risk: some are difficult to exploits, others have a bigger impact, and so on. Several solutions propose metrics to rate risk and some of the best known used formula’s such as
risk = criticality * likelihood of occurrence.
2. SOFTWARE PROPERTIES.
To be considered secure, software must exhibit three properties:
1. Dependability: Dependable software executes predictably and operates correctly under all conditions, including hostile
software comes under attack or runs on a malicious host.
2. Trustworthiness:
3.
The software must contain no malicious logic that causes it to behave in a malicious manner.
Survivability:
3. ANALYSIS
Survivable software that is (1) either resist (i.e., protect itself against) or tolerate (i.e., continue operating dependably in spite of) most known attacks plus as many novel attacks as possible, and (2) recover as quickly as possible, and with as little damage as possible, from those attacks that it can neither resist nor tolerate [4,5].
2% 3% 15% 37% 42% 0% 1% Encryption Module Other Communication Protocol Hardware Operating System Non-Server Application Server Application
Fig2. Percentage of Software threats in different areas.
Fig 2 Depicts that 41% server applications, 36% non server applications, 15% operating system are insecure, rest 3% of hardware, 2% of communication protocols and 1% others are the fields where lies the software threats. 0 5000 10000 15000 20000 25000 1 4 7 10 13 16 19 22 25 28
Fig 3. Growth rate of increasing threats
Fig 3 defines the security threats are increasing from 1980 to 2007. By means of the graph the growing rate of threats is shown.
4. SOFTWARE SECURITY THREATS
INSIDER THREATS: This perhaps the
most difficult category of threats, since the perpetrators are already inside the organizations leveraging their access to corporate information.
PERSISTENT TARGETED THREATS: theses are sophisticated threats targeting proprietary or sensitive information, often through subtle means such as faked e-mail messages or the exploitation of series of individually innocuous vulnerabilities.
SUPPLY CHAIN THREATS: In addition to the vulnerability of supply chains to direct IT security attacks the danger of counterfeit or tampered computer hardware and software provided by vendors and suppliers often based overseas, have already made headlines. ATTACKS AGAINST DATA: While great emphasize has been placed on securing data in transit, defending the data against unauthorized editing is often overlook.
Bharati Vidyapeeth’s Institute of Computer Applications and Management, New Delhi UNPUNISHED ATTACKS: The non-US
adversary is emboldened by the difficulty of prosecution against across national boundary.
ITSECURITY ARMS RACE: The threat is asymmetrical, with the adversary able to focus time and money on attacks, while the target has to prioritize spending on IT security among other budget items [6].
4.1 GENERAL PRINCIPLES OF
SECURE SOFTWARE DEVELOPMENT:
The following principles should guide the development of secure software, including all decisions made in producing the artifacts at every phase of the software life cycle.
1. 2.
Minimize the number of high-consequence targets.
3.
Don’t expose vulnerable and high-consequence components.
4.
Deny attackers the means to compromise.
5.
Security software is not the same as secure software
5. BUILDING AN IMPROVEMENT PROGRAM.
Once it is specific and actionable plan, a pragmatic approach should drive each initiative.
The general framework and plan discussed earlier should include several factors, including,
Never make blind assumptions.
tools, processes,
decision criteria and associated actions,
examples and blueprints, best practices,
guidelines, and metrics and measures.
Several other drivers, including current software architectures, security policies and guidelines and regulatory requirements, can also help align the framework with the strategic business direction.
6. CONCLUSION
This paper presents a critical look at discovering vulnerabilities at each phase of development life cycle and mitigates them there only. An improved/extended security process proposed in this paper seems to deliver some software.
8. FUTURE SCOPE
The finding in this paper leads to the following scope of further research. We have been further working on the analysis of latest sophisticated hardware and software tools which can be used to detect and quantify flaws and threats in software development life cycle.
REFERENCES
[1] Keramati, et.al, “Integrating software
development security activities with
agile methodologies”, 4493611,
Page(s):749 - 754, 2008.
[2] Zadeh, J, et.al, “Software development and related security issues”,
[4]. S. Lipner “The Trustworthy Computing Security Development Life
Cycle”. In Proceedings of the 20
343000, Page(s):746 – 748, 2007.
[3] Noopur Davis et.al, “Secure Software
Development Life Cycle Processes”,
ISBN: 1-4244-1029-0, IEEE, 2007.
th Annual Computer Security Applications
Society, Dec 2004.
[5] M.Haward, “Building More Secure Software with Improved Development
Life Cycle”, pp.63-65, IEEE Security &
Privacy, 2(6), Nov-Dec2004
[6] P. Torr., “Demystifying the
Threat-modeling Process”, pp.66-70, IEEE
