Security

The Potential Ramifications of Platform-Based Vulnerabilities on Cloud Computing

Lori MacVittie — Wed, 08 Feb 2012 13:26:00 GMT

#infosec #adcfw #cloud Alternate title: How to take out an entire PaaS cloud with one vulnerability

What do these two vulnerabilities have in common? Right, they’re platform-based vulnerabilities. Meaning they are vulnerabilities peculiar to the web or application server platform upon which applications are deployed. Mitigations for such vulnerabilities generally point to changes in configuration of the platform – limit post size, header value sizes, turn off some value in the associated configuration.

But they also have something else in common – risk. And not just risk in general, but risk to cloud providers whose primary value is in offering not just a virtual server but an entire, pre-integrated and pre-configured application deployment stack. Think LAMP, as an example, and providers like Microsoft (Azure) and VMware (CloudFoundry), more commonly adopting the moniker of PaaS. It’s an operational dream to have a virtual server pre-configured and ready to go with the exact application deployment stack needed and offers a great deal of value in terms of efficiency and overall operational investment, but it is – or should be – a security professional’s nightmare. It’s not unlike the recent recall of Chevy Volts – a defect in the platform needs to be mitigated. The only way to do it, for car owners, is to effectively shut down their ability to drive while a patch is applied. It’s disruptive, it’s expensive (you still have to get to work, after all), and it’s frustrating for the consumer. For the provider, it’s bad PR and negatively impacts the brand. Neither of which is appealing.

A vulnerability in the application stack, in the web or application server, can be operationally devastating to the provider – and potentially disruptive to the consumer whether the vulnerability is exploited or not.

STANDARDIZATION is a DOUBLE-EDGED SWORD

Assume a homogeneous cloud environment offering an application stack based on Microsoft ASP. Assume now an exploit, oh say like Post of Doom, is discovered whose primary mitigation lies in modifying the configuration of each and every instance. Virtualization of any kind provides a solution, of course, but introduces the possibility of disruption in the impact to consumer applications from the configuration change. A primary mitigation for the Post of Doom is to limit the size of data in a POST to under 8MB. Depending on the application, this has to potential to “break” application functionality, particularly those for which uploading big data is a focus. Images, video, documents, etc… These all may be impacted negatively, disrupting applications and angering consumers.

Patching, of course, is preferred, as it eliminates the underlying vulnerability without potentially breaking applications. But patching takes time – time to develop, time to test, time to deploy. The actual delivery of such patches in a PaaS environment is a delicate operation. You can’t just shut the whole cloud down and restart it after the patches are applied to the base images, can you? Do you wait, quiesce the vulnerable images and only force the patched ones when new instances are provisioned? A configuration-based mitigation, too, has these same issues. You can’t just shut down the whole cloud, apply the change, and reboot.

It’s a delicate balance of security versus availability that must struck for the provider, and certainly their position in such cases is one not to be envied. Damned if they do, damned if they don’t.

Then there is the risk of exploitation before any mitigation is applied. If I want to wreak havoc on a PaaS, I may be able to accomplish simply by finding one with the appropriate platform vulnerable to a given exploit, and attack. Cycling through applications deployed in that environment (easily identified at the network layer by the IP ranges assigned to the provider) should result in a wealth of chaos being wrought. The right vulnerability could take out a significant enough portion of the environment to garner attention from the outages caused.

Enterprise organizations that think they are immune from such issues should think again, as even a cloud provider is often not as standardized on a single application platform as an enterprise is, and it is that standardization that is at the root of the potential risk from platform-based vulnerabilities. Standardization, commoditization, these are good things in terms of many financial and operational benefits, but they can also cause operational risk to increase.

MITIGATE in the MIDDLE

There is a better solution, a better strategy, a better operational means of mitigating platform-based risks.

This is where the role of a flexible, broad-spectrum layer of security applies. One that enables security professionals to broadly apply security policies to quickly mitigate potentially disastrous vulnerabilities. Without disrupting a single running instance, an organization can deploy a mitigating solution that detects and prevents the effects of such vulnerabilities. Applying security policies that mitigate such vulnerabilities before they reach the platform is critical to preventing a disaster of epic (and newsworthy) proportions.

Whether stop gap or a permanent solution, by leveraging the application delivery tier of any data center – enterprise or cloud provider – such vulnerabilities can be addressed without imposing harsh penalties on applications and application owners, such as requiring complete shutdown and reboots.

Leveraging such a flexible data center tier insulates the platform from exploitation while insulating customers from the disruption required to mitigate immediately on the platform layer, allowing time to redress through patches or, at least, understand the potential implication to the application from the platform configuration changes required to mitigate the vulnerability.

In today’s data center, time is perhaps the biggest benefit afforded to IT by any solution, and yet the one least likely to be provided. A flexible application delivery tier capable of mitigating threats across the network and application stack without disruption is one of the few solutions available that offers the elusive and very valuable benefit of time. Providers and enterprises alike need to consider their current data center architecture and whether it supports the notion of such a dynamic tier. If not, it’s time to re-evaluate and determine whether a strategic change of direction is necessary to ensure the ability of operations and security teams to address operational risk as quickly and efficiently as possible.

Connect with Lori:	Connect with F5:

Related blogs & articles:

Technorati Tags: F5,MacVittie,security,architecture,availability,cloud computing,virtualization,devops,threat mitigation,application delivery,blog

F5 Friday: Goodbye Defense in Depth. Hello Defense in Breadth.

Lori MacVittie — Fri, 27 Jan 2012 12:45:00 GMT

#adcfw #infosec F5 is changing the game on security by unifying it at the application and service delivery layer.

Over the past few years we’ve seen firewalls fail repeatedly. We’ve seen business disrupted, security thwarted, and reputations damaged by the failure of the very devices meant to prevent such catastrophes from happening. These failures have been caused by a change in tactics from invaders who seek no longer to find away through or over the walls, but who simply batter it down instead. A combination of traditional attacks – network-layer – and modern attacks – application-layer – have become a force to be reckoned with; one that traditional stateful firewalls are often not equipped to handle. Encrypted traffic flowing into and out of the data center often bypasses security solutions entirely, leaving another potential source of a breach unaddressed. And performance is being impeded by the increasing number of devices that must “crack the packet” as it were and examine it, often times duplicating functionality with varying degrees of success. This is problematic because the resolution to this issue can be as disconcerting as the problem itself: disable security. Seriously. Security functions have been disabled, intentionally, in the name of performance.

IT security personnel within large corporations are shutting off critical functionality in security applications to meet network performance demands for business applications.

SURVEY: SECURITY SACRIFICED FOR NETWORK PERFORMANCE

What the company [NSS Labs] found would likely startle any existing or potential customers: three of the six firewalls failed to stay operational when subjected to stability tests, five out of six didn't handle what is known as the "Sneak ACK attack," that would enable attackers to side-step the firewall itself. Finally, according to NSS Labs, the performance claims presented in the vendor datasheets "are generally grossly overstated."

Independent lab tests find firewalls fall down on the job

Add in the complexity from the sheer number of devices required to implement all the different layers of security needed, which increases costs while impairing performance, and you’ve got a broken model in need of repair. This is a failure of the defense in depth strategy; the layered, multi-device (silo) approach to operational security. Most importantly, it’s one that’s failing to withstand attacks.

What we need is defense in breadth – the height of the stack –to assure availability and security using a more intelligent, unified security strategy.

DEFENSE in BREADTH

While it’s really not as catchy as “defense in the depth” the concept behind the admittedly awkward sounding phrase is sound: to assure availability and security simultaneously requires a strong security strategy from the bottom to the top of the networking stack, i.e. the application layer. The ability of the F5 BIG-IP platform to provide security up and down the stack has existed for many years, and its capabilities to detect, prevent, and withstand concerted attacks has been appreciated by its customers (quietly) for some time. While basic firewalling functions have been a part of BIG-IP for years, there are certain capabilities required of a firewall – specifically an ICSA certified firewall – that it didn’t have. So we decided to do something about that.

The result is the ICSA certification of the BIG-IP platform as a network firewall. Combined with its existing

ICSA certification for web application firewall (BIG-IP Application Security Manager) and SSL-TLS VPN 3.0 (BIG-IP Edge Gateway), the BIG-IP platform now supports a full-spectrum security solution in a single, unified system. What is unique about F5’s approach is that the security capabilities noted above can be deployed on BIG-IP Application Delivery Controllers (ADCs)—best known for providing industry-leading intelligent traffic management and optimization capabilities. This firewall solution is part of F5’s comprehensive security architecture that enables customers to apply a unified security strategy. For the first time in the industry, organizations can secure their networks, data, protocols, applications, and users on a single, flexible, and extensible platform: BIG-IP.

Combining network-firewall services with the ability to plug the hole in modern security implementations (the application layer) with a platform-based solution provides the opportunity to consolidate security services and leverage a shared infrastructure platform resulting in a more comprehensive, strategic deployment that is not only more secure, but more cost effective.

Resources:

Connect with Lori:	Connect with F5:

Related blogs & articles:

Technorati Tags: MacVittie,F5,F5 Friday,firewall,ICSA,security,BIG-IP,network,application security,DDoS,threat mitigation,blog

The Mobile Chimera

Lori MacVittie — Wed, 25 Jan 2012 11:56:00 GMT

#mobile #vdi #IPv6 In the case of technology – as with mythology - the whole is often greater (and more challenging) than the sum of its parts.

The chimera is a mythological beast of scary proportions. Not only is it fairly large, but it’s also got three, independent heads – traditionally a lion, a goat, and a snake. Some variations on this theme exist, but the basic principle remains: it’s a three-headed, angry beast that should not be taken lightly should one encounter it in the hallway.

Individually, one might have a strategy to meet the challenge of a lion or a goat head on. But when they converge into one very angry and dangerous beast, the strategies and tactics employed to best any one of them will almost certainly not work to address all three of them simultaneously.

The world of mobility is rapidly approaching its own technological chimera, one comprised of three individual technology trends. While successful stratagem and tactics exist which address each one individually, when taken together they form a new challenge requiring a new strategic approach.

THE MOBILE CHIMERA

Three technology trends - VDI, mobile, and IPv6 - are rapidly converging upon the enterprise. Each is driven in part by the other, and each requires in part functionality and support of another. Addressing the challenges accompanying this trifecta requires a serious evaluation of the enterprise infrastructure with an eye toward performance, scalability, and flexibility, less it be overwhelmed by demand originating both internally and externally.

Mobile

The myriad articles, blogs, and editorial orations on mobile device growth have to date focused on the need for organizations to step up and accept the need for device-ready enterprise applications. This focus has thus far ignored the reality of the diversity of the device client base, the ramifications of which those with long careers in IT will painfully recall from the client-server era. Thus it is no surprise that interest in and adoption of technology such as VDI is on the rise, as virtualization serves as a popular solution to the problem of delivering applications to a highly-diverse set of clients.

But virtualization, as popular a solution as it may be, is not a panacea. Security and control over corporate resources and applications is a growing necessity today because of the ease with which users can take advantage of mobile technology to access them.

Access control does not entirely solve the challenges of a diverse mobile client audience, as attackers turn their attention on mobile platforms as a means to gain access to resources and data previously beyond their reach. The need for endpoint security inspection continues to grow as the threat posed by mobile devices continues to rear its ugly head.

VDI

It was inevitable that the growth of mobile device usage in the enterprise continued to grow that so, too, would the solution of VDI grow as the most efficient way to deliver applications without requiring mobile platform-specific versions. The desire by business owners and security practitioners to keep data securely within the data center "walls", too, is a factor in the rising desire to deploy VDI. VDI enables organizations to deliver applications remotely while maintaining control over data inside the data center, preserving enforcement of corporate security policies and minimizing risk.

But VDI deployments are not trivial, regardless of the virtualization platform chosen. Each virtualization solution has its challenges and most of those challenges revolve around the infrastructure necessary to support such an initiative. Scalability and flexibility are important facets of VDI delivery infrastructure, and performance cannot be overlooked if such deployments are to be considered successful.

IPv6

Who could forget that the Internet is being pressured to move to IPv6 sooner rather than later, in part because of the growth of mobile clients? The strain placed on service providers to maintain IPv4 support as a means to not "break the Internet" can only be borne so long before IPv6 becomes, as has been predicted, the Y2K for the network.

The ability to deliver applications via VDI to mobile devices will soon require support for IPv6, but will not obviate the need to support IPv4 just yet. A dual stack approach will be required during the transition period, putting delivery infrastructure again front and center in the battle to deploy and support applications for mobile devices.

With all accounts numbering mobile devices in the four billion range across multiple platforms and effectively 0 IPv4 addresses left to assign to those devices, it should be no surprise that as these three technology trends collide the result will be the need for a new mobility strategy.

This is why solutions are strategic and technology is tactical. There exist individual products that easily solve each of these problems individually, but very few solutions that address the combined juggernaut that is the three combined. It is necessary to coordinate and architect a solution that can solve all three challenges simultaneously as a means to combat complexity and its associated best friend forever, operational risk.

A flexible and scalable delivery strategy will be necessary to ensure performance and security without sacrificing operational efficiency.

Connect with Lori:	Connect with F5:

Related blogs & articles:

Technorati Tags: F5,MacVittie,mobile,vdi,ipv6,application delivery,strategy,performance,security,availability,architecture,quasar,blog

The API is the Center of the Application (Integration) Universe

Lori MacVittie — Mon, 23 Jan 2012 12:42:00 GMT

#mobile #fasterapp #ccevent Today, at least. Tomorrow, who knows?

Some have tried to distinguish between “mobile cloud” and “cloud” by claiming the former is the use of the web browser on a mobile device to access services while the latter uses device-native applications. Like all things cloud, the marketing fluff is purposefully obfuscating and sweeping under the rug the technology required to make things work for consumers, whether those consumers be your kids or IT professionals. Infrastructure is not eliminated when organizations take to the cloud nor do the constraints of web-based protocols and methodologies become irrelevant when Bob uses a service to store photos of his kid’s piano recital on Flickr.

The applications and web browsers on a mobile device are using the same technology, the same protocols, suffering under the same constraints as the rest of us in wireline land. If developers are as smart as they are lazy (and I say that as a compliment because it is the laziness of developers that more often than not leads to innovation) they have already moved to an API-centric model in which web site and device native-app interfaces both leverage the same APIs.

This isn’t just a social integration phenomenon – it isn’t just about Twitter and Facebook and Google. API usage and demand is growing, and it is not expected to stop any time soon. Given the option, developers asked about desire to connect to services (assuming service = API) the overwhelming response was developers would like to connect to “everything, if it were easy.” (API Integration Pain Survey Results)

The API is rapidly becoming (if it isn’t already) the center of the application (integration) universe. This unfortunately has the potential to cause confusion and chaos in the data center. When a single API is consumed by multiple clients – mobile, remote, applications, partners, etc.. – solutions unique to each quickly seem to make their way into the code to deal with “exceptions” and “peculiarities” inherent to the client platform.

That’s inefficient and, when one considers the growing number of platforms and form-factors associated with mobile communications alone, it is not scalable from a people and process perspective.

But reality is that these exceptions and peculiarities – often times caused by a lack of feature parity across form-factors and platforms – must be addressed somewhere, and that somewhere is unfortunately almost unilaterally determined to be the application. Do we need to treat mobile devices differently? In terms of performance and delivery concerns, yes. But that’s where we leverage the application delivery tier to differentiate by device to ensure delivery. That’s the beauty of an abstracted, service-enabled data center – there’s an intelligent and agile layer of application delivery services that mediates between clients (regardless of their form factor) and services to ensure that delivery needs (security, performance, and availability) are met in part by addressing the unique characteristics and reality of access via mobile devices.

ABSTRACT and ISOLATE

This is exactly the type of problem application delivery is designed to address. Multiple clients, multiple networks, all accessing the same application service or API but requiring specific authentication, security, and delivery characteristics to ensure that operational risk is mitigated in the most efficient manner possible.

This includes the ability to throttle services based on user and client, a common approach used by mega-sites such as Twitter. This includes the ability to provide single sign-on capabilities to all clients, regardless of platform, form-factor and support for enterprise-grade authentication integration to the same API or application service. This includes leveraging the appropriate security policies to ensure inbound and outbound security of data regardless of client, such that corporate data is not infected and spread to other consumers.

A flexible, scalable application delivery tier addresses the problem of a single API being utilized by a variety of clients in a way that precludes the need to codify specific functionality on a per-platform or form-factor basis in the application logic itself, making the API simpler and easier to maintain as well as test and upgrade. It makes APIs and application services more scalable in terms of people and processes, which in turn makes the development and deployment process more efficient and able to focus on new services rather than constantly modifying and updating existing ones.

Service-oriented architecture may have begun in the application demesne as a means to abstract and isolate services such that they could more easily be integrated, maintained, and changed without disruption, but the concept is applicable to the data center as a whole. By leveraging SOA concepts at the data center architecture level, the entire technological landscape of the business can be transformed into one that is ultimately more adaptable, more scalable, and more secure.

I’ll be at CloudConnect 2012 and we’ll discuss the subject of cloud and performance a whole lot more at the show!

Sessions

Connect with Lori:	Connect with F5:

Related blogs & articles:

Technorati Tags: F5,MacVittie,application delivery,data center,architecture,mobile,API,SOA,security,performance,availability,blog

The Fundamental Problem with Traditional Inbound Protection

Lori MacVittie — Fri, 20 Jan 2012 13:11:00 GMT

#adcfw #RSAC #infosec The focus on bandwidth and traffic continue to distract from the real problems with traditional inbound protections …

The past year brought us many stories focusing on successful attacks on organizations for a wide variety of reasons. Why an organization was targeted was not nearly as important as the result: failure to prevent an outage. While the volume of traffic often seen by these organizations was in itself impressive, it was not the always the volume of traffic that led to the outage, but rather what that traffic was designed to do: consume resources.

It’s a story we’ve heard before, particularly with respect to web and application servers. We know that over-consumption of resources impairs performance and, ultimately, causes outages. But what was perhaps new to many last year was that it wasn’t just servers that were falling to an overwhelming number of connections, it was the very protections put in place to detect and prevent such attacks – stateful firewalls.

Firewalls are the most traditional of inbound protection for data centers. Initially designed to simply prevent unauthorized access via specific ports, they have evolved to a level that includes the ability to perform limited packet inspection and make decisions based on the data within them. While this has been helpful in preventing a growing variety of attacks, they have remained unable to move laterally across protocols and understand expected and acceptable behavior within the context of a request, which results in a failure to recognize an attack. This is because modern application layer attacks look and smell to traditional inbound protection devices like legitimate requests. They are simply unable to parse behavior in its appropriate context and make the determination that the intention behind the request is malicious.

A recent InfoWorld article presented a five-point list regarding how to deny DDoS attacks. The author and his referenced expert Neal Quinn, VP of operations at Prolexic, accurately identify the root cause of the inability of traditional inbound protection to thoroughly mitigate DDoS attacks:

But the most difficult challenge has been DDoS attackers' increasing sophistication as they've moved from targeting Layers 3 and 4 (routing and transport) to Layer 7 (the application layer). They've learned, for example, how to determine which elements comprise a victim's most popular Web page, honing in on which ones take the most time to load and have the least amount of redundancy.

"Attackers are now spending a much longer period of time researching their targets and the applications they are running, trying to figure out where they can cause the most pain with a particular application," Quinn said. "For example, they may do reconnaissance to figure out what URL post will cause the most resource-consuming Web page refresh."

-- How to deny DDoS attacks

Unfortunately the five-point list describing the strategy and tactics to “deny DDOS attacks” completely ignores this difficult challenge, offering no advice on how to mitigate “the most difficult challenge".” While the advice to ensure enough compute resources tangentially touches upon the answer, the list is a traditional response that does not address the rising Layer 7 challenge.

CONNECTIONS not THROUGHPUT

To understand how to mitigate the rising layer 7 security challenge one must first understand the two core reasons traditional inbound security solutions are unlikely to mitigate these attacks. First is a failure to recognize an application layer attack for what it is. This failure cascades into the second reason traditional inbound security solutions fail: connection capacity.

Not bandwidth, connections. A million TCP connections can easily topple most modern firewalls today and yet the bandwidth involved could be miniscule compared to the gigabits of capacity many organizations have at their disposal. It isn’t about bandwidth anymore, it’s about connections. This is why the advice to ramp up compute processing power and memory is partially on target – because memory is imperative in maintaining massive session (connection) tables on infrastructure as traffic flows to and from targeted services.

Because traditional inbound protection devices are unable to recognize the malicious intent of these legitimate-appearing requests, they must maintain the connection. When combined with the need to maintain connections for all legitimate traffic, these malicious requests can quickly push a traditional device beyond its meager connection limitations. When that occurs, the results are disastrous. Performance, of course, suffers unacceptable degradation. One can only hope that is the only impact, for far more often the device simply fails, completely disrupting all services.

To complete the aforementioned list of “how to deny a DDoS attack”, it is necessary to implement a security solution at the perimeter of the network that is both able to detect and thus deny malicious requests and which has the connection capacity necessary to withstand the combined volume of legitimate and malicious requests. This solution must reside at the edge of the network, lest a less capable device be overwhelmed. This is because when it comes to perimeter security, the default is a serial strategy – nothing gets past a failed security device. If that security device is at the edge of the network, as is the case with traditional inbound security solutions like stateful firewalls, then all services residing topologically behind that device will fail should the firewall fall.

This is by design. One does not want unfettered access to services and applications. No perimeter protection, no access. It’s a sound strategy, but one that needs to employ a perimeter device capable of withstanding even the most diverse of attacks.

Traditional inbound security is too constrained in terms of connection capacity to maintain its position on the front lines. A more capable, intelligent security solution is required – one able to provide traditional inbound security protections as well as recognizing the malicious intent of more modern, application layer attacks.

Connect with Lori:	Connect with F5:

Related blogs & articles:

Technorati Tags: F5,MacVittie,firewall,security,application security,blog

The Ascendancy of the Application Layer Threat

Lori MacVittie — Tue, 17 Jan 2012 13:19:00 GMT

#adcfw #RSAC Attackers have outflanked your security infrastructure

Many are familiar with the name of the legendary Alexander the Great, if not the specific battles in which he fought. And even those familiar with his many victorious conquests are not so familiar with his contributions to his father’s battles in which he certainly honed the tactical and strategic expertise that led to his conquest of the “known” world.

In 339 BC, for example, then Macedonian King Phillip II – the father of Alexander the Great – became engaged in a battle at Chaeronea against the combined forces of ancient Greece. While the details are interesting, they are not really all that germane to technology except for commentary on what may be* Phillips’ tactics during the battle, as suggested by the Macedonian author Polyaenus:

In another 'stratagem', Polyaenus suggests that Philip deliberately prolonged the battle, to take advantage of the rawness of the Athenian troops (his own veterans being more used to fatigue), and delayed his main attack until the Athenians were exhausted.

-- Battle of Chaeronea (338 BC) (Wikipedia)

This tactic should sound familiar, as it akin in strategy to that of application DDoS attacks today.

THE RISE of APPLICATION LAYER ATTACKS

Attacks at the application layer are here to stay – and we should expect more of them. When the first of these attacks was successful, it became a sure bet that we would see more of them along with more variations on the same theme. And we are. More and more organizations are reporting attacks bombarding them not just at the network layer but above it, at the transport and application layers.

Surely best practices for secure coding would resolve this, you may think. But the attacks that are growing to rule the roost are not the SQLi and XSS attacks that are still very prevalent today. The attacks that are growing and feeding upon the resources of data centers and clouds the globe over are more subtle than that; they’re not about injecting malicious code into data to be spread around like a nasty contagion, they’re DDoS attacks. Just like their network-focused DDoS counterparts, the goal is not infection – it’s disruption.

These attacks exploit protocol behavior as well as potentially missed vulnerabilities in application layer protocols as a means to consume as many server resources as possible using the least amount of client resources. The goal is to look legitimate so the security infrastructure doesn’t notice you, and then slowly leech compute resources from servers until they can’t stand – and they topple.

They’re Phillip’s Macedonians; wearing out the web server until it’s too tired to stand.

These attacks aren’t something listed in the OWASP Top Ten (or even on the OWASP list, for that matter). These are not attacks that can be detected by IPS, IDS, or even traditional stateful firewalls. These technologies focus on data and anomalies in data, not behavior and generally not at the application protocol layer.

For example, consider HTTP Fragmentation attacks.

In this attack, a non-spoofed attacker establishes a valid HTTP connection with a web server. The attacker then proceeds to fragment legitimate HTTP packets into tiny fragments, sending each fragment as slow as the server time out allows, holding up the HTTP connection for a long time without raising any alarms. For Apache and many other web servers designed with improper time-out mechanisms, this HTTP session time can be extended to a very long time period. By opening multiple extended session per attacker, the attacker can silently stop a web service with just a handful of resources.

Multiple Methods in a Single Request is another fine example of exhausting a web server’s resources. The attacker creates multiple HTTP requests, not by issuing them one after another during a single session, but by forming a single packet embedded with multiple requests. This allows the attacker to maintain high loads on the victim server with a low attack packet rate. This low rate makes the attacker nearly invisible to NetFlow anomaly detection techniques. Also, if the attacker selects the HTTP method carefully these attacks will bypass deep packet inspection techniques.

There a number of other similar attacks, all variations on the same theme: manipulation of valid behavior to exhaustion of web server resources with the goal of disrupting services. Eventually, servers crash or become so slow they are unable to adequately service legitimate clients – the definition of a successful DDoS attack.

These attacks are not detectable by firewalls and other security infrastructure that only examine packets or even flows for anomalies because no anomaly exists. This is about behavior, about that one person in the bank line who is acting oddly – not enough to alarm most people but just enough to trigger attention from someone trained to detect it. The same is true of security infrastructure. The only component that will detect such subtle improper behavior is one that’s been designed to protect it.

* It was quite a while ago, after all, and sources are somewhat muddied. Whether this account is accurate or not is still debated.

Connect with Lori:	Connect with F5:

Related blogs & articles:

Technorati Tags: F5,MacVittie,security,firewall,application,service delivering,dynamic infrastructure,web application security,DDoS,threat mitigation,blog

F5 Friday: Why SSL VPN Still Matters

Lori MacVittie — Fri, 13 Jan 2012 12:55:00 GMT

#mobile #vdi #infosec Scale and flexibility make SSL VPN an important part of any corporate remote access strategy

You might have noticed a couple of news items from F5 this week that appeared related. If you noticed you were right, they are.

First, we were very excited to announce recognition of our hard work on our SSL VPN solutions: F5 Positioned in Leaders Quadrant of SSL VPN Magic Quadrant. Second, we were even more excited to announce adding industry-leading support for Android’s 4.x OS, enhancing its SSL VPN capabilities.

Why would be excited about that? Because mobile devices and virtualization (desktop, a la VDI, and server, a la cloud) continue to drive the need for secure remote access at a scale never before experienced by most IT organizations. While web monsters and primarily web-focused organizations have long understand the critical nature of scalability to their business, IT shops for whom a web presence was only somewhat important have not necessarily invested in the infrastructure or architecture necessary to truly scale to meet the increasing demand. It is increasingly the case that IT orgs of all shapes, sizes, and concerns must look to the scalability of its infrastructure to ensure its ability to service users inside and outside the data center via an often times dizzying array of clients and technologies.

SSL VPNs arose from similar needs many years ago, out of the overwhelming complexity associated with IPSEC and the inability to support every end-user from every platform available. An SSL VPN generally provides two things: secure remote access via a web-top portal and network-level access via an SSL secured tunnel between the client and the corporate network.

By providing both modes of access via an established, ubiquitous protocol (SSL), such solutions are better able to provide end users with access to resources regardless of platform. By deploying such a solution on a proven, highly scalable platform (BIG-IP), such solutions are better able to provide IT with the means to scale not only the solution but its requisite infrastructure services.

Enhanced Mobile Support

BIG-IP^® Edge Client^™ is the industry’s first SSL VPN solution that provides comprehensive security and mobile access for all devices running Android 4.x (codenamed Ice Cream Sandwich). It’s free, and you can get it anytime you like. Right now, if you want – go ahead. Grab it, I’ll wait.

Oh, you aren’t running Ice Cream Sandwich yet? If you’ve got a “rooted” device, we’ve got your back there, too, with our BIG-IP Edge Client for “rooted” devices.

Additionally, F5 is introducing enhanced support for its BIG-IP Edge Portal™, which provides managed application access to enterprise web applications such as SharePoint, wikis, and Intranet sites. This is that web top access mentioned earlier – a secure means of providing access to resources from any device without giving away the keys to the kingdom via the more open corporate network access route.

And ultimately, this two-pronged approach to secure remote access afforded by SSL VPN solutions like BIG-IP Edge Gateway will continue to be important to corporate remote access strategies precisely because of the need to differentiate levels of service and access based on location, device, and user – something only a context-aware solution can provide.

This is why validation of external sources of our work in the SSL VPN arena is exciting – because SSL VPN continues to be a significantly more flexible option to traditional IPSEC VPN connectivity and with the continued growth of mobile devices and demand for technology like VDI, it will certainly only continue to expand its applicability in the enterprise as scale and flexibility become more and more necessary to meet the diverse, distributed demand of clients.

Connect with Lori:	Connect with F5:

Related blogs & articles:

Technorati Tags: F5,F5 Friday,MacVittie,mobile,vdi,ssl,ssl vpn,secure remote access,Android,Ice Cream Sandwich,BIG-IP,IPSEC,VPN,blog

Mature Security Organizations Align Security with Service Delivery

Lori MacVittie — Thu, 12 Jan 2012 13:33:00 GMT

#adcfw #RSAC Traditional strategy segregates delivery from security. Traditional strategy is doing it wrong…

Everyone, I’m sure, has had the experience of calling customer service. First you get the automated system, which often asks for your account number. You know, to direct you to the right place and “serve you better.” Everyone has also likely been exasperated when the first question asked by a customer service representative upon being connected to a real live person is … “May I have your account number, please?”

It’s frustrating and, for everyone involved, it’s cumbersome.

That’s exactly the process that occurs in most data centers today as application requests are received by the firewall and then passed on to the service delivery layer.

Traditional data center design segregates security from service delivery. There’s an entire complement of security-related components that reside at the perimeter of the network, designed to evaluate incoming traffic for a wide variety of potential security risks – DDoS, unauthorized access, malicious packets, etc… But that evaluation is limited to the network layers of the stack. It’s focused on packets and connections and protocols, and fails to take into consideration the broader contextual information that is carried along by every request. It’s asking for an account number but failing to leverage it and share it in a way that effectively applies and enforces corporate security policies.

It’s cumbersome.

Reality is that many of the functions executed by firewalls are duplicated in the application delivery tier by service delivery systems. What’s more frustrating is that many of those functions are executed more thoroughly and to better effect (i.e. they mitigate risk more effectively) at the application delivery layer.

What should be frustrating to those concerned with IT budgets and operational efficiency is that this disconnected security strategy is more expensive to acquire, deploy, and maintain. Using shared infrastructure is the hallmark of a mature security organization; it’s a sign of moving toward a more strategic security strategy that’s not only more technically adept but is financially sound.

SHARED INFRASTRUCTURE

We most often hear the term “shared infrastructure” with respect to cloud computing and its benefits. The sharing of infrastructure across organizations in a public cloud computing environment nets operational savings not only from alleviating the need to manage the infrastructure from the fact that the capital costs are shared across hundreds if not thousands of customers.

Inside the data center private cloud computing models are rising to the top of the “must have” list for IT for similar reasons. In the data center, however, there are additional technical and security benefits that should not be overlooked. Aligning corporate security strategy with the organizations’ service delivery strategy by leveraging shared infrastructure provides a more comprehensive, strategic deployment that is not only more secure, but more cost effective.

Service delivery solutions already provide a wide variety of threat mitigation services that can leveraged to mitigate the performance degradation associated with a disjointed security infrastructure, the kind that leads 9 of 10 organizations to sacrifice that security in favor of performance. By leveraging shared infrastructure to perform both service delivery acceleration as well as security, neither performance nor security need be sacrificed because it essentially aligns with the mantra of the past decade with regards to performance and security: crack the packet only once.

In other words, don’t ask the customer for their account number twice. It’s cumbersome, frustrating, and an inefficient means of delivering any kind of service.

Connect with Lori:	Connect with F5:

Related blogs & articles:

Technorati Tags: F5,MacVittie,security,firewall,strategy,service delivering,dynamic infrastructure,web application security,DDoS,threat mitigation,blog

F5 Friday: Creating a DNS Blackhole. On Purpose

Lori MacVittie — Fri, 06 Jan 2012 12:32:00 GMT

#infosec #DNS #v11 DNS is like your mom, remember? Sometimes she knows better.

Generally speaking, blackhole routing is a problem, not a solution. A route to nowhere is not exactly a good thing, after all. But in some cases it’s an approved and even recommended solution, usually implemented as a means to filter out bad packets at the routing level that might be malformed or are otherwise dangerous to pass around inside the data center.

This technique is also used at the DNS layer as a means to prevent responding to queries with known infected or otherwise malicious sites. Generally speaking, DNS does nothing more than act like a phone book; you ask for an address, it gives it to you. That may have been acceptable through the last decade, but it is increasingly undesirable as it often unwittingly serves as part of the distribution network for malware and other malicious intent.

In networking, black holes refer to places in the network where incoming traffic is silently discarded (or "dropped"), without informing the source that the data did not reach its intended recipient.

When examining the topology of the network, the black holes themselves are invisible, and can only be detected by monitoring the lost traffic; hence the name.

(http://en.wikipedia.org/wiki/Black_hole_(networking))

What we’d like to do is prevent DNS servers from returning addresses for sites which we know – or are at least pretty darn sure – are infected. While we can’t provide such safeguards for everyone (unless you’re the authoritative server for such sites) we can at least better protect the corporate network and users from such sites by ensuring such queries are not answered with the infected addresses.

Such a solution requires the implementation of a DNS blackhole – a filtering of queries at the DNS level. This can be done using F5 iRules to inspect queries against a list of known bad sites and returning an internal address for those that match. What’s cool about using iRules to perform this function is the ability to leverage external lookups to perform the inspection. Sideband connections were introduced in BIG-IP v11 and these connections allow external, i.e. off device, lookups for solutions like this. Such a solution is similar to the way in which you’d want to look up the IP address and/or domain of the sender during an e-mail exchange, to validate the sender is not on the “bad spammer” lists maintained by a variety of organizations and offered as a service.

Jason Rahm recently detailed this solution as architected by Hugh O’Donnel, complete with iRules, in a DevCentral Tech Tip. You can find a more comprehensive description of the solution as well as the iRules to implement in the tech tip.

v11.1: DNS Blackhole with iRules

Happy (DNS) Routing!

Connect with Lori:	Connect with F5:

Related blogs & articles:

Technorati Tags: F5,F5 Friday,MacVittie,DNS,routing,blackhole,network,iRules,architecture,security,context-aware,blog

The Three Axioms of Application Delivery

Lori MacVittie — Wed, 04 Jan 2012 12:04:00 GMT

#fasterapp If you know these three axioms, then you’ll know application delivery when you see it.

Like most technology jargon, there are certain terms and phrases that end up mangled, conflated, and generally misapplied as they gain traction in the wider market. Cloud is merely the latest incarnation of this phenomenon, and there will be others in the future. Guaranteed.

Of late the term “application delivery” has been creeping up into the vernacular. That could be because cloud has pushed it to the fore, necessarily. Cloud purports to eliminate the “concern” of infrastructure and allows IT to focus on … you guessed it, the application. Which in turn means the delivery of applications is becoming more and more pervasive in the strategic vocabulary of the market.

But like cloud and its predecessors, the term application delivery is somewhat vague and without definition. I am not going to define it, in case you were wondering, because quite frankly I’ve watched its expansion and transformation over the past decade and understand that application delivery is not static. As new technology and deployment models arise, new techniques and architectures must also arise to meet the challenges that naturally arise along with those applications.

But how, then, do you know what is and is not application delivery? If it can morph and grow and transform with time and technology, then anything can be considered application delivery, right?

Not entirely. Application delivery, after all, is about an end-to-end process. It’s about a request that is sent to an application and subsequently fulfilled and returned to the originator of the request. Depending on the application this process may be simple or exceedingly complex, requiring authentication, logging, verification, interaction of multiple services and, one hopes, a wealth of security services ensuring that what is delivered is what was intended and desired, and is not carrying along something malicious.

A definition comprising these concepts would be either be far too broad so as to be meaningless, or so narrow that it left no room to adapt to future technologies. Neither is acceptable, in my opinion. A much better way to understand what is (and conversely what is not) application delivery is to learn three simple axioms that define the core concepts upon which application delivery is based.

APPLICATION-CENTRIC

“Applications are not servers, hypervisors, or operating systems.”

Applications are not servers. They are not the physical or virtual server upon which they are deployed and from where they draw core resources. They are not the web and application servers on which they rely for application-layer protocol support. They are not the network stack from which they derive their IP address or TCP connection characteristics. They are uniquely separate entities that must be managed individually.

The concrete example of this axiom in action is health-monitoring of applications. Too many times we see load balancing services configured with health-checking options that are focused on IP or TCP or HTTP parameters. Ping checks, TCP half-open checks, HTTP status checks. None of these options are relevant to whether or not the application is available and executing correctly. A ping check assures us the network is operating and the OS is responding. A TCP half-open check tells us network stack is operating properly. An HTTP status check tells us the web or application server is running and accepting requests. But none of these even touches on whether or not the application is executing and responding correctly.

Similarly, applications are not ports, and security services must be able to secure the application, not merely its operating environment. Applications are not – or should not – be defined by their network characteristics, and neither should they be secured based on these parameters.

Applications are not servers, hypervisors, or operating systems. They are individual entities that must be managed individually, from a performance, availability, and security perspective.

MITIGATE OPERATIONAL RISK

“Availability, performance, and security are not separate operational challenges.”

In most IT organizations the people responsible for security are not responsible for performance or availability, and vice-versa. While devops tries to bridge the gap between applications and operations-focused professionals, we may need to intervene first and unify operations. These three operational concerns are intertwined, they are interrelated, they are paternal triplets. A DDoS attack is security, but it has – or likely will have – a profound impact on both performance and availability. Availability has an impact on performance, both positive and negative. And too often performance concerns result in the avoidance of security that can ultimately return to bite availability in the derriere.

Application delivery recognizes that all three components of operational risk are inseparable, and they must be viewed as a holistic concern. Each challenge should be addressed with the others in mind, and with the understanding that changes in one will impact the others.

OPERATE WITHIN CONTEXT

“Application delivery decisions cannot be made efficiently or effectively in a vacuum.”

Finally, application delivery recognizes that decisions regarding application performance, security, and availability cannot be made within a vacuum. What may improve performance for a mobile client accessing an application over the Internet may actually impair performance for a mobile client accessing the application over the internal data center network. What is appropriate authentication methods for a remote PC desktop are unlikely to be applicable to the same user requesting access over a smartphone. The various components of context provide the means by which the appropriate policies are enforced and applied at the right time to the right client for the right application.

It is context that provides the unique set of parameters that enfolds any given request. We cannot base decisions solely on user, because user may migrate during the day from one client device to another, and one location to another. We cannot base decisions solely on device, because network conditions and type may change as the user roams from home to the office and out to lunch, moving seamlessly between mobile carrier network and WiFi. We cannot base decisions solely on application, because the means and location of the client may change its behavior and impact delivery in a negative way.

When you put these axioms into action, the result is application delivery. A comprehensive, holistic and highly strategic approach to delivering applications. It is impossible to say application delivery is these five products delivered as a solution because whether or not those products actually comprise an application delivery network depends on whether or not they are able to deliver on the promise of these three axioms of application delivery.

Connect with Lori: Connect with F5:

Related blogs & articles:

The Pythagorean Theorem of Operational Risk

DevOps. It’s in the Culture, Not Tech.

Ecosystems are Always in Flux

The Impossibility of CAP and Cloud

Who In The World Are You?

Operational Risk Comprises More Than Just Security

At the Intersection of Cloud and Control…

IT Services: Creating Commodities out of Complexity

What is a Strategic Point of Control Anyway?

Technorati Tags: F5,MacVittie,application delivery,application delivery axioms,performance,security,availability,operational risk,architecture,platform,context-aware,blog