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.
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 […]
#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.
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:
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.
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.
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:
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 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.
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.
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 […]
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.
Simply defined the SDDC promises that you’ll be able to treat «all» of your IT infrastructure as if it’s completely malleable. That there are no restrictions to how you can use and assign everything from border controls to VM size as long as you stay within the technical capabilities of the devices. The promise is great, but the reality is still a dream for the majority of enterprises.
In his session at 15th Cloud Expo, Mark Thiele, EVP, Ecosystem Evangelism at SUPERNAP, will cover where and how a business might benefit from SDDC and also why they should or shouldn’t attempt to adopt today.
Mark Thiele’s responsibilities at SUPERNAP include evaluating new data center technologies, developing partners and providing industry thought leadership. His insights on the next generation of technological innovations and how these technologies speak to client needs and solutions are invaluable. He shares his enthusiasm and passion for technology and how it impacts daily life and business on local, national and world stages.
SAP HANA combines database, data processing, and application platform capabilities in-memory. The platform provides libraries for predictive, planning, text processing, spatial, and business analytics. This new architecture enables converged OLTP and OLAP data processing within a single in-memory column-based data store with ACID compliance, while eliminating data redundancy and latency. By providing advanced capabilities, such as predictive text analytics, spatial processing, data virtualization, on the same architecture, it further simplifies application development and processing across big data sources and structures. This makes SAP HANA the most suitable platform for building and deploying next-generation, realtime applications and analytics.
As Platform as a Service (PaaS) matures as a category, developers should have the ability to use the programming language of their choice to build applications and have access to a wide array of services. Bluemix is IBM’s open cloud development platform that enables users to easily build cloud-based, creative mobile and web applications without having to spend large amounts of time and resources on configuring infrastructure and multiple software licenses. In this track, you will learn about the array of services to support and accelerate application development, as well as building applications on Bluemix using Java and node.JS. Learn more about Bluemix at www.bluemix.net.