Introduction
The software development lifecycle (SDLC) is a framework utilized in the development of software systems. Its structure involves five phases that are essential for effective software development, which is as follows (Hijazi, Alqrainy, Muaidi, & Khdour, 2014):
- Requirements analysis
- Design
- Implementation and Unit testing
- Integrations and systems testing
- Maintenance and operations.
Nevertheless, software development is a process that involves certain risks, as the SDLC framework is prone to weaknesses from the start of the project and until the acceptance of the final product by the customer. There are different kinds of threats that affect each particular stage and might cause disruptions or even prevent the entire project from being completed. In order to be able to manage these risks properly and provide a cost-efficient risk management strategy, these risks and their causes must be fully understood and identified. The concept of intrinsic versus non-intrinsic security weaknesses is considered to be among the primary factors to consider when developing an effective risk management strategy. The purpose of this paper is to explain how Risk Management is used to determine whether a vulnerability is considered intrinsic or non-intrinsic, and how that decision influences subsequent decisions that guide secure and resilient software design per the SDLC.
What are Intrinsic and Non-Intrinsic Vulnerabilities?
Intrinsic vulnerabilities are identified as vulnerabilities that are organically present in software design (Mead et al., 2009). These are the inherent flaws of any software product that cannot be removed out of the equation without completely destroying the system. The existence of such weaknesses is a necessary evil, and they cannot be fully eliminated, only mitigated. An example of an intrinsic vulnerability is the existence of data storage that is necessary for numerous applications that have to deal with databases. Eliminating such a weakness completely through software means is impossible, as the existence of a centralized database is necessary for the entire system to operate. The solution to such a vulnerability could involve installing the database on a separate computer with no access to the Internet (Thakur, n.d.). There have been examples of such an intrinsic vulnerability being exploited in the past. The latest cyber-attack on a corporate database happened in 2017 when hackers have accessed Deloitte’s customer data (Hopkins, 2017).
Non-intrinsic vulnerabilities, on the other hand, are identified as vulnerabilities that can be effectively counteracted by designing around them or building them out during the software development process (Mead et al., 2009). An example of a non-intrinsic vulnerability would be the possibility of unauthorized access, which could be countered by the installation of an identification subroutine in order to ensure that only authorized users have access to the software.
Risk Management and the SDLC
As it is the case with any other product or service, customers tend to require assurances that the product will work as intended and will not cause harm to their work or the enterprise. However, every product comes with certain risks that are inbuilt into the system (Singer & Friedman, 2014). Nevertheless, the customer still has the right to know what all of the identifiable risks the product inherently represents (Bingchang, Liang, Zhuhua, & Min, 2012). This statement lies at the foundation of software assurance, as well as risk management and cost-efficiency analysis techniques. As a rule, software assurances cover only the non-intrinsic and nonfunctional vulnerabilities that may exist in the developed software. These assurances state that the end product is free from all and any known preventable vulnerabilities that may have been added to the product during any of the five stages of SDLC. This portion of the risk analysis deals with known preventable vulnerabilities (Mead, 2014).
However, when it comes to intrinsic vulnerabilities, the customer needs to be informed about the potential setbacks and ways of mitigating the risks. In addition, the seriousness of the risk must be assessed, in order to determine the most cost-efficient manner of mitigating said risks. Sometimes, a balance must be found between software vulnerability and software cost-efficiency (“Understanding technology costs,” n.d.). A minor system within the software could be left vulnerable if the consequences of it being compromised do not outweigh the costs of protecting and maintaining it. A good example of such a method would involve assessing the costs of constantly maintaining a protective subroutine versus estimating approximate times between software failures and calculating the costs and consequences of repairing said failure.
There are four categories of measures, through which a cost-efficiency analysis and risk analysis could be evaluated (Mead et al., 2009). These measures are financial perspective measures, customer perspective measures, operational perspective measures, and growth perspective measures. After all known intrinsic and non-intrinsic weaknesses are identified, it is important to classify all known vulnerabilities to these four categories and analyze them both separately and in conjunction with one another. Depending on the severity of the risk, software functionality may have to be diminished or expanded, should the inherent risks found in it be considered acceptable.
Conclusions
No software comes without any inherent risks put into its code or functioning. The SDLC framework is vulnerable to certain risks during every stage of software development. The understanding of what intrinsic and non-intrinsic weaknesses are present in the software, as well as the cost-efficiency of counteracting said risks, is the basis behind resilient and cost-efficient software security.
References
Bingchang, L., Liang, S., Zhuhua, C., & Min, L. (2012). Software vulnerability discovery techniques: A survey. Multimedia Information Networking and Security, 2012, 37-45.
Hijazi, H., Alqrainy, S., Muaidi, H., & Khdour, T. (2014). Risk factors in software development phases. European Scientific Journal, 10(3), 213-232.
Hopkins, N. (2017). Deloitte hit by cyber-attack revealing clients’ secret emails.The Guardian. Web.
Mead, N. (2014). Seven principles for software assurance. Web.
Mead, N. R., Allen, J. H., Conklin, W. A., Drommi, A., Harrison, J., Ingalsbe, J., Shoemaker, D. (2009). Making the business case for software assurance.Web.
Singer, P. W., & Friedman, A. (2014). Cybersecurity and cyberwar: What everyone needs to know. Oxford, England: Oxford University Press.
Thakur, D. (n.d.). What is importance, levels, requirement of security in database environment? Web.
Understanding technology costs. (n.d.). Web.