Internet of Things Patterns
This is an excerpt of the pattern that was first published in [1].

Blacklist

Icon of the Blacklist pattern

Available privileges may be abused. To stop this, implement a Blacklist to which identifiers of abusive communication partners can be added. For each partner that requests a privilege first check this list and deny it if its identifier is found on it.

Aliases:

Filter

Context:

For IoT systems to work, communication partners need privileges to access parts of others. Some examples include devices that need access privileges on the backend server to send it their data, or applications that need privileges to access certain functionality or to be executed on a device or a server. Some privileges may have to be explicitly granted, others may be freely available. In the latter case, abuse is a problem which has to be handled. But even when privileges are explicitly granted, abuse is still possible, for example if a device is hijacked by a malicious intruder.

Problem:

Privileges, no matter if freely available or explicitly granted, may be abused. There has to be a mechanism to stop existing abuse and to limit potential future abuse.

Forces:

  • Intervention: Abuse may already be happening. The mechanism has to be able to intervene and stop existing abuse.

  • Prevention: The mechanism has to prevent future abuse where possible.

  • Identification: To be able to prevent abuse, it must be possible to identify abusers. But identification may be imprecise or easy to forge.

  • Control: The mechanism has to provide control over what communication partners or actions are deemed abusive. It has to allow manual adjustment if these circumstances change.

  • Simplicity: The mechanism should be easy to understand and easy to use.

  • Efficiency: The mechanism has to be resource efficient. It should not have a large impact on the normal operation of an IoT system. It should be able to run on constrained devices.

Solution:

Implement a Blacklist to which identifiers of abusive communication partners can be added with an administrative interface. Implement checks for every privilege that the Blacklist controls. If such a privilege is requested and the identifier of the requesting communication partner is on the Blacklist, block it. If not, allow it to proceed.

Solution sketch of the Factory Bootstrap pattern

Solution Details:

This is an excerpt of a previously published pattern. The full pattern can be found in [1].


Benefits:
Drawbacks:

Variants:

Related Patterns:

Known Uses:

  1. L. Reinfurt, U. Breitenbücher, M. Falkenthal, P. Fremantle, and F. Leymann, “Internet of Things Security Patterns,” in Proceedings of the 24th Conference on Pattern Languages of Programs (PLoP), 2017. Available at https://dl.acm.org/citation.cfm?id=3290305