Web 2.0

Mobile versus Mobile: An Identity Crisis

Lori MacVittie — Mon, 16 Jan 2012 13:00:00 GMT

#mobileThe expansive options consumers revel in creates an identity crisis for IT that is best resolved via context-aware mobile mediation.

Back in the days of the browser wars, when standards were still largely ignored and the battle for the desktop was highly competitive, developers had to make choices and compromises. They could either write extensive client-side scripts to detect the user’s browser and address the peculiarities of that environment or they could simply ignore them with a disclaimer that “this site (works best when viewed in | was written for) browser X.”

As time went by, developers were able to discontinue this annoying practice as browser features converged and a common, standardized platform emerged upon which all applications were able to be delivered to any popular browser without concern.

Then mobile phones appeared, and the user experience degraded again, this time driven by the relatively feeble processing power of the platform. Small screens aside, the memory and processing power available on a mobile phone was such that – when combined with a constrained networking environment – the delivery of increasingly chunky, graphic heavy, interactive applications to mobile phones was simply a bad idea for both organizations and its visitors.

Developers and web ops returned to the inspection of HTTP headers to determine whether or not a visitor was using a mobile platform, and began writing leaner, more compact interfaces specifically for those platforms.

Enter tablets. Neither desktop nor phone, these admittedly mobile platforms are compact but nearly as powerful as their overweight tethered cousins without sacrificing the mobility of their anorexic form-factor brethren.

COMMON GROUND: MOBILE OPERATING SYSTEM

Tablets are certainly able to take advantage of emerging web application standards such as HTML5 to deliver a full, rich interactive desktop-style experience on a mobile platform, but are rarely offered it. They are by default offered up a mobile experience because of a common element: the operating system. Even if the operating system was masked, still they’ll find out by checking a second, lesser known HTTP header: HTTP_X_WAP_PROFILE. And if not there, then potentially in HTTP_PROFILE.

Unfortunately, this is not necessarily the fault of the developer. There are no standards prescribing what should or should not identity a mobile device, and thus manufacturers are left to their own devices (pun only somewhat intended).

There is no reliable way, today, to identify a mobile device accurately. Developers are left writing complex scripts that strip apart user agents, profile strings and whatever other contextual data they can extract from HTTP headers to determine how best to serve up content.

That often means visitors are served content that is not wholly appropriate for their device. Even if they could, the market is so volatile at this point that it’s a sure bet that a new device will enter soon that requires modification to the application yet again. More code, more string manipulation, more latency in processing.

CONTEXT-AWARE MOBILE MEDIATION

It would be nice if developers could simply receive accurate inbound HTTP headers. Headers that clearly identify the device not only from an operating system perspective, but from a form-factor and network perspective in a standard way. But there are no standards, yet, and may never be. Thus a solution may be found in imposing standards upon inbound requests specifically for developers to better address the disparities in resolution, functionality, and performance between the various mobile device types.

This requires some amount of pre-planning. Design, if you will, or architecture up front. It requires that developers and devops sit down together and determine a standard means of communicating information between infrastructure and the applications it supports. Consider the possibility of two custom HTTP headers, one identifying the network type and one specifying form-factor and device:

HTTP_X_NETWORK = “WIFI | MOBILE | LAN”

HTTP_X_DEVICE = “TABLET | PHONE | DESKTOP”

If developers could rely on these two custom HTTP headers to exist for every inbound request, they could then develop applications based upon these characteristics that were more appropriate for the given device and network over which the device connected. Implementation requires only minimal inspection and insertion on a context-aware mediating device such as a network-side scripting capable application delivery controller.

Because the application delivery controller is topologically positioned in a strategic point of control, it has visibility into the network, client, and server-side environments. This gives it the ability to better interpret and execute policies that govern the delivery of applications to optimize performance and assure availability, but it also provides the ability to extract and share pertinent data with applications and other infrastructure. This data can be shared in a number of ways, including modification of the payload, of the headers, insertion of new headers, removal of old headers, etc…

The flexibility inherent in network-side scripting solutions, particularly those capable of side-band connectivity, allows devops and developers to design and develop a solution that works for them – in their environment.

The advantage to such a solution lies not only in more accurate, actionable data to share with applications, but in its ability to easily be modified without negatively impacting the application. A second advantage is the ability of developers to also take into consideration the network characteristics of the mobile device, data generally not available or, if available, generally inaccurate. A mobile device today may be accessing an application via WiFi or a mobile network, and that piece of information is quite pertinent as the performance and capabilities of each network are quite different and have a significant impact on the end-user experience from a delivery perspective.

Yet this data is not available by default to developers and it cannot reliably be inferred from device type. By leveraging a context-aware mediating solution, however, it becomes possible to share this data with developers such that they are able to take that information into consideration when putting together a response to a given request.

While not a panacea, such a solution certainly provides a more consistent and overall accurate environment in which to deliver applications to the increasingly broad and diverse spectrum of mobile devices.

Connect with Lori:	Connect with F5:

Related blogs & articles:

Technorati Tags: F5,MacVittie,mobile,HTML5,tablet,context-aware,performance,architecture,network-side scripting,iRules,strategic point of control,blog

WILS: WPO versus FEO

Lori MacVittie — Mon, 05 Dec 2011 12:14:00 GMT

Understanding web #acceleration techniques and when to apply them

We’ve already discussed the difference between acceleration and optimization, so now it’s time to quickly dig into the difference between the two major types of acceleration: WPO (Web Performance Optimization) and FEO (Front End Optimization).

The difference is important because each technique is effective at addressing different performance bottlenecks, and obviously applying the wrong solution to the problem will not provide the desired results, i.e. fast, fast, fast web applications.

WPO focuses on content delivery, which means it applies different optimization techniques to counter poorly performing networks and servers. WPO will use various TCP optimizations to redress issues in the network related to TCP connections between the client and the server such as retransmission storms caused by overly congested network conditions. WPO will also apply compression to content to minimize the size and reduce the number of packets that must traverse the network. This is a boon over higher latency and/or lower bandwidth connections in improving transfer speed.

FEO, on the other hand, focuses on content transformation. This requires actually changing the content in some way as a means to improve overall performance. Modifying (often merely adding) cache control headers can dramatically improve performance by forcing the use of caching on infrequently changing content. Similarly, techniques like domain sharding that increase the parallelization of requests can reduce the transfer time for what are increasingly large object sets, resulting in (at least perceived) improvements in performance.

Some FEO solutions further manipulate the actual content of the page, rearranging the objects and elements so as to be optimally retrieved and rendered by the browser being used. As the way in which rendering engines work varies from browser to browser, this can actually have a significant impact on the (at least perceived) performance of a web application. FEO solutions are best for complex web pages with many elements and objects, as these benefit from techniques like caching and domain sharding because the bottleneck is in the number of requests required to retrieve a page as opposed to transfer speed. The use of FEO is a primary means of improving performance to not only mobile clients but especially mobile clients over mobile networks. Elimination of white space and comments (minification), image optimization (removal of EXIF data, for example) is particularly effective at reducing content size and therefore improving performance for mobile clients.

The best solution is, of course, an intelligent acceleration intermediary capable of determining based on context which combination of the two techniques will optimally improve performance, as it is generally true that no single technique will unilaterally improve performance.

Happy Accelerating!

WILS: Write It Like Seth. Seth Godin always gets his point across with brevity and wit. WILS is an ATTEMPT TO BE concise about application delivery TOPICS AND just get straight to the point. NO DILLY DALLYING AROUND.

Connect with Lori:	Connect with F5:

Related blogs & articles:

Technorati Tags: F5,MacVittie,WILS,acceleration,optimization,web application acceleration,performance,FEO,WPO,compression,transformation,application delivery,mobile,blog

F5 Friday: Domain Sharding On-Demand

Lori MacVittie — Fri, 02 Dec 2011 12:19:00 GMT

Domain sharding is a well-known practice to improve application performance – and you can implement automatically without modifying your applications today.

If you’re a web developer, especially one that deals with AJAX or is responsible for page optimization (aka “Make It Faster or Else”), then you’re likely familiar with the technique of domain sharding, if not the specific terminology.

For those who aren’t familiar with the technique (or the term), domain sharding is a well-known practice used to trick browsers into opening many more connections with a server than is allowed by default. This is important for improving page load times in the face of a page containing many objects. Given that the number of objects comprising a page has more than tripled in the past 8 years, now averaging nearly 85 objects per page, this technique is not only useful, it’s often a requirement. Modern browsers like to limit browsers to 8 connections per host, which means just to load one page a browser has to not only make 85 requests over 8 connections, but it must also receive those requests over those same, limited 8 connections. Consider, too, that the browser only downloads 2-6 objects over a single connection at a time, making this process somewhat fraught with peril when it comes to performance. This is generally why bandwidth isn’t a bottleneck for web applications but rather it’s TCP related issues such as round trip time (latency).

Here are the two main points that need to be understood when discussing Bandwidth vs. RTT in regards to page load times:

1.) The average web page has over 50 objects that will need to be downloaded (reference: http://www.websiteoptimization.com/speed/tweak/average-web-page/) to complete page rendering of a single page.

2.) Browsers cannot (generally speaking) request all 50 objects at once. They will request between 2-6 (again, generally speaking) objects at a time, depending on browser configuration.

This means that to receive the objects necessary for an average web page you will have to wait for around 25 Round Trips to occur, maybe even more. Assuming a reasonably low 150ms average RTT, that’s a full 3.75 seconds of page loading time not counting the time to download a single file. That’s just the time it takes for the network communication to happen to and from the server. Here’s where the bandwidth vs. RTT discussion takes a turn decidedly in the favor of RTT.

-- RTT (Round Trip Time): Aka – Why bandwidth doesn’t matter

So the way this is generally addressed is to “shard” the domain – create many imaginary hosts that the browser views as being separate and thus eligible for their own set of connections. This spreads out the object requests and responses over more connections simultaneously, allowing what is effectively parallelization of page loading functions to improve performance.

Obviously this requires some coordination, because every host name needs a DNS entry and then you have to … yeah, modify the application to use those “new” hosts to improve performance. The downside is that you have to modify the application, of course, but also that this results in a static mapping. On the one hand, this can be the perfect time to perform some architectural overhauls and combine domain sharding with creating scalability domains to improve not only performance but scalability (and thus availability). You’ll still be stuck with the problem of tightly-coupled hosts to content, but hey – you’re getting somewhere which is better than nowhere.

Or the better way (this is an F5 Friday so you knew that was coming) would be to leverage a solution capable of automatically sharding domains for you. No mess, no fuss, no modifying the application. All the benefits at one-tenth the work.

DOMAIN SHARDING with BIG-IP WebAccelerator

What BIG-IP WebAccelerator does, automatically, is shard domains by adding a prefix to the FQDN (Fully Qualified Domain Name). The user would initiate a request for “www.example.com” and WebAccelerator would go about its business of requesting it (or pulling objects from the cache, as per its configuration). Before returning the content to the user, however, WebAccelerator then shards the domain, adding prefixes to objects. The browser then does its normal processing and opens the appropriate number of connections to each of the hosts, requesting each of the individual objects. As WebAccelerator receives those requests, it knows to deshard (unshard?) the hosts and make the proper requests to the web or application server, thus insuring that the application understands the requests. This means no changes to the actual application. The only changes necessary are to DNS to ensure the additional hosts are recognized appropriately and to WebAccelerator, to configure domain sharding on-demand.

This technique is useful for improving performance of web applications and is further enhanced with BIG-IP platform technology like OneConnect which multiplexes (and thus reuses) TCP connections to origin servers. This reduces the round trip time between WebAccelerator and the origin servers by keeping connections open, thus eliminating the overhead of TCP connection management. It improves page load time by allowing the browser to request more objects simultaneously.

This particular feature falls into the transformative category of web application acceleration as it transforms content as a means to improve performance. This is also called FEO (Front End Optimization) as opposed to WPO (Web Performance Optimization) which focuses on optimization and acceleration of delivery channels, such as the use of compressing and caching.

Happy Sharding!

Connect with Lori:	Connect with F5:

Related blogs & articles:

Technorati Tags: F5,MacVittie,F5 Friday,acceleration,optimization,BIG-IP,BIG-IP WebAccelerator,domain sharding,AJAX,Web 2.0,blog

HTML5 Web Sockets Changes the Scalability Game

Lori MacVittie — Mon, 07 Nov 2011 12:36:00 GMT

#HTML5 Web Sockets are poised to completely change scalability models … again.

Using Web Sockets instead of XMLHTTPRequest and AJAX polling methods will dramatically reduce the number of connections required by servers and thus has a positive impact on performance. But that reliance on a single connection also changes the scalability game, at least in terms of architecture.

Here comes the (computer) science…

If you aren’t familiar with what is sure to be a disruptive web technology you should be.

Web Sockets, while not broadly in use (it is only a specification, and a non-stable one at that) today is getting a lot of attention based on its core precepts and model.

Web Sockets

Defined in the Communications section of the HTML5 specification, HTML5 Web Sockets represents the next evolution of web communications—a full-duplex, bidirectional communications channel that operates through a single socket over the Web. HTML5 Web Sockets provides a true standard that you can use to build scalable, real-time web applications. In addition, since it provides a socket that is native to the browser, it eliminates many of the problems Comet solutions are prone to. Web Sockets removes the overhead and dramatically reduces complexity.

- HTML5 Web Sockets: A Quantum Leap in Scalability for the Web

So far, so good. The premise upon which the improvements in scalability coming from Web Sockets are based is the elimination of HTTP headers (reduces bandwidth dramatically) and session management overhead that can be incurred by the closing and opening of TCP connections. There’s only one connection required between the client and server over which much smaller data segments can be sent without necessarily requiring a request and a response pair.

That communication pattern is definitely more scalable from a performance perspective, and also has a positive impact of reducing the number of connections per client required on the server. Similar techniques have long been used in application delivery (TCP multiplexing) to achieve the same results – a more scalable application. So far, so good.

Where the scalability model ends up having a significant impact on infrastructure and architectures is the longevity of that single connection:

Unlike regular HTTP traffic, which uses a request/response protocol, WebSocket connections can remain open for a long time.

- How HTML5 Web Sockets Interact With Proxy Servers

This single, persistent connection combined with a lot of, shall we say, interesting commentary on the interaction with intermediate proxies such as load balancers. But ignoring that for the nonce, let’s focus on the “remain open for a long time.”

A given application instance has a limit on the number of concurrent connections it can theoretically and operationally manage before it reaches the threshold at which performance begins to dramatically degrade. That’s the price paid for TCP session management in general by every device and server that manages TCP-based connections.

But Lori, you’re thinking, HTTP 1.1 connections are persistent, too. In fact, you don’t even have to tell an HTTP 1.1 server to keep-alive the connection! This really isn’t a big change.

Whoa there hoss, yes it is. While you’d be right in that HTTP connections are also persistent, they generally have very short connection timeout settings. For example, the default connection timeout for Apache 2.0 is 15 seconds and for Apache 2.2 a mere 5 seconds. A well-tuned web server, in fact, will have thresholds that closely match the interaction patterns of the application it is hosting. This is because it’s a recognized truism that long and often idle connections tie up server processes or threads that negatively impact overall capacity and performance. Thus the introduction of connections that remain open for a long time changes the capacity of the server and introduces potential performance issues when that same server is also tasked with managing other short-lived, connection-oriented requests.

Why this Changes the Game…

One of the most common inhibitors of scale and high-performance for web applications today is the deployment of both near-real-time communication functions (AJAX) and traditional web content functions on the same server.

That’s because web servers do not support a per-application HTTP profile. That is to say, the configuration for a web server is global; every communication exchange uses the same configuration values such as connection timeouts. That means configuring the web server for exchanges that would benefit from a longer time out end up with a lot of hanging connections doing absolutely nothing because they were used to grab standard dynamic or static content and then ignored. Conversely, configuring for quick bursts of requests necessarily sets timeout values too low for near or real-time exchanges and can cause performance issues as a client continually opens and re-opens connections. Remember, an idle connection is a drain on resources that directly impacts the performance and capacity of applications. So it’s a Very Bad Thing™.

One of the solutions to this somewhat frustrating conundrum, made more feasible by the advent of cloud computing and virtualization, is to deploy specialized servers in a scalability domain-based architecture using infrastructure scalability patterns. Another approach to ensuring scalability is to offload responsibility for performance and connection management to an appropriately capable intermediary.

Now, one would hope that a web server implementing support for both HTTP and Web Sockets would support separately configurable values for communication settings on at least the protocol level. Today there are very few web servers that support both HTTP and Web Sockets. It’s a nascent and still evolving standard so many of the servers are “pure” Web Sockets servers, many implemented in familiar scripting languages like PHP and Python. Which means two separate sets of servers that must be managed and scaled. Which should sound a lot like … specialized servers in a scalability domain-based architecture.

The more things change, the more they stay the same.

The second impact on scalability architectures centers on the premise that Web Sockets keep one connection open over which message bits can be exchanged. This ties up resources, but it also requires that clients maintain a connection to a specific server instance.

This means infrastructure (like load balancers and web/application servers) will need to support persistence (not the same as persistent, you can read about the difference here if you’re so inclined). That’s because once connected to a Web Socket service the performance benefits are only realized if you stay connected to that same service. If you don’t and end up opening a second (or Heaven-forbid a third or more) connection, the first connection may remain open until it times out. Given that the premise of the Web Socket is to stay open – even through potentially longer idle intervals – it may remain open, with no client, until the configured time out. That means completely useless resources tied up by … nothing. Persistence-based load balancing is a common feature of next-generation load balancers (application delivery controllers) and even most cloud-based load balancing services. It is also commonly implemented in application server clustering offerings, where you’ll find it called server-affinity. It is worth noting that persistence-based load balancing is not without its own set of gotchas when it comes to performance and capacity.

THE ANSWER: ARCHITECTURE

The reason that these two ramifications of Web Sockets impacts the scalability game is it requires an broader architectural approach to scalability. It can’t necessarily be achieved simply by duplicating services and distributing the load across them. Persistence requires collaboration with the load distribution mechanism and there are protocol-based security constraints with respect to incorporating even intra-domain content in a single page/application. While these security constraints are addressable through configuration, the same caveats with regards to the lack of granularity in configuration at the infrastructure (web/application server) layer must be made. Careful consideration of what may be accidentally allowed and/or disallowed is necessary to prevent unintended consequences. And that’s not even starting to consider the potential use of Web Sockets as an attack vector, particularly in the realm of DDoS. The long-lived nature of a Web Socket connection is bound to be exploited at some point in the future, which will engender another round of evaluating how to best address application-layer DDoS attacks.

A service-focused, distributed (and collaborative) approach to scalability is likely to garner the highest levels of success when employing Web Socket-based functionality within a broader web application, as opposed to the popular cookie-cutter cloning approach made exceedingly easy by virtualization.

Connect with Lori:	Connect with F5:

Related blogs & articles:

Technorati Tags: F5,MacVittie,HTML5,Web Sockets,architecture,scalability,TCP,devops,performance,security

Infrastructure Architecture: Whitelisting with JSON and API Keys

Lori MacVittie — Wed, 12 Oct 2011 11:31:00 GMT

Application delivery infrastructure can be a valuable partner in architecting solutions ….

AJAX and JSON have changed the way in which we architect applications, especially with respect to their ascendancy to rule the realm of integration, i.e. the API. Policies are generally focused on the URI, which has effectively become the exposed interface to any given application function. It’s REST-ful, it’s service-oriented, and it works well.

Because we’ve taken to leveraging the URI as a basic building block, as the entry-point into an application, it affords the opportunity to optimize architectures and make more efficient the use of compute power available for processing. This is an increasingly important point, as capacity has become a focal point around which cost and efficiency is measured. By offloading functions to other systems when possible, we are able to increase the useful processing capacity of an given application instance and ensure a higher ratio of valuable processing to resources is achieved.

The ability of application delivery infrastructure to intercept, inspect, and manipulate the exchange of data between client and server should not be underestimated. A full-proxy based infrastructure component can provide valuable services to the application architect that can enhance the performance and reliability of applications while abstracting functionality in a way that alleviates the need to modify applications to support new initiatives.

AN EXAMPLE

Consider, for example, a business requirement specifying that only certain authorized partners (in the integration sense) are allowed to retrieve certain dynamic content via an exposed application API. There are myriad ways in which such a requirement could be implemented, including requiring authentication and subsequent tokens to authorize access – likely the most common means of providing such access management in conjunction with an API. Most of these options require several steps, however, and interaction directly with the application to examine credentials and determine authorization to requested resources. This consumes valuable compute that could otherwise be used to serve requests.

An alternative approach would be to provide authorized consumers with a more standards-based method of access that includes, in the request, the very means by which authorization can be determined. Taking a lesson from the credit card industry, for example, an algorithm can be used to determine the validity of a particular customer ID or authorization token. An API key, if you will, that is not stored in a database (and thus requires a lookup) but rather is algorithmic and therefore able to be verified as valid without needing a specific lookup at run-time. Assuming such a token or API key were embedded in the URI, the application delivery service can then extract the key, verify its authenticity using an algorithm, and subsequently allow or deny access based on the result.

This architecture is based on the premise that the application delivery service is capable of responding with the appropriate JSON in the event that the API key is determined to be invalid. Such a service must therefore be network-side scripting capable. Assuming such a platform exists, one can easily implement this architecture and enjoy the improved capacity and resulting performance boost from the offload of authorization and access management functions to the infrastructure.

1. A request is received by the application delivery service.

2. The application delivery service extracts the API key from the URI and determines validity.

3. If the API key is not legitimate, a JSON-encoded response is returned.

4. If the API key is valid, the request is passed on to the appropriate web/application server for processing.

Such an approach can also be used to enable or disable functionality within an application, including live-streams. Assume a site that serves up streaming content, but only to authorized (registered) users. When requests for that content arrive, the application delivery service can dynamically determine, using an embedded key or some portion of the URI, whether to serve up the content or not. If it deems the request invalid, it can return a JSON response that effectively “turns off” the streaming content, thereby eliminating the ability of non-registered (or non-paying) customers to access live content.

Such an approach could also be useful in the event of a service failure; if content is not available, the application delivery service can easily turn off and/or respond to the request, providing feedback to the user that is valuable in reducing their frustration with AJAX-enabled sites that too often simply “stop working” without any kind of feedback or message to the end user.

The application delivery service could, of course, perform other actions based on the in/validity of the request, such as directing the request be fulfilled by a service generating older or non-dynamic streaming content, using its ability to perform application level routing.

The possibilities are quite extensive and implementation depends entirely on goals and requirements to be met.

Such features become more appealing when they are, through their capabilities, able to intelligently make use of resources in various locations. Cloud-hosted services may be more or less desirable for use in an application, and thus leveraging application delivery services to either enable or reduce the traffic sent to such services may be financially and operationally beneficial.

ARCHITECTURE is KEY

The core principle to remember here is that ultimately infrastructure architecture plays (or can and should play) a vital role in designing and deploying applications today. With the increasing interest and use of cloud computing and APIs, it is rapidly becoming necessary to leverage resources and services external to the application as a means to rapidly deploy new functionality and support for new features. The abstraction offered by application delivery services provides an effective, cross-site and cross-application means of enabling what were once application-only services within the infrastructure. This abstraction and service-oriented approach reduces the burden on the application as well as its developers.

The application delivery service is almost always the first service in the oft-times lengthy chain of services required to respond to a client’s request. Leveraging its capabilities to inspect and manipulate as well as route and respond to those requests allows architects to formulate new strategies and ways to provide their own services, as well as leveraging existing and integrated resources for maximum efficiency, with minimal effort.

Connect with Lori:	Connect with F5:

Related blogs & articles:

Technorati Tags: F5,MacVittie,JSON,HTTP,architecture,integration,application delivery,cloud computing,devops,network-side scripting,dynamic infrastructure

Et Tu, Browser?

Lori MacVittie — Mon, 26 Sep 2011 12:59:00 GMT

Friends, foes, Internet-denizens … lend me your browser.

Were you involved in any of the DDoS attacks that occurred over the past twelve months? Was your mom? Sister? Brother? Grandfather?

Can you even answer that question with any degree of certainty?

Reality is that the reason for attack on the web is subtly shifting to theft not necessarily of data, but of resources. While the goal may still be to obtain personal credentials for monetary gain, it is far more profitable to rip hundreds or thousands of credentials from a single source than merely getting one at a time. From a miscreant’s point of view, the return on investment is simply much higher targeting a site than it is targeting you, directly.

But that doesn’t mean you’re off the hook. In fact, quite the opposite. For there are other just as nefarious purposes to which your resources can be directed, including inadvertently participating in a grand-scale DDoS attack for what is now-a-days called “hactivism.”

In both cases, you are still a victim, but you may not be aware of it as the goal is to stealth-install the means by which your compute resources can be harnessed to perpetrate an attack and it may not be caught by the security you have in place (you do have some in place, right?). You can’t necessarily count on immunity from infection because you only visit “safe sites”.

That’s because one of the ways in which attackers leverage your compute resources is not through installation of adware or other malware, but directly through JavaScript loaded via infected sites. At issue is the possible collision between web application and browser security.

attackers are recommending to develop a system by which people are lured to some other content, such as SPAM SPAM SPAM !!!graphy, but by visiting the website would invisibly launch the DDOS JavaScript tool. -- Researchers say: DDoS "Low Orbit Ion Cannon" attackers could be easily traced

Now consider the number of serious vulnerabilities reported by WhiteHat Security during the Fall of 2010. Consider the rate across Social Networking sites. Assume an attacker managed to exploit one of those vulnerabilities and plant the DDoS JavaScript tool such that unsuspecting visitors end up playing a role in a DDoS attack.

It gets worse, as far as the potential impact goes. The recent revelation of a new SSL/TLS vulnerability (BEAST) includes a pre-condition that JavaScript be injected into the browser. CSRF (Cross-Site Request Forgery) is a fairly common method of managing such a trick, and is listed by WhiteHat in the aforementioned report as having increased to 24% of all vulnerabilities. So, too, is XSS (Cross-Site Scripting) which ranks even higher in WhiteHat’s list, tying “information leakage” for the number one spot at 64%.

In order to execute their attack, Rizzo and Duong use BEAST (Browser Exploit Against SSL/TLS) against a victim who is on a network on which they have a man-in-the-middle position. Once a victim visits a high-value site, such as PayPal, that uses TLS 1.0, and logs in and receives a cookie, they inject the client-side BEAST code into the victim's browser. This can be done through the use of an iframe ad or just loading the BEAST JavaScript into the victim's browser. -- New Attack Breaks Confidentiality Model of SSL, Allows Theft of Encrypted Cookies

Such an attack is designed to steal high-value data such as might be stored in an encrypted cookie used to conduct transactions with Paypal or an online banking service.

Depending on the level of protection at the web application layer, the delivery of such JavaScript may go completely unnoticed. Most web application security focuses on verifying user input, not application responses, are free from infection. And too many consumers believe running anti-virus scanning solutions are enough to detect and prevent infection in general, not realizing that a dynamically injected JavaScript (something many sites do all the time for monitoring performance and to enable real-time interaction) may, in fact, be “malicious” or at the very least an attempt at resource theft.

How do you stop a browser that essentially stabs you in the back by accepting, without question, questionable content?

Without layering additional security on the browser that parses through each and every piece of content delivered, there isn’t a whole lot you can do – other than turn off the ability to execute JavaScript which, today, essentially renders the Internet useless.

GO to the SOURCE

If we look at the source of browser infections we invariably find the only viable, reasonable, effective answer is to eliminate the source. When you have a pandemic you figure out what’s causing it and you go to the source. Yes, you treat the symptoms of the victims if possible, but what you want to really do is locate and whack the source so it stops spreading.

In “Perceptions about Network Security” (Ponemon Institute, June 2011) surveys show that the top three sources of a breach were insider abuse (52%), malicious software download (48%), and malware from a website (43%). Interestingly, 29% indicated the breach resulted from malicious content coming from a “social networking site”, which would – when added to the malware from a website (of which social networking sites are certainly a type) that source tops the chart with 72% of all causes of breaches being a direct result of the failure of a website to secure itself, and essentially allow itself to become a carrier of an outbreak.

Certainly if you have control over the desktops, laptops, and mobile devices from which a client will interact with your web site or network and you have the capability to deploy policies on those clients that can aid in securing and protecting that client, you should. But that capability is rapidly dwindling with the introduction of a vast host of clients with wildly different OS footprints and the incompatibility of client-side, OS specific agents and apps capable of supporting a holistic client-side security strategy.

Enforcing policies regarding interaction with corporate resources is really your best and most complete option. Like a DDoS attack, you are unlikely to be able to stop the infection of a client. You can, however, stop the spread and possible infection of your corporate resources as a carrier. The more organizations that attend to their own house’s security and protection, the better off end-users will likely be. Reducing the sources of the pandemic of client-side infections will reduce the risk not only to your own organization and users, but to others. And if we can all reduce the potential sources down to sites relying on user’s specifically visiting an infected site, the client-side mechanisms in place to protect users against known malware distribution sites will get us further to a safer and more enjoyable Internet.

Connect with Lori:	Connect with F5:

Related blogs & articles:

Technorati Tags: F5,MacVittie,security,web application security,browser,malware,Ponemon,client,mobile

The Real News is Not that Facebook Serves Up 1 Trillion Pages a Month…

Lori MacVittie — Wed, 21 Sep 2011 13:14:00 GMT

It’s how much load that really generates and how it scales to meet the challenge.

There’s some amount of debate whether Facebook really crossed over the one trillion page view per month threshold. While one report says it did, another respected firm says it did not; that its monthly page views are a mere 467 billion per month.

In the big scheme of things, the discrepancy is somewhat irrelevant, as neither show the true load on Facebook’s infrastructure – which is far more impressive a set of numbers than its externally measured “page view” metric. Mashable reported in “Facebook Surpasses 1 Trillion Pageviews per Month” that the social networking giant saw “approximately 870 million unique visitors in June and 860 million in July” and followed up with some per visitor statistics, indicating “each visitor averaged approximately 1,160 page views in July and 40 per visit — enormous by any standard. Time spent on the site was around 25 minutes per user.”

From an architectural standpoint it’s not just about the page views. It’s about requests and responses, many of which occur under the radar from metrics and measurements typically gathered by external services like Google. Much of Facebook’s interactive features are powered by AJAX, which is hidden “in” the page and thus obscured from external view and a “page view” doesn’t necessarily include a count of all the external objects (scripts, images, etc…) that comprises a “page”. So while 1 trillion (or 467 billion, whichever you prefer) is impressive, consider that this is likely only a fraction of the actual requests and responses handled by Facebook’s massive infrastructure on any given day.

Let’s examine what the actual requests and responses might mean in terms of load on Facebook’s infrastructure, shall we?

SOME QUICK MATH

Loading up Facebook yields 125 requests to load various scripts, images, and content. That’s a “page view”. Sitting on the page for a few minutes and watching Firebug’s console, you’ll note a request to update content occurs approximately every minute you are on a page. If we do the math – based on approximate page views per visitor, each of which incurs 125 GET requests – we can math that up to an approximation of 19,468 RPS (Requests per Second).

That’s only an approximation, mind you, and doesn’t take into consideration the time factor, which also incurs AJAX-based requests to update content occurring on a fairly regular basis. These also add to the overall load on Facebook’s massive infrastructure. And that’s before we start considering the impact from “unseen” integrated traffic via Facebook’s API which, according to the most recently available data (2009) was adding 5 billion requests a day to that load. If you’re wondering, that’s an additional 57,870 requests per second, which gives us a more complete number of 77,338 requests per second.

SOURCE: 2009 Interop F5 Keynote

Let’s take a moment to digest that, because that’s a lot of load on a site – and I’m sure it still isn’t taking into consideration everything. We also have to remember that the load at any given time could be higher – or lower – based on usage patterns. Averaging totals over a month and distilling down to a per second average is just that – a mathematical average. It doesn’t take into consideration that peaks and valleys occur in usage throughout the day and that Facebook may be averaging only a fraction of that load with spikes two and three times as high throughout the day.

That realization should be a bit sobering, as we’ve seen recent DDoS attacks that have crippled and even toppled sites with less traffic than Facebook handles in any given minute of the day.

The question is, how do they do it? How do they manage to keep the service up and available despite the overwhelming load and certainty of traffic spikes?

IT’S the ARCHITECTURE

Facebook itself does a great job of discussing exactly how it manages to sustain such load over time while simultaneously managing growth, and its secret generally revolves around architectural choices. Not just the “Facebook” application architecture, but its use of infrastructure architecture as well. That may not always be apparent from Facebook’s engineering blog, which generally focuses on application and software architecture topics, but it is inherent in those architectural decisions.

Take, for example, an engineer’s discussion on Facebook’s secrets to scaling to over 500 million users and beyond. The very first point made is to “scale horizontally”.

This isn't at all novel but it's really important. If something is increasing exponentially, the only sensible way to deal with it is to get it spread across arbitrarily many machines. Remember, there are only three numbers in computer science: 0, 1, and n. (Scaling Facebook to 500 Million Users and Beyond (Facebook Engineering Blog))

Horizontal scalability is, of course, enabled via load balancing which generally (but not always) implies infrastructure components that are critical to an overall growth and scalability strategy. The abstraction afforded by the use of load balancing services also has the added benefit of enabling agile operations as it becomes cost and time effective to add and remove (provision and decommission) compute resources as a means to meet scaling challenges on-demand, which is a key component of cloud computing models.

In other words, in addition to Facebook’s attention to application architecture as a means to enable scalability, it also takes advantage of infrastructure components providing load balancing services to ensure that its massive load is distributed not just geographically but efficiently across its various clusters of application functionality. It’s a collaborative architecture that spans infrastructure and application tiers, taking advantage of the speed and scalability benefits afforded by both approaches simultaneously.

Yet Facebook is not shy about revealing its use of infrastructure as a means to scale and implement its architecture; you just have to dig around to find it. Consider as an example of a collaborative architecture the solution to some of the challenges Facebook has faced trying to scale out its database, particularly in the area of synchronization across data centers. This is a typical enterprise challenge made even more difficult by Facebook’s decision to separate “write” databases from “read” to enhance the scalability of its application architecture. The solution is found in something Facebook engineers call “Page Routing” but most of us in the industry call “Layer 7 Switching” or “Application Switching”:

The problem thus boiled down to, when a user makes a request for a page, how do we decide if it is "safe" to send to Virginia or if it must be routed to California?

This question turned out to have a relatively straightforward answer. One of the first servers a user request to Facebook hits is called a Load balancer; this machine's primary responsibility is picking a web server to handle the request but it also serves a number of other purposes: protecting against denial of service attacks and multiplexing user connections to name a few. This load balancer has the capability to run in Layer 7 mode where it can examine the URI a user is requesting and make routing decisions based on that information. This feature meant it was easy to tell the load balancer about our "safe" pages and it could decide whether to send the request to Virginia or California based on the page name and the user's location. (Scaling Out (Facebook Engineering Blog))

That’s the hallmark of the modern, agile data center and the core of cloud computing models: collaborative, dynamic infrastructure and applications leveraging technology to enable a cost-efficient, scalable architectures able to maintain growth along with the business.

SCALABILITY TODAY REQUIRES a COMPREHENSIVE ARCHITECTURAL STRATEGY

Today’s architectures – both application and infrastructure – are growing necessarily complex to meet the explosive growth of a variety of media and consumers. Applications alone cannot scale themselves out – there simply aren’t physical machines large enough to support the massive number of users and load on applications created by the nearly insatiable demand consumers have for online games, shopping, interaction, and news. Modern applications must be deployed and delivered collaboratively with infrastructure if they are to scale and support growth in an operationally and financially efficient manner.

Facebook’s ability to grow and scale along with demand is enabled by its holistic, architectural approach that leverages both modern application scalability patterns as well as infrastructure scalability patterns. Together, infrastructure and applications are enabling the social networking giant to continue to grow steadily with very few hiccups along the way. Its approach is one that is well-suited for any organization wishing to scale efficiently over time with the least amount of disruption and with the speed of deployment required of today’s demanding business environments.

Connect with Lori:	Connect with F5:

Related blogs & articles:

Technorati Tags: F5,MacVittie,Facebook,architecture,scalability,Page Routing,Layer 7 Switching,application delivery,VIPRION,dynamic infrastructure

Who Took the Cookie from the Cookie Jar … and Did They Have Proper Consent?

Lori MacVittie — Wed, 14 Sep 2011 10:04:10 GMT

Cookies as a service enabled via infrastructure services provide an opportunity to improve your operational posture.

Fellow DevCentral blogger Robert Haynes posted a great look at a UK law regarding cookies. Back in May a new law went info effect regarding “how cookies and other “cookie-like” objects are stored on users’ devices.” If you haven’t heard about it, don’t panic – there’s a one-year grace period before enforcement begins and those £500 000 fines are being handed out. The clock is ticking, however.

What do the new regulations say? Well essentially whereas cookies could be stored with what I, as a non-lawyer, would term implied consent, i.e. the cookies you set are listed along with their purpose and how to opt out in some interminable privacy policy on your site, you are now going to have to obtain a more active and informed consent to store cookies on a user’s device.

-- The UK Cookie Law – <place your own bad pun here>

Robert goes on to explain that the solution to this problem requires (1) capturing cookies and (2) implementing some mechanism to allow users to grant consent. Mind you, this is not a trivial task. There are logic considerations – not all cookies are set at the same time – as well as logistical issues – how do you present a request for consent? Once consent is granted, where do you store that? In a cookie? That you must gain consent to store? Infinite loops are never good. And of course, what do you if consent is not granted, but the application depends on that cookie existing?

To top it all off, the process of gathering consent requires modification to application behavior, which means new code, testing and eventually deployment.

Infrastructure services may present an alternative approach that is less disruptive technologically, but does not necessarily address the business or logic ramifications resulting from such a change.

COOKIES as a SERVICE

Cookies as a Service, a.k.a. cookie gateways, wherein cookie authorization and management is handled by an intermediate proxy, is likely best able to mitigate the expense and time associated with modifying applications to meet the new UK regulation. As Robert describes, he’s currently working on a network-side scripting solution to meet the UK requirements that leverages a full-proxy architecture’s ability to mediate for applications and communicate directly with clients before passing requests on to the application.

Not only is this a valid approach to managing privacy regulations, it’s also a good means of providing additional security against attacks that leverage cookies either directly or indirectly. Cross-site scripting, browser vulnerabilities and other attacks that bypass the same origin policy of modern web browsers – sometimes by design to circumvent restrictions on integration methods – as well as piggy-backing on existing cookies as a means to gain unauthorized access to applications are all potential dangerous of cookies. By leveraging encryption of cookies in conjunction with transport layer security, i.e. SSL, organizations can better protect both users and applications from unintended security consequences.

Implementing a cookie gateway should make complying with regulations like the new UK policy a less odious task. By centralizing cookie management on an intermediate device, they can be easily collected and displayed along with the appropriate opt-out / consent policies without consuming application resources or requiring every application to be modified to include the functionality to do so.

AN INFRASTRUCTURE SERVICE

This is one of the (many) ways in which an infrastructure service hosted in “the network” can provide value to both application developers and business stakeholders. Such a reusable infrastructure-hosted service can be leveraged to provide services to all applications and users simultaneously, dramatically reducing the time and effort required to support such a new initiative. Reusing an infrastructure service also reduces the possibility of human error during the application modification, which can drag out the deployment lifecycle and delay time to market. In the case of meeting the requirements of the new UK regulations, that delay could become costly.

According to a poll of CIOs regarding their budgets for 2010, The Society for Information Management found that “Approximately 69% of IT spending in 2010 will be allocated to existing systems, while about 31% will be spent on building and buying new systems. This ratio remains largely the same compared to this year's numbers.” If we are to be more responsive to new business initiatives and flip that ratio such that we are spending less on maintaining existing systems and more on developing new systems and methods of management (i.e. cloud computing ) we need to leverage strategic points of control within the network to provide services that minimize resources, time and money on existing systems. Infrastructure services such as cookie gateways provide the opportunity to enhance security, comply with regulations and eliminate costs in application development that can be reallocated to new initiatives and projects.

We need to start treating the network and its unique capabilities as assets to be leveraged and services to be enabled instead of a fat, dumb pipe.

Connect with Lori:	Connect with F5:

Related blogs & articles:

Technorati Tags: F5,MacVittie,security,web application security,compliance,regulation,cookie,cookie gateway,encryption,dynamic infrastructure,UK,network-side scripting

F5 Friday: Zero-Day Apache Exploit? Zero-Problem

Lori MacVittie — Fri, 26 Aug 2011 15:21:32 GMT

#infosec A recently discovered 0-day Apache exploit is no problem for BIG-IP. Here’s a couple of different options using F5 solutions to secure your site against it.

It’s called “Apache Killer” and it’s yet another example of exploiting not a vulnerability, but a protocol’s behavior.

UPDATE (8/26/2011) We're hearing that other Range-* HTTP headers are also vulnerable. Take care to secure against these potential attack vectors as well!

In this case, the target is Apache and the “vulnerability” is in the way multiple ranges are handled by the Apache HTTPD server. The RANGE HTTP header is used to request one or more sub-ranges of the response, instead of the entire response entity. Ranges are sometimes used by thin clients (an example given was an eReader) that are memory constrained and may want to display just portions of the web page. Generally speaking, multiple byte ranges are not used very often.

RFC 2616 Section 14.35.2 (Range retrieval request) explains:

HTTP retrieval requests using conditional or unconditional GET methods MAY request one or more sub-ranges of the entity, instead of the entire entity, using the Range request header, which applies to the entity returned as the result of the request:
      Range = "Range" ":" ranges-specifier
A server MAY ignore the Range header. However, HTTP/1.1 origin servers and intermediate caches ought to support byte ranges when possible, since Range supports efficient recovery from partially failed transfers, and supports efficient partial retrieval of large entities.

The attack is simple. It’s a simple HTTP request with lots – and lots – of ranges. While this example uses the HEAD method, it can also be used with a GET.

  HEAD / HTTP/1.1 Host:xxxx  Range:bytes=0-,5-1,5-2,5-3,…

According to researchers testing the vulnerability, a successful attack requires a “modest” number of requests.

BIG-IP SOLUTIONS

There are several options to prevent this attack using BIG-IP solutions.

HEADER SANITIZATION

First, you can modify the HTTP profile to simply remove the Range header. HTTP header removal – and replacement – is a common means of manipulating request and response headers as a means to “fix” broken applications, clients, or enable other functionality. This is a form of header sanitization, used typically to remove non-compliant header values that may or may not be malicious, but are undesirable. The Apache suggestion is to remove any Range header with 5 or more values.

Note that this could itself break clients whose functionality expects a specific data set as specified by the RANGE header. As it is a rarely used header it is unlikely to impact clients adversely, but caution is always advised. Collaborate with developers and understand the implications before arbitrarily removing HTTP headers that may be necessary to application functionality.

HEADER VALUE SCRUBBING

You can also use an iRule to scrub the headers. By inspecting and thus detecting large numbers of ranges in the RANGE header, you can subsequently handle the request based on your specific needs. Possible reactions include removal of the header, rejection of the request, redirection to a honey pot, or replacement of the header.

Sample iRule code (always test before deploying into production!)

when HTTP_REQUEST {

    # remove Range requests for CVE-2011-3192 if more than 5 ranges are requested

    if { [HTTP::header "Range"] matches_regex {bytes=(([0-9\- ])+,){5,}} } {

        HTTP::header remove Range

    }

}

Again, changing an HTTP header may have negative consequences on the functionality of the application and/or client, so tread carefully.

BIG-IP ASM ATTACK SIGNATURE

Another method of mitigation using BIG-IP solutions is to use a BIG-IP Application Security Manager (ASM) attack signature to detect and act upon an attack using this technique. The signature to add looks like:

pcre:"/Range:[\t ]*bytes=(([0-9\- ])+,){5,}/Hi";

It is important to be aware of this exploit and how it works, as it is likely that once it is widely mitigated, attacks will begin (if they already are not) to explore the ways in which this header can be exploited. There are multiple “range” style headers, any of which may be vulnerable to similar exploitation, so it may be time to consider your current security strategy and determine whether the field of potential exploitable headers is such that a more negative approach (default deny unless specifically allowed) may be required to secure against future DoS attacks targeting HTTP headers.

There are also alternative solutions available already, including this writeup from SpiderLabs with a link to an OWASP mod_security rule file for mitigations.

Stay safe out there!

Connect with Lori:	Connect with F5:

Related blogs & articles:

Technorati Tags: F5,F5 Friday,MacVittie,Apache,exploit,Range,HTTP,security,web application firewall,BIG-IP ASM,iRules

F5 Friday: If Only the Odds of a Security Breach were the Same as Being Hit by Lightning

Lori MacVittie — Fri, 19 Aug 2011 10:43:48 GMT

#v11 AJAX, JSON and an ever increasing web application spread increase the odds of succumbing to a breach. BIG-IP ASM v11 reduces those odds, making it more likely you’ll win at the security table

When we use analogy often enough it becomes pervasive, to the point of becoming an idiom. One such idiom is the expression of unlikelihood of an event by comparing it to being hit by lightning. The irony is that the odds of being hit by lightning are actually fairly significant – about 1:576,000. Too many organizations view their risk of a breach as bring akin to being hit by lightning because they’re small, or don’t have a global presence or what have you. The emergence years ago of “mass” web attacks rendered – or should have rendered - such arguments ineffective. Given the increasing number of web transactions on the Internet and the success of web-based attacks to enact a breach, even comparing the risk to the odds of being hit by lightning does little but prove that eventually, you’re going to get hit.

Research by ZScaler earlier this year indicated an average (median) number of web transactions per day, per user at 1912. Analysts put the number of Internet users at about two billion. That translates into more than three trillion web transactions per day. Every day, three trillion transactions are flying around the web. Based on the odds of being hit by lightning, that means over 6 million of those transactions would breach an organization.

The odds suddenly aren’t looking as good as they might seem, are they? If you think that’s bad, you ain’t read the most recent Ponemon results, which recently concluded that the odds of being breached in the next year were a “statistical certainty.”

No, it’s not paranoia if they really are out to get you and guess what? Apparently they are out to get you.

Truth be told, I’m not entirely convinced of the certainty of a breach because it assumes precautionary measures and behavior is not modified in the face of such a dire prediction. If organizations were to say, change their strategy as a means to get better odds, then the only statistical certainty would likely be that a breach would be attempted – but not necessarily be successful.

The bad news is that even if you have protections in place, the bad guys methods are evolving. If your primary means of protection are internal to your applications, the possibility remains that a new attack will require a rewrite – and redeployment. And even if you are taking advantage of external protection such as a web application firewall like BIG-IP ASM (Application Security Manager) it’s possible that it hasn’t provided complete coverage or accounted for what are misconfiguration errors: typographical case-sensitivity errors that can effectively erode protections.

The good news is that even as the bad guys are evolving, so too are those external protective mechanisms like BIG-IP ASM. BIG-IP ASM v11 introduced significant enhancements that provide better protection for emerging development format standards as well as address those operational oops that can leave an application vulnerable to being breached.

BIG-IP v11 Enhancements

AJAX and JSON Support
AJAX growth over the past few years have established it as the status quo for building interactive web applications. Increasingly these interaction exchanges via AJAX use JSON as their preferred data format of choice. Previous versions of BIG-IP ASM were unable to properly parse and therefore secure JSON payloads.

A secondary issue with AJAX is related to the blocking pages generally returned by web application firewalls. For example, a BIG-IP ASM blocking page is HTML-based. When an AJAX embedded control triggers a policy violation, this means it can't present the blocking page because it doesn't expect to receive back HTML – it expects JSON. This leaves operators in the dark as it makes troubleshooting AJAX issues very difficult.

To address both these issues, BIG-IP ASM v11 can now parse JSON payloads and enforce proper security policies. This is advantageous not only for protecting AJAX-exchanged payloads, but for managing integration via JSON-based APIs from external sources. Being able to secure what is essentially third-party content is paramount to ensuring a positive security posture regardless of external providers’ level of security. BIG-IP ASM v11 can also now also display a blocking page by injecting JavaScript into the response that will popup a window with a support ID, traceable by operators for easier troubleshooting. The ability to display a blocking page and ID is unique to BIG-IP ASM v11.

Case Insensitivity
Case sensitivity in general is derived from the underlying web server OS. While having a case sensitivity policy is an advantage on Unix/Linux platforms it can be painful to manage on other platforms. This is due to the fact that many times developers will write code without considering sensitivity. For example, a web server configured to serve a single file type, “html”, may also need to configure Html, hTml, HTml, etc… because a developer may have fat-fingered links in the code with these typographical errors. On Windows platforms, this is not a problem for the application, but it becomes an issue for the web application firewall because it is sensitive to case necessarily. BIG-IP ASM v11 now includes a simple checkbox-style flag that indicates it should ignore case, making it more adaptable to Windows-based platforms in which case may be variable. This is important in reducing false positives – situations where the security device thinks a request is malicious but in reality it is not. As web application firewalls generally contain very granular, URI-level policies to better protect against injection-style attacks, they often flag case differences as being “errors” or “possible attacks.” If configured to block such requests, the web application firewall would incorrectly reject requests for pages or URIs with case differences caused by typographical errors. This enhancement allows operators to ignore case and focus on securing the payload.

BIG-IP ASM VE

BIG-IP ASM is now available in a virtual form-factor, ASM VE. A virtual form-factor makes it easier to evaluate and test in lab environments, as well as enabling developers to assist in troubleshooting when vulnerabilities or issues arise that involve the application directly. Virtual patching, as well, is better enabled by a virtual form factor, as is the ability to deploy remotely in cloud computing environments.

There is no solution short of a scissors that can reduce your risk of breach to 0. But there are solutions that can reduce that risk to a more acceptable level, and one of those solutions is BIG-IP ASM. Getting hit by lightning on the Internet is a whole lot more likely than the idiom makes it sound, and anything that can reduce the odds is worth investigating sooner rather than later.

More BIG-IP ASM v11 Resources:

Connect with Lori: Connect with F5:

Related blogs & articles:

Technorati Tags: F5,F5 Friday,MacVittie,security,web application security,web application firewall,JSON,HTTP,AJAX,virtualization,Web 2.0