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

Whitelist

Icon of the Whitelist pattern

Available privileges may be abused, but not all potential abusers are known beforehand. To minimize the risk of abuse, add identifiers of all trusted communication partners to a Whitelist. Block the privileges controlled by the Whitelist for those who are not on it.

Alias:

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 be freely available by default, but others should only be made available to trusted partners. In both cases, abuse is a problem which has to be handled. This can be done by using the Authenticator pattern [2], which relies on cryptographic mechanisms and tokens but requires some processing power. Thus, this may not be applicable everywhere in IoT systems, where very constrained devices may not have enough resources to execute such a mechanism. Besides, tokens used by these mechanisms may be stolen and used on other devices, or devices may be stolen and used from other locations. Denial-of-service attacks might also be a problem. Such illegitimate request should be blocked to not waste too many resources on them.

Problem:

Privileges may be abused and attackers may try to overwhelm a system with requests. Using a Blacklist to block known abusive communication partners helps, but such a list is never complete. There has to be a mechanism to limit access to known communication partners to minimize the possible range of attacks.

Forces:

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

  • Identification: To be able to grant only certain communication partners the controlled privileges, is has to be possible to identify them reliably.

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

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

Solution:

Implement a Whitelist to which identifiers of communication partners may be added with an administrative interface. Implement checks for every privilege which the Whitelist controls. If such a privilege is requested and the requester’s identifier is on the Whitelist, allow it to proceed. If not, deny the request.

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
  2. M. Schumacher, E. B. Fernandez, D. Hybertson, F. Buschmann, and P. Sommerlad, Security Patterns: Integrating Security and Systems Engineering. Wiley, 2005.