The Lawmakers move securing software up the agenda: HTC a high profile casualty

With Mobile World Congress 2013 taking place in Barcelona this week and all the fanfare over new product launches and technology, it may have escaped many people’s notice that something monumental has happened. No, it’s not a new device, a new form factor, a new app store of any of those things you would normally associate with mobile.

On 22nd February 2013 handset and device manufacturer HTC, admitted charges of distributing insecure software and putting users at risk. HTC was charged with committing a number of offences by the Federal Trade Commission (FTC) and rather than go to trial, it admitted its guilt and agreed to a number of steps that will not only impact HTC but have the potential to significantly change the software industry.

Before going any further it is worth saying that this is an American judgement, against the American subsidiary of HTC. Despite this, it is a major milestone in the relationship between regulator and software vendor, something that we have not seen before and, quite honestly, something that is decades overdue.

The details of the charges can be found at This is a document that is worth five minutes of anyone’s time to read and consider. Just in case you don’t have the time, here are some of the key items:

HTC’s failure to employ reasonable security in the customization of its mobile devices

This covers the customization that HTC carried out to Android in order to differentiate it from competitors devices. It also covers the utilities and software that HTC distributed with its devices and the work done for operators.

The FTC found that HTC:

  1. Failed to properly train its developers.
  2. Failed to establish a secure by design process.
  3. Failed to properly test software.
  4. Failed to have a way to identify software problems.
  5. Failed to have a proper software remediation process.
  6. Introduced security vulnerabilities through its customizations that would allow third parties to exploit sensitive information stored on the devices.
  7. HTC undermined the Android OS permission based security model by allowing applications to access data from other applications by assuming the permissions of that secondary application.
  8. HTC’s own logging application used an insecure communications mechanism that allowed other applications to access the logging system and capture highly sensitive data from the devices.
  9. The Carrier IQ software deployed on devices to allow carrier to analyze and track network problems was also compromised through the insecure communications mechanism.
  10. Malware was able to access devices and send SMS messages that were not stored in the user outbox which meant that the user did not know the messages had been sent.
  11. HTC failed to deactive debug code installed on devices allowing third party applications to use that code to gather information from devices.
  12. When debug data was sent to HTC, it also gathered sensitive user data and sent that back to HTC.

All of these items listed above caused harm to consumers that could have been prevented if HTC had carried out proper training and security practices. In addition, HTC was charged with making false statements in its user manuals.

Guilty: How HTC must pay

HTC has been quick to accept its guilt and avoid a court case. As a result, it has managed to avoid the risk of significant fines.

However, it has had to agree to a serious range of actions to rectify the problems above. These include:

  1. The issuing of software updates to fix the problems identified.
  2. Create a training programme for all its developers to improve their competency.
  3. Agree to security audits every 2 years for the next 20 years.

HTC is not alone

These charges are about as damning as it gets but are they acts confined just to HTC? In their entirety one would hope so but there are a range of items above that can be applied to a lot of software in the market.

For example, it is virtually impossible to ship any software without it containing bugs or security vulnerabilities. Oracle has recently been pilloried for its poor security policies around Java and its failure to respond to security problems quickly. Another vendor Microsoft, issues security patches on a regular basis. Apple has recently had to issue updates to its software to rectify problems.

The key difference between these vendors and HTC is that they have processes to identify security problems, spend money on teaching developers how to write secure code and have mechanisms to issue patches. However, looking at the FTC judgement, that may not be enough, especially for Oracle who has been extremely slow to deal with Java issues which has caused a lot of bad press for them lately.

There is, however, a serious risk here for other device manufacturers and not just mobile phone vendors. It took home router vendors almost a decade to secure devices at the point of shipping. As we look at an ever increasing penetration of computing and Internet enable devices in the home from heating to fridges, home security to TV, the FTC has put vendors on notice that they need to do more out of the box.

It is not just device manufacturers here. The European Union believes that all cars sold after 2014 will be Internet enabled. This means that there has to be a programme in place now whereby regulators begin to develop mechanisms to do advanced testing of highly complex systems.

Safe and secure in the enterprise…think again

A number of the charges levied at HTC could be applied to software developed by enterprise developers. In the Creative Intellect Consulting Security Surveys from 2011 and 2012 there was a clear concern from respondents that the current software delivery practices were a serious cause for concern. From the front of the published report one of the key messages was:

Current software delivery practices show software security still a cause for high concern, risk and financial loss:

The results of the survey show that security is still not embedded tightly into the software delivery process and that there is a belief, among practitioners, that management is not fully committed to investing in a secure code approach. The culture and attitude or, to be more succinct, the lack of the right mind set for delivering and maintaining secure software, throws light on some worrying concerns. Organizations, brands and people are being put at risk by a failure to take software security seriously, but no more so than in the application lifecycle management process. It begs the question as to whether organizations have the capacity for and are ready to deliver secure software targeting next-generation technologies such as Cloud computing and mobile delivery platforms.

Careless software security strategies cost business

The results from our survey also showed that few companies actually subject in-house and packaged applications to rigorous security testing. Even fewer have a test process controlled by the operations team to ensure that an application is “fit for purpose” before it is deployed. One doesn’t need to look far to see that bad apps are still being delivered.

Even tougher legislation is potentially waiting in the wings

We are fast approaching a point where stricter regulation and compliance rules (much like those that govern safety-critical industries and the financial industry) will become an imperative for the wider market. The EU has already signaled that it wants to extend consumer legislation already in place for computer games to business software which, if adopted, would result in far reaching legislation impacting anyone writing computer software. From a boardroom perspective the tightening of laws surrounding directors and their responsibilities could, reasonably, be used to allege negligence where a company loses money due to poorly written and insecure software. In HTC’s case the legislative process has already swung into action.

The case for negligence is getting much easier to prove due to a number of significant factors:

  1. Detection tools are, in general, greatly improved. They can be integrated to dynamically and automatically detect errors at all stages of the software lifecycle. But especially in the upfront design and development processes, as well as prior to deployment or release when the costs and impact are significantly smaller.
  2. Suppliers are starting to wake up to the importance of promoting strategies for secure by design as well as providing and promoting secure development lifecycle models, methodologies and process support. We would expand the term to “Secure by design and practice” to strengthen the case.
  3. Not-for-profit industry professional bodies like (ISC)2 and others such as the International Association of Software Architects (IASA) are devising comprehensively robust professional certifications to help bring consistent levels of software security education, training and qualification to IT and software roles. All this can help provide organizations and their software teams the necessary skill sets for addressing security professionally and skillfully.
  4. There is a broad spectrum of industry bodies – from vendors to not-for-profit organizations and government policy units – focused on providing insights and resolutions to known common software security failings so that organizations and individuals can take preventative action.
  5. It has been well established, through numerous industry surveys over a number of years including the results from this one, that culture; lack of management drive; and weak education and training support are significant barriers/hurdles to addressing secure code development and software security in general.

A full copy of CIC’s “State of Secure Application Lifecycle Management” can be downloaded from our website. The survey report provides other key messages that enterprise customers need to act on.

The industry response

Over the last few months, both IBM and HP have been aggressively talking about their security and testing services. These are no longer being positioned as discrete systems but as part of a larger solution. The development of Software Testing as a Service (STaaS) has made it possible for enterprises to gain access to advanced testing that was either too expensive or too complex for many enterprises to consider.

HP and IBM are not the only vendors who have upped their security and testing story. Other tools vendors are creating cross platform testing solutions with a lot of emphasis on the emergence of mobile devices. In Spring 2013, Creative Intellect Consulting will be publishing its view on where IBM and HP are with their security story.

The hackers aren’t the only ones out to test your security vulnerabilities

The FTC has now put device vendors on notice that they will have to up their game. Enterprise developers need to take note as well. Any organisations delivering mobile applications to its users needs to do its own testing of the underlying platform to make sure it is secure. If the applications are deployed on Bring Your Own Devices (BYOD) and cause personal data to be leaked, then the enterprise could find itself guilty of several of the charges that HTC was found to be guilty of.

Until this decision, the software industry has enjoyed a high level of freedom from prosecution because software has been seen as R&D rather than as a consumable such as a fridge or a car. This FTC move against HTC has the ability to change this for ever. The FTC has established cause and effect tied to negligent or poor processes. If software developers do not up their game urgently, HTC won’t be the only company in serious trouble.