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, iTunes
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.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:Where Do You Wear Your Malware?
The London Stock Exchange, Android phones and even the impenetrable Mac have all been malware targets recently. If you’re connected to the internet, you are at risk. It is no surprise that the crooks will go after whatever device people are using to conduct their life – mobile for example, along with trying to achieve that great financial heist….’if we can just get this one big score, then we can hang up our botnets and retire!’ Perhaps Homer Simpson said it best, ‘Ooh, Mama! This is finally really happening. After years of disappointment with get-rich-quick schemes, I know I'm gonna get Rich with this scheme...and quick!’ Maybe we call this the Malware Mantra! Malware has been around for a while, has changed and evolved over the years and we seem to have accepted it as part of the landmines we face when navigating the internet. I would guess that we might not even think about malware until it has hit us….which is typical when it comes to things like this. Out of sight, Out of mind. I don’t think ‘absence makes the heart grow fonder’ works with malware. We certainly take measures to guard ourselves, anti-virus/firewall/spoof toolbars/etc, which gives us the feeling of protection and we click away thinking that our sentinels will destroy anything that comes our way. Not always so. It was reported that the London Stock Exchange was delivering malvertising to it’s visitors. The LSE site itself was not infected but the pop-up ads from the site delivered some nice fake warnings saying the computer was infected and in danger. This is huge business for cybercriminals since they insert their code with the third-party advertiser and never need to directly attack the main site. Many sites rely on third-party ads so this is yet another area to be cautious of. One of the things that Web 2.0 brought was the ability to deliver or feed other sites with content. If you use NoScript with Firefox on your favorite news site (or any major site for that matter), you can see the amazing amount of content coming from other sources. Sometimes, 8-10 or more domains are listed as content generators so be very careful as to which ones you allow. With the success of the Android platform, it also becomes a target. This particular mobile malware looks and acts like the actual app. The problem is that it also installs a backdoor to the phone and asks for additional permissions. Once installed, it can connect to a command server and receive instructions; including sending text messages, add URL’s/direct a browser to a site along with installing additional software. The phone becomes part of a botnet. Depending on your contract, all these txt can add up leading to a bill that looks like you just bought a car. In fact, Google has just removed 21 free apps from the Android Market saying its malware designed to get root access to the user’s device. They were all masquerading as legitimate games and utilities. If you got one of these, it’s highly recommended that you simply take your phone back to the carrier and swap it for a new one, since there’s no way of telling what has been compromised. As malware continues to evolve, the mobile threat is not going away. This RSA2011 recap predicts mobile device management as the theme for RSA2012. And in related news, F5 recently released our Edge Portal application for the Android Market – malware free. Up front, I’m not a Mac user. I like them, used them plenty over the years and am not opposed to getting one in the future, just owned Windows devices most of my life. Probably due to the fact that my dad was an IBM’r for 30 years. Late last week, stories started to appear about some beta malware targeting Macs. It is called BlackHole RAT. It is derived from a Windows family of trojans and re-written to target Mac. It is spreading through torrent sites and seems to be a proof-of-concept of what potentially can be accomplished. Reports say that it can do remote control of an infected machine, open web pages, display messages and force re-boots. There is also some disagreement around the web as to the seriousness of the threat but despite that, criminals are trying. Once we all get our IPv6 chips installed in our earlobes and are able to take calls by pulling on our ear, a la Carol Burnett style, I wonder when the first computer to human virus will be reported. The wondering is over, it has already happened. ps Resources: London Stock Exchange site shows malicious adverts When malware messes with the markets Android an emerging target for cyber criminals Google pulls 21 apps in Android malware scare More Android mobile malware surfaces in third-party app repositories Infected Android app runs up big texting bills Ignoring mobile hype? Don't overlook growing mobile device threats "BlackHole" malware, in beta, aims for Mac users Mac Trojan uses Windows backdoor code I'll Believe Mac malware is a problem when I see it BlackHole RAT is Really No Big Deal 20 years of innovative Windows malware Edge Portal application on Android MarketInvasion of Privacy - Mobile App Infographic Style
Couple blogs/weeks ago, I posted What’s in Your Smartphone? covering the recent Nielsen report, State of the Appnation – A Year of Change and Growth in U.S. Smartphones. According to the study, 70% (last year) and 73% (this year) expressed concern over personal data collection and 55% were cautious about sharing location info via smartphone apps so, obviously, it is important that users are aware of the risks they face when downloading and using apps. So it is perfect timing that I came across Veracode’s infographic showing real world cases to outline the threat to user privacy posed by mobile apps. Infographic by Veracode Application Security Fascinating and scary at the same time. ps References: How Mobile Apps are Invading Your Privacy Infographic Infographic: How Mobile Apps Invade Your Privacy State of the Appnation – A Year of Change and Growth in U.S. Smartphones Nielsen: 1 in 2 own a smartphone, average 41 apps Freedom vs. Control BYOD–The Hottest Trend or Just the Hottest Term Hey You, Get Off-ah My Cloud! Evolving (or not) with Our Devices The New Wallet: Is it Dumb to Carry a Smartphone? BYOD Is Driving IT ‘Crazy,’ Gartner Says Consumerization trend driving IT shops 'crazy,' Gartner analyst saysAndroid 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 .BYOD 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 RSAFreedom vs. Control
No sooner had I posted BYOD–The Hottest Trend or Just the Hottest Term, last week than yet another BYOD survey hit the news. The full results will be released in a webinar tomorrow but SANS announced their First Annual Survey Results on Mobility Security. Last December, SANS launched its first ever mobility survey to discover if and how organizations are managing risk around their end user mobile devices. The survey of 500 IT pros found that a meager 9% of organizations felt they were fully aware of the devices accessing corporate resources, while 50% felt only vaguely or fairly aware of the mobile devices accessing their resources. In addition, more than 60 % of organizations allow staff to bring their own devices. With so many companies allowing BYOD, controls and policies are very important to securing business environments. Courtesy: SANS Mobility BYOD Security Survey Deb Radcliff, executive editor, SANS Analyst Program said, ‘Another interesting note is that organizations are reaching for everything at their disposal to manage this risk,…Among them are user education, MDM (mobile device management), logging and monitoring, NAC and guest networking, and configuration controls.’ 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. The BYOD challenges, I think, falls under an age old dilemma: Freedom vs. Control. We see this clash in world politics, we’ve seen it pertaining to the internet itself, we may even experience it at home with our offspring. The freedom to select, use, work and play with the desired mobile device of our choosing bumping up against a company’s mandate to protect and secure access to sensitive corporate information. There can be tension between a free and open culture verses the benefits of control and information management. Sometimes people equate freedom with having control over things yet when it comes to controlling others, many of us feel slightly uncomfortable on either end of the leash. Sometimes oversight is necessary if someone does not have self-control. BYOD is a revolution, a drastic change in how organizations manage devices and manage access to information. If you look at revolutions through the years, often it’s about freedom vs. control. I’m certainly not suggesting an employee coup of the executive floor but remember there are two distinct and diverse powers at play here and successful BYOD deployments need to involve both people and technology. ps Resources SANS Mobility BYOD Security Survey Are your employees on a BYOD binge? SANS Survey: BYOD Widespread But Lacking Sufficient Oversight SANS First Annual Survey Results on Mobility Security: Lack of Awareness, Chaos Pervades with BYOD BYOD–The Hottest Trend or Just the Hottest Term Only 9 Percent of Organizations Are Aware of the Devices Accessing Their Corporate Data Evolving (or not) with Our Devices The New Wallet: Is it Dumb to Carry a Smartphone? Audio Tech Brief - Secure iPhone Access to Corporate Web Applications Freedom vs Control – important lessons to be learned New security flaws detected in mobile devices Freedom and Control | Psychology Today Devo - Freedom Of Choice (Video)Scary App Games. SSL without benefit.
#androidDev When an SSL enabled app isn’t, and how easy that is to implement. Remember the Maginot line and how powerful and defensive it was going to be… And then the Germans just bypassed it? Remember the West Wall, where the Allies were going to throw themselves against in the waning days of World War II… And then it was not just pierced but effectively eliminated as a protective barrier in five days of fighting? That’s what happens when you know you need a defense, and you place all of your eggs in one basket. At least in the IT world a little caution can save you a lot. Here’s a cautionary tale. We trust SSL explicitly, but from a “download random app X” perspective, that’s a mistake. I’ve been spending my evenings on a home project developing an app for the Android. There are a ton of things that the app needs to work, so when I hit the “must communicate with SSL” part, I wanted a quick fix work-around for prototyping because my test site’s SSL cert was both self-signed and had a host name mismatch. I researched and settled on the solution for the final app, but in the interim, I came across some interesting ideas on how app developers can resolve SSL problems… There are several excellent (if excellent is the correct term) examples out there for how to completely avoid SSL benefits while using SSL. Some of the app developers you’re getting apps from are using them too. I refuse to link to them here, but I’ll just give you the business level overview… There is a class in Java called a Trust Manager. It’s job is to validate SSL certificates. Two common problems are with self-signed and hostname mismatched certificates. The problem is that the default action of the classes in Java is to reject either one automatically, causing connections to servers those certificates were retrieved from to be blocked. There are several good solutions to this problem, and all only require a few steps. The steps are beyond the scope of this blog, but I have a theory for a really simple solution that I’ll blog about if it works as I think it will (can’t test it at the moment, building new Dev machines for Lori and I is taking night-time precedence over this development project). You would be amazed at how many forums have the suggested solution of over-riding (subclassing for the devs in the audience) the X509 Trust Manager and approving EVERY connection. No checking at all, just return “True” from all of the “is this valid” methods. If you also over-ride the HostNameVerifier and always return “true” to say “the host is good” no matter what. It works for every site imaginable. It also allows for MiTM attacks, bogus sites where you think you’re protected, all sorts of things. So in short, it gives you all of the overhead of SSL and none of the protection. Kind of like collecting candybar wrappers. They may look good, but you can’t enjoy them. In the current environment, your users are downloading all sorts of apps. And they have no clue what is done with SSL within apps that claim to use it. And that might just cause your users, with some amount of corporate data on their devices, to be a source of data leakage. There is not a really solid way of testing if an app is using a bogus trust manager (because the dev was not good enough to implement an actual solution) in an enterprise environment, but there are ways to test for symptoms. Set up an SSL protected server with self-signed cert, and connect to it. If the app doesn’t ask you to confirm the exception, I’d be suspicious. Then change the server name without updating the cert. If the app doesn’t ask you to confirm the exception, I’d be suspicious. If you’re a developer, those sites telling you to build a trust-everything manager are NOT offering a viable solution. Most caveat their solutions with that commentary, but some do not. While I did use it for testing, there is not a valid use to ship an app with that kind of abomination inside of it. If you’re an enterprise, consider setting up a simple test server and asking your staff to use it on new apps. It may be paranoid, this is certainly not the worst security threat that downloaded apps create, but it’s simple to set up a test server, and at least then you’ll know for certain if a given app is a risk. And check any outsourced apps you have had developed. A simple text search to look for HostNameVerifier in the source tree and then look for the verify() method. If it returns true always, you outsourced to the wrong developers. This is only one of the places the code has to be bad to implement “trust all hosts” though, so just get solid developers to look it over if you find this problem. Better safe than sorry. Just saying.BYOD 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 RSA
