MOBILE SECURITY - CoDI€¦ · Module 1: Understanding Security Windows Phone Overview •...

MOBILE SECURITYStudent Guide

Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide

mGovernment 4

This is the first of a series of modules in the Security Track. This module has two

objectives:

First to convey an understanding of why mobile (wireless) security is so

fundamentally different from the wired systems that have been the mainstay of

IT systems in the past.

The second objective is to list and describe the four types of mobile phone

platform with an eye towards how the manufacturers of these products deal

with the security challenges. That part of the topic is covered in later modules.

CONTENT

THEMES

• Architecture, Security

Module 1, mGov Training Introduction

mGovernment

Module 1 : UnderstandingSecurity

5

Understanding Security

Module 1, mGov Training IntroductionModule 1: Understanding Security

LEARNING OBJECTIVES


mGovernment 6

This module introduces the objectives:

1. Understand the fundamental wireless security difference.

2. List the four handheld platforms and understand their origins.

mGovernment 7

Module 1: Understanding Security

• Understand the fundamental wireless security difference.

• List the four handheld platforms and understand their origins.

Objectives

LEARNING OBJECTIVES


mGovernment 8

1. Introduce Sun Tzu.

2. Introduce the idea that to understand defense, you must also understand

offense.

CONTENT

We begin the journey of starting to think like security people by going back to

ancient times…

Circa 500BC when Sun Tzu said in his book The Art of War: “Know your enemies

and know yourself, and you need not fear the result of 100 battles.”

This is as true today as it was in 500BC. So let us start thinking like the adversary.

Mobile government services depend on wireless connection interfaces.

That is the whole point of mobile – to get untethered from the wire. Why is it

that hackers (the adversaries) find wireless (mobile) systems more vulnerable to

attack?

mGovernment 9

How To Think About Security


Know your enemies and know yourself,

and you need not fear the

result of 100 battles.

Paraphrased Translation, Sun Tzu – The Art of War,

circa 500BC

• To know our enemy, we must

become our enemy.

• To know how to defend ourselves,

we must know how to attack

ourselves.

Sources

https://en.wikipedia.org/wiki/Sun_Tzuhttp://classics.mit.edu/Tzu/artwar.html

LEARNING OBJECTIVES


mGovernment 10

Why is wireless security fundamentally different? Let’s do a little experiment and

see if we can answer that question.

Consider the visual of 4 volunteers to help convey this concept.

Two of the volunteers each take one end of a computer network cable called a

Category 5 or Cat 5 cable. They pull it taught. The two volunteers in our visual

description represent critical servers communicating with each other over that

dedicated connection in the datacenter.

The third volunteer is the datacenter security manager whose job is to protect

the data traveling over this wire between the two servers. To make the visual

more interesting, let’s have the security manager reading a newspaper to pass

the time – waiting for something to happen.

The fourth volunteer represents an attacker. The stage is now set. In order for

the attacker to gain access to the data on this wire, he or she has to physically

penetrate the datacenter, and physically access (touch) the network cable inside

of that data center.

CONTENT

1. Understand that the fundamental difference between wired and wireless

network security stems from the physical layer

mGovernment 11


• Why is wireless security different?

• Need four volunteers….

• Hopefully, this:

• Helped you focus your thoughts on

the wireless difference

• Enables you to explain why wireless is

different to your peers and bosses

Demo


mGovernment 12

CONTENT

The datacenter security manager is diligent. He is keeping watch, ready to

defend the security of the data center. As the attacker reaches for the wire, the

datacenter manager rolls up that newspaper that he was reading and repels the

attack.

Volunteers, thank you.

This may seem like a silly demonstration, but consider: If an attacker wants

access to the data on this wire, he has to physically touch the wire. This is the

point – a rather obvious point.

But how does it work with Wireless? Is it the same? Not at all. If you can hear my

voice, you are in radio range, and you have access to the media. With wired,

the security is in the physical layer as in the wire. With wireless there is not the

same physical layer to provide protection and isolation. The radio frequency is

readily accessible from the parking lot of the building and with the right

technology possibly even much farther away. In wireless there is no need

to gain entry into the building and face the security manager. That is how

fundamentally different wireless is and why we need to recognize this in

our planning for securing the mobile (wireless) communications. Think

encryption.

As a way to wrap up this demonstration remember back to your time as a child.

Many of you may have played with tin can telephones. In order to hear the audio

mGovernment 13


CONTENT

in the can it requires that you hold the can in your hand, next to your ear. In

other words, you have to touch the media, the string and the cans. With a

normal voice conversation that’s not necessary, and neither is it with wireless.

Hopefully, this helps bring to focus the fundamental difference between the

security needed for wired and the security that is needed for wireless. It may

also provide a tool or two to help you explain this to others.

LEARNING OBJECTIVES


mGovernment 14

CONTENT

Consider the four major handheld smart phone platforms in the UAE market.

These are the four that the Telecommunications Regulatory Authority, TRA

tracks closely. There are others which may gain market share in the future. But

for now these are the major players.

Each of these platforms has its own strengths and weaknesses, but they all share

one feature; they will all be communicating with Back End computing resources

in the data center. So we really have to worry about not four, but five potential

security problem areas, each of the platforms and the computer system

resources that we find in the Back End.

1. Introduce the 4 major handheld platforms.

2. Emphasize that the problems is not limited to the handheld.

mGovernment 15


• Common Mobile Platforms

• BlackBerry

• Windows Phone

• iOS

• Android

• 1 App = 5 Problems

• 4 Platforms = 4 Problems

• +1 Backend = 5 Problems

mGov Security Problems

Glossary

TRA

Back End

LEARNING OBJECTIVES


mGovernment 16

CONTENT

Let’s look into a little more detail, beginning with the Blackberry.

The Blackberry Operating system came out in 1999, and underwent major

revisions in 2013. We refer to it as a proprietary operating system since it is not

open, but it is based on a Unix operating system variant called QNX. QNX is quite

mature and robust, and was open at one point before blackberry bought QNX

and withdrew the public code.

Today blackberry runs native code specifically built for its QNX version of

its own devices, as well as a subset of Android applications, all on handsets

manufactured by Blackberry.

Blackberry is the only platform that was originally designed for use

in business and government. It is well recognized in the industry as a

platform where security was and remains a primary design consideration.

1. Introduce the Blackberry.

2. Understand that when we discuss Blackberry we must consider the

Blackberry Enterprise Server.

3. Understand that Blackberry is the only one of the four platforms with

business and government origins, not consumer.

mGovernment 17

Developer Site: developer.blackberry.com


• Proprietary OS

• BlackBerry OS

• Released in 1999

• Java Virtual Machine (JVM) based

• BlackBerry 10 OS

• Released January 30, 2013

• Based on QNX Kernel

• Android runtime layer

• “Security First”

Engineered around Security

BlackBerry Overview

LEARNING OBJECTIVES


mGovernment 18

CONTENT

1. Introduce Windows Phone.

The modern version of the windows phone was introduced in 2010.

It actually shares commonality with the Windows 8 operating system, including

being based on the NT operating system kernel.

The Windows phone operating system or OS is licensed by Microsoft to handset

manufacturers, so it runs on several handset devices from different vendors.

These are consumer-oriented devices. This means that unlike the Blackberry

security was not a primary design consideration of the devices or the OS, and

they have a relatively small share of the UAE smart phone market.

mGovernment 19

Developer Site: www.windowsphone.com


Windows Phone Overview

• Proprietary OS

• Windows Mobile OS


• Support ended January 2013

• Windows Phone OS


• Not backwards-compatible

• Based on Windows NT kernel

• “Security Second”

Usability most important

LEARNING OBJECTIVES


mGovernment 20

CONTENT

1. Introduce iOS and the iPhone.

Apple introduced the iPhone in June of 2007 and it revolutionized the smart

phone market, displacing Blackberry, Nokia, Palm and others who were early

smart phone market leaders.

iOS has Unix roots, is currently on version 9 and runs on iPhone 5 and 6 handsets,

as well as iPads. All are manufactured and sold by Apple.

Like the Windows Phone, these are consumer-oriented devices, meaning

security was not a primary design consideration, even though there is a robust

set of security controls and features in the hardware and OS.

mGovernment 21


iOS Overview

• Proprietary OS

• Based on Unix (BSD) Kernel

• First released June 2007

• iOS 6

• No longer developed

• Last update was February 2014

• iOS 9

• Current iOS version

• iPhone 5; 6 models

• All current iPad models


• Usability most important

Developer Site:developer.apple.com/devcenter/ios/

LEARNING OBJECTIVES


mGovernment 22

CONTENT

1. Introduce Android.

Google developed the Android operation system and released it in 2008. It, like

iOS has roots in Unix, in this case being based on the Linux kernel.

Unlike the other three major platforms, the majority of the platform and its

default utilities are open source, which means Google publishes and allows you

to read and modify the source code.

The current version (as of the second Quarter 2014) of Android released by

Google is 4,4, codenamed KitKat, although not all hardware manufactures are

selling devices with the latest version, or providing updates to it. Android 5.X has

been released, but not universally adopted.

Android is also a consumer device, but with a quite robust security model.

As we explore these platforms in later modules of instruction, you will find that

we spend more time discussing Android than the other platforms. That is simply

because it is an open platform, and we know more about it.

mGovernment 23


• Open Source OS

• Based on Linux Kernel

• Released October 2008

• Android 4.1 – 4.3 – Jelly Bean

• Released July 2012 (v4.1)

• Android 4.4 – KitKat

• Released October 2013

• Introduced new run-time environment.

• Android 5.X available.


• Usability is most important, but…

• Built on a very secure, common kernel

Android Overview

Developer Site: www.android.com


mGovernment 24

CONTENT

It is important to emphasize the origins of the four major platforms under

consideration.

Blackberry is the only one of the four with roots in business and government, and

its security features reflect that.

However, understand that unless your agency is furnishing devices to your

customers or employees, the choice of platform is out of your control.

This means you need to understand your user base, and to be prepared to

support all of them.

1. Discuss Platform Origins.

LEARNING OBJECTIVES

mGovernment 25


“You don’t know who you are unless you know where you came from.”

• Designed for Consumers:

• iOS (iPhone, iPod, iPad)

• Android

• Windows Phone

• Designed for Business and Government:

• BlackBerry

Platform Origins

LEARNING OBJECTIVES


mGovernment 26

Review the Objectives (re-read the slide).

CONTENT

1. Understand the fundamental wireless security difference.

2. List the four handheld platforms and understand their origins.

mGovernment 27

• Objectives

• Understand the fundamental wireless security difference

• List the four handheld platforms and understand their origins

Review of Objectives


QUIZ


mGovernment 28

It is now time to review your knowledge

of this material


mGovernment 29


Quiz – Question 1

Quiz – Question 2

1. Wireless network security is different from wired network

security because of the fundamental differences at the Physical

Layer?

Select one:

a. True

b. False

2. Blackberry is the only one of the four platforms with business and

government, not consumer origins?

Select one:

a. True

b. False


End of Module


mGovernment 32

In this module we review the words from two well-known figures in the security

industry: Dan Geer and Jimmy Kuo. Dan and Jimmy say similar things about the

inherent problem facing us in the security community and the public at large

who are impacted by this inherent problem.

CONTENT

THEMES

Architecture, Security, Business Processes & Collaboration.

• Accessed through the web browser

• Deployed over Internet

• Can develop/design one application for all platforms

• A cross-platform mobile application

• Provides uniformity across all platforms

• Near-instant updates

• Updates to the application are actually updates to the website,

happening on the back-end

Introduction

SDLC: Service Delivery Lifecycle

Glossary

mGovernment 33

Module 2: Architectural Overview Understanding the Problem

Architectural Overview

Understanding the Problem

LEARNING OBJECTIVES


mGovernment 34

Introduce the Objectives, (read the slide).

CONTENT

This module has these objectives:

1. Understand Dan Geer’s “Structural Problem”.

2. Understand Jimmy Quo’s “Cops and Robbers” analogy.

mGovernment 35

Objectives


• Understand Dan Geer’s “Structural Problem”

• Understand Jimmy Quo’s “Cops and Robbers” analogy

LEARNING OBJECTIVES


mGovernment 36

CONTENT

1. Begin to understand Dan’s point.

In his foreword to Carlos Solari’s Security in a Web 2.0+ World, Dan Geer said: “We

are many. They are few. We are losing. They are winning. The reason is structural.”

By “We” he refers to the Information Security community, by “They” he means

the hackers or attackers, in other words, the bad guys.

We’ll expose the structural reason that Dan is talking about in the next several

slides. At the end, we review another point of view on this issue that addresses

the perceptions surrounding this problem.

mGovernment 37


Sources

“We are many. They are few.We are losing. They

are winning.The reason is structural.”

Dan Geer in the Foreword to Security in a Web 2.0+ World by Carlos Solari and Colleagues

http://eu.wiley.com/WileyCDA/WileyTitle/productCd-0470745754.html

LEARNING OBJECTIVES


mGovernment 38

CONTENT

In the next series of slides we take an admittedly simplified view of the IT systems

development. As the web outgrew its humble beginnings of static web pages, we

moved to dynamic content.

At first this was pretty simple. A generation of software programming languages

were re-purposed or came to be to make it easier to achieve this very need –

how to move from the humble static web pages to the ways that we now take for

granted when we interact with a web site.

One of the first languages re-purposed was PERL. PERL programs allowed

the web server to talk to a backend database using a construct called CGI, or

Common Gateway Interface. We had moved from static informational pages on a

web server to the ability to query a database. Progress.

1. Understand the origins of web applications, and in the coming slides, their

evolution.

mGovernment 39


Brief History of Web Software

GLOSSARY

PERL: Practical Extraction and Reporting Language.

CGI: Common Gateway Interface.


mGovernment 40

Along come the security guys, alarmed at the idea that someone on the Internet

could have unfettered access to the internals of a corporate database.

They arrived after the fact as usual, with a firewall and some secure socket layer

or SSL encryption to protect the connection.

You may remember that SSL originated from one of the first commercial

browsers called Netscape.

This is part of the structural problem. The security features, in this case, SSL and

a firewall, were added after the fact, not built into the design and architecture

from the beginning. This is the beginning of the trend we see continue even to

this day.

CONTENT

mGovernment 41


Brief History of Web Software and the security approach

Glossary

Firewall: A policy enforcement device that controls traffic between two

networks.

SSL: Secure Sockets Layer.

LEARNING OBJECTIVES


mGovernment 42

CONTENT

1. Expose the format we will use for the next several slides.

As an aid to see the trend we put this instance in time into a table:

The format of the table is: the Date, the enabling web technology, and the

security countermeasure to the risk created by that technology.

The date was circa 1995, the technology was CGI/PERL, and the countermeasures

were a network firewall to enforce policy and SSL to encrypt the connection.

mGovernment 43


First Revision

LEARNING OBJECTIVES


mGovernment 44

CONTENT

1. Begin to see the evolution and increasing complexity in the architecture.

In this next slide we take another snapshot in time – an evolution in web services

capability. Note the innovation inside the web server. Now we have Java Server

Pages and Active Server pages for more rich dynamic content, better session

data, etc.

• What was the corresponding security countermeasure?

Proceed to the next slide and what do we see?

mGovernment 45


Glossary

Evolving Web Software

JSP: Java Server Pages, dynamically generated web pages.

ASP: Active Server Pages (Microsoft scripting for the server side).


mGovernment 46

CONTENT

The answer is not much. Firewalls improved, SSL improved, the security

industry started to take notice and began to develop other after-the-fact

security products to aid in countering the increased risk. This and the following

slides emphasize that as “the web” evolved toward what we now know, the

security mechanisms largely did not.

We still depend on SSL and firewalls of one type or another for the bulk of

our protection. The security trend has been to stay the same even as the risk

continued to rise and hackers started to show their skills in ever-increasing and

alarming ways. Breaking in to the network and gaining access to the web sites

was now old.

Breaking into the web application and gaining access to the database of account

information, credit card information was now the purpose.There was money to

be made – criminal money.

mGovernment 47


Year Software Security

1995 CGI/PERL Network firewall & SSL1997 JSP, ASP Network firewall & SSL

Second Revision Innovation?


mGovernment 48

Continuing on we are now in the multi-tiered back end.

• Has the security mechanism evolved?

CONTENT

mGovernment 49

EJB: Enterprise Java Beans: managed server-side component for modular

construction of enterprise applications.

DCOM: Distributed Component Object Model: MS technology for software

distributed across the network.

Glossary

Evolving Web Software (2)



mGovernment 50

CONTENT

The answer to the question from the previous slide is “no”.

Note that the software and architecture is becoming more complex, but

the countermeasures remain largely the same. Yes, there are a host of other

security technologies that entered the marketplace – all of them following

the trend of trying to patch vulnerable systems.

The web services were in such high demand that there was no time given

to the idea that maybe this was not such a good trend. Maybe it was time to

go back and start re-engineering all of this new innovation to make sure that

it was secure. It was 1998 – in the midst of a global tech bubble.

mGovernment 51


Third Revision Innovation?


1995 CGI/PERL Network firewall & SSL1997 JSP, ASP Network firewall & SSL1998 EJB, DCOM Network firewall & SSL


mGovernment 52

In this third generation of the evolving web software we see technologies and

protocols designed to make it faster and easier to get to that rich data in the

back-end. It just keeps evolving…What about the security?

Well yes, there was something new that was added to mitigate against the

growing risk and the hackers who were having their way.

But it was not a net new addition – it was just another firewall added to create

the DMZ and other compartmentalization inside the back end.

SOAP: Simple Object Access Protocol…a protocol for exchanging structured

information in the implementation of web services in computer networks.

XML: Extensible Markup Language.

RDBMS: Relational Database Management System.

ERP: Enterprise Resource Planning.

CONTENT

Glossary

mGovernment 53


A Spectrum of mGovernment Service Delivery Formats

The mGovernment Mission


mGovernment 54

So, yes, multiple firewalls came in at some point.

Some of them were specialized technology, specifically Web Application

Firewalls. Still, the story is the same one, it is protection technology added

after the fact and not dealing with the root of the problem – still adding more

band-aids.

CONTENT

mGovernment 55

Web Application Firewall: An application-layer firewall specifically designed

to protect web applications.

Glossary

Fourth Revision Innovation?



1995 CGI/PERL Network firewall & SSL1997 JSP, ASP Network firewall & SSL1998 EJB, DCOM Network firewall & SSL1999 SOAP, XML Network firewalls & SSL

LEARNING OBJECTIVES


mGovernment 56

CONTENT

At this point in the history, we can see that the architecture has become

rather sophisticated and very complex. It is a relatively common architecture

these days.

Note the link out to a Partner Application Server. The inevitable began to

happen. In order to streamline the supply chain, IT shops began to connect

directly to partner networks to gain access to their applications – sharing

information directly. The security people and the network people don’t even

have control any longer.

It is a shared control at best or better said, a combined risk with partners

who may common needs but may have entirely different regard for what

constitutes adequate security and even different business agendas.

1. Understand that the complexity is becoming difficult to understand.

Glossary

mGovernment 57

CRM: Customer Relationship Management.

Evolving Software (4)



mGovernment 58

CONTENT

The software and architecture continue to evolve. The story has not changed.

Continue through the next few slides and let us bring this to a conclusion.

mGovernment 59

Glossary

SOAP: Simple Object Access Protocol.

REST: Representational State Transfer.

Fifth Revision Innovation?



1995 CGI/PERL Network firewall & SSL1997 JSP, ASP Network firewall & SSL1998 EJB, DCOM Network firewall & SSL1999 SOAP, XML Network firewalls & SSL2001 SOAP, REST Network firewalls & SSL


mGovernment 60

In this slide we see the evolution, to Web 2.0 when the web matured beyond

static web pages to interactive information.

CONTENT

mGovernment 61

Glossary

Web 2.0: Web 2.0 suggests a new version of the World Wide Web,

it does not refer to an update to any technical specification, but

rather to cumulative changes in the way Web pages are made and used.

Sixth Revision Innovation?



1995 CGI/PERL Network firewall & SSL1997 JSP, ASP Network firewall & SSL1998 EJB, DCOM Network firewall & SSL1999 SOAP, XML Network firewalls & SSL2001 SOAP, REST Network firewalls & SSL2003 Web 2.0 Network firewalls & SSL


mGovernment 62

And evolve it did. Now with the introduction of “Cloud”, you may not be

sure where your data and computing are, which country, continent, etc.

The security industry continued to offer new innovations in the same

ineffective way by layering on security technologies. The root of the problem

started to become clear now. It is vulnerable software code. It is the lack of

foundations of trust. When an operating system is compromised should that

system continue to be trusted? It is if you are not aware of the compromise.

What has been the way to deal with this expanded risk? The same tired

answer: Firewalls and SSL with a host of other similar security technologies. Dan

and Jimmy are right. This is not a revelation. It is old news.

But we have not advanced the security model.

CONTENT

mGovernment 63

Seventh Revision Innovation?



1995 CGI/PERL Network firewall & SSL1997 JSP, ASP Network firewall & SSL1998 EJB, DCOM Network firewall & SSL1999 SOAP, XML Network firewalls & SSL2001 SOAP, REST Network firewalls & SSL2003 Web 2.0 Network firewalls & SSL2007 Cloud Network firewalls & SSL


mGovernment 64

And we finally arrive at mobile. Notice the trail of evolution in the Software

column, and the relatively static nature in the Security column.

With minor exceptions, there has been almost no evolution with firewalls or SSL

technology in this time. The reason is structural.

CONTENT

mGovernment 65

We’re now at Mobile Innovation?



1995 CGI/PERL Network firewall & SSL1997 JSP, ASP Network firewall & SSL1998 EJB, DCOM Network firewall & SSL1999 SOAP, XML Network firewalls & SSL2001 SOAP, REST Network firewalls & SSL2003 Web 2.0 Network firewalls & SSL2007 Cloud Network firewalls & SSL2009 Mobile Improvement needed

LEARNING OBJECTIVES


mGovernment 66

CONTENT

Building on the previous several slides, note the evolution of the technologies on

the back end and of the overall complexity of the environment, and the relative

lack of parallel evolution in the security controls.

We are STILL depending upon after-the-fact security controls rather than secure

design, architecture and coding.

The product developers / vendors continue to supply us, the end users, with

what are essentially defective products, and placing the responsibility to secure

them and the resulting infrastructure on us.

This is the structural problem to which Dan Geer refers.

Another problem is related to perceptions. It is possible “to win”, but refer to the

next slide.

1. Understand that the nature of the problem is largely structural.

mGovernment 67

The Reason is Structural


We are trying to fight this

problem…

…with this older, simpler way of

thinking.

We are not winning now – the reason is structural.

We need a new way

LEARNING OBJECTIVES


mGovernment 68

There is a good lesson here, one that you may read on your own.

Jimmy came up with this around 1 June 2014, and it relates directly to the

perceptions in and of the security community.

The security professionals can succeed or win 1000 times, and their one loss or

failure will end up on the front page of the paper.

The bad guys fail correspondingly as often as we succeed, but you never hear

of that. One win for them results in a failure for us, and we wind up in the paper

again.

This is not fair, but it is real, and the way the world works.

CONTENT

1. Understand the perception component to the structural problem.

mGovernment 69

We’re living in the same world and media circumstances as the cops against

the robbers. The cops have to prevent every crime, but they can’t. The

robbers only have to succeed once, and they’ll make the news, even if it’s

against the most hapless of all potential victims. In fact, the more hapless,

the better the media plays it up. The hapless, after all, are the people who

need the most protection, which the cops were not able to provide.

Occasionally, the cops catch a stupid criminal. And once in a while, the

criminals band together to form gangs. And when that gang creates a big

enough splash, or they piss off the wrong people, the cops take them down.

You know some of the criminals collaborate and trade secrets.

But ultimately, each is in it for his own personal and disjoint benefit. You

know the cops definitely cooperate to do a better job. Their salaries are

hardly a fraction of what the criminals take in. But they do it for their ethics

to be on the right side of Good. Security researchers are of that vein.

It’s not whether the good guys are better or the bad guys are better. It’s

who is able to sleep better at night knowing his ethics align with the great

society we’re all in.

Jimmy Kuo

Senior Architect, Symantec

Jimmy Kuo’s POV:


LEARNING OBJECTIVES


mGovernment 70


CONTENT

1. Understand Dan Geer’s “Structural Problem”.

2. Understand Jimmy Quo’s “Cops and Robbers” analogy.

mGovernment 71

• Understand Dan Geer’s “Structural Problem”.

• Understand Jimmy Quo’s “Cops and Robbers” analogy.



QUIZ


mGovernment 72


of this material


mGovernment 73


Quiz – Question 1

• To complete this module you will need to correctly

answer the End-of-Module Questions. Proceed by answering the first

question.

Dan Geer wrote: “We are many. They are few.

We are losing. They are winning. The reason is structural.” He was talking

about (pick all that apply):

Select one/ or more:

a. The problem of the supply chain where current practice is that

security is expected to be something done by the end-users of

technology devices.

b. That security needs to become part of the systems development

lifecycle (SDLC) in order to change the structural reasons why we are

losing.

c. That there is no way to win against a hacker.

d. That the end is foretold and we might as well give up.

LEARNING OBJECTIVES

INSTRUCTOR GUIDANCE

1. Define HTML 5 Web Applications.

2. Understand pros and cons of HTML 5.

• Instructors will use the slide text to guide them.

• Introduce HTML5 web applications.


mGovernment 74

End of Module

mGovernment 75


mGovernment 76

CONTENT

Now we will begin discussion of how the architecture will evolve from a security

perspective in the eGov to mGov transition.

Glossary

SYNOPSIS

THEMES

This module covers the introduction to the mGovernment Roadmap and a

discussion of the first track.

Architecture, Security

eGov: Electronic Government, Web-based government services.

mGov: Mobile Government, Government services on handheld, mobile

devices.


mGovernment 7 7

Module 3: A New Architecture

A New

Architecture

LEARNING OBJECTIVES


mGovernment 78


CONTENT

1. This module has these objectives:

• Understand the changes to the architecture required by mGov.

• Expose the class to Attack Surfaces, discussed in detail later.

• Expose the class to the high-level differences with mobile applications.

mGovernment 79


Objectives




LEARNING OBJECTIVES


mGovernment 80

1. Understand a simple n-tier web application architecture.

2. Grasp Basic Terminology, see glossary.

This is a typical, simplified logical diagram of a web-based service as we have in

the eGovernment model. Note the designation of “n-Tier. This means that there

is more than one tier – the n means multiple.

In this diagram there are three that are depicted, within the eGov data center:

the multi-layer back end and the front end.. Again, this is a highly simplified view

of a web-based architecture used here to convey an important security notion.

The “Front End” for eGov is at the boundary of the datacenter, and is typically a

web server. The applications execute (largely) from the front end back to where

data is actually stored, called the “Back End”, all within a datacenter somewhere.

The web browser on the end-user’s computer interprets and displays content

from the front end. In this example, the security between the browser and the

web server is handled by the browser developer and the server developer, and

their security teams. The use of an encrypted channel using secure socket layer

(SSL) is an example of this type of security.

CONTENT

mGovernment 81

Glossary

Front End: The portion of the application that generates the user interface.

Back End: The remainder of the application except for the User Interface.

n-Tier: Multiple Tiered, where the number of tiers is unknown or

unimportant

SAP, Siebel: Example enterprise database solutions.

The n-Tier Architecture (Simplified)


An n-Tier Architecture

Web-based services (eGov)


mGovernment 82

CONTENT

The Attack Surface, or the areas where a Hacker can Attack<CLICK>are

intuitively the physical boundaries of the datacenter, and the public-facing

network interface of the front end in that same data center.

In the eGov services model the browser is a window into the information and the

business logic that is contained in the data center. This is the principal target of

a hacker.

Now proceed to the next slide and consider what happens to the Attack Surface

when the architecture changes to include mGov services.


mGovernment 8 3


The n-Tier Architecture (Simplified)

An n-Tier Architecture

Web-based services (eGov)

LEARNING OBJECTIVES


mGovernment 84

1. Understand the origins of web applications, and in the coming slides, their

evolution.

2. Expose the class to the “Attack Surface”.

CONTENT

With mGov, the “Front End” has moved to some degree out of the datacenter

and into the handset.

<CLICK>

This extends and changes the “Attack Surface” of the overall application, which

now extends from the storage in the back end all the way through the multiple

tiers (the n-tier), over the Internet, across the carrier’s network and into the

handheld where the front end now resides.

We will talk in more detail about “Attack Surfaces” in a later module, but we can

introduce the term and use it here.

Security controls in the eGov world that were implemented by the web

server and browser developers now fall to you, the mobile application developer to

implement in your App software code, and in your back end APIs. The Attack

Surface is now expanded. There is more to defend.

mGovernment 85


Migration to the Mobile n-Tier Architecture (Simplified)


mGovernment 86

GLOSSARY

App: Mobile Application, specifically in this use, the portion of code actually

running on the mobile platform.

API: Application Programming Interface.


mGovernment 8 7


Migration to the Mobile n-Tier Architecture (Simplified)

LEARNING OBJECTIVES


mGovernment 88

Let us now consider an interesting dilemma in this conversation about eGov and

mGov and the terms front end and back end. In the data center point of view,

the terms front and back end have traditionally referred to the servers such as

web application servers as being the “front end” and the intermediate processing

and storage as being the “back end.” Application Developers, however, have a

different perspective for these terms. In their point of view, the “front end” is

the smart device (smartphone or tablet) where the application is running.

The entire data center in their view of the IT infrastructure is the “back end.”

This difference of perspective has the potential to drive inconsistent design

considerations and can create some confusion. From a security point of view

both these perspectives are partly right. The “front-end” is not one or the

other but in fact both. It is important that these differences be resolved in the

migration from the more traditional eGovernment to the new mGovernment

services architecture.

CONTENT

1. Understand that the terms Front End and Back End take on different meaning

depending on perspective and the application architecture.


mGovernment 89

Front End, Back End: The meanings for this can change depending on

architecture or perspective

Glossary

Front End or Back End?

Data Center

Application Developers

Front EndBack End

IT Systems & Network Staff

Front EndBack End

Data Storage Data Servers Mobile Devices

LEARNING OBJECTIVES


mGovernment 90

In this slide it now becomes clear why this is true. Native applications, the apps

loaded on the smart phones that are now the expanded Attack Surface have

additional security concerns. Native apps address the functional shortcomings

of normal web applications that use the mobile platform browser. They take ad-

vantage of the mobile platform itself, its ability to compute, and specifically the

sensors and hardware components of the phone or tablet.

But they also introduce new problems for the developer from a security point of

view. Mainly, the issues that have been traditionally handled by the commercial

browser developers and their security team.are now the concerns of the app de-

veloper and the owner of the apps – each one of them.

Understanding this is challenging.

OWASP: the Open Web Application Security Project gives a starting point on how

to organize this challenge and think through the appropriate mitigations.

1. Introduce OWASP as a resource.

2. Understand more about how the security picture changes with mobile

applications.

CONTENT


mGovernment 91

Glossary

Sources

CoDI: Center of Digital Innovation.

http://owasp.org

Native Apps

• Address limitations of Mobile Web

• Take advantage of mobile capabilities

• Subject to normal security vulnerabilities, e.g.: OWASP Top Ten

• Also introduces new vulnerabilities

• Lost/Stolen

• Secure Storage

• Secure Interaction with different protocols

• Emergent behavior – new protocols, features: NFC, SMS, MMS, GPS,

• Unclear usage patterns

• Privacy is “the third rail”


mGovernment 92

CONTENT

OWASP:

• Is Open Source meaning that it is open to anyone who wants to make a

contribution

• It was started in 2001 and the

• First publication of the standard came out in 2008, as the Application Security

Verification Standard (ASVS) to normalize the requirements for security in the

vendor market

• It now covers mobile as well as web applications

But be mindful that OWASP, like the real world, is always updating, reflecting the

nature of the market, and of the security issues involved.

OWASP is a good resource, and their “Top Ten” lists are indications of common

problems, mistakes, misconfigurations, etc., and of what is being exploited.

The “Top Ten” is periodically revised, so keep checking on it regularly.

Note that the testing performed in the Center of Digital Innovations - CoDI - is

based at least in part on the OWASP Top 10.

With this as background now consider this expanded Attach Surface. New vulner-

abilities come with the mobile platform. Obviously the devices are more prone

to loss or theft, meaning an attacker would have direct physical access to the

device.


mGovernment 93

CONTENT

If the device in question has removable storage, you need to understand the

security properties involved, and that differs from platform to platform.

We cannot predict what the platform (iOS, Android, etc.) developers will include

in new versions, nor can we predict how consumers will use them.

Privacy is of varying concern depending on various factors like societal norms,

the law, etc., but understand this simple observation: information once revealed,

and the Privacy of individuals compromised, cannot generally be restored. We

should always be concerned about privacy even if our users are not (now, yet).

When designing the mobile native app for your government entity, this concern

should be at the top of the list.

LEARNING OBJECTIVES


mGovernment 94

1. Get a glimpse of how the mobile server is evolving.

This next slide is a representational diagram of a modern integrated architecture

of a mobile architecture described here as the Mobile Middle Tier A Security

Token Service, or STS. STS is a software based identity provider responsible for

issuing security tokens, especially software tokens, as part of a claims-based

identity system.

In a typical usage scenario, a client requests access to a secure software

application, often called a relying party. Instead of the application authenticating

the client, the client is redirected to an STS. The STS authenticates the client and

issues a security token. Finally, the client is redirected back to the relying party

and presents the security token. The token is the data record in which claims are

packed. The token is protected from tinkering with strong cryptology.

The software application verifies that the token originated from an STS trusted

by it, and then makes authorization decisions accordingly. The token is creating

a chain of trust between the STS and the software application consuming the

claims.

Completing this description we can now start to appreciate some of the inherent

complexity necessary to create the trusted transactions for mobile services in

general and more specifically government mobile services.

CONTENT


mGovernment 95

Glossary

STS: Security Token Service.

Mobile Middle Tier

Mobile “Thingfrastructure” STS CloudProprietary OS, Access control

Token exchange Standards based Access control

Token by reference Resolve artifacts Token by reference & value

Mobile sessions & permissions Constrain and manage sessions for Mobile clients

Cloud sessions & permissions


mGovernment 96

LEARNING OBJECTIVES

1. Understand the changes to the architecture required by mGov.

2. Expose the class to Attack Surfaces, discussed in detail later.

3. Expose the class to the high-level differences with mobile applications.


CONTENT

mGovernment 97







of this material

QUIZ


mGovernment 98

Quiz – Question 1

1. Which of the following is a role of the PMO ?

a. Design new applications for government

services

b. Convert all government services to mobile

c. Establish policies, standards, and best practices

d. Collaborate with stakeholders


mGovernment 99


Quiz – Question 3

Quiz – Question 2

3. What is capacity building ?

a. Working together to achieve the same goals

b. Increasing the ability to serve more customers

c. Understanding what organizations can do for each other

d. A major responsibility of the PMO

2. Which of the following is an example of a

mobile worker ?

a. A restaurant worker

b. A building inspector

c. An office administrator

d. A teacher

mGovernment 1 0 0


End of Module


mGovernment 1 0 1


mGovernment 102

CONTENT

We will introduce the concept of an SDLC (defined later) and discuss how its

proper application can begin to address the Structural Problem.

THEMES

• Security, Strategy.

• Business Processes & Collaboration.


mGovernment 1 0 3

Module 4: Addressing the Structural Problem with mGov

Addressing the Structural Problem with

mGov

LEARNING OBJECTIVES


mGovernment 104


1. Introduce SDLC.

2. Understand the common aspects of a Development Lifecycle.

3. Understand that the proper application of an SDLC can help address the

Structural Problem.


CONTENT

mGovernment 105


Objectives

• Introduce SDLC.

• Understand the common aspects of a Development Lifecycle.

• Understand that the proper application of an SDLC can help address

the Structural Problem.

LEARNING OBJECTIVES


mGovernment 106

1. Introduce a generic SDLC

This is a grossly simplified view of the SDLC. It is provided to conceptualize how

the SDLC is cyclical, and continues to be relevant long after implementation.

The next slide displays a much more detailed analysis of the SDLC, but lacks the

cyclical display of this one.

The “S” can be System, Software or Security. All are relevant, even though this

is the Security track.

In all cases, the SDLCs share two key features, discussed on the next slide,

and the most important thing to understand is the importance of maximizing

involvement of all parts of the team from the beginning.

SDLC: Security, Software or System Development Lifecycle.

Glossary

CONTENT


mGovernment 107

• A cyclical process which establishes the development, maintenance,

& improvement of a system or application

• Determine what you need

• Design a solution

• Implement the solution

• Test to see if it meets needs

• Maintain it, and then…



• Implement the solution

• Test to see if it meets needs

• Maintain it, and then…



Development Life Cycle (SDLC)

https://upload.wikimedia.org/wikipedia/commons/1/19/SDLC_-_Software_

Development_Life_Cycle.jpg

SOURCES

https://upload.wikimedia.org/wikipedia/commons/1/19/

SDLC_-_Software_Development_Life_Cycle.jpg

LEARNING OBJECTIVES


mGovernment 108

1. Understand the two common features of any Development Lifecycle.

There are two common SDLC factors we want to focus on at a high level:

The first common factor is that all SDLCs contain a start point. It is critical to

maximize participation as early as possible in this phase, to build security into the

process from the beginning. This is the only way to attack the structural problem

we discussed previously.

It is critical from a development point of view to achieve and document

agreement on the scope of the project in the beginning phase.

The second common factor is that these cycles typically do not end. Once a

given cycle is complete, a new one begins based on the outcome of the previous

one.

CONTENT


mGovernment 109

• Start Point

• All Development Lifecycles have a beginning, requirements

definition / analysis

• Maximize Participation

• Cyclical

• Development Lifecycles do not typically end

• In all phases, capture:

• Additional Features

• Bugs

• Enhancements

• Etc…..

• Roll these into Requirements for the next Cycle

SDLC Common Features

LEARNING OBJECTIVES


mGovernment 110

1. Identify some of the details of embedding security in each phase of the

SDLC.

Embed security in ALL Phases, but ensure participation from the beginning.

Ensure Security requirements are captured in the beginning with the functional

and other requirements.

Make sure the architecture allows for defense in depth.

In the design phase, build and consider threat models to flesh out the detailed

security requirements.

Use well understood, known secure frameworks when coding, following good,

secure coding practices.

Integrate security testing, including source code analysis, vulnerability

assessment and penetration testing.

CONTENT


mGovernment 111

Address the Structural Problem – Embed security in the

development life cycle

• Requirements gathering

• Define non-functional security requirements, and align with

functional requirements

• Architecture

• Ensure defense in depth coverage and capabilities

• Detailed design

• Build and analyze threat models to generate detailed security

design requirements

• Development

• Implement frameworks and patterns for common security services.

Follow good secure coding practices.

• Testing

• Integrate source code analysis, vulnerability assessment and security

testing

SDLC

LEARNING OBJECTIVES


mGovernment 112

1. Ensure students understand that the mGov transition represents an

opportunity to address the structural problem.

CONTENT

The mGov project, which is really the continuation and evolution of a long

running effort to modernize government in the UAE, represents an enormous

opportunity to address the structural problem.

Lots of infrastructure will be added, will be changing and modernized, and this is

a chance to get security embedded in the process, not applied afterwards as a

band-aid for the structural problem.

mGovernment 113


• Most security activity is treatment, not prevention

• Most treatment applied to symptoms, not the disease

• The disease is poor program code, poor hardware configuration,

and poor architecture design

• mGov presents an unprecedented opportunity to do security prop-

erly from the start, instead of rushing to fix the problems we could

have avoided

• This allows security to participate in development,

instead of inheriting a broken system from the start

Crisis or Opportunity?

LEARNING OBJECTIVES


mGovernment 114

The choice is pretty simple, and the analogy here is a good one.

CONTENT

1. Reinforce the opportunity, and the consequences of missing it.


mGovernment 115

Which Do You Want?

7

A gram of prevention? A kilogram of treatment?

• Get involved with your Entity’s mGov plans! NOW!

• Don’t get involved.• Bad code will be written• Bad infrastructure designed• Bad management choices

• You’ll have plenty of work to do in the future, cleaning up the mGov Security messes you could have avoided by starting today.

OR

LEARNING OBJECTIVES


mGovernment 116

Returning back to the discussion from the first security module, learning to think

like a security professional includes learning to place yourself in the mindset of

the attacker.

The Hackers Will attack your systems

The Hackers Will find your weaknesses

The Hackers Will successfully break in

The Hackers Will steal data and sell it

The Hackers Will do it again

The Hackers Will always be there

The Hackers Will never stop

The Hackers Will grow in numbers

Now that you know that, what are you going to do about it?

CONTENT

1. Reinforce from module SC01 that this is the mindset of the attacker, and that

they never stop.


mGovernment 117

Remember…I WILL attack your systemsI WILL find your weaknessesI WILL successfully break inI WILL steal data and sell itI WILL do it againI WILL always be thereI WILL never stopI WILL grow in numbers

What will you do about it?

http://aymcreations.deviantart.com/art/Hacker-343952762

LEARNING OBJECTIVES


mGovernment 118

CONTENT


1. Introduce SDLC.

2. Understand the common aspects of a Development Lifecycle.

3. Understand that the proper application of an SDLC can help address the

Structural Problem.


mGovernment 119


• Introduce SDLC

• Understand the common aspects of a Development Lifecycle

• Understand that the proper application of an SDLC can help address

the Structural Problem

QUIZ


mGovernment 120


of this material


mGovernment 121


Quiz – Question 1

1. It is critical to maximize involvement of all members of the

team at the earliest possible point in the development lifecycle?

Select one:

a. True

b. False

mGovernment 1 2 2


End of Module


mGovernment 1 2 3

mGovernment 1 2 4


This short module begins the discussion of several security models / frameworks

and related concepts.

The point of using these is to help shape and structure your thoughts, and

more importantly, when you are discussing security with a colleague, by using a

common model or framework, to allow you to share vocabulary and a frame of

reference, which makes sharing knowledge easier.

CONTENT

THEMES

1. Security, Strategy.

2. Business Processes & Collaboration.


1 2 5125mGoverment

Module 5: Security Frameworks & Models

Security Frameworks

& Models

LEARNING OBJECTIVES


mGovernment 126


1. Introduce Security Goals.

2. Set expectations for the next several modules.


CONTENT

mGovernment 127


• Introduce Security Goals.

• Set expectations for the next several modules.

Objectives

LEARNING OBJECTIVES


mGovernment 128

1. Introduce Security Goals: CIA

ISO 27000:2009 defines Information Security as the “Preservation of

confidentiality, integrity and availability of information. “

This is a classic definition, and could be expanded, but these are the basics we

want to keep in mind as our goals.

In detail:

InfoSec “Ensures that only authorized users (confidentiality) have access to

accurate and complete information (integrity) when required (availability).”

(ISACA, 2008)

CONTENT

mGovernment 129

CONFIDENTIALITY

INTEGRITY

AVAILABILITY

Glossary


The Goals are C.I.A.

ISO 27000:2009: ISO Standard: Information technology - Security techniques -

Information security management systems - Overview and vocabulary.

ISACA: an international professional association focused on IT Governance.

LEARNING OBJECTIVES


mGovernment 130

1. Set the stage for the following several modules.

We will cover, (or covered in a previous module) each of these briefly. These

are aids to help you structure your thinking, and communicate about security

effectively.

CONTENT

mGovernment 131


Tools in the Toolbox

• SDLC (Discussed earlier)

• OWASP

• STRIDE

• Attack Surface Modeling

• Static & Dynamic Analysis

• Penetration Testing

LEARNING OBJECTIVES


mGovernment 132

1. Introduce Security Goals.

2. Set expectations for the next several modules.


CONTENT

mGovernment 133



• Introduce Security Goals

• Set expectations for the next several modules


of this material

QUIZ

Quiz – Question 1


mGovernment 134

• Match the following Goals with their definitions:

6

Goals:

A. Confidentiality

B. Availability

C. Integrity

• Information is available when required.

• Information is accurate and complete.

• Only authorized users have access to the information.


mGovernment 135


Quiz – Question 2

2. What is a security goal?

Select one:a. Confidentiality – keeping information secret

b. Integrity – prevent and detect tampering

c. Availability – ability to access and use resources

d. All of the above

mGovernment 1 3 6


End of Module

mGovernment 1 3 7

mGovernment 1 3 8


This module introduces the first of several security models/ frameworks,

OWASP, or the Open Web Application Security Project. Again, the point of using

frameworks and models is to help shape and structure your thoughts, and

more importantly, when you are discussing security with a colleague, by using a

common model or framework, to allow you to share vocabulary and a frame of

reference, which makes sharing knowledge easier.

CONTENT

THEMES

• Security.

OWASP

Glossary

Module 6: OWASP Open Web Application Security Project

OWASPOpen

Web Application Security Project

LEARNING OBJECTIVES


mGovernment 140


1. Introduce OWASP.

2. Explore several of the OWASP Top 10 Mobile security risks.

3. Get students in the habit of referring to external sources (in this case OWASP)

for details of complex topics.


CONTENT


mGovernment 141

• Introduce OWASP.

• Explore several of the OWASP Top 10 Mobile security risks.

• Get students in the habit of referring to external sources (in this case

OWASP) for details of complex topics.

Objectives

LEARNING OBJECTIVES


mGovernment 142

1. Discuss OWASP as resource.

OWASP is a great resource. How many of you are aware of it in the Web world?

They also “do mobile”, so take advantage…

From their web site: “The Open Web Application Security Project (OWASP) is a

501(c)(3) worldwide not-for-profit charitable organization focused on improving

the security of software. Our mission is to make software security visible, so that

individuals and organizations worldwide can make informed decisions about

true software security risks. “

They provide a “Top 10” list of risks or vulnerabilities for web applications, and

now they are providing something similar for mobile applications, which is

natural as Internet applications transition from web-based to our mobile devices.

Think of these Top 10 lists as mistakes that others have made. Making you

aware of them makes it easier for you to avoid repeating them.

If (when) you take your mGov app to the CoDI for testing, know that the OWASP

Top 10 is one of the things they strive to test for.

CONTENT


mGovernment 143

SOURCES

http://owasp.org

OWASP Mobile Top Ten

• There is a standardized

way to organize your

approach to Security

by Design

• (Revisit the Top 10, as they are

periodically revised)

• IF you see a test question on

OWASP, refer to the current

Top 10 on the web site……

mGovernment 1 4 4


The composition and order of the 10 change periodically for various reasons, so

it’s wise to stay aware of them as they shift, or when answering a test question.

CONTENT


mGovernment 145

OWASP Mobile Top Ten

• There is a standardized

way to organize your

approach to Security

by Design

• (Revisit the Top 10, as they are

periodically revised)

• IF you see a test question on

OWASP, refer to the current

Top 10 on the web site……

LEARNING OBJECTIVES


mGovernment 146

1. Understand that secure storage, particularly removable storage, is an issue.

Sensitive data ends up on mobile devices, in RAM, in on-board and removable

storage. This data will not encrypt or protect itself, so a lot of the issues related

to Insecure Storage come down to poor assumptions on the part of developers,

or outright self-inflicted wounds.

A prime example are the removable SD cards in common use on platforms other

than iOS. These are almost always formatted with FAT, the old File Allocation

Table, which has NO permission or protection model. This means if the attacker

gets the card, unless the application which wrote to it encrypted it, the data it

contains is exposed.

Mobile devices to get lost, stolen, left on busses, trains, airplanes, in taxis, etc., so

we loose the physical layer of protection. We MUST be aware of and address this.

CONTENT


mGovernment 147

Glossary

Sources

RAM: Random Access Memory.

SD Card: Secure Digital Card.

FAT: File Allocation Table.

http://owasp.org

Insecure Storage

A problem on mobile for two reasons

• Many apps store data locally for performance, session cache and

other reasons

• Devices get lost and stolen, sometimes with sensitive data on them

LEARNING OBJECTIVES


mGovernment 148

1. Understand the basics of buffer overflow bugs.

A buffer overflow is a name for a common class of vulnerabilities.

In this simple example in the “C” programming language, the code block on the

left has a problem, the one on the right not so much.

On the left, the code:

• Declares a variable called “text” of type “char”, 100 bytes long

• Prompts the user to “Enter Text”

• Reads input from the user into the variable text using the scanf function.

The problem is that there is no check or limit on the size of the data being read

in with scanf. If more than 100 bytes come in, they will overflow the input buffer

and be written into memory.

An attacker will search for and find these flaws, inject his malicious payload into

a memory location of his choice by adjusting the length of the input, and cause

your program to crash (at best), or to execute his code (bad).

CONTENT


mGovernment 149

http://owasp.org

https://en.wikipedia.org/wiki/Buffer_overflow

Sources

Buffer Overflow

• The program copies an input buffer to an output buffer without

verifying that the size of the input buffer is less than the size of the

output buffer, leading to a buffer overflow.

char text[100];

printf (“Enter text: “);

scanf (“%s”, text);

char text[100];


scanf (“%99s”, text);

mGovernment 1 5 0


CONTENT

On the right, the code:

• Declares the variable and prompts the user as before

• Reads input as before, but now limits what is read in to 99 bytes so that it plus

the NULL terminator will fit in the declared 100 byte variable space.

This is an extremely common type of programming error that honestly results

from lazy programmers, or from programmers who were not taught secure

coding practices.

It may be detected by source code analysis, or dynamic testing, but it’s easier to

just prevent the poor coding in the first place.

Note that some languages like Java are built to prevent these types of problems

from the beginning.

mGovernment 151


Buffer Overflow

• The program copies an input buffer to an output buffer without

verifying that the size of the input buffer is less than the size of the

output buffer, leading to a buffer overflow.

char text[100];


scanf (“%s”, text);

char text[100];


scanf (“%99s”, text);

LEARNING OBJECTIVES


mGovernment 152

1. Begin to understand the class of issues associated with improper session

handling.

State machines are tricky, particularly with stateless protocols like http, or with

asynchronous connections, long-lived connections, and frequent disconnects, all

of which come along with moving applications to mobile.

I invite you to explore this in detail from OWASP, but the end result of exploitation

of this class of vulnerability normally results in a hijacked session, allowing the

attacker access to a user’s data, or to elevate privilege, or both.

Using the device ID as a session token is a rookie mistake. Don’t make it, or let

your developers make it.

CONTENT

mGovernment 153


• Mobile session differences

• Usability, connections

• Sessions – HTTP cookies, oauth tokens, SSO tokens

• Vuln 0 is using device ID as session token

• Impact

• Privilege escalation

• Unauthorized access

• Circumvent licensing and payments

Improper Session Handling

LEARNING OBJECTIVES


mGovernment 154

The notion of a an Untrusted Input rises from the programming practice of

accepting input from an exterior source blindly and using it without validating it

to make sure it is as expected.

At a minimum, that means the data is of the expected type and length, and does

not contain inappropriate characters.

For example, a login ID field should only accept text, of the maximum length of

the LoginID, and reject any special characters or reserved programming words.

A Login ID field is not an appropriate place for text like:

Select * from users;

Which is a SQL command, complete with semicolon, that just might dump the

entire user table.

Some of these attacks take nothing more than the URL bar of a browser to

explore or execute, so they are particularly dangerous.

Bottom line is that Programmers MUST validate all input.

CONTENT

1. Understand that programmers should never trust un-validated inputs.

mGovernment 155

Security Decisions via Untrusted Inputs

• Bypass permission and security models

• Examples

• iOS abusing URL schemes

• Android abusing intents

• Vectors

• Malicious apps

• Client side injection

• Impacts

• Consuming paid resources

• Data Exfiltration

• Privilege escalation

SOURCES

http://owasp.org


LEARNING OBJECTIVES


mGovernment 156

1. Begin to understand data leakage.

One thing is certain, data that has “leaked”, or which is not in an expected

location, is not under scrutiny (at least not by the good guys) and is not being

protected.

Let’s look at one very specific example of potential data leakage, on the iPhone.

Think of the following scenario: You are entering some text in an application on

your phone, and the phone rings. Immediately, the iPhone switches the screen

to the phone screen, where you either take or reject the call.

When finished with the call screen, the iPhone immediately switches you back

to where you were in the previous application. If this has happened to you, and

paid close attention, you might have noticed that upon returning to the original

app, it was not immediately responsive, even though you could see it on screen.

CONTENT


mGovernment 157

Side Channel Data Leakage

SOURCES

http://owasp.org

• Causes: a mix of not disabling platform features and programming

flaws

• Results in Sensitive data in unintended places

• Web cache

• Keystroke logging

• Screenshots (iOS backgrounding)

• Logs (system, crash)

• Temp directories

• Impacts

• Data retained indefinitely

• Privacy violations

mGovernment 1 5 8


CONTENT

The reason is that when iOS make a switch as described, it takes a screenshot

of the original app, and upon return, displays the screenshot while it does the

full context switch to the app.

Now, ask yourself:

• Were you entering sensitive data that might have been captured on the

screenshot?

• Where was / is that screenshot stored?

• Is / was it encrypted?

• What else has access to it?

• Was it wiped? Securely?

This is potential data leakage through a side channel.

Again, read the details on this and the other examples of the Top 10 we

mentioned, plus the rest of the current Top 10 from OWASP.

There are other good resources at OWASP to help understand the issues, as

well as help learn how to test for them.


mGovernment 159

Side Channel Data Leakage

• Causes: a mix of not disabling platform features and programming

flaws

• Results in Sensitive data in unintended places

• Web cache

• Keystroke logging

• Screenshots (iOS backgrounding)

• Logs (system, crash)

• Temp directories

• Impacts

• Data retained indefinitely

• Privacy violations

LEARNING OBJECTIVES


mGovernment 160

1. Introduce OWASP.

2. Explore several of the OWASP Top 10 Mobile security risks.

3. Get students in the habit of referring to external sources (in this case

OWASP) for details of complex topics.


Let me emphasize that 3d objective. It’s very important to teach you where to go

for critical information, and to build the habit of going there.

CONTENT


mGovernment 161


• Introduce OWASP

• Explore several of the OWASP Top 10 Mobile security risks

• Get students in the habit of referring to external sources (in this

case OWASP) for details of complex topics

QUIZ


mGovernment 162


of this material


mGovernment 163


Quiz – Question 1

1. OWASP never revises their “Top 10” lists or any of their other

resources, so one visit to their web site should be enough for the

duration of a project?

Select one:

a. True

b. False


End of Module


mGovernment 166

CONTENT

This module introduces the STRIDE threat model and continues the introduction

of Attack Surface Modeling.

• Security.

THEMES









Introduction

Module 7: STRIDE & Attack Surface Modeling


Glossary

mGovernment 167

STRIDE

&

Attack Surface

Modeling


LEARNING OBJECTIVES


mGovernment 168

CONTENT



1. Introduce STRIDE and basic countermeasures.

2. Continue exploration of Attack Surface Modeling.


mGovernment 169

Objectives

• Introduce STRIDE and basic countermeasures.

• Continue exploration of Attack Surface Modeling.

LEARNING OBJECTIVES


mGovernment 170

STRIDE is a vulnerability or threat model invented and in wide use by Microsoft

and across the industry. They find it valuable for modeling the threats and then

proposing countermeasures.

It identifies six types of threats. As you can see, STRIDE is an acronym which

stands for:

• Spoofing

• Tampering

• Repudiation

• Information Disclosure

• Denial of Service

• Elevation of Privilege

You will probably note some overlap with our security goals of CIA,

Confidentiality, Integrity and Availability, but these are more specific.

Further, CIA represents goals, STRIDE represents threats.

CONTENT

1. Introduce and explore STRIDE.


mGovernment 171

STRIDE Threat Model

Threat Description Example

SpoofingAssume identity of client, server or request/response

Phishing attack to fool user into sending credentials to fake site

TamperingAlter contents of request of response

Message or data integrity compromised to change parameters or values

RepudiationDispute legitimate transaction Illegitimately claiming a

transaction was not completed

Information DisclosureUnauthorized release of data Unencrypted message sniffed

off the network

Denial of ServiceService not available to authorized users

System flooded by requests until web server fails

Elevation of privilegeBypass authorization system Attacker changes group

membership


mGovernment 172

Spoofing occurs when an attacker assumes the identity of subject (like user or

client), object (like a server, web application or database), or account. Phishing is

an example of Spoofing where an attacker fools the user by spoofing a legitimate

site like an online bank and tricks the user into sending their username and

password to a site the attacker controls. It is also possible for an attacker to spoof

the identity of the user directly.

Tampering occurs when message or data is altered by the attacker.

Repudiation occurs when the attacker denies an authentic event such as

claiming that an ATM machine did not give any money when in fact the attacker

did receive money from the ATM.

Information may be disclosed in number of ways; information can be sniffed

off of a network communication channel, such as through packet sniffing

unencrypted networks. Attackers may actively try to gather information through

injecting SQL commands to the database.

Denial of Service (also sometimes called “Denial of business”) means an attacker

can swamp the system to deny access to legitimate users.

Elevation of privilege occurs when an attacker finds a way to bypass access

control that limits their privileges. An attacker may try to elevate privilege by

using a normal account to run commands that are administrator only.

CONTENT


mGovernment 173

CONTENT

This is a brief overview of the STRIDE threat model, and on the next slide, we

will look at how countermeasures can be identified based on these threats.

LEARNING OBJECTIVES


mGovernment 174

CONTENT

The value of threat modeling is to assist with building security into the design.

Specifically, the threat model gives a concrete set of requirements and location

of the countermeasure in the system.

For the six threats in STRIDE that we briefly introduced, each could be mitigated

by a different countermeasure.

This list is illustrative not exhaustive; the purpose is to see that each threat will

likely yield different security mechanisms

Spoofing threats such as when an attacker impersonates a user, client or server,

may be mitigated by authentication mechanisms which verify the authenticity of

the subjects, objects and users.

Tampering threats such as altering data may be mitigated by signing and

hashing data to verify the integrity of the data.

Repudiating legitimate transactions may be mitigated through an audit log that

contains evidence of the transaction.

1. Understand how analyzing the threats helps us select appropriate

countermeasures.


mGovernment 175

Countermeasures

Threat Security ServiceSpoofing AuthenticationTampering Digital Signature, HashRepudiation Audit LoggingInformation Disclosure EncryptionDenial of Service AvailabilityElevation of privilege Authorization


mGovernment 176

Information disclosure can occur in many ways. For example, the threat of

sniffing information off the wire, can be mitigated by encryption.

Denial of service is mitigated through availability services like clustering, and fail

over, and by careful planning.

Elevation of privilege is mitigated through authorization checking to see if the

user has the correct rights to access the system.

This table is a good example of the value of threat modeling. It shows that

security is not one thing or one mechanism. Rather security can be defined as a

set of mechanisms that cope with certain threats. Depending on which threats

the system designers are trying to mitigate, the threat model will yield different

guidance for which mechanisms are necessary.

CONTENT


mGovernment 177

Countermeasures

Threat Security ServiceSpoofing AuthenticationTampering Digital Signature, HashRepudiation Audit LoggingInformation Disclosure EncryptionDenial of Service AvailabilityElevation of privilege Authorization

LEARNING OBJECTIVES


mGovernment 178

CONTENT

Attack surface Modeling is a way of thinking developed by Microsoft and

Carnegie Mellon University. It is really a refinement and application of some very

old military techniques to information security.

The core ideas here are that careful analysis can reveal where you can get

attacked, and sometimes how. It tells you what you must monitor to detect an

attack, and helps you prioritize your defensive efforts

The Attack Surface consists of:

• Data

• Method

• Channel

Here are some specific examples if the Mobile Attack Surface listed on the slide.

1. Understand the basics Attack Surface Modeling.


mGovernment 179

Attack Surface

• Developed at Microsoft and Carnegie Mellon

• Not really a New Idea….

• Describes the locations an attacker can launch, propagate and

detonate an attack

• The Attack Surface consists of: Data + Method + Channel

• Example Mobile Web Service Attack Surfaces:

• Data: JSON, XML, HTML5

• Method: HTTP, URI

• Channel: HTTP

LEARNING OBJECTIVES


mGovernment 180

CONTENT

Consider the examples listed under Data, Method and Channel on the slide.

Remember the changes to the n-tier architecture diagrams in the eGov and

mGov cases?

It’s pretty intuitive that when we move the front end of the application out of

the datacenter and into a handheld or mobile device, that the Attack Surface

has changed.

Analysis of the Attack Surface in both cases can help the attacker organize and

plan his offensive efforts. We do the same things to understand how he will try

and attack, therefore what we must defend.

1. Continue the Attack Surface discussion with some Mobile specifics.


Glossary

mGovernment 181

Mobile Attack Surface

Mobile Attack Surface analysis creates (exposes?) numerous challenges

BLE: Bluetooth Low Energy.

NFC: Near Field Communications.

• Data

• Application, standard & proprietary

• Can be stored inadvertently, e.g. backgrounding

• Method

• Some app methods are black box

• Synthetic methods, asychronous applications

• Communications channel

• Not just HTTP

• SMS/MMS, NFC, GPS, BLE, and more

• Inbound communications - Push notifications

• Difficulty in testing

LEARNING OBJECTIVES


mGovernment 182


CONTENT

1. Introduce STRIDE and basic countermeasures.

2. Continue exploration of Attack Surface Modeling.


mGovernment 183

• Introduce STRIDE and basic countermeasures.

• Continue exploration of Attack Surface Modeling.


QUIZ


mGovernment 184


of this material


mGovernment 185


Quiz – Question 1

1. What Threats are included in the STRIDE Threat Model?

Select one or more:

a. Spoofing

b. Tampering

c. Repudiation

d. Integrity

e. Denial of Service

f. Elevation of Privilege

1 8 6


End of Module


mGovernment 188

This module introduces several different types of security testing, and provides

some real-world examples of vulnerabilities that were or should have been

discovered through testing.

CONTENT

THEMES

• Security, Applications.


mGovernment 1 8 9

Module 8: Analysis & Testing

Analysis &

Testing

LEARNING OBJECTIVES


mGovernment 190

CONTENT



1. Discuss Static Analysis.

2. Discuss Dynamic Analysis.

3. Discuss Penetration Testing.

4. Provide some Real-World Examples.


mGovernment 191

Objectives

• Discuss Static Analysis.

• Discuss Dynamic Analysis.

• Discuss Penetration Testing.

• Provide some Real-World Examples.

LEARNING OBJECTIVES


mGovernment 192

CONTENT

This slide attempts to make it clear that no one method will find all

vulnerabilities, and that there will be overlaps, and gaps.

For projects where you are creating code, or managing the coding, you should

ALWAYS perform static analysis, mostly because you can.

You have the source code, which is a requirement.

As a side note, if you have contracted out development or portions of the

development of your applications, make sure that you secure the source code

as a deliverable, so that you can perform static analysis, or contract that out.

Perform Dynamic testing to the extent that you can. You may be limited here by

the availability of tools, or the budget to buy them.

Penetration testing should also be performed, but we will discuss some limitations

and expectations later.

1. Understand that no testing method is a direct replacement for another, and

that none will find all vulnerabilities.


mGovernment 193

Finding Coding Weaknesses

LEARNING OBJECTIVES


mGovernment 194

Static analysis can and should start with manual peer review of the code by the

developers during the development process, and continue with independent

testing, preferably with high quality commercial or potentially free software

review tools. The commercial ones can be expensive, so leverage the CoDI at

the TRA in Dubai.

They have tools and automated testing which is available to mGov team

members at no charge.

Note that you have to have the source code to do this in a traditional way, but

that attackers will decompile your binaries for this purpose, so you can never

assume that the bad guy isn’t going to read your code, and everything in it.

That means embedding things in code (hard-coded urls, account names,

passwords, etc) is an exceedingly bad idea. You can embed it you cannot

hide it.

Explore the code example above……

<CLICK>

CONTENT

1. Introduce static analysis with a simple example.


mGovernment 195

Static Analysis

• Security-themed Code Review.

• Doesn’t execute the code – finds most of the flaws.

• Usually performed by automated tools.

Simple example:

function isAdministrator(permissionLevel){

if (permissionLevel > 2)

return true;

if (permissionLevel < 2)

return false;

}

• What happens if permissionLevel equals 2?


mGovernment 196

What will happen if permissionLevel = 2 ? It’s not clear, is it?

That is exactly the problem, what WILL the machine do if permissionLevel = 2 ?

We do not know, which is not an acceptable outcome in the security world.

CONTENT


mGovernment 197

Static Analysis

• Security-themed Code Review.

• Doesn’t execute the code – finds most of the flaws.

• Usually performed by automated tools.

Simple example:

function isAdministrator(permissionLevel){

if (permissionLevel > 2)

return true;

if (permissionLevel < 2)

return false;

}

• What happens if permissionLevel equals 2?

LEARNING OBJECTIVES


mGovernment 198

Let’s look at a simple two line block of C code. <CLICK>

To begin, you have to understand a little about Boolean logic and the way

expressions are evaluated.

When you evaluate a statement like “if (A and B)”, first the truth of “A” is tested,

and the statement is automatically false if A is false; B never gets evaluated in

that case. If A is true, then the second condition, B is tested.

OR’s are parsed similarly, except only one side of an OR has to be true for the

statement to be true, so if the first is true, the second will not be evaluated. If it

is false, the second side will be.

In this example, we test if “options” are “_WCLONE” or “_WALL”. The “==”

operator in C is a test for equality, the “ | “ operator for OR. Assume one is true.

Then we test the right side of the AND test, “&&” is the operator for AND in C.

CONTENT

1. Understand how a simple typographical error, uncaught, can result in a

critical security failure.


mGovernment 199

Real World Example

if ((options == (__WCLONE|__WALL)) && (current->uid = 0))retval = -EINVAL;

ASSIGNMENT!NOT EVALUATION!

If not discovered, this code would execute when called in a very specific manner.

The uid 0 belongs to root.

Opening this backdoor would grant unrestricted administrator access to the system.

Don’t worry, it was discovered before the kernel was published.


mGovernment 200

Remember, both sides of an AND must be true for the test to be true, so if the

first condition is true, and we have assumed it is, the second will be evaluated.

<CLICK>

The right side of the && operator is “current->uid = 0”, <CLICK>

but that single “=” is not a test of equality, it is an assignment. It SETs the current

user id (uid) to “0”, which assigns the root identity to whoever runs this code and

with options == _WCLONE or _WALL

This is a textbook example of a root level elevation of privilege threat (remember

the E in STRIDE) that resulted probably as a because of a simple typographical

error.

<CLICK>

This was caught at the last minute before this code was integrated into the linux

kernel via static analysis.

CONTENT


mGovernment 201

Real World Example

if ((options == (__WCLONE|__WALL)) && (current->uid = 0))retval = -EINVAL;

ASSIGNMENT!NOT EVALUATION!

If not discovered, this code would execute when called in a very specific manner.

The uid 0 belongs to root.

Opening this backdoor would grant unrestricted administrator access to the system.

Don’t worry, it was discovered before the kernel was published.

LEARNING OBJECTIVES


mGovernment 202

Let’s introduce the Heartbleed vulnerability, which should have been discovered

through static analysis, but was actually discovered through a testing technique

call fuzzing, which we will discuss later.

For those of you who are very technically minded, I refer you to the URL on the

slide, where this is explored and explained in detail. Alternatively, refer to the

CVE listing.

An explanation follows in the next three slides, but essentially, a coding flaw

(a buffer over-read) in the implementation of the optional heartbeat functionality

in OpenSSL results in leakage of information, and eventually total defeat of the

protection, and compromise of the systems.

Heartbleed was independently discovered by several research teams, but the

vulnerability was disclosed by Google on 1 April 2014. The date of the release

caused some issues, as some readers initially thought it was an April Fools Joke.

CONTENT

1. Introduce the Heartbleed Vulnerability.


mGovernment 203

Glossary

SOURCES

Heartbleed (CVE-2014-0160)

• Announced by Google Security Team on

April 1st, 2014

The date created some confusion

• Exploits poorly written OpenSSL code

http://www.heartbleed.com

Another Real World Example: HeartBleed

CVE: Common Vulnerabilities and Exposures.

https://cve.mitre.orghttp://www.heartbleed.com

LEARNING OBJECTIVES


mGovernment 204

Glossary

TLS: Transport Layer Security.

DTLS: Datagram TLS.

The optional heartbeat extension to TLS / DTLS provides a way to test and

keep alive secure communication links without the need to renegotiate the

connection.

The requestor sends a message containing a random payload, and the length of

the payload.

The responder should reply with the same random payload, proving that it is

alive.

CONTENT

1. Explain the Mechanics of the vulnerability and the exploit.


mGovernment 205

HeartBleed

SOURCES

http://xkcd.com/1354/

Source: http://xkcd.com/1354/

LEARNING OBJECTIVES


mGovernment 206

RFC: an IETF standards document.

IETF: Internet Engineering Task Force.

Glossary

The way the heartbeat extension is supposed to work is spelled out in RFC

6520. Hackers sometimes read RFCs, but they don’t always follow the rules, and

implementations are sometimes not perfect.

CONTENT

1. Continue to explain the Mechanics of the vulnerability and the exploit.


mGovernment 207

HeartBleed (2)

SOURCES



LEARNING OBJECTIVES


mGovernment 208

So the hacker thinks….. “what if I send a payload of length 3, but tell the responder

that the length is 500?”

A vulnerable server does not check that the length in the request matches

the actual random payload. It replies with the specified random payload, then

over-reads the buffer and sends the requested number of bytes from memory,

up to 64k.

This allows an attacker to read the memory on the server, 64k at a time, and can

leak almost anything.

CONTENT



mGovernment 209

HeartBleed (3)


SOURCES


LEARNING OBJECTIVES


mGovernment 210

All versions of OpenSSL from the initial release of version 1.01 through 1.0.1f

have this flaw, and the heartbeat option is on by default.

You should test to see if your code is vulnerable. A list of services which do that

is at the URL provided.

CONTENT



mGovernment 211

• Heartbleed (CVE-2014-0160)

• OpenSSL versions 1.0.1 through

1.0.1f are vulnerable

All other versions are safe

• Heartbleed Vulnerability Testing

Services List:

http://en.wikipedia.org/wiki/Heart-

bleed#Vulnerability_testing_services

HeartBleed (4)

http://en.wikipedia.org/wiki/Heartbleed#Vulnerability_testing_services

SOURCES

LEARNING OBJECTIVES


mGovernment 212

The heartbeat extension can work in either direction, so a server can request

a heartbeat from a client, like a mobile device. This can result in a “reverse

heartbleed”.

Android uses OpenSSL, and android devices with version 4.1.1 have the flaw.

Google has fixed this problem in subsequent versions, but many vendors have

not supplied patches or updates to the older version of Android. Some continue

to sell it.

As an exercise, those of you with Android devices should check the version, and

if you are vulnerable, check with your vendor for an update.

For the record, iOS was never vulnerable to this issue.

CONTENT


2. Emphasize how widespread this problem IS, and that it will be with us until

vendors, including handset manufacturers provide fixes.


mGovernment 213

“Reverse Heartbleed” • “Heartbeats” can be requested

from mobile devices

Android JellyBean 4.1.1 IS

AFFECTED & REMAINS UNPATCHED

• About 50 million devices

• Device Manufacturers are

responsible for issuing patches

• Will they? Ever?

iOS was never affected

HeartBleed (5)

Source: http://gadgets.ndtv.com/internet/news/android-411-devices-vulnerable-to-heartbleed-bug-says-google-508262

LEARNING OBJECTIVES


mGovernment 214

CONTENT

Unlike static analysis, which looks at the source code, dynamic analysis looks at

the running environment. All you need is access to the device, or access to the

API on the backend, and you can test.

There are a number of techniques for this, free and commercial tools. The tools

for the mobiles themselves are behind the rest of the testing community, but

this is changing. Again, leverage the CoDI as they are acquiring and evaluating

the testing tools, and making them available for mGov team use.

DO test against the production versions of your code, as in the same code

version.

DO NOT test against the production environment without exercising extreme

care.

1. Introduce Dynamic Analysis


Glossary

mGovernment 215

CoDI Provides:

• Static Analysis Testing (correct).

• Dynamic Analysis Testing (correct).

• Penetration Testing.

• Reviews client-side (device) and server-side (back end) code while it

is running

• Mimics how a hacker would attack the app through a direct device

connection or the back end’s internet accessible interfaces

• Dynamic analysis tests that are created without careful planning

may negatively impact the application’s performance or behavior,

since the application is operating during the test

If you are performing these tests against a non-production version of

your app, they are irrelevant

Dynamic Analysis

LEARNING OBJECTIVES


mGovernment 216

Fuzzing is a dynamic analysis technique whose goal is to identify vulnerabilities.

It works by injecting randomized or malformed data into the target asset’s inputs.

Note that Fuzz testing does not require access to the source code.

Asset identification is the beginning of the Fuzz testing lifecycle, because these

asset “targets” are the place the fuzz tests will deployed against. An asset could

be any node in the application chain from the front end in the mobile device to

the back end in the data center, and all points in between.

The asset provides the target of the fuzzer – where the fuzzed data and events

will be directed.

Vulnerabilities are weak points that an attacker can exploit against an Asset.

HeartBleed was discoverable via static analysis, and should have been found that

way. In reality, it was discovered through fuzzing.

CONTENT

1. Introduce Fuzzing..


mGovernment 217

https://www.owasp.org/index.php/Fuzzing

http://www.ibm.com/developerworks/library/j-fuzztest/index.html

SOURCES

• Fuzz testing finds vulnerabilities

• Inject Random data into module inputs

• Does NOT require access to source code

Fuzzing – What is it?

https://www.owasp.org/index.php/Fuzzing http://www.ibm.com/developerworks/library/j-fuzztest/index.html

LEARNING OBJECTIVES


mGovernment 218

If you don’t perform testing of your systems, including dynamic analysis, the

hackers will do it for you, or it will happen by accident. Here’s an example of the

later.

This is the USS Yorktown, and in 1996 it was the test platform for the US

Navy’s Smart Ship program. Smart Ships were modernized and controlled by a

networked set of Windows NT servers and workstations.

While on sea trials in 1997, aboard this ship, a sailor entered a “Zero” somewhere

unexpected. The software accepted it, Unvalidated, and passed it on where it

eventually wound up as a divisor in a mathematical operation.

Divide by zero is an undefined operation in mathematics, and in this case, the

exception that the zero divide generated was not handled gracefully.

The system crashed, the crash cascaded to other systems across the ship, which

lost power and control.

The Yorktown had to be towed back to port.

CONTENT

1. Demonstrate how testing can prevent operational disasters in the real world.


mGovernment 219

USS Yorktown

• Testing platform for the US Navy’s “Smart Ship” program in 1996.

• State of the art Windows NT 4.0 & fiber optics installed to show how

technology could improve the “modern US Navy”.

Real World Fuzz Example

• In 1997, a crew member enters 0

into a database

• This caused a “Divide by zero”

error, which shut down all of the

ship’s systems.

• The USS Yorktown had to be

towed back to dock

LEARNING OBJECTIVES


mGovernment 220

A Penetration test, or PenTest is an intentional attack on a system with the intent

to discover vulnerabilities.

Hackers will PenTest your applications and back ends for you, and they will

exploit your vulnerabilities.

In a perfect world, you will already have performed your own PenTest. CoDI and

the aeCERT can assist you with this.

PenTests are usually labeled “white box”, or “black box”. With a white box test,

you supply the attacker with complete information about the target. In the black

box scenario, the attacker starts with little to no information, maybe as little as

the name of the target.

A black box test is more realistic, but less likely to uncover flaws. If budget

permits, perform both, preferably with independent teams.

A positive result means that some flaws were discovered, and can be addressed.

You do not know if you found them all.

CONTENT

1. Introduce Penetration Testing.

2. Understand the limitations of penetration testing


mGovernment 221

• Penetration Testing (“PenTest”): an intentional attack on an appli-

cation or system to test and assess its vulnerabilities

• White vs Black:

• “White Box” – All background information about the target is known

or provided

• “Black Box” – Little or no information is provided

• Positive results: flaws uncovered, corrected

• Negative results: unknown whether no flaws exist, or if they were

simply not found

Penetration Testing

CONTENT

A negative result reports no flaws. Does that mean none exist, none were found

for whatever reason, or that no testing was actually performed?

LEARNING OBJECTIVES


mGovernment 222

We expose these terms “white vs black vs grey” to make you aware of how they

are used in the industry.

The terms “Black Hat” and “White Hat” have their origins in the old Hollywood

western films. Good guys wore white hats, bad guys wore black. Grey is a mixture

of the two colors.

The label “White Hat Hacker” is supposed to mean that the person is ethical, and

that you can trust them.

A “Black Hat” is an attacker.

A “Grey Hat” is someone you are not sure about, or someone who fits both roles.

The bottom line is this: Hackers explore and break things. Hackers who do this

for you, with your knowledge and permission can help you. Hackers doing it

without your knowledge or permission are simply criminals.

CONTENT

1. Expose the labels applied to hackers.

2. Understand the challenge of finding and selecting an ethical hacker, or Pen

Tester

Introduction


mGovernment 223

CONTENT

Hacker Descriptions:

• White hat – “Ethical Hackers” that specialize in professional

security assessment & PenTesting

• Black hat – “Malicious Hackers” that break into systems for

personal gain and/or political reasons (“hacktivism”)

• Grey hat – A mix of white and black hat. May be a professional

“white hat” and a “black hat” as a hobby

Hire a “White hat” to PenTest your

app before a “Black hat” does it with

malicious intent.

Needless to say, it is vitally important that you choose your white hats, or

PenTesters carefully, and monitor their activities. It is best to stay with

well-known professional organizations like commercial firms or government

entities as opposed to working with individual, independent practitioners.

LEARNING OBJECTIVES


mGovernment 224

In 2013, Target got a “PenTest” from a helpful gang of hackers that resulted in

the compromise of 40 million payment cards.

We will never know if a professional penetration test would have exposed this

vulnerability before it was exploited, but it is extremely likely that it would have.

In any case, Target had not performed one, even though it is a requirement of

the PCI DSS, and they were theoretically compliant.

CONTENT

1. Understand how failure to test can result in operational disasters in the real

world.


mGovernment 225

PCI DSS: Payment Card Industry Data Security Standard

Glossary

Target Corporation

• Announced in December 2013 that approximately 40 million credit

cards were compromised.

• Malicious code exploited a known vulnerability on unpatched

Windows systems.

• Target’s CIO resigned.

• CIO had no IT experience

• The PCI mandated PenTest

was not performed

Real World Penetration

LEARNING OBJECTIVES


mGovernment 226


CONTENT

1. Discuss Static Analysis.

2. Discuss Dynamic Analysis.

3. Discuss Penetration Testing.

4. Provide some Real-World Examples.

mGovernment 227

Module 8 : Analysis & Testing

• Discuss Static Analysis

• Discuss Dynamic Analysis

• Discuss Penetration Testing

• Provide some Real-World Examples



of this material

QUIZ


mGovernment 228

Quiz – Question 1

1. Static Analysis requires the tester to have, or to gain, access to the

source code?

a. True

b. False


mGovernment 229


Quiz – Question 3

Quiz – Question 2

3. Fuzzing is used for:

Select one:

a. Checking for the robustness of the application at run time

b. Static analysis of the source code

c. Dynamic analysis of your application

d. None of the above

e. A and C

2. CoDI Provides:

a. Static Analysis Testing

b. Dynamic Analysis Testing

c. Penetration Testing

QUIZ


mGovernment 230


of this material


mGovernment 231


Quiz – Question 5

Quiz – Question 4

4. To fuzz test an application, an attacker only needs:

Select one:

a. Access to the full source code to the application

b. Access to the application interfaces and runtime (the app itself)

c. Both of the above

d. Neither of the above

5. A Penetration test with negative results, which found no flaws in

the target, means that there really are no flaws in the target?

a. True

b. False

mGovernment 2 3 2


End of Module


2 3 3


mGovernment 234

We discuss the strength in learning from others mistakes and failures.

CONTENT

THEMES

• Security, Business Processes & Collaboration.


mGovernment 2 3 5

Module 9: Strength in Failures

Strength in

Failures

LEARNING OBJECTIVES


mGovernment 236


CONTENT


1. Understand the strength of learning from others mistakes and failures.

2. Identify some resources for sharing.


mGovernment 237

• Understand the strength of learning from others mistakes and

failures.

• Identify some resources for sharing

Objectives

LEARNING OBJECTIVES


mGovernment 238

In the engineering world, when something fails, engineers descend upon the

disaster, investigate and determine the causes.

Then they publish a report of findings so that the mistake is less likely to be

repeated.

CONTENT

1. Introduce the idea of engineers investigating failures and publishing reports

detailing the root causes.


mGovernment 239

What can we learn from history about technology failures?

LEARNING OBJECTIVES


mGovernment 240

CONTENT

Background:

This is the original Tacoma Narrows Bridge. It opened for traffic on 1 July 1940

and collapsed 7 November of the same year. At the time, it was the 3d largest

(longest) suspension bridge in the world, behind the Golden Gate in San Francisco

and the George Washington in NYC.

What you are seeing here is called resonance.

The winds that day struck the resonance point of the bridge, causing it to vibrate

and oscillate, with unforeseen consequences.

The bridge’s collapse had a lasting effect on science and engineering. In many

physics textbooks, the event is presented as an example of elementary forced

resonance with the wind providing an external periodic frequency that matched

the bridge’s natural structural frequency.

Almost every engineering or physics student in the world sees this video at some

point in their education.

1. Reinforce that engineers investigate disasters and report on problems.


mGovernment 241

Bridge Failures

LEARNING OBJECTIVES


mGovernment 242

This is a video of the Hindenburg disaster. The crash of LZ 129 took place in

Lakehurst, NJ, 6.5.1937

There had been many successful flights up to this point….. but it only takes one

failure.

In this case a combination of events culminated in a static spark which set off

Hydrogen gas which had accumulated between the buoyancy bladders and the

outer skin of the airship.

CONTENT

1. Reinforce that engineers investigate disasters and report on problems.


mGovernment 243

Aviation Failures

LEARNING OBJECTIVES


mGovernment 244

CONTENT

The point of this module should be obvious now.

Engineers collectively learn from individual failures.

We are in an engineering field as well, and should apply the same mindset, but

there is a great deal of resistance. It’s simply embarrassing if nothing else.

Share information on failures, at least with the aeCERT.

Preferably, share with other members of the same team and with other teams.

Do not make the same mistakes that others have, learn from their failures, and

let others learn from yours.

1. Reinforce the strength of learning from others failures.


mGovernment 245

CVE

Glossary

• Building collapses, train crashes, etc.

In these cases, experts investigate, determine the root causes, and

share the information to prevent it from recurring.

• This is not common practice with Information Security!

• Nobody wants to announce their failures.

• Not announcing failures = Not announcing fixes.

• If we don’t share information, how can we learn?

• If we don’t learn, how can we improve?

Failure is Everywhere

LEARNING OBJECTIVES


mGovernment 246

CONTENT

SOURCES

We’ve mentioned OWASP and the CVE project as resources in the past.

These are links to the developer web sites for each of the platforms.

Don’t forget Google. We recommend you search periodically for vulnerability

disclosure discussions. These tend to move around for various reasons.

1. Provide a summary of some resources already mentioned, and some others.

• owasp.org• cve.mitre.org• developer.android.com• developer.apple.com• devcenter.windowsphone.com• developer.blackberry.com


mGovernment 247

• Familiar ones:

• OWASP Top 10 and other of their resources

• CVE: list of vulnerabilities, each typically with a brief description, patch

or fix information, proof of concept code for use in testing, etc.

• Platform Developer’s web sites:

• developer.android.com

• developer.apple.com

• devcenter.windowsphone.com

• developer.blackberry.com

• Don’t forget Google

Search for vulnerability disclosure discussions. These have a tendency to

move around.

Some Resources

LEARNING OBJECTIVES


mGovernment 248

CONTENT


1. Understand the strength of learning from others mistakes and failures.

2. Identify some resources for sharing.

mGovernment 249


• Understand the strength of learning from others mistakes and

failures.

• Identify some resources for sharing


QUIZ


mGovernment 250


of this material


mGovernment 251


Quiz – Question 1

1. Engineers, including software and security engineers, can

learn valuable lessons by studying the failures of others.

a. True

b. False

mGovernment 2 5 2


End of Module

mGovernment 2 5 3


mGovernment 254

We will begin the discussion of security features of the four featured mobile

platforms, beginning with Android. The Android discussion is the longest and

most detailed, for several reasons.

First and foremost, it is the most open platform. The kernel is linux, which is

open. The architecture, which we will see in detail in two slides, is open. Google

has released the bulk of the Android system as open source, so we have the code

and know the most about it.

The bad news is the attacker has the same access, and as we will show you later,

he has easy access to the source code of your applications as well, with all that

that implies.

Another reason that we focus on Android, beyond the fact that it is the most

prevalent smart phone OS in the UAE, is that we are simply starting the overall

discussion of the platforms with it.

We will expose and discuss security features in the context of the Android

discussion, many of which are also present with the other platforms.

Essentially, the Android discussion is the baseline discussion, and we discuss

differences when we review the other platforms.

CONTENT

THEMES

• Architecture, Applications, Security


mGovernment 2 5 5

Module 10: Android Security

Android Security

LEARNING OBJECTIVES


mGovernment 256

CONTENT



1. Understand the architecture of the Android operating system.

2. Understand how components fit together to build applications.

3. Understand the security model.


mGovernment 257

Objectives

• Understand the architecture of the Android operating system.

• Understand how components fit together to build applications.

• Understand the security mode.

LEARNING OBJECTIVES


mGovernment 258

First, relax…. Most of you will live in the blue zone.

This is fondly known as the lasagna model, because of all of the layers. If you’re

an old Unix person, this should look familiar.

Applications:

1. All applications are written using the Java programming language.

2. Android ships with a set of core applications including an email client, SMS

program, calendar, maps, browser, contacts, and others. All applications are

written using the Java programming language.

Application Framework:

3. By providing an open development platform, Android offers developers the

ability to build extremely rich and innovative applications. Developers are free

to take advantage of the device hardware, access location information, run

background services, set alarms, add notifications to the status bar, and much,

much more.

4. Developers have full access to the same framework APIs used by the core

applications. The application architecture is designed to simplify the reuse of

CONTENT

1. Explore the internal architecture of the Android OS.

2. Reinforce that this is a UNIX platform.

mGovernment 259

Android Architecture


Source: http://developer.android.com/guide/basics/what-is-android.html


mGovernment 260

CONTENT

components; any application can publish its capabilities and any other application

may then make use of those capabilities (subject to security constraints enforced

by the framework). This same mechanism allows components to be replaced by

the user.

5. Underlying all applications is a set of services and systems, including:

a. A rich and extensible set of Views that can be used to build an application,

including lists, grids, text boxes, buttons, and even an embeddable web browser

b. Content Providers that enable applications to access data from other

applications (such as Contacts), or to share their own data

c. A Resource Manager, providing access to non-code resources such as localized

strings, graphics, and layout files

d. A Notification Manager that enables all applications to display custom alerts

in the status bar

e. An Activity Manager that manages the lifecycle of applications and provides a

common navigation backstack

6. For more details and a walkthrough of an application, see the Notepad Tutorial

from the Android developer website.

Libraries:

7. Android includes a set of C/C++ libraries used by various components of

the Android system. These capabilities are exposed to developers through the

Android application framework. Some of the core libraries are listed below:

8. System C library - a BSD-derived implementation of the standard C system

library (libc), tuned for embedded Linux-based devices

9. Media Libraries - based on PacketVideo’s OpenCORE; the libraries support

playback and recording of many popular audio and video formats, as well as

mGovernment 261


CONTENT

static image files, including MPEG4, H.264, MP3, AAC, AMR, JPG, and PNG

10. Surface Manager - manages access to the display subsystem and seamlessly

composites 2D and 3D graphic layers from multiple applications

11. LibWebCore - a modern web browser engine which powers both the Android

browser and an embeddable web view

12. SGL - the underlying 2D graphics engine

13. 3D libraries - an implementation based on OpenGL ES 1.0 APIs; the libraries

use either hardware 3D acceleration (where available) or the included, highly

optimized 3D software rasterizer

14. FreeType - bitmap and vector font rendering

15. SQLite - a powerful and lightweight relational database engine available to

all applications

Android Runtime:

16. Android includes a set of core libraries that provides most of the functionality

available in the core libraries of the Java programming language.

17. Every Android application runs in its own process, with its own instance of

the Dalvik virtual machine (VM). Dalvik has been written so that a device can run

multiple VMs efficiently. The Dalvik VM executes files in the Dalvik Executable

(.dex) format which is optimized for minimal memory footprint. The VM is

register-based, and runs classes compiled by a Java language compiler that have

been transformed into the .dex format by the included “dx” tool.


mGovernment 262

CONTENT

Linux Kernel:

18. The Dalvik VM relies on the Linux kernel for underlying functionality such as

threading and low-level memory management.

19. Android relies on Linux version 2.6 for core system services such as security,

memory management, process management, network stack, and driver model.

The kernel also acts as an abstraction layer between the hardware and the rest

of the software stack.

20. Finally, the Binder provides for Interprocess Communication. As this is

effectively a choke point, it is the structure within the kernel which enforces the

permissions defined by the application developer in the AndroidManifest.xml file.

More on this in a couple of slides.

mGovernment 263

http://developer.android.com/guide/basics/what-is-android.html

• Dalvik: The Java Virtual Machine inside Android.

SOURCES

Glossary


LEARNING OBJECTIVES


mGovernment 264

Activities- For example, an email application might have one activity that shows

a list of new emails, another activity to compose an email, and another activity

for reading emails. Although the activities work together to form a cohesive user

experience in the email application, each one is independent of the others. As

such, a different application can start any one of these activities (if the email

application allows it). For example, a camera application can start the activity in

the email application that composes new mail, in order for the user to share a

picture.

Services- For example, a service might play music in the background while the

user is in a different application, or it might fetch data over the network without

blocking user interaction with an activity. Another component, such as an

activity, can start the service and let it run or bind to it in order to interact with it.

Content Providers: Through the content provider, other applications can query

or even modify the data (if the content provider allows it). For example, the

Android system provides a content provider that manages the user’s contact

information. As such, any application with the proper permissions can query

part of the content provider (such as ContactsContract.Data) to read and write

CONTENT

1. Introduce terms and concepts at the core of Android applications.


mGovernment 265

• Activities: a single screen with a user interface.

• Services: long-running tasks in background. Services do not expose a UI.

• Content Providers: a shared set of application data: SQLite DB, Web

resource, file system, or other persistent storage.

• Broadcast Receiver: a component that responds to system wide

broadcast announcements.

Application Components “Android vocabulary Lesson”


mGovernment 266

CONTENT

information about a particular person. Content providers are also useful for

reading and writing data that is private to your application and not shared. For

example, the Note Pad sample application uses a content provider to save notes.

Broadcast Receiver: Many broadcasts originate from the system—for example,

a broadcast announcing that the screen has turned off, the battery is low, or a

picture was captured. Applications can also initiate broadcasts—for example, to

let other applications know that some data has been downloaded to the device

and is available for them to use. Although broadcast receivers don’t display a

user interface, they may create a status bar notification to alert the user when

a broadcast event occurs. More commonly, though, a broadcast receiver is just

a “gateway” to other components and is intended to do a very minimal amount

of work. For instance, it might initiate a service to perform some work based on

the event.


mGovernment 267

• Activities: a single screen with a user interface.

• Services: long-running tasks in background. Services do not expose a UI.

• Content Providers: a shared set of application data: SQLite DB, Web

resource, file system, or other persistent storage.

• Broadcast Receiver: a component that responds to system wide

broadcast announcements.

Application Components “Android vocabulary Lesson”

LEARNING OBJECTIVES


mGovernment 268

Using an email application as an example, talk through the terms from the

previous slide and how they would play together to build a complete email

application.

The email application might have three activities or screens, one to read mail,

a second to compose mail, and a third to list messages in a folder. All of these

Activities will be visible to the user.

They will communicate with Services to send and receive mail.

These will communicate with a Content Provider to store the mail, attachments,

etc.

Finally, the application contains a Broadcast Receiver so that it can me notified

of things like low battery, screen shut down, etc.

CONTENT

1. Reinforce the terms and definitions from the previous slide using this

graphic.


mGovernment 269

Components in Context

LEARNING OBJECTIVES


mGovernment 270

From a high level, these mechanisms are how application components

communicate with each other.

For some students, that may be all of the detail that they need. More advanced

individuals may be interested in the details below:

Intents are asynchronous messages which allow application components to

request functionality from other Android components. Intents allow you to

interact with components from the same applications as well as with components

contributed by other applications. For example, an activity can start an external

activity for taking a picture.

There are separate methods for activating each type of component:

You can start an activity (or give it something new to do) by passing an Intent to

startActivity() or startActivityForResult() (when you want the activity to return a

result).

You can start a service (or give new instructions to an ongoing service) by passing

an Intent to startService(). Or you can bind to the service by passing an Intent to

bindService().

CONTENT

1. Discuss messaging between the various Android application components.


mGovernment 271

• Intent:

• Asynchronous Message sent to activate a Activity, Service or

Broadcast Receiver.

• Sending an Intent

• Content Resolver:

• Activates Content Provider

Component Messaging

CONTENT

You can initiate a broadcast by passing an Intent to methods like sendBroadcast(),

sendOrderedBroadcast(), or sendStickyBroadcast().

You can perform a query to a content provider by calling query() on a

Content Resolver.

LEARNING OBJECTIVES


mGovernment 272

The “this app needs access to $resource” messages the user gets at install time

are driven by this file and its contents.

The AndroidManifest.xml file is created by the application developer.

It contains quite granular controls and permissions, but once it is packaged with

the application components into the .apk file, it becomes an all-or-nothing thing.

In other words, at install-time, the end user is presented with the permission list

in the form “This application will access the following resources <list>”. The end

user has only one choice at that point, install the application with the associated

permissions, or do not install.

The access limits are enforced by? The Binder in the kernel.

Other platforms handle this differently. iOS for example allows the user to adjust

some permissions and access controls post-install.

CONTENT

1. Introduce the AndroidManifest.xml file and its functions.


mGovernment 273

Metadata about the application is stored in and loaded from

AndroidManifest.xml

Manifest File

• Identify any user permissions the application requires, such

as Internet access or read-access to the user’s contacts.

• Declare the minimum API Level required by the application,

based on which APIs the application uses.

• Declare hardware and software features used or required by

the application, such as a camera, or a multi-touch screen.

• API libraries the application needs to be linked against (other

than the Android framework APIs), such as the Google Maps

library.

LEARNING OBJECTIVES


mGovernment 274

As you can see, the Manifest file is written in XML, Extensible Markup Language

Extensive documentation on the Manifest is available on the Android developer

website at the URL on the slide.

Some selected examples:

In the <application> element, the android:icon attribute points to resources for

an icon that identifies the application.

In the <activity> element, the android:name attribute specifies the fully qualified

class name of the Activity subclass and the android:label attributes specifies a

string to use as the user-visible label for the activity.

You must declare all application components this way:

<activity> elements for activities

<service> elements for services

<receiver> elements for broadcast receivers

<provider> elements for content providers

CONTENT

1. Show an example Manifest file.


mGovernment 275

<?xml version=”1.0” encoding=”utf-8”?>

<manifest ... >

<uses-permission android:name=”android.permission.WRITE_

EXTERNAL_STORAGE” android:maxSdkVersion=”18” />

<application android:icon=”@drawable/app_icon.png” ... >

<activity android:name=”com.example.project.ExampleActivity”

android:label=”@string/example_label” ... >

</activity>

...

</application>

</manifest>

Reference: https://developer.android.com/guide/topics/manifest/

manifest-intro.html

Android Manifest.xml


mGovernment 276

XML: Extensible Markup Language.

https://developer.android.com/guide/topics/manifest/manifest-intro.html

Glossary

SOURCES

CONTENT

Activities, services, and content providers that you include in your source but do

not declare in the manifest are not visible to the system and, consequently, can

never run.

However, broadcast receivers can be either declared in the manifest or created

dynamically in code (as BroadcastReceiver objects) and registered with the

system by calling registerReceiver().


mGovernment 277

<?xml version=”1.0” encoding=”utf-8”?>

<manifest ... >

<uses-permission android:name=”android.permission.WRITE_

EXTERNAL_STORAGE” android:maxSdkVersion=”18” />

<application android:icon=”@drawable/app_icon.png” ... >

<activity android:name=”com.example.project.ExampleActivity”

android:label=”@string/example_label” ... >

</activity>

...

</application>

</manifest>

Reference: https://developer.android.com/guide/topics/manifest/

manifest-intro.html

Android Manifest.xml

LEARNING OBJECTIVES


mGovernment 278

Android is a privilege-separated operating system, in which each application runs

with a distinct system identity (Linux user ID and group ID). Parts of the system

are also separated into distinct identities. Linux thereby isolates applications

from each other and from the system.

Additional finer-grained security features are provided through a “permission”

mechanism.

Permissions are declared by the developer in the AndroidManifest.xm file, and

enforced by the binder component of the underlying linux kernel.

Permissions are enforced:

• At the time of a call into the system, to prevent an application from executing

certain functions.

• When starting an activity, to prevent applications from launching activities of

other applications.

• When both sending and receiving broadcasts, to control who can receive your

broadcast or who can send a broadcast to you.

CONTENT

1. Discuss some details about the permissions declared in the AndroidManifest.

xml file.


mGovernment 279

Permissions

• Included in AndroidManifest.xml, used to protect data and

functionality

• Permission makes the application boundary, enforced in kernel

• Examples

• Use system:

• android.permission.CALL_EMERGENCY_NUMBERS

• Read data

• android.permission.READ_OWNER_DATA

• Write data

• android.permission.WRITE_CONTACTS

• Set System settings

• android.permission.SET_WALLPAPER

Reference: https://developer.android.com/guide/topics/security/

permissions.html


mGovernment 280

CONTENT

• When accessing and operating on a content provider.

• When binding to or starting a service.

ALL enforced within the underlying Linux kernel.

https://developer.android.com/guide/topics/security/permissions.html

SOURCES


mGovernment 281

• Included in AndroidManifest.xml, used to protect data and

functionality

• Permission makes the application boundary, enforced in kernel

• Examples

• Use system:

• android.permission.CALL_EMERGENCY_NUMBERS

• Read data

• android.permission.READ_OWNER_DATA

• Write data

• android.permission.WRITE_CONTACTS

• Set System settings

• android.permission.SET_WALLPAPER

Reference: https://developer.android.com/guide/topics/security/

permissions.html

Permissions

LEARNING OBJECTIVES


mGovernment 282

CONTENT

These are some examples of permissions that should be familiar to most Android

users.

The full list of available permissions is on the Android developer website at the

URL on the slide.

1. Provide some examples of some specific permissions.

http://developer.android.com/reference/android/Manifest.permission.html

SOURCES


mGovernment 283

• ACCESS_COARSE_LOCATION

• Allows an app to access approximate location derived from network

location sources such as cell towers and Wi-Fi.

• ACCESS_FINE_LOCATION

• Allows an app to access precise location from location sources such

as GPS, cell towers, and Wi-Fi.

• NFC

• Allows applications to perform I/O operations over NFC.

• WRITE_EXTERNAL_STORAGE

• Allows an application to write to external storage.

• WRITE_SMS

• Allows an application to write SMS messages.

• Full list at:

http://developer.android.com/reference/android/Manifest.permission.

html

Permission Examples

LEARNING OBJECTIVES


mGovernment 284

Content providers are handled a little differently. Here are some examples.

The details for Content providers are on the Android developers website

beginning at the URL provided on the next slide.

CONTENT

1. Introduce Content Provider Grants.


mGovernment 285

https://developer.android.com/guide/topics/providers/content-provider-

basics.html

SOURCES

• Different model than permissions.

• Used with Content Providers.

• URI Permissions are a special case.

• URI examples:

• content://com.example.app.provider/AccountsTable.

• A content authority called com.example.app.provider.

• A table called AccountsTable.

• content://com.example.app.provider/AccountsTable/Users.

• A table called Users.

Content Provider Grants

LEARNING OBJECTIVES


mGovernment 286

CONTENT

Grants provide a capabilities model for permissions, for example the ability to

open a file attachment.

They are applied or enforced at the Intent filter, which is declared in the

AndroidManifest.xml file.

Content providers documentation is on the Android developers website

beginning at the URL provided. Expect to start reading at this page and to follow

links to several others.

1. Continue with examples of Content Provider grants and provide the

reference URL.


mGovernment 287

• Grants - Implement a capabilities model for Granting permissions,

such as opening up a file attachment

• Applied at the Intent filter

• Can be used for granular, event based access

• Read permission:

• FLAG_GRANT_READ_URI_PERMISSION

• Write permission:

• FLAG_GRANT_WRITE_URI_PERMISSION

• Reference:

https://developer.android.com/guide/topics/providers/content-

provider-basics.html

Content Provider Grants (2)

SOURCES

https://developer.android.com/guide/topics/providers/content-provider-

basics.html

LEARNING OBJECTIVES


mGovernment 288

If you remember, this is the graphic we used when we introduced the terms

Activity, Service, Content Provider and Broadcast Receiver, to illustrate how the

components fit together to make up an app.

At this point, we have overlaid it with the security mechanisms we’ve been

discussing so you can see how it all fits together.

All of these controls, to reiterate, are declared by the developer in the

AndroidManifest.xml file, and enforced by the underlying linux kernel.

The permissions are reported to the user at install-time, where the user must

accept them as declared, or decline to install the app.

CONTENT

1. Bring the security controls together with the application components.


mGovernment 289

Glossary

SDLC: Software Development Life Cycle.

Using Permissions

LEARNING OBJECTIVES


mGovernment 290

Here is a checklist to follow prior to deployment of a application.

Share this with the development team at the beginning of the SDLC so that there

are no surprises at the end.

The conversation with the development staff should be something along the

lines of:

“Here are the things I as the security person am concerned that we get right.

Understand that I will be reviewing all of this with you prior to approving the

application.”

CONTENT

1. Provide a checklist for reviewing permissions with the development staff.


mGovernment 291

Pre-Deployment Checklist

• Review Android Manifest.

• Inspect permissions for:

• Activities

• Services

• Intents & Intent filters

• Content providers

• Broadcasts

• Custom permissions

• Grants

Permission Review

LEARNING OBJECTIVES


mGovernment 292


CONTENT

1. Understand the architecture of the Android operating system.

2. Understand how components fit together to build applications.


mGovernment 293


• Understand the architecture of the Android operating system.

• Understand how components fit together to build applications.

• Understand the security model.



of this material

QUIZ


mGovernment 294

Quiz – Question 1

1. The Binder is the structure within the kernel that enforces

the permissions defined by the application developer in the

AndroidManifest.xml file.

a. True

b. False


mGovernment 295

Module 10 : Android Security

Quiz – Question 3

Quiz – Question 2

3. An Android Intent is used to access Content Providers?

a. True

b. False

2. Android Content Providers are used to?

Select one:

a. Send and Receive SMS messages

b. Access Web content via URIs

c. Store and manage data

d. Both B and C

QUIZ


mGovernment 296


of this material


mGovernment 297


Quiz – Question 5

Quiz – Question 4

4. In designing Android apps it is best to allow the maximum

level of permissions to all the phones features and services:

Select one:

a. True

b. False

5. On the Android platform, resources which the app can access

are declared:

Select one:

a. In the AndroidManifest.xml file.

b. When uploading the app to the Google Play store.

c. By the CA when Signing the app.

d. In the Source Code.

mGovernment 2 9 8


End of Module


mGovernment 2 9 9

mGovernment 300


We will continue our discussion of security on the android platform, now focusing

on securing the app.

CONTENT

THEMES

• Architecture, Applications, Security.









Introduction


Glossary

mGovernment 301

Module 11: Defending Android Apps

DefendingAndroid Apps

LEARNING OBJECTIVES


mGovernment 302


CONTENT


1. Understand the security features of the Android OS.

2. Discuss data encryption and key management.

3. Understand the code signing process.


mGovernment 303

• Understand the security features of the Android OS.

• Discuss data encryption and key management.

• Understand the code signing process.

Objectives

LEARNING OBJECTIVES


mGovernment 304

We will discuss each of these topics in this module.

Note that many of these topics are relevant in one form or another on other

platforms.

CONTENT

1. Outline the topics covered in this module.


mGovernment 305

• Building A Sandbox.

• Data Encryption.

• Key Management.

• ASLR (Address Space Layout Randomization).

• Secure Element.

• Input Validation.

• Code Signing Process.

Defending Android Apps

LEARNING OBJECTIVES


mGovernment 306

A sandbox is a limited execution environment.

The term comes from sandboxes that children play in, and it’s a good metaphor:

• It’s a safe environment, with soft sand, and safe toys

• It has a boundary, to keep the kids in, threats out, and to limit interaction in-

and-out

The sandbox begins and ends with the linux kernel.

At the beginning, each application runs with a unique UNIX UID and GID (User

ID and Group ID), and the associated UNIX file permission model that goes with

it. Each file has access rights of Read, Write, Execute (or a combination thereof)

associated with it on a per-User, per-Group and Other basis. We get basic access

controls or permissions based on this.

Finer grained permissions are specified in the Manifest as we discussed previously.

This means, as we mentioned previously, that the permission declarations in the

AndroidManifest.xml file MUST be set up correctly, to allow the minimum access

necessary for the app to perform its task, and that the security professional

MUST review that manifest carefully.

CONTENT

1. Understand the “sandbox” and how it is built and configured on the Android

platform.


mGovernment 307

Building a sandbox

• Signed apk creates isolation boundary for application & its data

• Reviewing manifest & permissions required

• Kernel enforces sandbox protections

• An application should execute only within its own sandbox, and not

rely on other applications to boot or execute code


mGovernment 308

CONTENT

Developers should be prepared to defend and justify every permission they

grant, and the security prodessional should challenge every one.

It is possible to allow applications to “cross the boundary” of the sandbox, i.e., to

access resources outside the sandbox. In general, this is bad practice.

To summarize, each app or .apk runs within its own sandbox as we have described.

We strictly limit what can cross the boundaries of the box with the permissions of

the AndroidManifest.xml file.

And, at the end, it’s all enforced by the binder in the underlying Linux kernel.


mGovernment 309

Building a sandbox

• Signed apk creates isolation boundary for application & its data

• Reviewing manifest & permissions required

• Kernel enforces sandbox protections

• An application should execute only within its own sandbox, and not

rely on other applications to boot or execute code

LEARNING OBJECTIVES


mGovernment 310

Mobile devices with the sensitive data they usually contain and process present

a challenging problem: how do we secure that data when the device is likely to

be stolen, and the data flows over untrusted networks from the device to the

servers in the back end?

We address this largely through encryption. Data at Rest (DAR) and Data in Transit

(DIT) MUST therefore be encrypted.

The problem with a sentence like “DAR and DIT must be protected by encryption”

is that is in the passive voice. It tells you what has to happen, but not who has

to do it.

The developer MUST code the application to encrypt data where necessary, and

to communicate through SSL / TLS, and MUST do this correctly.

The Security processional MUST audit to ensure that this was done, and works

properly.

Key management is always a challenge; see the next slide.

CONTENT

1. Understand Android cryptography resources.


mGovernment 311

Glossary

DAR: Data at Rest.

DIT: Data in Transit.

• DAR and DIT must be protected by encryption

• DAR requires file encryption, DIT requires SSL / TLS

• Must be programed in; it is NOT automatic or done by the OS

• The Android Crypto Libraries

recommended include:

• javax.crypto

• javax.crypto.interfaces

• java.security

• java.security.cert

Data encryption

LEARNING OBJECTIVES


mGovernment 312

This is one of those weak points where developers consistently make mistakes

that compromise the integrity of the system.

If you are storing the key somehow, unprotected, on the same device as the

encrypted storage, you might as well have never encrypted it.

Get professional help here, and follow well-established guidelines / procedures,

i.e. PKCS from RSA. PKCSs are now maintained by the IETF in several RFCs.

Specifically, PBKDF2 from PKCS5, RFC 2898 can help with the key management

problem.

CONTENT

1. Discuss Key Management.

PKCS: Public Key Cryptography Standards, originally from RSA, now in various

RFCs from the IETF.

PBKDF2: Password-Based Key Derivation Function 2.

RSA: RSA.com, a security company, now a part of EMC.

RFC: Request for Comment, a standards or informational document from the

IETF.

IETF: Internet Engineering Task Force, the standards body for the Internet.

Glossary


mGovernment 313

• Why is it important?

Kerckhoff’s principle from 1883 states that the strength of a

cryptosystem depends on the key not the algorithm

• This is the hardest problem in cryptosystems!

• Not a technical problem - a systems engineering problem

• The process of:

• Key creation - generating keys for use in the system,

• Key distribution - exchanging keys

• Key protection - placing security mechanism to guard the keys

• Key storage - persisting the key, e.g. in a directory

• Key validation - is this a valid request

• Lifecycle management - revoking and

Key management

LEARNING OBJECTIVES


mGovernment 314

Normally, when a program is loaded, it is laid out into memory the same way

each time. In other words, a particular program instruction or piece of data will

always have the same address.

Attackers exploit this condition by overflowing an input buffer with their malicious

payload. They adjust the target location for the payload with an offset, and

having the program addresses always the same makes it easy for the attacker to

put HIS code where HE wants it.

Programmers should write code to validate all input, including truncating the

data input to the size of the buffer allocated to receive it.

Programmers are not perfect, and for various reasons, do not always do this.

ASLR randomizes the addressing, so that a given program does not load into

memory exactly the same way twice. Since specific instructions or data are no

longer in predictable locations, it is much more difficult for the attacker to put

HIS code where HE wants it.

This protection is NOT perfect, and should be considered the SECOND line of

defense. The first is good code.

CONTENT

1. Introduce Address Space Layout Randomization.


mGovernment 315

ASLR: Address Space Layout Randomization.

Glossary

• Provides some buffer

overflow protection

• Not perfect, but making

steady progress

• In Android since 4.0, 4.1

ASLR

Reference: https://en.wikipedia.org/wiki/Address_space_layout_randomization

https://en.wikipedia.org/wiki/Address_space_layout_randomization

SOURCES

LEARNING OBJECTIVES


mGovernment 316

The secure element provides secure storage of credentials (digital certificates).

This is done in dedicated, segregated hardware managed by a dedicated secure

OS separate from the host OS. A secure element is currently present in many

handsets, including several Android devices.

In the context of smart cards, an application protocol data unit (APDU) is the

communication unit between a smart card reader and a smart card. In this

context, the firewall rules managing the APDUs would be between the Secure

Element with its dedicated OS, and the host OS.

Certificates are loaded into the secure element and managed by an entity called

the TSM, Trusted Service Manager. This hierarchy as depicted in the graphic will

let, for example, Emirates ID securely load your EIDA digital certificate into the

secure element in your phone, using the wireless carriers (du and Etisalat) as the

proxies, thus facilitating identity operations.

If the handset also has an NFC radio, and app can retrieve the credential from the

secure element and present it for identity, or perhaps payment, via NFC.

The FedNet project in the UAE will include a national TSM and integration with

CONTENT

1. Introduce the Secure Element.

2. Introduce the TSM.


mGovernment 317

CONTENT

EIDA and other entities.

Interestingly, Secure Elements are not present in iOS devices, although there

are third party devices to add them. These usually consist of a sleeve with an

integrated NFC radio, and an SD card slot. The actual secure element is typically

implemented in the SD Card.

• Option for higher assurance Key

storage

• Runs in a logically and physically

separate OS

• Separate OS means for example

running JavaCard not Android

• Implements firewall rules to restrict

APDU (Application Protocol Data

Unit) access & interfaces

• Communicates with TSM (Trusted

Service Manager) over proxy or

direct means

Secure Element

LEARNING OBJECTIVES


mGovernment 318

Input validation is not Android specific, nor is it security specific, it’s just solid

coding practice.

The idea is simple: keep garbage out of the system by only accepting valid input.

Whole classes of attacks are thwarted by this simple practice.

In general, we can perform this one of two ways known as “whitelisting” and

“blacklisting”.

With whitelisting, we filter the input and only allow known good data through.

With blacklisting, we filter the input, and block known bad data.

We talk about this during the Analysis & Testing module, but we can test for

improper input validation with several techniques, not the least of which is

“fuzzing”

CONTENT

1. Discuss the importance of input validation.


mGovernment 319

• Required to protect against malicious

injection of SQL, JavaScript and other

commands

• Approaches include –

• whitelist validation: default deny,

accept only known good

• blacklist validation: default allow,

block known bad input

Input Validation

LEARNING OBJECTIVES


mGovernment 320

These are the mechanics of how to final-package and sign an Android application.

Note this is a command line example, some IDEs will do most, if not all of this for

you if configured (ex: Appcelerator)

The Android system requires that all installed applications be digitally signed with

a certificate whose private key is held by the application’s developer. The Android

system uses the certificate as a means of identifying the author of an application

and establishing trust relationships between applications. The certificate is not

used to control which applications the user can install.

The certificate does not need to be signed by a certificate authority: it is perfectly

allowable, and typical, for Android applications to use self-signed certificates.

This is a significant weakness of the Android system of code signing as compared

with the code signing procedures in place for the other major mobile platforms.

CONTENT

1. Describe the code signing process for Android Apps.


mGovernment 321

Glossary

• Get a private key for signing (either from CA like VeriSign or gener-

ate your own from OpenSSL)

• Compile application in release mode (example ant release)

• Sign application with private key

• $ jarsigner -verbose -sigalg MD5withRSA -digestalg SHA1 -keystore

my-release-key.keystore my_application.apk alias_name

• Run zipalign (in Android SDK) performance optimization, reduces

RAM usage

Code Signing Process

IDE: Integrated Development Environment.

LEARNING OBJECTIVES


mGovernment 322

There is a Good news, Bad news scenario here.

The Good news is that Google and Android require code to be signed, and we get

some security benefits from that.

The Bad news is that Google goes not require a certificate from a specific trusted

third party, i.e. they allow self-signed certificates, so we as end users have no real

assurance as to the identity of the author of an application like we do on the

other platforms.

CONTENT

1. Continue code signing discussion.


mGovernment 323

• All Android applications must be signed.

• Signature makes isolation boundary for application.

• Google / Android team currently requires No Central CA, self

sign is supported.

• Sign apk with private key with Keytool, jarsigner or other tool.

• Required to publish to App Market.

Code Signing Notes

LEARNING OBJECTIVES


mGovernment 324


CONTENT

1. Understand the security features of the Android OS.

2. Discuss data encryption and key management.

3. Understand the code signing process.

mGovernment 325


• Understand the security features of the Android OS.

• Discuss data encryption and key management.

• Understand the code signing process.



of this material

QUIZ


mGovernment 326

Quiz – Question 1

1. The PBKDF2 function is used for:

Select one:

a. Authenticating access to an application’s data.

b. Playing Angry Birds.

c. Keeping information confidential, protecting storage.

d. None of the Above.

e. Both A & C.


mGovernment 327

Module 11 : Defending Android Apps

Quiz – Question 2

Quiz – Question 3

3. The Secure Element:Select one:

Select one:

a. Is not present on iOS platforms prior to iPhone 6

b. Was a Science Fiction film starring Bruce Willis

c. Runs the same OS as the platform OS

d. Is implemented inside the Android Kernel

2. Address Space Layout Randomization (ASLR) defends against

buffer overflow attacks?

Select one:

a. True

b. False

QUIZ


mGovernment 328


of this material


mGovernment 329


Quiz – Question 4

Quiz – Question 5

4. A Secure Element can best be used:

Select one:

a. To authenticate using the public-key cryptography as with

smart card use

b. To integrate with an NFC chip providing for secure micro-

payments

c. As a separate secure data storage device like an SD card for

your pictures

d. A and B

5. Applications for the Android platform must be signed a

certificate issued by Google:

Select one:

a. True

b. False

mGovernment 3 3 0


End of Module

mGovernment 3 3 1


mGovernment 332

THEMES

CONTENT

• Applications, Security

In this module, we will show you how simple it is for an attacker to decompile

your Android app and gain access to your source code.

mGovernment 333

Module 12: Decompiling Android Apps

Decompiling Android Apps

LEARNING OBJECTIVES


mGovernment 334

CONTENT



1. Understand the ease with which an attacker can decompile your app and

gain access to your source code.

2. Understand the implications:

a. Ability to Trojan apps.

b. Ability to reverse engineer the back end APIs.


mGovernment 335

• Understand the ease with which an attacker can decompile your

app and gain access to your source code.

• Understand the implications:

• Ability to Trojan apps.

• Ability to reverse engineer the back end APIs.

Objectives

LEARNING OBJECTIVES

INSTRUCTOR GUIDANCE

CONTENT


mGovernment 336

• Situational Awareness: This is shared across several mobile platforms.

We will talk through the process of building an Android app at a high level, and

de-compiling it like an attacker to get back to the source code.

Let’s begin with Building the app

We start with Java source code in plain text

First we compile it into java class files

Then we run through several packaging steps

If you have an IDE (Integrated Development Environment), it will probably do

a lot of this for you automatically

Now, let’s reverse the process

We go through several steps to un-package and get back to first a dex file,

then a jar file, and finally to class files

Then we de-compile the class files and end up

Back where we started, with plain text source code

1. Overview the build process.

2. Overview the de-compilation process.


mGovernment 337

Reverse Engineering apk

Package it Build the app:

Un-Package it De-Compile itIn Reverse:

LEARNING OBJECTIVES


mGovernment 338

CONTENT

The next 18 slides are screenshots from the hands-on activity of decompiling

an Android Application.

They assume that the student has a notebook prepared with the tools nec-

essary.

1. Walk the students through the decompilation process.


mGovernment 339

• Hands-on, decompiling from the Windows Platform.

Demonstration

LEARNING OBJECTIVES


mGovernment 340

CONTENT

Beginning from the Windows desktop, open the highlighted folder in the low-

er left, labeled “Decompiler Lab”.



mGovernment 341

Open Decompiler Lab

mGov Application Developers Course -Day 3

LEARNING OBJECTIVES


mGovernment 342

CONTENT

Each folder contains two or more files, including an Instructions.txt file. For all

of the steps, the process for the student is to open the Instructions file, read

and follow the directions.



mGovernment 343

Open Step1-APK


LEARNING OBJECTIVES


mGovernment 344

CONTENT

Each folder contains two or more files, including an Instructions.txt file. For all

of the steps, the process for the student is to open the Instructions file, read

and follow the directions.



mGovernment 345

Find mGov.apk


LEARNING OBJECTIVES


mGovernment 346

CONTENT

For step One, rename the .apk file, i.e. the Android Application to end with .zip.



mGovernment 347

Rename to mGov.zip


LEARNING OBJECTIVES


mGovernment 348

CONTENT

The windows OS will pop up a warning like this one, indicating that changing

the file extension might break some things. Don’t worry, that’s exactly what

we want to do.

Windows uses the filename extension to know what type of file it is, and how

the operating system should handle it.



mGovernment 349

Click Yes

LEARNING OBJECTIVES


mGovernment 350

CONTENT

Notice that once the file is renamed, the icon for the file changes to that of a

compressed folder.

Double click on the file icon to open the compressed folder, i.e. the zip file.



mGovernment 351

Double-click mGov.zip


LEARNING OBJECTIVES


mGovernment 352

CONTENT

Opening the .zip file reveals the contents, specifically the structure of the

packaged Android Application. Notice the AndroidManifest.xml file, which

defines the permission and access controls for the application. The developer

prepared this.

Exploring the res folder will eventually reveal graphics files.

Viewing them and comparing them to the running Android Application will

show that these files contain the graphical resources used to build elements

displayed on the screen.

Finally, notice the classes.dex file, which is the actual Dalvik executable run by

the Android system. This contains the compiled application code, and we will

work with it in Step 2.

Navigate to the higher folder.



mGovernment 353

Browse the different files


LEARNING OBJECTIVES


mGovernment 354

CONTENT

Now, navigate to the Step 2 folder….



mGovernment 355

Open Step2-dex2jar


LEARNING OBJECTIVES


mGovernment 356

CONTENT

Open and follow the instructions in the Instructions file:

Double click on the shortcut to the command prompt. It’s important to

use the provided shortcut, as it opens the command prompt window in the

correct directory, and with the command execution prompt set properly to

allow the student access to the necessary commands.



mGovernment 357

Double-click Command Prompt


LEARNING OBJECTIVES


mGovernment 358

CONTENT

The command prompt window should look like this.

Confirm that you are in the proper folder by looking at the path in the prompt.



mGovernment 359

Command Prompt opens


LEARNING OBJECTIVES


mGovernment 360

CONTENT

Type in the command as shown and hit enter to execute it.

The command is: d2j-dex2jar.bat mGov.apk.



mGovernment 361

Enter this command:


LEARNING OBJECTIVES


mGovernment 362

CONTENT

The command just executed converts the Dalvik executable (the .dex file) into

a normal Java executable (the .jar file).

When finished, navigate to the higher folder.



mGovernment 363

The program runs


LEARNING OBJECTIVES


mGovernment 364

CONTENT

Now, navigate to the Step 3 folder.



mGovernment 365

Open Step3-JD-GUI



LEARNING OBJECTIVES


mGovernment 366

CONTENT

Open and follow the directions in the Instructions file:

Double click on the jd-gui.exe file. This will open a Java Decompiler with a

Graphical User Interface.



mGovernment 367

Double-click jd-gui.exe


LEARNING OBJECTIVES


mGovernment 368

CONTENT

The Decompiler should look like this..



mGovernment 369

Java Decompiler opens


LEARNING OBJECTIVES


mGovernment 370

CONTENT

Drag the .jar file produced in step 2 and drop it in the running decompiler

window.

Alternatively, use the File menu in the decompiler menu bar to open the .jar

file.



mGovernment 371

Drag/drop mGov-dex2jar.jar into Java Decompiler


LEARNING OBJECTIVES


mGovernment 372

CONTENT

A folder hierarchy should appear on the left side of the decompiler.

Single click on the plus sign to the left of the folders to open them and explore.

Continue to open sub-folders until you see files with a “J” icon.

These are the actual java class files, which are the compiled versions of the

java components of the application.



mGovernment 373

Folders appear on the left


LEARNING OBJECTIVES


mGovernment 374

CONTENT

Clicking on any of the class files (the “J” icons) will cause the source code to

appear in the right panel.

Notice that the formatting (tabs, indents and spaces) and comments appear

as they were entered by the original developer.

It is really that simple to decompile an Android application, and to access the

source code and the developers comments.



mGovernment 375

Expand the folders to review the application code


LEARNING OBJECTIVES


mGovernment 376

CONTENT

All of these controls are good, but with the following combination of problems:

• An attacker can de-compile your (or any other) application and get to the

source code

• An attacker can insert his own code, and recompile / repackage it with his

own matching AndroidManifest.xml

• Since Google will accept any certificate to perform the app signing, he can

re-sign his now trojaned version of your app

• The user can be tricked into accepting and loading this app, and if the

“Unknown Sources: Allow installation of apps from sources other than the

Play Store” box is checked under Security in Settings, the app will load and run

The Android security model, which is otherwise quite robust, can be completely

circumvented by this.

Users must understand to never load apps from untrusted sources, and to not

check the box to allow that.

Developers, and that means mGov developers, should NEVER release apps

through other than the official store channel.

1. Understand the implications of being able to easily de-compile Android

apps.


mGovernment 377

CONTENT

Primary components

• All Applications must be signed by

the developer

• The Android package (.apk) is as-

signed a distinct Linux user ID

• Privileges enforced by Kernel us-

ing Linux user ID and group Id

• Permissions defined in Android-

Mainfest.xml

• Special capabilities based permis-

sions for URI access of Content

Providers

Security Architecture

In addition, this ability to de-compile means that the attacker can reverse

engineer the API for your back end, plus he has running example code in the form

of the original app itself. This gives the attacker a huge head start on attacking

your back end.

And remember, a trojaned app usually compromises one user at a time. Attacking

the back end can yield ALL of the data it contains.

LEARNING OBJECTIVES


mGovernment 378

CONTENT

Here is an example of a trojaned, or fake application in the wild.

Droid 09 masqueraded as banking application, but it was not.

It targeted several large banks, some, like First Tech Credit Union did not even

have a REAL banking application available, nontheless, users downloaded and

installed the app.

If you do not yet have a mobile app, you might want to make it apparent on

your traditional web site that you do not.

If you do have an app, make it clear that it is only available through the official

app store, and provide links.

1. Expose a real trojaned application.


mGovernment 379

• Masquerades as banking application

• Targeted many different medium to large sized

banks – Chase, Sun Trust, BB&T, and others

• First Tech Credit Union posted a warning on

its site about the issue, saying

“If you did download the Droid09 app, please remove it from your phone and take it to

your mobile provider to ensure it’s completely removed”. It adds, “As a reminder, we

don’t currently have an app for the Android phone.”

• Reference: http://www.theinquirer.net/inquirer/news/1585716/

fraud-hits-android-apps-market

Droid 09

LEARNING OBJECTIVES


mGovernment 380

CONTENT


1. Understand the ease with which an attacker can decompile your app and

gain access to your source code

2. Understand the implications:

a. Ability to Trojan apps

b. Ability to reverse engineer the back end APIs


mGovernment 381

• Understand the ease with which an attacker can decompile your

app and gain access to your source code.

• Understand the implications:

• Ability to Trojan apps.

• Ability to reverse engineer the back end APIs.


QUIZ


mGovernment 382

It is now time to review your knowledge of this material

mGovernment 383

Quiz – Question 1


1. Decompilation of Android apps:

Select all that are correct:

a. Reveals the source code

b. Exposes the API for the back end

c. Facilitates building trojaned versions of the original app

d. Is so hard and time consuming that it is not a threat

mGovernment 3 8 4


End of Module

mGovernment 385

LEARNING OBJECTIVES

mGovernment 386


CONTENT

Code obfuscation techniques make it more difficult for an attacker to easily

decompile apps to readable source code.

Obfuscation: hiding of meaning, making code confusing, ambiguous, and

harder to interpret.

• Applications, Security.

Glossary

mGovernment 387

Module 13: Code Obfuscation

Code Obfuscation

LEARNING OBJECTIVES


mGovernment 388

CONTENT



1. Expose Obfuscation.

2. Explain the limits of obfuscation techniques.


mGovernment 389

• Expose Obfuscation

• Understand the limits of obfuscation techniques

Objectives

LEARNING OBJECTIVES


mGovernment 390

Access to source code and reverse engineering applications is ALWAYS an issue

from a security point of view.

All that really means is that the obscurity layer of the security is gone.

As the de-compilation example makes clear, the attacker will be able to read your

source code. He will find anything you have tried to “secure” by hiding it in the

code. While he will not see the source for your back end through this process, he

will see how the front end (the mobile application) communicates with the back

end, so at least that portion of your API will be exposed, with running example

code!

We cannot prevent this, but we can make it more difficult.

CONTENT

1. Overview the build process.

2. Overview the de-compilation process.


mGovernment 391

• Native apps introduce client-side code which, as HTML5 apps,

would be server-side, therefore hidden

• Attackers can find vulnerabilities through source code analysis

• Attackers can learn how the backend works by reviewing the native

app code

Is Decompilation of Applications an Issue?

LEARNING OBJECTIVES


mGovernment 392

CONTENT

A lot of security, be it physical or information security, is about making things

more difficult or time consuming for the attacker. If we as the defenders can

make the target more difficult to attack, then perhaps we can deter the attacker,

or redirect him to a less well-defended target.

That is specifically what obfuscation does; it makes it more difficult (but not

impossible) to read the code.

We hope that the attacker, when faced with obfuscated code, will choose another

target.

1. Define and explain obfuscation.


mGovernment 393

• A technique which rewrites the code into a style that is more

difficult to analyze and understand

• Code Obfuscation creates a situation where an attacker must

spend more time, money, and resources to study the code

Code Obfuscation

LEARNING OBJECTIVES


mGovernment 394

CONTENT

This is a simple block of JavaScript. It’s not Java like used in Android apps, but

it’s related and close enough to serve as a simple example of some of the

obfuscation techniques.

Let’s step through this block of code. Observe:

• It declares the variable error_level, and sets it to the value 4.

• The two comment styles, and the comments

• The function declarations, and how one function calls the other

• The first function has two arguements, and calls the second function

• The second function has three arguements, but writes some specific text,

and uses some system calls

• Language features like the reserved words, parentheses, brackets,

semicolons, etc., which cannot change

• Style elements like carriage returns, hanging indents, coding conventions

which make it easier for the human to read

1. Explain the basics of a simple block of code.


mGovernment 395

Standard JavaScript

var error_level = 4; /* error level to show alerts for*/function log_error(whereStr, msg){

log_common(3,"error:" + whereStr, msg);//call common function

}

function log_common(lvl, whereStr, msg){var buf = '<div class=logitem>' + new Date() +

whereStr + msg + '</div>';if (lvl >= error_level)

alert(buf);errlog.write(buf);

}

LEARNING OBJECTIVES


mGovernment 396

CONTENT

This is functionally the same code block as on the previous slide, except that it

has been “minified” as described in the slide.

Note the reserved words (var function, etc), the numbers of arguments in the

functions, the fixes strings, and the system calls.

Compare with the previous slide and you will see that these two blocks of code

do exactly the same thing.

The machine can not tell the difference, will execute both, and produce the

same result.

The last statement is not strictly 100% accurate. Minification is commonly used

with Javascript to speed up execution. It contains less characters, so it will travel

from the server to the client (in this case a browser) more quickly, and when

received, it will parse and therefor execute more quickly for the same reason.

1. Show and explain a trivial example of obfuscation.


mGovernment 397

SOURCES

var q=4;function y(a,b){x(3,”error:”+a,b);}function x(c,d,e){var f=’<div

class=logitem>’+new Date()+d+e+’</div>’;if(c>=q)alert(f);r.write(f);}

• Comments removed

• Unnecessary white-space removed

• Variables changed to shorter names

Reference: https://en.wikipedia.org/wiki/Minification_%28program-

ming%29

Minified JavaScript

https://en.wikipedia.org/wiki/Minification_%28programming%29

LEARNING OBJECTIVES


mGovernment 398

CONTENT

There are more powerful techniques which can be use to obfuscate code.

You have seen the simple level in the previous two slides.

Dead code injection involves inserting code blocks which are never called, or

which perform null operations.

Expressions and hex escapes which are easily parsed by the machine can be

extremely confusing to a human.

We’ll look at the more complex expression substitutions in the next example.

Remember, and we will reinforce this in the next two slides, we are not making it

impossible for the attacker to transform the code back into something human

readable, we are just making it more difficult and time consuming.

1. Expose additional obfuscation techniques.


mGovernment 399

• Obfuscation potency, the level confusion to the reader:

• Simple – Minification (Removing code comments & white space,

changing variable names)

• Moderate – Dead code injection

• Complex – Expressions, Hex escapes, etc.

• Obfuscation Resiliency

How difficult it is to put the code back together?

• Remember mobile devices have limited resources and obfuscation

can create performance delays

Not all Obfuscation is the Same


mGovernment 400

CONTENT

This is the same source block we started out with before.

Focus on the reserved words, and on the declaration of the variable error_level,

and setting it to 4.


mGovernment 401

Standard JavaScript

var error_level = 4; /* error level to show alerts for*/function log_error(whereStr, msg){

log_common(3,"error:" + whereStr, msg);//call common function

}

function log_common(lvl, whereStr, msg){var buf = '<div class=logitem>' + new Date() +

whereStr + msg + '</div>';if (lvl >= error_level)

alert(buf);errlog.write(buf);

}

LEARNING OBJECTIVES


mGovernment 402

CONTENT

This is still readable, but much harder to understand.

Focusing on the reserved words in the language, we can see a variable declaration

in the first line (in red).

Instead of a readable variable name, or a single letter variable name, we now

have “zfafb4b3d80”. This could just as easily be MUCH longer.

The open and close parenthesis in that expression mean in this case “do some

math”

The math is: take the values “0x550” and add to it “1066”, then subtract “0x976)

0x550 and 0x976 are encoded in hexidecimal, 1066 in decimal. The machine

will convert:

0x550 1360

+1066

---------

2426

0x976 - 2422

---------

4

1. Demonstrate more advanced obfuscation techniques.


mGovernment 403

Very Obfuscated

var zfafb4b3d80=(0x550+1066-0x976);function

z9fe5826ce8(z0bf8c0e6c8,z26241da7c7){za56048cb23((0x1cf+6841-

0x1c85),”\x65\x72\x72\x6f\x72\x3a”+z0bf8c0e6c8,z26241da7c7);}

function za56048cb23(z26241da7c7,z3309f8f2aa,z2e4d4a9bbf)

{var z0bf8c0e6c8=”\x3c\x64\x69\x76\x20\x63\x6c\x61\

x73\x73\x3d\x6c\x6f\x67\x69\x74\x65\x6d\x3e”+new

Date()+z3309f8f2aa+z2e4d4a9bbf+”\x3c\x2f\x64\x69\x76\

x3e”;if(z26241da7c7>=zfafb4b3d80){alert(z0bf8c0e6c8);}z9df02a65fb.

write(z0bf8c0e6c8);}

CONTENT

We can see with this first line that we are looking at functionally identical code.

Look deeper into the obfuscated code block and you will see additional reserved

words (function), and syntax elements.

This is much harder, but still not impossible to read.

LEARNING OBJECTIVES


mGovernment 404

CONTENT

Strongly consider obfuscating your code, particularly if it is a sensitive application.

Tools are out there; google is your friend in locating them.

The CoDI will test your code to determine if you have obfuscated the source, and

recommends that you do.

1. Discuss obfuscation tools.


mGovernment 405

Obfuscation Tools

• Automated tools to obfuscate code are available

• Commercial

• Free / Open

• Google will help you find them

• CoDI will test to see if you have obfuscated your source

LEARNING OBJECTIVES


mGovernment 406

CONTENT


1. Expose Obfuscation.

2. Understand the limits of obfuscation techniques.

mGovernment 407



• Expose Obfuscation.

• Understand the limits of obfuscation techniques.

QUIZ


mGovernment 408


of this material


mGovernment 409


Quiz – Question 1

1. Obfuscation makes it more difficult and time consuming, but

not impossible, for an attacker to read and understand source

code.

Select one:

a. True

b. False

mGovernment 4 1 0


End of Module

mGovernment 4 1 1


mGovernment 412

CONTENT

This is a discussion of Public Key Cryptography and PKI.

This is not in any way exclusive to peculiar to Android, but we need understand it

for all platforms and the bigger picture.

THEMES

Glossary


Crypto: Cryptography.

PKI: Public Key Infrastructure.


mGovernment 4 1 3

Module 14: Crypto & PKI

Crypto &

PKI

LEARNING OBJECTIVES


mGovernment 414

CONTENT



1. Understand basic cryptography.

2. Understand the difference between symmetric and asymmetric encryption.

3. Understand the fundamentals of a PKI.


mGovernment 415

• Understand basic cryptography.

• Understand the difference between symmetric and asymmetric

encryption.

• Understand the fundamentals of a PKI.

Objectives

LEARNING OBJECTIVES


mGovernment 416

CONTENT

Let’s begin by defining some very basic terms for use in this and some

subsequent modules.

1. Define some basic terms.


mGovernment 417

• Encryption: Turns a clear-text message (plaintext) into a data

stream which looks like a meaningless and random sequence of

bits (ciphertext).

• Decryption: Reverses that process, cyphertext -> plaintext.

• Cryptographic Algorithm, aka a cipher: A mathematical function

that tells us how to do these transformations. A set of rules or

operations.

• Key: Mixed in with the plaintext to produce the cyphertext, or to

reverse the process.

Crypto 101

LEARNING OBJECTIVES


mGovernment 418

CONTENT

Some more definitions, this time of more advanced terms.

It is critical to understand the difference between symmetrical and asymmetrical

cryptography, as this is the fundamental basis for modern cryptography.

The main issue with symmetrical cryptography involves key management, spe-

cifically, the distribution of keys. Asymmetrical cryptography solves this prob-

lem, and brings other interesting properties along.

1. Continue definitions.


mGovernment 419

• Symmetrical Encryption: Uses the same key to encrypt and to

decrypt.

• Cypher is normally published.

• Sender and receiver use a common key.

• Key is secret.

• Asymmetrical Encryption: Uses one key to encrypt, and a separate

paired key to decrypt.

• Cypher is published

• Sender and Receiver each have two keys, a key pair

• By convention, one key is public, the other is private

• Encrypt with one, decrypt with the other key in the pair

Crypto 102

LEARNING OBJECTIVES


mGovernment 420

CONTENT

We take the basic principle of asymmetrical cryptography that we introduced on

the previous slide, i.e. that you encrypt with one key, and decrypt with a different

but paired key, and we combine that with some conventions and practices to get

Public Key Cryptography.

Let’s use an example:

Alice and Bob wish to communicate securely. Each generates a key pair, and

they each designate one of the paired keys their Public Key, and the other key in

that pair their Private Key.

Both publish their public keys, and keep their private keys secret, sharing them

with no one.

For Alice to send Bob a message that only Bob can read, she encrypts it with his

public key. Since only Bob has access to the paired private key, he, and only he,

can then decrypt Alice’s message to him with that private key. No one but Bob

can do this, so this provides confidentiality.

1. Explain the basics Public Key Cryptography building on the definitions.


mGovernment 421

Asymmetric Cryptography + conventions and practices = Public Key

Cryptography.

• Uses two separate, but paired keys:

• Public Key – This key can be published.

• Private Key – Only you should have access to this key.

• Data encrypted with one key can only be decrypted by the other

key.

Public Key Cryptography

Data encrypted with your

Is decrypted with your

Who encrypts this data?

Who can read this data?

What purposedoes this serve?

Public Key Private Key Anyone Only You Confidentiality

Private Key Public Key Only You Anyone Authenticity


mGovernment 422

CONTENT

Alice could also send Bob a message encrypted with her private key, which only

she has. Bob (or anyone else) can decrypt that message with Alice’s public key

and know that only Alice could have sent it. Since anyone can have Alice’s public

key, there is no confidentiality, but there is authentication, because only Alice

has the ability to encrypt a message with her private key.

We can combine these two operations….. if Alice wishes to send Bob a private

message, and wants Bob to know that she, and only she, sent it.

• Alice, in this order:

• Encrypts the message with her private key, which only she can do,

effectively signing it.

• Encrypts the result again with Bob’s Public Key, so that only Bob can

decrypt and read it.

• Bob reverses the process:

Starting with the encrypted message, he:

• Decrypts it with his private key, which only he has. He can now read the

contents.

• Decrypts the resulting content with Alice’s public key, verifying that Alice

“signed” it, and that the message could only come from her.

The table at the bottom of the slide re-states these properties.


mGovernment 423

Asymmetric Cryptography + conventions and practices = Public Key

Cryptography.

• Uses two separate, but paired keys:

• Public Key – This key can be published.

• Private Key – Only you should have access to this key.

• Data encrypted with one key can only be decrypted by the other

key.

Public Key Cryptography

Data encrypted with your

Is decrypted with your

Who encrypts this data?

Who can read this data?

What purposedoes this serve?

Public Key Private Key Anyone Only You Confidentiality

Private Key Public Key Only You Anyone Authenticity

LEARNING OBJECTIVES


mGovernment 424

CONTENT

Lets continue the conversation and examples of public key cryptography from

the previous slide, and focus on the digital signature.

Since only you should have access to the private key in your pair, when you

encrypt something with it, you have effectively signed it.

Anyone who can access your public key can decrypt this message, thus verifying

your signature.

It is critical to maintain the private key properly. If it is shared, leaked or stolen,

we loose the essential properties if the system.

This also provides us the property of non-repudiation, which we will discuss in

detail on the next slide.

1. Continue the discussion of Public Key Cryptography, focusing on digital

signatures.


mGovernment 425

• Digital Signatures

• Since only you have access to it, when you encrypt data with your

private key, you are effectively signing the data.

• This signed data can be decrypted with only your public key –

which anyone can have.

• Since only you should have access to your private key, any data

that has been encrypted with it is confirmed to have originated

from you.

This provides a property called nonrepudiation

Public Key Cryptography (2)

LEARNING OBJECTIVES


mGovernment 426

CONTENT

Nonrepudiation is an essential property that cryptography provides which

enables a lot of things, not the least of which are legally binding digital signatures

and financial transactions.

The term originates from the law.

It works like this: Since only you have access to your private key, any message

or data encrypted with your private key must have come from you. You cannot

deny that it did, because only you have the ability to encrypt with your private

key.

Again, it is critical to maintain control of the private key in the pair, otherwise we

loose this property as well as the ones previously discussed.

1. Introduce Nonrepudiation.


mGovernment 427

• Originates from law practices (lawyers).

• “Non” – meaning “No”.

• “Repudiation” – meaning “denial”.

• “Nonrepudiation” – “No denial”.

• Nonrepudiation means there can be “no denial” that data which

has been digitally signed with your private key originated from

you.

Nonrepudiation


mGovernment 428

CONTENT

As you can imagine, the management of keys in this kind of a complicated

system becomes a problem.

As stated on the slide, we need assurance that your key pair was actually

generated by you.

We solve that with a Public Key Infrastructure, which is a set of conventions and

procedures that binds a lot of components together.

We will explore further on the next two slides.


mGovernment 429

• How do we know that the public key we obtained actually belongs

to the person we want to send encrypted data to?

• How do we know that the public key doesn’t belong to someone

trying to steal confidential information?

A Public Key Infrastructure (PKI) solves this problem

Public Key Management


mGovernment 430

LEARNING OBJECTIVES

CONTENT

Here we define some more terms we need, and begin the discussion which the

graphic on the next slide will make clear.

The Registration Authority or RA actually verifies or validates the identity of the

person or entity. The degree of diligence that the RA devotes to this validation

is the basis for the strength of the assertions. More diligence means stronger

assurance of the identity, and we can therefore trust it more. This level of

diligence is typically documented in a Certificate Practices Statement.

The CA actually performs the operations to create the digital certificates at the

direction of the RA. The CA signs the public key of the validated entity with the

CA’s private key, thus binding the verified identity to the public key, creating a

Digital Certificate.

The VA maintains copies of the certificates, and validates them on request.

In practice, these three logical entities are frequently combined into one

(commercial or government) entity.

It will all make sense after the next slide.

1. Understand PKI Roles.


mGovernment 431

There are specific roles and functions within a PKI:

• Registration Authority (RA):

Conducts an investigation to validate the identity of the person re-

questing a public/private key pair

• Certificate Authority (CA):

Certifies the identities of the owner of a public key by signing their

public key with the CA’s private key

• Validation Authority (VA):

• Validates supplied keys against a trusted resource

• An single organization can fulfill all three of these roles

(Symantec, Comodo Group, Emirates ID, etc.)

PKI Roles or Entities

LEARNING OBJECTIVES


mGovernment 432

CONTENT

<This slide is very animated and builds in the following way>

Start with Bob, who wants to be able to communicate securely. Note that in this

example, Bob has already generated his key pair.

<CLICK>

Introduce the three entities we talked about on the previous slide the RA, the CA,

and the VA. Bob sends a request for a digital certificate to the RA.

<CLICK>

The RA follows the procedures in their Certificate Practices Statement, and

assures itself that Bob really is BOB. They direct the CA to issue a certificate.

<CLICK>

The CA generates and signs the Certificate by signing Bob’s private key, sends it

to Bob, and to the VA

1. Introduce a PKI and walk through an example.


mGovernment 433

Public-Key Infrastructure (PKI)


mGovernment 434

CONTENT

<CLICK>

Now lets introduce someone Bob has a need to communicate securely with, his

bank.

<CLICK>

Bob wants his bank to transfer money from one account to another. He sends a

message to the bank, signed with his private key.

<CLICK>

The Bank contacts the VA and asks them to validate that Bob signed the message.

<CLICK>

The VA validates the signature, and returns an “OK” to the bank

<CLICK>

Now, how does all this work in the UAE?

<CLICK>

Each holder of an Emirates ID is already enrolled in this system, and the Emirates

ID card contains a digital certificate.


mGovernment 435

Public-Key Infrastructure (PKI)

LEARNING OBJECTIVES


mGovernment 436

CONTENT

The people of the UAE have a huge advantage in that the EIDA is in place and

every citizen and resident is issued an Emirates ID. That Emirates ID has an

embedded smart chip, and on that chip are a public / private key pair, the public

key signed by EIDA.

The hardest part of establishing a PKI is issuing the certificates to the users. This

is already done in the UAE.

Several projects will come together in late 2014 and forward to extend this into

the mobile world. The hardest part of the problem, validating the identities and

issuing the certificates (ID Cards) is already done.

1. Discuss the role of Emirates ID Authority.


mGovernment 437

This is how Emirates ID works

The Emirates ID card contains a unique pair of encryption keys in the

on-board smartchip, issued by the EIDA

• What does that mean for mGov?

• The hardest part of Identity Management problem is solved.

• Users can register with your mGov service simply using their

Emirates ID.

• Users can receive encrypted messages from you.

• Users can send digitally signed messages to you.

Role of EIDA

LEARNING OBJECTIVES


mGovernment 438

CONTENT


1. Understand basic cryptography.

2. Understand the difference between symmetric and asymmetric encryption.

3. Understand the fundamentals of a PKI.

mGovernment 439

Module 14 : Crypto & PKI


• Understand basic cryptography.

• Understand the difference between symmetric and asymmetric

encryption.

• Understand the fundamentals of a PKI.

QUIZ


mGovernment 440


of this material


mGovernment 441


Quiz – Question 2

Quiz – Question 1

1. Public Key Cryptography is a method of safely sharing

symmetric encryption keys and allowing us to digitally sign

information.

Select one:

a. This statement is 100% accurate.

b. Public Key Cryptography does not use symmetric encryption.

c. Public Key Cryptography replaces the need for digital

signatures.

d. The correct name is “Private Key Cryptography”.

2. The role of the RA (Registration Authority) in the PKI is to:

Select one:

a. Verify the identity of the person or entity according to the

RAs Certificate Practice Statement.

b. Create the Digital Certificate by signing the entity’s public

key.

c. Maintain copies of certificates and validates them upon

request.

mGovernment 4 4 2


End of Module

mGovernment 4 4 3


mGovernment 444

CONTENT

This module contains an introduction to and discussion of SSL / TLS.

This is not in any way exclusive to peculiar to Android, but we need to understand

it for all platforms and the bigger picture.

THEMES

GLOSSARY


SSL: Secure Sockets Layer.

TLS: Transport Layer Security.


mGovernment 4 4 5

Module 15: SSL / TLS

SSL / TLS

LEARNING OBJECTIVES


mGovernment 446

CONTENT



1. Introduce SSL / TLS.

2. Understand what SSL / TLS does for us.

3. Understand the role of SSL / TLS in mobile computing.


mGovernment 447

Objectives

• Introduce SSL / TLS.

• Understand what SSL / TLS does for us.

• Understand the role of SSL / TLS in mobile computing.

LEARNING OBJECTIVES


mGovernment 448

CONTENT

The acronyms SSL and TLS are used interchangeably, but they are not exactly

he same.

SSL was invented by Netscape Communications for use in the Netscape Web

Browser.

Version 1.0 was never released to the public.

Version 2 was released, but issues were discovered.

Version 3 was also released, and then was moved into the IETF standards track

for maintenance and enhancement.

The working group renamed it TLS, which is what it remains today.

1. Introduce SSL and TLS.


mGovernment 449

TLS / SSL

• TLS – Transport Layer Security

• SSL – Secure Sockets Layer

• SSL TLS

• SSL evolved into what is known as TLS today.

• SSL is an older protocol which is still supported via TLS.

• Most new devices implement TLS (not SSL).

• When most people say “SSL”, they mean “TLS”.

• Unless we get into very detailed discussions about older

technology, it is safe to think that TLS and SSL are the same thing.

LEARNING OBJECTIVES


mGovernment 450

CONTENT

What does it really do for us?

In no particular order, i.e., some of these protections may be more important at

one time than another, depending on the use:

It encrypts the communications CHANNEL between the client and the server.

Data in Transit (DIT) between the two is private, i.e. safe against INFORMATION

DISCLOSURE, and at least partially protected against TAMPERING and SPOOFING.

At the most basic level, it authenticates the server to the client. The client can

validate the identity of the server.

It can also authenticate the identity of the client to the server. This is optional

and client side authentication is traditionally regarded as difficult because of

scalability issues.

In the Emirates, that problem is largely solved by EIDA and government agencies

will be able to validate client (user) identity eventually over the FedNet.

1. Discuss the two basic benefits of SSL / TLS.


mGovernment 451

• Encrypts the communication channel HTTP through TLS / SSL

becomes HTTPS

• Authenticates server to client

Client accessing https://www.foobar.com knows they are

connecting with “FooBar Corporation”, and that only foobar.com

can understand (decrypt) the request

• IF using client side certificates, the server can authenticate the

client This is not common, but technically possible

What does TLS / SSL do?

LEARNING OBJECTIVES


mGovernment 452

CONTENT

Lets apply the STRIDE model we discussed previously.

Looking at the DATA, METHOD AND CHANNEL, we can see that TLS protects

against the threat of INFORMATION DISCLOSURE in the CHANNEL, and provides

partial mitigation against SPOOFING and TAMPERING.

1. Analyze SSL / TLS using the STRIDE Threat model.


mGovernment 453

TLS / SSL Services

LEARNING OBJECTIVES


mGovernment 454

CONTENT

With SSL / TLS, the client and server negotiate until they agree on compatible

parameters.

The client begins, requesting an SSL / TLS connection, and supplying certain

parameters.

The server responds with its capabilities, and its digital certificate.

Most important step: The client validates the certificate. At a minimum,

the certificate should be valid, current, correctly signed with the private key

corresponding to a digital certificate from one of the CAs which are pre-loaded

in the client (browser, mobile device, etc.). Continuing certificate validation,

the Canonical Name (aka CNAME or CN) within the certificate MUST match the

domain name of the server. If it does, the client has assurance as to the identity

of the server.

At that point, the client generates a random session key, encrypts it with the

public key of the server from the server’s certificate, and sends the encrypted

key to the server. The client is finished at this point.

The server is finished negotiating at this point. After it decrypts the random

session key with the server’s private key, the client and server both now have

that key, and can now exchange information securely by encrypting the data

with the session key.

1. Walk through the simple SSL / TLS Handshake.


mGovernment 455

TLS / SSL Handshake

LEARNING OBJECTIVES


mGovernment 456

CONTENT

Mutual Authentications means that both parties have assurance as to the

Identity of the other.

In SSL / TLS, this requires clients to have digital certificates of their own.

The negotiation works the say was as on the previous side, except after the client

validates the server certificate and generates, encrypts and sends the session

key to the server, it also sends a copy of its client certificate. The server validates

the client certificate much as the client with the server certificate. At this point,

both parties have assurance as to the identity of the other party.

This is the “crown jewels”, and the UAE are very well positioned to get there since

the Emirates ID in the hands of every citizen or resident contains a client digital

certificate.

1. Continue and expand from the previous slide to include use of Client

Certificates in the handshake.


mGovernment 457

Mutual Authentication

LEARNING OBJECTIVES


mGovernment 458

CONTENT

I can think of virtually no cases where it does not make sense to use TLS always.

“Mixed modes” mean that some traffic is encrypted, some is not. It adds

significant complexity to the logic of both the client and back end, and introduces

the possibility of sending sensitive data unencrypted / unprotected, so it is best

to avoid it.

“SSL / TLS Always” is the most secure, and the simplest approach for the

programmer. Mixing secure vs. non secure modes mean that both the client and

server have to implement some kind of traffic control mechanism to manage

which data goes over which channel. It is much easier to just use a single, secure

channel.

If you must use mixed channels for some reason, make sure the secure channel

is used for:

• All login attempts

• The duration of all authenticated secure sessions

• Transactions containing sensitive data

1. Recommend that SSL / TLS always be used.


mGovernment 459

Always

• Simplest approach – Encrypt all communications with TLS / SSL.

Avoid mixed mode!

• At the very least, use TLS / SSL for:

• All login attempts.

• The duration of all authenticated secure sessions.

• Transactions containing sensitive data.

When should I use TSL / SSL?

LEARNING OBJECTIVES


mGovernment 460

CONTENT

The graphic serves to illustrate that even the best tools, in this case, a bicycle

chain and lock are useless if not used correctly.

Among other things, the client and server have to be in sync.

Synchronization means, among another things, having clocks that are correct

(mostly) and certificates that are valid, and signed by CAs recognized by the oth-

er party.

Valid in this sense means:

• The date when the certificate was issued / became valid is in the past.

• The date when the certificate expires is in the future.

Both will cause errors. Your code should handle these and any other certificate

validation errors, not just proceed anyway.

1. Emphasize that SSL / TLS must be used correctly to provide the benefits.


mGovernment 461

• Server & Client must be

synchronized.

• Must also synchronize with:

• Client Certificate Authority

Root.

• Server Certificate Authority

Root.

What can go wrong?

LEARNING OBJECTIVES


mGovernment 462

CONTENT

This is a partial listing of some certification validation errors. Client and server

code must handle these errors, and not proceed with the handshake if they

occur.

1. List some SSL validation errors and emphasize that they must be handled.


mGovernment 463

SSL Error Handling

Constants

int SSL_DATE_IN-

VALID

Certificate date is invalid

int SSL_EXPIRED Certificate expired

int SSL_IDMIS-

MATCH

Hostname mismatch

int SSL_INVALID Generic error

int SSL_MAX_ER-

ROR

(deprecated)

int SSL_NOTYET-

VALID

Certificate not yet valid

int SSL_UNTRUST-

ED

Certificate authority not trusted

LEARNING OBJECTIVES


mGovernment 464

CONTENT

Here is a checklist for deploying TLS in your applications:

The last two bullets are particularly important. A lot of the digital world was

found to be (and remains) vulnerable to the heartbleed problem in OpenSSL. It

is a lot more widespread that most people realize, and will be with us for a long

time in legacy equipment and software.

Testing did eventually uncover it.

1. Present a checklist for the use of the developer and security professional to

use when building / checking apps.


mGovernment 465

• TLS / SSL only – no “mixed mode” (unsecured, unauthenticated

network communications)

• Verify certificates

• Verify name (CN, Canonical Name)

• Know your errors, and handle them appropriately

• Verify the CAs in the root for devices

• Verify the server side

• Test! Never assume “it just works”

• Remember: Heartbleed

App Checklist

LEARNING OBJECTIVES


mGovernment 466

CONTENT


1. Introduce SSL / TLS.

2. Understand what SSL / TLS does for us.

3. Understand the role of SSL / TLS in mobile computing.

mGovernment 467

Module 15 : SSL / TLS

• Introduce SSL / TLS.

• Understand what SSL / TLS does for us.

• Understand the role of SSL / TLS in mobile computing.



of this material

QUIZ


mGovernment 468

Quiz – Question 1

1. TLS / SSL mitigates against which of the STRIDE Threat Model

threats in the channel (pick three)?

Select one or more:

a. Spoofing.

b. Tampering.

c. Repudiation.

d. Information Disclosure.

e. Denial of Service.

f. Elevation of Privilege.


mGovernment 469


Quiz – Question 3

Quiz – Question 2

2. SSL protects which part of the application Attack Surface.

Select one:

a. Message Data

b. Application Method

c. Communication Channel

d. None of the Above

3. When authenticating a SSL connection to amazon.com which

part of the certificate is authenticated?

Select one:

a. CP= amazon.com.

b. notDuring=May 17 00:00:00 2013 GMT.

c. CN= amazon.com

d. None of the Above.

QUIZ


mGovernment 470


of this material


mGovernment 471


Quiz – Question 4

4. Client side SSL certificates are used for:

Select one:

a. Authenticating the server.

b. Authenticating the client.

c. Both of the above.

d. Neither of the above.

mGovernment 4 7 2


End of Module

mGovernment 4 7 3


mGovernment 474

CONTENT

This module continues the discussion of mobile platforms by discussing iOS

(iPhone) security mechanisms.

There are fewer slides here than in the Android module, but a lot of the basics we

covered with Android apply here as well.

THEMES

Glossary


iOS: Apple’s Operating System for the iPhone and iPad









Introduction


Glossary

Module 16: iOS Security

iOS Security


mGovernment 476

LEARNING OBJECTIVES

CONTENT

Let’s discuss incentives. It is important to understand a vendors incentives, and

business models to understand some of the architecture and design decisions

they have made.

For example, Apple leveraged the existing heritage of Macs and technical skills

of it’s developers to make the decisions to use Objective C as the development

language. In doing so they inherited the problems with C family languages…

because they were incentivized to use the legacy skills of the existing apple

developer base.

What are the motivations (incentives) for Apple? They sell devices, they develop

the UI, and the resulting user experience is very smooth. They are incentivized

to keep it that way.

By doing so, they can sell more devices…and songs and videos via iTunes, the

biggest money maker for Apple. Apple revolutionized the mobile market with

the iPhone, and no one will argue that point, but perhaps their most brilliant

decision was to tie the iPhone so tightly to iTunes. The placed a music store in

your hands, and turned the music industry upside down in the process.

1. Discuss Incentives and their influence on design decisions.


CONTENT

• Comparison of platforms reveals differences.

• Understanding the motivations, business models and inventives of

Apple vs. Google helps us understand the differences.

Incentives

Google’s revenue is from advertising…that’s why they do it the way they do it.

They want to maximize the number of eyes seeing Google advertising, so they

give away the operating system, and make it trivially easy to become an Android

app developer.

Apple sells hardware, music and videos. They give away virtually nothing.

Google (for the most part) does not sell hardware, gives away the OS to

manufacturers and individuals. They sell adds, so more eyes on (Android) screens

is better for them.


mGovernment 478

LEARNING OBJECTIVES

CONTENT



1. Understand the architecture of the iOS operating system.



• Understand the architecture of the iOS operating system.

• Understand the security model.

Objectives


mGovernment 480

LEARNING OBJECTIVES

CONTENT

Compare the architecture with Android on this and the next slide.

This is similar to the Android architecture of Activities, Services, Content Providers,

etc., and as of the 2014 World Wide Developer Conference, it seems like they are

moving more in the Android direction of more integrated applications.

It’s layered model, similar to Android’s but a little less cluttered.

1. Introduce the iOS architecture.


iOS Layered Architecture

• Cocoa Touch

App development framework

• Media

Multimedia, audio, visual, graphics

• Core Services

Networking, iCloud, location,

Security APIs

• Core OS

Low level, Bluetooth LE, Security

services, certificate, key

management

Like the Android slide, except

designed in Cupertino…..

LEARNING OBJECTIVES


mGovernment 482

CONTENT

Starting at the physical layer and working up, we see some differences with

Android.

First, Apple designs and manufactures (OK, they contract that out) their own

hardware. Unlike google, they are in control. At any given time, there are ~3

“current” device designs in the market, and practically one OS version, whatever

is current.

There is a crypto engine with an embedded Apple certificate in the hardware, so

on a non-jailbroken device, there is the ability to validate that applications are

digitally signed by an Apple-issued and signed certificate.

The kernel is Unix based, so the low level Unix type file permissions that we are

used to on Android are here as well.

The filesystem is encrypted, with the OS and the userspace segregated.

Applications run in individual sandboxes, like Android.

There is no removable storage, so we don’t have to worry about it encrypting

data stored there.

A secure element is present with iPhone 6 and later.

1. Introduce the iOS Security Architecture.


Glossary

• Apple’s model:

• Architecture.

• Encryption.

• Data Protection.

• Network Security.

• Physical.

iOS Security Architecture

Jailbroken: an iOS device which has been exploited to allow the installation of

applications from other than iTunes amon other things.

LEARNING OBJECTIVES


mGovernment 484

CONTENT

The graphic depicts the lifecycle of an iOS application from startup, being shifted

into background, back to the foreground, and quitting.

When shifting from one app to another (using one app and the phone rings) and

back, the transition when it comes back is very quick. The app you are returning

to is non-responsive initially… ever wonder why?

You are initially returned to a screen snap shot of the previous application, not

the app itself. This was done to enhance the user experience, giving the user the

perception of snappy performance as the iPhone switch contexts from one app

to another.

This potentially could contain very sensitive information like your bank account

number, depending on the application.

Remember incentives?

1. Expose the iOS backgrounding behavior as a potential channel for

information leakage.


CONTENT

Application Lifecycle

The security professional has to worry about where that snap shot of sensitive

information was kept. If it’s in memory – what part of memory. If it’s there and

accessible…it will be accessed.

Remember the STRIDE threat model. This is a potential Information Leakage

threat from the Method.

LEARNING OBJECTIVES


mGovernment 486

CONTENT

Android applications are written in java, and run in a java virtual machine called

Dalvik. One of the benefits of this is that the environment manages the memory

for the developer.

Up until June 2014, the only programming language for iOS applications was

Objective C, which shares some of the traditional C family languages problems.

The most recent Objective C compiler takes care of some of these issues for you,

but not all.

iOS applications, and iOS developers are responsible for memory management

at the end of the day.

As of the June 2014 WorldWide Developer Conference, Apple announced a new

language “Swift”

It remains to be seen what the security implications of this will be, but things

will probably change. At the minimum, for some time at least, developers will

probably be able to use either language for iOS apps

1. Contrast memory management on iOS with Android.


• iOS applications must manage memory:

• Programming language is Objective-C.

• Newer Compiler handles some, but not all issues.

• Bugs: Buffer overflows, integer overflows, double free, format

strings.

• Security features include:

• Data Execution Protection (DEP).

• Address Space Layout Randomization (ASLR).

• Rules:

• Do not allocate memory until user is authenticated.

• Protect keys & references to keys.

• Utilize randomized memory.

Memory


mGovernment 488

CONTENT

Security features include ASLR like with Android, but add Data Execution

Protection (DEP). Memory is designated executable or not, making the attackers

life more difficult.

General programming rules apply here as well. Secure programming is mostly

just good programming.


• iOS applications must manage memory:

• Programming language is Objective-C.

• Newer Compiler handles some, but not all issues.

• Bugs: Buffer overflows, integer overflows, double free, format

strings.

• Security features include:

• Data Execution Protection (DEP).

• Address Space Layout Randomization (ASLR).

• Rules:

• Do not allocate memory until user is authenticated.

• Protect keys & references to keys.

• Utilize randomized memory.

Memory


mGovernment 490

LEARNING OBJECTIVES

1. Discuss storage with iOS.

• On the device, the primary difference is that there is no removable storage

like on Android and the other platforms.

• Internally, we have access to Plists, which typically store configuration

information.

• As with Android, there is a SQLite database available.

• The Keychain is an apple innovation that we will discuss in a few slides

• iOS has an integrated certificate store, and the normal assortment of buffers

and caches.

• Off the device, the innovation is the iCloud. This requires networking

access to function, and over time, applications have taken more and more

advantage of it.

CONTENT


• On device

• Files, Plists

• SQLite

• Keychain

• Certificate store

• Buffers & caches

• Off device

• Networking

• iCloud

• Streams

• P2P

• Push Notifications

Storage

LEARNING OBJECTIVES


mGovernment 492

CONTENT

What’s involved with getting an app into the iTunes app store?

First the developer must register with Apple and pay a fee, $100 US currently.

Apple issues the developer a digital certificate for the purpose of signing apps.

The certificate chains back to an Apple CA, as does the certificate embedded in

the hardware, so the iPhones and iPads can validate that they are loaded apps

from known developers.

There is a set of standards published by Apple for apps. This tends to be a moving

target, but Apple will check an app before it accepts it. It’s reasonable to assume

that they are performing some static analysis of the source code, so they are

trying to be proactive and keep the bad stuff out of the iTunes store.

They are of course also concerned about usability, a User Experience consistent

with their guidelines, and revenue issues.

Contrast this with Google / Android approval model, where apps are apparently

more readily accepted into the Play store.

Apple model: Keep bad stuff out of the store from the beginning.

Android model: Pull it out when discovered, lots more apps to encourage

adoption.

1. Compare and contrast the process and policies for getting an app accepted

by Apple vs. by Google.


What security can you expect

from App Store review

process?

• In general, Apple is likely to be

more concerned with usability and

revenue than security.

• Reasonable to assume some static

analysis and no dynamic analysis

• Not perfect, but overall result is

far better than Android at keeping

malware out of its App Store

App Store Process

LEARNING OBJECTIVES


mGovernment 494

CONTENT

Decompilation of binary applications is possible on any platform, but it rarely

yields the kind of treasure we find on the Android platform.

It is definitely possible on the iOS platform, just not as easy as Android.

Commercial and free tools exist, and it is possible to patch (trojan) binaries, but

they should be caught at install time when their signature does not validate.

The Good news: this does not yield a human readable block of source code like

Android.

But, if you have ever seen a hacker (reverse engineer) blow through assembly

code with IDAPro, you begin to understand that this IS possible.

1. Discuss decompilation of iOS apps.


Glossary

IDA Pro: Interactive Disassembler used for disassembly and reverse engineering

of binary applications.

• Assume iOS applications can and will be reverse engineered by

attackers…but not as easily as Android.

• Free and commercial tools available.

• Information can be harvested from binaries.

• Binaries can be patched by attackers to create trojanized applications.

• It is more difficult than Android, but possible.

Decompilation

LEARNING OBJECTIVES


mGovernment 496

CONTENT

The model for signing code on iOS is similar to that for Android, but with two

large differences:

• First, with iOS, Apple as the hardware manufacturer embeds their own

certificate in the hardware. iOS uses this to validate the signature on the apps.

• Second, Apple requires developers to register with them and to pay a fee.

Apple then issues each developer a digital certificate signed by Apple. That

signature is checked by Apple when the developer submits the app to them,

when it goes in the iTunes store, and then the iPhone loads it. It also is used for

these other purposes.

This is overall a much more secure system than is in place with Android, and is

similar to what is in place with Windows phone and Blackberry.

1. Discuss the code signing process for iOS apps, and how it differs from the

Android / Google process.


• Registration and verification process required for developers and

for all third party applications

• Required for App Store and iOS execution

• Unlike Android, executable code must be signed with an Apple

issued certificate

• Signature used for

• LoadingUpdate

• Authentication

• Runtime Integrity

• Sandboxing

Code Signing for iOS

LEARNING OBJECTIVES


mGovernment 498

CONTENT

Prior to the iPhone 6, the keychain on iOS was as close as we come to having a

secure element on the iOS platform without external hardware, but it is different.

External hardware with iPhones is an issue:

• Ugly, spoils the aesthetics, makes the phone less desirable to the user

• For the data thief, it screams “steal me”

Speculation is that Apple may include a secure element in future versions.

They have an alternative to NFC, so it is not clear where they will go. Included in

iPhone 6 and later.

In the mean time, the keychain can securely store (strong) keys for the user on

a per-application basis, and supply them automatically when the user accesses

the app.

The protection is only as good as you protecting the device. If the device is

stolen, the attacker may be able to use your stored keys.

There is a flow chart on the next slide which shows how the keychain works in

practice.

1. Expose and describe the Keychain.


• Protected storage.

• Important note – the protection is only as good as what protects

the device: physical access and passcode.

• Key interfaces.

• Add and update keys.

• Search for keys.

• Entitlement based access through keychain-access-groups.

Keychain

LEARNING OBJECTIVES


mGovernment 500

CONTENT

This is a flow diagram of how the keychain works with iOS apps.

Follow it through, it’s pretty intuitive.

1. Show a flow chart of the keychain in operation.


• Try to locate stored key

(SecItemCopyMatching).

• Otherwise prompt user and if

login successful, ask to store with

with either:

• SecItemAdd.

• SecItemUpdate.

Keychain In Practice

LEARNING OBJECTIVES


mGovernment 502

CONTENT

SSL and TLS clients and servers negotiate during the handshake. One of the

things selected is SSL vs TLS and which version.

Systems should be configured to NEVER negotiate below SSL v3, and the latest

version of TLS is always prefered.

DTLS is Datagram TLS, or TLS for UDP as opposed to TCP.

The same issues and considerations apply here as for Android, except Apple does

not, and never did use OpenSSL, so the heartbleed bug was not here.

1. Discuss SSL / TLS on iOS.


Glossary

DTLS: Datagram TLS.

TCP: Transmission Control Protocol, session-oriented transport protocol from

the Internet Suite.

UDP: User Datagram Protocol, sessionless transport protocol from the Internet

Suite.

• iOS supports SSL v3, TLS 1.1 & 1.2, and DTLS.

• Considerations.

• Used for one way (usually) or two way (infrequently) authentication.

• Encrypt communications channel.

• Coordinating Solution.

• Check hostname.

• Ensure exceptions are managed.

• Complications.

• Error handling.

• Testing issues for SSL clients.

• Mixed mode issues.

• Ensure certificate chains and roots are deployed.

TLS / SSL

LEARNING OBJECTIVES


mGovernment 504

CONTENT

The sandbox here works a little differently, and is not considered as strong as the

Android one, but it is here.

1. Discuss the Sandbox as implemented on iOS.


• Boundary defined by digital signature.

• Protected by DEP (Data Execution

Protection) and ASLR (Address Space

Location Randomization).

• Does not limit network

communications, sockets, or

interaction with system services.

iOS Sandbox

LEARNING OBJECTIVES


mGovernment 506

CONTENT


1. Understand the architecture of the iOS operating system.



• Understand the architecture of the iOS operating system.

• Understand the security model .



of this material

QUIZ


mGovernment 508

Quiz – Question 1

1. iOS applications are written in:

Select two:

a. A Java-like language.

b. C#.

c. Python.

d. Objective C.

e. C++.

f. Swift


mGovernment 509


Quiz – Question 3

Quiz – Question 2

2. ASLR is: (pick the best answer):

Select one:

a. Only used on iOS platforms.

b. Only used on Android platforms.

c. Used to protect against buffer overflows.

d. Exclusive to the Blackberry Enterprise Server.

3. All iOS Applications may be signed by a third party OpenSSL

certificate to be deployed in the Apple App Store.

Select one:

a. True

b. False

QUIZ


mGovernment 510


of this material


mGovernment 511


Quiz – Question 4

4. All iOS Applications must be signed by an Apple issued

certificate to be deployed in the Apple App Store.

Select one:

a. True

b. False

mGoverment 5 1 2

End of Module

mGoverment 5 1 3


mGovernment 514

CONTENT

This module continues the discussion of mobile platforms by discussing Windows

Phone security mechanisms.

There are fewer slides here than in the Android module, but a lot of the basics we

covered with Android apply here as well.

THEMES










Introduction


Glossary

Module 17: Windows Phone Security

Windows Phone Security

LEARNING OBJECTIVES


mGovernment 516

CONTENT



1. Understand security model and peculiarities of Windows Phone.


mGovernment 517

• Understand security model and peculiarities of Windows Phone.

Objectives

LEARNING OBJECTIVES


mGovernment 518

CONTENT

Windows phone code signing requirements are similar to the Android / Apple

requirements, with the following exception:

Microsoft requires that developers sign code, and that they obtain a code signing

certificate from a designated 3d party, Symantec at this point.

This signature model is stronger than Android’s, but weaker than iOS and

Blackberry because there is no certificate embedded in the handset at

manufacturing time.

Each application runs in a sandbox, similar to the other platforms, and application

are run by the Execution Manager.

1. Introduce the Windows Phone Platform.


mGovernment 519

• Windows Phone store enforces mandatory code signing

• Applications are run by the Execution Manager

• Each application runs in its own sandboxed process

Windows Phone Platform

LEARNING OBJECTIVES


mGovernment 520

CONTENT

There is virtually nothing new here, the same considerations as the other

platforms. So let’s review them:

• Use SSL / TLS, Always.

• Do not allow use of SSL older than SSLv3, and prefer the latest version of TLS.

• Validate certificates and certificate chains, including matching CN to the

hostname.

• No Mixed Modes.

1. Discuss Network Security on Windows Phone.


mGovernment 521

• Ensure all communications are over TLS / SSL.

• Ensure that communication do not support older (SSL v2) ciphers.

• Ensure certificates and certificate chains are validated.

• Ensure host names match.

• Ensure no mixed mode (SSL & non-SSL) is supported.

Network Security

LEARNING OBJECTIVES


mGovernment 522

CONTENT

Pay particular attention to artifacts in these folders left over from operations

(temp files) and installation.

The windows phone is a derivative of the modern MS windows OS, so the crypto

library is there, and good. Use it to protect stored data DAR), as it’s not done

globally or automatically.

Windows phones, like Androids typically have removable SD cards, unlike iOS.

Data stored there is not protected unless done so explicitly by the application.

1. Discuss the peculiarities of data security on Windows Phone.


mGovernment 523

Data persistence

• Installation folder.

• Local folder.

• Media library.

• External Storage (SD Card) Win32 APIs (Windows 8).

Data Security

LEARNING OBJECTIVES


mGovernment 524

CONTENT


1. Understand security model and peculiarities of Windows Phone.


mGovernment 525

• Understand security model and peculiarities of Windows Phone.


QUIZ


mGovernment 526


of this material


mGovernment 527


Quiz – Question 1

1. Windows Phone applications must be signed by the developer

with a Microsoft signed certificate.

Select one:

a. True

b. False

mGovernment 5 2 8


End of Module

mGovernment 5 2 9


mGovernment 530

CONTENT

This module continues the discussion of mobile platforms by discussing

Blackberry and the Blackberry Enterprise Server (BES).

This is a little bit of a different animal in that it is not appropriate to discuss the

blackberry handheld as a standalone. You have to consider the BES, discussed

later.

On the one hand, client platform decisions are largely out of the hands of the

mGov developer / security person, certainly in G2C (government to citizen)

model. On the other hand, in G2G and G2E (Government to government or

employee) that may not be the case, so we’ll talk about this a little.

THEMES










Introduction


Glossary

Module 18: BlackBerry Security

BlackBerry Security

LEARNING OBJECTIVES


mGovernment 532

CONTENT



1. Understand the security model of the Blackberry.

2. Understand how the Blackberry integrates with the Blackberry Enterprise

Server (BES).


mGovernment 533

• Understand the security model of the Blackberry.

• Understand how the Blackberry integrates with the Blackberry

Enterprise Server (BES).

Objectives

LEARNING OBJECTIVES


mGovernment 534

CONTENT

Blackberry is the only one of the platforms we discuss that was designed from

the beginning for government and business use, with security as a primary

consideration from an early point.

EVERY blackberry talks to a Blackberry Enterprise Server, even citizen owned

phones talk to BESs operated by their carrier, in the UAE Du/Etisalat (TRA). The

BES is designed to manage and secure the communications to the handheld,

and the handheld itself.

With Blackberry version 10, the system was redesigned to segregate work from

personal, both apps and data.

The current BES can also do this for Android and iOS devices, and is designed to

help companies / government solve the Bring Your Own Device (BYOD) problems.

1. Expose highlights of the blackberry + BES architecture.


mGovernment 535

• It’s all about the BES 10 (BB Enterprise Server)

• Less focused on the BB Smartphone

• Focused on the BES

• Provides a separation between Work and Personal Use

• Example: cannot cut/paste between the two

• Secure, segregated storage

• Designed to be a BYOD manager

• Solves a critical problem for businesses and government

• Plays to RIMs strength - managing the endpoint devices of many

operating systems

• Where is it, what’s running on it, if lost, remote kill the access and

wipe if necessary

Blackberry Security Strategy: “A New Approach”

LEARNING OBJECTIVES


mGovernment 536

CONTENT

This is similar to what we saw on Android and iOS, but goes further in terms of

memory protections and policy controls.

The BES has several hundred policy elements that it can enforce on a configured

and connected device, including iOS and Android devices.

It can do slightly more with a blackberry handheld, but not much.

1. Discuss the access controls of the Blackberry.


mGovernment 537

• Blackberry 10 supports ASLR, non executable stack and heap

(tree-based data structure)…the highest key (parent) is the root key.

• Apps use permissions capabilities model to request access.

• Most sophisticated policy set - Resources are partitioned, Active

Directory integration, fine grained access control.

Platform Access Control

LEARNING OBJECTIVES


mGovernment 538

CONTENT

This illustrates how some of those controls mentioned on the previous slide can

work.

1. Give an example of how Platform Access Controls work on the blackberry.


mGovernment 539

Platform Access Control permissions model

LEARNING OBJECTIVES


mGovernment 540

CONTENT

The blackberry is designed to store securely to local storace, including (optionally)

to the removable SD card. When an SD card is inserted, the blackberry offers to

encrypt it.

This is very different from other platforms.

The BES can wipe data from a supported and connected device remotely, either

the whole device, or just the “work” area.

Blackberry devices will also wipe themselves automatically after a configured

number of failed login attempts, offering some protection for lost / stolen

devices.

1. Explore how secure storage is different on the blackberry.


mGovernment 541

• Passcode protected storage.

• Wipe data remotely:

• Full device.

• Work space only.

• SD Card has support for encrypted storage.

• BES 10.

• Storage separated into base file, work file, personal files.

• Each app runs under unique ID.

• Can manage Blackberry, iOS and Android devices.

Secure Storage

LEARNING OBJECTIVES


mGovernment 542

CONTENT

All communications between the blackberry handheld and its BES are TLS

encrypted. The blackberry is preloaded with the TLS certificate from the BES

server, so it can validate that one sent matched the one stored.

Additionally, BB devices sign and hash messages for additional protection, unique

to this platform.

1. Explore differences in the communications on the Blackberry platform.


mGovernment 543

• TLS on Blackberry.

• A device sends a request to the BlackBerry Infrastructure to open a

TLS connection.

• The BlackBerry Infrastructure sends its TLS certificate to the device.

• The device uses a root certificate that is preloaded on the device to

verify the TLS certificate. If the user deleted the root certificate, the

device prompts the user to trust the TLS certificate.

• The device opens the TLS connection.

• Additional message integrity: Blackberry signs and hashes

messages sent to the device using message keys for integrity.

Secure Communications

LEARNING OBJECTIVES


mGovernment 544

CONTENT


1. Understand the security model of the Blackberry.

2. Understand how the Blackberry integrates with the Blackberry Enterprise

Server (BES).


mGovernment 545

• Understand the security model of the Blackberry.

• Understand how the Blackberry integrates with the Blackberry

Enterprise Server (BES).


QUIZ


mGovernment 546


of this material


mGovernment 547


Quiz – Question 2

Quiz – Question 1

1. The BlackBerry Enterprise Server (BES) Release 10 is designed

to (pick the one best answer):

Select one:

a. Compete for the mobile smart phone market.

b. Deal with the security challenge of Bring Your Own Device

(BYOD) where the device is used for both personal and work

reasons.

c. Both of the above.

d. None of the above.

2. Which of these platforms signs and hashes messages sent by

the device to the client to ensure integrity

Select one:

a. Windows Phone

b. iOS

c. Android

d. Blackberry

e. All of the Above

f. Both A & B

g. None of the Above

mGovernment 5 4 8


End of Book

www.government.ae

MOBILE SECURITY - CoDI€¦ · Module 1: Understanding Security Windows Phone Overview •...

Documents

Transcript of MOBILE SECURITY - CoDI€¦ · Module 1: Understanding Security Windows Phone Overview •...