Stephan Schmidt

Keep a List of Insecure Features

First step for more security

Part of my CTO Coaching

As a CTO you should keep a list of insecure features. I know you have them.

Those insecure features are an attack surface for hacking and social engineering. Every time I was CTO or engineering manager, we had insecure features, most often with back office applications.

Examples for insecure features include:

CSV export of all customers (marketing might have wanted this for an “integration”). This can easily lead to a data leak by an angry employee.
Search for support by anything else than customer number. This enables customer support agents and probably lots of people with access to the back office tools to search for people (as has happened to stalker victims and celebrities)
Search results that return more than X results, and contain more data than what is needed to identify what you were looking for. This list can easily be cut & past and taken away to a competitor
Link where customer support can impersonate a customer Customer support agents can do whatever they want and it looks like the customer did it, e.G. crimes.
Links in marketing emails to auto-login (might be forwarded)

Why to have insecure features in the first place? These were probably build because there was no time to build something better, or because someone thought “conversion” and “convenience”.

To mitigate the risk immediately, log the usage of those features (in a legal way). If a customer service agent or any employee impersonates a customer, this needs to go to a log file. These log files need to be audited regularly - and perhaps automatic for patterns.

What to do now with the insecure features you have? Plan to remove them. This is an uphill battle because customer support, marketing and others that depend on those features, will object and say they can’t do their work without those features.

Start by creating a list of those features. When you start as a CTO, this is one of the first things to do. Talk to engineers, explain the concept, and ask for unsecure features and shortcuts that have been taken that are unsecure. Write all of them down in a list.

Show the list to the CEO. Showing this to the CEO reduces your responsibility and CYA if things get bad. Explain the list and the impact to the CEO. Suggest a timeframe and solution of how to get rid of them. Keep the list in your regular discussions about risk and security with the CEO and everyone else who is responsible for risk in the company (e.G., the CFO).

Features on the list need to be fixed in the end though. But start with a list.