Jump to content

Vulnerability (computer security): Difference between revisions

From Wikipedia, the free encyclopedia
Browse history interactively
← Previous editNext edit →
Content deleted Content added
VisualWikitext
m Restored due to unconstructive edits
Tags: Visual edit Mobile edit Mobile web edit
→‎External links: recovered categories
(2 intermediate revisions by 2 users not shown)
Line 1: Line 1:
{{short description|Exploitable weakness in a computer system}}
{{short description|Exploitable weakness in a computer system}}
{{Computer hacking}}
{{Computer hacking}}
'''Vulnerabilities''' are flaws in a computer system that weaken the overall security of the system.
'''Vulnerabilities''' are flaws in a computer system that weaken the overall security of the device/system. Vulnerabilities can be weaknesses in either the hardware itself, or the software that runs on the hardware. Vulnerabilities can be [[Exploit (computer security)|exploited]] by a [[threat actor]], such as an attacker, to cross privilege boundaries (i.e. perform unauthorized actions) within a computer system. To exploit a vulnerability, an attacker must have at least one applicable tool or technique that can connect to a system weakness. In this frame, vulnerabilities are also known as the [[attack surface]]. Constructs in [[computer language|programming languages]] that are difficult to use properly can also manifest large numbers of vulnerabilities.


Despite intentions to achieve complete correctness, virtually all hardware and software contains bugs where the system does not behave as expected. If the bug could enable an attacker to compromise the confidentiality, integrity, or availability of system resources, it is called a vulnerability. Insecure [[software development]] practices as well as design factors such as complexity can increase the burden of vulnerabilities. There are different types most common in different components such as hardware, operating systems, and applications.
[[Vulnerability management]] is a cyclical practice that varies in theory but contains common processes which include: discover all assets, prioritize assets, assess or perform a complete vulnerability scan, report on results, remediate vulnerabilities, verify remediation - repeat. This practice generally refers to software vulnerabilities in computing systems.<ref>{{Cite web|date=2019-03-12|title=Vulnerability Management Life Cycle {{!}} NPCR {{!}} CDC|url=https://www.cdc.gov/cancer/npcr/tools/security/vmlc.htm|access-date=2020-07-04|website=www.cdc.gov|language=en-us}}</ref> Agile vulnerability management refers to preventing attacks by identifying all vulnerabilities as quickly as possible.<ref>{{Cite book|last1=Ding|first1=Aaron Yi|last2=De Jesus|first2=Gianluca Limon|last3=Janssen|first3=Marijn|title=Proceedings of the Eighth International Conference on Telecommunications and Remote Sensing |chapter=Ethical hacking for boosting IoT vulnerability management |date=2019|chapter-url=http://dl.acm.org/citation.cfm?doid=3357767.3357774|series=Ictrs '19|language=en|location=Rhodes, Greece|publisher=ACM Press|pages=49–55|doi=10.1145/3357767.3357774|isbn=978-1-4503-7669-3|arxiv=1909.11166|s2cid=202676146}}</ref>


[[Vulnerability management]] is a process that includes identifying systems and prioritizing which are most important, scanning for vulnerabilities, and taking action to secure the system. Vulnerability management typically is a combination of remediation (fixing the vulnerability), mitigation (increasing the difficulty or reducing the danger of exploits), and accepting risks that are not economical or practical to eliminate. Vulnerabilities can be scored for risk according to the [[Common Vulnerability Scoring System]] or other systems, and added to vulnerability databases. {{as of|2023}}, there are more than 20 million vulnerabilities catalogued in the [[Common Vulnerabilities and Exposures]] (CVE) database.
A security risk is often incorrectly classified as a vulnerability. The use of vulnerability with the same meaning of risk can lead to confusion. The risk is the potential of a significant impact resulting from the exploit of a vulnerability. Then there are vulnerabilities without risk: for example when the affected [[asset (computing)|asset]] has no value. A vulnerability with one or more known instances of working and fully implemented attacks is classified as an exploitable vulnerability—a vulnerability for which an [[exploit (computer security)|exploit]] exists. The window of vulnerability is the time from when the security hole was introduced or manifested in deployed software, to when access was removed, a security fix was available/deployed, or the attacker was disabled—see [[zero-day attack]].


A vulnerability is initiated when it is introduced to into hardware or software. It becomes active and exploitable when the software or hardware containing the vulnerability is running. The vulnerability may be discovered by the vendor or a third party. Disclosing the vulnerability (as a [[software patch |patch]] or otherwise) is associated with an increased risk of compromise because attackers often move faster than patches are rolled out. Regardless of whether a patch is ever released to remediate the vulnerability, its lifecycle will eventually end when the system, or older versions of it, fall out of use.
[[Security bug]] is a narrower concept. There are vulnerabilities that are not related to software: [[Computer hardware|hardware]], site, personnel vulnerabilities are examples of vulnerabilities that are not software security bugs.


==Definitions==
==Causes ==
Despite developers' goal of delivering a product that works entirely as intended, virtually all [[software bugs|software]] and [[hardware bug|hardware]] contains bugs.{{sfn|Ablon|Bogart|2017|p=1}} If a bug creates a security risk, it is called a vulnerability.{{sfn|Ablon|Bogart|2017|p=2}}{{sfn|Daswani |Elbayadi|2021|p=25}}{{sfn|Seaman|2020|pp=47-48}} [[Software patch]]es are often released to fix identified vulnerabilities, but those that remain unknown ([[Zero-day (computing)|zero day]]s) as well as those that have not been patched are still liable for exploitation.{{sfn|Daswani |Elbayadi|2021|pp=26-27}} Vulnerabilities vary in their ability to be [[Exploit (computer security)|exploit]]ed by malicious actors,{{sfn|Ablon|Bogart|2017|p=2}} and the actual risk is dependent on the nature of the vulnerability as well as the value of the surrounding system.{{sfn|Haber |Hibbert|2018|pp=5-6}} Although some vulnerabilities can only be used for [[denial of service]] attacks, more dangerous ones allow the attacker to [[code injection|inject]] and run their own code (called [[malware]]), without the user being aware of it.{{sfn|Ablon|Bogart|2017|p=2}} Only a minority of vulnerabilities allow for [[privilege escalation]], which is necessary for more severe attacks.{{sfn|Haber |Hibbert|2018|p=6}} Without a vulnerability, the exploit cannot gain access.{{sfn|Haber |Hibbert|2018|p=10}} It is also possible for [[malware]] to be installed directly, without an exploit, if the attacker uses [[Social engineering (security)|social engineering]] or implants the malware in legitimate software that is downloaded deliberately.{{sfn|Haber |Hibbert|2018|pp=13–14}}
[[ISO/IEC 27005|ISO 27005]] defines '''vulnerability '''as:<ref name=ISO27005/>
===Design factors===
:''A weakness of an asset or group of assets that can be exploited by one or more threats,'' where an ''asset is anything that has value to the organization, its business operations, and their continuity, including information resources that support the organization's mission''<ref>British Standard Institute, Information technology -- Security techniques -- Management of the information and communications technology security -- Part 1: Concepts and models for information and communications technology security management BS ISO/IEC 13335-1-2004</ref>
Fundamental design factors that can increase the burden of vulnerabilities include:

*Complexity: Large, complex systems increase the probability of flaws and unintended [[File system permissions|access point]]s.<ref name=Vacca23>{{cite book
[[IETF]] RFC 4949 '''vulnerability''' as:<ref name="rfc4949">Internet Engineering Task Force RFC 4949 Internet Security Glossary, Version 2</ref>
:'' A flaw or weakness in a system's design, implementation, or operation and management that could be exploited to violate the system's security policy''

The [[Committee on National Security Systems]] of [[United States|United States of America]] defined '''vulnerability ''' in CNSS Instruction No. 4009 dated 26 April 2010 [[National Information Assurance Glossary]]:<ref name=CNSSI4009>{{cite web |url=http://www.cnss.gov/Assets/pdf/cnssi_4009.pdf |title=CNSS Instruction No. 4009 |archive-url=https://web.archive.org/web/20130628221207/https://www.cnss.gov/Assets/pdf/cnssi_4009.pdf |archive-date=2013-06-28 |date=26 April 2010}}</ref>
:''Vulnerability—Weakness in an information system, system security procedures, internal controls, or implementation that could be exploited by a threat source.''

Many [[NIST]] publications define '''vulnerability ''' in IT context in different publications: FISMApedia<ref>{{cite web|url=http://fismapedia.org/index.php|title=FISMApedia|work=fismapedia.org}}</ref> term<ref>{{cite web|url=http://fismapedia.org/index.php?title=Term:Vulnerability|title=Term:Vulnerability|work=fismapedia.org}}</ref> provide a list. Between them SP 800-30,<ref name=SP80030>[http://csrc.nist.gov/publications/nistpubs/800-30/sp800-30.pdf NIST SP 800-30 Risk Management Guide for Information Technology Systems]</ref> give a broader one:
:'' A flaw or weakness in system security procedures, design, implementation, or internal controls that could be exercised (accidentally triggered or intentionally exploited) and result in a security breach or a violation of the system's security policy. ''

[[ENISA]] defines '''vulnerability''' in<ref>{{cite web|url=https://www.enisa.Europa.EU/topics/threat-risk-management/risk-management/current-risk/risk-management-inventory/glossary#G52|title=Glossary|work=europa.eu}}</ref> as:
:'' The existence of a weakness, design, or implementation error that can lead to an unexpected, undesirable event [G.11] compromising the security of the computer system, network, application, or protocol involved.(ITSEC)''

[[The Open Group]] defines '''vulnerability''' in<ref>Technical Standard Risk Taxonomy {{ISBN|1-931624-77-1}} Document Number: C081 Published by The Open Group, January 2009.</ref> as
:''The probability that threat capability exceeds the ability to resist the threat''.

[[Factor Analysis of Information Risk]] (FAIR) defines '''vulnerability''' as:<ref name=FAIR>[http://www.riskmanagementinsight.com/media/docs/FAIR_introduction.pdf "An Introduction to Factor Analysis of Information Risk (FAIR)", Risk Management Insight LLC, November 2006] {{webarchive|url=https://web.archive.org/web/20141118061526/http://www.riskmanagementinsight.com/media/docs/FAIR_introduction.pdf |date=2014-11-18 }};</ref>
:''The probability that an asset will be unable to resist the actions of a threat agent''

According to FAIR vulnerability is related to Control Strength, i.e. the strength of control as compared to a standard measure of force and the [[threat (computer)|threat]] Capabilities, i.e. the probable level of force that a threat agent is capable of applying against an asset.

[[ISACA]] defines '''vulnerability''' in [[Risk It]] framework as:
:''A weakness in design, implementation, operation or internal control''

Data and Computer Security: Dictionary of standards concepts and terms, authors Dennis Longley and Michael Shain, Stockton Press, {{ISBN|0-935859-17-9}}, defines '''vulnerability''' as:
:''1) In computer security, a weakness in automated systems security procedures, administrative controls, Internet controls, etc., that could be exploited by a threat to gain unauthorized access to information or to disrupt critical processing. 2) In computer security, a weakness in the physical layout, organization, procedures, personnel, management, administration, hardware or software that may be exploited to cause harm to the ADP system or activity. 3) In computer security, any weakness or flaw existing in a system. The attack or harmful event, or the opportunity available to a threat agent to mount that attack.''
Matt Bishop and Dave Bailey<ref>Matt Bishop and Dave Bailey. A Critical Analysis of Vulnerability Taxonomies. Technical Report CSE-96-11, Department of Computer Science at the University of California at Davis, September 1996</ref> give the following definition of computer '''vulnerability''':
:''A computer system is composed of states describing the current configuration of the entities that make up the computer system. The system computes through the application of state transitions that change the state of the system. All states reachable from a given initial state using a set of state transitions fall into the class of authorized or unauthorized, as defined by a security policy. In this paper, the definitions of these classes and transitions is considered axiomatic. A vulnerable state is an authorized state from which an unauthorized state can be reached using authorized state transitions. A compromised state is the state so reached. An attack is a sequence of authorized state transitions which end in a compromised state. By definition, an attack begins in a vulnerable state. A vulnerability is a characterization of a vulnerable state which distinguishes it from all non-vulnerable states. If generic, the vulnerability may characterize many vulnerable states; if specific, it may characterize only one...''
[[National Information Assurance Training and Education Center]] defines '''vulnerability''':<ref>Schou, Corey (1996). Handbook of INFOSEC Terms, Version 2.0. CD-ROM (Idaho State University & Information Systems Security Organization)</ref><ref>[http://niatec.info/Glossary.aspx?term=6018&alpha=V NIATEC Glossary]</ref>

:''A weakness in automated system security procedures, administrative controls, internal controls, and so forth, that could be exploited by a threat to gain unauthorized access to information or disrupt critical processing. 2. A weakness in system security procedures, hardware design, internal controls, etc. , which could be exploited to gain unauthorized access to classified or sensitive information. 3. A weakness in the physical layout, organization, procedures, personnel, management, administration, hardware, or software that may be exploited to cause harm to the ADP system or activity. The presence of a vulnerability does not in itself cause harm; a vulnerability is merely a condition or set of conditions that may allow the ADP system or activity to be harmed by an attack. 4. An assertion primarily concerning entities of the internal environment (assets); we say that an asset (or class of assets) is vulnerable (in some way, possibly involving an agent or collection of agents); we write: V(i,e) where: e may be an empty set. 5. Susceptibility to various threats. 6. A set of properties of a specific internal entity that, in union with a set of properties of a specific external entity, implies a risk. 7. The characteristics of a system which cause it to suffer a definite degradation (incapability to perform the designated mission) as a result of having been subjected to a certain level of effects in an unnatural (manmade) hostile environment.''

==Vulnerability and risk factor models==

A resource (either physical or logical) may have one or more vulnerabilities that can be exploited by a threat actor. The result can potentially compromise the [[confidentiality]], [[integrity]] or [[availability]] of resources (not necessarily the vulnerable one) belonging to an organization and/or other parties involved (customers, suppliers). The so-called [[CIA triad]] is a cornerstone of [[Information Security]].

An attack can be ''active'' when it attempts to alter system resources or affect their operation, compromising integrity or availability. A "''passive attack''" attempts to learn or make use of information from the system but does not affect system resources, compromising confidentiality.<ref name=rfc4949/>

[[File:2010-T10-ArchitectureDiagram.png|thumb|OWASP: relationship between threat agent and business impact]]
[[OWASP]] (see figure) depicts the same phenomenon in slightly different terms: a threat agent through an attack vector exploits a weakness (vulnerability) of the system and the related security controls, causing a technical impact on an IT resource (asset) connected to a business impact.

The overall picture represents the [[Risk factor (computing)|risk factors]] of the risk scenario.<ref>[http://www.isaca.org/Knowledge-Center/Research/Documents/RiskIT-FW-18Nov09-Research.pdf ISACA THE RISK IT FRAMEWORK (registration required)] {{webarchive |url=https://web.archive.org/web/20100705110913/http://www.isaca.org/Knowledge-Center/Research/Documents/RiskIT-FW-18Nov09-Research.pdf |date=July 5, 2010 }}</ref>

==Information security management system==
A set of policies concerned with the [[information security management system]] (ISMS), has been developed to manage, according to [[Risk management]] principles, the [[Countermeasure (computer)|countermeasures]] to ensure a security strategy is set up following the rules and regulations applicable to a given organization. These countermeasures are also called [[Security controls]], but when applied to the transmission of information, they are called [[Security service (telecommunication)|security services]].<ref name=Vacca>{{cite book
|last1= Wright
|first1=Joe
|first2 = Jim | last2 = Harmening
|editor-last=Vacca
|editor-first=John
|title=Computer and Information Security Handbook
|series=Morgan Kaufmann Publications
|year=2009
|publisher= Elsevier Inc
|isbn= 978-0-12-374354-1
|page=257
|chapter=15
}}
</ref>

==Classification==
Vulnerabilities are classified according to the asset class they are related to:<ref name=ISO27005>ISO/IEC, "Information technology -- Security techniques-Information security risk management" ISO/IEC FIDIS 27005:2008</ref>
* hardware
** susceptibility to humidity or dust
** susceptibility to unprotected storage
** age-based wear that causes failure
** over-heating
* software
** insufficient testing
** insecure coding
** lack of [[audit trail]]
** design flaw
* network
** unprotected communication lines (e.g. lack of [[cryptography]])
** insecure [[network architecture]]
* personnel
** inadequate recruiting process
** inadequate [[security awareness]]
** insider threat
* physical site
** area subject to natural disasters (e.g. flood, earthquake)
** interruption of power source
* organizational
** lack of regular audits
** lack of continuity plans
** lack of security

==Causes==

*Complexity: Large, complex systems increase the probability of flaws and unintended [[File system permissions|access point]]s.<ref name=Vacca23/>
*Familiarity: Using common, well-known code, software, operating systems, and/or hardware increases the probability an attacker has or can find the knowledge and tools to exploit the flaw.<ref>{{cite book | title = Technical Report CSD-TR-97-026 | first = Ivan | last = Krsul | publisher = The COAST Laboratory Department of Computer Sciences, Purdue University | date = April 15, 1997 | citeseerx = 10.1.1.26.5435 }}</ref>
*Connectivity: More physical connections, privileges, ports, protocols, and services and time each of those are accessible increase vulnerability.<ref name=FAIR/>
*Password management flaws: The computer user uses [[Password strength|weak passwords]] that could be discovered by brute force.<ref>{{Cite news|url=https://www.theregister.co.uk/2017/01/16/123456_is_still_the_worlds_most_popular_password/|title=Just give up: 123456 is still the world's most popular password|last=Pauli|first=Darren|date=16 January 2017|work=The Register|access-date=2017-01-17}}</ref> The computer user stores the password on the computer where a program can access it. Users re-use passwords between many programs and websites.<ref name=Vacca23>{{cite book
|last= Kakareka
|last= Kakareka
|first=Almantas
|first=Almantas
Line 118: Line 27:
}}
}}
</ref>
</ref>
*Familiarity: Using common, well-known code, software, operating systems, and/or hardware increases the probability an attacker has or can find the knowledge and tools to exploit the flaw.<ref>{{cite book | title = Technical Report CSD-TR-97-026 | first = Ivan | last = Krsul | publisher = The COAST Laboratory Department of Computer Sciences, Purdue University | date = April 15, 1997 | citeseerx = 10.1.1.26.5435 }}</ref>
*Connectivity: any system connected to the internet can be accessed and compromised. [[Air gap (networking)|Disconnecting systems from the internet]] is one truly effective measure against attacks, but it is rarely feasible.{{sfn|Linkov|Kott|2019|p=2}}
*[[Legacy software]] and [[legacy hardware|hardware]] is at increased risk, but upgrading often is prohibitive in terms of cost and [[downtime]].{{sfn|Haber |Hibbert|2018|p=155}}
===Development factors===
Some [[software development]] practices can affect the risk of vulnerabilities being introduced to a code base. Lack of knowledge about secure software development or excessive pressure to deliver features quickly can lead to avoidable vulnerabilities to enter production code, especially if security is not prioritized by the [[company culture]]. This can lead to unintended vulnerabilities. The more complex the system is, the easier it is for vulnerabilities to go undetected. Some vulnerabilities are deliberately planted, which could be for any reason from a disgruntled employee selling access to hackers, to sophisticated state-sponsored schemes to introduce vulnerabilities to software.{{sfn|Strout|2023|p=17}} Inadequate [[code review]]s can lead to missed bugs, but there are also [[Static application security testing|static code analysis]] tools that can be used as part of code reviews and may find some vulnerabilities.{{sfn|Haber |Hibbert|2018|p=143}}


[[DevOps]], a development workflow that emphasizes automated testing and deployment to speed up the deployment of new features, often requires that many developers be granted access to change configurations, which can lead to deliberate or inadvertent inclusion of vulnerabilities.{{sfn|Haber |Hibbert|2018|p=141}} Compartmentalizing dependencies, which is often part of DevOps workflows, can reduce the [[attack surface]] by paring down dependencies to only what is necessary.{{sfn|Haber |Hibbert|2018|p=142}} If [[software as a service]] is used, rather than the organization's own hardware and software, the organization is dependent on the cloud services provider to prevent vulnerabilities.{{sfn|Haber |Hibbert|2018|pp=135-137}}
*Fundamental [[operating system]] design flaws: The operating system designer chooses to enforce suboptimal policies on user/program management. For example, operating systems with policies such as [[default permit]] grant every program and every user full access to the entire computer.<ref name=Vacca23/> This operating system flaw allows viruses and malware to execute commands on behalf of the administrator.<ref>{{cite web|url=http://www.ranum.com/security/computer_security/editorials/dumb/|title=The Six Dumbest Ideas in Computer Security|work=ranum.com}}</ref>
===National Vulnerability Database classification===
*Internet Website Browsing: Some internet websites may contain harmful [[Spyware]] or [[Adware]] that can be installed automatically on the computer systems. After visiting those websites, the computer systems become infected and personal information will be collected and passed on to third party individuals.<ref>{{cite web|url=http://projects.webappsec.org/w/page/13246989/Web-Application-Security-Statistics#APPENDIX2ADDITIONALVULNERABILITYCLASSIFICATION|title=The Web Application Security Consortium / Web Application Security Statistics|work=webappsec.org}}</ref>
The [[National Vulnerability Database]] classifies vulnerabilities into eight root causes that may be overlapping, including:{{sfn|Garg|Baliyan|2023|pp=17–18}}
*[[Software bug]]s: The programmer leaves an exploitable bug in a software program. The software bug may allow an attacker to misuse an application.<ref name=Vacca23/>
#[[Improper input validation|Input validation]] (including [[buffer overflow]] and [[boundary condition]]) vulnerabilities occur when [[input checking]] is not sufficient to prevent the attacker from injecting malicious code.{{sfn|Garg|Baliyan|2023|p=17}}
*[[Unchecked user input]]: The program assumes that all user input is safe. Programs that do not check user input can allow unintended direct execution of commands or SQL statements (known as [[Buffer overflow]]s, [[SQL injection]] or other non-validated inputs).<ref name=Vacca23/>
# [[Access control]] vulnerabilities enable an attacker to access a system that is supposed to be restricted to them, or engage in [[privilege escalation]].{{sfn|Garg|Baliyan|2023|p=17}}
*Not learning from past mistakes:<ref>Ross Anderson. Why Cryptosystems Fail. Technical report, University Computer Laboratory, Cambridge, January 1994.</ref><ref>Neil Schlager. When Technology Fails: Significant Technological Disasters, Accidents, and Failures of
#When the system fails to handle and exceptional or unanticipated condition correctly, an attacker can exploit the situation to gain access.{{sfn|Garg|Baliyan|2023|p=18}}
the Twentieth Century. Gale Research Inc., 1994.</ref> for example most vulnerabilities discovered in [[IPv4]] protocol software were discovered in the new [[IPv6]] implementations.<ref>[[Hacking: The Art of Exploitation Second Edition]]</ref>
#A [[configuration vulnerability]] comes into existence when configuration settings cause risks to the system security, leading to such faults as unpatched software or file system permissions that do not sufficiently restrict access.{{sfn|Garg|Baliyan|2023|p=18}}
The research has shown that the most vulnerable point in most information systems is the human user, operator, designer, or other human:<ref>
#A [[race condition]]—when timing or other external factors change the outcome and lead to inconsistent or unpredictable results—can cause a vulnerability.{{sfn|Garg|Baliyan|2023|p=18}}
{{cite book |last1=Kiountouzis |first1= E. A.|last2= Kokolakis |first2=S. A. |title=Information systems security: facing the information society of the 21st century |date= 31 May 1996|publisher=[[Chapman & Hall]], Ltd |location= London|isbn=0-412-78120-4 }}</ref> so humans should be considered in their different roles as asset, threat, information resources. [[Social engineering (security)|Social engineering]] is an increasing security concern.
==Vulnerabilities by component==
===Hardware ===
{{main |Hardware security bug}}
Deliberate security bugs can be introduced during or after manufacturing and cause the [[integrated circuit]] not to behave as expected under certain specific circumstances. Testing for security bugs in hardware is quite difficult due to limited time and the complexity of twenty-first century chips,{{sfn|Salmani|2018|p=1}} while the globalization of design and manufacturing has increased the opportunity for these bugs to be introduced by malicious actors.{{sfn|Salmani|2018|p=11}}
===Operating system ===
{{see also|Operating system#Security}}
Although [[operating system vulnerabilities]] vary depending on the [[operating system]] in use, a common problem is [[privilege escalation]] bugs that enable the attacker to gain more access than they should be allowed. [[Open-source]] operating systems such as [[Linux]] and [[Android]] have a freely accessible [[source code]] and allow anyone to contribute, which could enable the introduction of vulnerabilities. However, the same vulnerabilities also occur in proprietary operating systems such as [[Microsoft Windows]] and [[List of Apple operating systems|Apple operating systems]].{{sfn|Garg|Baliyan|2023|pp=20-25}} All reputable vendors of operating systems provide patches regularly.{{sfn |Sharp|2024|p=271}}


===Client–server applications===
==Consequences==
[[Client–server model |Client–server application]]s are downloaded onto the end user's computers and are typically updated less frequently than web applications. Unlike web applications, they interact directly with a user's [[operating system]]. Common vulnerabilities in these applications include:{{sfn |Strout |2023|p=15}}
The impact of a security breach can be very high.<ref name=TD>{{cite web|last=Rasmussen|first=Jeremy|title=Best Practices for Cybersecurity: Stay Cyber SMART|work=Tech Decisions|date=February 12, 2018|url=https://mytechdecisions.com/network-security/best-practices-cybersecurity-stay-cyber-smart/|access-date=September 18, 2020}}</ref> Most legislation sees the failure of IT managers to address IT systems and applications vulnerabilities if they are known to them as misconduct; IT managers have a responsibility to manage [[IT risk]].<ref>{{Cite web|title=What is a vulnerability? - Knowledgebase - ICTEA|url=https://www.ictea.com/cs/knowledgebase.php?action=displayarticle&id=2092&language=english|access-date=2021-04-03|website=www.ictea.com}}</ref> [[Privacy law]] forces managers to act to reduce the impact or likelihood of that security risk. [[Information technology security audit]] is a way to let other independent people certify that the IT environment is managed properly and lessen the responsibilities, at least having demonstrated good faith. [[Penetration test]] is a form of verification of the weakness and countermeasures adopted by an organisation: a [[White hat (computer security)|White hat]] hacker tries to attack an organisation's information technology assets, to find out how easy or difficult it is to compromise the IT security.<ref name=Vacca22>{{cite book
*Unencrypted data that is in permanent storage or sent over a network is relatively easy for attackers to steal.{{sfn |Strout |2023|p=15}}
|last= Bavisi
*[[Process hijacking]] occurs when an attacker takes over an existing [[computer process]].{{sfn |Strout |2023|p=15}}
|first=Sanjay
===Web applications===
|editor-last=Vacca
[[Web applications]] run on many websites. Because they are inherently less secure than other applications, they are a leading source of [[data breach]]es and other security incidents.{{sfn |Strout |2023|p=13}}{{sfn|Haber |Hibbert|2018|p=129}} Common types of vulnerabilities found in these applications include:
|editor-first=John
*[[Authentication]] and [[authorization]] failures enable attackers to access data that should be restricted to trusted users.{{sfn |Strout |2023|p=13}}
|title=Computer and Information Security Handbook
*[[Cross-site scripting]] (XSS) enables attackers to [[code injection|inject]] and run [[JavaScript]]-based [[malware]] when [[input checking]] is insufficient to reject the injected code.{{sfn |Strout |2023|p=13}} XSS can be persistent, when attackers save the malware in a data field and run it when the data is loaded; it can also be loaded using a malicious [[URL]] link (reflected XSS).{{sfn |Strout |2023|p=13}} Attackers can also insert malicious code into the [[domain object model]].{{sfn |Strout |2023|p=14}}
|series=Morgan Kaufmann Publications
*[[SQL injection]] and similar attacks manipulate [[database queries]] to gain unauthorized access to data.{{sfn |Strout |2023|p=14}}
|year=2009
*[[Command injection]] is a form of code injection where the attacker places the malware in data fields or [[process]]es. The attacker might be able to take over the entire server.{{sfn |Strout |2023|p=14}}
|publisher= Elsevier Inc
*[[Cross-site request forgery]] (CSRF) is creating client requests that do malicious actions, such as an attacker changing a user's credentials.{{sfn |Strout |2023|p=14}}
|isbn= 978-0-12-374354-1
*[[Server-side request forgery]] is similar to CSRF, but the request is forged from the server side and often exploits the enhanced privilege of the server.{{sfn |Strout |2023|p=14}}
|page=375
*[[Business logic vulnerability]] occurs when programmers do not consider unexpected cases arising in [[business logic]].{{sfn |Strout |2023|pp=14-15}}
|chapter=22
==Management ==
}}
{{main |Vulnerability management}}
</ref> The proper way to professionally manage IT risk is to adopt an Information Security Management System, such as [[ISO/IEC 27002]] or [[Risk IT]] and follow it, according to the security strategy set forth by the upper management.<ref name="Vacca"/>


There is little evidence about the effectiveness and cost-effectiveness of different cyberattack prevention measures.{{sfn|Agrafiotis ''et al.''|2018|p=2}} Although estimating the risk of an attack is not straightforward, the mean time to breach and expected cost can be considered to determine the priority for remediating or mitigating an identified vulnerability and whether it is cost effective to do so.{{sfn|Haber |Hibbert|2018 |pp=97-98}} Although attention to security can reduce the risk of attack, achieving perfect security for a complex system is impossible, and many security measures have unacceptable cost or usability downsides.{{sfn |Tjoa ''et al.''|2024|p=63}} For example, reducing the complexity and functionality of the system is effective at reducing the [[attack surface]].{{sfn |Tjoa ''et al.''|2024|pp=68, 70}}
One of the key concepts of information security is the principle of [[defence in depth]], i.e. to set up a multilayer defence system that can:<ref name=TD />
* prevent the exploit
* detect and intercept the attack
* find out the threat agents and prosecute them
[[Intrusion detection system]] is an example of a class of systems used to detect [[attack (computing)|attacks]].


Successful vulnerability management usually involves a combination of remediation (closing a vulnerability), mitigation (increasing the difficulty, and reducing the consequences, of exploits), and accepting some residual risk. Often a [[defense in depth]] strategy is used for multiple barriers to attack.{{sfn |Magnusson |2020|p=34}} Some organizations scan for only the highest-risk vulnerabilities as this enables prioritization in the context of lacking the resources to fix every vulnerability.{{sfn|Haber |Hibbert|2018|pp=166-167}} Increasing expenses is likely to have [[diminishing returns]].{{sfn|Haber |Hibbert|2018 |pp=97-98}}
[[Physical security]] is a set of measures to physically protect an information asset: if somebody can get physical access to the asset, it is widely accepted that an attacker can access any information on it or make the resource unavailable to its legitimate users.
===Remediation===
Remediation fixes vulnerabilities, for example by downloading a [[software patch]].{{sfn|Haber |Hibbert|2018|p=11}} [[Software vulnerability scanner]]s are typically unable to detect zero-day vulnerabilities, but are more effective at finding known vulnerabilities based on a database. These systems can find some known vulnerabilities and advise fixes, such as a patch.{{sfn |Strout |2023|p=8}}{{sfn|Haber |Hibbert|2018|pp=12-13}} However, they have limitations including [[false positive]]s.{{sfn|Haber |Hibbert|2018|p=11}}


Vulnerabilities can only be exploited when they are active-the software in which they are embedded is actively running on the system.{{sfn|Haber |Hibbert|2018|p=84}} Before the code containing the vulnerability is configured to run on the system, it is considered a carrier.{{sfn|Haber |Hibbert|2018|p=85}} Dormant vulnerabilities can run, but are not currently running. Software containing dormant and carrier vulnerabilities can sometimes be uninstalled or disabled, removing the risk.{{sfn|Haber |Hibbert|2018|pp=84-85}} Active vulnerabilities, if distinguished from the other types, can be prioritized for patching.{{sfn|Haber |Hibbert|2018|p=84}}
Some sets of criteria to be satisfied by a computer, its operating system and applications to meet a good security level have been developed: [[ITSEC]] and [[Common criteria]] are two examples.
===Mitigation===
Vulnerability mitigation is measures that do not close the vulnerability, but make it more difficult to exploit or reduce the consequences of an attack.{{sfn |Magnusson |2020|p=32}} Reducing the [[attack surface]], particularly for parts of the system with [[root (computing)|root]] (administrator) access, and closing off opportunities for exploits to engage in [[privilege exploitation]] is a common strategy for reducing the harm that a cyberattack can cause.{{sfn|Haber |Hibbert|2018|p=11}} If a patch for third-party software is unavailable, it may be possible to temporarily disable the software.{{sfn |Magnusson |2020|p=33}}


===Testing ===
==Vulnerability disclosure==
A [[penetration test]] attempts to enter the system via an exploit to see if the system is insecure.{{sfn|Haber |Hibbert|2018|p=93}} If a penetration test fails, it does not necessarily mean that the system is secure.{{sfn|Haber |Hibbert|2018|p=96}} Some penetration tests can be conducted with automated software that tests against existing exploits for known vulnerabilities.{{sfn|Haber |Hibbert|2018|p=94}} Other penetration tests are conducted by trained hackers. Many companies prefer to contract out this work as it simulates an outsider attack.{{sfn|Haber |Hibbert|2018|p=96}}
[[Coordinated vulnerability disclosure|Coordinated disclosure]] (some refer to it as "responsible disclosure" but that is considered a biased term by others) of vulnerabilities is a topic of great debate. As reported by The Tech Herald in August 2010, "[[Google]], [[Microsoft]], [[TippingPoint]], and [[Rapid7]] have issued guidelines and statements addressing how they will deal with disclosure going forward."<ref>{{cite web|url=http://www.thetechherald.com/article.php/201033/6025/The-new-era-of-vulnerability-disclosure-a-brief-chat-with-HD-Moore|title=The new era of vulnerability disclosure - a brief chat with HD Moore|work=The Tech Herald|access-date=2010-08-24|archive-url=https://web.archive.org/web/20100826235806/http://www.thetechherald.com/article.php/201033/6025/The-new-era-of-vulnerability-disclosure-a-brief-chat-with-HD-Moore|archive-date=2010-08-26|url-status=dead}}</ref> The other method is typically [[Full disclosure (computer security)|full disclosure]], when all the details of a vulnerability is publicized, sometimes with the intent to put pressure on the software author to publish a fix more quickly. In January 2014 when Google revealed a Microsoft vulnerability before Microsoft released a patch to fix it, a Microsoft representative called for coordinated practices among software companies in revealing disclosures.<ref>{{cite web |url= http://blogs.technet.com/b/msrc/archive/2015/01/11/a-call-for-better-coordinated-vulnerability-disclosure.aspx |title=A Call for Better Coordinated Vulnerability Disclosure - MSRC - Site Home - TechNet Blogs |first=Chris |last=Betz |work=blogs.technet.com |date=11 Jan 2015 |access-date=12 January 2015}}</ref>


===Vulnerability inventory===
== Vulnerability lifecycle ==
[[File:Vulnerability timeline.png|thumb|Vulnerability timeline|upright=1.2]]
[[Mitre Corporation]] maintains an incomplete list of publicly disclosed vulnerabilities in a system called [[Common Vulnerabilities and Exposures]]. This information is immediately shared with the [[National Institute of Standards and Technology]] (NIST), where each vulnerability is given a risk score using [[Common Vulnerability Scoring System]] (CVSS), [[Common Platform Enumeration]] (CPE) scheme, and [[Common Weakness Enumeration]].
The vulnerability lifecycle begins when vulnerabilities are introduced into hardware or software.{{sfn|Strout|2023|p=16}} Detection of vulnerabilities can be by the software vendor, or by a third party. In the latter case, it is considered most ethical to immediately disclose the vulnerability to the vendor so it can be fixed.{{sfn|Strout|2023|p=18}} Government or intelligence agencies buy vulnerabilities that have not been publicly disclosed and may use them in an attack, stockpile them, or notify the vendor.{{sfn| Libicki|Ablon|Webb|2015|p=44}} As of 2013, the [[Five Eyes]] (United States, United Kingdom, Canada, Australia, and New Zealand) captured the plurality of the market and other significant purchasers included Russia, India, Brazil, Malaysia, Singapore, North Korea, and Iran.{{sfn |Perlroth |2021 |p=145}} Organized criminal groups also buy vulnerabilities, although they typically prefer [[exploit kit]]s.{{sfn| Libicki|Ablon|Webb|2015|pp=44, 46}}


Even vulnerabilities that are publicly known or patched are often exploitable for an extended period.{{sfn|Ablon|Bogart|2017|p=8}}{{sfn|Sood|Enbody|2014|p=42}} Security patches can take months to develop,{{sfn|Strout|2023|p=26}} or may never be developed.{{sfn|Sood|Enbody|2014|p=42}} A patch can have negative effects on the functionality of software{{sfn|Sood|Enbody|2014|p=42}} and users may need to [[software testing|test]] the patch to confirm functionality and compatibility.{{sfn| Libicki|Ablon|Webb|2015|p=50}} Larger organizations may fail to identify and patch all dependencies, while smaller enterprises and personal users may not install patches.{{sfn|Sood|Enbody|2014|p=42}} Research suggests that risk of cyberattack increases if the vulnerability is made publicly known or a patch is released.{{sfn| Libicki|Ablon|Webb|2015|pp=49–50}} Cybercriminals can [[reverse engineer]] the patch to find the underlying vulnerability and develop exploits,{{sfn|Strout|2023|p=28}} often faster than users install the patch.{{sfn| Libicki|Ablon|Webb|2015|pp=49–50}}
[[Cloud service provider|Cloud service providers]] often do not list security issues in their services using the [[Common Vulnerabilities and Exposures|CVE]] system.<ref>{{Cite web |title=Wiz launches open database to track cloud vulnerabilities |url=https://www.techtarget.com/searchsecurity/news/252522106/Wiz-launches-open-database-to-track-cloud-vulnerabilities |access-date=2022-07-20 |website=SearchSecurity |language=en}}</ref> There is currently no universal standard for [[cloud computing]] vulnerability enumeration, severity assessment, and no unified tracking mechanism.<ref>{{Cite web |last=Barth |first=Bradley |date=2022-06-08 |title=Centralized database will help standardize bug disclosure for the cloud |url=https://www.scmagazine.com/editorial/analysis/cloud-security/security-leaders-call-for-centralized-database-to-help-standardize-bug-disclosure-for-the-cloud |access-date=2022-07-20 |website=www.scmagazine.com |language=en}}</ref> The [https://www.cloudvulndb.org Open CVDB] initiative is a community-driven centralized cloud vulnerability database that catalogs CSP vulnerabilities, and lists the steps users can take to detect or prevent these issues in their own environments.<ref>{{Cite web |first1=Jai |last1=Vijayan |date=2022-06-28 |title=New Vulnerability Database Catalogs Cloud Security Issues |url=https://www.darkreading.com/cloud/new-initiative-seeks-to-shed-light-on-cloud-vulnerabilities |access-date=2022-07-20 |website=Dark Reading |language=en}}</ref>


Vulnerabilities become deprecated when the software or vulnerable versions fall out of use.{{sfn|Strout|2023|p=18}} This can take an extended period of time; in particular, industrial software may not be feasible to replace even if the manufacturer stops supporting it.{{sfn|Strout|2023|p=19}}
OWASP maintains a list of vulnerability classes with the aim of educating system designers and programmers, therefore reducing the likelihood of vulnerabilities being written unintentionally into the software.<ref>{{cite web|url=http://www.owasp.org/index.php/Category:Vulnerability|title=Category:Vulnerability|work=owasp.org}}</ref>


==Vulnerability disclosure date==
==Assessment, disclosure, and inventory ==
===Assessment ===
The time of disclosure of a vulnerability is defined differently in the security community and industry. It is most commonly referred to as "a kind of public disclosure of security information by a certain party". Usually, vulnerability information is discussed on a mailing list or published on a security web site and results in a security advisory afterward.
A commonly used scale for assessing the severity of vulnerabilities is the open-source specification [[Common Vulnerability Scoring System]] (CVSS). CVSS evaluates the possibility to exploit the vulnerability and compromise data confidentiality, availability, and integrity. It also considers the how the vulnerability could be used and how complex an exploit would need to be. The amount of access needed for exploitation and whether it could take place without user interaction are also factored in to the overall score.{{sfn |Strout |2023|pp=5-6}}{{sfn|Haber |Hibbert|2018|pp=73-74}}


===Disclosure===
The '''time of disclosure''' is the first date a security vulnerability is described on a channel where the disclosed information on the vulnerability has to fulfill the following requirement:
Someone who discovers a vulnerability may disclose it immediately ([[Full disclosure (computer security)|full disclosure]]) or wait until a patch has been developed ([[Coordinated vulnerability disclosure|responsible disclosure]], or coordinated disclosure). The former approach is praised for its transparency, but the drawback is that the risk of attack is likely to be increased after disclosure with no patch available.<ref>{{cite web |title=Ask an Ethicist: Vulnerability Disclosure |url=https://ethics.acm.org/integrity-project/ask-an-ethicist/ask-an-ethicist-vulnerability-disclosure/ |website=[[Association for Computing Machinery]]'s Committee on Professional Ethics |access-date=3 May 2024 |date=17 July 2018}}</ref> Some vendors pay [[bug bounty|bug bounties]] to those who report vulnerabilities to them.{{sfn|O'Harrow|2013|p=18}}{{sfn| Libicki|Ablon|Webb|2015|p=45}} Not all companies respond positively to disclosures, as they can cause legal liability and operational overhead.{{sfn|Strout|2023|p=36}} There is no law requiring disclosure of vulnerabilities.{{sfn|Haber |Hibbert|2018 |p=110}} If a vulnerability is discovered by a third party that does not disclose to the vendor or the public, it is called a [[zero-day vulnerability]], often considered the most dangerous type because fewer defenses exist.{{sfn|Strout|2023|p=22}}


===Vulnerability inventory===
* The information is freely available to the public
The most commonly used vulnerability dataset is [[Common Vulnerabilities and Exposures]] (CVE), maintained by [[Mitre Corporation]].{{sfn |Strout |2023|p=6}} {{As of |2023}}, it has over 20 million entries.{{sfn |Strout |2023|p=8}} This information is shared into other databases, including the United States' [[National Vulnerability Database]],{{sfn |Strout |2023|p=6}} where each vulnerability is given a risk score using [[Common Vulnerability Scoring System]] (CVSS), [[Common Platform Enumeration]] (CPE) scheme, and [[Common Weakness Enumeration]].{{cn|date=May 2024}} CVE and other databases typically do not track vulnerabilities in [[software as a service]] products.{{sfn |Strout |2023|p=8}} Submitting a CVE is voluntary for companies that discovered a vulnerability.{{sfn|Haber |Hibbert|2018 |p=110}}
* The vulnerability information is published by a trusted and independent channel/source
* The vulnerability has undergone analysis by experts such that risk rating information is included upon disclosure

;Identifying and removing vulnerabilities
Many software tools exist that can aid in the discovery (and sometimes removal) of vulnerabilities in a computer system. Though these tools can provide an auditor with a good overview of possible vulnerabilities present, they can not replace human judgment. Relying solely on scanners will yield false positives and a limited-scope view of the problems present in the system.

Vulnerabilities have been found in every major operating system <ref name="David Harley">{{cite web | url=https://www.welivesecurity.com/2015/03/10/operating-system-vulnerabilities-exploits-insecurity/ | title=Operating System Vulnerabilities, Exploits and Insecurity | date=10 March 2015 |access-date=15 January 2019 | author= David Harley}}</ref> including [[Microsoft Windows|Windows]], [[macOS]], various forms of [[Unix]] and [[Linux]], [[OpenVMS]], and others. The only way to reduce the chance of a vulnerability being used against a system is through constant vigilance, including careful system maintenance (e.g. applying software patches), best practices in deployment (e.g. the use of [[firewall (networking)|firewalls]] and [[access control]]s) and auditing (both during development and throughout the deployment lifecycle).

==Locations in which vulnerabilities manifest==
Vulnerabilities are related to and can manifest in:
* physical environment of the system
* the personnel (i.e. employees, management)
* administration procedures and security policy
* business operation and service delivery
* hardware including peripheral devices <ref>Most laptops vulnerable to attack via peripheral devices. http://www.sciencedaily.com/releases/2019/02/190225192119.htm Source: University of Cambridge]</ref> <ref>Exploiting Network Printers. [https://oaklandsok.github.io/papers/muller2017.pdf Institute for IT-Security, Ruhr University Bochum] </ref>
* software (i.e. on premises or in cloud)
* connectivity (i.e. communication equipment and facilities)
It is evident that a pure technical approach cannot always protect physical assets: one should have administrative procedure to let maintenance personnel to enter the facilities and people with adequate knowledge of the procedures, motivated to follow it with proper care. However, technical protections do not necessarily stop [[Social engineering (security)]] attacks.

Examples of vulnerabilities:
* an attacker finds and uses a buffer overflow weakness to install malware to then exfiltrate sensitive data;
* an attacker convinces a user to open an email message with attached malware;
* a flood damages one's computer systems installed at ground floor.

===Software vulnerabilities===<!-- New links in alphabetical order please -->
Common types of software flaws that lead to vulnerabilities include:
*[[Memory safety]] violations, such as:
**[[Buffer overflow]]s and [[Buffer over-read|over-read]]s
**[[Dangling pointer]]s
*[[Data validation|Input validation]] errors, such as:
**[[Code injection]]
**[[Cross-site scripting]] in web applications
**[[Directory traversal]]
**[[Email injection]]
**[[Format string attack]]s
**[[HTTP header injection]]
**[[HTTP response splitting]]
**[[SQL injection]]
*[[Confused deputy problem|Privilege-confusion]] bugs, such as:
**[[Clickjacking]]
**[[Cross-site request forgery]] in web applications
**[[FTP bounce attack]]
*[[Privilege escalation]]
*[[Race conditions]], such as:
**[[Symlink race]]s
**[[Time-of-check-to-time-of-use]] bugs
*[[Side-channel attack]]
**[[Timing attack]]
*[[User interface]] failures, such as:
**[[victim blaming|Blaming the Victim]] prompting a user to make a security decision without giving the user enough information to answer it<ref>[http://blog.mozilla.com/rob-sayre/2007/09/28/blaming-the-victim/] {{webarchive|url=https://web.archive.org/web/20071021201149/http://blog.mozilla.com/rob-sayre/2007/09/28/blaming-the-victim/|date=October 21, 2007}}</ref>
**[[Race condition]]s<ref>{{cite web|url=http://www.squarefree.com/2004/07/01/race-conditions-in-security-dialogs/|title=Jesse Ruderman » Race conditions in security dialogs|work=squarefree.com}}</ref><ref>{{cite web|url=http://lcamtuf.blogspot.com/2010/08/on-designing-uis-for-non-robots.html|title=lcamtuf's blog|work=lcamtuf.blogspot.com|date=16 August 2010}}</ref>
**Warning fatigue<ref>{{cite web|url=http://www.freedom-to-tinker.com/?p=459|title=Warning Fatigue|work=freedom-to-tinker.com|date=22 October 2003 }}</ref> or user conditioning.

Some set of coding guidelines have been developed and a large [[List of tools for static code analysis|number of static code analyzers]] has been used to verify that the code follows the guidelines.

==See also==


==Liability ==
* [[Browser security]]
The software vendor is usually not legally liable for the cost if a vulnerability is used in an attack, which creates an incentive to make cheaper but less secure software.{{sfn|Sloan|Warner|2019|pp=104-105}} Some companies are covered by laws, such as [[Payment Card Industry Security Standards Council|PCI]], [[HIPAA]], and [[Sarbanes-Oxley]], that place legal requirements on vulnerability management.{{sfn|Haber |Hibbert|2018 |p=111}}
* [[Computer security]]
* [[Computer emergency response team]]
* [[Information security]]
* [[Internet security]]
* [[Mobile security]]
* [[Vulnerability scanner]]
*[[Coordinated vulnerability disclosure]]
*[[Full disclosure (computer security)|Full disclosure]]


==References==
==References==
{{reflist|colwidth=30em}}
{{reflist|colwidth=30em}}
==Sources ==
{{refbegin|indent=yes}}
*{{cite book |last1=Ablon |first1=Lillian |last2=Bogart |first2=Andy |title=Zero Days, Thousands of Nights: The Life and Times of Zero-Day Vulnerabilities and Their Exploits |date=2017 |publisher=Rand Corporation |isbn=978-0-8330-9761-3 |language=en|url=https://www.rand.org/content/dam/rand/pubs/research_reports/RR1700/RR1751/RAND_RR1751.pdf}}
* {{cite journal | last=Agrafiotis | first=Ioannis | last2=Nurse | first2=Jason R C | last3=Goldsmith | first3=Michael | last4=Creese | first4=Sadie | last5=Upton | first5=David | title=A taxonomy of cyber-harms: Defining the impacts of cyber-attacks and understanding how they propagate | journal=Journal of Cybersecurity | volume=4 | issue=1 | date=2018 | issn=2057-2085 | doi=10.1093/cybsec/tyy006|ref={{sfnref|Agrafiotis et al.|2018}}}}
*{{cite book |last1=Daswani |first1=Neil|authorlink=Neil Daswani |last2=Elbayadi |first2=Moudy |title=Big Breaches: Cybersecurity Lessons for Everyone |date=2021 |publisher=Apress |isbn=978-1-4842-6654-0}}
*{{cite book |last1=Garg |first1=Shivi |last2=Baliyan |first2=Niyati |title=Mobile OS Vulnerabilities: Quantitative and Qualitative Analysis |date=2023 |publisher=CRC Press |isbn=978-1-000-92451-0 |language=en}}
*{{cite book |last1=Haber |first1=Morey J. |last2=Hibbert |first2=Brad |title=Asset Attack Vectors: Building Effective Vulnerability Management Strategies to Protect Organizations |date=2018 |publisher=Apress |isbn=978-1-4842-3627-7 |language=en}}
*{{cite book |last1=Libicki |first1=Martin C. |last2=Ablon |first2=Lillian |last3=Webb |first3=Tim|url=https://www.rand.org/content/dam/rand/pubs/research_reports/RR1000/RR1024/RAND_RR1024.pdf |title=The Defender’s Dilemma: Charting a Course Toward Cybersecurity |date=2015 |publisher=Rand Corporation |isbn=978-0-8330-8911-3 |language=en}}
*{{cite book |last1=Linkov |first1=Igor |last2=Kott |first2=Alexander |title=Cyber Resilience of Systems and Networks |date=2019 |publisher=Springer International Publishing |isbn=978-3-319-77492-3 |pages=1–25 |language=en |chapter=Fundamental Concepts of Cyber Resilience: Introduction and Overview}}
*{{cite book |last1=Magnusson |first1=Andrew |title=Practical Vulnerability Management: A Strategic Approach to Managing Cyber Risk |date=2020 |publisher=No Starch Press |isbn=978-1-59327-989-9 |language=en}}
*{{cite book |last1=O'Harrow |first1=Robert |title=Zero Day: The Threat In Cyberspace |date=2013 |publisher=Diversion Books |isbn=978-1-938120-76-3 |language=en}}
*{{cite book |last1=Perlroth |first1=Nicole |title=This Is How They Tell Me the World Ends: Winner of the FT & McKinsey Business Book of the Year Award 2021 |date=2021 |publisher=Bloomsbury Publishing |isbn=978-1-5266-2983-8 |language=en}}
*{{cite book |last1=Salmani |first1=Hassan |title=Trusted Digital Circuits: Hardware Trojan Vulnerabilities, Prevention and Detection |date=2018 |publisher=Springer |isbn=978-3-319-79081-7 |language=en}}
*{{cite book |last1=Seaman |first1=Jim |title=PCI DSS: An Integrated Data Security Standard Guide |date=2020 |publisher=Apress |isbn=978-1-4842-5808-8 |language=en}}
*{{Cite book |last=Sharp |first=Robin |url= |title=Introduction to Cybersecurity: A Multidisciplinary Challenge |date=2024 |publisher=Springer Nature |isbn=978-3-031-41463-3 |language=en}}
*{{cite book |last1=Sloan |first1=Robert H. |last2=Warner |first2=Richard |title=Why Don't We Defend Better?: Data Breaches, Risk Management, and Public Policy |date=2019 |publisher=CRC Press |isbn=978-1-351-12729-5 |language=en}}
*{{cite book |last1=Sood |first1=Aditya |last2=Enbody |first2=Richard |title=Targeted Cyber Attacks: Multi-staged Attacks Driven by Exploits and Malware |date=2014 |publisher=Syngress |isbn=978-0-12-800619-1 |language=en}}
*{{cite book |last1=Strout |first1=Benjamin |title=The Vulnerability Researcher's Handbook: A comprehensive guide to discovering, reporting, and publishing security vulnerabilities |date=2023 |publisher=Packt Publishing |isbn=978-1-80324-356-6 |language=en}}
*{{cite book |last1=Tjoa |first1=Simon |last2=Gafić |first2=Melisa |last3=Kieseberg |first3=Peter |title=Cyber Resilience Fundamentals |date=2024 |publisher=Springer Nature |isbn=978-3-031-52064-8 |language=en|ref={{sfnref|Tjoa et al.|2024}}}}
{{refend}}


==External links==
==External links==
*{{Commonscatinline}}
*{{Commonscatinline}}
* Security advisories links from the Open Directory http://dmoz-odp.org/Computers/Security/Advisories_and_Patches/


{{Information security}}
{{Information security}}

Revision as of 19:09, 9 May 2024

Part of a series on
Computer hacking
History
Hacker culture and ethic
Conferences
Computer crime
Hacking tools
Practice sites
Malware
Computer security
Groups
Publications

Vulnerabilities are flaws in a computer system that weaken the overall security of the system.

Despite intentions to achieve complete correctness, virtually all hardware and software contains bugs where the system does not behave as expected. If the bug could enable an attacker to compromise the confidentiality, integrity, or availability of system resources, it is called a vulnerability. Insecure software development practices as well as design factors such as complexity can increase the burden of vulnerabilities. There are different types most common in different components such as hardware, operating systems, and applications.

Vulnerability management is a process that includes identifying systems and prioritizing which are most important, scanning for vulnerabilities, and taking action to secure the system. Vulnerability management typically is a combination of remediation (fixing the vulnerability), mitigation (increasing the difficulty or reducing the danger of exploits), and accepting risks that are not economical or practical to eliminate. Vulnerabilities can be scored for risk according to the Common Vulnerability Scoring System or other systems, and added to vulnerability databases. As of 2023, there are more than 20 million vulnerabilities catalogued in the Common Vulnerabilities and Exposures (CVE) database.

A vulnerability is initiated when it is introduced to into hardware or software. It becomes active and exploitable when the software or hardware containing the vulnerability is running. The vulnerability may be discovered by the vendor or a third party. Disclosing the vulnerability (as a patch or otherwise) is associated with an increased risk of compromise because attackers often move faster than patches are rolled out. Regardless of whether a patch is ever released to remediate the vulnerability, its lifecycle will eventually end when the system, or older versions of it, fall out of use.

Causes

Despite developers' goal of delivering a product that works entirely as intended, virtually all software and hardware contains bugs.[1] If a bug creates a security risk, it is called a vulnerability.[2][3][4] Software patches are often released to fix identified vulnerabilities, but those that remain unknown (zero days) as well as those that have not been patched are still liable for exploitation.[5] Vulnerabilities vary in their ability to be exploited by malicious actors,[2] and the actual risk is dependent on the nature of the vulnerability as well as the value of the surrounding system.[6] Although some vulnerabilities can only be used for denial of service attacks, more dangerous ones allow the attacker to inject and run their own code (called malware), without the user being aware of it.[2] Only a minority of vulnerabilities allow for privilege escalation, which is necessary for more severe attacks.[7] Without a vulnerability, the exploit cannot gain access.[8] It is also possible for malware to be installed directly, without an exploit, if the attacker uses social engineering or implants the malware in legitimate software that is downloaded deliberately.[9]

Design factors

Fundamental design factors that can increase the burden of vulnerabilities include:

  • Complexity: Large, complex systems increase the probability of flaws and unintended access points.[10]
  • Familiarity: Using common, well-known code, software, operating systems, and/or hardware increases the probability an attacker has or can find the knowledge and tools to exploit the flaw.[11]
  • Connectivity: any system connected to the internet can be accessed and compromised. Disconnecting systems from the internet is one truly effective measure against attacks, but it is rarely feasible.[12]
  • Legacy software and hardware is at increased risk, but upgrading often is prohibitive in terms of cost and downtime.[13]

Development factors

Some software development practices can affect the risk of vulnerabilities being introduced to a code base. Lack of knowledge about secure software development or excessive pressure to deliver features quickly can lead to avoidable vulnerabilities to enter production code, especially if security is not prioritized by the company culture. This can lead to unintended vulnerabilities. The more complex the system is, the easier it is for vulnerabilities to go undetected. Some vulnerabilities are deliberately planted, which could be for any reason from a disgruntled employee selling access to hackers, to sophisticated state-sponsored schemes to introduce vulnerabilities to software.[14] Inadequate code reviews can lead to missed bugs, but there are also static code analysis tools that can be used as part of code reviews and may find some vulnerabilities.[15]

DevOps, a development workflow that emphasizes automated testing and deployment to speed up the deployment of new features, often requires that many developers be granted access to change configurations, which can lead to deliberate or inadvertent inclusion of vulnerabilities.[16] Compartmentalizing dependencies, which is often part of DevOps workflows, can reduce the attack surface by paring down dependencies to only what is necessary.[17] If software as a service is used, rather than the organization's own hardware and software, the organization is dependent on the cloud services provider to prevent vulnerabilities.[18]

National Vulnerability Database classification

The National Vulnerability Database classifies vulnerabilities into eight root causes that may be overlapping, including:[19]

  1. Input validation (including buffer overflow and boundary condition) vulnerabilities occur when input checking is not sufficient to prevent the attacker from injecting malicious code.[20]
  2. Access control vulnerabilities enable an attacker to access a system that is supposed to be restricted to them, or engage in privilege escalation.[20]
  3. When the system fails to handle and exceptional or unanticipated condition correctly, an attacker can exploit the situation to gain access.[21]
  4. A configuration vulnerability comes into existence when configuration settings cause risks to the system security, leading to such faults as unpatched software or file system permissions that do not sufficiently restrict access.[21]
  5. A race condition—when timing or other external factors change the outcome and lead to inconsistent or unpredictable results—can cause a vulnerability.[21]

Vulnerabilities by component

Hardware

Main article: Hardware security bug

Deliberate security bugs can be introduced during or after manufacturing and cause the integrated circuit not to behave as expected under certain specific circumstances. Testing for security bugs in hardware is quite difficult due to limited time and the complexity of twenty-first century chips,[22] while the globalization of design and manufacturing has increased the opportunity for these bugs to be introduced by malicious actors.[23]

Operating system

See also: Operating system § Security

Although operating system vulnerabilities vary depending on the operating system in use, a common problem is privilege escalation bugs that enable the attacker to gain more access than they should be allowed. Open-source operating systems such as Linux and Android have a freely accessible source code and allow anyone to contribute, which could enable the introduction of vulnerabilities. However, the same vulnerabilities also occur in proprietary operating systems such as Microsoft Windows and Apple operating systems.[24] All reputable vendors of operating systems provide patches regularly.[25]

Client–server applications

Client–server applications are downloaded onto the end user's computers and are typically updated less frequently than web applications. Unlike web applications, they interact directly with a user's operating system. Common vulnerabilities in these applications include:[26]

Web applications

Web applications run on many websites. Because they are inherently less secure than other applications, they are a leading source of data breaches and other security incidents.[27][28] Common types of vulnerabilities found in these applications include:

Management

Main article: Vulnerability management

There is little evidence about the effectiveness and cost-effectiveness of different cyberattack prevention measures.[31] Although estimating the risk of an attack is not straightforward, the mean time to breach and expected cost can be considered to determine the priority for remediating or mitigating an identified vulnerability and whether it is cost effective to do so.[32] Although attention to security can reduce the risk of attack, achieving perfect security for a complex system is impossible, and many security measures have unacceptable cost or usability downsides.[33] For example, reducing the complexity and functionality of the system is effective at reducing the attack surface.[34]

Successful vulnerability management usually involves a combination of remediation (closing a vulnerability), mitigation (increasing the difficulty, and reducing the consequences, of exploits), and accepting some residual risk. Often a defense in depth strategy is used for multiple barriers to attack.[35] Some organizations scan for only the highest-risk vulnerabilities as this enables prioritization in the context of lacking the resources to fix every vulnerability.[36] Increasing expenses is likely to have diminishing returns.[32]

Remediation

Remediation fixes vulnerabilities, for example by downloading a software patch.[37] Software vulnerability scanners are typically unable to detect zero-day vulnerabilities, but are more effective at finding known vulnerabilities based on a database. These systems can find some known vulnerabilities and advise fixes, such as a patch.[38][39] However, they have limitations including false positives.[37]

Vulnerabilities can only be exploited when they are active-the software in which they are embedded is actively running on the system.[40] Before the code containing the vulnerability is configured to run on the system, it is considered a carrier.[41] Dormant vulnerabilities can run, but are not currently running. Software containing dormant and carrier vulnerabilities can sometimes be uninstalled or disabled, removing the risk.[42] Active vulnerabilities, if distinguished from the other types, can be prioritized for patching.[40]

Mitigation

Vulnerability mitigation is measures that do not close the vulnerability, but make it more difficult to exploit or reduce the consequences of an attack.[43] Reducing the attack surface, particularly for parts of the system with root (administrator) access, and closing off opportunities for exploits to engage in privilege exploitation is a common strategy for reducing the harm that a cyberattack can cause.[37] If a patch for third-party software is unavailable, it may be possible to temporarily disable the software.[44]

Testing

A penetration test attempts to enter the system via an exploit to see if the system is insecure.[45] If a penetration test fails, it does not necessarily mean that the system is secure.[46] Some penetration tests can be conducted with automated software that tests against existing exploits for known vulnerabilities.[47] Other penetration tests are conducted by trained hackers. Many companies prefer to contract out this work as it simulates an outsider attack.[46]

Vulnerability lifecycle

Vulnerability timeline

The vulnerability lifecycle begins when vulnerabilities are introduced into hardware or software.[48] Detection of vulnerabilities can be by the software vendor, or by a third party. In the latter case, it is considered most ethical to immediately disclose the vulnerability to the vendor so it can be fixed.[49] Government or intelligence agencies buy vulnerabilities that have not been publicly disclosed and may use them in an attack, stockpile them, or notify the vendor.[50] As of 2013, the Five Eyes (United States, United Kingdom, Canada, Australia, and New Zealand) captured the plurality of the market and other significant purchasers included Russia, India, Brazil, Malaysia, Singapore, North Korea, and Iran.[51] Organized criminal groups also buy vulnerabilities, although they typically prefer exploit kits.[52]

Even vulnerabilities that are publicly known or patched are often exploitable for an extended period.[53][54] Security patches can take months to develop,[55] or may never be developed.[54] A patch can have negative effects on the functionality of software[54] and users may need to test the patch to confirm functionality and compatibility.[56] Larger organizations may fail to identify and patch all dependencies, while smaller enterprises and personal users may not install patches.[54] Research suggests that risk of cyberattack increases if the vulnerability is made publicly known or a patch is released.[57] Cybercriminals can reverse engineer the patch to find the underlying vulnerability and develop exploits,[58] often faster than users install the patch.[57]

Vulnerabilities become deprecated when the software or vulnerable versions fall out of use.[49] This can take an extended period of time; in particular, industrial software may not be feasible to replace even if the manufacturer stops supporting it.[59]

Assessment, disclosure, and inventory

Assessment

A commonly used scale for assessing the severity of vulnerabilities is the open-source specification Common Vulnerability Scoring System (CVSS). CVSS evaluates the possibility to exploit the vulnerability and compromise data confidentiality, availability, and integrity. It also considers the how the vulnerability could be used and how complex an exploit would need to be. The amount of access needed for exploitation and whether it could take place without user interaction are also factored in to the overall score.[60][61]

Disclosure

Someone who discovers a vulnerability may disclose it immediately (full disclosure) or wait until a patch has been developed (responsible disclosure, or coordinated disclosure). The former approach is praised for its transparency, but the drawback is that the risk of attack is likely to be increased after disclosure with no patch available.[62] Some vendors pay bug bounties to those who report vulnerabilities to them.[63][64] Not all companies respond positively to disclosures, as they can cause legal liability and operational overhead.[65] There is no law requiring disclosure of vulnerabilities.[66] If a vulnerability is discovered by a third party that does not disclose to the vendor or the public, it is called a zero-day vulnerability, often considered the most dangerous type because fewer defenses exist.[67]

Vulnerability inventory

The most commonly used vulnerability dataset is Common Vulnerabilities and Exposures (CVE), maintained by Mitre Corporation.[68] As of 2023, it has over 20 million entries.[38] This information is shared into other databases, including the United States' National Vulnerability Database,[68] where each vulnerability is given a risk score using Common Vulnerability Scoring System (CVSS), Common Platform Enumeration (CPE) scheme, and Common Weakness Enumeration.[citation needed] CVE and other databases typically do not track vulnerabilities in software as a service products.[38] Submitting a CVE is voluntary for companies that discovered a vulnerability.[66]

Liability

The software vendor is usually not legally liable for the cost if a vulnerability is used in an attack, which creates an incentive to make cheaper but less secure software.[69] Some companies are covered by laws, such as PCI, HIPAA, and Sarbanes-Oxley, that place legal requirements on vulnerability management.[70]

References

  1. ^ Ablon & Bogart 2017, p. 1.
  2. ^ a b c Ablon & Bogart 2017, p. 2.
  3. ^ Daswani & Elbayadi 2021, p. 25.
  4. ^ Seaman 2020, pp. 47–48.
  5. ^ Daswani & Elbayadi 2021, pp. 26–27.
  6. ^ Haber & Hibbert 2018, pp. 5–6.
  7. ^ Haber & Hibbert 2018, p. 6.
  8. ^ Haber & Hibbert 2018, p. 10.
  9. ^ Haber & Hibbert 2018, pp. 13–14.
  10. ^ Kakareka, Almantas (2009). "23". In Vacca, John (ed.). Computer and Information Security Handbook. Morgan Kaufmann Publications. Elsevier Inc. p. 393. ISBN 978-0-12-374354-1.
  11. ^ Krsul, Ivan (April 15, 1997). Technical Report CSD-TR-97-026. The COAST Laboratory Department of Computer Sciences, Purdue University. CiteSeerX 10.1.1.26.5435.
  12. ^ Linkov & Kott 2019, p. 2.
  13. ^ Haber & Hibbert 2018, p. 155.
  14. ^ Strout 2023, p. 17.
  15. ^ Haber & Hibbert 2018, p. 143.
  16. ^ Haber & Hibbert 2018, p. 141.
  17. ^ Haber & Hibbert 2018, p. 142.
  18. ^ Haber & Hibbert 2018, pp. 135–137.
  19. ^ Garg & Baliyan 2023, pp. 17–18.
  20. ^ a b Garg & Baliyan 2023, p. 17.
  21. ^ a b c Garg & Baliyan 2023, p. 18.
  22. ^ Salmani 2018, p. 1.
  23. ^ Salmani 2018, p. 11.
  24. ^ Garg & Baliyan 2023, pp. 20–25.
  25. ^ Sharp 2024, p. 271.
  26. ^ a b c Strout 2023, p. 15.
  27. ^ a b c d Strout 2023, p. 13.
  28. ^ Haber & Hibbert 2018, p. 129.
  29. ^ a b c d e Strout 2023, p. 14.
  30. ^ Strout 2023, pp. 14–15.
  31. ^ Agrafiotis et al. 2018, p. 2.
  32. ^ a b Haber & Hibbert 2018, pp. 97–98.
  33. ^ Tjoa et al. 2024, p. 63.
  34. ^ Tjoa et al. 2024, pp. 68, 70.
  35. ^ Magnusson 2020, p. 34.
  36. ^ Haber & Hibbert 2018, pp. 166–167.
  37. ^ a b c Haber & Hibbert 2018, p. 11.
  38. ^ a b c Strout 2023, p. 8.
  39. ^ Haber & Hibbert 2018, pp. 12–13.
  40. ^ a b Haber & Hibbert 2018, p. 84.
  41. ^ Haber & Hibbert 2018, p. 85.
  42. ^ Haber & Hibbert 2018, pp. 84–85.
  43. ^ Magnusson 2020, p. 32.
  44. ^ Magnusson 2020, p. 33.
  45. ^ Haber & Hibbert 2018, p. 93.
  46. ^ a b Haber & Hibbert 2018, p. 96.
  47. ^ Haber & Hibbert 2018, p. 94.
  48. ^ Strout 2023, p. 16.
  49. ^ a b Strout 2023, p. 18.
  50. ^ Libicki, Ablon & Webb 2015, p. 44.
  51. ^ Perlroth 2021, p. 145.
  52. ^ Libicki, Ablon & Webb 2015, pp. 44, 46.
  53. ^ Ablon & Bogart 2017, p. 8.
  54. ^ a b c d Sood & Enbody 2014, p. 42.
  55. ^ Strout 2023, p. 26.
  56. ^ Libicki, Ablon & Webb 2015, p. 50.
  57. ^ a b Libicki, Ablon & Webb 2015, pp. 49–50.
  58. ^ Strout 2023, p. 28.
  59. ^ Strout 2023, p. 19.
  60. ^ Strout 2023, pp. 5–6.
  61. ^ Haber & Hibbert 2018, pp. 73–74.
  62. ^ "Ask an Ethicist: Vulnerability Disclosure". Association for Computing Machinery's Committee on Professional Ethics. 17 July 2018. Retrieved 3 May 2024.
  63. ^ O'Harrow 2013, p. 18.
  64. ^ Libicki, Ablon & Webb 2015, p. 45.
  65. ^ Strout 2023, p. 36.
  66. ^ a b Haber & Hibbert 2018, p. 110.
  67. ^ Strout 2023, p. 22.
  68. ^ a b Strout 2023, p. 6.
  69. ^ Sloan & Warner 2019, pp. 104–105.
  70. ^ Haber & Hibbert 2018, p. 111.

Sources

Retrieved from "https://en.wikipedia.org/w/index.php?title=Vulnerability_(computer_security)&oldid=1223078225"