Q. The Safest Mobile Device? A. Depends
Depends?!? Well, isn't that the answer to a lot of things in this world? Often our answer depends on the context of the question. Sometimes the answer depends on who you ask since it may only be an opinion or a feeling. Sometimes the answer is based on a survey, which is a moment in time, and might change a day later. I write a lot about secure mobile access, especially to the enterprise, so I'm obviously interested in any stories about the risks of mobile devices. There were a couple over the last few weeks that really caught my attention since they seemed to completely contradict each other. Earlier in the month, SC Magazine had a story titled, RSA 2013: iOS safer than Android due to open app model, patching delays which covered much of what many already feel - due to Apple's controlled ecosystem, the apps that are available are less of a risk to a user. They made note of the McAfee Threats Report which says Android malware almost doubled from the 2nd to 3rd quarter of 2012. Then just last week, also from SC Magazine, an article titled, Study finds iOS apps to be riskier than Android appeared. What? Wait, I thought they were safer. Well, no apparently. But before I go any further, I do need to mention that the author of both articles, Marcos Colon (@turbomarcos) does reference his first article and says, 'Security concerns surrounding the Android platform have always taken a back seat to that of iOS, but a new study challenges that notion,' so slack has been extended. :-) Anyway, according to an Appthorityreport, iOS apps pose a greater risk and has more privacy issues (to users) than Android. Appthority's 'App Reputation Report' looked at 50 of the top free apps available on both platforms and investigated how their functionality affects user privacy. They looked for “risky” app etiquette like sending data without encryption, sharing information with 3rd-parties, and gaining access to the users' calendars. (Chart) In this particular study, in almost all the cases, iOS gave access to the most info. Of the 50 apps, all of them (100%) sent unencrypted data via iOS but 'only' 92% sent clear text on Android. Tracking user location: 60% on iOS verses 42% on Android. Sharing user data with third-parties: 60% on iOS verses 50% on Android. When it comes to accessing the user's contacts, something we really do not like, 54% of iOS apps accessed the contact list compared to only 20% on Android. One of biggest differences, according to the article, is that at least on Andriod users are presented with a list of content the app wants to hook and the user can decide - on iOS, permissions can be changed once the app is installed. To claim one device is either 'safer,' or 'riskier' is somewhat a moot point these days. Any time you put your entire life on a device and then rely on that device to run your life, there is risk. Any time we freely offer up private information, there is a risk. Any time we rely on others to protect our privacy and provide security, there is a risk. Any time we allow apps access to personal information, there is risk. But like any potential vulnerability, individuals and organizations alike, need to understand the potential risk and determine if it something they can live with. Security is risk management. To top all this off and really what made me write this, was an @GuyKawasaki tweet titled Love Logo Swaps and among the many twists on brands, was this one: And it all made sense. ps Related: RSA 2013: iOS safer than Android due to open app model, patching delays Study finds iOS apps to be riskier than Android Smartphone hacking comes of age, hitting US victims 6 Steps To Address BYOD: A Security Management Roadmap 10 Awesome Logo Swaps Inside Look - F5 Mobile App Manager Is BYO Already D? Will BYOL Cripple BYOD? Freedom vs. Control BYOD–The Hottest Trend or Just the Hottest Term BYOD 2.0 – Moving Beyond MDM with F5 Mobile App Manager Technorati Tags: mobile device,smartphone,ios,android,privacy,safety,security,silva,byod,mam,f5,risk Connect with Peter: Connect with F5:BIG-IP Edge Client 2.0.2 for Android
Earlier this week F5 released our BIG-IP Edge Client for Android with support for the new Amazon Kindle Fire HD. You can grab it off Amazon instantly for your Android device. By supporting BIG-IP Edge Client on Kindle Fire products, F5 is helping businesses secure personal devices connecting to the corporate network, and helping end users be more productive so it’s perfect for BYOD deployments. The BIG-IP® Edge Client™ for all Android 4.x (Ice Cream Sandwich) or later devices secures and accelerates mobile device access to enterprise networks and applications using SSL VPN and optimization technologies. Access is provided as part of an enterprise deployment of F5 BIG-IP® Access Policy Manager™, Edge Gateway™, or FirePass™ SSL-VPN solutions. BIG-IP® Edge Client™ for all Android 4.x (Ice Cream Sandwich) Devices Features: Provides accelerated mobile access when used with F5 BIG-IP® Edge Gateway Automatically roams between networks to stay connected on the go Full Layer 3 network access to all your enterprise applications and files Supports multi-factor authentication with client certificate You can use a custom URL scheme to create Edge Client configurations, start and stop Edge Client BEFORE YOU DOWNLOAD OR USE THIS APPLICATION YOU MUST AGREE TO THE EULA HERE: http://www.f5.com/apps/android-help-portal/eula.html BEFORE YOU CONTACT F5 SUPPORT, PLEASE SEE: http://support.f5.com/kb/en-us/solutions/public/2000/600/sol2633.html If you have an iOS device, you can get the F5 BIG-IP Edge Client for Apple iOS which supports the iPhone, iPad and iPod Touch. We are also working on a Windows 8 client which will be ready for the Win8 general availability. ps Resources F5 BIG-IP Edge Client Samsung F5 BIG-IP Edge Client Rooted F5 BIG-IP Edge Client F5 BIG-IP Edge Portal for Apple iOS F5 BIG-IP Edge Client for Apple iOS F5 BIG-IP Edge apps for Android Securing iPhone and iPad Access to Corporate Web Applications – F5 Technical Brief Audio Tech Brief - Secure iPhone Access to Corporate Web Applications iDo Declare: iPhone with BIG-IP Technorati Tags: F5, infrastructure 2.0, integration, cloud connect, Pete Silva, security, business, education,technology, application delivery, ipad, cloud, context-aware,infrastructure 2.0, iPhone, web, internet, security,hardware, audio, whitepaper, apple, iTunesBYOD Policies – More than an IT Issue Part 5: Trust Model
#BYOD or Bring Your Own Device has moved from trend to an permanent fixture in today's corporate IT infrastructure. It is not strictly an IT issue however. Many groups within an organization need to be involved as they grapple with the risk of mixing personal devices with sensitive information. In my opinion, BYOD follows the classic Freedom vs. Control dilemma. The freedom for user to choose and use their desired device of choice verses an organization's responsibility to protect and control access to sensitive resources. While not having all the answers, this mini-series tries to ask many the questions that any organization needs to answer before embarking on a BYOD journey. Enterprises should plan for rather than inherit BYOD. BYOD policies must span the entire organization but serve two purposes - IT and the employees. The policy must serve IT to secure the corporate data and minimize the cost of implementation and enforcement. At the same time, the policy must serve the employees to preserve the native user experience, keep pace with innovation and respect the user's privacy. A sustainable policy should include a clear BOYD plan to employees including standards on the acceptable types and mobile operating systems along with a support policy showing the process of how the device is managed and operated. Some key policy issue areas include: Liability, Device Choice, Economics, User Experience & Privacy and a Trust Model. Today we look at Trust Model. Trust Model Organizations will either have a BYOD policy or forbid the use all together. Two things can happen if not: if personal devices are being blocked, organizations are losing productivity OR the personal devices are accessing the network (with or without an organization's consent) and nothing is being done pertaining to security or compliance. Ensure employees understand what can and cannot be accessed with personal devices along with understanding the risks (both users and IT) associated with such access. While having a written policy is great, it still must be enforced. Define what is ‘Acceptable use.’ According to a recent Ponemon Institute and Websense survey, while 45% do have a corporate use policy, less than half of those actually enforce it. And a recent SANS Mobility BYOD Security Survey, less than 20% are using end point security tools, and out of those, more are using agent-based tools rather than agent-less. According to the survey, 17% say they have stand-alone BYOD security and usage policies; 24% say they have BYOD policies added to their existing policies; 26% say they "sort of" have policies; 3% don't know; and 31% say they do not have any BYOD policies. Over 50% say employee education is one way they secure the devices, and 73% include user education with other security policies. Organizations should ensure procedures are in place (and understood) in cases of an employee leaving the company; what happens when a device is lost or stolen (ramifications of remote wiping a personal device); what types/strength of passwords are required; record retention and destruction; the allowed types of devices; what types of encryption is used. Organizations need to balance the acceptance of consumer-focused Smartphone/tablets with control of those devices to protect their networks. Organizations need to have a complete inventory of employee's personal devices - at least the one’s requesting access. Organizations need the ability to enforce mobile policies and secure the devices. Organizations need to balance the company's security with the employee's privacy like, off-hours browsing activity on a personal device. Whether an organization is prepared or not, BYOD is here. It can potentially be a significant cost savings and productivity boost for organizations but it is not without risk. To reduce the business risk, enterprises need to have a solid BYOD policy that encompasses the entire organization. And it must be enforced. Companies need to understand: • The trust level of a mobile device is dynamic • Identify and assess the risk of personal devices • Assess the value of apps and data • Define remediation options • Notifications • Access control • Quarantine • Selective wipe • Set a tiered policy Part of me feels we’ve been through all this before with personal computer access to the corporate network during the early days of SSL-VPN, and many of the same concepts/controls/methods are still in place today supporting all types of personal devices. Obviously, there are a bunch new risks, threats and challenges with mobile devices but some of the same concepts apply – enforce policy and manage/mitigate risk As organizations move to the BYOD, F5 has the Unified Secure Access Solutions to help. ps Related BYOD Policies – More than an IT Issue Part 1: Liability BYOD Policies – More than an IT Issue Part 2: Device Choice BYOD Policies – More than an IT Issue Part 3: Economics BYOD Policies – More than an IT Issue Part 4: User Experience and Privacy BYOD–The Hottest Trend or Just the Hottest Term FBI warns users of mobile malware Will BYOL Cripple BYOD? Freedom vs. Control What’s in Your Smartphone? Worldwide smartphone user base hits 1 billion SmartTV, Smartphones and Fill-in-the-Blank Employees Evolving (or not) with Our Devices The New Wallet: Is it Dumb to Carry a Smartphone? Bait Phone BIG-IP Edge Client 2.0.2 for Android BIG-IP Edge Client v1.0.4 for iOS New Security Threat at Work: Bring-Your-Own-Network Legal and Technical BYOD Pitfalls Highlighted at RSA
Android Encrypted Databases
The Android development community, as might be expected, is a pretty vibrant community with a lot of great contributors helping people out. Since Android is largely based upon Java, there is a lot of skills reusability between the Java client dev community and the Android Dev community. As I mentioned before, encryption as a security topic is perhaps the weakest link in that community at this time. Perhaps, but since that phone/tablet could end up in someone else’s hands much more easily than your desktop or even laptop, it is something that needs a lot more attention from business developers. When I set out to write my first complex app for Android, I determined to report back to you from time-to-time about what needed better explanation or intuitive solutions. Much has been done in the realm of “making it easier”, except for security topics, which still rank pretty low on the priority list. So using encrypted SQLite databases is the topic of this post. If you think it’s taking an inordinate amount of time for me to complete this app, consider that I’m doing it outside of work. This blog was written during work hours, but all of the rest of the work is squeezed into two hours a night on the nights I’m able to dedicate time. Which is far from every night. For those of you who are not developers, here’s the synopsis so you don’t have to paw through code with us: It’s not well documented, but it’s possible, with some caveats. I wouldn’t use this method for large databases that need indexes over them, but for securing critical data it works just fine. At the end I propose a far better solution that is outside the purview of app developers and would pretty much have to be implemented by the SQLite team. Okay, only developers left? Good. In my research, there were very few useful suggestions for designing secure databases. They fall into three categories: 1. Use the NDK to write a variant of SQLite that encrypts at the file level. For most Android developers this isn’t an option, and I’m guessing the SQLite team wouldn’t be thrilled about you mucking about with their database – it serves a lot more apps than yours. 2. Encrypt the entire SD card through the OS and then store the DB there. This one works, but slows the function of the entire tablet/phone down because you’ve now (again) mucked with resources used by other apps. I will caveat that if you can get your users to do this, it is the currently available solution that allows indices over encrypted data. 3. Use one of several early-beta DB encryption tools. I was uncomfortable doing this with production systems. You may feel differently, particularly after some of them have matured. I didn’t like any of these options, so I did what we’ve had to do in the past when a piece of data was so dangerous in the wrong hands it needed encrypting. I wrote an interface to the DB that encrypts and decrypts as data is inserted and removed. In Android the only oddity you won’t find in other Java environments – or you can more easily get around in other Java environments – is filling list boxes from the database. For that I had to write a custom provider that took care of on-the-fly decryption and insertion to the list. My solution follows. There are a large varieties of ways that you could solve this problem in Java, this one is where I went because I don’t have a lot of rows for any given table. The data does not need to be indexed. If either of these items is untrue for your implementation, you’ll either have to modify this implementation or find an alternate solution. So first the encryption handler. Note that in this sample, I chose to encode encrypted arrays of bytes as Strings. I do not guarantee this will work for your scenario, and suggest you keep them as arrays of bytes until after decryption. Also note that this sample was built from a working one by obfuscating what the actual source did and making some modifications for simplification of example. It was not tested after the final round of simplification, but should be correct throughout. package com.company.monitor; import javax.crypto.Cipher; import javax.crypto.spec.SecretKeySpec; import android.util.Base64; public class DBEncryptor { private static byte[] key; private static String cypherType = cypherType; public DBEncryptor(String localPass) { // save the encoded key for future use // - note that this keeps it in memory, and is not strictly safe key = encode(localPass.getBytes()).getBytes(); String keyCopy = new String(key); while(keyCopy.length() < 16) keyCopy = keyCopy + keyCopy; byte keyA[] = keyCopy.getBytes(); if(keyA.length > 16) key = System.arraycopy(keyA, 0, key, 0, 16); } public String encode(byte [] s) { return Base64.encodeToString(s, Base64.URL_SAFE); } public byte[] decode(byte[] s) { return Base64.decode(s, Base64.URL_SAFE); } public byte[] getKey() { // return a copy of the key. return key.clone(); } public String encrypt(String toEncrypt) throws Exception { //Create your Secret Key Spec, which defines the key transformations SecretKeySpec skeySpec = new SecretKeySpec(key, cypherType); //Get the cipher Cipher cipher = Cipher.getInstance(cypherType); //Initialize the cipher cipher.init(Cipher.ENCRYPT_MODE, skeySpec); //Encrypt the string into bytes byte[ ] encryptedBytes = cipher.doFinal(toEncrypt.getBytes()); //Convert the encrypted bytes back into a string String encrypted = encode(encryptedBytes); return encrypted; } public String decrypt(String encryptedText) throws Exception { // Get the secret key spec SecretKeySpec skeySpec = new SecretKeySpec(key, cypherType); // create an AES Cipher Cipher cipher = Cipher.getInstance(cypherType); // Initialize it for decryption cipher.init(Cipher.DECRYPT_MODE, skeySpec); // Get the decoded bytes byte[] toDecrypt = decode(encryptedText.getBytes()); // And finally, do the decryption. byte[] clearText = cipher.doFinal(toDecrypt); return new String(clearText); } } So what we are essentially doing is base-64 encoding the string to be encrypted, and then encrypting the base-64 value using standard Java crypto classes. We simply reverse the process to decrypt a string. Note that this class is also useful if you’re storing values in the Properties file and wish them to be encrypted, since it simply operates on strings. The value you pass in to create the key needs to be something that is unique to the user or tablet. When it comes down to it, this is your password, and should be treated as such (hence why I changed the parameter name to localPass). For seasoned Java developers, there’s nothing new on Android at this juncture. We’re just encrypting and decrypting data. Next it does leave the realm of other Java platforms because the database is utilizing SQLite, which is not generally what you’re writing Java to outside of Android. Bear with me while we go over this class. The SQLite database class follows. Of course this would need heavy modification to work with your database, but the skeleton is here. Note that not all fields have to be encrypted. You can mix and match, no problems at all. That is one of the things I like about this solution, if I need an index for any reason, I can create an unencrypted field of a type other than blob and index on it. package com.company.monitor; import android.content.ContentValues; import android.content.Context; import android.database.Cursor; import android.database.sqlite.SQLiteDatabase; import android.database.sqlite.SQLiteDatabase.CursorFactory; import android.database.sqlite.SQLiteOpenHelper; public class DBManagernames extends SQLiteOpenHelper { public static final String TABLE_NAME = "Map"; public static final String COLUMN_ID = "_id"; public static final String COLUMN_LOCAL = "Local"; public static final String COLUMN_WORLD = "World"; private static int indexId = 0; private static int indexLocal = 1; private static int indexWorld = 2; private static final String DATABASE_NAME = "Mappings.db"; private static final int DATABASE_VERSION = 1; // SQL statement to create the DB private static final String DATABASE_CREATE = "create table " + TABLE_NAME + "(" + COLUMN_ID + " integer primary key autoincrement, " + COLUMN_LOCAL + " BLOB not null, " + COLUMN_WORLD +" BLOB not null);"; public DBManagernames(Context context, CursorFactory factory) { super(context, DATABASE_NAME, factory, DATABASE_VERSION); } @Override public void onCreate(SQLiteDatabase db) { db.execSQL(DATABASE_CREATE); } @Override public void onUpgrade(SQLiteDatabase db, int oldVersion, int newVersion) { // TODO Auto-generated method stub // Yeah, this isn't implemented in production yet either. It's low on the list, but definitely "on the list" } // Assumes DBEncryptor was used to convert the fields of name before calling insert public void insertToDB(DBNameMap name) { ContentValues cv = new ContentValues(); cv.put(COLUMN_LOCAL, name.getName().getBytes()); cv.put(COLUMN_WORLD, name.getOtherName().getBytes()); getWritableDatabase().insert(TABLE_NAME, null, cv); } // returns the encrypted values to be manipulated with the decryptor. public DBNameMap readFromDB(Integer index) { SQLiteDatabase db = getReadableDatabase(); DBNameMap hnm = new DBNameMap(); Cursor cur = null; try { cur = db.query(TABLE_NAME, null, "_id='"+index.toString() +"'", null, null, null, COLUMN_ID); // cursors connsistently return before the first element. Move to the first. cur.moveToFirst(); byte[] name = cur.getBlob(indexLocal); byte [] othername = cur.getBlob(indexWorld); hnm = new DBNameMap(new String(name), new String(othername), false); } catch(Exception e) { System.out.println(e.toString()); // Do nothing - we want to return the empty host name map. } return hnm; } // NOTE: This routine assumes "String name" is the encrypted version of the string. public DBNameMap getFromDBByName(String name) { SQLiteDatabase db = getReadableDatabase(); Cursor cur = null; String check = null; try { // Note - the production version of this routine actually uses the "where" field to get the correct // element instead of looping the table. This is here for your debugging use. cur = db.query(TABLE_NAME, null, null, null, null, null, null); for(cur.moveToFirst();(!cur.isLast());cur.moveToNext()) { check = new String(cur.getBlob(indexLocal)); if(check.equals(name)) return new DBNameMap(check, new String(cur.getBlob(indexWorld)), false); } if(cur.isLast()) return new DBNameMap(); return new DBNameMap(cur.getString(indexLocal), cur.getString(indexWorld), false); } catch(Exception e) { System.out.println(e.toString()); return new DBNameMap(); } } // used by our list adapter - coming next in the blog. public Cursor getCursor() { try { return getReadableDatabase().query(TABLE_NAME, null, null, null, null, null, null); } catch(Exception e) { System.out.println(e.toString()); return null; } } // This is used in our list adapter for mapping to fields. public String[] listColumns() { return new String[] {COLUMN_LOCAL}; } } I am not including the DBNameMap class, as it is a simple container that has two string fields and maps one name to another. Finally, we have the List Provider. Android requires that you populate lists with a provider, and has several base ones to work with. The problem with the SimpleCursorAdapter is that it assumes an unencrypted database, and we just invested a ton of time making the DB encrypted. There are several possible solutions to this problem, and I present the one I chose here. I extended ResourceCursorAdapter and implemented decryption right in the routines, leaving not much to do in the list population section of my activity but to assign the correct adapter. package com.company.monitor; import android.content.Context; import android.database.Cursor; import android.view.LayoutInflater; import android.view.View; import android.view.ViewGroup; import android.widget.ResourceCursorAdapter; import android.widget.TextView; public class EncryptedNameAdapter extends ResourceCursorAdapter { private String pw; public EncryptedHostNameAdapter(Context context, int layout, Cursor c, boolean autoRequery) { super(context, layout, c, autoRequery); } public EncryptedHostNameAdapter(Context context, int layout, Cursor c, int flags) { super(context, layout, c, flags); } // This class must know what the encryption key is for the DB before filling the list, // so this call must be made before the list is populated. The first call after the constructor works. public void setPW(String pww) { pw = pww; } @Override public View newView(Context context, Cursor cur, ViewGroup parent) { LayoutInflater li = (LayoutInflater) context.getSystemService(Context.LAYOUT_INFLATER_SERVICE); return li.inflate(R.layout.my_list_entry, parent, false); } @Override public void bindView(View arg0, Context arg1, Cursor arg2) { // Get an encryptor/decryptor for our data. DBEncryptor enc = new DBEncryptor(pw); // Get the TextView we're placing the data into. TextView tvLocal = (TextView)arg0.findViewById(R.id.list_entry_name); // Get the bytes from the cursor byte[] bLocal = arg2.getBlob(arg2.getColumnIndex(DBManagerNames.COLUMN_LOCAL )); // Convert bytes to a string String local = new String(bSite); try { // decrypt the string local = enc.decrypt(local); } catch(Exception e) { System.out.println(e.toString()); // local holds the encrypted version at this point, fix it. // We’ll return an empty string for simplicity local = new String(); } tvSite.setText(local); } } The EncryptedNameAdapter can be set as the source for any listbox just like most examples set an ArrayAdapter as the source. Of course, it helps if you’ve put some data in the database first . That’s it for this time. There’s a lot more going on with this project, and I’ll present my solution for SSL certificate verification some time in the next couple of weeks, but for now if you need to encrypt some fields of a database, this is one way to get it done. Ping me on any of the social media outlets or here in the comments if you know of a more elegant/less resource intensive solution, always up for learning more. And please, if you find an error, it was likely introduced in the transition to something I was willing to throw out here publicly, but let me know so others don’t have problems. I’ve done my best not to introduce any, but always get a bit paranoid if I changed it after my last debug session – and I did to simplify and sanitize.BYOD Policies – More than an IT Issue Part 3: Economics
#BYOD or Bring Your Own Device has moved from trend to an permanent fixture in today's corporate IT infrastructure. It is not strictly an IT issue however. Many groups within an organization need to be involved as they grapple with the risk of mixing personal devices with sensitive information. In my opinion, BYOD follows the classic Freedom vs. Control dilemma. The freedom for user to choose and use their desired device of choice verses an organization's responsibility to protect and control access to sensitive resources. While not having all the answers, this mini-series tries to ask many the questions that any organization needs to answer before embarking on a BYOD journey. Enterprises should plan for rather than inherit BYOD. BYOD policies must span the entire organization but serve two purposes - IT and the employees. The policy must serve IT to secure the corporate data and minimize the cost of implementation and enforcement. At the same time, the policy must serve the employees to preserve the native user experience, keep pace with innovation and respect the user's privacy. A sustainable policy should include a clear BOYD plan to employees including standards on the acceptable types and mobile operating systems along with a support policy showing the process of how the device is managed and operated. Some key policy issue areas include: Liability, Device Choice, Economics, User Experience & Privacy and a trust Model. Today we look at Economics. Many organizations look at BYOD as an opportunity to reduce some costs. Clearly, not having an equipment cost - $200-$600 per-device - can add up depending on the company's size. It might also make financial sense for a smaller company with few employees. Since the phone is owned by the employee, then they are probably responsible for the bill every month. Depending on their personal contract/plan, excessive charges could arise due to the extra minutes used for work related calls. Often, monthly charges are fairly consistent with established plans, and while there are times when the bill is higher due to an incidental charge to some other overage, many people fail to review their phone bill when it arrives. BYOD could force employees into a higher monthly service plan but it also gives users visibility into their usage, if for instance, the corporate BYOD policy allows for reimbursement. This can drive personal responsibility for how they use their minutes. While BYOD could reduce the overall expenditure for IT issued devices and many organizations report employees are happier and more productive when they are using the device of their desire (an enablement tool), there might be other areas that costs could increase. While the employee does spend their own money on the device, there are certainly enterprise costs to managing and securing that device. There could also be a snag however when it comes to licensing. Does BYOD also require Bring Your Own License? In many instances, this is an area that IT needs to keep an eye on and often the answer is yes. Some of the most common enterprise software licensing agreements require licensing any device used "for the benefit of the company" under the terms of the enterprise agreement. That often means that all those BYO devices might require a license to access common corporate applications. This also means that even if the user already has a particular license, which they purchased on their own or it came with the device, the organization might still need to license that device under their enterprise software agreement. This could diminish any cost savings from the BYOD initiative. There are solutions to such as using alternative products that are not restricted by licensing but, those may not have the key features required by the workforce. IT needs to understand if their license agreements are per-user or per-device and what impact that may have on a BYOD policy. A few questions that the Finance department should determine is: Should the company offer users a monthly stipend? How is productivity measured? Will the management and security cost more than IT (volume) procurement? What are the help desk expenses and policy about support calls. There certainly needs to be discussion around mobile app purchase and deployment for work use. Are there any compliance, additional audit costs or tax implications with a BYOD initiative? As part of the BYOD Policy the Economics Checklist, while not inclusive, should: · Investigate the effects of a BYOD reimbursement plan on your ability to negotiate with wireless carriers · Consider putting logging and reporting in place to monitor after-hours use · Incorporate a “help desk as a last resort” guideline into your employee BYOD social contract · Estimate costs for any increased need for compliance monitoring · Ask Finance about tax implications (cost or benefit) of a BYOD policy ps Related BYOD Policies – More than an IT Issue Part 1: Liability BYOD Policies – More than an IT Issue Part 2: Device Choice BYOD–The Hottest Trend or Just the Hottest Term FBI warns users of mobile malware Will BYOL Cripple BYOD? Freedom vs. Control What’s in Your Smartphone? Worldwide smartphone user base hits 1 billion SmartTV, Smartphones and Fill-in-the-Blank Employees Evolving (or not) with Our Devices The New Wallet: Is it Dumb to Carry a Smartphone? Bait Phone BIG-IP Edge Client 2.0.2 for Android BIG-IP Edge Client v1.0.4 for iOS New Security Threat at Work: Bring-Your-Own-Network Legal and Technical BYOD Pitfalls Highlighted at RSABYOD Policies – More than an IT Issue Part 2: Device Choice
#BYOD or Bring Your Own Device has moved from trend to an permanent fixture in today's corporate IT infrastructure. It is not strictly an IT issue however. Many groups within an organization need to be involved as they grapple with the risk of mixing personal devices with sensitive information. In my opinion, BYOD follows the classic Freedom vs. Control dilemma. The freedom for user to choose and use their desired device of choice verses an organization's responsibility to protect and control access to sensitive resources. While not having all the answers, this mini-series tries to ask many the questions that any organization needs to answer before embarking on a BYOD journey. Enterprises should plan for rather than inherit BYOD. BYOD policies must span the entire organization but serve two purposes - IT and the employees. The policy must serve IT to secure the corporate data and minimize the cost of implementation and enforcement. At the same time, the policy must serve the employees to preserve the native user experience, keep pace with innovation and respect the user's privacy. A sustainable policy should include a clear BOYD plan to employees including standards on the acceptable types and mobile operating systems along with a support policy showing the process of how the device is managed and operated. Some key policy issue areas include: Liability, Device choice, Economics, User Experience & Privacy and a trust Model. Today we look at Device Choice. Device Choice People have become very attached to their mobile devices. They customize and personalize and it's always with them, to the point of even falling asleep with the device. So ultimately, personal preference or the 'consumerization of IT' notion is one of the primary drivers for BYOD. Organizations need to understand, what devices employees prefer and what devices do employees already own. That would could dictate what types of devices might request access. Once organizations get a grasp on potential devices, they then need to understand each device's security posture. About 10 years ago, RIM was the first technology that really brought the Smartphone into the workplace. It was designed to address the enterprise's needs and for years was the Gold Standard for Enterprise Mobility. Management control was integrated with the device; client certificate authentication was supported; Active Directory/LDAP servers were not exposed to the external internet; the provisioning was simple and secure; organizations could manage both Internet access and intranet access, and IT had end point control. When Apple's iPhone first hit the market, it was purely a consumer device for personal use and was not business centric, like the BlackBerry. Initially, the iPhone did not have many of the features necessary to be part of the corporate environment. It was not a business capable device. It did not support applications like Exchange, which is deployed in many organizations and is critical to a user's day-to-day activities. Over time, the iPhone has become a truly business capable device with additional mechanisms to protect end users. Android, very popular with consumers, also offers numerous business apps but is susceptible to malware. Device selection is also critical to the end user experience. Surveys show that workers are actually more productive when they can use their personal smartphone for work. Productivity increases since we prefer to use our own device. In addition, since many people like to have their device with them all the time, many will answer emails or do work during non-work hours. A recent survey indicated that 80% of Americans work an extra 30 hours a month on their own time with BYOD. But we are much happier. A few blogs ago, I wrote about Good Technology’s BYOD survey, found that organizations are jumping on the phenomenon since they see real ROI from encouraging BYOD. The ability to keep employees connected (to information) day and night can ultimately lead to increased productivity and better customer service. They also found that two of the most highly regulated industries - financial services and health care - are most likely to support BYOD. This shows that the security issues IT folks often raise as objections are manageable and there's major value in supporting BYOD. Another ROI discovered through the survey is that since employees are using their own devices, half of Good’s customers don't pay anything for the employees' BYOD devices – essentially, according to Good, getting employees to pay for the productivity boost at work. As part of the BYOD Policy the Device Choice Checklist, while not inclusive, should: · Survey employees about their preferences and current devices · Define a baseline of acceptable security and supportability features · Do homework: Read up on hardware, OS, and regional variances · Develop a certification program for future devices · Work with Human Resources on clear communication to employees about which devices are allowed–or not–and why ps Related BYOD Policies – More than an IT Issue Part 1: Liability BYOD–The Hottest Trend or Just the Hottest Term FBI warns users of mobile malware Will BYOL Cripple BYOD? Freedom vs. Control What’s in Your Smartphone? SmartTV, Smartphones and Fill-in-the-Blank Employees Evolving (or not) with Our Devices The New Wallet: Is it Dumb to Carry a Smartphone? Bait Phone BIG-IP Edge Client 2.0.2 for Android BIG-IP Edge Client v1.0.4 for iOS New Security Threat at Work: Bring-Your-Own-Network Legal and Technical BYOD Pitfalls Highlighted at RSAAndroid and SSL. What Doesn't Work.
Not so long ago I wrote a blog entry about SSL on Android in regards to some certificates, and mentioned that I would be following up as the work progressed. I have worked through the options and implemented a working solution that I’ll eventually blog about, but this entry is to discuss what doesn’t work, or is a sub-standard solution, what I settled on, and why. It’s light on implementation details, but does offer enough information that interested developers can research a similar solution. The options I discovered or considered are: Forcing the user to import the requisite certs Ignoring all SSL errors Allowing over-ride of errors globally to the app Using the browser to implement exceptions to SSL security Forcing the user to accept problems every time they use the app Creating a system to securely store exception information and use it every time the app loads Many developers adopt the first solution because they have static sites the app is accessing, and can simply say “do this once and you don’t have to worry about it again” (until the cert expires). In the case of the app I’m developing, it is designed for use with scenarios where the certs are often self-signed, and in a testing environment, often transient. So this option was not one I wished to pursue. In the previous blog I mentioned ignoring all SSL errors, and that is a dangerous route I would not ask users to bear. Ignoring errors without asking the user opens users up to Man in the Middle (MitM) attacks. So this one was ruled out from day one – though it appears many developers are going this route. I did briefly consider in the application options giving the user a check-box to silently over-ride SSL errors. Since this is within the control of the user, it was a better solution, but as most of us know, options like this are set once and not looked at again unless there is a problem. And in the case of SSL MitM attacks, it’s too late when you notice a problem. So I ruled this option out also. In that previous blog, I had alluded to what I hoped might be a simple solution to the problem. It was my hope at the time that one could simply call the browser using the Android Dev system of “intents” and ask it to open the page, thus using the browsers’ good certificate error handling to create the exception. Except the default browser on most Android devices does not store exceptions – so there was no way to utilize that information from a remote application. Thus, I dropped this line of enquiry also. It is a relatively easy endeavor to make two dialogs and write a little bit of code to ask the user each time you go out to the web application if they accept the issues with the certificate. One dialog would handle “host name mismatch” exceptions, the other would handle “Certificate Not Trusted” errors – both of which can easily occur in the environment the app will target. I did consider going this route, but the application makes many SOAP calls to the same server over the course of its lifetime, so this would become annoying for users. The only thing worse than having no application is having one that no one wants to use because it’s too painful. So this option was dropped also. This leaves the last option. It is the most involved, requiring both of the dialogs mentioned above, and more code to handle the exceptions. It also requires the exception information be saved… Which then requires that this saved information be encrypted, since it will reside long-term on the device. The solution has the following elements, just for those who are looking into this type of thing: Application level username and password. Java salted encryption of application password. Dialogs to ask user to approve exceptions. An SQLite database of exception information. Java encryption of all information stored in the database. This leaves only one issue – how to “untrust” a site. Since this is not a common problem, I will likely put out version 1.0 with only the option to delete the application user, which in turn will delete all exception information. This may sound extreme, but it is a rare scenario, and I have to leave something for version 2.0. Out now, improved later, in the vein of all current development methodologies. In version 2.0 I’ll allow deletion of individual exception information. But you never know, I may decide to side-track and implement this functionality in version 1.0, depending upon the other portions of the development effort. The information stored in the database is in the form FQDN, username, password. From which the app can then rebuild the SOAP URI. While it wasn’t strictly necessary to encrypt the FQDN, as long as the encryption code was there, why leak information about the network? It added weeks to my development effort to get this up, running, and thoroughly tested, but it was worth it. When a company throws up a test environment and uses a self-signed cert simply because it is easier, the application needs to support that test environment with a minimum of pain. This is a relatively common occurrence in the space the app is in, so it was worth the effort. Your mileage may vary. Now, back to actually communicating with the server and giving users the information/control they want .Hype Cycles, VDI, and BYOD
Survive the hype. Get real benefits. #F5 #BYOD #VDI An interesting thing is occurring in the spaces of Virtual Desktop Infrastructure (VDI) and Bring Your Own Device (BYOD) that is subtle, and while not generally part of the technology hype cycle, seems to be an adjunct of it in these two very specific cases. In espionage, when launching a misinformation campaign, several different avenues are approached for maximum impact, and to increase believability. While I don’t think this over-hype cycle is anything like an espionage campaign, the similarities that do exist are intriguing. The standard hype cycle tells you how a product category will change the world, we’ve seen it over and over in different forms. Get X or get behind your competitors, Product Y will solve all your business problems and cook you toast in the morning. More revolutionary than water, product Z is the next big thing. Product A will eliminate the need for (insert critical IT function here)… The hype cycle goes on, and eventually wears out as people find actual uses for the product category, and the limitations. At that point, the product type settles into the enterprise, or into obscurity. This is all happening with both VDI and BYOD. VDI will reduce your expenses while making employees happier and licensing easier… Well, that was the hype. We’ve discovered as an industry that neither of these hype points was true, and realized that the anecdotal evidence was there from the early days. That means it is useful for reducing hardware expenses, but even that claim is being called into question by those who have implemented and paid for servers and some form of client. There are very valid reasons for VDI, but it is still early yet from a mass-adoption standpoint, and enterprises seem to acknowledge it needs some time. Still, the hype engine declares each new year “The Year of VDI”. Server virtualization shows that there won’t be a year of VDI when its time comes, but rather a string of very successful years that slowly add up. Meanwhile, BYOD is everything for everyone. Employees get the convenience of using the device of their choice, employers get to reduce expenses on mobile devices, the sun comes out, birds sing beautiful madrigals… Except that like every hype cycle ever, that’s nowhere near the reality. Try this one on for size to see what I’m talking about: If you’re not familiar with my example corporation ZapNGo, see my Load Balancing For Developers series of blogs Because that is never going to happen. Which means it is not “bring your own device”, it is “let us buy the device you like” which will also not last forever unless there is management convergence. In the desktop space, organizations standardized on Windows because it allowed them to care for their gear without having to have intimate knowledge of three (or ten) different operating systems. There is no evidence that corporations are going to willy-nilly support different device OS’s and the associated different apps that go along with using multiple device OS’s. In many industries, the need to control the device at a greater level than most users want their personal devices messed with (health care and financial services spring to mind) will drive a dedicated device for work, like it or not. So why is there so much howling about “the democratization of IT”? Simple, the people howling for BYOD belong to two groups. C-Level execs that need access 24x7 if an emergency occurs, and people like me – techno geeks that want to pop onto work systems from their home tablet. The other 90% of the working population? They do not want work stuff on their personal tablet or phone. They just don’t. They’ll take a free tablet from their employer and even occasionally use it for work, but even that is asking much of a large percentage of workers. Am I saying BYOD is bogus? No. But bear with me while I circle back to VDI for a moment… In the VDI space, there was originally a subtle pressure to do massive implementations. We’ve had decades of experience as an industry at this point, and we know better than to do massive rip-n-replace projects unless we have to. They just never go as planned, they’re too big. So most organizations have the standard pilot/limited implementation/growing implementation cycle. And that makes sense, even if it doesn’t make VDI vendors too happy. In the interim, if you discover something that makes a given VDI implementation unsuitable for your needs, you still have time to replace it with a parallel project. The most cutting-edge (to put it nicely) claims are that your employees – all of them! – want access to their desktops on their BYOD device. Let me see, how do you spell that… S L O W. That’s it. Most of your employees don’t want work desktops at work, let alone on their tablet at the beach. It’s just us geeks and the overachievers that even think it’s a good idea, and performance will quickly disillusion even the most starry eyed of those of us who do. So let’s talk realities. What will we end up with after the hype is done and how can you best proceed? Well, here are some steps you can take. Some of these are repeated from my VDI blog post of a few months ago, but repetition is not a terrible thing, as long as it’s solid advice. Pick targeted deployments of both. Determine who most wants/needs BYOD and see if those groups can agree on a platform. Determine what segments of your employee population are best suited to VDI. Low CPU usage or high volume of software installs are good places to start. Make certain your infrastructure can take the load and new types of traffic. If not, check the options F5 has to accelerate and optimize your network for both products. Move slowly. The largest VDI vendors are certainly not going anywhere, and at a minimum, neither are Android and iOS. So take your time and do it right. SELL your chosen solutions. IT doesn’t generally do very well on the selling front, but if you replace a local OS with a remote one, every performance issue will be your fault unless you point out that no matter where they are geographically, their desktop stays the same, it is easier to replace client hardware when you don’t have to redo the entire desktop, etc. Gauge progress. Many VDI deployments fell on hard times because they were too ambitious, or because they weren’t ambitious enough and didn’t generate benefits, or because they weren’t properly sold to constituents. BYOD will face similar issues. Get a solid project manager and have them track progress not in terms of devices or virtual desktops, but in terms of user satisfaction and issues that could blow up as the project grows. That’s it for now. As always, remember that you’re doing what’s best for your organization, do not concern yourself with hype, market, or vendor health, those will take care of themselves. Related Articles and Blogs: Four Best Practices for Reducing Risk in the Cloud Dreaming of Work Speed Matters, but Dev Speed or App Speed? Infographic: Protect Yourself Against Cybercrime Multiscreen Multitasking Upcoming Event: F5 Agility Summit 2012 Enterprise Still Likes Apple over AndroidMultiscreen Multitasking
Talk about killing two birds with one stone - according to a Pew Internet & American Life Project report, more Americans on their phones while watching TV. About half of U.S. mobile phone owners use their devices while watching TV, a new study suggests. While most (38%) are clicking away as a commercial filler, many are enhancing their viewing experience by interacting along with the program. About 23% of cellphone users exchange text messages with their friends about the same show they are simultaneously watching on TV; around 20% of them visit websites mentioned on TV; 22% used their phone to check whether something they heard on television was true; 11% of cellphone owners use their devices to read what others are writing online about a particular television program; another 11% posts comments on online boards using their cellphones; and 6% used their phone to vote for a reality show contestant. Both men and women equally are glued to their smartphone while watching TV with the 18-24 age bracket leading the way (81%), followed by the 25-34 group (72%). The massive growth of smartphones and how we use them is infiltrating every aspect of our lives. The most basic task of making a phone call seems miniscule compared to the many other things we do with smartphones. Our personal devices are also becoming the primary mobile device we use for work with all the BYOD initiates being implemented. It’s also clear that with all the other tasks and activities we use our smartphones for, providing a solid BYOD policy within an organization is important to keeping corporate resources safe. Not sure how I turned the results of a TV survey into a BYOD challenge but there you have it. And somehow the famous words of Homer Simpson now have much more meaning, ‘Then we figured out we could park them in front of the TV. That's how I was raised, and I turned out TV.’ ps References: More Americans on their phones while watching TV Cellphone usage, television watching go hand in hand The Rise of the “Connected Viewer” More Americans Are Using Mobile Phones While Watching TV Americans juggle phones, TV at same time: survey Man Watches 252 Netflix Movies in a Month, Gets Invited to Netflix HQ Will BYOL Cripple BYOD? What’s in Your Smartphone? Freedom vs. Control BYOD–The Hottest Trend or Just the Hottest Term Here's Help for Mobile Security Cellphone Surveillance ExplodesSpeed Matters, but Dev Speed or App Speed?
In running, speed matters. But how the speed matters is very important, and what type of running is your forte’ should determine what you are involved in. As a teen, I was never a very good sprinter. Just didn’t get up to speed fast enough, and was consistently overcome by more nimble opponents. But growing up on a beach was perfect conditioning for cross country track. Running five miles in beach sand that gave way underfoot and drained your energy much faster than it allowed you to move forward was solid practice for running through the woods mile after mile. And I wasn’t a bad runner – not a world champion to be sure – but I won more often than I lost when the “track” was ten or fifteen miles through the woods. The same is true of mobile apps, though most organizations don’t seem to realize it yet. There are two types of mobile apps – those that are developed for sprinting, by getting them to market rapidly, and those that are developed for the long haul, by implementing solutions based around the platform in question. By “platform” in this case, I mean the core notions of “mobile” apps – wireless, limited resources, touch interfaces, and generally different use cases than a laptop or desktop machine. It is certainly a more rapid go-to-market plan to have an outsourcer of some kind dump your existing HTML into an “app” or develop a little HTML5 and wrap it in an “app”, but I would argue that the goals of such an endeavor are short term. Much like sprinting, you’ll get there quickly, but then the race is over. How the judges (customers in this case) gauge the result is much more important. There are three basic bits to judging in mobile apps – ease of use, which is usually pretty good in a wrapped HTML or “hybrid” app; security, which is usually pretty horrendous in a hybrid app; and performance, which is usually pretty horrendous in a hybrid app. The security bit could be fixed with some serious security folks looking over the resultant application, but the performance issue is not so simple. You see, performance of a hybrid application is a simple equation… Speed of original web content + overhead of a cell phone + overhead of the app wrapper around the HTML. Sure, you’ll get faster development time wrapping HTML pages in an app, but you’ll get worse long-term performance. Kind of the same issue you get when a sprinter tries to run cross country. They rock for the first while, but burn out before the cross country racers are up to speed. You can use tools like our Application Delivery Optimization (ADO) engine to make the wrapped app perform better, but that’s not a panacea. Longer term it will be necessary to develop a more targeted, comprehensive solution. Because when you need a little bit of data and could wrap display functionality around it on the client side, transferring that display functionality and then trying to make it work in a client is pure overhead. Overhead that must be transmitted on a slower network over what is increasingly a pay-as-you-go bandwidth model. Even if the application somehow performs adequately, apps that are bandwidth hogs are not going to be repaid with joy as increasing numbers of carriers drop unlimited bandwidth plans. So before you shell out the money for an intermediate step, stop and consider your needs. Enterprises are being beaten about the head and shoulders with claims that if you don’t have a mobile app, you’re doomed. Think really carefully before you take the chicken-little mentality to heart. Are your customers demanding an app? If so are they demanding it right this instant? if so, perhaps a hybrid app is a good option, if you’re willing to spend whatever it costs to get it developed only to rewrite the app native in six or ten months. Take a look at the Play store or the Apple store, and you’ll see that just throwing an app out there is not enough. You need to develop a method to let your customers know it’s available, and it has to offer them… Something. If you can’t clearly define both of those requirements, then you can’t clearly define what you need, and should take a deep breath while considering your options. Let’s say you have a web-based calculator for mortgage interest rates. It is calling web services to do the interest rate calculations. For not much more development time, it is possible to build a very sweet version of the same calculator in native mode for either iPhones or Android (depending upon your platform priorities, could be either), with a larger up-front investment but less long-term investment by re-using those web services calls from within the mobile app. A little more money now, and no need to rewrite for better performance or targeting Mobile in the future? Take the little extra hit now and do it right. There are plenty of apps out there, and unless you can prove you’re losing money every day over lack of a mobile app, no one will notice that your application came out a month or two later – but they will notice how cool it is. While we’re on the topic, I hate to burst any bubbles, but every single website doesn’t need a dedicated app. We have to get over the hype bit and get to reality. Most people do not want 50 reader apps on their phone, each one just a simple hybrid shell to allow easier reading of a single website. They just don’t. So consider whether you even need an app. Seriously. If the purpose of your app is to present your website in a different format, well news flash, all mobile devices have this nifty little tool called a web browser that’s pretty good at presenting your website. Of course, when you do deploy apps, or even before you do, consider F5’s ADO and security products. They do a lot with mobile that is specific to the mobile world. App development is no simple task, and good app development, like all good development, will cost you money. Make the right choices, drive the best app you can out to your customers, because they’re not very forgiving of slow or buggy apps, and they’re completely unforgiving about apps that mess up their mobile devices. And maybe one day soon, if we’re lucky, we’ll have a development toolkit that works well and delivers something like this: Related Articles and Blogs F5 Solutions for VMware View Mobile Secure Desktop Drama in the Cloud: Coming to a Security Theatre Near You Scary App Games. SSL without benefit. Will BYOL Cripple BYOD? Four Best Practices for Reducing Risk in the Cloud Birds on a Wire(less) 22 Beginner Travel Tips Dreaming of Work 20 Lines or Less #59: SSL Re-encryption, Mobile Browsing, and iFiles Scaling Web Security Operations with DAST and One-Click Virtual Patching BIG-IP Edge Client v1.0.4 for iOS
