Categorizing and Minimizing Threats to your Business

Hindsight is always 2020. The weak link seems obvious in retrospect, but only because you are focusing on it. When your focus is narrow, you are more likely to notice mistakes, but as we saw in the multi-layered diagram above, the scope of an IoT solution is usually anything but narrow. 

Many IoT security pitfalls stem from the complexity that is derived from a wide project scope. It is not impossible to build a secure yet complex IoT solution, but when additional constraints are imposed without an associated compromise, mistakes are made.

The root cause of cybersecurity mistakes is often a simple one: lack of resources. The limited resource may include but is not limited to:

1. Time
   • There is no replacement for quality engineering time. In the fast-paced modern business environment though, leaders often pressure engineering teams for rapid progress, with the intent being a faster time-to-market & cheaper development costs. Though these are noble intentions, in order to make ambitious progress on a short timeline, shortcuts must come from somewhere.
   • Make sure any shortcuts come from the product features instead of product security, or your engineering team will be spreading itself too thin.
2. Budget
   • A constrained budget will mean that less engineers are available, the resources those engineers have at their disposal is limited, and more responsibility is placed on each one. This is tricky to navigate, unless the scope of the project fits the budget in some form of reality.
   • There are ways to outsource parts of the IoT solution for less upfront cost, such as FCC-certified hardware modules or parts of the software solution that can be licensed or paid on a per-use basis. These options can make each dollar go a bit further, but it is unlikely to fix a project which was doomed from day 1, due to lack of a realistic budget.
   • If the budget available does not fit the project, evaluate shortcuts that do not compromise on security, or more likely, change the project scope.
3. Experience
   • Lack of experience within the engineering team can be a large factor in the resulting cybersecurity. Engineers who are great at PCB design & hardware, are unlikely to have relevant experience in web security or cross-compatible user interfaces. Team members need to be based in roles that play to their strengths.
   • If your team doesn’t have each base covered from day 1, that’s okay – Don’t be afraid to use external specialists in areas where your team has blindspots. The only mistake to avoid here, is ignorance in assuming that your team can learn as they go without extra guidance or additional development time.
4. Communication
   • Even with a competent engineering team, poor communication can lead to serious design or implementation flaws. Since IoT solutions are spread between many layers from hardware to the cloud, often separate engineers or teams are responsible for a segmented area of the solution, and must communicate in order for all these areas to work together.
   • Problems arise when poor communication leads to assumptions about the area of responsibility that is divided between teams. This is not unique to IoT, but it is crucial for consistent communication between the end-user, engineers, and business leaders.

Mistakes based on the constraints listed above are an avoidable risk. Most horror-stories are born from one of these causes, even though sometimes they don’t surface until a few years later.

A more simplistic solution with proper security is better than a full-capability one which compromises on security. Your customer interest might tempt you to start with a shiny full-capability solution (and work on the boring security later), but this is the wrong order of events. Security should be first, additional features should come after.

Shortcuts are not inherently bad. In fact, it often makes a lot of sense to limit scope, outsource parts of the solution, or reduce non-critical features & plan to add more support in future updates. Real trouble only comes when those shortcuts come in the form of cybersecurity, or overall usage testing.

Let’s look at a real-world example.

For context, OEMs who offer connected products often have more than one portal to access their product:

1. There is a customer-facing portal for viewing real-time dashboards, gaining analytical insights, or setting alerts. 
2. There is an OEM-facing portal, which is used to manage the product fleet & customer base. This portal provides fleet-wide business insights & actions that only the OEM should have access to, such as OTA (Over-the-air) updates, customer support, & viewing internal service metrics.

One way to shorten development time is to combine these portals. Basically, hide the OEM/Admin interface within the customer facing one. This approach can save development time, but it can be dangerous without proper security measures in place.

Sound familiar? This actually happened, with Jacuzzi SmartTubs. Basically, sensitive customer data was exposed to a curious user, who was able to access the hidden OEM interface, without proper credentials.