Security rarely moves at the pace of the market – products ship to meet marketing deadlines, not security deadlines. Security seems like a difficult-to-absorb expense relative to new feature development, and nowhere is this more evident than in the breakneck speed of the mobile device development cycle. That pace isn’t slowing. The winners get devices into the hands of the users by the millions and the losers get to watch the tiny hardware margins evaporate and leave no revenue to fund the hard work of doing security right.
So it’s easy to see why security takes a back seat. It’s a matter of survival.
But it’s also a matter of culture. Whiz-bang marketing sessions tend to drive funding more than kernel optimization issues would. And while stripping down a kernel in meaningful ways would serve to bolster a robust, secure product, a development team would have to already understand that capability at a deep level, and, more importantly, be able to explain that in a marketing context. Those folks are rare indeed. Don’t believe it? Go try to hire enough of them to build a secure mobile device – on a marketing timeline.
So the secondary market is left to pick up the pieces, or at least cope with the post-launch rapid barrage of software/firmware updates from the manufacturer who ran out of time and money before the hardware shipped. This means the public become the beta test group and the early beta testers are really testing alpha code.
This is the current state of millions of mobile devices. But that’s starting to change.
Now, because hacking has gone mainstream, it’s easier to justify having a robust security budget (well, compared to a few years back), because more consumers are looking for it on the packaging and sales side of the equation. This means it’s a question that’s far more likely to be asked during a funding cycle, and even be allocated to a dedicated budget early on.
While there’s still a gap in the market between product development and secure coding staff, the funding tends to translate into real internal security budget early in the development cycle.
Also, it’s much more common these days to push out a structured update cycle for security releases, and you can take notes from lots of other companies who have already navigated those waters to cherry pick what works. That way, even if some issues slip through, the public has assurances that they’re being prioritized in terms of impact and released in an appropriate timeframe.
In the past few years, the code analysis tools have become much more robust and easier to use, which has resulted in much higher test coverage, so it’s easier to ensure better code as you go, which creates less resistance to best practices among the developers.
And while there will be an ever-raging battle over software development methodologies, there are lots of companies that have already wrangled with what works in the mobile space. In the past, development cycles were angled at anything from cable TV boxes to traffic light controllers, but not really at mobile devices as a full development cycle. Now that’s changed, so it’s more likely you’ll have folks on your team that have some experience with what works and why.
It’s getting better. We know more now about the space, so there’s not as much need to reinvent everything. The platforms have stabilized to an extent, so you have limited targets to develop against. Rather than five platforms you may have one or two, and you can still sell enough of a single platform to succeed in the market.
Slowly, mobile device security will continue to improve, or hopefully even break even or outpace the attacks. And with the increased sense for the need for security budget, you may be able to sell these concepts to management. Meanwhile, if customers continue to demand better security in the marketplace (and vendors continue to listen), we’ll all be safer.
Discover how ESET Mobile Security can boost the security of your devices; visit us at the from 28-30th June 2017. Meet us at our booth E05 in Hall W2 at the New International Expo Centre.