Previous month:
September 2016
Next month:
December 2016

October 2016

Threats, Vulnerabilities and Exploits – oh my!

This post originally appeared at ICANN blog on 10 Aug 2015.

Some of the most commonly used security terms 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.

Image by Degan Walters

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 RFC2828 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 exfiltrateall the records from that database.

A 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.


Zone access is a TLD abuse mitigation enabler: help your friends help you

Note: The views expressed here are mine alone. 

Image by Mike Morris

The Centralized Zone Data Service (CZDS) was introduced to facilitate and accelerate the process of requesting access to generic Top Level Domain (TLD) zone data. CZDS is included in the new TLD registry operator contractual obligation:

Registry Operator will enter into an agreement with any Internet user, which will allow such user to access an Internet host server or servers designated by Registry Operator and download zone file data.  The agreement will be standardized, facilitated and administered by a Centralized Zone Data Access Provider, which may be ICANN or an ICANN designee (the “CZDA Provider)

Legitimate consumers of zone data - criminal or abuse investigators, first responders to cyber attacks, operational security professionals, abuse researchers - rely on daily downloads of zone files to monitor and respond to additions, deletions or changes to domain names registered in all TLDs to identify and respond to security threats that make use of domain names. In many cases, a reliable, daily feed of zone data assists in the early mitigation of phishing, spam, malware hosting or botnet enrollment.

The response to CZDS is overwhelmingly positive. CZDS simplifies what might have been a registration nightmare: if you think that I exaggerate, imagine having to apply for access to potentially a thousand separate business entities, each having unique acceptable use policies or enrollment processes. CZDS considerably reduces this complexity. Still, as a colleague of investigators who use CZDS extensively, I receive a steady stream of complaints or concerns regarding CZDS implementation or execution.

Let me share three top concerns and suggest some remedies. 

CZDS Application Approvals 

Timely processing and approval of CZDS applications is important, especially since this is the current method for renewal. It's disturbing to learn that applications remain in a pending state for 100 or more days for certain new TLD registries. Every operator has business or operational priorities, but you will do your organization a service by processing applications promptly.


Access to zone data is typically granted for a limited period; however, investigators depend on uninterrupted zone access to observe additions, deletions or changes to domain names registered in each TLD. Delays in approving renewals creates "black holes" in zone data histories. These gaps hamper long term analyses that can be particularly useful to registry operators in identifying abuse behaviors; for example, investigators or researchers may discover a flocking behavior that a registry operator may be able to mitigate, e.g., abuse registration spikes on specific days, or through targeted registrars. 

PLEASE consider offering long renewal periods for applicants who you can associate with legitimate anti-abuse actvities. 

Denials of zone access requests 

New TLD registry operators are obliged to support CZDS. The CZDS registration portal collects applicant contact information and other data related to access (e.g., IP addresses the applicant will use to download zone files). Certain registry operators deny access to zone data when the applicant submits a post office box rather than a physical location. In such cases, the registry operator contends that it cannot ascertain the legitimacy of the applicant because they cannot determine the nature of the applicant's business or geo-location. 

There are several legitimate reasons why investigators use PO boxes rather than street addresses, and many of these have to do with physical safety. Abuse investigators have been and remain targets for retaliation from criminals whose activities they disrupt. High profile incidents are not limited to cyber attacks such as defacements or DDoS, but also kidnappings and swatting

There's a simple remedy here. PLEASE do not reject zone access in cases where applications include a PO Box.  Take the time to contact the applicant by email or phone. In all likelihood, you will gain a better appreciation for the legitimacy of the applicant through such contact than you would from an address.  

A second recourse: Contact me, to reach out to the operations security community to help you vet the applicant. It's very possible that someone in OPSEC knows the investigator or is one connection removed. Worst case scenario is that you've at least confirmed that a large trusted collaborative community is unfamiliar with the applicant. Best case is that you are able to grant access to a  applicant with some confidence regarding their legitimacy.

Either remedy is likely to produce a positive outcome. Either remedy is also less time consuming for all parties (applicant, registry operator, ICANN compliance) than processing a complaint. 

Know your friends

Investigators are not the enemy of registries. You run a legitimate operation. They are working to mitigate abuse of your operation. Assisting investigators is in your best business interest.