APM Cookbook: On-Demand VPN for iOS Devices
Overview I’ve been using On-Demand VPN for a number of years as it’s a secure and easy way to access applications while on the road with the added benefit of conserving device battery life when idle. On-Demand VPN is a simple concept. You define a domain or list of domains in the “Connect On Demand” settings. The Edge Client looks at the DNS requests made by the App (e.g Safari) and when the FQDN matches one of the defined domains, it fires up the VPN in the background and authenticates using a X.509 Client Certificate. On-Demand VPN requires the installation of a X.509 Client Certificate on the iOS device, which can be provisioned using a number of tools. This article will not go into these tools, but I will give you a few ideas how to get the X.509 certificate on the device. Some of the methods I have used in the past: Mobile Device Management (MDM) configured to use Simple Certificate Enrollment Protocol (SCEP) iPhone Configuration Utility (iPCU) Email the .p12 or .pfx file When using X.509 Client Certificates, I highly recommend adding the User Principal Name (UPN), e.g. test.user@f5.demo to the Subject Alternative Name (SAN) extension. This allows APM to identify the user of the device and can be used for: Single Sign On (SSO) using Kerberos or SAML Active Directory / LDAP queries to determine group membership etc. Logging and Reporting In a large scale environment I recommend using MDM, SCEP, Certificate Authority (CA) and an OCSP Responder to verify the revocation status. This article will cover how to configure the APM to authenticate the user and establish the VPN tunnel automatically using the On-Demand feature. My Example In my working example, I have a pre-configured CA called “CA1” joined to the domain “f5.demo”. The iOS device has the client certificate (Test User) installed with a UPN “test.user@f5.demo” in the SAN extension. This certificate has been issued by CA1 and is trusted by the iOS device. I have also installed the F5 Edge Client via the App Store. Step 1 – Import the SSL Certificates 1.1 Import the SSL Certificate/Key that will be used for SSL VPN connection System >> File Management >> SSL Certificate List Please follow SOL14620: Managing SSL certificates for BIG-IP systems My configuration looks like this: 1.2 Import Certificate Authority Certificate that is signing the Client Certificates Repeat Step 1.1 but this time you need to import the CA Certificate (without the Key) that is signing the User Certificates. It should look something similar to this: Step 2 – Create a Client SSL Profile Local Traffic >> Profiles >> SSL >> Client >> “Create” Supply the following: Name: vpn.f5.demo_ssl_profile Parent Profile: clientssl Certificate: vpn.f5.demo Key: vpn.f5.demo Trusted Certificate Authorities: CA1 Select “Finished” to save. Step 3 – Create the APM Configuration In this example I will use an On-Demand Certificate Authentication to validate the client certificate and some TCL to extract the UPN from the SAN extension. After successful authentication, a VPN tunnel is then assigned and established. You can expand on this configuration by adding an OCSP Responder to check if the certificate has been revoked. Simply modify the Names, IP addresses, DNS etc. to suit your environment. 3.1 Create a Webtop Access Policy >> Webtop >> Webtop List >> “Create” Supply the following: Name: vpn_webtop Type: Full Select “Finished” to save. 3.2 Create a Connectivity Profile Access Policy >> Secure Connectivity >> Connectivity Profile >> “Create” Supply the following: Name: vpn_cp Parent Profile: connectivity Select “Finished” to save. 3.3 Create a Lease Pool Access Policy >> Network Access >> Lease Pools >> IPv4 Lease Pools >> “Create” Supply the following: Name: vpn_lease_pool_10.123.123.0 Start IP Adddress: 10.123.123.1 End IP Address: 10.123.123.254 Select “Add” Select “Finished” to save. 3.4 Create a Network Access Access Policy >> Network Access >> Network Access List >> “Create” Supply the following: Name: vpn_na Caption: SSL VPN Select “Update” to save. Under “Network Settings”. Supply the following: IPV4 Lease Pool: vpn_lease_pool_10.123.123.0 Traffic Options: Use split tunneling for traffic (select appropriate option for your environment) IP Address: 10.0.0.0 Mask: 255.0.0.0 Select “Add” Select “Update” to save. Under “DNS/Hosts” Supply the following: IPV4 Primary Name Server: 10.10.20.1 DNS Default Domain Suffix: f5.demo Select “Update” to save. 3.5 Create an Access Policy We can now bring it all together using the Visual Policy Editor (VPE). Access Policy >> Access Profiles >> Access Profile List >> “Create” Supply the following: Name: vpn.f5.demo_ap Languages: English (en) Use the default settings for all other settings. Select “Finished” to save. 3.6 Edit the Access Policy in the VPE Access Policy >> Access Profiles >> Access Profile List >> “Edit” (vpn.f5.demo_ap) On the fallback branch after the Start object, add anOn-Demand Cert Auth object. Leave the defaults and “Save”. On the Successful branch after the On-Demand Cert Auth object, add a Variable Assign object. Supply the following: Name: Extract UPN Add the following variable assignments by selecting “Add new entry” >> “change”. Variable Assignment 1: Custom Variable (Unsecure): session.logon.last.domain Custom Expression: set upn [mcget {session.logon.last.upn}]; if {[string first "@" $upn] >= 0} { return [string range $upn [expr { [string first "@" $upn] + 1 } ] end ]; } else { return ""; } Variable Assignment 2: Custom Variable (Unsecure): session.logon.last.username Custom Expression: set upn [mcget {session.logon.last.upn}]; if {[string first "@" $upn] >= 0} { return [string range $upn 0 [expr { [string first "@" $upn] - 1 } ] ]; } else { return $upn; } Variable Assignment 3: Custom Variable (Unsecure): session.logon.last.upn Custom Expression: set e_fields [split [mcget {session.ssl.cert.x509extension}] "\n"]; foreach qq $e_fields { if {[string first "othername:UPN" $qq] >= 0} { return [string range $qq [expr { [string first "<" $qq] + 1 } ] [expr { [string first ">" $qq] - 1 } ] ]; } } return ""; Select “Finished”, then “Save” when your done. The VPE should look similar to this: On the fallback branch after the Extract UPN object, add a Full Resource Assign object. Supply the following: Name: SSL VPN Select “Add new entry” >> “Add/Delete” Add the Webtop: /Common/vpn_webtop (from step 3.1) Add the Network Access: /Common/vpn_na (from step 3.4) Select “Update” then “Save”. On the fallback branch after the SSL VPN object, change Deny ending to Allow. The finished policy should look similar to this: Step 4 – Create the Virtual Server for SSL VPN In this step, you need to create a HTTPS Virtual Server (VS) for the Edge Client to establish the connection. I also recommend creating a DTLS VS in addition to the HTTPS VS. This configuration is well documented in the APM Manual and I will not go through the DTLS VS creation. 4.1 Create the HTTP VS Local Traffic >> Virtual Servers >> Virtual Server List >> “Create” Supply the following: Name: vpn.f5.demo_https_vs Destination: 10.10.20.100 Service Port: HTTPS HTTP Profile: http SSL Profile (Client): vpn.f5.demo_ssl_profile (from step 2) SNAT Pool: Auto Map Access Profile: vpn.f5.demo_ap (from step 3.5) Connectivity Profile: vpn_cp (from step 3.2) Select “Finished" to save. Step 5 – Configure the Edge Client on the iOS device and Test 5.1 Create a new Edge Client Configuration Open the Edge Client and select “Settings” then “Add Configuration…” Supply the following: Description: On Demand VPN Server: vpn.f5.demo Use Certificate: On Certificate: Test User Connect On Demand: On Select Domain List Add Domain… In my example: demo.vpn Don’t forget to Save 5.2 Test Open Safari and access a URL that will cause the VPN trigger. In my example http://intranet.demo.vpn, a Sharepoint site. The VPN will start up when it sees the DNS query for intranet.demo.vpn and the data will flow across the VPN as per the Network Access settings. Conclusion On-Demand VPN with APM is a simple way to enable the workforce by providing a secure and easy to use remote access solution while out of the office.
Solving Secure Mobile Access with F5 and iOS 7 Per app VPN - Part 1
Overview As an F5 engineer out in the field I’m fortunate in the fact that I get to talk with customers about their projects and security concerns. While it probably would not surprise you to learn that Mobility is a key project for many organizations what does surprise me is how many are still using a layer-3 VPN approach on mobile devices. The major problem with this design is that once the VPN is established any application on the mobile platform can now access the corporate network. As we hear more and more about malware on mobile devices it is critical to start protecting corporate infrastructure by limiting access to corporate applications only. With iOS 7 Apple introduced a great way to accomplish this with their Per app VPN. Per app VPN allows iOS to control which applications have access to the VPN tunnel. This gives organizations the ability to designate which applications are corporate apps and treat everything else as personal. Per app VPN also works in Safari with a per-tab level of granularity. So I can have one tab open watching who the Houston Texan’s take in the first round draft (Johnny Manziel of course) and a second tab that is securely connected to my corporate SharePoint site. To take advantage of the iOS Per app VPN functionality Apple requires an Enterprise Mobile Management (EMM) solution to configure the mobile device and an Enterprise VPN solution like F5’s Access Policy Manager. So, if you’re anything like me you’ve scrolled past this text and straight to the pictures below because you need to deploy this ASAP right? We’ll here we go… Configuration The iOS Per app VPN uses F5’s APM SOCKS Proxy functionality so we'll need TMOS 11.4 or higher installed on the BIG-IP and Edge Client 2.0 or higher installed on the mobile device. 1. Create a new Application Policy Profile and select your default language. 2. Customize the Profile's Visual Policy Builder by adding a Client Cert Inspection object and set the successful branch to Allow 3. Create a new LTM Client SSL Profile: set Client Certificate to request set Trusted Certificate Authority to the CA that signed the certificate installed on the iOS device. 4. Create a new LTM Virtual Server: Add your customer Client SSL profile Select your Access Profile Select the default Connectivity Profile of create a custom connectivity profile with default settings Click the VDI & Java Support box to enable SOCKS proxy capabilities User Experience So What does the end result look like? In the example below I tested the Safari per-tab capabilities by clicking the F5 shortcut icon and seamlessly had access to my test web server. Next Steps In Part 2we will walk through how I configured AirWatch to perform the user experience demonstration.F5 BIG-IP Edge Client Now Supported in Apple macOS Sierra and iOS 10
F5 BIG-IP Edge Client and other F5 BIG-IP Access Policy Manager (APM) client features are now supported in Apple macOS Sierra (10.12) as of Tuesday, September 20, 2016 – the same day as the macOS Sierra was released! AND, BIG-IP Edge Client also supports Apple iOS 10 as of September 13, 2016 – the same day as it was released! Compatibility matrices for BIG-IP versions – only for those versions that still have active Software Development support – have been updated for support for both iOS 10 and macOS Sierra. The EPSEC release for macOS Sierra (release 450) is targeted for availability by thisFriday, September 23, 2016. macOS Sierra related known issues – some issues were found which might affect some BIG-IP Edge Client and BIG-IP APM customers. Thosechanges are: When usedwithJava 8, Java RDP freezes after using Caps Lock, Alt, Shift or Ctrl keys(611478). This issue will need to be addressed by Oracle. “Internal error” messages have been seen when using app tunnel on Safari 10 (611327) BIG-IP Edge Client customizations are not applied on macOS Sierra (611669). F5 will issue Engineering Hotfixes to address this issue inthe short term if there are customer support requests (CSRs). iOS 10 related changes – some behavior changes were also discovered with iOS 10 that customers may wish to know that relate to BIG-IP Edge Client and VPN use: When a user uses a per-app VPN configuration, that VPN connection is usually indicated with a VPN icon on the device status bar (at the top of the screen). In iOS 10, when an application that uses the per app VPN tunnel is not in the foreground, the VPN icon is not displayed on the status bar. In addition, when Safari is in the foreground and uses the per-app tunnel, the VPN icon is not displayed. This is a change in the OS, and not on Edge Client. Note: The behavior has not changed for a full device VPN initiated by On-Demand VPN or if the user manually uses Edge Client to establish a VPN connection. For these configurations, the VPN icon is always displayed when the VPN connection is active, as long as the connection has not been disconnected. iOS 10 known issues – the following are identified issues on iOS 10 that may affect the BIG-IP Edge Client, depending on the use case: •Previous settings from the Client Proxy Autoconfig Script are used and not refreshed until Safari is restarted (612997) •BIG-IP Edge Client fails to establish a layer 3 connection when layer 4 per-app VPN is already established. The following error is displayed: "Server unreachable. Please check your network connectivity and server address” (611923) The above behavior changes are due to changes in macOS or iOS 10 and not due to Edge Client changes. An AskF5 solution withthisinformation and more specifics on the issue, additional minor issues, and possible workarounds forcustomers should be available shortly. For further information on currently supported versions of BIG-IP software, please see the following article: SOL8986: F5 software life cycle policy https://support.f5.com/kb/en-us/solutions/public/8000/900/sol8986.html and the F5 Access and Edge Apps Compatibility Matrix.F5 BIG-IP Edge Client Now Supported in Apple macOS Sierra and iOS 10
F5 BIG-IP Edge Client and other F5 BIG-IP Access Policy Manager (APM) client features are now supported in Apple macOS Sierra (10.12) as of Tuesday, September 20, 2016 – the same day as the macOS Sierra was released! AND, BIG-IP Edge Client also supports Apple iOS 10 as of September 13, 2016 – the same day as it was released! Compatibility matrices for BIG-IP versions – only for those versions that still have active Software Development support – have been updated for support for both iOS 10 and macOS Sierra. The EPSEC release for macOS Sierra (release 450) is targeted for availability by thisFriday, September 23, 2016. macOS Sierra related known issues – some issues were found which might affect some BIG-IP Edge Client and BIG-IP APM customers. Thosechanges are: When usedwithJava 8, Java RDP freezes after using Caps Lock, Alt, Shift or Ctrl keys(611478). This issue will need to be addressed by Oracle. “Internal error” messages have been seen when using app tunnel on Safari 10 (611327) BIG-IP Edge Client customizations are not applied on macOS Sierra (611669). F5 will issue Engineering Hotfixes to address this issue inthe short term if there are customer support requests (CSRs). iOS 10 related changes – some behavior changes were also discovered with iOS 10 that customers may wish to know that relate to BIG-IP Edge Client and VPN use: When a user uses a per-app VPN configuration, that VPN connection is usually indicated with a VPN icon on the device status bar (at the top of the screen). In iOS 10, when an application that uses the per app VPN tunnel is not in the foreground, the VPN icon is not displayed on the status bar. In addition, when Safari is in the foreground and uses the per-app tunnel, the VPN icon is not displayed. This is a change in the OS, and not on Edge Client. Note: The behavior has not changed for a full device VPN initiated by On-Demand VPN or if the user manually uses Edge Client to establish a VPN connection. For these configurations, the VPN icon is always displayed when the VPN connection is active, as long as the connection has not been disconnected. iOS 10 known issues – the following are identified issues on iOS 10 that may affect the BIG-IP Edge Client, depending on the use case: •Previous settings from the Client Proxy Autoconfig Script are used and not refreshed until Safari is restarted (612997) •BIG-IP Edge Client fails to establish a layer 3 connection when layer 4 per-app VPN is already established. The following error is displayed: "Server unreachable. Please check your network connectivity and server address” (611923) The above behavior changes are due to changes in macOS or iOS 10 and not due to Edge Client changes. An AskF5 solution withthisinformation and more specifics on the issue, additional minor issues, and possible workarounds forcustomers should be available shortly. For further information on currently supported versions of BIG-IP software, please see the following article: SOL8986: F5 software life cycle policy https://support.f5.com/kb/en-us/solutions/public/8000/900/sol8986.html and the F5 Access and Edge Apps Compatibility Matrix.F5 BIG-IP Edge Client for iOS version 2.0.9 Now Available
F5 recently released F5 BIG-IP Edge Client for iOS, version 2.0.9 on the Apple App Store. The release of the F5 Edge Client for iOS, version 2.0.9 delivers various fixesand workarounds that address customer issues, along with other security related fixes. The main issues F5 Edge Client for iOS, version 2.0.9 addresses pertain to problems encountered by customers using iOS App Configurations with MDM solutions and Edge Client for iOS; in these instances, the Edge Client had been crashing or only made visible the background of the Edge Client for iOS app. The BIG-IP versions that currently support F5 Edge Client for iOS, version 2.0.9 may be found in the BIG-IP Edge Client Compatibility Matrix. The release notes for F5 Edge Client for iOS, version 2.0.9 are also available. Should there be any additions or modifications to the F5 Edge Client for iOS, version 2.0.9, F5 will communicate those as soon as possible. Please contact F5 Support with any questions or comments regarding F5 Edge Client for iOS, version 2.0.9.
Multipath TCP (MPTCP)
#mobile #webperf #IOS7 Two! Two connections at the same time, ah ah ah... Long ago, when the web was young, we (as in the industry) figured out how to multiplex TCP (and later HTTP which we now call message steering) in order to dramatically improve application performance while simultaneously reducing load on servers. Yes, you could more with less. It was all pretty exciting stuff. Now, at long last, we're seeing the inverse come to life on the client side in the form of Multipath TCP (MPTCP) or, if you prefer a more technically sounding term to confuse your friends and family: inverse multiplexing. While the geeks among us (you know who you are) have always known how to use both the wired and wireless interfaces on our clients, it's never been something that had real advantages when it comes to web performance. There was no standard way of using both connections at the same time and really, there was very little advantage. Seriously,if you're wired up to at least a 100Mbps full duplex LAN do you really need a half-duplex wireless connection to improve your performance? No. But in the case of mobile devices, the answer is a resounding yes - yes I do. Because 2 halves make a whole, right? Okay, maybe not, but it's certainly a whole lot closer. THE MAGIC of MULTIPLEXING Most mobile devices enable you to connect over both wireless radio (mobile) network and a wireless LAN network. Most of the time you're probably using both at the same time without conscious thought. It just does what it does, as long as it's configured and connected. What it doesn't do, however, is enable an application to use both connections at the same time to connect up to an application. Your application can often use either one, but it is limited to using just one at a time. Unless you're using an MPTCP-enabled device. TCP is built on the notion of a single connection between 2 hosts. MPTCP discards that notion and enables a device to seamlessly switch between and/or simultaneously send a TCP connection over multiple interfaces. Basically, MPTCP splits up a TCP connection into subflows, and is able to (based on the device) dynamically route messages across either of those subflows. This is, you're thinking, perfect for HTTP exchanges which often require a significant number of "sub-requests" for a client to retrieve all the objects required for an given web page/application. Exactly. You're sending (and one hopes receiving) data twice as fast. Which on a mobile device is likely to be very noticeable. The problem is (and you knew there was one, didn't you?) that both the client and the host need to "speak" MPTCP to realize its potential benefits with respect to application performance. There aren't a whole lot of implementations at the moment, though one of those being iOS7 is certain impetus for hosts (the server side of all those apps) to get refitted for MPTCP. Of course, that's unlikely, isn't it? If you're in the cloud, are your hosts MPTCP ready? If you're not in the cloud, is your own infrastructure MPTCP ready? Like SPDY before it (and there's an interesting scenario - running MPTCP over SPDY) these kinds of protocol enhancements require support on both the client and the server and generally speaking, while organizations want to be able to leverage the improvements in performance (or efficiency or security) they can't justify a forklift upgrade and the ensuing disruption to get there. Further complicating potential adoption is limited support. Though Apple certainly holds a significant share of the mobile market, it's not the only player and MPTCP is only supported by iOS7 - an upgrade that hasn't been exactly cheered as the greatest thing since sliced bread by the market in general. Whether MPTCP will gain momentum as iOS7 continues to roll out and other players adopt (and that is not necessarily a given) will be determined not only by application developers desiring (or perhaps demanding) support but by whether or not organizations are able to rapidly roll out support on their end without completely replacing their entire infrastructure. A very good (and fairly technical) article on MPTCP and IOS7 from ArsTechnica. And of course your day wouldn't be complete unless I pointed out the MPTCP RFC.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 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 RSABIG-IP Edge Client v1.0.4 for iOS
If you are running the BIG-IP Edge Client on your iPhone, iPod or iPad, you may have gotten an AppStore alert for an update. If not, I just wanted to let you know that version 1.0.4 of the iOS Edge Client is available at the AppStore. The main updates in v1.0.4: IPv6 Support Localization New iPad Retina Graphics The BIG-IP Edge Client application from F5 Networks 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 iOS 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. I updated mine today without a problem. ps
