F5 Access Policy Manager and Firefox Browser version 43 and 47+
Firefox Browser version 43 has new plug-in signing requirements. F5 will be providing Engineering Hotfixes for BIG-IP versions 12.0.0, 11.6.0, and 11.5.3, which will include a F5 Access Policy Manager plug-in signed by Firefox for Microsoft Windows and Linux platforms. With F5 officially supporting Firefox version 34, this is a “best efforts” approach to alleviate any disruptions brought about by Firefox version 43 and the upcoming Firefox version 44, related to plug-in signing requirements (Feature Enhancement ID:564253). If issues are uncovered with versions of Firefox greater than version 34 after installing the appropriate Engineering Hotfix, it is recommended that users be guided to use Microsoft Internet Explorer on Windows, and Safari on Mac, as detailed in thisDevCentral post. Another option is to use BIG-IP Edge Client for these two platforms. For Linux, there is a CLI client available for network access. These Engineering Hotfix releases are short-term fixes. A more permanent solution will be available in an upcoming release of BIG-IP; specifics will also be available in the aforementioned DevCentral post. We will make the Engineering hotfixes available for customers who create a support case with F5 Support. This Engineering Hotfix should be good for up to Firefox 46 and F5 will need to have Mozilla sign the plug-in again for Firefox 47+. This is just how Firefox plug-in signing works currently. January 7, 2016 Update: While we (F5) is making progress in getting the Engineering hotfixes out, we are currently working through some issues seen with the Mozzilla add-on submission tool. Once that is resolved, then we expect to be able to provide an ETA for the Engineering Hotifxes. F5 is working on this with urgency. January 8, 2016 Update: We (F5) have the issue with the Mozilla add-on tools resolved, so we can provide a target ETA of January 15, 2016 (Friday) to provide Engineering Hotfixes for the 3 versions of BIG-IP we had mentioned on this post. January 14, 2016 Update: We have run into a few issues that need to be addressed so we will need a few more days to have the Engineering Hotfixes available. Again,F5 is working on this with urgency. January 21, 2016 Update: We have an Engineering Hotfix for BIG-IP 11.6.0, based on BIG-IP 11.6.0 Hotfix 6 now. Again to get it, customers should create a support case with F5 Support. We are still planning to provide an Engineering Hotfix forBIG-IP 12.0.0 and 11.5.3 soon. January 25, 2016 Update: We have an Engineering Hotfix for BIG-IP 12.0.0 based on BIG-IP 12.0.0 Hotfix 1 now. Again to get it, customers should create a support case with F5 Support. We are still planning to provide an Engineering Hotfix forBIG-IP 11.5.3 soon. January 26, 2016 Update: We have an Engineering Hotfix for BIG-IP 11.5.3 based on BIG-IP 11.5.3 Hotfix 2. Customers should create a support case with F5 Support. F5 will target to release Engineering Hotfixes before Firefox 47 is available. May 9, 2016 Update: F5 is currently working on Engineering Hotfixes for the various BIG-IP for Firefox 47+ that would work for all Firefox versions (even Firefox 46 and earlier). Mozilla is allowing for plug-in signing for all (*) versions of Firefox again. We do not have the releases ready for customers yet but expect to have it shortly. Once they are available, we will announce it here and also provide it initially to F5 Support and thus customers can get it via a Support ticket. Shortly after it is available via F5 Support, we will provide it on https://downloads.f5.com. May 16, 2016 Update: F5 has Engineering Hotfixes for 11.5.4 HF1 and 11.6.0 HF6 available. These should work with all versions* of Firefox (including Firefox 47 Beta builds). For now, customers should create a support ticket with F5 Support to get the Engineering Hotfixes. We will provide it on https://downloads.f5.com shortly and we are also working on Engineering Hotfixes for12.0.0 HF2 and 11.6.1. May 21, 2016 Update: F5 has Engineering Hotfix for 12.0.0 HF2 available. These should work with all versions* of Firefox (including Firefox 47 Beta builds). For now, customers should create a support ticket with F5 Support to get the Engineering Hotfixes. We will provide it on https://downloads.f5.com shortly and we are also working on Engineering Hotfixes for11.6.1 and 12.1.0. May 31, 2016 Update:F5 has Engineering Hotfix for 11.6.1 available. For now, customers should create a support ticket with F5 Support to get the Engineering Hotfixes. *These Engineering Hotfixes should work on all versions of Firefox, including 47+, until Firefox removes its NPAPI support. To address that we have another DevCentral post: here:https://devcentral.f5.com/s/articles/addressing-security-loopholes-of-third-party-browser-plug-ins
Dyre Malware Analysis
Dyre, also known as Dyreza, is a banking Trojan that was first seen around June 2014. With the combination of its ability to steal login credentials by browser hooking and bypassing SSL, its man-in-the-middle (MITM) proxy server, and its Remote Access Trojan (RAT) capabilities, Dyre has become one of the most dangerous banking Trojans. The Dyre Trojan is designed to steal login credentials by grabbing the whole HTTPS POST packet, which contains the login credentials sent to a server during the authentication process, and forwarding it to its own server. The malware downloads a configuration file containing a list of targeted bank URLs. Each URL is configured to be redirected to Dyre’s MITM proxy server, on a different port for each bank. This allows the attacker to make a MITM attack by forwarding any user request to the bank and returning bogus data, including fake login pages, popup windows, and JavaScript/HTML injections. After all the information has been acquired by the attacker, he can remotely access the victim’s computer using a built-in VNC (Virtual Network Computing) module and perform transactions, data exfiltration, and more. How it works malware downloads a configuration file containing a list of targeted bank URLs. Each URL is configured to be redirected to Dyre’s MITM proxy server, on a different port for each bank. This allows the attacker to make a MITM attack by forwarding any user request to the bank and returning bogus data, including fake login pages, popup Malware behavior on a Win7-32bit system Surprisingly, the malware behaves differently on Win7-32bit, most likely due to security implementation differences. The method of registering itself as a system service is implemented on WinXP and 64bit systems (tested on Win7-64bit). On Win7-32bit, Dyre operates more similarly to the known Zeus malware by injecting code in the Explorer.exe process and operating from there. Man-In-The-Middle (MITM) Attack When a user enters his bank’s URL in the browser line, the Trojan is triggered and forwards the URL to the corresponding proxy server as stated in its configuration file. · The MITM proxy server forwards requests to the banks and disguises itself as the real user. · The returning response from the bank is intercepted by the proxy server. · Instead of the real response, the user receives a fake login page which is stored on the proxy server, and contains scripts and resources from the real bank’s page. The scripts and resources are stored in folders named after the unique port configured for each bank. · The information entered by the user is sent to the proxy server and then forwarded to the real bank server, allowing the attacker to log in instead of the user and perform operations on his behalf. The fake login page The fake page contains a script called main_new - , which is responsible for handling the objects presented to the user on the fake page and performing the MITM attack. The fake page contains an array of configuration parameters in the header. Some of the more interesting ones are: · ID. The unique identification of the bank, which is the same as the port number in the configuration file. · Incorrect login error. On each login attempt to the bank, the proxy server will forward the request to the real bank’s server and perform the authentication. If the authentication fails, it will also present an error to the user on the fake page. · Block message. If the MITM attack succeeds, the attacker is able to perform a transaction and block the user from accessing his account. This parameter stores the presented message. The F5 Solution Real-time identification of affected users - F5 WebSafe and MobileSafe are able to detect the user is affected by a Trojan and that the information provided by it to the customer is also sent to an unauthorized drop zone. Identification of malicious script injection – once downloaded to the client’s browser, WebSafe and MobileSafe make sure there has been no change to the site’s HTML. If such a change is detected, the customer is notified immediately. Protection against Trojan-generated money transfers - the combination of recognizing affected users, encrypting information, and recognizing malicious scripts is key to disabling Trojans from performing unauthorized actions within the account. WebSafe and MobileSafe detect the automatic attempts and intercept them. Malware research - F5 has a dedicated Trojan and malware R&D team that searches for new threats and new versions of existing ones. The team analyzes the programming techniques and methodologies used to develop the malware in order to keep the F5 line of products up to date and effective against any threat. To get the full technical detailed Malware analysis report click here. To download the executive summary, click here.
How is SDN disrupting the way businesses develop technology?
You must have read so much about software-defined networking (SDN) by now that you probably think you know it inside and out. However, such a nascent industry is constantly evolving and there are always new aspects to discover and learn about. While much of the focus on SDN has focused on the technological benefits it brings, potential challenges are beginning to trouble some SDN watchers. While many businesses acknowledge that the benefits of SDN are too big to ignore, there are challenges to overcome, particularly with the cultural changes that it brings. In fact, according to attendees at the Open Networking Summit (ONS) recently the cultural changes required to embrace SDN outweigh the technological challenges. One example, outlined in this TechTarget piece, is that the (metaphorical) wall separating network operators and software developers needs to be torn down; network operators need coding skills and software developers will need to be able to program networking services into their applications. That’s because SDN represents a huge disruption to how organisations develop technology. With SDN, the speed of service provisioning is dramatically increased; provisioning networks becomes like setting up a VM... a few clicks of the button and you’re done. This centralised network provision means the networking element of development is no longer a bottleneck; it’s ready and available right when it’s needed. There’s another element to consider when it comes to SDN, tech development and its culture. Much of what drives software-defined networking is open source, and dealing with that is something many businesses may not have a lot of experience with. Using open source SDN technologies means a company will have to contribute something back to the community - that’s how open source works. But for some that may prove to be a bit of an issue: some SDN users such as banks or telecoms companies may feel protective of their technology and not want is source code to be released to the world. But that is the reality of the open source SDN market, so it is something companies will have to think carefully about. Are the benefits of SDN for tech development worth going down the open source route? That’s a question only the companies themselves can answer. Software-defined networking represents a huge disruption to the way businesses develop technology. It makes things faster, easier and more convenient during the process and from a management and scalability point of view going forward. There will be challenges - there always are when disruption is on the agenda - but if they can be overcome SDN could well usher in a new era of technological development.
Implementing PCoIP Proxy as a Security Server or Access Point Alternative
VMware’s Horizon Security Server and Access Point provides secure access to sessions over an unsecured WAN and/or Internet connection. Typically, the Security Server/Access Point is placed within an organization’s DMZ and proxies connections to internal Horizon desktop and application resources. F5 BIG-IP Access Policy Manager (APM) provides an alternative method for secure access to Horizon desktop and application resources by simplifying your VMware Horizon with View architecture, improving security, and increasing scalability. Harden Security and Increase Scalability F5 BIG-IP Access Policy Manager is the industry’s first Application Delivery Networking solution that brings full PCoIP proxy capabilities—certified by Teradici—to the market. This permits IT administrators to replace the View Security Server with a more secure and highly scalable solution in support of their end-user computing deployments. BIG-IP APM is an ICSA Labs–certified flexible, high-performance access and security solution that provides unified global access to your applications and network. BIG-IP APM converges and consolidates remote access, LAN access, and wireless connections within a single management interface and provides easy-to-manage access policies. These capabilities help you free up valuable IT resources and scale cost-effectively. Simplifying Your Horizon Architecture Because BIG-IP APM removes the pairing dependency between Security Servers and Connection Servers, the overall architecture can not only be simplified, but a higher level of scalability can be achieved. In addition to BIG-IP APM, F5 BIG-IP Local Traffic Manager (LTM) can provide intelligent traffic management and load balancing to the Connection Servers. The reduction in the overall number of components that need to be managed results in increased productivity for IT administrators, which is especially critical for multi-site or multi-pod VMware Horizon deployments. Traffic Flow The diagram outlines the traffic flow of an external Horizon Client connection when using the BIG-IP Access Policy Manager (APM) Module as a Security Server/Access Point alternative: Device connects in from the untrusted network. Connection to APM made over HTTPS using the client or the F5 APM WebTop Portal. User logs in. APM processes the authentication (single/multi-factor) to AD and/or other authentication source (LDAPS/RADIUS, etc.) Once user is validated, APM sends a request to the load balanced pool of Connection Servers to get a list of authorized applications and desktops using HTTPS or HTTP. The user is then presented with the list of available and authorized desktops and applications. User selects the application or desktop to launch. Request then sent from client and proxied to View Connection Server via HTTPS – client receives desktop and/or application source machine info (including the public/client facing IP address if using NAT). Client establishes a connection to the virtual desktop or RDS application server to the APM via PCoIP, or HTML 5 (using HTML Access) using HTTPS . The APM proxies this connection back to the virtual desktop or RDS application server. We've developed a step-by-step guide for implementing PCoIP Proxy, which you can download here. You can also do a walk through of this very setup in the VMware Hands-On-Lab (Look for HOL-MBL-1659) by clicking on the following link - http://labs.hol.vmware.com/HOL/catalogs/lab/2078.Getting Around the Logon/Legal Banner Issues when using APM PCoIP Proxy and Horizon
If you're using APM's PCoIP Proxy and require a logon banner, you've probably figured out that the PCoIP Proxy integration stops working when you turn on the integrated logon banner from within the Horizon Administrator. Adding to the pain, internal users can't get any logon banner since you had to turn it off in order for your external access to work! Well, the wait is over! With the use of a nifty iRule that you can attach to your internal Horizon Connection Servers virtual server, you can now present a banner BOTH internal users as well as external users who access Horizon resources using APM PCoIP Proxy. Here's how it works: Disable the logon banner through Horizon Administrator - the BIG-IP will handle presenting the banners for internal users (through the iRule) and external users (through the View iApp) instead of Horizon. Modify the text in the iRule with the text you want to show in the logon banner. Apply the iRule to your LTM Virtual Server that services internal Horizon users (either manually to the LTM virtual server or through the View iApp). You're done! A couple of things to think about when you implement this: If you need to present a legal disclaimer your external users using the PCoIP Proxy, you can still do that through the Horizon View iApp. Do not apply this to any virtual server running the APM PCoIP Proxy - it's only for providing the logon banner to internal Horizon users. The banner for PCoIP Proxy can be easily enabled through the iApp It's important to ensure the PCoIP Proxy's Connection Server settings are pointing to the individual connection server(s) and NOT the LTM virtual server that has the Logon Banner iRule applied. The iRule source is below. # Attach iRule to iApp created virtual server named "<iapp_name>_internal_https" # Replace the section “This is a XXX computer system that is FOR OFFICIAL USE ONLY. This # system is subject to monitoring. Therefore, no expectation of privacy is to be assumed. # Individuals found performing unauthorized activities are subject to disciplinary action # including criminal prosecution.” with your desired text. when RULE_INIT { # Debug Level 0=off, 1=on, 2=verbose set static::internal_disclaimer_debug 0 } when CLIENT_ACCEPTED { set log_prefix_cs "[IP::remote_addr]:[TCP::remote_port clientside] <-> [IP::local_addr]:[TCP::local_port clientside]" if { $static::internal_disclaimer_debug > 1 } { log local0. "<$log_prefix_cs>: CLIENT_ACCEPTED" } } when HTTP_REQUEST { set bypass 0 if {[HTTP::uri] starts_with "/portal/info.jsp"} { if { $static::internal_disclaimer_debug > 0 } { log local0. "<$log_prefix_cs>: Portal Info request, bypassing further processing"} set bypass 1 } else { if {[HTTP::header exists "Content-Length"]} { set content_length [HTTP::header "Content-Length"] } else { # If the header is missing, use a sufficiently large number set content_length 5000 } if { $static::internal_disclaimer_debug > 1 } { log local0. "<$log_prefix_cs>: Set content-length to $content_length"} HTTP::collect $content_length if { [HTTP::path] == "/broker/xml" && [HTTP::header Expect] == "100-continue" } { SSL::respond "HTTP/1.0 100 Continue\r\n\r\n" if { $static::internal_disclaimer_debug > 1 } { log local0. "<$log_prefix_cs>: Application requested: client requires 100 continue response, sending 100-continue"} } } } when HTTP_REQUEST_DATA { if { [HTTP::payload] contains "set-locale" and ( not ($bypass)) } { HTTP::respond 200 content {<?xml version="1.0"?><broker version="9.0"><configuration><result>ok</result><broker-guid>aaaaaaaa-bbbb-cccc-ddddddddddddddddd</broker-guid><authentication><screen><name>disclaimer</name><params><param><name>text</name><values><value>This is a XXX computer system that is FOR OFFICIAL USE ONLY. This system is subject to monitoring. Therefore, no expectation of privacy is to be assumed. Individuals found performing unauthorized activities are subject to disciplinary action including criminal prosecution.</value></values></param></params></screen></authentication></configuration><set-locale><result>ok</result></set-locale></broker>} noserver "Connection" "close" "Content-Type" "text/xml;charset=UTF-8" if { $static::internal_disclaimer_debug > 1 } { log local0. "<$log_prefix_cs>: Sending Disclaimer Message"} } if { [HTTP::payload] contains "disclaimer" } { if { $static::internal_disclaimer_debug > 1 } { log local0. "<$log_prefix_cs>: Disclaimer Message Accepted - waiting for credentials."} } } This solution has been tested using Horizon 6.0 (and later) as well as the Horizon 3.0 (and later) Client. Earlier versions of the client and/or Horizon Connection Server could produce unexpected results. Big shout-out to Greg Crosby for his work on the iRule!Load Balancing VMware's Workspace Portal/Identity Manager with F5 BIG-IP Local Traffic Manager (LTM)
What is VMware Identity Manager (formerly known as VMware Workspace Portal)? VMware Identity Manager is a service that extends your on-premises directory infrastructure to provide a seamless Single Sign-On (SSO) experience to Web, Mobile, SaaS, and legacy applications. Simply put, it's a service aggregator and identity provider for your IT resources. One single login to Identity Manager gains you access to Citrix XenApp, Horizon, Web, SaaS, and ThinApp resources. You can find more about Identity Manager at https://www.vmware.com/products/identity-manager/. BIG-IP can provide intelligent traffic management, high availability and monitoring through the use of BIG-IP Local Traffic Manager (LTM) and BIG-IP DNS (Global Traffic Management). BIG-IP's Access Policy Manager (APM) can also provide secure access to the apps and resources accessible through the Identity Manager portal as well as the actual Identity Manager portal itself. In this article, we'll focus on building a highly available Identity Manager implementation using BIG-IP LTM. You can download the updated step-by-step load-balancing guide for VMware Workspace Portal/Identity Manager here. What's also cool is you can do a walk through of this very setup in the VMware Hands-On-Lab at VMworld 2015 (Look for HOL-MBL-1659) or by clicking the following link - http://labs.hol.vmware.com/HOL/catalogs/lab/2078. Special thanks to Bryan Salek, Matt Mabis, and Mosa Emamjomeh for helping put this together! Stay tuned for a future post on how to securely access Workspace Portal/Identity Manager using BIG-IP Access Policy Manager (APM), which includes proxying Citrix XenApp, Horizon, and Web Application resources. WorkspaceOne/Identity Manager 2.6 Update: When changing the FQDN of VMware Identity Manager there is an additional (and new) stepthat needs to be done.After changing the FQDN, log back into the Workspace One Admin UI using a local account and clickCatalog --> Settings. Next, selectNew End User Portal UIand clickEnable New Portal UI. Once completed, log out and you should now be able to login using a domain account.
F5 Anti-Fraud Solutions: Frictionless Protection for the Masses
Anti-Fraud Solutions: Why F5? In 2013, F5 Networks grew its security portfolio to include advanced Anti-Fraud services with the acquisition of the Israeli-based security company Versafe. At the RSA Conference in San Francisco this week, we have a section of our F5 booth dedicated to the Anti-Fraud solution where we are talking about the technology, answering questions and demonstrating the capabilities all week. If you cannot make it to the conference or even if you attended but missed us at our booth, that’s not a problem. I’ll fill you in on some of the details. First, just walking around the RSA Conference, it’s clear that there is no shortage of anti-fraud solutions on the market. The number is mind blowing and continuously growing. As new threats emerge, new technologies are introduced to combat them. But if you look at the approaches each company takes, they are often quite different. So that begs the question: why F5? Well, from a feature and function standpoint, we cover a wide range of web-based fraud detection and protection capabilities. The WebSafe solution, which protects web-based applications, safeguards against various forms of malicious activity including phishing attacks, Man-In-The-Middle, Man-In-The-Browser and Trojan activity such as web injections, form hijacking, page modifications and transaction modification. But what makes the solution unique is that it enables 100% coverage of the user base in a completely clientless manner, without impacting the user experience. We inject our obfuscated code via an iRule, into the web application code as part of the response data. In other words, the solution is completely frictionless, which is key differentiator number one. And because the solution leverages common browser-based technologies, we protect users who are navigating from all types of devices: laptops, PCs, tablets, smart TVs, mobile devices, etc. As long as the user is navigating with a standard web browser, they will be protected. This is key differentiator number two. From a deployment standpoint, today the WebSafe solution is implemented via an iRule on an F5 device (either physical or virtual), so there is no need to introduce changes to the web applications our customers are looking to protect from online fraud. This saves time when deploying the solution because there is no need to engage web development resources which are often outsourced or already engaged in critical projects. Our ability to deploy without these web application changes equates to savings and is key value proposition number three. As a matter of fact, many F5 customers can leverage their current F5 investment and deploy the Anti-Fraud services on their existing infrastructure, requiring no additional hardware investment: differentiator number four. Lastly, WebSafe provides protection against online fraud without a client install and with no change in the online users’ experience. Introducing CAPTCHAs, popups, etc is often too intrusive to the end user, so we are looking to protect the users without introducing friction in the process. Summary If you are at the RSA Conference, stop by booth 1801. We would be happy to demonstrate our Anti-Fraud solution and help to enhance your fraud protection capabilities. If you are not at RSA, look for further details here. We will be posting more details about F5’s Anti-Fraud solutions throughout the coming weeks.Managing Horizon Traffic across Multiple Data Centers with BIG-IP DNS
In a typical single data center environment, VMware Horizon virtual desktop clients typically use a fully qualified domain name (FQDN) when accessing desktop and application resources. More and more customers are distributing their Horizon application and desktop infrastructure to distribute across multiple physical/logical data centers. Some of the business and technical reasons may include disaster recovery, system resiliency, and elastic desktop/application capacity. How are these multi-data center implementations of Horizon accessed? One common scenario is to provide a specific domain name to users either based on a user’s geographical location (for example, https://europe.example.com) or a user’s business unit (for example, https://finance.example.com). If the user has an ability to access resources from multiple data centers, the user’s overall experience might be sub-optimal if the end user is not being connected to the most appropriate, optimal data center. By deploying BIG-IP DNS (formerly Global Traffic Manager) with Horizon View, a single namespace (for example, https://desktop.example.com) can be provided to all end users - one URL to remember. BIG-IP DNS and BIG-IP Local Traffic Manager (LTM) also work together to ensure that requests are intelligently routed to a preferred data center, regardless of the user’s current location. In this example, users leverage a single namespace (view-apoc.bd.f5.com). They will initially connect to BIG-IP DNS (GTM). BIG-IP DNS will make a routing decision (based on availability, topology, connection, etc.) and then send the user to a specific data center. The user will then login with the Horizon View client and access their desktop/applications. If a data center is inaccessible, new users are automatically routed to the available data center; existing users will be disconnected and then reconnect to the live data center. Taking advantage of these key BIG-IP modules (BIG-IP DNS and LTM) empowers IT staff to integrate multiple VMware Horizon pods or physical sites for source desktops, all without disrupting users. By enabling users to reconnect to their existing persistent desktop source when required and providing a dynamic and agile infrastructure that can adapt to planned and unplanned events, the BIG-IP system becomes key to successful VMware Horizon deployments. We've developed a step-by-step guide for implementing BIG-IP DNS across two (or more) data centers using BIG-IP DNS and BIG-IP Local Traffic Manager, which you can download here . You can also do a walk through of this very setup in the VMware Hands-On-Lab (Look for HOL-MBL-1659) by clicking on the following link - http://labs.hol.vmware.com/HOL/catalogs/lab/2078.Privacy for a Price
A few weeks ago, I went to my usual haircut place and after the trim at the register I presented my loyalty card. You know the heavy paper ones that either get stamped or hole-punched for each purchase. After a certain number of paid visits, you receive a free haircut. I presented the card, still in the early stages of completion, for validation and the manager said I could convert the partially filled card to their new system. I just had to enter my email address (and some other info) in the little kiosk thingy. I declined saying, 'Ah, no thanks, enough people have my email already and don't need yet another daily digest.' He continued, 'well, we are doing away with the cards and moving all electronic so...' 'That's ok,' I replied, 'I'll pay for that extra/free haircut to keep my name off a mailing list.' This event, of course, got me thinking about human nature and how we will often give up some privacy for either convenience or something free. Imagine a stranger walking up to you and asking for your name, address, email, birthday, income level, favorite color and shopping habits. Most of us would tell them to 'fill in the blank'-off. Yet, when a Brand asks for the same info but includes something in return - free birthday dinner, discounted tickets, coupons, personalized service - we typically spill the beans. Infosys recently conducted a survey which showed that consumers worldwide will certainly share personal information to get better service from their doctors, bank and retailers; yet, they are very sensitive about how they share. Today’s digital consumers are complicated and sometimes suspicious about how institutions use their data, according to the global study of 5,000 digitally savvy consumers. They also created an infographic based on their findings. Overall they found: 82 percent want data mining for fraud protection, will even switch banks for more security; 78 percent more likely to buy from retailers with targeted ads, while only 16 percent will share social profile; 56 percent will share personal and family medical history with doctors ...and specific to retail: To know me is to sell to me: Three quarters of consumers worldwide believe retailers currently miss the mark in targeting them with ads on mobile apps, and 72 percent do not feel that online promotions or emails they receive resonate with their personal interests and needs To really know me is to sell me even more: A wide majority of consumers (78 percent) agree that they would be more likely to purchase from a retailer again if they provided offers targeted to their interests, wants or needs, and 71 percent feel similarly if offered incentives based on location Catch-22 for retailers? While in principle shoppers say they want to receive ads or promotions targeted to their interests, just 16 percent will share social media profile information. Lacking these details could make it difficult for retailers to deliver tailored digital offers Your data is valuable and comes with a price. While many data miners are looking to capitalize on our unique info, you can always decline. Yes, it is still probably already gathered up somewhere else; Yes, you will probably miss out on some free or discounted something; Yes, you will probably see annoying pop-up ads on that free mobile app/game and; Yes, you might feel out of the loop. But, it was still fun to be in some control over my own info leaks. ps Related: Path pledges to be ad-free: Will consumers pay for their privacy? What Would You Pay for Privacy? Paying for privacy: Why it’s time for us to become customers again Consumers Worldwide Will Allow Access To Personal Data For Clear Benefits, Says Infosys Study Engaging with digital consumers: Insights from Infosys survey [Infographic] Parking Ticket Privacy Invasion of Privacy - Mobile App Infographic Style 'Radio Killed the Privacy Star' Music Video? Technorati Tags: privacy,data,big data,mobile,loyalty,consumer,human,information,personal,silva,security,retail,financial Connect with Peter: Connect with F5:
SDN: An architecture for operationalizing networks
As we heard at last week’s Open Networking Summit 2014, managing change and complexity in data centers is becoming increasingly difficult as IT and operations are constantly being pressured to deliver more features, more services, and more applications at ever increasing rates. The solution is to design the network for rapid evolution in a controlled and repeatable manner similar to how modern web applications are deployed. This is happening because it is no longer sufficient for businesses to deliver a consistent set of services to their customers. Instead, the world has become hyper-competitive and it has become necessary to constantly deliver new features to not only capture new customers but to retain existing customers. This new world order poses a significant conflict for the operations side of the business as their charter is to ensure continuity of service and have traditionally used careful (often expensive) planning efforts to ensure continuity of service when changes are needed. The underling problem is that the network is not operationalized and instead changes are accomplished through manual and scripted management. The solution for operations is to move towards architectures that are designed for rapid evolution and away from manual and scripted processes. Software Defined Networking address these challenges by defining a family of architectures for solving these types operational challenges and operations teams are latching on with a rarely seen appetite. The key to the success of SDN architectures is the focus on abstraction of both the control and data planes for the entire network via open APIs (not just the stateless Layer 0-4 portions). The first layer of abstraction allows for a centralized control plane system called an SDN Controller, or just Controller, that understands the entire configuration of the network and programmatically configures the network increasing the velocity and fidelity of configurations by removing humans from configuration loop – humans are still needed to teach the Controller what to do. These Controllers allow for introspection on the configuration and allow for automated deployments. As Controllers mature, I expect them to gain the capabilities of a configuration management system (CMS) allowing for network architects to rapidly revert changes virtually instantaneously. The second layer of abstraction allows for network architects or third parties to programmatically extend the capabilities of a data path element. This can be as seemingly simple as adding a match-and-forward rule to a switch (e.g., OpenFlow) or as seemingly complex as intercepting a fully parsed HTTP request, parsing an XML application object contained within, and then interrogating a database for a forwarding decision (e.g., LineRate and F5) based on the parsed application data. However, realizing the fully operational benefits of SDN architectures requires that the entire network be designed with SDN architectural principles including both the stateless components (e.g., switching, routing, and virtual networking) and the stateful components (e.g., L4 firewalls, L7 application firewalls, and advanced traffic mangement). Early on SDN proponents, as SDN evolved from a university research project, proposed pure stateless Layer 2-3 networking ignoring the complexities of managing modern networks that call for stateful L4-7 services. The trouble with this approach is that every additional operational domain disproportionately increases operational complexities, as the domains need to be “manually” kept in sync. Recognizing this need, major Layer 2-4 vendors, including Cisco, have formed partnerships with F5 and other stateful Layer 4-7 vendors to complement their portfolios. With the goal of helping customers operationalize their networks, I offer the following unifying definition of SDN for discussion: “SDN is a family of architectures (not technologies) for operationalizing networks with reduced operating expenses, reduced risks, and improved time to market by centralizing control into a control plane that programmatically configures and extends all network data path elements and services via open APIs.” Over the next few months I’ll dig deeper into different aspects of SDN – stay tuned!
