Most IT administrators are painfully aware that Windows Server 2003 will reach the end of extended support in July 2015. This is a big deal because Windows Server 2003 has been a monster success since it was released 11 years ago. From 2003 to 2010 this platform was the workhorse for applications deployed at both small businesses and large enterprises. And, even though Microsoft released a major update with Windows 2008, late in 2008, most enterprises stuck with Windows 2003 until Windows Server 2008 R2 launched on October 22, 2009.

read more

#SSL #webperf #infosec 

Now your services can take advantage of hardware acceleration even when they're deployed on virtual machines

Way back in the day, when SSL offloading was young and relatively new, there were a variety of hardware, software and even architecture that arose to defeat the security penalty imposed by the requisite cryptographic functionality.

Most commonly, we'd slap a PCI-card into a server, muck with the web server configuration (to load some shared objects) and voila! Instant performance boost via hardware acceleration. Later, an architectural approach that leveraged a network-based offload capability was introduced. This meant configuring an SSL offload appliance in a side (or one) arm configuration (common for caches and even load balancers back then) in which SSL traffic was routed to the offload appliance and decrypted before being sent on to the web or app server. You added some latency in the hairpin (or trombone, if you prefer) but that was always more than offset by the improvement of not letting the web server try to decrypt that data in the first place.

We've come a long way since then and most often these days you'll find an application delivery controller (ADC) or an app proxy serving duty as cryptographic master of the application. Most ADCs are still far more efficient at handling SSL/TLS traffic because they've benefitted from Moore's Law in two places: the core system and the SSL acceleration hardware (which takes advantage of CPUs, too, in addition to custom hardware).

Now comes the advent of the next generation of application delivery architectures which, necessarily, rely on a fabric-based approach and incorporate virtual appliances as well as traditional hardware. Services deployed on the hardware of course benefit from the availability of specialized SSL acceleration but the virtual appliances? Not so much.

We (as in the corporate We) didn't like that much at all, especially given trends toward greater key lengths and the forthcoming HTTP 2.0 specification which, yes, requires SSL/TLS. That means a lot more apps are going to need SSL – but they aren't going to want the associated performance penalty that comes with it running on software. They may not be as important, but they aren't expendable. That's true whether the web server natively handles SSL or you move it off to a virtual ADC within the services fabric. All apps are important, of course, but we know that some are more important than others and thus are afforded the benefits of services deployed on faster performing hardware while others are relegated to virtual machines.

We take our commitment with Synthesis to leave no application behind seriously and thus have introduced the industry's first hybrid SSL offload capability.

Hybrid SSL Offload 

Hybrid SSL Offload was made available with the release of BIG-IP 11.6 and enables virtual editions of BIG-IP as well as less capable and legacy BIG-IP appliances and devices to harness the power of hardware to improve app performance through cryptographic acceleration. This has the added benefit of freeing up resources on virtual appliances to improve the overall performance and capacity of app services deployed on that virtual edition.

In a nutshell, user requests are sent to the appropriate virtual ADC instance, which hosts all app services for an app except SSL. SSL is offloaded to a designated service running on a hardware platform that can take advantage of its targeted hardware acceleration.

Using hybrid SSL offload within the Synthesis service fabric allows organizations to:

•Achieve the maximum SSL performance of a virtual license  

•Free up Virtual Edition CPU utilization for other application services

All together this means better app performance and capacity for services deployed on virtual editions.

All applications need services and deserve optimal performance, even those that might otherwise by designated as "red shirt" apps by IT. F5 Synthesis continues to leave no application behind by ensuring every application has access to the services it needs, even when it means collaborating across device types.

read more

Monetization. Monetize. Great sounding words. Is it just pricing or something more? Merriam-Webster defines monetize as “to coin into legal tender,” or “to purchase debt and thereby free for other uses moneys that would have been devoted to debt service,” or “to utilize (something of value) as a source of Brian James

The post Monetization – As interesting as it sounds? appeared first on Recurring Revenue Blog | Aria Systems.

read more

Big news last week was about the JPMC data breach that could potentially impact millions of customers. This news brought about the return of “banks that are too big to fail” discussions on a much smaller scale then we saw during the financial crisis a few years back. The fact is, we live in a […]

The post Too Big To Scale – Data Visualizations at Web Scale written by Jim Hirschauer appeared first on Application Performance Monitoring Blog from AppDynamics.

read more

Editor’s note: This post by Invincea CEO Anup Ghosh first appeared at LinkedIn. We knew this would be of interest to you and posted it here with the author’s permission.-bg I’ll say it up front, your security program does not work because it is based on three common myths we hold as unquestionable truths in […]

read more

Applications are as integral to F5 technologies as they are to your business.

An old adage holds that an individual can be judged by the company he keeps. If that holds true for organizations, then F5 would do well to be judged by the vast array of individual contributors, partners, and customers in its ecosystem. From its long history of partnering with companies like Microsoft, IBM, HP, Dell, VMware, Oracle, and SAP to its astounding community of over 160, 000 engineers, administrators and developers speaks volumes about its commitment to and ability to develop joint and custom solutions.

F5 is committed to delivering applications no matter where they might reside or what architecture they might be using. Because of its full proxy architecture, F5’s ADC platform is able to intercept, inspect and interact with applications at every layer of the network. That means tuning TCP stacks for mobile apps, protecting web applications from malicious code whether they’re talking JSON or XML, and optimizing delivery via HTTP (or HTTP 2.0 or SPDY) by understanding the myriad types of content that make up a web application: CSS, images, JavaScript and HTML.

But being application-driven goes beyond delivery optimization and must cover the broad spectrum of technologies needed not only to deliver an app to a consumer or employee, but manage its availability, scale and security.

Every application requires a supporting cast of services to meet a specific set of business and user expectations, such as logging, monitoring and failover. Over the 18 years in which F5 has been delivering applications it has developed technologies specifically geared to making sure these supporting services are driven by applications, imbuing each of them with the application awareness and intelligence necessary to efficiently scale, secure and keep them available.

With the increasing adoption of hybrid cloud architectures and the need to operationally scale the data center, it is important to consider the depth and breadth to which ADC automation and orchestration support an application focus. Whether looking at APIs or management capabilities, an ADC should provide the means by which the services applications need can be holistically provisioned and managed from the perspective of the application, not the individual services. Technology that is application-driven, enabling app owners and administrators the ability to programmatically define provisioning and management of all the application services needed to deliver the application is critical moving forward to ensure success. F5 iApps and F5 BIG-IQ Cloud do just that, enabling app owners and operations to rapidly provision services that improve the security, availability and performance of the applications that are the future of the business.

That programmability is important, especially as it relates to applications according to our recent survey (results forthcoming) in which a plurality of respondents indicated application templates are "somewhat or very important" to the provisioning of their applications along with other forms of programmability associated with software-defined architectures including cloud computing.

Applications increasingly represent opportunity, whether it's to improve productivity or increase profit. Capabilities that improve the success rate of those applications are imperative and require a deeper understanding of an application and its unique delivery needs than a protocol and a port.

F5 not only partners with application providers, it encapsulates the expertise and knowledge of how best to deliver those applications in its technologies and offers that same capability to each and every organization to tailor the delivery of their applications to meet and exceed security, reliability and performance goals. 

Because applications aren't just a set of protocols and ports, they're opportunities. And how you respond to opportunity is as important as opening the door in the first place.

read more

#SDAS #HTTP #webperf #SSL De facto standards can be as difficult to transition off of as official ones

If you haven't heard about HTTP 2.0 it's time to start paying attention. It is anticipated that in November the latest version of the specification will become "the standard" for applications.

It includes enhancements designed to improve the security and performance of web applications, which have become critical strategic components to just about every organization on the planet. Go ahead, name an organization that doesn't rely on at least one web-based application to conduct business today.

Exactly.

Performance and security being imperatives along with the presence of applications means that HTTP 2.0 should be a welcome addition to the family of Internet protocols. But it will likely be met with some amount of trepidation by those tasked with supporting it on the data center side of applications because one of the downsides of updating standard protocols after so many years (HTTP 1.1 was ratified in RFC 2616 in 1999) is that they're rarely compatible. That's because in technology years, that 15 years is more like 75 years.

Consider for a moment IPv6, which was officially standardized way back in 1995 (RFC1883).

Yes, I said 1995. Before the great dot bomb. Before Web 2.0. Before mobile apps.

And how's that been going for us? Well, as of May 2014 more than 96% of all Internet traffic was still carried via IPv4. Go ahead, read that again because you're right – a 4% adoption rate over nearly 20 years is somewhat hard to swallow, isn't it?

But, you might think, IP affects everything. We're only talking about apps, here. And web apps, at that.

Well, let's consider that for a moment. According to our data, 65% of all apps are delivered via HTTP right now. in other words, HTTP is pretty darned important to app delivery and it'd be pretty hard to convince someone to upgrade all the things that need upgrading in order to support HTTP 2.0 (particularly with its requirement for encryption via SSL or TLS).

And yet major browsers (and consumer demand for speed, more speed and even MOAR SPEED) are already pushing adoption by broadly supporting SPDY (the protocol upon which HTTP 2.0 is based and which is the primary cause behind compatibility headaches). According to this site, which tracks SPDY adoption across browsers, all major browsers already have at least partial (if not full) support for SPDY.

They're ready to go. The app side? Not so much.

That's where an app gateway comes into play.

App Gateway: Bridging the Old and the New 

Like IPv6, the answer to the conundrum of transitioning from one protocol to another is a gateway. In the case of HTTP, it's an app gateway because HTTP is an app layer protocol.

In the latest release of the ADC platform on which F5 Synthesis High Performance Services Fabric is built we've included both SPDY 1.3 and HTTP 2.0 support, enabling a gateway architectural approach to supporting the latest (soon to be) standard and the existing, more prominent one. This architectural feat is accomplished by way of BIG-IP's full proxy architecture, which lets our ADC speak one version a protocol on the outside (the client) and another on the inside (to the app).

But what about all that security stuff you might ask. The requirement for SSL and TLS is as disruptive as the changes to the core protocol, after all.

You're right, it is, but again – the nature of being a full proxy means we can support SSL or TSL on the outside and plain old HTTP on the inside, sans encryption. While some organizations require end-to-end encryption of all traffic, those that don't will benefit from the ability to leverage client-side (outside) encryption without doing so on the inside (server-side) where lots of Layer 4-7 services may need visibility into traffic to do their respective jobs.

Using a gateway approach also enables a mix of HTTP 2.0 and HTTP 1.x on the inside (server side). That means organizations can take a transitory approach to adoption of the latest app protocol, moving if and when it seems most prudent based on upgrade and refresh cycles, not standards body meeting schedules.

The performance and security (and let's not forget business) benefits to moving to HTTP 2.0 with its SSL/TLS requirements and improvements in core transport of data between client and server are worth exploring. But it's understandable that a protocol so entrenched like HTTP 1.x is not easily ripped out and replaced with something new. Taking a gateway approach to adoption enables organizations to support the old while exploring the new and making sure that consumers and employees using the latest and greatest browsers will be able to enjoy improved performance and productivity.

Additional Resources:

• F5 Synthesis 
• Demo of F5 HTTP 2.0 Gateway with Sr. Product Manager Dawn Parzych @ Velocity 2014  

read more

UPDATE (9/28/2014): Our security team indicates that we're now seeing the majority of attempted exploits of Shellshock coming in through input paramters. They've provided ASM signatures to mitigate and recommend customers use these signatures to protect their applications. You can find these signatures and more information in this post: https://devcentral.f5.com/articles/bash-shellshock-mitigation-using-asm-signatures 

I had a great conversation this morning with Tom Spector, Enterprise Network Engineering Lead for Security here at F5, about the ways in which customers can use BIG-IP Application Security Manager (ASM) to mitigate Shellshock.

As you're no doubt aware, the potential exploits of Shellshock continue to evolve and we're seeing both HTTP header and input fields used as a transport mechanism for this Bash vulnerability. Web application firewalls (WAF) are a well known tool for protecting applications both on inbound (request) and the outbound (response) across headers and payloads. In the case of Shellshock, BIG-IP ASM is able to provide protection regardless of whether the HTTP method is POST or GET.

Tom offered the following suggestions when using ASM to mitigate Shellshock.

Character Restrictions

Restrict the character ‘{‘ in HTTP headers. Unlike parentheses that are commonly used in headers the character ‘{‘ is not as commonly used (although there may be cases when it is).

To do this in BIG-IP ASM:

• Ensure that under the blocking settings (Security -> Application Security -> Blocking -> Settings) you have checked for learn/alarm/block the violation for ‘Illegal meta character in header’ (found under ‘Input Violations’ section)
• Disallow the characters ‘{‘ in the header character set configuration (Security -> Application Security -> Headers -> Character Set)
• Save and apply the policy

You can also restrict the characters ‘(‘, ‘)’, and ‘{‘ in parameter values. These characters are not typically found in parameter values (some restrictions apply such as phone numbers that include parentheses in the values).

To do this in BIG-IP ASM:

• Ensure that under the blocking settings (Security -> Application Security -> Blocking -> Settings) you have checked for learn/alarm/block the violation for ‘Illegal meta character in value’ (found under ‘Input Violations’ section)
• By default, ASM already disallows the characters ‘(‘, ‘)’, and ‘{‘ in parameter values. You can verify this by looking at the parameter value character set configuration (Security -> Application Security -> Parameters -> Character Set -> Parameter Value)
• Save and apply the policy

Signatures

Ensure all signatures relevant to your environment are enabled (and are not in staging as is any parameter you wish to protect). A few signatures are aimed at identifying shell command injections included in headers or parameters. While this does not target the Shellshock initial attack vector (using the “() {“ sequence) it does handle the injection portion of the attack, i.e. bash commands included after the sequence such as netcat and telnet.

Additionally, consider adding these ASM signature to your arsenal: https://devcentral.f5.com/articles/bash-shellshock-mitigation-using-asm-signatures per our security team's recommendation.  

Cookies

One of the headers that may be targeted is Cookie. Using cookie encryption and/or ASM cookie enforcement will restrict any cookie tampering and catch those attempts to manipulate the cookie header of an application.

Please ensure you carefully evaluate the potential impact these changes can have in terms of false positives. In some cases the characters ‘(‘, ‘)’, and ‘{‘ are used in a legitimate manner within an application and blocking them my cause valid traffic to be denied.  As patches for vulnerable systems are available, make plans to roll them out as soon as possible. 

We will continue to update mitigations and provide additional guidance on mitigating Shellshock as they become available. You can always find the latest information regarding Shellshock on f5.com/shellshock.

Stay safe.

read more

American interest in online privacy and surveillance programs has jumped since Edward Snowden’s revelations about digital government surveillance in the United States. Deteriorating public relations have plagued intelligence agencies that have been identified as participating in the mass surveillance phenomenon, and many tech companies have already responded to their customers’ concerns with more encryption or […]

read more

The Internet of Things is a misnomer. That implies that everything is on the Internet, and that simply should not be – especially for things that are blurring the line between medical devices that stimulate like a pacemaker and quantified self-sensors like a pedometer or pulse tracker. The mesh of things that we manage must be segmented into zones of trust for sensing data, transmitting data, receiving command and control administrative changes, and peer-to-peer mesh messaging.

read more