Features, Bugs, and Backdoors: The Differences, How Language Can Be (Mis)Used, And A Word Of Caution

Language is a powerful tool.

With acronyms like ACL, IPS/IDS, and APT*, the security world has created its own language, acronyms, and catchphrases. In our industry, sometimes the meaning of more commonly used words can cause misunderstandings. For example, is a hacker a bad actor or a well-intentioned individual? Are all software bugs also security vulnerabilities? Can the terms feature, bug, and backdoor be used interchangeably?

A feature, a bug, or a backdoor might look like the same thing to some, but they are not. Imprecision in this area can breed misunderstandings. I believe that there are two key differences between a feature, a bug, and a backdoor: intent and transparency.

Features
Intentional: Yes
Transparency: Yes (Known to customers at the start)

A product feature is clearly intentional, as it is designed to satisfy customer requirements or some other compliance or diagnostics requirements. It is known publicly, usually well documented, and is used in customer environments (why it was put there in the first place!) At Cisco, we believe that all designed-in capabilities, including diagnostic tools, should be well documented.

Bugs
Intentional: No
Transparency: Variable (Known to customers once identified and disclosed)

A product bug is clearly unintentional, as it can negatively affect the customer experience. Inevitably a vendor can be praised or punished publicly on how a bug is discovered, how trivial or complicated it is, and how the fix and disclosure is handled. What your vendor does when they become aware of bug is where transparent disclosure policy comes in.

At Cisco, we are transparent about our process, have a clear Disclosure Policy, and give our customers the information they need to act in their own best interests.

Backdoors
Intentional: Yes
Transparency: No (Unknown to customers)

A backdoor is intentional, and is not disclosed or documented. It could be the result of a well-meaning customer support engineer, a third party software library, or the actions of a bad actor. An adversary, using an exploit kit, could also install one after a product has been deployed and is being used by a customer. Backdoors are nearly always viewed as wrong, because something intentional is happening in an environment without a customer’s knowledge or authorization.

At Cisco, we do not knowingly enable backdoors in our products. We do not deliberately build backdoors into our products. We do not work with any organization or government to implement backdoors in our products. Our policy on backdoors is very clear.

(Mis)Using the Terms
Features, bugs, and backdoors—these three terms can be confused, misused, or misconstrued by design to create doubt. It is one thing to do something accidental, like forgetting to remove a fixed testing password before a software release. It’s quite another to say that this was done deliberately to put a customer at risk.

A bug can be exploited to install a backdoor, but the bug is not itself a backdoor. Nor is a well-documented feature, implemented according to industry standards, supporting the work of law enforcement—it’s a feature. Pointing to these as examples of creating deliberate risk in customer environments is misleading, at best.

Word of Caution
These topics and distinctions are important to all of us in the security world. By using very specific examples and commonly shared definitions, we can help reduce misunderstandings and advance the public conversation.

*Access Control List (ACL), Intrusion Prevention System/Intrusion Detection System (IPS/IDS), Advanced Persistent Threat (APT).