“Protect your assets!” is a mantra that is much used in information security. The term ‘asset’ is useful when applied to a specific business perspective. However, for managing security it does not fully cover the things that need protection. Indeed, the use of the term can easily make you overlook the things that need security measures. In this article, I argue that we should broaden our view, and start using the concept of ‘objects of security’, which is a mental model that can help us better understand security.

Assets: a business perspective

The notion of an asset is one of the first things everybody learns when working in information security. An asset refers to a thing of use or value that needs protection from damage and threats. In most literature on information security, a computer hardware device is considered an asset, as is information stored on computers. Assets also include intangible things like intellectual property, advance orders, and even reputation. Observe that these things are all viewed from a business perspective: an asset as a useful or valuable thing that can contribute to the success of an organization.

What objects need security?

One of the problems of working in security is identifying the things or ‘objects’ that need security. If you ask a business owner what he or she considers to be their company's assets, he or she will not immediately come up with company-issued mobile devices, or the database with customers' credit card details. To him or her these are just accessories, like a pen and paper. Still, these are the objects of concern for a security manager and measures are needed to protect them. In general, it is easy to logically reason that protecting these objects (e.g. smartphones) contributes to protecting the company assets. However, if security managers use (business) assets as the starting point in their process to identify the objects that need security, it is hard to find the things that need protection.

Value and obligation

Another reason not to rely on the concept of assets in information security is that the value of something is not the only motivation for security. One of the most obvious other reasons to protect something is because you are obliged to protect it. Regulations and policies make you create security measures for objects even though you might not consider them assets. For example, a company is obliged to protect personal information according to the relevant legislation, though the marital status of employees is certainly not an asset for the company. These obligations apply at various levels. For example, an employee does not consider his or her company laptop an asset, but policy and regulations oblige him or her to protect it with strong passwords, and to not leave it on a train.

Implicit expectations

The obligation to protect something is not always the direct result of a prescribed rule. For example, customers expect organizations to act in their best interest and expect their data to be protected as part of this service. Similarly, supervisory bodies or public opinion expect certain security measures to be in place without explicitly asking for them. We often see this expressed as the requirement: ‘adequate measures should be taken’. Therefore the objects of security are also identified by the indirect obligations to protect them, such as customer relations, reputation, liability, and due diligence.

All these unspoken assumptions and implicit expectations make it hard to identify the objects that need security: when are they all covered? Identifying them is indeed a challenging task, but the thing to keep in mind is that it is about what other people value. For example, we as a society value the ‘right to be forgotten’. Keeping track records of your customers can feel like a violation of that value, especially if these records end up being stolen and published online. What someone considers as an obligation is considered by someone else as a value. Both value and obligation are criteria for identifying the objects of security. They are however strongly intertwined. In fact, they are the same criteria, but viewed from a different perspective.

Value and threats

Besides value and obligation, the ultimate motivation to secure an object is that it needs to be protected against harm, danger or threat (by definition). In many cases, this need is motivation enough to protect something. We create security measures for an object not because it has value or because we are obliged to protect it, but simply because if we don’t, we suffer some loss or harm. For example, ransomware infections by phishing mails are a persistent threat that can have considerable impact. This should therefore be a (priority) object of security and measures should be taken to counter the threat, for example awareness, hardening systems, monitoring, and a smoothly operating back-up facility. A ransomware infection can cause a lot of nuisance and take up the valuable time of your employees and system administrators. Although such threats can ultimately have an impact on a business, from a business perspective these are not assets that are at stake, and neither are they valuable to somebody else. But from an operational perspective these are security concerns that need to be addressed, because if they are not you are in trouble.

It goes without saying that you need to take security measures to protect against known or predictable threats. There might not always be a direct connection to business assets, but that can easily happen. For example, if blackmailers threaten to make some data public if they do not receive some money, this object of security is directly linked to the obligations you have, and to the business assets, like reputation. This shows that taking security measures simply because ‘if you don’t you’re in trouble’ is a very valid reason.

Hierarchical objects of security

To have a clearer idea about what must be protected, and to make it more manageable, it is useful to create intermediate objects of security. For instance, unauthorized access to workstations is an object that needs security measures. Infringement on this, like a ransomware infection, might harm a company's valuables or obligations, and will certainly cause some problems. These intermediate objects can be viewed not as direct valuables for the business, but valuables for security. For example, the actual patch level of the software used in your company should be monitored as a security measure, because if for whatever reason it is faulty, you could be in trouble. A smooth-running software patch mechanism is therefore a valuable thing for security.

This last example shows that the value of objects is also determined by the harm that might occur if they are not protected. Objects become valuable if they are exposed to known or predictable threats. There is a relation between value and threats in the same way that there is a relation between value and obligation. Again, they are the same, viewed from a different angle: if there is a threat on an object, some harm might occur, which makes it a valuable thing to protect.

Change your view

Identifying the things that require security measures is a difficult job. It might help you, as a security manager, not to use the term ‘asset’ as a starting point, but instead employ the mental model of objects of security. These objects can be identified by: (1) the value they have for you or somebody else; (2) the implicit or explicit obligation you have to protect them; and (3) known or foreseeable threats that mean there may be problems if you don’t protect them. These three factors cannot be seen separately but are strongly related. In fact, they are the same, but viewed from different angles. Changing your view on security might help you understand and solve the complex security problems a little better.