There’s a lot of marketing buzz associated with mobility and development related to the Internet of Things (IoT) these days, but from a security perspective, some of the hype isn’t all that reassuring once the rubber hits the road. For example, just recently, a security analysis firm known as Kryptowire announced that they had identified a security weakness in a certain brand’s Android-driven smartphones. The threat vector allowed sensitive user information, such as active text messages, to be potentially delivered to third parties in real time and allowed for constant physical monitoring, message tracking, and information retrieval in perpetuity.
Now, we don’t know about you folks; but how would you like some person, company, or unknown governmental agency looking over your shoulder every time you text your kids, wife, girlfriend, friends, or business colleagues, thereby offering the possibility of destroying all canons of digital privacy? And, if that wasn’t bad enough, the mobile OS itself was not really the problem. Instead, a low-level marketing analysis utility wrapped around the system kernel ended up being the larger threat, which is where the IoT comes in.
As it happened, a Shanghai-based development shop known as ADUPS doing business analysis by means of mobile push/pull updates via the ‘Firmware On The Air’ utility (FOTA) utility found itself at odds with the particular device’s internal security instructions. From an IoT perspective, the nominal goal of the exercise was to aggregate gross marketing information anonymously, a process that has become largely accepted by mobility users since digital business intelligence first emerged. In theory, then, the totality of the device’s market-related information would be delivered to various commercial marketing consumers in the blind, and everyone would end up with a host of happy campers, including customers, the analytic developers, and its cadre of clients.
However, in practice, a particular device brand’s instruction set wasn’t compliant with a scheduled update, and consequently, the process breached the brand’s security firewall, causing them to start communicating everything in the clear. This, of course, triggered a squawk from the manufacturer, and the developers in Shanghai had to execute a subsequent FOTA update and public statement, thereby fixing the problem going forward. However, the smart and highly-vigilant folks at Kryptowire identified the problem by chance, and, as they say, ‘that’s viral tech security history.’
Now, in all cases, near as we can tell, there were no serious issues involving anyone or anything other than substantive embarrassment and inconvenience. However, in our view, the point is pretty clear from a DevOps consultant’s perspective.
Today’s mobile systems development is driven by a sense of ‘continuous everything’ including; design, production, QA, Ops, delivery, and follow-on improvement processes. This means that everything is moving at lightspeed, and even the most detailed developer, leveraging the best management methodologies, will occasionally make an error; even though, in our case, the DevOps methodology is ‘supposed’ to catch and fix problems before they happen.
But, what about the inter-relationship between third-party firmware and/or hardware partners and their role in creating ultimately efficient, stable, and secure consumer products? To go back to the original scenario for a minute; the ADUPS folks were working on an assumption of a nominal code base that worked fine for a host of other device manufacturers; while the device manufacturer’s internal systems were working on the assumption of past experience with ADUPS, along with an equally nominal set of internal instructions that had worked fine in the past; so when the aforementioned update hit and the chips finally cascaded to the table, who actually ended up being the more responsible party?
Truth be told, neither; both; and all of us – simultaneously. Somewhere between the two ‘nominal’ development conditions, something of import was missed at a compliance validation level. At the end of the day, the people who were impacted the most were customers, which is clearly not a compelling goal for any of us to foster.
Potentially, the IoT poses the greatest threat to today’s digital universe since the device-to-software-to-device loop is constantly expanding on a largely unattended basis; whether it’s a smartphone, baby monitor, refrigerator, coffee pot, connected car, wireless home security system, or anything else folks can dream up. Consequently, as a cautionary tale, the ADUPS flap has shown to be what it is, a potential failure that ‘could’ create problems untold. On the other hand, however, we can and must always do better; which, in the end, is really what successful Devops consulting is really about.