The Top 10, Top Predictions for 2012
Around this time of year, almost everyone and their brother put out their annual predictions for the coming year. So instead of coming up with my own, I figured I’d simply regurgitate what many others are expecting to happen. Security Predictions 2012 & 2013 - The Emerging Security Threat – SANS talks Custom Malware, IPv6, ARM hacking and Social Media. Top 7 Cybersecurity Predictions for 2012 - From Stuxnet to Sony, a number of cyberattacks emerged in 2011 that experts have predicted for quite some time. Webroot’s top seven forecasts for the year ahead. Zero-day targets and smartphones are on this list. Top 8 Security Predictions for 2012 – Fortinet’s Security Predictions for 2012. Sponsored attacks and SCADA Under the Scope. Security Predictions for 2012 - With all of the crazy 2011 security breaches, exploits and notorious hacks, what can we expect for 2012? Websense looks at blended attacks, social media identity and SSL. Top 5 Security Predictions For 2012 – The escalating change in the threat landscape is something that drives the need for comprehensive security ever-forward. Firewalls and regulations in this one. Gartner Predicts 2012 – Special report addressing the continuing trend toward the reduction of control IT has over the forces that affect it. Cloud, mobile, data management and context-aware computing. 2012 Cyber Security Predictions – Predicts cybercriminals will use cyber-antics during the U.S. presidential election and will turn cell phones into ATMs. Top Nine Cyber Security Trends for 2012 – Imperva’s predictions for the top cyber security trends for 2012. DDoS, HTML 5 and social media. Internet Predictions for 2012 – QR codes and Flash TOP 15 Internet Marketing Predictions for 2012 – Mobile SEO, Social Media ROI and location based marketing. Certainly not an exhaustive list of all the various 2012 predictions including the doomsday and non-doomsday claims but a good swath of what the experts believe is coming. Wonder if anyone predicted that Targeted attacks increased four-fold in 2011. ps Technorati Tags: F5, cyber security, predictions, 2012, Pete Silva, security, mobile, vulnerabilities, crime, social media, hacks, the tube, internet, identity theftBIG-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, iTunesF5 and Promon Have Partnered to Protect Native Mobile Applications from Automated Bots - Easily
This DevCentral article provides details on how F5 Bot Defense is used today to protect against mobile app automated bot traffic from wreaking havoc with origin server infrastructure and producing excessive nuisance load volumes, and in turn how the Promon Mobile SDK Integrator is leveraged to speed the solution's deployment. The integrator tool contributes to the solution by allowing the F5 anti-bot solution to be inserted into customer native mobile apps, for both Apple and Android devices, with a simple and quick “No Code” approach that can be completed in a couple of minutes.No source code of the native mobile app need be touched, only the final compiled binaries are required to add the anti bot security provisions as a quick, final step when publishing apps. Retrieving Rich, Actionable Telemetry in a Browser World In the realm of Internet browser traffic, whether the source be Chrome, Edge, Safari or any other standards-based web browser, the key to populating the F5 anti-bot analytics platform with actionable data is providing browsers clear instructions of when, specifically, to add telemetry to transactions as well as what telemetry is required.This leads to the determination, in real time, of whether this is truly human activity or instead automated, negative hostile traffic. The “when” normally revolves around the high value server-side endpoint URLs, things like “login” pages, “create account” links, “reset password” or “forgot username” pages, all acting like honeypot pages where attackers will gravitate to and direct brute force bot-based attacks to penetrate deep into the service. All the while, each bot will be cloaked to the best of their abilities as a seemingly legitimate human user.Other high-value transaction endpoints would likely be URLs corresponding to adding items to a virtual shopping cart and checkout pages for commercial sites. Telemetry, the “what” in the above discussion, is to be provided for F5 analytics and can range from dozens to over one hundred elements.One point of concern is inconsistencies in the User Agent field produced in the HTTP traffic, where a bot may indicate a Windows 10 machine using Chrome via the User Agent header, but various elements of telemetry retrieved indicate a Linux client using Firefox.This is eyebrow raising, if the purported user is misleading the web site with regards to the User Agent, what is the traffic creator’s endgame? Beyond analysis of configuration inconsistencies, behavioral items are noted such as unrealistic mouse motions at improbable speeds and uncanny precision suggesting automation, or perhaps the frequent use of paste functions to fill in form fields such as username, where values are more likely to be typed or be auto filled by browser cache features. Consider something as simple as the speed of key depressed and the key being released upward, if signals indicate an input typing pace that defies the physics of a keyboard, just milliseconds for a keystroke, this is another strong warning sign of automation. Telemetry in the Browser World Telemetry can be thought of as dozens and dozens of intelligence signals building a picture of the legitimacy of the traffic source. The F5 Bot Defense request for telemetry and subsequently provided values are fully obfuscated from bad actors and thus impossible to manipulate in any way. The data points lead to a real time determination of the key aspect of this user:is this really a human or is this automation? This set of instructions, directing browsers with regards to what transactions to decorate with requested signals, is achieved by forcing browsers to execute specific JavaScript inserted into the pages that browsers load when interacting with application servers.The JavaScript is easily introduced by adding JavaScript tags into HTML pages, specifically key returned transactions with “Content Type=text/HTML” that subsequently lead to high value user-side actions like submission of user credentials (login forms). The addition of the JavaScript tags is frequently inserted in-line to returned traffic through a F5 BIG-IP application delivery controller, the F5 Shape proxy itself, or a third-party tag manager, such as Google Tag Manager.The net result is a browser will act upon JavaScript tags to immediately download the F5 JavaScript itself.The script will result in browsers providing the prescribed rich and detailed set of telemetry included in those important HTTP transactions that involve high value website pages conducting sensitive actions, such as password resetting through form submissions. Pivoting to Identify Automation in the Surging Mobile Application Space With native mobile apps, a key aspect to note is the client is not utilizing a browser but rather what one can think of a “thick” app, to borrow a term from the computer world.Without a browser in play, it is no longer possible to simply rely upon actionable JavaScript tags that could otherwise be inserted in flight, from servers towards clients, through application delivery controllers or tag managers.Rather, with mobile apps, one must adjust the app itself, prior to posting to an app store or download site, to offer instructions on where to retrieve a dynamic configuration file, analogous to the instructions provided by JavaScript tag insertion in the world of browsers. The retrieved configuration instruction file will guide the mobile app in terms of which transactions will require “decorating” with telemetry, and of course what telemetry is needed.The telemetry will often vary from one platform such as Android to a differing platform such as Apple iOS.Should more endpoints within the server-side application need decorating, meaning target URLs, one simply adjusts the network hosted configuration instruction file. This adjustment in operations of a vendor’s native mobile application behavior is achieved through F5 Bot Defense Mobile SDK (Software Development Kit) and representative provided telemetry signals might include items like device battery life remaining, device screen brightness and resolution and indicators of device setup, such as a rooted device or an emulator posing as a device.Incorrectly emulated devices, such as one displaying mutually exclusive iOS and Android telemetry, concurrently, allows F5 to isolate troublesome, unwanted automated traffic from the human traffic required for ecommerce to succeed efficiently and unfettered. The following four-step diagram depicts the process of a mobile app being protected by F5 bot defense, from step one with the retrieval of instructions that include what transactions to decorate with telemetry data, through to step four where the host application (the mobile app) is made aware if the transaction was mitigated (blocked or flagged) by means of headers introduced by the F5 Antibot solution. The net result of equipping mobile apps with the F5 Bot Defense Mobile SDK, whether iOS or Android, is the ability to automatically act upon automated bot traffic observed, without a heavy administrative burden. A step which is noteworthy and unique to the F5 mobile solution is the final, fourth step, whereby a feedback mechanism is implemented in the form of the Parse Response header value.This notifies the mobile app that the transaction was mitigated (blocked) en route.One possible reason this can happen is the app was using a dated configuration file, and a sensitive endpoint URL had been recently adjusted to require telemetry.The result of the response in step 4 is the latest version of the config file, with up-to-date telemetry requirements, will automatically be re-read by the mobile app and the transaction can now take place successfully with proper decorated telemetry included. Promon SDK Integrator and F5 Bot Defense: Effortlessly Secure Your Mobile Apps Today One approach to infusing a native mobile app with the F5 Bot Defense SDK would be a programmatic strategy, whereby the source code of the mobile app would require modifications to incorporate the F5 additional code.Although possible, this may not be aligned with the skillsets of all technical resources requiring frequent application builds, for instance for quality assurance (QA) testing. Another issue might be a preference to only have obfuscated code at the point in the publishing workflow where the security offering of the SDK is introduced.In simple terms, the core mandate of native mobile app developers is the intellectual property contained within that app, adding valuable security features to combat automation is more congruent with a final checkmark obtained by protecting the completed application binary with a comprehensive protective layer of security. To simplify and speed up the time for ingestion of the SDK, F5 has partnered with Promon, of Oslo, Norway to make use of an integrator application from Promon which can achieve a “No Code” integration in just a few commands.The integrator, technically a .jar executable known as the Shielder tool at the file level, is utilized as per the following logic. The workflow to create the enhanced mobile app, using the Promon integration tool, with the resultant modified mobile app containing the F5 (Shape) SDK functions within it, consists of only two steps. 1.Create a Promon SDK Integrator configuration file 2.Perform the SDK injection An iOS example would take the follow form: Step 1: python3 create_config.py --target-os iOS --apiguard-config ./base_ios_config.json --url-filter *.domain.com --enable-logs --outfile sdk_integrator_ios_plugin_config.dat Step 2: java -jar Shielder.jar --plugin F5ShapeSDK-iOS-Shielder-plugin-1.0.4.dat --plugin sdk_integrator_ios_plugin_config.dat ./input_app.ipa --out . /output_app.ipa --no-sign Similarly, an Android example would remain also a simple two-step process looking much like this: Step 1: python3 create_config.py --target-os Android --apiguard-config ./base_android_config.json --url-filter *.domain.com --enable-logs --outfile sdk_integrator_android_plugin_config.dat Step 2: java -jar Shielder.jar --plugin F5ShapeSDK-Android-Shielder-plugin-1.0.3.dat --plugin sdk_integrator_android_plugin_config.dat ./input_app.apk --output ./output_app.apk In each respective “Step 1”, the following comments can be made about the create_config.py arguments: target-os specifies the platform (Apple or Android). apiguard-config will provide a base configuration .json file, which will server to provide an initial list of protected endpoints (corresponding to key mobile app exposed points such as “create account” or “reset password”), along with default telemetry required per endpoint.Once running, the mobile app equipped with the mobile SDK will immediately refresh itself with a current hosted config file. url-filter is a simple means of directing the SDK functions to only operate with specific domain name space (eg *.sampledomain.com).Url filtering is also available within the perpetually refreshed .json config file itself. enable-logs allows for debugging logs to be optionally turned on. outfile specifies for file naming of the resultant configuration.dat file, which is ingested in step 2, where the updated iOS or Android binary, with F5 anti-bot protections, will be created. For Step 2, where the updated binaries are created, for either Apple iOS or Android platforms, these notes regard each argument called upon by the java command: shielder.jar is the portion of the solution from Promon which will adjust the original mobile application binary to include F5 anti-bot mobile security, all without opening the application code. F5ShapeSDK-[Android or iOS]-Shielder-plugin-1.0.3.dat is the F5 antibot mobile SDK, provide in a format consumable by the Promon shielder. The remaining three arguments are simply the configuration output file of step 1, the original native mobile app binary and finally the new native mobile app binary which will now have anti-bot functions. The only additional step that is optionally run would be re-signing the new version of the mobile application, as the hash value will change with the addition of the security additions to the new output file. Contrasting the Promon SDK Integrator with Manual Integration and Mobile Application Requirements The advantage of the Promon Integrator approach is the speed of integration and the lack of any coding requirements to adjust the native mobile application.The manual approach to integrating F5 Bot Defense Mobile SDK is documented by F5 with separate detailed guides available for Android and for iOS.A representative summary of the steps involved include the following check points along the path to successful manual SDK integration: oImporting the provided APIGuard library into Android Studio (Android) and Xcode (iOS) environments oThe steps for iOS will differ depending on whether the original mobile app is using a dynamic or static framework, commands for both Swift and Objective-c are provided in the documentation oThe F5 SDK code is already obfuscated and compressed; care should be followed not to include this portion of the revised application in existing obfuscation procedures oWithin Android Studio, expand and adjust as per the documentation the Gradle scripts oInitialize the Mobile SDK; specific to Android and the Application Class the detailed functions utilized are available with the documentation, including finished initialization examples in Java and Kotlin oSpecific to iOS, initialize the mobile SDK in AppDelegate, this includes adding APIGuardDelegate to the AppDelegate class as an additional protocol, full examples are provided for Swift and Obective-c oBoth Android and iOS will require a GetHeaders functions be invoked through code additions for all traffic potentially to be decorated with telemetry, in accordance with the instructions of the base and downloaded configuration files As demonstrated the by the list length of these high-level and manual steps above, which involve touching application code, the alternative ease and simplicity of the Promon Integrator two command offering may be significant in many cases. The platform requirements for the F5 Bot Defense and Promon paired solution are not arduous and frequently reflect libraries used in many native mobile applications developed today.These supported libraries include: oAndroid: HttpURLConnection, OkHttp, Retrofit oiOS: NSURLSession, URLSession, Alamofire Finally, mobile applications that utilize WebViews, which is to say applications using browser-type technologies to implement the app, such as support for Cascading Style Sheets or JavaScript, are not applicable to the F5 Bot Defense SDK approach.In some cases, entirely WebView implemented applications may be candidates for support through the browser style JavaScript-oriented F5 Bot Defense telemetry gathering. Summary With the simplicity of the F5 and Promon workflow, this streamlined approach to integrating the anti-bot technology into a mobile app ecosystem allows for rapid, iterative usage. In development environments following modern CI/CD (continuous integration/continuous deployment) paradigms, with build servers creating frequently updated variants of native mobile apps, one could invoke the two steps of the Promon SDK integrator daily, there are no volume-based consumption constraints.
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.
AppSec Made Easy: Anti-Bot for Mobile APIs
Learn how to use the F5 Advanced Web Application Firewall to easily lock down your applications so that bots can’t attack your mobile APIs. Integrating an SDK can be challenging, but this video will show you the quick way to add anti-bot and other protections directly into your mobile app. See the entire AppSec Made Easy series.Is 2015 Half Empty or Half Full?
With 2015 crossing the half way point, let's take a look at some technology trends thus far. Breaches: Well, many databases are half empty due to the continued rash of intrusions while the crooks are half full with our personal information. Data breaches are on a record pace this year and according to the Identity Theft Resource Center (ITRC), there have been 400 data incidents as of June 30, 2015. One more than this time last year. And, 117,576,693 records had been compromised. ITRC also noted a 85% increase in the number of breaches within the banking sector. From health care to government agencies to hotel chains to universities and even Major League Baseball, breaches and attacks are now a daily occurrence. Cloud: Who would've thought back in 2008 that this cloud thing would now be half full? Over the last couple years, the 'cloud' has become a very viable option for organizations large and small. It is becoming the platform for IoT and many organizations such as Google and GE are now moving critical corporate applications to the cloud. While hybrid is the new normal remember, The Cloud is Still just a Datacenter Somewhere. DNS: While IPv4 addresses are now completely empty, DNS seems to be half to almost full in 2015. DNS continues to be a target for attackers along with being an enabler for IoT. It is so important that Cisco recently acquired OpenDNS to help fight IoT attacks and the courts got a guilty plea from an Estonian man who altered DNS settings on infected PCs with the DNSChanger malware. I think of DNS as a silent sufferer - you really don't care about it until it doesn't work. Start caring this year. Internet: Full but still growing. As noted above, IPv4 addresses are gone. Asia, Europe, Latin America and now North America have run out of IPv4 addresses and have exhausted their supplies. If you're wondering how to handle this glass, F5 has some awesome 4to6 and 6to4 solutions. IoT: Things, sensors and actuators are all the buzz and are certainly half full for 2015. At this time last year, IoT was at the top of the Gartner Hype Cycle and it has certainly not disappointed. Stories abound about Internet of Things Security Risks and Challenges, 10 of the biggest IoT data generators, the Top 10 Worst Wearable Tech Devices So Far, The (Far-Flung) Future Of Wearables, along with the ability to Smell Virtual Environments and if We Need Universal Robot Rights, Ethics And Legislation. RoboEthics, that is. Mobile: We are mobile, our devices are mobile and the applications we access are now probably mobile also. Mobility, in all it's connotations, is a huge concern for enterprises and it'll only get worse as we start wearing our connected clothing to the office. The Digital Dress Code has emerged. Mobile is certainly half full and there is no empting it now. Privacy: At this point with all the surveillance, data breaches, gadgets gathering our daily data and our constant need to tell the world what we're doing every second, this is probably bone dry. Pardon, half empty, sticking to the theme. That's what I got so far and I'm sure 2015's second half will bring more amazement, questions and wonders. We'll do our year in reviews and predictions for 2016 as we all lament, where did 2015 go? There is that old notion that if you see a glass half full, you're an optimist and if you see it half empty you are a pessimist. Actually, you need to understand what the glass itself was before the question. Was it empty and filled half way or was it full and poured out? There's you answer! ps Related: It's all contained within the blog. Technorati Tags: f5,breach,security,cloud,dns,iot,mobile,2015,silva,empty or full Connect with Peter: Connect with F5:F5 Friday: Should you stay with HTTP/1 or move to HTTP/2 ?
Application experience aficionados take note: you have choices now. No longer are you constrained to just HTTP/1 with a side option of WebSockets or SPDY. HTTP/2 is also an option, one that like its SPDY predecessor brings with it several enticing benefits but is not without obstacles. In fact, it is those obstacles that may hold back adoption according to IDG research, "Making the Journey to HTTP/2". In the research, respondents indicated several potential barriers to adoption including backward compatibility with HTTP/1 and the "low availability" of HTTP/2 services. In what's sure to noticed as a circular dependency, the "low availability" is likely due to the "lack of backward compatibility" barrier. Conversely, the lack of backward compatibility with HTTP/1 is likely to prevent the deployment of HTTP/2 services and cause low availability of HTTP/2 services. Which in turn, well, you get the picture. This is not a phantom barrier. The web was built on HTTP/1 and incompatibility is harder to justify today than it was when we routinely browsed the web and were shut out of cool apps because we were using the "wrong" browser. The level of integration between apps and reliance on many other APIs for functionality pose a difficult problem for would-be adopters of HTTP/2 looking for the improved performance and efficacy of resource utilization it brings. But it doesn't have to. You can have your cake and eat it too, as the saying goes. HTTP Gateways What you want is some thing that sits in between all those users and your apps and speaks their language (protocol) whether it's version 1 or version 2. You want an intermediary that's smart enough to translate SPDY or HTTP/2 to HTTP/1 so you don't have to change your applications to gain the performance and security benefits without investing hundreds of hours in upgrading web infrastructure. What you want is an HTTP Gateway. At this point in the post, you will be unsurprised to learn that F5 provides just such a thing. Try to act surprised, though, it'll make my day. One of the benefits of growing up from a load balancing to an application delivery platform is that you have to be fluent in the languages (protocols) of applications. One of those languages is HTTP, and so it's no surprise that at the heart of F5 services is the ability to support all the various flavors of HTTP available today: HTTP/1, SPDY, HTTP/2 and HTTP/S (whether over TLS or SSL). But more than just speaking the right language is the ability to proxy for the application with the user. Which means that F5 services (like SDAS) sit in between users and apps and can translate across flavors of HTTP. Is your mobile app speaking HTTP/2 or SPDY but your app infrastructure only knows HTTP/1? No problem. F5 can make that connection happen. That's because we're a full proxy, with absolute control over a dual-communication stack that lets us do one thing on the client side while doing another on the server side. We can secure the outside and speak plain-text on the inside. We can transition security protocols, web protocols, and network protocols (think IPv4 - IPv6). That means you can get those performance and resource-utilization benefits without ripping and replacing your entire web application infrastructure. You don't have to reject users because they're not using the right browser protocol and you don't have to worry about losing visibility because of an SSL/TLS requirement. You can learn more about F5's HTTP/2 and SDPY Gateway capabilities by checking out these blogs: What are you waiting for? F5 Synthesis: Your gateway to the future (of HTTP) Velocity 2014 HTTP 2.0 Gateway (feat Parzych) F5 Synthesis Reference Architecture: AccelerationThe Top 10, Top 10 2013 Predictions
Like last year, everyone has their Technology predictions with their annual lists for the coming year. Instead of coming up with my own, I figured I’d simply regurgitate what many others are expecting to happen. Cloud computing in 2013: Two warnings: @DavidLinthicum has his two tragic cloud computing predictions for 2013 (price wars & skills shortage). Nice to see some realism mixed with all the 'this is the greatest.' 10 Cloud Predictions for 2013: CIO has an interesting slide show covering things like Hybrid Cloud, Management, Brokers, SDN, Outages and a few other critical components. RSA's Art Coviello: 8 Computer Security Predictions For 2013: Attacks grow, Hackers grow, business's not prepared grows along with investment, analysis and intelligence to mitigate threats. Security Predictions 2013-2014: Emerging Trends in IT and Security: SANS gets some input from various industry folks on what they think. Areas like authentication, mobile devices, Windows 8, geo-forensics, gamification and others are highlighted Top 6 security predictions for 2013: InformationWeek India lists FortiGuard Labs predictions covering APT, two factor auth, M2M exploits. mobile malware, and botnets. Tech Guru Mark Anderson's Top 10 Predictions For 2013: Forbes' list is cool since it goes beyond just security, cloud and IT. Yes, mobile and hacktivism are covered but also Driverless Cars, eBooks, Net TVs and the LTE vs. Fiber battle. Top predictions, about IT predictions, for 2013: Of course I love the title and this article digs into the question of 'is any real insight uncovered' with these predictions?. Forrester: Networking predictions for 2013: ComputerWeekly shares 4 of Forrester's report on eight critical predictions for 2013. SDN, WLAN, Strategic sourcing and staffing make the list. 7 Predictions for Cloud Computing in 2013 That Make Perfect Sense: Back to Forbes again, this time specific to cloud. Private clouds, personal clouds, community clouds, cloud brokers, and even a prediction that the term 'cloud' starts to fade. 2013 Astrology Predictions: Gotta have a little fun and give you something to look forward to based on your astrological sign. That is, of course, if we make it past Dec 21. Certainly not even close to an exhaustive list of all the various 2013 predictions but a good swath of what some experts believe is coming. OK, and here are just a few of my own: BYOD Matures - instead of managing entire device, only those corporate apps and data will be in control. Mobile Security and BYOD come together. Also, things like cars and TVs that have internet connections will get added to the BYOD realm. Why couldn't a road warrior access his VDI from the car's NAV screen? Why couldn't someone check their email between commercials. Anything with an IP and screen is game. Major Mobile Malware - we've seen some here and there but think there will be a big jump in attempts to get at device's info...especially as more BYOD gets deployed. Cloud Classification (Pub/Pri/Hy) - lines become even more blurry as they all are used to create Hybrid Infrastructures. No one cloud will take over but will be a part of the entire infrastructure which includes in-house, cloud, leased raised floor, and just about any place that data can live. There might also be some movement on Cloud Standards. More Breaches/DoS/Hacktivism - if 2012 is any indication, this will continue. Hacker Defection - I think there will be more ex-malicious hackers going mainstream and joining legit companies - and they will expose some of the tricks of the trade. ps Resources The Top 10, Top Predictions for 2012 Technorati Tags: F5,cyber security,predictions,2013,Pete Silva,security,mobile,vulnerabilities,crime,social media,hacks,cloud,internet,identity theft Connect with Peter: Connect with F5:
Authenticate user of native mobile app with OpenId Connect
Does F5 Big IP Access Manager support mobile apps authenticating over OpenId Connect with custom URI redirect_uri? Our native mobile app (iOS and Android) authenticates the user using the Authorization Code Grant flow. How it Works. Our redirect_uri (ie callback uri) is: com.mckesson.wfm.ansos2go://signin We are a software vendor in the Healthcare domain. Our customer who uses F5 Big IP says that this URI is considered invalid by F5 when configuring the OpenId Connect Service Provider. Is that true? If so, how do native mobile app developers perform OIDC authentication with F5? Thanks, Scott UPDATE: I got word from my customer that they set up a rewrite policy, so they could enter the redirect_uri as https:/com.mckesson.wfm.ansos2go://signin. Then, they strip off the https:// in the response to the initial 'authorize' call. This is NUTS! Why does F5 Big IP Access Manager require redirect_uri to be https://...? This totally breaks the OpenId Connect specification which says "The Redirection URI MAY use an alternate scheme, such as one that is intended to identify a callback into a native application." https://openid.net/specs/openid-connect-core-1_0.html#AuthorizationEndpoint
