Secure Software Development Life Cycle Research Paper

Exclusively available on Available only on IvyPanda® Made by Human No AI

Introduction

Information assurance is one of the major dimensions of computer systems security. It involves protection of valuable data and facts from possible damage, misuse, or theft. In some cases, the data theft may lead to losses estimated to reach millions; therefore, companies and organizations do everything possible to ensure that their information is safe (Bishop, 2003). Many techniques have been discovered and applied to ensure safety, but most of them have been outwitted by hackers.

The battle with hackers is getting tougher every day, and Shawn Henry having analyzed the situation believes that it would be impossible to defeat the hackers (Barrett. 2012). However, there is still some hope that the issue of the hackers’ attacks can be managed if the best practices that have been developed so far will be implemented by all developers. Incorporation of security issues in the software development life cycle commonly known as Secure SDLC is so far undefeated.

It involves the assessment and testing the software for common and anticipated flaws and security loopholes in every stage of its development, hence correcting them appropriately. It is a more secure and cheaper option than trying to stand against and complete the whole software, so it should be tested only to realize its weaknesses that would have been located and rectified in an earlier stage (Grembi, 2008; Rakesh & Vignesh, 2011). We look at the general classes of attacks and vulnerabilities that come as a result of software flaws.

General classes of attacks

First, we have authentication management flaws. This refers to weak passwords that can be discovered using the brutal hacking (Meunier, 2008). Also, a poor storage of passwords makes them easily accessible to cybercriminals, thus becoming another weakness detected. The password management system should incorporate ease of use together with high quality security. Complicated systems that are not user friendly make the whole system more vulnerable as users try navigational paths that help them bypass some security checks, and with time, these paths become loopholes for attackers to use.

Passwords have been in existence in the computing world for a long time as they become a common and quite effective way to ensure security of personal and corporation data. The very initial form is when the user should have a username and a password to log into a system. In the very early stages, passwords were stored on the server in plain text form. When a user inputs his password, it is compared with the one in the database, and if they match, access is allowed. If a password was intercepted at any stage, then it was easy for an attacker to access the system in impersonation of a legitimate user. Due to the insecurity associated with this method of authentication, hashed passwords were introduced where the specimen password would be run through a hashing algorithm before storage.

The hash would be a sequence of bytes that cannot be reversed to reproduce the password. When logging in, the user types his password, and the system produces its hash and compares it with the stored sample. There is no fear of interception since the hash is almost useless to a hacker. Then there was a challenge–response model according to which the system sent the user a challenge in the form of randomized character string, and the user responded with a computational value based on the password and the challenge. In search of more secure means of system access, scientists came up with the idea of one time passwords which although were tedious and costly to generate, were as well more secure.

Then Kerberos was developed which is a distributed authentication service that uses tickets. The password technology has, however, evolved over time bringing in more secure means like smart cards and biometric techniques. These reduce the typing involved at login and make the process easier and more secure than using the ordinary password. Smart cards are read by machines and biometric methods due to bodily features, such as fingerprints for authentication. But, even with these evolutions, the username-password combination is still the most commonly used form of authentication.

Second, we have software bugs which are errors in the program that cause the system to behave abnormally. They are easily exploitable by attacks. With such a bug, it is easy to find a loophole that allows an adversary to bypass security checks and/or run commands on the host. If the programmer leaves data buffer sizes unchecked, it makes them vulnerable to overflows leading to corruption of memory areas defined by stacks or heaps. These can be exploited by attackers who flood the buffers with data with the aim of corrupting or overwriting the contents of these buffers. This may also lead to the following results, thus the computer under attack begins to execute the malicious code provided by the hacker.

Bugs are dated as early as 1945 when Grace Murray Hopper and her team, while working on the mark II and mark III machines, found a bug (a moth) trapped in a relay and causing the whole system to malfunction. The insect was removed and attached to the machine’s log book with the note “First actual case of bug being found” next to it (Hughes, 1989). This was the origin of the term bug, and it was used to refer to mechanical failures in hardware, but with software evolution, it was adopted to refer to all the errors in software that make it malfunction. Recently, Toyota recalled 160000 of its new model Prius after complaints that the vehicles warning lights were going on with no reason.

Also, the gasoline engines for these cars were reported to stop unexpectedly. The problem was caused by a bug in the software that controls the auto. In 1990, a bug in a new version of software released used the control of long distance switches for AT&T caused a network outage by making the huge computers in use crash when they receive a particular message. It was a message that is sent to inform neighbors of recovery from a crash. It began with a switch crashing in New York forcing its neighbors to crash and reboot, and then the trend went on to the neighbors’ neighbors, and in no time, 114 machines were crashing and rebooting after every six seconds. This led to a 9-hours-‘no service’ state for the users.

The previous version of the software was reloaded to save the situation. Invalidated user input is the third vulnerability. Some programs lack the means to validate data input and assume that all inputs are harmless. This can allow unauthorized direct execution of SQL commands. Lastly, we have flaws in the operating system design. Mostly, these occur when choosing policies to be enforced, such as authentication ones, some of them, if set to default, will allow all users to access every detail of the system.

If an attacker gains access to the system in the name of an authorized user, he/she can take control over the system and accomplish the set mission that may be still or corrupt data files, read confidential information, and harm the system in some other way. This is possible not only for human attackers but also for malware. Impersonation of a legitimate user by malware and viruses is also common leading to loss of valuable data and information. They execute commands which effects, such as deletion of files from databases or coping and addition of the same ones, are disastrous.

New general classes of attacks and vulnerabilities

As time goes and new technologies emerge, new threats of attacks appear each day that exploit vulnerabilities in the new technologies or those that have not been seen as vulnerabilities before. One of these new threats is Cross Site Scripting (CSS or XSS). This is found in systems when their output is un-escaped data, thus exploiting web applications that are dynamically driven. A user’s submitted information is redisplayed on another page after being held in a database. In such a case, JavaScript or HTML can be easily input into the field with the unverified data causing operational disruptions. If an attacker’s effort is rewarded by a successful system entry, the hacker can now conduct his ill intended activities, such as spreading worms, taking over control of user accounts, hence accessing the cookies, reading the browser history and also accessing the clipboard contents.

JavaScript is executable, and when passed through forms, it is assumed to be from an authentic source, and it has privileges equal to other users including access to information (Gundy, Chen, 2011). This poses great danger since it may be from an adversary with ill motives. XSS may become a bigger problem with the use of AJAX which can enable the script to access critical functions and databases. This might lead to SQL injection which is executed when a web application allows its users to input plain text into a text box, and this is used to query a database (Ullman, 2008). The attacker can then take control over the database and do whatever they wish.

We also have Cross Site Request Forgery (CSRF) that is often mistaken for Cross Site Scripting. In this form of attack, a legitimate user is tricked by an attacker by sending a request to a website he is authorized to use. This may be done via a link sent to a person by attacker, normally, from a malicious website, or even through a chat message that when clicked on, sends the request that the attacker intended to the victim’s website, and the request seems to have come from the victimized user. Once the request is granted, the attacker may gain access to databases and other sensitive information on the victim website.

The whole website may be compromised if the attacked user was an administrator. The New York Times’ website suffered from such an attack where users’ email addresses were accessed by hackers. The flaw was later patched after it had been identified. CSRF, as it is commonly referred to, can impact heavily on the user since the attacker has the ability to do whatever he/she wishes with the account. He/she can even access bank details and other very important information that is connected with online business. Internet security experts look at it as an incoming big threat to cyber security (Higgins, 2006)

Examples of companies using Secure SDLC tools

Fishnet security is a company that provides system development tools for use in development of secure programs using secure SDLC, i.e. programs that help developers incorporate security measures into the system. Fishnet does not only provide tools but also uses these techniques to create secure software for its customers. Some companies, such as Fortune 500, have partnered with Fishnet to ensure high level security within programs; the applications are developed by multidisciplinary teams of experts. These teams combine expertise from network engineering, software development, computer science, etc. They have developed an Application Security Solution set that comprises Application security evaluation, Source Code Review, Web Application Firewall, and others. Fishnet security also provides means of training developers and users in a secure way (Peloquin, 2009)

Microsoft is a leading software development company. In its continued efforts to provide secure applications to its clients, Microsoft has adopted the Secure Software development Life Cycle approach to security. Every development milestone has its security requirements that must be met in order to progress (Kunene, 2010). If the software fails the test for a particular stage, progress is stalled until all the requirements are met. Threat models are created for every new project to help identify weaknesses that may make the end product vulnerable.

Effectiveness of Secure SDLC application

The common vulnerabilities and attacks are defined in a database, Common Weaknesses and Enumeration (CWE) database, maintained by MITRE Corporation that is free for access (Chandran, 2011). These form a basis of what to look for in software’s security analysis. However, the list may not be exhaustive as new threats are emerging every minute now and then. The tools for secure SDLC may also not cover all vulnerabilities; this means that the effective use of these tools is not enough to curb all the threats, but to try to do it is a major step.

With continuous upgrades, these practices will stay at the top of the list. Companies like Microsoft have reported up to 60% drop in the cases of security breaches reported after adopting SDL techniques. It would be worth noting that the organizations are highly effective in using these tools, but the tools themselves need to be highly maintained ensuring that they are able to address new threats, challenges or vulnerability that may crop up. Traditional methods of security control that have proved effective in the past should also not be discarded but combined with the secure applications to enhance their security even further.

Conclusion

Security requirements should be part and parcel of software requirement analysis in the SDLC. When it comes to design and testing, the same case should be applied. Just like applications are taken through rigorous performance testing procedure, in the same way, they should be tested for security. However, the rising demand for information assurance should not run over the need for quality. As programmers struggle to create secure information systems, they should also bear in mind the initial requirement which is quality. If it does not fulfill its intended purpose effectively, then no matter, how secure an application is, it is valueless.

References

Barrett, D. (2012).The Wall Street Journal. Web.

Bishop, M., (2003) Computer Security: Art and Science. Boston, MA: Addison Wesley.

Chandran, D. (2011) CWE Initiative Helps Secure Code Development Efforts. COTS Journal. Web.

Grembi, J. (2008) Secure Software Development: A security Programmer’s Guide. Boston, MA: Course Technology.

Gundy, V. & Chen, H. (2011).Noncespaces: Using Randomization to Defeat Cross site Scripting Attacks, Computers & Security. Web.

Higgins, K. (2006). . Dark Reading. Web.

Hughes, P. (1989). American Genesis: A History of the American Genius for Invention. Penguin Books.

Kunene, G. (2010). Security in All Phases of the Software Development Lifecycle. Web.

Meunier, P. (2008) CS626: Classes of Attacks and Vulnerabilities, Perdue University. Web.

Peloquin, J. (2009) Secure SDLC Review and Development. Web.

Rakesh, D., Vignesh, R. (2011) A Software Engineering Approach for Vulnerability Analysis. International Journal of Computer Applications in Engineering Sciences (IJCAES). Web.

Ullman, L. (2008) PHP 6 and MySQL 5 for Dynamic Websites. Peachpit Press.

More related papers Related Essay Examples
Cite This paper
You're welcome to use this sample in your assignment. Be sure to cite it correctly

Reference

IvyPanda. (2020, July 14). Secure Software Development Life Cycle. https://ivypanda.com/essays/secure-software-development-life-cycle/

Work Cited

"Secure Software Development Life Cycle." IvyPanda, 14 July 2020, ivypanda.com/essays/secure-software-development-life-cycle/.

References

IvyPanda. (2020) 'Secure Software Development Life Cycle'. 14 July.

References

IvyPanda. 2020. "Secure Software Development Life Cycle." July 14, 2020. https://ivypanda.com/essays/secure-software-development-life-cycle/.

1. IvyPanda. "Secure Software Development Life Cycle." July 14, 2020. https://ivypanda.com/essays/secure-software-development-life-cycle/.


Bibliography


IvyPanda. "Secure Software Development Life Cycle." July 14, 2020. https://ivypanda.com/essays/secure-software-development-life-cycle/.

If, for any reason, you believe that this content should not be published on our website, please request its removal.
Updated:
This academic paper example has been carefully picked, checked and refined by our editorial team.
No AI was involved: only quilified experts contributed.
You are free to use it for the following purposes:
  • To find inspiration for your paper and overcome writer’s block
  • As a source of information (ensure proper referencing)
  • As a template for you assignment
Privacy Settings

IvyPanda uses cookies and similar technologies to enhance your experience, enabling functionalities such as:

  • Basic site functions
  • Ensuring secure, safe transactions
  • Secure account login
  • Remembering account, browser, and regional preferences
  • Remembering privacy and security settings
  • Analyzing site traffic and usage
  • Personalized search, content, and recommendations
  • Displaying relevant, targeted ads on and off IvyPanda

Please refer to IvyPanda's Cookies Policy and Privacy Policy for detailed information.

Required Cookies & Technologies
Always active

Certain technologies we use are essential for critical functions such as security and site integrity, account authentication, security and privacy preferences, internal site usage and maintenance data, and ensuring the site operates correctly for browsing and transactions.

Site Customization

Cookies and similar technologies are used to enhance your experience by:

  • Remembering general and regional preferences
  • Personalizing content, search, recommendations, and offers

Some functions, such as personalized recommendations, account preferences, or localization, may not work correctly without these technologies. For more details, please refer to IvyPanda's Cookies Policy.

Personalized Advertising

To enable personalized advertising (such as interest-based ads), we may share your data with our marketing and advertising partners using cookies and other technologies. These partners may have their own information collected about you. Turning off the personalized advertising setting won't stop you from seeing IvyPanda ads, but it may make the ads you see less relevant or more repetitive.

Personalized advertising may be considered a "sale" or "sharing" of the information under California and other state privacy laws, and you may have the right to opt out. Turning off personalized advertising allows you to exercise your right to opt out. Learn more in IvyPanda's Cookies Policy and Privacy Policy.

1 / 1