Open Disclosure of Software Vulnerabilities

Question: Discuss about the Open Disclosure of Software Vulnerabilities. Answer: Introduction Software vulnerability is any error that can be exploited by a hacker for compromising system or stealing data. Attacks can of different nature and can cause different levels of severity. Vulnerability once known is responded by the software developer by fixing it through release of a patch(Altinkemer, et al., 2004). Security vulnerabilities have caused a huge number of worms and viruses coming into the world and attackers exploiting these vulnerabilities are able to take some significant benefits by stealing money or confidential information about users and entities. These vulnerabilities are explored and reporting by security professionals so that remedies to counter these attacks can be found in advance to stop hackers from exploiting systems. These disclosures are made public in the marketplace which is open for all to reach. However, disclosure of security vulnerabilities on one side warn the users and software programmers to resolve them, on the other side, they also make the attackers attentive enough to act fast against vulnerabilities before they are taken care of(Cencini, et al., 2005). This paper explores different types of vulnerabilities that systems have different types of disclosures made, and different types of hackers to understand what positions they take in order to exploit the vulnerabilities as soon as they discover problems with software before their next versions could be launched. Research methods and approach Choice of research method depends on the objectives, philosophical assumptions of the researcher, availability of research data, availability of resources, availability of time, and the context of research(ML, 2004). As there is a lot of information already available on the subject of interest, thus, a secondary research would be used. Past research papers, journal articles, news articles, and academic papers would be studied and a critical analysis would be done using content analysis(Johnston, 2014). The research explored the types of vulnerabilities, the disclosure of vulnerabilities, types of hackers and the positions they take Vulnerabilities in software can be of two types including software defects that include design and coding flaws and configuration errors that include dangerous services and administrative errors. As per the Gartner study, 25% of the security attacks that become successful exploit software defects. These defects can be introduced when the design of software is unsafe. There could be instances when the software is not designed to face the exposure to the internet but when it actually happens, the software becomes vulnerable to the security threats. Such flaws should usually get discovered while performing requirement analysis, developing architecture, or while designing. If there are flaws in the software coding, it can cause issues like buffer overflow, non-random coding, and race conditions(K Telang, 2004). Configuration errors can occur when multiple software products are made to work together in such a manner that they cause vulnerabilities. As per the Gartner study, 65% of the security attacks that become successful exploit such configuration errors. At times, a software is configured in such a way that it allows those services to connect that do not meet the operational requirements of the system. This can cause malfunctioning of software(Arora, et al., 2003). Such flaws can be identified during quality assurance testing. However, subsequent changes made in software can still cause configuration errors at later stages. Configuration errors also include misconfigured access controls which can be the most dangerous threat to security in software as it let unauthorized users perform malicious activities by abusing privileges of legitimate users. Such flaws can be detected at the Quality Assurance stage but they usually appear only after the system becomes operational. Thus, it is essen tial that access policy compliance scans are regularly done(Pescatore, 2003). Vulnerabilities can also be classified on the basis of the stage of disclosure. A vulnerability can be called as secret when is never disclosed or patched. A published vulnerability is disclosed but not patched, and patched vulnerability would both be published and patched. A typical path of any kind of vulnerability goes from secret to published to patched. A research involving 2952 observations made over 9 weeks involving 328 different software vulnerabilities had found that 160 of the vulnerabilities were made public on the same day of discovery, 77 vulnerabilities had no patches made and 76 were patched later. The vulnerabilities that were published attracted 5.45 attacks every day per host while patched vulnerabilities attracted 2.5 attacks per host per day(Arora Telang, 2013). Microsoft defines a life cycle of software vulnerabilities beginning with its birth, followed by discovery, disclosure, correction, publicity, scripting, and death. Birth refers to the stage of development when the vulnerability is actually created. Vulnerabilities that are detected and then corrected before the deployment are not considered in the case. At discovery stage, a researcher or developer comes to know that the vulnerability exists in the software(Schryen, 2011). Once discovered, the vulnerability is disclosed to vendor, authority, developer or public. Vendor then analyzes the bug, fixes it, and releases the patch to the public. Once patch is released, the vulnerability is spread to public along with the patch. A tool is developed for exploitation of vulnerability in the scripting stage. After patching most systems, old systems may get retired or the exploit does not remain a subject of interest for hackers leading to the death of vulnerability(Arora, et al., 2006). Vulnerability disclosures can be classified into a few categories including non-disclosure, limited disclosure full disclosure, and responsible disclosures. When a security researcher finds out about vulnerability in software and instead of letting the information out keeps it a secret, it is an act of non-disclosure(Algarni Malaiya, 2014). The reason for non-disclosure could simply be laziness or a malicious intent to freely break into the system without having a need to implement patches. Such a hacker can share the information about vulnerability to other hacker which can compromise user security. If this happens, it can later lead to full-disclosures initiated by underground communities(Zhao, et al., 2015). When the software vulnerability is disclosed only to a limited audience and not a wider community or public, it is a limited disclosure. A small group is provided with the complete details of the vulnerability. The challenge in this type of disclosure is that it is difficult to determine who could be trusted as it is very difficult to enforce the ethical behaviour on the people it is disclosed to. The information disclosed in this type of disclosure is actually not much detailed and thus, there may not be a complete understanding of the structure of the flaw in the audience which can lead to repetition of same mistake by a developer in future. Thus, limited disclosure is often criticized y researchers(Hoskins, 2015). Full disclosure involves spreading of information to whole community with details like how it was found, what software it can affect, how it can be exploited, and how it can be protected from security attacks. This act is considered as ethical because one user is informed about the vulnerabilities through a community; they can disable the affected software in their machines to protect themselves. Such a move would also push software vendors to immediately notice the flaw and work on remedial actions. With full disclosure, the researcher also receives the credit immediately and this can be motivator security professionals(Wattal Telang, 2004). Over the years, there have been several policies proposed concerning disclosure such as full disclosure policy and vulnerability disclosure in 2000 by RFP and CERT respectively. A vulnerability disclosure framework was formed by NIAC in the year 2004. Full Disclosure policy by RFP focuses on researchers and advocates full disclosure of vulnerabilities to community. CET vulnerability disclosure suggests disclosure of vulnerability of any software to public but is against the full disclosure including details and exploit codes. The NIAC had advised building of a framework for defining the guidelines for disclosure. A disclosure policy is affected by how the participants in a disclosure respond including software vendors, hackers, and users as each of them would be affected in some way by the policy. If the disclosure is fast then the patches for filling vulnerability also comes faster from the vendor. An optimal disclosure policy can give more time to software developers to come up with patches. If patching is to be done in the real time, the vulnerability must never be disclosed except to the developers so that before a hacker identifies vulnerability, a patch can be released by the developer. If a disclosure is made instantly after discovery not followed by the launch of the patch, it can leads to a loss for the software vendor. CERT gives 45 days to developers to come up with patches before the disclosure is made public. In a typical disclosure process, a limited disclosure is done which begins with the discovery of vulnerability by a security researcher which s first communicated to the software vendor or an independent regulatory body like CERT which can later make the vulnerability public. In some cases, if full disclosure policy is used, the vulnerability can be directly disclosed to the public. This usually happens when researchers use public forums like Bugtraq for making disclosures(Telang Wattal, 2004). Three types hackers operate in the digital space each with some distinguishing characteristics and these include grey-hat hackers who are actually researchers, black hat hackers who violate the last of security to get personal gains and is often involved in selling zero-day vulnerability exploits, and white hat hackers who are ethical and use their skills for legal purposes. Grey-hat hackers when finds software vulnerability would simply disclose it without the concern of its consequences but a white hat hacker would do this disclosure to the developer so that the developer can fix the vulnerability to prevent attacks(A, 2004). The White hat and grey-hat hackers are involved in making disclosures of vulnerabilities. While grey-hat hackers use forums as platforms for disclosures, White-hat hackers are those ethical hackers that can involved by security organizations themselves to identify vulnerabilities and make limited disclosures. Vulnerability disclosure appears to be an important activity in the security space as it would make the users or developers aware of the issues and take precautions or launch fixes to remediate the security problem. Four types of disclosure approaches were found including no disclosure, limited disclosure, full disclosure, and responsible disclosure. Depending on the types of vulnerabilities and the capacity of the vendor to launch the patches would be useful in determine which approach to take. A real time patching system may require a company to not make any disclosure and directly release patches. A disclosure policy may be formulated by an organization such that the process of disclosure can be formalized and organized(SANS, 2017). There could be three possible regimes that are followed for making disclosures of vulnerabilities by software firms. A firm may choose to not disclose any of the vulnerabilities or issue any updates. Another firm may choose to disclose all vulnerabilities and release update as soon as possible after that. A firm can also adapt to an existing disclosure policy. Whatever is the policy of disclosure, it has to be communicated to the consumer at the time of the purchase of the software from the vendor(Choi, et al., 2007). Conclusions The paper explored the idea of disclosure of software vulnerabilities. The paper discussed different types of vulnerabilities, hackers, and disclosures. It was found that most companies define a policy for disclosure which can either be self-developed or adopted from security bodies like CERT. The type of disclosure to be made depends on the capacity of vendor to launch patches and the level of threat caused by vulnerability. References A, A., 2004. Whose Bug Is It Anyway? The Battle over Handling Software Flaws, s.l.: IEEE Software. Algarni, A. Malaiya, Y., 2014. Software vulnerability markets: Discoverers and buyers. International Journal of Computer, Information Science and Engineering, 8(3), pp. 71-81. Altinkemer, K., Rees, J. Sridhar, S., 2004. Vulnerabilities and Patches of Open Source Software: An Empirical Study, s.l.: Purdue University . Arora, A., Caulkins, J. Telang, R., 2003. Provision of Software Quality in the Presence of Patching Technology, s.l.: Carnegie Mellon University. Arora, A., Krishnan, R., Telang, R. Yang, Y., 2006. An Empirical Analysis of Software Vendors Patching Behavior: Impact of Vulnerability Disclosure, s.l.: Carnegie Mellon University. Arora, A. Telang, R., 2013. Economics of Software Vulnerability Disclosure , s.l.: Carnegie Mellon University. Cencini, A., Yu, K. Chan, T., 2005. Software Vulnerabilities: Full-, Responsible-, and Non-Disclosure , s.l.: University of Washington. Choi, J. P., Fershtman, C. Gandal, N., 2007. Network Security: Vulnerabilities and Disclosure Policy, s.l.: Michigan State University. Hoskins, B. N., 2015. The Rhetoric of Commoditized Vulnerabilities: Ethical Discourses in Cybersecurity , s.l.: Virginia Polytechnic Institute and State University . Johnston, M. P., 2014. Secondary Data Analysis:A Method of which the Time Has Come. Qualitative and Quantitative Methods in Libraries (QQML), Volume 3, pp. 619-626. K, K. Telang, R., 2004. Market for Software Vulnerabilities? Think Again, s.l.: Carnegie Mellon University. ML, J., 2004. Application of systematic review methods to qualitative research: practical issues., s.l.: Pub Med. Pescatore, J., 2003. Taxonomy of Software Vulnerabilities, s.l.: Gartner, Inc. SANS, 2017. How do we define Responsible Disclosure?, s.l.: SANS Institute. Schryen, G., 2011. Is open source security a myth?. Communications of the ACM, 54(5), pp. 130-140. Telang, R. Wattal, S., 2004. Impact of Software Vulnerability Announcements on the Market Value of Software Vendors an Empirical Investigation, s.l.: Heinz School of Public Policy. Wattal, S. Telang, R., 2004. Effect of Vulnerability Disclosures on Market Value of Software Vendors An Event Study Analysis , s.l.: Carnegie Mellon University . Zhao, M., Grossklags, J. Liu, P., 2015. An Empirical Study of Web Vulnerability Discovery Ecosystems, s.l.: Pennsylvania State University.