You have probably heard about the recent Peloton API hack. If you have not heard about the details, this link describes the Peloton API Hack.
This incident further cements that IoT and PII are directly in the crosshairs for hackers. Every platform these days requires you to give up personal information in order to create an account.
Yes, even an exercise bike needs PII data to use the product’s full capabilities. This need for constant access to PII data is a gold mine for hackers and a real threat to protecting the general public’s personal information.
APIs are everywhere
You may not realize it, but APIs are used in most applications or IoT products as it is a way to connect products and provide greater functionality.
The problem is that these IoT products are becoming increasingly complex based on interconnectivity. It is more and more complicated for companies to ensure that they think of every possible use case in terms of API usage.
A developer has a specific time frame to release functionality, while hackers have unlimited time once the application or product is in production to find things that the developer might have missed.
Embarrassment is not an excuse
With the Peloton API finding, a white hat hacker properly disclosed the identified issue to Peloton and gave them an industry-standard time frame to acknowledge and fix the issue.
The problem is that Peloton was not transparent on how they planned to address the issue. This makes me think that Peloton was embarrassed about the finding and hoped it would go away quietly.
We all need to be on the same page, and open communication is key to finding security issues and remediating them correctly. Ignoring the problem due to embarrassment is not acceptable.
What can companies do to protect their customer’s PII?
Products and Applications are complex, and companies must clearly understand everything happening within their application architecture related to APIs.
If Peloton had an application architectural risk map of what APIs touched PII data, they would have been able to find and address this issue much sooner.
APIs are straightforward to use and implement, but understanding everything an API exposes is very difficult without a complete architectural view.