You are on page 1of 14

Mobile software

security
done right
The five big questions that lead to secure
mobile development
By Jacob West
Chief Technology Officer
HP Enterprise Security Products

Plan

Contents
Run

4
2

Build

Value stream 1:
From strategy to portfolio
Who will users hold accountable?

What platform strategy makes sense?

Where should you develop your mobile apps?

11

How do we build secure mobile apps?

13

In a user-centric world, apps are the heart of how people experience the enterprise. Not so
Mobile security self-assessment

Security in the mobile world

Why is mobile security an imperative?

long ago, the task of taking a service from initial request to final production might have been
measured in months. But given todays demands for a constant stream of new capabilities,
we now measure delivery in weekseven days. This brings a monumental change to every
aspect of the strategy-to-portfolio stream.

Of course, if yours is like most IT organizations, you already have IT portfolio processes and
solutions in place. But its likely that you are looking to improve the consistency and quality
of the data that those processes produceand youre probably seeking a broader, more
complete view of how steps in the processes interact.
In the midst of all this, in-house IT often doesnt control the end-to-end design of a system
and instead must become proficient in rapidly brokering and integrating commercially sourced
services and apps as well as creating its own. This has given rise to new development methods
like Agile, and programming and delivery methods like DevOps. The bottom line is that we
must be able to manage the entire service lifecycle so that we can deliver results quickly,
flexibly, and continuously.

Its no longer acceptable for IT to simply align to the


businessit must be a cohesive part of the business, defining
and measuring its value in business terms.
-David Wray, CTO, IT Performance and Governance, HP Professional Services

Security in the mobile world

hy

Todays security-conscious users will hold someone accountable for every security misstep they encounter on mobile devices
even if that accountability is ultimately misplaced.

Wh

What

How

As users increasingly work on mobile devices, HP Security Research expects the number of threats and vulnerabilities to grow
precipitously in the years ahead.

With security challenges looming, organizations must develop a security strategy that encompasses the varied choices they will
have to make in the fast-changing mobile ecosystem.

Five questions to lead decisively


Here are five questions that enterprises must askand answerto set a foundation for a robust, cost-effective mobile
application security strategy.
1. Why is mobile security an imperative?
Intense worldwide mobile adoption rates are putting a finer point on the responsibilities of mobile app purveyors.
2. Who will users hold accountable?
The perception of fault for vulnerabilities in mobile apps is decided by users.
3. What platform strategy makes sense?
Native apps, once the default choice for many enterprises, often create unnecessary security and support challenges
compared to hybrid or cross-platform alternatives.
4. Where should you develop your mobile apps?
From in-house development to boutique mobile-centric outsourcers, where an app is built introduces important tradeoffs.
5. How do you build secure mobile apps?
Security best practices for building traditional software can often be easily adopted by mobile development projects.
When it comes to secure mobile development, one size does not fit all. Each organization must fully absorb the issues that
underlie these five questions. Only then will you have the foundation you need to create a mobile app strategy that offers the
best protection for your business and, most importantly, for your users.
We tackle each of these questions on the following pages.
3

Where

What

How

Wh

hy

Where

Why is mobile security an


imperative?

Device type
PC (Desk-based and
Notebook)
Ultramobile
Tablet

2012

2013

2014

2017

341,263

315,229

302,315

271,612

9,822

23,592

38,687

96,350

116,113

197,202

265,731

467,951

Mobile phone

1,746,176

1,875,774

1,949,722

2,128,871

Total

2,213,373

2,411,796

2,556,455

2,964,783

Source: Gartner (April 2013)

We are in the midst of a huge shift in the technologies people depend on. In Q4 of 2010, the
industry shipped more smartphones than PCs (laptops and desktops combined) for the first
time. Gartner projects a steady decline in desktop devices and a sharp rise in shipments of
mobile devices in the years to come.
In some developing countries such as India, traffic generated by mobile devices has already
surpassed the traffic originating from traditional PCs. While this isnt yet the case in the United
States or Europe, the trend is spreading worldwide and impacts the way enterprises connect
with customers, partners, and employees.
As an industry, were moving away from traditional desktop computers in favor of mobile
devices for all aspects of our IT interaction. As a result, mobile has become the major area of
growth for IT and development investment.
Clearly, enterprises must adapt to a mobile world. Perhaps less clear, however, is the fact that
organizations that do so without properly accounting for security will put themselves at a
rapidly growing disadvantage compared to their security-aware competitors.

Worldwide device shipments by segment


(Thousands of units)

What

How

Wh

hy

Where

Who will users hold


accountable?

Organizations are not, for the most part, being held accountable for the level of security in
their mobile applications. This is because large-scale public breaches still occur far more often
in web and traditional infrastructure applications than in mobile applications. But thats going
to change.

App owners

Network providers

App developers

Manufacturers

Thanks to the rapid adoption of mobile technology, the number of high-profile breaches
resulting from vulnerabilities in mobile apps and their back-end infrastructure is sure to grow.
As this happens, users are going to look for someone to hold accountable. Who will pay the
price?

OS authors

Users

Security is everyones problem

Who will users hold accountable?

App owners
Naturally, users often start with the most obvious association: the app owner. If your logo was
on the app that allowed a users data to be compromised, they might (often rightly) assume
that it was your code that allowed the breach to occur. But app owners wont be the only
targets for user backlash.

App developers
Many users of mobile apps today have no idea who developed them. They often assume the
logo featured in the app is the same as that of its developer, but we know that isnt always the
case. As users become more mature in sourcing their applications, development shops that
dont build security into apps risk incurring ire as well.

Network service providers, device manufacturers,


and OS authors
The biggest cost for the users of mobile devices, in most cases, is the monthly payment for
a data service plan. The network service provider is responsible for the way apps connect to
back-end servers and infrastructure that drive functionality. A compromise might drive users
to send that monthly payment to another provider.
Especially for less tech-savvy users, if something happens to compromise data theyve
entered into a device, they might take out their unhappiness on the device manufacturer by
opting to purchase a device from a competing vendor.
Finally, a users choice of operating system typically governs their choices for acquiring new
apps. Few app vulnerabilities are caused by the underlying OS. However, the association
between an insecure app and the distribution channel over which it was obtained could hurt OS
authors who, like device manufacturers and network service providers, rely on brand loyalty.
In short, every actor in the mobile ecosystem has something to gain from improved software
security for mobile apps. When security incidents occur, everyone in the mobile security
landscape is at risk of losing the trust of their users. In the face of angry users, the perception
of culpability can cost you customers and reputation.
Enterprises with mobile apps should consider how their choice of platform, development
strategy, and delivery impacts users perceptions of fault, and work with partners who are
building user trust in the entire ecosystem.
6

What

How

Wh

hy

Where

What platform strategy


makes sense?

Native versus hybrid


In the early days of smartphones, we saw a lot of companies jump straight into native app
development (primarily Apple iOS and Google Android). We saw it even for apps that didnt
require the advanced access to hardware and user interface capabilities that native apps
provide. Despite gaining no particular advantage, organizations burdened themselves with
multiple development initiatives to support multiple platforms, and faced a corresponding
multitude of security challenges.
Companies are beginning to wise up. Many will soon trade native app development for a single
solution that spans as many platforms as possible. Gartner supports this theory: By 2015, 80
percent of available apps will be either pure mobile-optimized web applications or hybrid apps
that support multiple platforms by rendering web content in lightweight native containers
generated from source code written once and compiled to multiple target platforms.

What platform strategy makes sense?

The delivery issue

Choosing a secure language

Increasingly, the app store is going to be the control point for mobile security. Once a
vulnerable or malicious app has been delivered to the device, its too late to find and eliminate
it effectively. Its far more effective to make the choke point at the point of delivery, where
resources are more plentiful and no damage has been done.

Finally, when it comes to platform strategy, consider the inherent security of the programming
language that underpins your targeted platform.

Gartner says that by 2017 or 2018, 25 percent of enterprises will have their own enterprisespecific application store for delivering applications to their users. Google Play supports a
model for enterprises that want to create their own app stores, but does little to account for
security.
The advantage of the Apple modela closed app storeis centralized control over the
ecosystem. Apple has a lot of control over what can be delivered to devices, as well as the
ability to revoke applications from devices if the app is found to be vulnerable or malicious.
However, enterprises that want to go beyond Apples efforts to secure app downloads have
few options.
As the market becomes more saturated and competition for remaining market share grows
more intense, security at the app-store level will be a key differentiator. This differentiator will
impact not only commercial app stores, but also enterprises that want to provide secure apps
for their workforce.

Objective-C, the language iOS apps are written in, has been around for some time, yet was
not widely known before iPhones became popular. Because of this pedigree, Objective-C has
legacy challenges:
1. It is not type- or memory-safe, which means buffer overflows are a major risk for
developers building iOS applications.
2. Because it wasnt widely used in enterprises before iOS, the industry does not have a
decades-long backlog of experience, tools, and processes to support secure development.

In contrast, Android applications are written in Java. This is advantageous for the typical
enterprise, which has ample Java development expertise already in house. There is also a
much longer history of tool support and processes to support secure development in Java.
Finally, Java is a more modern language, which means we can rule out problemssuch as
buffer overflowsthat only result from type-unsafe languages like Objective-C. Of course,
ruling out a single class of vulnerability doesnt guarantee any meaningful level of security.
While security issues wont be the only factor in your platform decision, these issues are a
major driver pushing enterprises back to mobile-optimized web applications.

What

How

Wh

hy

Where

Where should you develop


your mobile apps?

In-house

Traditional
outsource

Boutique/mobile
outsource

Very few companies today write all of their own code. Outsourcing relationships are the norm,
not the exception. Mobile growth means accelerated delivery expectations, and that has led
many companies to further increase their outsourcing. In particular, companies are often using
specialized boutique development firms that only build mobile applications. But is it a good
idea?
Lets consider the pros and cons of mobile development options:

Control
Integration
Reuse

Knowable expectation
Influence

Speed
Specialization
Expertise
Cost

Speed
Cost

Specialization

Unknown expectations
Influence/control

The ups and downs of mobile development options

Where should you develop your mobile apps?

In-house development

Traditional outsourcing

Boutique firms

Pros

Pros

Pros

Leverages your existing investments in infrastructure


and process.

Removes surprises, as expectations for long-term


outsourcers are already established.

Makes it easier to integrate new development with


existing systems.

Provides you with greater influence over the way the


software is built than you might have with a new
company or a specialized outsource firm.

Provides control over the secure development lifecycle


used to build the software.
Maximizes ROI on existing secure development
processes by extending them to mobile.
Cons
Increases training costs for staff on new technologies,
such as for Objective-C or developing on the Android
platform.

Cons
Makes it harder to find specialized talent on mobile
development.
Doesnt change your accountability for the security of
your applications. You must be able to validate that
the software is secure when accepting delivery.

Can deliver apps more quickly and at lower cost than


the alternatives by utilizing specialized talent for
delivering mobile applications on different platforms.
Cons
Tend to focus on delivering a consumer product very
quickly, which may lead the firm to have a lack of security
expertise or engineering depth.
Can struggle with back-end integrations due to a lack of
experience and limited access.
May have development and security processes that are
not open to external influence.

Requires diligence when adding on to legacy applications


to avoid introducing risk by exposing new capabilities.
Requires mobile platformspecific knowledge in the
central security team.

10

What

How

Wh

hy

Where

How do we build secure


mobile apps?
Security for mobile app development isnt terribly different from security for traditional
application development: all the core principles of the traditional client-server relationship still
apply. So what do we know about how companies build secure software?

Reactive: assessing
and remediating code
Security team alone
responsible for
security
Small set of programs
Addressing software
security after the fact
High IT value

In place: software
security required
before production
Security team works
with development on
security
All critical software
secure
Solving software
security during
development

Proactive: instilling
best practices into
future code
Development takes
over responsibility for
security
All enterprise
software embedding
security into software
development lifecycle
(SDLC)
High strategic value

High business value

Explore

Accelerate

Optimize

At a high level, most companies move through three levels of maturity when rolling out a
software security initiative.

Level 1
The first level of maturity is the establishment of a central security team whose job is to run
vulnerability assessments on a very small set of the most important applications, looking for
the most serious vulnerabilities. The central security team eliminates the highest-risk issues,
but its a reactive model that does not scale well. Typically, the central security group is just 2
percent of the size of the software development team. The exclusively centralized model is
not designed to address all security risks, and increasingly this is what companies must do.

Level 2
The next level of maturity is when the central security group begins to work very closely
with the development team, helping them perform security assessments and raising their
awareness about secure coding practices. In this model, the central security team focuses on
sophisticated issues, while the coding team takes responsibility for simpler tasks.

Level 3
Software security assurance journey

At the most mature stage, the development team is responsible for its own security. The
central security group acts primarily as a trusted partner, enabling development, setting policy,
and perhaps creating tool and process customizations.

11

How do we build secure mobile apps?

The state of security maturity


Perhaps the best way to learn best practices for software security is to look at what other
organizations are doing. The Building Security in Maturity Model (BSIMM) makes this
information available in aggregate across the software community.
The BSIMM is a study of real-world software security initiatives, organized so that you can
determine where you stand with your software security initiative and how to evolve your
efforts over time. BSIMM4 describes the software security initiatives at 51 well-known
companies. All told, the BSIMM describes the work of 974 software security group members,
working with a virtual team of 2,039 people in other roles to secure the software developed by
218,286 developers. On average, the participants have practiced software security for nearly
six years (with some initiatives being brand new at first measurement, and the oldest initiative
being 17 years old in September 2012).
BSIMM4 describes 111 activities, organized in 12 practices according to the Software Security
Framework. The study keeps track of how many times each activity was observed in the 51
firms. Here are the resulting data. (To interpret individual activities, download a copy of the
BSIMM document from bsimm.com.)

12

Mobile security self-assessment


If we take the why for granted, there are four questions left to answer as you assess or build a mobile security strategy:
who, what, where, and how.

Who

Your users

What

Platform support;
web or hybrid over
native

Who
Think first about the type of apps you have: What do they do, and who uses them? Who will your users hold accountable for
security mishaps, and how will you respond?

What
Next, think carefully about platform support. Plan to support only those platforms that your users care about, and avoid the
security entanglements of native apps unless your business requires specific capabilities they provide.

Where

In-house
development or
outside?

Where
Decide on the best strategy for app developmentin-house, traditional outsourcer, or boutique mobile development firmto
meet your needs. If you go for in-house development, make sure you retain the right security expertise and adopt a secure
development process.

How

Secure delivery

How
Finally, decide on a development and delivery mechanism for your mobile apps that gives you control and accountability.
By asking these questions up front, youll develop a thorough strategy for mobile app security that not only protects your users,
but also guards the organization against the damaging effects of security missteps.

13

For more, visit HPs page on mobile application security, and go to Fortifymyapp.com
to assess the security of mobile apps youve already developedincluding a free tool
to test your code.

Jacob West is chief technology officer for Enterprise Security Products (ESP) at HP. In his
role, West influences the security roadmap for the ESP portfolio and leads HP Security
Research (HPSR), which drives innovation with research publications, threat briefings, and
actionable security intelligence delivered through HP security products.
A world-recognized expert on software security, West co-authored the book Secure
Programming with Static Analysis with colleague and Fortify founder Brian Chess in 2007.
Today, the book remains the only comprehensive guide to how developers can use static
analysis to avoid the most prevalent and dangerous vulnerabilities in code.
West co-authors the Building Security in Maturity Model (BSIMM) and speaks frequently at customer and industry
events, including RSA Conference, Black Hat, Defcon, and OWASP. A graduate of the University of California, Berkeley,
West holds dual degrees in computer science and French, and resides in San Francisco.

More From Discover Performance


Follow the evolution of IT leadership at HPs Discover
Performance site, and subscribe to get the best of our articles
delivered directly to your inbox twice a quarter.
hp.com/go/discoverperformance
Copyright 2013 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice. The only warranties for HP products and services are set forth in the express
warranty statements accompanying such products and services. Nothing herein should be construed as constituting an additional warranty. HP shall not be liable for technical or editorial errors or omissions
contained herein.

You might also like