common security programs found within organizationsincludingincident response,securityauditing,proactivesecuritymonitoring, and forensicinvestigations.According to the 2010/2011Computer Security InstituteComputer Crime andSecurity Survey,

61.5%

of respondents

from

various companies

reported that

internal audits wereperformed within their organizations

as a security mechanism. Additionally, 44%

reported

thatdata-loss prevention

and user-content monitoring programs were in place

(Richardson, 2010).

Thesestatistics show that many organizations are aware of

insider threat

enterprise risks and havetaken stepsto mitigate them; however, given the lack oftechnology

SpecialWeapons and Tactics (SWAT)team. His device exceeded the allotted monthly character limits,causingsurchargesto beincurred by the city,which Quon

reimbursed.When his supervisorreviewedtheaudit of

Quon’sdevice,Quon was allegedly reprimanded

for sendinga large quantity of

non-work related textmessages, some of which were sexually explicit.

Quon argued that his rights were violated sincehe paid the

incurred

surcharges

(U.S. Supreme Court, 2010). The Court’s

opinion

stated

that thisverdict

was

not meant to be broad; however,there arepotentialimplications to BYOD policies

sinceit can be construed thatQuon’s mobile device, although

provided byhis employer,waspartially his since he paid for some of the charges.

This interpretation may

lead

organizationstoinstall monitoring apps like

DroidWatch on all enterprise smartphones, including

those that are

personallyowned.

Mobile phone privacy wasdiscussed in the caseof Fannie Garcia, a former police dispatcher forthe city of Laredo, Texas.

Garcia

was fired aftera

coworker’s wife discovered inappropriatecontent on Garcia’spersonalsmartphone and reported it tosupervisory personnel. The

phone

wasremoved

froman unlocked storage locker whereGarcia

worked

without Garcia’s permission.

TheFifth CircuitU.S. Court of Appealsaffirmed a district court’s ruling that Garcia’s phone contentwas not protected under the

Stored Communications Act

(SCA)

and,

as a result, upheldher12

dismissal

(U.S. Court of Appeals, 5th Circuit, 2012).

The rulingmeans

that the SCA does notprotect data stored on a smartphone, because the data is not stored withina “facility throughwhich wire and electronic communications are kept in temporary storage, or as back-up storage.”Therefore, data collected through an applikeDroidWatch

of its results, andthe potential anti-forensic opportunities available in

the app.

5.2

Design

and Implementation

5.2.1

System Architecture

DroidWatch’s system architecture is described inFigure4. Each descending layer representsahigher level of abstraction.Various collection, storage, and transfer

components are handled by aservice

that

facilitates actions within the appand the enterprise server.The individualcomponentslabeledwithin the

diagram are explained throughout

the design subsections.

18

Figure4.DroidWatch

System Architecture

5.2.2

User Consent to Monitoring

TheDroidWatch

app

isdependent

upon a user consent banner

(seeFigure5)

that appears whenthe app is

startedduring the phone’s boot

process

or launched manually through the Android appmenu.

Upon acceptance of its

terms and conditions,

which are configurable prior to the app’sinstallation in thestrings.xml

file,

a long-running service is launched to perform the

datacollection, storage, and transfer components of the system architecture. The option to reject theuser consentterms is also presentedfor the purposes of this research, although organizations maywish to omit this option in real deployments.

Rejecting or closing the user consent banner causesthe

DroidWatch

service not to run.The banner is implemented using an activity that is registeredin the AndroidManifestto receive theandroid.intent.action.BOOT_COMPLETED

details; however, they arenotgenerallyprone to false positive or duplication issues

because of their implementation details.20

Broadcast receivers react to atomic events

and

have ten seconds to perform

their

functions beforethey are

terminated by the Android operating system(Google, n.d.-c).

Alarms

5.2.3.3Alarms

are scheduled operations

configuredinDroidWatch

to periodically query contentprovidersor directlycall

static Java methodsto pull in new data.

They are reliable,

but only run atdesignated times. Data that is deleted or modified between collection runs may not be captured inits original form, if at all. In addition, other

processes mustbein place to ensure that duplicateevents fromdata sets are not added to the local SQLite database (i.e., an alarm that runs twiceover the same data set may detect the same event both times).

The strategy is based on the aforementioned pros and cons (refer toSection5.2.3) and the relativeease of implementation.First, data sets shouldbeanalyzed to determine if they generate systembroadcasts. If they do, broadcast receivers should be considered as the collection component. Ifbroadcasts are not available,considercontent observers for implementation. Alarms should beused if broadcasts and content observers are unavailable or ineffective for the targeted datacollection.

21

5.2.5

Local Storage

All collected data is stored temporarily in a local SQLite database

on the phone

and isconfiguredtobe accessible

to theDroidWatch

app

only. StandardStructured Query Language (SQL)

database functions such as selections, insertions, and

deletions are handled by a

custom-developed

DroidWatchcontent provider.

Using

a content provider instead of direct

SQLite

database calls

allows

each ofDroidWatch’s collections to performdata

storage

functions

inathread-safe and

structured manner.

A scheduled alarm periodically transfers thelocalSQLite database

file

over

hypertext transferprotocol secure

(HTTPS)

POST

to the enterprise serverfor processing.Thetransferprocess isdesigned to run

in the background with minimal impact on a user’s experience, helped by therelatively small size (50-100 kilobytes) of

the database file.Thefilesize is minimized by clearingevents dated prior to the start time of

a successful transfer event.In addition, the clearingmechanism

lessens therisk of data loss should the phone be compromised.

5.2.6

EnterpriseServer

The enterprise serverprototype,

to which the collected data flows,

is an Ubuntu Linux virtualmachine on a local, private

network running Apache,

PHP: Hypertext Processor (PHP),MySQL,and Splunk.

Apachewas

configured with a self-signedsecure socket

layer (SSL)certificate,whichwas

included as an assetfilewithin theDroidWatchapp. This allows

data to be transferredover an

HTTPS connection.

PHP code handles the secure POST uploads, extracts the events fromthe uploaded SQLite file, and stores them in an enterprise

MySQL database. Note thatthe PHPcode used on the server is available in Appendix C.

Splunk periodically pullsdata from theMySQL database

and makes the events

available in its interface for analysis and reporting.

22

5.2.7

Data Process Flow

The data process flow within the

DroidWatch

app is depicted in

Figure6.

Data collection andstorage is a continuous process,withtransfers scheduled every two hours

by default (this value isconfigurable).

Upon a successful transfer

to the enterprise server, events dated prior to thetransfer are wiped from the local phone database.

File transfer attempts

that

fail are logged

in thedatabase and do not result in the wiping of any events.

Figure6.Data Process Flow Diagram

5.2.8

Data

Sets

Table1

lists the targeted data setscollectedfor this thesis.Each data set can be configuredthrough

droidwatch.properties,

an asset fileincludedwithin the app

that

allows fortheadjustment

of

collection intervals (i.e., how long the system waits between collections).Organizations can choose to omit a data set collection

the phone used in this research runsthe older Gingerbread operating system,undocumented parts of the Android framework API areused to retrievethese events and

may not work in

other Android phones

or versions.11

The alarmis

configured toscan

thecontent://com.android.calendar/event_entities

content providerURIfor new eventsevery twelve

hours

by default.

Since the content providerdoes notallow access to

any fields thatindicate

whena calendar event is added

to a device, aseparate calendar database table is created and maintained. Upon the installationand firstexecutionof DroidWatch, the table is populated with current calendar events and marked with thecurrent timestamp.

During

periodic scans

of the built-in Android calendar, DroidWatch checkseach entry against its internalcalendar table and adds the eventif it is new.While additional datasuch as location, author, and event details are available through the content

provider, this researchfocuses

oneventdates and titles. Access to perform these actions on the calendar

data set requirestheandroid.permission.READ_CALENDAR

permission

be declared in theAndroidManifest.

11

Undocumented content provider URIs were identified through various online Android-related forums andconfirmed by their presence in the source code ofthe Android Open Source Project.

26

Call Logs

5.2.8.5Call details are

retrievable

using a variety of methods.A broadcast receiver

can be used, butnotificationsare only triggeredwhen the phone changes its state (