Cybersecurity Debt

Technical Debt is a term used by software developers to refer to aspects of their code base which they know were expedient or short cuts and which may need to be fixed or expanded some day. For example, assuming that all money amounts are USD, or assuming that all dates and times are in a particular timezone.

Like financial debt, technical debt can be a useful tool or it can be a time bomb waiting to blow up your company. The difference is in understanding and managing the risks and the rewards.

I will digress to give an example for those readers for whom this is all terribly abstract. If you do not need an example, feel free to skip the following paragraph.

Once upon a time I wrote a Laboratory Management System (LMS) and provided a powerful patient lookup tool. What I did not provide was much in the way of navigating lists of patients because there weren't many patients to view in any of the systems. This was fine for the initial release. Things went well and that meant that the oldest installation now needed more than simple pagination: they needed navigation by initial letter of last name, they needed the ability to jump to particular pages and they needed the software to warn them when their query would return a huge number of patients. I added all this because that technical debt had come due. Then smaller installations complained about all the new and, to them, utterly useless overhead. I then added code so that the amount of presentation overhead was commensurate with the size of the list. I could have done all that work for the first version, but it wasn't needed then and would have been a cost without much present benefit. Taking on technical debt isn't always bad, but it isn't always good either.

So it is with cybersecurity: you incur Cybersecurity Debt when you take an action whose risk : reward ratio is currently acceptable. You cannot simply congratulate yourself on a job well done and move on. You need to constantly revisit the calculation of risk versus reward.

Put another way, every IT service has a benefit (providing the service) and a cost (maintenance, the possibility of failure and the possibility of abuse). In cybersecurity, we recast this as a risk (the cost) and a reward (the benefit). Allowing devices to connect to your WiFi is a service that provides benefit, but that benefit comes at a cost. Part of the cost is monitoring what random devices do on your WiFi and constantly confirming that random devices are as contained in their access as you think they are.

A big issue in this arena is the background of obviousness. After you have provided multi-function printer (MFP) access for a several years you stop thinking about providing multi-function printer access, you just do it. You don't think about it any more. But you should think about it because MFP's can scan and transfer data over the network and even though print jobs can contain confidential information which should never leave your internal, secure network. Over time, as printing has become less and less important, I see a disappointing number of shops which are not reviewing their printing needs and not confirming that the fancy new network isn't exposing print jobs to unauthorized eyes. Long-term debt is still debt. Boring things are still things. Functions which don't demand attention still need attention.

This is what we mean by cybersecurity debt and managing that debt is part of what we mean by behavioral cybersecurity. Maybe it is time to assess your cybersecurity debt. That is hard. We can help. Ask us how.