WHITE PAPER SECURING ENTERPRISE APPS

WHITE PAPER | SECURING ENTERPRISE APPS

Table of Contents

INTRODUCTION

Some Context: The History of Enterprise Mobility Then: The BlackBerry and Windows Mobile

Now: BYOD and Consumerization The Mobile Security Landscape

KEY SECURITY CHALLENGES FACING ENTERPRISE APP

DEVELOPMENT

The Right Platform Keeps your Protected

Access Control

Authentication

Authorization with Role-Based Access Single Sign-On

Session Management

Data Protection

Protection of Data at Rest Protection of Data in Flight

Protection from Attack

Hardened Server Logging

ABOUT VERIVO AKULA

INTRODUCTION

When it comes to IT security, “the more things change, the more they stay the same.” Despite each seismic change in technology over the years, from mainframe, to client/server, to n-tier web apps, and now to cloud and mobile, the essential challenges in protecting corporate information and assets have always been the same. In fact, each shift in IT architecture, with a constant push toward more openness and ubiquity of applications and data, has made security harder, not easier. Think about the risk of a user sitting on-campus, at a terminal that is hardwired to a mainframe computer. Compare that to a user sitting in a taxi, using a mobile device that is not owned by the company, connected to corporate data sources via the public Internet, and who might just leave that device on the seat when he gets out of the taxi. That is quite a difference! Instead of pushing back against new technology, the winners embrace new technology and turn it into a

competitive advantage. And there are always new technology solutions helping solve the latest security challenges.

Verivo has been involved in enterprise mobility for over a decade, and has continuously developed strategies and technologies to solve mobile security requirements. We believe that an open mobile app platform, conceived and built with security as a core capability, can solve the key challenges in enterprise mobility. Mobile apps built and managed using such a platform will have security “built-in”, not “layered-on”. This whitepaper discusses the key security challenges in building enterprise mobile apps and an open platform approach to solving those challenges.

Some Context: The History of Enterprise Mobility

Then: BlackBerry and Windows Mobile

Ah, the good old days. Provision a company-owned BlackBerry on the BES (BlackBerry Enterprise Server), hand it to the employee, and you were done. Security and manageability were built-in to the BlackBerry platform, which was designed around the needs of enterprises. Users were happy because BlackBerry was the gold standard and they didn’t have anything else to compare it to, except for one or two friends that had Windows Mobile devices. Microsoft also knew how to lock down corporate-owned devices and Windows Mobile was well integrated into the Windows network security model. Windows Mobile became the standard for rugged devices for field service use and its use in this vertical market continues to this day.

Then came the iPhone.

Now: BYOD and Consumerization

It was hard to see at the time that Apple’s launch of the iPhone in 2007 would end up changing everything. After all, this was first and foremost a consumer device. But plenty of business people, including BlackBerry users, bought one for personal use. Carrying two phones was not only a hassle; it gave users a constant reminder of the stark differences in the user experience between the two platforms. It was “there’s an app for that” versus “hey, you got email and calendar, what more do you want?” Apple’s maniacal focus on perfecting the user experience and the torrent of innovation unleashed by the “app economy” resulted in a once-unthinkable turn of events. Users, not IT, decided which mobile device they were going to use for work and told IT to support it. And then they handed back their BlackBerry devices. The bring-your-own-device (BYOD) model is fast becoming the norm for enterprises large and small. Reseach shows that the majority of enterprises have either formal or informal support for BYOD.

But the revolution is not just about freedom of choice in devices. Users’ expectations about the enterprise mobile user experience are heightened by their consumer mobile experience. Great design, task-specific functionality and navigation, high performance, and frequent updates are all necessary for users to embrace an enterprise mobile app. Security, as usual, is not high on the list of users’ concerns. It is left to IT to make sure that a BYOD policy can be implemented while in compliance with corporate security policy and governance.

And while user satisfaction and app adoption is important to the enterprise, there are security risks and challenges associated with BYOD that can’t be ignored. A few of those include:

• Loss or Stolen Device: The vast majority of data breaches are associated with lost or stolen devices. When an employee-owned device is lost or stolen, the corporate data it houses is only as secure as the apps the enterprise has delivered and the policies that can be enforced (such as remote wipe or authentication requirements).

• Loss of Control of Corporate Data: Without strong BYOD policies, it can be difficult, if not impossible to assess the risk of data breachs on employee-owned devices.

• Malware: When the user owns the device, there is the possibility of device tampering (jail-breaking or rooting devices), or the potential risk from custom device operating systems (seen primarily on Android devices). Employee-owned devices that do not adhere to corporate-approved operating system standards increase the risk of non-compliance with data privacy laws and regulatory requirements. The Mobile Security Landscape

How do you make sense of all the different tools and technologies to create a mobile security strategy that can keep up with the rapid pace of change in today’s enterprise? To date, the primary tool for mobile security has been mobile device management (MDM). MDM adds a layer of security and management over the entire device. MDM features including data encryption, VPN provisioning, remote locking/data wipe, enforcement of corporate password policies, and geotracking have enabled IT departments to bring the security and management of iOS and Android devices to rough parity with Blackberry devices and BES. However, in mimicking the BES model, MDM is solving a need that is quickly becoming obsolete. That is a need primarily related to corporate-owned mobile devices.

The MDM model becomes a liability in today’s BYOD enterprise. Devices that mix personal apps and data with corporate apps and data cannot be managed effectively in a device-centric MDM model. For example, when a mobile user leaves the company, a MDM solution wipes everything from the device including personal apps and data. But if you do not wipe the device, there is no guarantee that corporate data is not left on it. Generally speaking, users find MDM to be “heavy-handed” when applied to personally-owned devices. The solution to this problem is to secure the enterprise apps and data, instead of the device. Only then will IT have the ability to enforce security policies and users will get the mobile experience they expect.

Mobile app management (MAM)is a new solution being offered by many vendors and most MDM providers are adding MAM capabilities. MAM applies a security and management layer over work-related apps and data on a device while leaving personal apps and data alone. This also is often referred to “app wrapping” or “containerizing” enterprise mobile apps and data. MAM protects data by providing an encrypted tunnel for communication between the enterprise apps and backend servers as well as encryption of local data storage. MAM solutions may also include an enterprise app store and/or other app distribution and updating capabilities.

MAM solutions also feature some form of data leakage protection (DLP) on the device. This restricts operations such as copy/paste and open-in to prevent sensitive data from being compromised. In some cases, DLP works invisibly with no change to the user experience, while in other cases, there is a MAM client app that sets up an “enterprise workspace” that is visually separated from the home screen/launcher and that contains the icons for the MAM-protected enterprise apps. Data exchange is allowed between apps in the enterprise workspace and prevented between enterprise and personal apps. This alteration of the user experience is sometimes called “dual-persona.” In

2013, Samsung introduced a dual-persona capability, called Samsung KNOX, directly into the Android operating system for certain devices. Although Apple appears to be discouraging a dual-persona model, the introduction of iOS 7 adds some DLP functions that operate invisibly. It remains to be seen whether users ultimately embrace the dual-persona experience on their devices or prefer a single home screen for all their apps.

MAM is integrated with enterprise apps both at the app level and at the backend. On the backend, a gateway server is usually deployed in the enterprise DMZ to provide the encrypted tunnel. Connections are then made from the gateway to the enterprise data sources needed by the apps. The gateway server may also include other services such as authentication, management and basic analytics.

On the app side, there are two approaches to integrate custom apps with MAM. The first is to use an SDK provided by the MAM vendor to replace operating system network and data storage calls with equivalent calls to the MAM-protected versions. The drawback to this approach is that it only works for newly-built apps; any existing custom apps as well as third-party apps cannot be secured this way.

The second MAM integration approach is called “app-wrapping”. In this approach, an app binary is specially modified to inject the MAM versions of network and data storage calls directly into the machine code. This technique has the advantage of working on existing custom apps as well as new apps. Some MAM vendors support the SDK approach only, others support app wrapping only, and some support both approaches.

MDM and MAM exist because today’s mobile technology stack (apps, devices, networks, back-ends) is by nature insecure. These tools work by layering security around apps and data. But this layering stops at the boundaries of the app, both on the client and on the server. They cannot work “inside” the app. There is a long list of security requirements that can only be met in the design and coding of the app itself. Audit trails must be comprehensive and accessible. Service endpoints must be hardened against attack. Users must be positively authenticated to all protected corporate data sources, even when offline. And the list of requirements goes on. In other words, security must be built-in, not just layered-on. Verivo Akula offers the features enterprise app builders and operators need to build security right into their custom apps, whether they are native, hybrid or mobile web.

Nearly 80% of

companies that allow mobile devices on their networks experienced a mobile security incident withing the past year.

Dimensional Research, The Impact of Mobile Device Security on Information Security: A Survey of IT Professionals, June 2013

KEY SECURITY CHALLENGES FACING ENTERPRISE MOBILE

APP DEVELOPMENT

It may go without saying that security plays a critical role in the success of mobile within the enterprise. Apps must meet rigorous security standards. They must comply with existing corporate policies. They must also be implemented in an environment that is safe from hackers and malicious attacks. Each of these requirements represents a wide of challenges for companies to overcome.

The key security challenges for enterprise mobility include:

• Data must be protected, both at rest and in transit, despite differences in each mobile platform’s ability to encrypt data

• The infrastructure must be safe from attack

• Different types of users will need different levels of access and permissions in each app

• Apps may need to authenticate against multiple back-end systems, each with different types of credentials required

• Corporate security policies will need to be enforced, and those policies may change over time

• Audit trails are required to ensure compliance and accountability • Apps need to integrate with existing identity management and

mobile device management (MDM) systems

Apps that do not have the ability to enforce stringent security policies put organizations at risk on many levels.

The Right Mobile Platform Keeps your Enterprise Protected

Enterprise mobile development platforms enable critical security features to help companies build secure mobile apps. These platforms let you build mobile infrastructure with the ability to encrypt data at rest on-device and in transit. You can enforce user entitlements through single-sign-on and authorization roles. Transactional history can be audited through extensive logging and mobile app security policies can be managed centrally. In addition, the right platform should be hardened against common security threats including the OWASP Top 10 list and validated with standard security testing tools.

How do

you

Ensure

_{that your}

apps

and your

data

are

The most fundamental security principle is Access Control. A resource should only be accessible to people that are authorized to access it. In enterprise mobility, this means that any person that has not been explicitly granted access to specific corporate data within a mobile app should not have access to that data.

Access control can be broken down into two basic functions Authentication and Authorization. Before deciding if enterprise data should be shared, the entity requesting the data needs to be identified. Authentication provides an answer to the question “who is attempting to access this data”. After the “who” question is answered, then the second aspect of access control is to check authorization – in other words, “should the identified user be granted access to the data being requested.”

Enterprise mobile apps should be tied into the company’s existing identity directory so end-users can login and gain access using their existing usernames and passwords (or other credentials). This authentication process of identifying and verifying user identities requires an authoritative directory of user identity information to check against such as Microsoft Active Directory or Oracle’s Unified Directory.

Checking a given user’s credentials to verify their identity and grant access is a relatively easy process while their mobile device is attached to the network. However, a more difficult challenge to solve is authenticating users when a mobile app is used offline. For example, when a field service employee enters the basement of facility where there’s no network coverage, an enterprise mobile app must still be able to authenticate against the enterprise’s directory. This must be done without storing the user’s credentials on the device to eliminate the risk of user credentials being compromised if the device was stolen.

One solution to the offline challenge is to enable offline login. Instead of storing user credentials on a device, a one-way hashing algorithm could be used to encode the user’s password. Then, when a user attempts to login to the app while offline, their password would be hashed and compared against a previously stored one-way hash of their password. If the hashes match, then access is permitted.

While the idea of offline login prevents password extraction from a compromised device, an offline mobile device is still vulnerable to other potential attacks. For example, if a device is lost, an attacker could keep the device offline and attempt by brute force to guess the password. There are solutions that allow mobile apps to monitor such attempts and take appropriate action. For example preventing offline login and automatically wiping the app’s data from the device. These safeguards can be customized according to each company’s network security policies and modified as policies change.

Access Control

Authentication

After being authenticated, users must be authorized to gain access to app functions and data based on what rights they have been granted within the organization. These Role-Based Rights are often included in the same system as the user’s identity and managed via containers such as Active Directory’s groups and membership within specific groups. For example, an organization may create groups representing Employee Type: Contractor or Employee; Position: Manager or Executive; and Department: Sales or Operations.

Each of these different groups of people will need different rights within the organization’s mobile app. This can be facilitated through a permission system based on roles. An IT Operations Administrator needs to be able to create Roles for an app. Then assign the organization’s existing groups to the roles, and assign the permissions each role has in the app.

It is important to note that to work effectively, the app should not maintain a database of users and groups separate from the corporate directory. Mobile apps should retrieve this authorization information from the corporate directory and simply map roles (and thus permissions) to groups. This avoids duplicating information and eliminates the risk of conflicts and errors from un-synchronized changes.

The permissions granted to a user after login are available to be enforced on the client as well as the server. This allows app developers to customize the user interface and behavior of the app dynamically depending on the user’s roles. When apps are made dynamic in this way, users will never have the unpleasant experience of filling out a form or requesting data only to find after the fact that they are not authorized to perform that operation. This also relieves developers of the need to build and maintain multiple apps to serve users in different roles in the organization.

A Single Sign-On strategy is required to address the challenges of multiple, isolated IT systems that perform dedicated functions within enterprises. It’s common to see a CRM system that tracks customers, an ERP system that tracks inventory and a Human Resources system that tracks employees. Ideally all these systems would work together seamlessly. However, each system usually has its own identity provider that results in each user needing to maintain multiple accounts and passwords.

Multiple user accounts are a barrier to mobility on two fronts. The first challenge is mobilizing and integrating data from disparate systems in a mobile app. The second challenge is in providing a streamlined mobile user interface to access disparate systems. Mobile users will reject apps that force them to enter multiple usernames and passwords to be productive.

Look for solutions that can simplify and solve those challenges of disparate systems with unique authentication requirements. For example, a mobile app platform should maintain an encrypted credential store that can be populated by end users via the very apps it powers.

Authorization with Role-Based Access

This feature allows end users to inform the platform of separate credentials that should be used on their behalf to gain access to remote systems that require separate credentials. In this way, once a user authenticates into a mobile app using their primary network account, secure access to all other systems will be unlocked with their stored credentials. When any of the stored credentials change, the user will be prompted to provide updated credentials while logging into the app, and the new credentials will be stored for later use.

If an organization has already implemented Single-Sign-On (SSO), then a mobile app should be able to be configured to authenticate against the SSO system. The app should retrieve issued security authorization tokens and pass the authentication token to backend systems for which there is a trust relationship with the SSO system.

Once an end-user authenticates into an app, a user session must be created. After a period of inactivity, a user session can be closed requiring the end-user to authenticate again with their credentials. This protects data when a person that logs into a mobile app and their device is left unattended, misplaced or stolen. In some industries like healthcare, session management is an important feature to implement security policies for unattended devices. Beyond simple session management, there are mobile platforms that enable and enforce customizable, complex logout rules. These platforms give IT Administrators the abilities to forcibly log out individual users under certain conditions, force offline users to be logged out, and require a network connection to authenticate against the corporate server to regain access.

Session management should also be extended to offline operation. That would allow sessions to expire or time-out even when network connectivity is unavailable or server calls are not taking place. Client-only sessions could be created when users login into apps while offline.

Protecting sensitive corporate data is critical to the acceptance of any mobile solution. Data must be protected both while in transit (“in-flight”) across open networks and wherever it may be stored (“at-rest”). Each of these two states has distinct security concerns.

The key security risks for data at rest include:

• Extracting data off the mobile device through physical means. For example, mobile data might be synced or copied a connected computer. Mobile data could also be compromised by physically removing the device’s memory.

• Malicious programs on mobile devices. For example, a malicious app might attempt to read sales lead information from your company’s CRM mobile app.

Session Management

Data Protection

The key security risks for data in flight include:

• Intercepting data when it is transferred between client and server. For example, an eavesdropper might intercept communications between a mobile sales force app and the enterprise to capture inside information about the company’s customers, sales, and market performance.

When protecting data at rest, it is best to employ a multi-pronged approach of prevention and encryption.

Policies and infrastructure that prevent data access are the first step. By decreasing the amount of time data remains on a device, the likelihood of attackers gaining access to the data is also decreased. Data should be removed from mobile devices when it is no longer needed or when the state of the device becomes suspect. For example, if a device is lost, all the data should automatically be removed from the device.

The best solutions let you create configurable rules that control when data gets wiped from the local device. This lets the IT Ops Manager or Security Administrator create rule-based policies. For example, “If someone fails to login 10 times in a row while offline, then assume someone is trying to break into the app and wipe all local data.” And “If the device has been offline for 2 weeks then assume it has been lost and wipe all data.”

Encryption is important because if your data does fall into the wrong hands, then you need to be confident that the data is unusable. If the physical local storage of a mobile device is removed and the device’s data files are copied from the storage, then the last line of defense is for those data-files to be encrypted with strong encryption. Without the decryption keys, those data files are unreadable. To prevent breaches when data is physically extracted from a device, there

needs to be strong encryption of local data stores using the AES-256 encryption algorithm. Apps should be built using a combination of encrypted and un-encrypted data stores, to properly protect sensitive data but to maximize app performance when accessing non-sensitive data.

Data in-flight, during transfer between devices and servers over open networks, is vulnerable to interception. One solution is the creation of encrypted service endpoints using Transport Layer Security (TLS) and Secure Sockets Layer (SSL) between the backend and device. When configured with the proper set of SSL cipher suites and extended validation (EV) SSL certificates, enterprise-grade data protection is achieved.

Protection of Data at Rest

Verivo Software | 1000 Winter Street Waltham, MA 02451 | 781.795.8200 | www.verivo.com

Any security solution is only as strong as its weakest point. No matter how advanced the security solution, if the system hardware is physically accessible, it can be easily compromised. Many data breaches occur due to physical theft of servers and hard-drives. It is imperative that mobile app systems be physically secured.

After physical security, the next vulnerable areas to be considered are the operating system and any software infrastructure needed to run the system. These must be kept up to date and hardened against attacks.

Although the architecture of many enterprise apps resides on-premise and behind a firewall, it is still critical that the architecture be protected from malware and common types of attacks. It’s important to use a solution that can withstand top security threats including code and SQL injection, cross-site scripting, cross-site request forgery and others. That solution should also be regularly tested with standard security testing tools including IBM AppScan and OWASP Zed Attack Proxy (ZAP).

The ability to create and view extensive logging is important for prevention, diagnosis and remediation of mobile data breaches. All calls to server endpoints should be logged including data requests, authentication attempts and management interactions. This makes it possible to proactively detect and report on abnormal request patterns and other events of security interest, as well as providing a database for forensic activity.

Protection from Attack

Hardened Server

Logging

ABOUT VERIVO AKULA

Akula is a ground-breaking platform that lets you build, secure and control enterprise mobile apps. Akula is the first platform that delivers a robust set of enterprise mobility capabilities based on open, industry standards that work with your development environment and your mobile ecosystem. Designed to meet the needs of today’s enterprise, Akula lets you build enterprise mobile infrastructure that scales across all of your mobile apps and back-end systems – so you can build apps faster, control apps centrally, and respond to changing requirements faster.

Verivo Akula Keeps You Protected

Akula enables the enterprise-grade security features that companies need to build secure mobile apps. Akula makes it easy to encrypt data both at rest on-device and in transit in today’s enterprise with employee’s using personal on-devices to access enterprise data on open networks. Enforce user entitlements through single-sign-on and authorization roles even when apps operate offline. Audit transactional history through extensive logging, and enforce security policies centrally. Akula lets you build enterprise-grade security throughout your apps.

Akula

_{lets you}

build

security

right into

custom

apps

Verivo Software | 1000 Winter Street Waltham, MA 02451 | 781.795.8200 | [email protected]

AKULA FACILITATES THE CREATION OF SECURE APPS. HERE’S HOW.

Authentication Akula can integrate with a variety of identity management systems, including Active Directory, LDAP, Siteminder and others. The platform includes connectors (“realms”) for common systems out of the box, but companies can always create customized behavior with Akula’s Realm SDK. Akula’s authentication mechanism adds instant value to the developer by supporting a number of features via the Akula client SDK, including offline login, session timeouts and the enforcement of related policies. For example, using the Akula client SDK, a mobile developer can make a call to authenticate a user with a single line of code, and both the online and offline login scenarios will be handled automatically. Akula also supports authentication via SAML tokens, OAuth and other common protocols.

Session Management Akula handles session management for both online and offline scenarios and allows companies to configure timeouts and other related settings. The platform’s server-side persistent storage manager allows session data to persist across multiple requests and even across multiple servers, allowing for full session management even in

high-availability and load-balanced sever configurations

Credential Store Akula includes a server-side credential store that allows companies to store (and encrypt) user credentials for multiple back-end systems. Or, if a company has already invested in Siteminder, Tivoli Access Manager or another SSO tool, Akula can integrate with those via its built-in realm mechanism. Such credential storage mechanisms are critical for apps that must connect to multiple data sources, each authenticating with the end-users’ credentials.

AuthorizationAkula server endpoints can be configured to allow access only to certain roles. These roles are inherited directly from the system of record for identity management (e.g., Active Directory), so changes made on the back-end will trickle down to Akula in real-time. Also, user definitions only need to exist in the back-end system and do not need to be re-defined or managed separately on the Akula server.

Data ProtectionIt cannot be overstated that protection of data is critical to the success of any mobile solution. Akula’s client SDK provides data encryption mechanisms for locally-stored data on iOS and Android devices and ensures encryption keys are user-specific and secure. For data in transit, the Akula server supports SSL so that data connections between client and server can flow over HTTPS.

Protection from Attack Although the Akula server may often reside on-premise and behind a company’s firewall, it is critical that the server be protected from malware and common types of attacks. To that end, the Akula server has been built and tested to withstand top security threats including injection, cross-site scripting, cross-site request forgery and others. The security of the Akula server is regularly tested with standard security testing tools including IBM AppScan and OWASP Zed Attack Proxy (ZAP).

Logging Akula provides extensive logging for all calls to server endpoints including data requests, authentication attempts and management API requests. The logs are highly configurable and can be tailored to specific business and security needs. For example, logs can be

configured to write varying levels of detail out to a log file depending on which module is being requested or which user is requesting it. Or, a company may decide to direct output for a particular event to an Oracle database instead of a flat file in the file system. Akula’s logging mechanism is based on the SLF4J implementation of Apache log4j, so it is highly configurable and extensible. Companies may take advantage of this flexibility to report on specific abnormal pattern requests or keep an audit trail of specific management roles changes.

Access Control For an enterprise mobile app, it is critical to limit access to the app and its data to ensure only