Skip to main content

Threats, Vulnerabilities and Exploits – oh my!

Threats exploits 558x388 10aug15 en

Some of the most commonly used security are misunderstood or used as if they were synonymous.  Certain of these security terms are so closely related that it's worth examining these together. Today, we'll look at several related terms – threat, vulnerability, and exploit – and learn how security professionals use these to assess or determine risk.

Remember the Objective: Protect Assets

The reason we put security measures in place is to protect assets. Assets are anything that we determine to have value. An asset's value can be tangible; for example, gold and jewelry are tangible assets, as are people. In a corporate network, a database, the server that hosts that database, and the network that provides connections to the server are also tangible assets. Other assets – company or personally sensitive information or reputation – have intangible value but are no less important.

Threats and Threat Actors

Security considers several kinds of threats. A threat may be an expressed or demonstrated intent to harm an asset or cause it to become unavailable. Hostile acts that target an asset, irrespective of the motive, are considered threats. Acts of nature, human error or negligence are also considered threats. Both of these kinds of threats can cause web service or email interruptions, loss or unintentional disclosure of sensitive information, and in the emerging Internet of Things, both kinds may be determined to pose threats of human harm. Identifying threats is an important but extremely complicated aspect of security management.

Someone or some thing must express or pose a threat. These are threat actors. Some threat actors are individual attackers or state actors. Disgruntled, under-skilled, or overworked employees can also pose threats to an organization's assets and security management must consider all of these.


A vulnerability is a flaw in the measures you take to secure an asset. This is a broader interpretation of the traditional definition, which considers only flaws or weaknesses in systems or networks (See RFC 2828). Vulnerabilities expose your organization's assets to harm. They exist in operating systems, applications or hardware you use. For example, if you do not run antivirus and antimalware software, your laptop or mobile device is vulnerable to infections. Similarly, if you fail to routinely update your operating systems or application software, these will remain vulnerable to software problems ("bugs") that have been identified and patched. (These security efforts are called vulnerability mitigation or vulnerability reduction.)

How you configure software, hardware and even email or social media accounts can also create vulnerabilities. How you manage privacy settings, for example, may affect whether pre-release information about a product you intended to share with only your co-workers is instead shared publicly.

User behaviors create opportunities for attackers and are thus vulnerabilities, too. A system administrator who surfs the web from an administrator account on a corporate workstation may become a victim of a "drive-by" infection of malicious software. This behavior creates a vulnerability that is not considered in the RFC 2828 definition but is no less a problem in today's Internet than bugs in software.

Lastly, as we discussed in our first security awareness blog, people are vulnerable to social engineering. This vulnerability is proving to be one of the most formidable to mitigate. Raising security awareness is finally achieving recognition as an important component of vulnerability mitigation.


The term exploit is commonly used to describe a software program that has been developed to attack an asset by taking advantage of a vulnerability. The objective of many exploits is to gain control over an asset. For example, a successful exploit of a database vulnerability can provide an attacker with the means to collect or exfiltrate all the records from that database. The successful use of exploits of this kind is called a data breach. Exploits are also developed to attack an operating system or application vulnerability to gain remote administrative or "run" privileges on a laptop or server. (This is a common objective of malware, which we'll examine in a future post.)

Not all exploits involve software, and it's incorrect to classify all exploit-based attacks as hacking. Scams - socially engineering an individual or employee into disclosing personal or sensitive information - are an age-old kind of exploit that does not require hacking skills.


You'll find many definitions when you search the term risk. One that I find the simplest to understand is "the potential for loss, damage or destruction of an asset as a result of a threat exploiting a vulnerability" [TAG]. This ties the terminology we've reviewed – asset, threat, vulnerability, exploit – together quite neatly. In practice, for every asset, you identify the set of threats that could harm the asset. You then identify the vulnerabilities that threat actors could exploit to harm that asset. This, remarkably, is the simple part. The tricky part comes when you look at mitigation. Eliminating all threats – and thus having no risk – is unachievable, as there will always exist a degree of risk. The prevailing wisdom is to determine the cost of mitigating threats against the benefits. In theory, this effort defines the amount of risk you must tolerate given what you are willing to spend. In practice, it's proving much more challenging in the Internet era than before.


    Domain Name System
    Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as"""" is not an IDN."