O.K. - firstly - long time no blog. Secondly, apologies for that - a mixture of vacation, work, and work travel has recently seen me distracted a little from my blogging duties (my plate spinning is improving, however). Anyway, with the apologies out of the way, onto the subject of this blog. Recently I was invited by Microsoft to speak at BlueHat on Windows CE/Mobile security, even being given a guest spot on their blog and doing a podcast for them. Pedram from TippingPoint has provided a good summary of the talks that saves me from typing them up.
I wanted to take this opportunity to elaborate on some of the things I touched on in the podcast. I discussed some of the things that platform providers, OEMs, and network operators can do in order to try and be prepared for the need to release security patches for mobile devices and improve security overall. I only gave a brief summary and wanted to expand this a little further.
Below I've provided a set of bulleted points to consider, covering each of the four types of organization involved in the ecosystem of cellular handset security. These are designed to improve security and relationships with researchers, while also preparing to be able to respond to security vulnerabilities in the future. This is meant to be rather high-level, but more rounded than those I briefly mentioned in the Microsoft interview (also, I appreciate that platform providers and OEMs can in some cases be one and the same – but often they are not in this modern world of COTs mobile platforms).
Platform Providers
• Prevention: The year is 2007, and while I have to be careful not to throw rocks within the greenhouse in which I live, prevention is the best medicine. These days, all platform providers should be adopting security development lifecycles (SDLs). In addition, mobile providers should be looking to employ all exploit mitigation technologies that are understood and available today, such as DEP (data execution prevention), ASLR (address space layout randomization), stack canaries (to mitigate stack based overflows), heap canaries (to mitigate heap manager attackers). While mobile platforms will present some unique challenges when implementing ASLR due to the use of ROM and execute in place, these need to be addressed in the short-to-medium term.
• Security Point of Contact: Today, the majority of tier-1 and tier-2 ISVs will have security point of contacts in-line with the recommendations outlined by the Organization for Internet Safety in the "OIS Guidelines for Security Vulnerability Reporting and Response, V2.0." Ideally, all mobile platform providers will adhere to these guidelines to allow the reporting of issues in a universally accepted way. By embracing external security researchers and responding to security issues appropriately these platform vendors can build and retain valuable relationships with security researchers who find security vulnerabilities in their products, while reducing the risk their customers are exposed to.
• Timely Response: I’ve had some very different experiences when dealing with mobile OS providers. From those who refuse to tell you which revision of firmware fixes the vulnerability unless you sign an NDA (I didn’t) through to those who take a significant period of time to fix the issue in the first place. All of this from an external researcher’s perspective who is simply trying to help them makes the whole experience downright awful. So, in the spirit of engaging researchers, providing timely updates on progress as well as timely fixes will gain you more kudos than doing the complete opposite.
• Notification: Currently, a vast majority (actually, all of them in my experience) of mobile operating system providers only provide details of security updates in the form of either knowledge base articles or change logs that accompany the source code they distribute. The problem with this approach is that OEMs and those directly affected may not realize a security issue or the associated severity has been resolved; therefore, the result is more exposure for all. Ideally these platform providers should consider reviewing their methods of notification, moving to a more formal and accepted method. This would include the notification of OEMs, operators, and end user organizations. Ideally this would include information such as a CVSS score. By adopting this more formal approach, it will firstly allow those OEMs affected and secondly those operators and end user organizations affected to be made aware of the issue while also providing details on the risk and impact associated with it. This, in turn, will allow OEMs to work with the operators and potentially end user organizations to then develop, test, and deploy appropriate firmware updates.
OEMs
• Security Program Managers: The first step for many OEMs will be to appoint one or more security program managers. These people should be responsible for security both at a software and hardware layer. Their responsibilities will include having to perform due diligence on hardware and software components licensed from other manufacturers of ISVs. By creating these go-to people for security, the OEMs will find it far easier to respond to security issues when they are discovered while also having a consistent position.
• External Security Point of Contact: This function is exactly the same as that performed by the platform provider’s equivalent. It is likely that many researchers will attempt to first reach out to the OEM of the device or the carrier of branded device before the platform provider. The result of which is that OEMs should follow the same OIS guidelines in establishing a security response function. This will not only allow the resolution of security issues in components the OEM is directly responsible for or licenses, but also the relaying of security issues to the platform provider - should they be appropriate.
• Monitor, Assess, Integrate and Deploy: All OEMs should ideally be closely monitoring change logs and knowledge base articles from platform providers in order to identify vulnerabilities. Once security issues are identified the OEM should assess the severity of the issue and if their products are affected. If found to be affected these patches should be integrated into current and future firmware releases, tested, certified, and made available to carriers in branded form or end users in unbranded form if appropriate. One of the biggest challenges with this will be the significant change in how handset manufactures have historically worked – there will need to be some hard discussions on how many years (yes years) devices will be supported in this manner. We have to accept that just because users in today's modern societies probably change their handset every 24 to 48 months doesn’t mean the handsets stop being used. Instead, they are often recycled and supplied to emerging markets. The problem is that if security patching is not made available for an extended period of time (four to five years at least) it means that we are simply shifting the security issues in older handsets to these emerging markets.
Network Operators
• External Security Point of Contact: As with platform providers and OEMs there is the possibility of researchers directly reporting handset security issues they have discovered directly to the operator. The result of which is that operators will establish points of contact to allow the receipt of such reports and facilitate the liaison with the affected OEM or platform provider.
• Firmware certification: Currently, the majority of if not all operators want to be able to certify new releases of firmware before they are deployed to customers. Operators should really look at developing a light weight certification process for updates that only resolve security issues. Most devices separate radio (baseband processor or "BP") from application (application processor or "AP"). If the changes only affect the AP and can be certified through an automated regression cycle to ensure functionality or compatibility is not affected, then this will expedite the process of delivering update firmware to affected customers.
• Firmware distribution: There exists today the flash over the air standard that facilitates the distribution of firmware - as the name implies - over-the-air (clever that, huh?). However, we have to accept that it is not widely deployed, nor is it supported by all handset OEMs. So, at least in the short term, operators should look to provide user-enabled upgrades for devices. Moving away from a service centre focused model makes sense for many reasons, especially because the likelihood updates will actually get deployed increases significantly.
End User Organizations
• Make, Model and Version: The first step for any security/risk department wishing to understand their exposure to mobile security issues is to first understand what their users are using. For these organizations it’s going to be imperative to log the makes, models, and versions of firmware in use within their organization. One of the challenges is going to be keeping this up-to-date. We have to accept that many users will discard their supplied device and use their own. In these instances this could be unwittingly exposing the organization to a risk they are unaware of.
• Monitor The Situation and Ask Questions: Today end user organizations probably get the sharp end of this stick for many reasons. The situation can, in some circumstances, be described as dire for an end user organization wanting to identify what security issues exist today, let alone if the handsets they have deployed are actually vulnerable to any of them. The only way this can really be resolved is using vulnerability databases that are increasingly cataloging them, while also asking questions of the organization's carrier of choice. By doing so they will over time be able to start to influence the important changes with carriers who are best placed to help them.
• Who Would You Call?: If you found one of your cellular devices had been compromised who would you call? The operator? The OEM? The platform provider? A security provider? Answering this question (identifying who is the appropriate point of contact that can help you in times of urgency) will really be quite key. If you’re going to phone the operator you’re probably not going to want to phone a standard customer service rep. So, work with your account managers today in order to understand what the best course of action would be in the event of the emergency.
O.K. this ended up being far longer than I had originally envisaged but I think it’s a good initial stab to help the relevant parties be better prepared. While I agree it’s not comprehensive, I think you probably could write a whole paper on the unique traits of the cellular ecosystem and security, where responsibilities lay, and the best course of action for the future. Maybe I or someone else will get around to it, maybe not :-). We have to appreciate that cellular device security is going to be an increasing area of research that attackers will gravitate to at some point. But, by acknowledging these problems today and making improvements over the short to medium term, we can all be better prepared.
Well, that’s about it from me for now. Until next time - also, if anyone out there does want to discuss this subject off-line in more detail, feel free to contact me.